Univention Bugzilla – Bug 35346
UCS in Active Directory domain & AD Takeover
Last modified: 2014-08-07 17:49:01 CEST
It should be possible to take over the AD domain at a later point. +++ This bug was initially created as a clone of Bug #34091 +++ It should be possible to run UCS as part of an Active Directory domain. In this case UCS must not provide Kerberos, DNS or Samba domain controller functionality. The synchronization of users, groups and computers will be done through the UCS AD connector. A password synchronization is not necessary, we will add an overlay module for OpenLDAP which uses the AD Kerberos as password verification backend for simple LDAP bind. The UCS system should able to provide Samba shares. Synchronized objects should be marked as synced (objectsuniventionObjectFlag: synced). In the default read mode of the connector it should not be possible to modify the synchronized attributes. The UDM modules property extension should be extended, for example "readonly_when_synced: True", default is False. Furthermore the object creation via UMC should display a warning that this object will not synchronized to AD.
* In adtakeover state "start" a new method is called which detects and reverts AD Member mode settings and then runs 96univention-samba4.inst for the first time. That joinscript detects if adtakeover is in state "start" and disables slapd on port 389, saves VERSION=1 and quits without provisioning the Samba DS. * Before robocopy it was necessary to run samba-tool ntacl sysvolreset once, otherwise the ntacls didn't allow the Administrator to copy files (Without AD Member mode the univention-samba4 joinscript would have done this). * For convenience the nameserver1 is set to the local default IP before the robocopy phase. This avoids a long login delay in case the UMC timeout happenes during robocopy, which may occur once the AD-Server has been switched off. Advisory: 2014-07-30-univention-management-console-module-adtakeover.yaml
OK - ad takeover from member mode OK - normal ad takeover OK - YAML
If you run AD-Takeover in a domain configured in AD Member mode which has more than one UCS domaincontroller, then the AD-Takeover aborts with a message that smb.conf "server role=auto" is invalid. This is because samba4/role has not been set yet because 96univention-samba4.inst aborted: RUNNING 96univention-samba4.inst ERROR: It is not possible to install a samba 4 domaincontroller into a samba 3 environment. EXITCODE=1 So I guess we need to set samba4/ignore/mixsetup=yes in the adtakover module when coming from AD Member mode.
Fixed. Advisory: 2014-07-28-univention-management-console-module-adtakeover.yaml
please also abort the takeover if the univention-run-join-scripts in disable_admember_mode fails
Ok, coming from AD Member we now run the 96univention-samba4.inst joinscript selectively and check its return status. If it's no 0, the takeover.py restores the univentionService="AD Member" for the localhost, so the adtakeover may be run again later and take the same code path (exiting AD Member mode) as before. If this this initial step worked, then 97univention-s4-connector.inst is run to set some basic UCR variables. A general univention-run-join-scripts is avoided until the very end on the takeover. This is how it was before the AD Member changes. Advisory updated.
OK - samba4/ignore/mixsetup=yes OK - takeover detects if 96univention-samba4.inst fails OK - YAML
I just had a traceback while running "AD Takeover" from AD Member mode. Looks like the sqlite table is not yet there after the first start of the S4 Connector. Looks like a timing issue: ========================================================================== 2014-08-06 17:18:38,199 Starting S4 Connector 2014-08-06 17:18:38,199 Calling: /etc/init.d/univention-s4-connector start 2014-08-06 17:18:38,258 Starting univention-s4-connector daemon. 2014-08-06 17:18:41,636 done. 2014-08-06 17:18:41,637 Waiting for S4 Connector sync 06.08.14 17:18:42.832 MODULE ( PROCESS ) : Die Ausführung des Kommandos copy_domain_data ist fehlgeschlagen: Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/univention/management/console/modules/adtakeover/__init__.py", line 60, in _background result = func(self, request) File "/usr/lib/pymodules/python2.6/univention/management/console/modules/adtakeover/__init__.py", line 107, in copy_domain_data takeover.join_to_domain_and_copy_domain_data(ip, username, password, self.progress) File "/usr/lib/pymodules/python2.6/univention/management/console/modules/adtakeover/takeover.py", line 299, in join_to_domain_and_copy_domain_data takeover.start_s4_connector(progress) File "/usr/lib/pymodules/python2.6/univention/management/console/modules/adtakeover/takeover.py", line 1328, in start_s4_connector wait_for_s4_connector_replication(self.ucr, self.lp, progress) File "/usr/lib/pymodules/python2.6/univention/management/console/modules/adtakeover/takeover.py", line 2047, in wait_for_s4_connector_replication c.execute('select value from S4 where key=="lastUSN"') OperationalError: no such table: S4 ==========================================================================
The sqlite3 exception now get's catched and a log message is produced. The wait_for_s4_connector_replication loop continues as usual waiting lastUSN to converge to highestCommittedUSN. Advisory is updated.
OK, if i add a sleep in the s4 connector i get 2014-08-06 18:59:39,696 Waiting for S4 Connector sync 2014-08-06 18:59:40,885 no such table: S4 2014-08-06 18:59:42,057 no such table: S4 2014-08-06 18:59:43,235 no such table: S4 ... 2014-08-06 19:01:48,905 Calling: univention-config-registry set connector/s4/poll/sleep=5 connector/s4/retryrejected=10 2014-08-06 19:01:49,138 Setting connector/s4/poll/sleep 2014-08-06 19:01:49,139 Setting connector/s4/retryrejected 2014-08-06 19:01:49,148 Calling: /etc/init.d/univention-s4-connector restart and the takeover works fine.
http://errata.univention.de/ucs/3.2/172.html