Univention Bugzilla – Bug 36354
Active Directory Connection Wizards sets wrong UCR variable for binddn
Last modified: 2016-12-14 12:36:44 CET
The Active Directory Connection Wizard sets the UCR variable "connector/ad/ldap/binddn" always to "cn=<Username>,cn=users,<ldapbase>", even if the given user is not in "cn=users". Example: There is an additional Domain Admin within the OU "ou=admins". This user was specified as admin user in the Active Directory Connection Wizard. The user is found and the Wizard can be finished successfully. But the synchronisation doesn't work since the wrong DN is written to UCR: Expected behaviour: the UCR variable ''connector/ad/ldap/binddn'' should contain ''cn=Admin,ou=admins,DC=sld,DC=tld'' Observed behaviour: the UCR variable ''connector/ad/ldap/binddn' contains ''cn=Admin,cn=users,DC=sld,DC=tld''
Reported via Ticket#2014103021000207
Removed errata status since it happens only once.
Happened for the second time at remote installation at a customer. This is really an annoying bug because it is very difficult to find out for a usual user. At least if he is a new user.
The string is hardcoded in Javascript: services/univention-ad-connector/umc/js/adconnector/SetupWizard.js: 592 » » » » LDAP_BindDN: lang.replace('cn={username},cn=users,{LDAP_Base}', vals), Is it possible to do a univention-ad-search at this state? How to get this DN? Otherwise we need to adjust the field so that the user must enter the DN instead of the username.
> Is it possible to do a univention-ad-search at this state? > How to get this DN? This is how I determined it in Michels case: ldapsearch -x -h somedc.ad.dom \ -D thatadmin@AD.DOM \ -y /etc/univention/connector/ad/bindpw \ -b 'DC=ad,DC=dom' \ samaccountname=thatadmin dn This trick of using the userPrincipalName (with simplebind!) I discovered by chance during the development phase of our AD Connection setup (aka "Membermode"). It seems to be specific to AD but it's really useful to determine a bind dn. On the other hand, one could argue that this implies that we could probably simply set connector/ad/ldap/binddn=thatadmin@AD.DOM
Added get_ad_binddn_from_name to univention.management.console.modules.adconnector. Here, ldbsearch with username and password is used to get the dn of the "username" object. Default is still cn={username},cn=users,{LDAP_Base} but if get_ad_binddn_from_name finds something, this DN is used. univention-ad-connector.yaml errata 4.1-4 merged to 4.2-0 But, we have to wait for Bug #43070
This change is pretty much useless until we decide to fix Bug #42545. If we don't want to fix Bug #42545, we should only allow Administrator as connector user (as this account is always member of Domain Admins).
(In reply to Felix Botner from comment #7) > This change is pretty much useless until we decide to fix Bug #42545. No, I wouldn't say this. With this bug the the AD-Connector do not even start syncing if the user is not in the users container. Bug #42545 is about a fragile "guess_ad_domain_language". In this case a consequential error. Nevertheless I would like to vote to fix both bugs ;-)
(In reply to Michel Smidt from comment #8) > (In reply to Felix Botner from comment #7) > > This change is pretty much useless until we decide to fix Bug #42545. > > No, I wouldn't say this. With this bug the the AD-Connector do not even > start syncing if the user is not in the users container. > Bug #42545 is about a fragile "guess_ad_domain_language". In this case a > consequential error. > Nevertheless I would like to vote to fix both bugs ;-) No, unless Bug #42545 is fixed the binddn user (if not already member of Domain Admins in UCS) is removed from Domain Admins in AD. After that the connector sync is broken (as the user has no longer the rights to create/modify objects in AD).
(In reply to Felix Botner from comment #9) > (In reply to Michel Smidt from comment #8) > > (In reply to Felix Botner from comment #7) > > > This change is pretty much useless until we decide to fix Bug #42545. > > > > No, I wouldn't say this. With this bug the the AD-Connector do not even > > start syncing if the user is not in the users container. > > Bug #42545 is about a fragile "guess_ad_domain_language". In this case a > > consequential error. > > Nevertheless I would like to vote to fix both bugs ;-) > > No, unless Bug #42545 is fixed the binddn user (if not already member of > Domain Admins in UCS) is removed from Domain Admins in AD. After that the > connector sync is broken (as the user has no longer the rights to > create/modify objects in AD). sorry, it is Bug #43070
(In reply to Felix Botner from comment #10) > (In reply to Felix Botner from comment #9) > > (In reply to Michel Smidt from comment #8) > > > (In reply to Felix Botner from comment #7) > > > > This change is pretty much useless until we decide to fix Bug #42545. > > > > > > No, I wouldn't say this. With this bug the the AD-Connector do not even > > > start syncing if the user is not in the users container. > > > Bug #42545 is about a fragile "guess_ad_domain_language". In this case a > > > consequential error. > > > Nevertheless I would like to vote to fix both bugs ;-) > > > > No, unless Bug #42545 is fixed the binddn user (if not already member of > > Domain Admins in UCS) is removed from Domain Admins in AD. After that the > > connector sync is broken (as the user has no longer the rights to > > create/modify objects in AD). > > sorry, it is Bug #43070 Well, then I am with you.
(In reply to Felix Botner from comment #6) > Added get_ad_binddn_from_name to > univention.management.console.modules.adconnector. Here, ldbsearch with > username and password is used to get the dn of the "username" object. > > Default is still cn={username},cn=users,{LDAP_Base} but if > get_ad_binddn_from_name finds something, this DN is used. > > univention-ad-connector.yaml errata 4.1-4 > > merged to 4.2-0 > > But, we have to wait for Bug #43070 done, tested with -> ucr get connector/ad/ldap/binddn CN=myadm,CN=groups,DC=w2k12,DC=test
Code review: OK Merge to UCS 4.2: OK Tests: OK Jenkins tests: OK YAML: OK (r75142)
<http://errata.software-univention.de/ucs/4.1/359.html>