Univention Bugzilla – Bug 45992
(4.2) GPOs not applied to OU-spanning users
Last modified: 2018-06-04 15:34:08 CEST
A teacher logged in at his default school, gets all his GPOs applied. If he logs in at an other school ou, the GPOs could not applied, because the school slave is not allowed to read the linked GPOs. _____________________________________________________________________________ samba-tool gpo listcontainers {9CC57F64-AA1A-4AEB-BA59-34C1D903BB93} Container(s) using GPO {9CC57F64-AA1A-4AEB-BA59-34C1D903BB93} DN: OU=a261,DC=edu,DC=univention,DC=test DN: OU=a473,DC=edu,DC=univention,DC=test DN: OU=a216,DC=edu,DC=univention,DC=test DN: OU=a262,DC=edu,DC=univention,DC=test DN: OU=a263,DC=edu,DC=univention,DC=test DN: OU=a915,DC=edu,DC=univention,DC=test DN: OU=a371,DC=edu,DC=univention,DC=test DN: OU=a110,DC=edu,DC=univention,DC=test DN: OU=a474,DC=edu,DC=univention,DC=test DN: OU=a109,DC=edu,DC=univention,DC=test DN: OU=a217,DC=edu,DC=univention,DC=test DN: OU=a260,DC=edu,DC=univention,DC=test DN: OU=a264,DC=edu,DC=univention,DC=test DN: OU=a267,DC=edu,DC=univention,DC=test DN: OU=a372,DC=edu,DC=univention,DC=test root@e262-sl01:~# samba-tool gpo listcontainers {9CC57F64-AA1A-4AEB-BA59-34C1D903BB93} Container(s) using GPO {9CC57F64-AA1A-4AEB-BA59-34C1D903BB93} DN: OU=a262,DC=edu,DC=univention,DC=test root@e261-sl01:/home/e262/lehrer/max.muste/windows-profiles# samba-tool gpo listcontainers {9CC57F64-AA1A-4AEB-BA59-34C1D903BB93} Container(s) using GPO {9CC57F64-AA1A-4AEB-BA59-34C1D903BB93} DN: OU=a261,DC=edu,DC=univention,DC=test _____________________________________________________________________________ dn: uid=max.muste,cn=lehrer,cn=users,ou=a262,dc=edu,dc=univention,dc=test _______________________________________________________________________________ UCS-Version version/erratalevel: 256 version/patchlevel: 3 version/releasename: Lesum version/version: 4.2 appcenter/apps/ucsschool/version: 4.2 v6
I had longer discussions with Stefan, Christina and Michael. The current solution, that is most flexible: 1) The LDAP ACLs have to be changed, so that all School-Slaves are able to read all GPO-Link attributes for other OUs. 2) Best practice for the following scenario: OU=e261,DC=edu,DC=univention,DC=test → dc-e261 → win-e261-01 OU=e262,DC=edu,DC=univention,DC=test → dc-e262 → johndoe (multi-school user; is member in e261 and e262!) The GPO for OU e261 should be linked to OU e261 AND e262. And for the GPO a security filter "group=Domain Users e261" should be set. Additionaly/Alternatively WMI filters should be set, that limit the GPO to computers that are part of OU e261. The GPO for OU e262 should be set up similar: - linked to OU e261 and e262 - security filter for group=Domain User e262 - WMI filter for computers of OU e262 This way, when user johndoe logs on to an OU 261 computer, there are only 2 GPOs left through the security filter that can be applied. These 2 GPOs are then further reduced to 1 GPO via the set WMI filter. If the GPO for e261 is altered, it applies automatically to all attached OUs. So in the worst case, the GPOs for each OU have to be attached to each single OU. But this is a one time effort. If this is tested, it should be documented in the UCS@school admin manual.
[4.2 3713dcc2] Bug #45992: Allow read access to GPO list for all DC-Slaves [4.2 dfb14d95] Bug #45992: YAML Notes: I increased the join script version. OUs are not updated automatically during the update. Changing something on the OUs adds the msGPO links to it.
Please also implement a test script.
(In reply to Sönke Schwardt-Krummrich from comment #3) > Please also implement a test script. [4.2 d555c682] Bug #45992: test gpo link replication
Updated ucs-test-ucsschool to make the new test script compatible with UCS@school master systems without installed S4: f0beac3e Bug #45992: add changelog entry 245cb0ca Bug #45992: improved test script OK: code change OK: functional change OK: tests OK: changelog entry OK: advisory
UCS@school 4.2 v9 has been released. https://docs.software-univention.de/changelog-ucsschool-4.2v9-de.html If this error occurs again, please clone this bug.