Bug 40435 - Windows-Client DN positions not synchronized, school GPOs not applied to client
Windows-Client DN positions not synchronized, school GPOs not applied to client
Status: CLOSED FIXED
Product: UCS@school
Classification: Unclassified
Component: Samba 4 - Slave PDC
UCS@school 4.1
Other Linux
: P3 normal with 2 votes (vote)
: UCS@school 4.1 R2 vXXX
Assigned To: Arvid Requate
Stefan Gohmann
: interim-3
: 41570 (view as bug list)
Depends on: 42981
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-14 21:44 CET by Arvid Requate
Modified: 2016-12-01 11:57 CET (History)
6 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 4: Minor Usability: Impairs usability in secondary scenarios
Who will be affected by this bug?: 3: Will affect average number of installed domains
How will those affected feel about the bug?: 3: A User would likely not purchase the product
User Pain: 0.206
Enterprise Customer affected?:
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Ticket number: 2016083021000628
Bug group (optional): Troubleshooting
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate univentionstaff 2016-01-14 21:44:41 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.
Comment 1 Arvid Requate univentionstaff 2016-01-14 21:46:55 CET
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
Comment 2 Arvid Requate univentionstaff 2016-06-14 18:46:34 CEST
*** Bug 41570 has been marked as a duplicate of this bug. ***
Comment 3 Sönke Schwardt-Krummrich univentionstaff 2016-09-21 15:07:22 CEST
Are there any problems that are caused by this difference?
Comment 4 Arvid Requate univentionstaff 2016-09-26 13:50:00 CEST
> 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
Comment 5 Florian Best univentionstaff 2016-09-26 14:04:42 CEST
This explains my unreproducible probems during some product tests.
Comment 6 Arvid Requate univentionstaff 2016-11-07 15:37:59 CET
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.
Comment 7 Arvid Requate univentionstaff 2016-11-17 14:30:21 CET
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
Comment 8 Stefan Gohmann univentionstaff 2016-11-23 06:41:27 CET
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
Comment 9 Arvid Requate univentionstaff 2016-11-23 13:21:43 CET
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.
Comment 10 Arvid Requate univentionstaff 2016-11-24 12:15:31 CET
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.
Comment 11 Stefan Gohmann univentionstaff 2016-11-29 15:39:40 CET
OK, my tests were successful.

YAML: OK
Comment 12 Janek Walkenhorst univentionstaff 2016-12-01 11:57:23 CET
<http://errata.software-univention.de/ucs/4.1/347.html>