Univention Bugzilla – Bug 42964
admember.py has problems if the server-domain is different from the ad domain
Last modified: 2019-01-03 07:22:40 CET
admember.py seems to work with: "dig $nameserver $(ucr get domainname) +short" - that returns the expected ip-address of the ad-dc if it is responsible for the DNS-Zone that matches with $(ucr get domainname). Customer Environment: AD/Samba-Domain: bla.foo.bar Serverdomain: cat.foo.bar A server-password-change is not possible with this setting. Maybe admember.py can work with Service-Records to determine the AD DC?
*** Bug 42963 has been marked as a duplicate of this bug. ***
According to the Ticket, this is about "Active Directory Takeover", so I'm re-categorizing this Bug as such. Quoting http://docs.software-univention.de/manual.html#windows:adtakeover : "The UCS domain controller needs to be installed with the same DNS domain name, NetBIOS (pre Windows 2000) domain name and Kerberos realm as the AD domain. It is also recommended to configure the same LDAP base DN."
(In reply to Arvid Requate from comment #2) > According to the Ticket, this is about "Active Directory Takeover", so I'm > re-categorizing this Bug as such. Full ack. But unfortunately the wrong ticket was linked. I changed it accordingly.
Quoting http://docs.software-univention.de/manual.html#ad-connector:ad-member-einrichtung : "The name of the DNS domain of the UCS systems must match that of the AD domain. The host name must of course be different." This requirement has been defined to cover these two points: * UCS systems configured for ad/member=yes install univention-samba by default to create a machine account in AD. * The Kerberos realm of the UCS system needs to match the one of AD. Changing this into a feature request. We need to define the desired alternative scenario, check the technical possibilities and identify necessary changes for App Wizard and Installer GUI.
Ok, after discussing this in detail I understand now what the problem is. In the customer scenario the AD member setup is working fine for most systems, which all have the same DNS domain name as the AD-DCs. But there is *one* UCS system that is configured with a different DNS domain and this system now has a problem during server password change: ============================================================================= Starting server password change (Wed Nov 9 01:05:56 CET 2016) Proceeding with regular server password change scheduled for today run-parts: executing /usr/lib/univention-server/server_password_change.d/50univention-mail-server prechange Create mail/postfix/stoppedbyserverpasswordchange Stopping Postfix Mail Transport Agent: postfix. run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-libnss-ldap prechange run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-nscd prechange run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-samba prechange Traceback (most recent call last): File "/usr/lib/univention-server/server_password_change.d/univention-samba", line 199, in <module> rc = run_prechange() File "/usr/lib/univention-server/server_password_change.d/univention-samba", line 164, in run_prechange info = univention.lib.admember.lookup_adds_dc() File "/usr/lib/pymodules/python2.7/univention/lib/admember.py", line 658, in lookup_adds_dc raise failedADConnect(["Connection to AD Server %s failed" % (ad_server)]) univention.lib.admember.failedADConnect: ['Connection to AD Server cat.foo.bar failed'] run-parts: /usr/lib/univention-server/server_password_change.d/univention-samba exited with return code 1 ============================================================================= So, the basic thing to check here, is if server password change can technically work in this scenario. Since kerberos/realm and windows/domain match the AD-Domain it could work. Maybe we can make server password change (or admember.py) smarter and reduce the requirements with respect to DNS.
Are there any new results available?
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018. Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.