Univention Bugzilla – Bug 36776
member-mode fails if Administrator account (well known RID) is renamend in AD
Last modified: 2015-01-29 11:43:07 CET
might be related to #35562 The member mode fails if * in AD, the "well known" administrator has been renamed * in UMC "Administrator" is used The samba join script renames the "Administrator" account in LDAP, but tries to use the "old" DN for UDM commandline. In UCS 3.2-4 it fails in line 277: univention-directory-manager computers/$server_role modify "$@" --dn "$ldap_hostdn" --append-option samba --set password="$(cat /etc/machine.secret)" || die
workaround: rename user / change password of the administrative account (RID 500) in UCS to the values of AD before running the member mode.
I cannot reproduce this, worked for me (tested with UCS 4.0): 1. Renamed AD Administrator name (and pre-2000 name) via AD Users and Computers 2. Started the UMC-App and used that account. The AD user had a different password than the Administtrator in UCS. The method univention.lib.admember.run_samba_join_script guesses the new DN: binddn = 'uid=%s,cn=users,%s' % (username, ucr.get('ldap/base')) where username is the given AD account name. Maybe the guess was wrong? I agree that we should LDAP-search at this point. If you have any details, please fill them in.
The log attached to Bug 36778 suggests that this might also have be caused by the renaming of the "Domain Admins" group: Process: Renaming 'cn=Domain Admins,cn=groups,dc=my,dc=domain' to 'Domänen-Admins' in UCS LDAP. I guess this could lead to a race between LDAP-ACL evaluation and the slapd restart py the well-known-sid-name-mapping listener: If the slapd hasn't been reloaded yet (listener postrun) then the active LDAP-ACLs would still match in "Domain Admins" but the LDAP object would already be in "Domänen-Admins" instead. This could be avoided if the rename_well_known_sid_objects method would wait for the restart of the slapd (or ensuring in some other way that the account has LDAP-read-access as a "domain administrator"). The weak point about this theory is that we should already have seen such a problem with the normal "Administrator" joining against a german AD, which we didn't.
(In reply to Arvid Requate from comment #2) > I cannot reproduce this, worked for me (tested with UCS 4.0): > > 1. Renamed AD Administrator name (and pre-2000 name) via AD Users and > Computers > 2. Started the UMC-App and used that account. The AD user had a different > password than the Administtrator in UCS. looks identical to my tests with UCS 3.2 > The method univention.lib.admember.run_samba_join_script guesses the new DN: > > binddn = 'uid=%s,cn=users,%s' % (username, ucr.get('ldap/base')) > > where username is the given AD account name. > Maybe the guess was wrong? I agree that we should LDAP-search at this point. yes, we should search AD here to be sure. But in the case I tested the guess would have been good, so that wasn't the problem. > If you have any details, please fill them in. Is there already a difference between UCS 3.2 and 4.0?
We now wait for slapd restart when Domain Admins has been renamed during AD Member setup. This is the only reason I can see here for failing apart from Bug 35562. Advisory: 2014-12-09-univention-lib.yaml
YAML: OK Tests: The join works fine with a renamed Administrator Code review: OK
<http://errata.univention.de/ucs/4.0/56.html>