Univention Bugzilla – Bug 33644
Group name mixture after univention-ad-takeover
Last modified: 2014-02-06 13:37:30 CET
After migrating a AD domain via univention-ad-takeover the group names for the default groups are mixed. For example Domain Users vs. Domänenbenutzer after migrating a German AD. The univention-ad-takeover process should rename the UCS groups to the names coming from Windows.
The rename process should consider the nagios values: univention-config-registry set 'auth/nagios/group/Domain Admins?yes' univention-config-registry set 'auth/nagios/group/Domain Admins?yes' It would be good if the rename process has a hook directory and every package can use it's own rename script.
The attribute univentionDefaultGroup (cn=default,cn=univention,$LDAP_BASE) should also be adjusted.
Nested groups should be considered as well.
In former versions univention-ad-takeover searched the AD for well known group names and created a bunch of UCR variables like connector/s4/mapping/group/table/"Domain Users"="Domänenbenutzer" to instruct the S4 Connector to map these group objects during sync. Now univention-ad-takeover has been adjusted to rename the groups instead in UCS LDAP to match the names as found in AD. Additionally it sets the UCR variables of the following kind: groups/default/domainusers="Domänenbenutzer" Now it's up to the UCR templates to translate "Domain Users" according to these UCR variables. This design might seem odd, but it allows a "UCS group entity" (such as domainusers := "Domain Users") to be identified by a different "custom group name", without prior knowledge of all the possible "custom group names". This way, the univention-ldap package can continue to define a set of default ACLs for a group typically called "Domain Users", which may be customized to a different name. The obvious drawback is, that each package dealing with groups needs to be made aware of this. Maybe we need the same for users, but this first iteration only addresses groups. Advisory: 2013-12-16-univention-s4-connector.yaml
*** Bug 33642 has been marked as a duplicate of this bug. ***
UCS 3.2 and a french w2k12 (1) Phase I finished. Now the SYSVOL share should be copied manually from \\win-270vd8dd5to\sysvol to \\master\sysvol (e.g. using robocopy): robocopy /mir /sec /z \\win-270vd8dd5to\sysvol \\master\sysvol this does not work if the Administrator username is NOT "Administrator" in windows (e.g., Administrateur). Please add net use \\$UCSNAME\Freigabe /USER:Administrator to the phase II message and the wiki article => Now the SYSVOL share should be copied manually from \\win-270vd8dd5to\sysvol to \\master\sysvol (e.g. using robocopy): net use \\master\Freigabe /USER:Administrator robocopy /mir /sec /z \\win-270vd8dd5to\sysvol \\master\sysvol (2) after phase I i now have both groups Domain Admins and the french version "Utilisateurs du domaine" -> univention-ldapsearch -LLL cn=Domain\ Users dn dn: cn=Domain Users,cn=groups,dc=w2k12,dc=test -> univention-ldapsearch -LLL cn="Utilisateurs du domaine" dn dn: cn=Utilisateurs du domaine,cn=users,dc=w2k12,dc=test (3) univention-s4connector-list-rejected fails due to enconding problems -> univention-s4connector-list-rejected UCS rejected 1: UCS DN: cn=Printer-Admins,cn=groups,dc=w2k12,dc=test S4 DN: <not found> Filename: /var/lib/univention-connector/s4/1389014185.169246 2: UCS DN: cn=Printer-Admins,cn=groups,dc=w2k12,dc=test S4 DN: <not found> Filename: /var/lib/univention-connector/s4/1389014282.066014 S4 rejected Traceback (most recent call last): File "/usr/sbin/univention-s4connector-list-rejected", line 161, in <module> main() File "/usr/sbin/univention-s4connector-list-rejected", line 145, in main print "%5d: S4 DN: %s" % (i,univention.s4connector.s4.encode_attrib(dn).encode('latin')) UnicodeEncodeError: 'latin-1' codec can't encode character u'\u2019' in position 15: ordinal not in range(256) (it works if i remove .encode('latin'))
Created attachment 5714 [details] ad-takeover.log
Created attachment 5715 [details] connector-s4.log
The reported issues have been fixed and the build version has been adjusted in the yaml advisory.
I now have two Admins -> id administrateur uid=2011(Administrateur) gid=5001(Utilisateurs du domaine) Gruppen=5001(Utilisateurs du domaine),5071(Utilisateurs) -> id administrator uid=2002(Administrator) gid=5000(Admins du domaine) Gruppen=5000(Admins du domaine), # Administrateur, users, w2k12.test dn: uid=Administrateur,cn=users,dc=w2k12,dc=test sambaPrimaryGroupSID: S-1-5-21-783941786-3613876442-1044395446-513 # Administrator, users, w2k12.test dn: uid=Administrator,cn=users,dc=w2k12,dc=test sambaPrimaryGroupSID: S-1-5-21-783941786-3613876442-1044395446-512 "Administrator" is member of "Domain Admins" but his sid has been changed (no longer a windows admin?) and "Administrateur" is not member of "Domain Admins" but has the 513 RID. This does not look good. Either we create a mapping from the AD -513 user to our Administrator or we rename our Administrator to the name of the AD -513 user. The latter also fixes the problem with robocopy in phase II (net use /USER: before robocopy if AD Administratorname not equal to the UCS Administratorname).
sambaPrimaryGroupSID is just the sid of the primary group, but you are right, we will need to do some kind of "translation" for these accounts as well. Assessment of the two issues here: 1. After the takeover "Administrateur" has the Well Known SID which was previously assigned to "Administrator" and the SID of "Administrator" was changed by Samba into a normal user SID: ======================================================= # Administrateur, users, w2k12.test dn: uid=Administrateur,cn=users,dc=w2k12,dc=test sambaSID: S-1-5-21-783941786-3613876442-1044395446-500 # Administrator, users, w2k12.test dn: uid=Administrator,cn=users,dc=w2k12,dc=test sambaSID: S-1-5-21-783941786-3613876442-1044395446-1607 ======================================================= This point is not directly visible to the user but could possibly cause problems in file and/or directory access control. 2. After the takeover "Administrateur" is not member of the renamed "Domain Admins" group, somehow the S4 connector decided to keep only "Administrator" in it. This second point is visible and confusing to the user.
The user mapping has been implemented as well. Advisory: 2013-12-11-univention-s4-connector.yaml
YAML: Failed: I think we should explain, that the user and groups names from the AD are now used. Tests: Failed: I was able to take over an German AD without any problem. Including a join of an UCS DC Backup after the take over. But I'm unable to take over an French W2K12 AD: From /var/log/univention/ad-takeover.log: ----------------------------------------------------------------------------- 2014-01-24 07:42:50,670 Starting Samba domain join. 2014-01-24 07:42:50,942 SPNEGO(gssapi_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_NO_LOGON_SERVERS 2014-01-24 07:42:50,989 SPNEGO(gssapi_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_NO_LOGON_SERVERS 2014-01-24 07:42:51,350 ERROR(runtime): uncaught exception - DsAddEntry failed 2014-01-24 07:42:51,350 File "/usr/lib/python2.6/dist-packages/samba/netcmd/__init__.py", line 175, in _run 2014-01-24 07:42:51,351 return self.run(*args, **kwargs) 2014-01-24 07:42:51,351 File "/usr/lib/python2.6/dist-packages/samba/netcmd/domain.py", line 560, in run 2014-01-24 07:42:51,352 machinepass=machinepass, use_ntvfs=use_ntvfs, dns_backend=dns_backend) 2014-01-24 07:42:51,352 File "/usr/lib/python2.6/dist-packages/samba/join.py", line 1220, in join_DC 2014-01-24 07:42:51,352 ctx.do_join() 2014-01-24 07:42:51,352 File "/usr/lib/python2.6/dist-packages/samba/join.py", line 1100, in do_join 2014-01-24 07:42:51,353 ctx.join_add_objects() 2014-01-24 07:42:51,353 File "/usr/lib/python2.6/dist-packages/samba/join.py", line 569, in join_add_objects 2014-01-24 07:42:51,353 ctx.join_add_ntdsdsa() 2014-01-24 07:42:51,353 File "/usr/lib/python2.6/dist-packages/samba/join.py", line 502, in join_add_ntdsdsa 2014-01-24 07:42:51,353 ctx.DsAddEntry([rec]) 2014-01-24 07:42:51,354 File "/usr/lib/python2.6/dist-packages/samba/join.py", line 465, in DsAddEntry 2014-01-24 07:42:51,354 raise RuntimeError("DsAddEntry failed") 2014-01-24 07:42:51,356 workgroup is DEADLOCK32 2014-01-24 07:42:51,356 realm is deadlock32.local 2014-01-24 07:42:51,356 checking sAMAccountName 2014-01-24 07:42:51,356 Adding CN=MASTER321,OU=Domain Controllers,DC=deadlock32,DC=local 2014-01-24 07:42:51,356 Adding CN=MASTER321,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=deadlock32,DC=local 2014-01-24 07:42:51,356 Adding CN=NTDS Settings,CN=MASTER321,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=deadlock32,DC=local 2014-01-24 07:42:51,356 DsAddEntry failed with status (5, 'WERR_ACCESS_DENIED') info (8567, 'WERR_DS_INCOMPATIBLE_VERSION') 2014-01-24 07:42:51,357 Join failed - cleaning up 2014-01-24 07:42:51,357 checking sAMAccountName 2014-01-24 07:42:51,357 removing samaccount: CN=MASTER321,OU=Domain Controllers,DC=deadlock32,DC=local 2014-01-24 07:42:51,357 Deleted CN=MASTER321,OU=Domain Controllers,DC=deadlock32,DC=local 2014-01-24 07:42:51,357 Deleted CN=MASTER321,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=deadlock32,DC=local 2014-01-24 07:42:51,377 Error: Samba domain join failed. ----------------------------------------------------------------------------- Maybe this has nothing to do with this original bug report but it blocks my QA. Test system is on krus: ssh root@10.201.32.1 univention-ad-takeover 10.201.32.2 -U Administrateur --password="Univention:99"
The log shows the following message during the first join attempt: > 2014-01-24 07:40:51,342 DsAddEntry failed with status (5, 'WERR_ACCESS_DENIED') info (8567, 'WERR_DS_INCOMPATIBLE_VERSION') I guess that's Bug 28913. Don't know how Felix got this working in his VMs: * fbotner_master-i386-50 * fbotner_w2k12-fr-63 (snapshot "plain ad" or "running", pw: univentionUCS3.2)
(In reply to Arvid Requate from comment #14) > The log shows the following message during the first join attempt: > > > 2014-01-24 07:40:51,342 DsAddEntry failed with status (5, 'WERR_ACCESS_DENIED') info (8567, 'WERR_DS_INCOMPATIBLE_VERSION') > > I guess that's Bug 28913. > > Don't know how Felix got this working in his VMs: > * fbotner_master-i386-50 > * fbotner_w2k12-fr-63 (snapshot "plain ad" or "running", pw: > univentionUCS3.2) OK, you are right. Set to fixed again.
I doubled the timeout for the initial listener replication to 180 seconds (in the french QA domain it took about 148 seconds) and tripled the time spent waiting for the listener to terminate (now 30 seconds). In case the Administrator changes it's name, I also needed to adjust the name in the smb.conf parameter "admin users" (part of Bug #33896) to be able to copy the sysvol.
Btw. the listener log rate is surprisingly slow, it takes at least 4 seconds between each call to well-known-sid-name-mapping/samba4-idmap. What's going on?
It's the univention.config_registry.handler_set which causes the delay. Maybe we should adjust the listener module to collect the ucr changes and commit them in the postrun in one go (before running the hooks).
See also Bug 34003.
Tests: OK: The takeover of a French and German AD was successful. In the French setup I had to set "ucr set samba/adminusers='join-backup administrateur'", that will be fixed through Bug #33896. Code: OK YAML: Failed, I think we should describe that the well known local users and groups are renamed to the AD names.
Advisory adjusted.
(In reply to Arvid Requate from comment #21) > Advisory adjusted. OK
http://errata.univention.de/ucs/3.2/48.html