Bug 35346 - UCS in Active Directory domain & AD Takeover
UCS in Active Directory domain & AD Takeover
Product: UCS
Classification: Unclassified
Component: General
UCS 3.2
Other Linux
: P5 enhancement (vote)
: UCS 3.2-2-errata
Assigned To: Arvid Requate
Felix Botner
Depends on:
Blocks: 34091 35501
  Show dependency treegraph
Reported: 2014-07-14 07:29 CEST by Stefan Gohmann
Modified: 2014-08-07 17:49 CEST (History)
1 user (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Gohmann univentionstaff 2014-07-14 07:29:17 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.
Comment 1 Arvid Requate univentionstaff 2014-07-30 15:54:29 CEST
* 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
Comment 2 Felix Botner univentionstaff 2014-08-01 13:14:10 CEST
OK - ad takeover from member mode
OK - normal ad takeover

Comment 3 Arvid Requate univentionstaff 2014-08-04 13:48:13 CEST
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.

So I guess we need to set samba4/ignore/mixsetup=yes in the adtakover module when coming from AD Member mode.
Comment 4 Arvid Requate univentionstaff 2014-08-04 14:07:52 CEST
Advisory: 2014-07-28-univention-management-console-module-adtakeover.yaml
Comment 5 Felix Botner univentionstaff 2014-08-04 14:27:00 CEST
please also abort the takeover if the univention-run-join-scripts in disable_admember_mode fails
Comment 6 Arvid Requate univentionstaff 2014-08-04 15:16:45 CEST
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.
Comment 7 Felix Botner univentionstaff 2014-08-04 18:19:38 CEST
OK - samba4/ignore/mixsetup=yes
OK - takeover detects if 96univention-samba4.inst fails

Comment 8 Arvid Requate univentionstaff 2014-08-06 17:21:47 CEST
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
  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
Comment 9 Arvid Requate univentionstaff 2014-08-06 17:59:43 CEST
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.
Comment 10 Felix Botner univentionstaff 2014-08-06 18:01:21 CEST
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.
Comment 11 Janek Walkenhorst univentionstaff 2014-08-07 17:49:01 CEST