Univention Bugzilla – Bug 40435
Windows-Client DN positions not synchronized, school GPOs not applied to client
Last modified: 2016-12-01 11:57:23 CET
I joined a windows client without pre-created account into an UCS@school Samba/AD DC Slave (Samba/AD also present on the Master, but that doesn't matter). In Samba/AD the Machine account has not been synchronized to the proper location below the school-OU: dn: CN=WIN7PRO2,CN=Computers,DC=nstx,DC=local In OpenLDAP the account is below the OU: dn: cn=WIN7PRO2,cn=computers,ou=gsmitte,dc=nstx,dc=local It would be great if the connector (or whatever) could automatically synchronize the positions. Actually we have a script for that, but I'm hesitating to actually run it, because it wants to move a builtin group too: root@slave74:~# /usr/share/univention-s4-connector/univention-s4-position-sync --dry-run Option --dry-run given, checking only: RENAME: cn=win7pro2,cn=computers,DC=nstx,DC=local to cn=WIN7PRO2,cn=computers,ou=gsmitte,DC=nstx,DC=local RENAME: CN=Print Operators,cn=builtin,DC=nstx,DC=local to cn=Printer-Admins,cn=groups,DC=nstx,DC=local RENAME: cn=slave74,ou=domain controllers,DC=nstx,DC=local to cn=slave74,cn=dc,cn=server,cn=computers,ou=gsmitte,DC=nstx,DC=local Probably it's ok to run it, but this should be either documented or automatized. You ask why I care? Because I want to have school-specific GPOs applied to my Windows Client.
Yeah, and this is what happens when you dare to use that tool: root@slave74:~# /usr/share/univention-s4-connector/univention-s4-position-sync Really modify Samba4 object positions? [yN]: y RENAME: cn=win7pro2,cn=computers,DC=nstx,DC=local to cn=WIN7PRO2,cn=computers,ou=gsmitte,DC=nstx,DC=local RENAME: CN=Print Operators,cn=builtin,DC=nstx,DC=local to cn=Printer-Admins,cn=groups,DC=nstx,DC=local Traceback (most recent call last): File "/usr/share/univention-s4-connector/univention-s4-position-sync", line 212, in <module> samdb.rename(ldb.Dn(samdb, object['dn']), ldb.Dn(samdb, mapped_dn)) _ldb.LdbError: (53, 'subtree_rename: Cannot move CN=Print Operators,cn=builtin,DC=nstx,DC=local to CN=Printer-Admins,CN=Groups,DC=nstx,DC=local - DISALLOW_MOVE set') That is a good message, the client has been moved: dn: CN=WIN7PRO2,CN=computers,OU=gsmitte,DC=nstx,DC=local
*** Bug 41570 has been marked as a duplicate of this bug. ***
Are there any problems that are caused by this difference?
> You ask why I care? Because I want to have school-specific GPOs applied to my Windows Client. School exam GPOs for the machine will not be applied, see ucs-test-ucsschool/90_ucsschool/98_samba4_evaluate_windows_gpo
This explains my unreproducible probems during some product tests.
IMHO the S4-Connector should synchronize the OpenLDAP DN position of Windows clients to Samba/AD during sync_from_ucs (i.e. if the S4-Connector is in sync or write mode). Only for Windows clients, not for UCS/Windows DCs. Bug 42859 showed that the S4-Connector recognizes move operations, at least when they happen in Samba/AD (via objectGUID). This shows that the S4-Connector doesn't completely ignore DN positions. And if it synchronizes the positions in that case, then it should always do it. The current situation also complicates analysis of support cases, because there are always two possibilities: DN synced or not. The current behavior was inherited from the AD-Connector, where Univention didn't want to move objects of the other domain. That's a good decision. So with regard to the AD-Connector we have to discuss if we want to change the behavior there as well. We could A) don't backport that change to the AD-Connector or B) only synchronize positions if the objectSid of the AD-LDAP-base matches the domain SID of the UCS domain (more complicated) or C) synchronize positions only if activated via UCR. AFAIK there are UCS@school environments which also use the AD-Connector to sync AD domains. Option C) could be good for those cases, somebody involved in such a scenario might want to comment.
As discussed I fixed this now by adjusting the LDB module univention_samaccountname_ldap_check and the helper script ucs-school-create_windows_computer in errata4.1-4. As a result, the position of new machine account objects created in Samba/AD by joining a Windows client now matches the position of the corresponding object in OpenLDAP. Details: 1. Via Bug #42981 I adjusted the UMC call selectiveudm/create_windows_computer to return the DN of the created object to the caller. 2. The calling script ucs-school-create_windows_computer maps this into a Samba/AD DN by changing the base. 3. Finally the LDB module reads this "proposed" Samba/AD DN. If nothing is returned the LDB module proceeds as before fixing this Bug. Otherwise it validates the output from ucs-school-create_windows_computer and rewrites the default DN in the machine add request to the proposed value. Advisory for errata4.1-4: univention-ldb-modules.yaml
I' only updated my test environment to the latest test errata packages. The UCS@school packages are still 4.1 R2 v8. After that, I was unable to join a Windows client. I got the following message in Windows 7: Zuordnung von Kontennamen und Sicherheitskennungen wurden nicht durchgeführt. From the s4connector.log on the School Slave: 04.12.2015 23:59:07,917 LDAP (PROCESS): sync from ucs: [windowscomputer] [ add] cn=WIN7PRO200,cn=computers,ou=schule1,DC=deadlock71,DC=intranet 04.12.2015 23:59:09,43 LDAP (PROCESS): sync to ucs: [windowscomputer] [ modify] cn=win7pro200,cn=computers,ou=schule1,dc=deadlock71,dc=intranet From the log.samba file on the School Slave: [2015/12/04 23:58:56.137030, 1, pid=21488] ../lib/ldb-samba/ldb_wrap.c:76(ldb_wrap_debug) ldb: univention_samaccountname_ldap_check: calling ucs-school-create_windows_computer [2015/12/04 23:58:59.148567, 1, pid=19133] ../lib/ldb-samba/ldb_wrap.c:76(ldb_wrap_debug) ldb: univention_samaccountname_ldap_check: LDB_ERR_ENTRY_ALREADY_EXISTS [2015/12/04 23:58:59.253257, 1, pid=21491] ../lib/ldb-samba/ldb_wrap.c:76(ldb_wrap_debug) ldb: univention_samaccountname_ldap_check: calling ucs-school-create_windows_computer Traceback (most recent call last): File "/usr/sbin/ucs-school-create_windows_computer", line 74, in <module> main() File "/usr/sbin/ucs-school-create_windows_computer", line 62, in main result = connection.request(args.command, options) File "/usr/lib/pymodules/python2.7/univention/lib/umc_connection.py", line 143, in request raise HTTPException(error_message) httplib.HTTPException: 500 on master711.deadlock71.intranet (selectiveudm/create_windows_computer): {"status": 590, "message": "Failed to create windows computer\nTraceback (most recent call last):\n File \"/usr/lib/pymodules/python2.7/univention/management/console/modules/selective-udm/__init__.py\", line 128, in create_windows_computer\n computer_dn = computer.create()\n File \"/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py\", line 305, in create\n return self._create()\n File \"/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py\", line 722, in _create\n al.extend(self._ldap_modlist())\n File \"/usr/lib/pymodules/python2.7/univention/admin/handlers/computers/windows.py\", line 546, in _ldap_modlist\n raise univention.admin.uexceptions.uidAlreadyUsed(': %s' % requested_uid)\nuidAlreadyUsed: : WIN7PRO200$\n"} [2015/12/04 23:59:01.740784, 1, pid=19125] ../lib/ldb-samba/ldb_wrap.c:76(ldb_wrap_debug) ldb: univention_samaccountname_ldap_check: LDB_ERR_ENTRY_ALREADY_EXISTS [2015/12/04 23:59:01.741284, 0, pid=19125] ../source4/dsdb/common/util_samr.c:184(dsdb_add_user) Failed to create user record CN=WIN7PRO200,CN=Computers,DC=deadlock71,DC=intranet: ldb_request: Entry already exists (68) Before I started the join, I didn't find the Windows client on the DC Master: ----------------------------------------------------------------------------- root@master711:~# univention-ldapsearch cn=win7* dn # extended LDIF # # LDAPv3 # base <dc=deadlock71,dc=intranet> (default) with scope subtree # filter: cn=win7* # requesting: dn # # search result search: 3 result: 0 Success # numResponses: 1 root@master711:~# ----------------------------------------------------------------------------- After the join: ----------------------------------------------------------------------------- root@master711:~# univention-ldapsearch cn=win7* dn # extended LDIF # # LDAPv3 # base <dc=deadlock71,dc=intranet> (default) with scope subtree # filter: cn=win7* # requesting: dn # # WIN7PRO200, computers, Schule1, deadlock71.intranet dn: cn=WIN7PRO200,cn=computers,ou=Schule1,dc=deadlock71,dc=intranet # WIN7PRO200$, uid, temporary, univention, deadlock71.intranet dn: cn=WIN7PRO200$,cn=uid,cn=temporary,cn=univention,dc=deadlock71,dc=intranet # search result search: 3 result: 0 Success # numResponses: 3 # numEntries: 2 root@master711:~# ----------------------------------------------------------------------------- From the management-console-module-selective-udm.log on the DC Master: ----------------------------------------------------------------------------- root@master711:~# less /var/log/univention/management-console-module-selective-udm.log 04.12.15 23:58:43.093 DEBUG_INIT 04.12.15 23:58:43.776 MODULE ( WARN ) : Using deprecated LDAP_Connection.search_base parameter. 04.12.15 23:58:46.084 DEBUG_INIT 04.12.15 23:58:46.717 MODULE ( WARN ) : Using deprecated LDAP_Connection.search_base parameter. 04.12.15 23:58:46.855 ADMIN ( WARN ) : cancel: release (uidNumber): 2013 04.12.15 23:58:46.856 ADMIN ( WARN ) : cancel: release (sid): S-1-5-21-1441717394-3094984520-2066648231-5026 04.12.15 23:58:46.868 MODULE ( WARN ) : Failed to create windows computer Traceback (most recent call last): File "/usr/lib/pymodules/python2.7/univention/management/console/modules/selective-udm/__init__.py", line 128, in create_windows_computer computer_dn = computer.create() File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 305, in create return self._create() File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 722, in _create al.extend(self._ldap_modlist()) File "/usr/lib/pymodules/python2.7/univention/admin/handlers/computers/windows.py", line 546, in _ldap_modlist raise univention.admin.uexceptions.uidAlreadyUsed(': %s' % requested_uid) uidAlreadyUsed: : WIN7PRO200$ ----------------------------------------------------------------------------- After updating to the latest UCS@school test packages on the DC Master, the join works. I've reverted my environment. If you like, you can use it: On kiwik: for vm in stefan_4.0-71.1-School-Master stefan_4.0-71.2-School-Backup stefan_4.0-71.3-School-Slave stefan_Windows7-77.1; do virsh snapshot-revert $vm 4.1-4errata327-4.1r2v8-testerrata; done After that, you can connect to the Windows client stefan_Windows7-77.1 via libvirt and join it into the domain deadlock71.intranet. The IPs: DC Master: 10.201.71.1 DC Backup: 10.201.71.2 (even if the hostname is slave712) School Slave: 10,201.71.3
The package has not been updated on the master: ii univention-management-console-module-selective-udm 5.0.0-1.21.20151014155 Not sure how we can handle that. I'll look into the interaction between the new ucs-school-create_windows_computer and that UMC module version.
I've adjusted the ucs-school-create_windows_computer script to work with the old version of umc-selective-udm. merged, built and advisory adjusted.
OK, my tests were successful. YAML: OK
<http://errata.software-univention.de/ucs/4.1/347.html>