Univention Bugzilla – Bug 28390
Samba 4 in MS AD joinen für Migrationen
Last modified: 2012-12-12 21:10:10 CET
Es fehlt derzeit die Produktunterstützung für eine Migration von AD nach Samba 4 über Samba 4. Dazu könnte eine Wiki Anleitung erstellt werden, die folgendes beschreibt: - Warnung, dass das nicht gegen produktive AD Systeme gemacht wird. Nach Möglichkeit wird ein MS AD System geklont und die Migration wird gegen dieses AD System durchgeführt - Installation eines UCS DC Master - Join des UCS DC Master in die AD Domäne - DRS Replikation abwarten - Sysvol Share replizieren - Alle AD DCs abschalten - Samba 4 in der Domäne aktivieren Ziel ist es ähnlich wie beim NT pdc-takeover, dass die Windows Clients nicht neu joinen müssen.
Prüfung zur 3.1
Created attachment 4706 [details] Aktuelle Version des Migrationsskripts. Das Skript führt ein Mapping von lokalisierten AD-Grupppennamen zu englischen UCS-Gruppennamen ein. Dafür ist eine angepasste Version des S4 Connectors notwendig. TODO: * DNS-Cleanup vor dem AD-Join * OU Synchronisation * Cleint Tests (Kerberos etc.)
Die aktuelle Skriptverion ist jetzt unter dem Namen univention-ad-takeover in das Paket univention-s4-connector eingebaut. Mit der aktuellen Version des Skripts funktionierte im Test mit einem einzelnen Windows Server 2003R2 folgende Schritte: * Installation des UCS-Masters mit neuen Namen aber gleicher Domäne. * Skript Ausführung Phase I * sysvol-Kopie vom AD-Server aus per robocopy von share zu share * Skript Ausführung --fsmo-takeover * Login am übernommenen Windows-7 Client mit übernommenem Benutzer * Anlegen eines neuen Benutzers unter UCS * Login am übernommenen Windows-7 Client mit neuem Benutzer * Login am übernommenen Windows-7 Client als Domänen-Administrator * Zugriff von Client aus per "AD Benutzer & Computer", Rechtsclick auf Domäne, "Domänencontroller ändern..", UCS-Server wird korrekt angezeigt. * Start der Gruppenrichtlinenverwaltung, übernommene GPOs sind vorhanden. * Neuer Join eines Clients, Login als Benutzer * Nach Reboot den Windows-Clients registriert sich dieser im DNS. Aktuell bekannte Einschränkungen: * Umbenennung eines Windows7-Clients (übernommen/neu gejoined) vom Client aus brincht mit Fehlermeldung ab. * IPv6-Unterstützung ist generell noch ungetestet. * Überprüfung des Abschaltung zusätzlicher AD-DCs ist nicht implementiert.
Umbenennung von Windows(7)-Clients von Client aus hat mit Samba4 RC2 funktioniert, vermutlich war das ein Problem von Alpha17.
Folgende generelle Ramenbedingungen sollten beachtet werden: * Das UCS-System und das AD-System müssen im gleichen IP-Subnetz sein. Das UCS-System ist am Ende des Takeovers zusätzlich auch unter dem Namen und der IP-Adresse des abgeschalteten AD-Servers erreichbar. (Siehe Bug 28955) * Es wird aktuell nur IPv4 unterstützt. * Das UCS-System muss mit der gleichen DNS-Domäne, Kerberos-Realm und LDAP-Basis installeirt werden, wie der AD-Server. Hostname und IP-Addresse müssen unterschiedlich zum AD-Server gewählt werden. * GPO-Bearbeitung und Schreibzugriff auf das SYSVOL-Verzeichnis sind vermutlich mit der Samba4-Version aus UCS 3.0-2 nur mit dem "Administrator" Konto möglich. GPO-Administration als Domain Admins ist im Moment ungetestet und wird daher erstmal nicht empfohlen. * Das letzte vor dem Takeover gesetzte Administrator-Passwort wird übernommen (Zeitstempel). Das das UCS-System in der Praxis vermutlich nach dem AD-System installiert wurde, wird von S4 Connector dann das Administrator- Passwort aus UCS als das aktuellste beibehalten. Falls der Admin hingegen nach der UCS-Installation in AD nochmal das Administrator-Passwort geändert hat, dann ist das das aktuellere und am Ende das gültige. * Alle vor dem Takeover im Samba4 getroffenen Einstellungen werden durch den Takeover gelöscht und durch die im AD-Server ersetzt. * Nach dem Takeover ist es notwendig, die Windows-Clients neu zu booten. Hintergrund ist, dass die Clients beim Neustart ein Update ihrer DNS-Daten an Samba4 schicken, das diese ggf. noch nicht hat (je nachdem wo die Daten im AD gespeichert waren). In den Tests zeigte sich, dass die GPO- Auswertung am Client (per gpupdate /force) Fehler im "Machine"-Teil meldete, wenn Samba4 die DNS-Daten für den Client noch nicht registriert hat.
Getestet per Bug 28521.
Drei Verbesserungen gegenüber der Version auf der c't DVD wurden noch in das Skript eingebaut: * Das Skript wartet jetzt auf interaktive Eingabe um nach der manuellen Kopie des Sysvol mit Phase III (FSMO-Takeover) weiterzumachen. Es prüft dann, ob der AD-Server noch per ping erreichbar ist und fragt so lange bis er netzwerktechnisch nicht mehr erreichbar ist. * Das Skript gibt die Kommandozeile für den robocopy-Aufruf aus. (Ggf. könnte es noch sagen, dass das Teil der "Resource Kit Tools" ist?) * Für das Konto des (der) DCs wird der Passwortablauf deaktiviert statt in den Samba4-Domänen-Passworteinstellungen max./min. Passwortalter und Passwort-History-Länge anzupassen. UCS 3.1 Changelog ist jetzt auch angepasst.
Weitere Anpassungen gegenüber der Version auf der c't DVD wurden noch in das Skript eingebaut: * Es wird jetzt so lange gewartet bis lastUSN des S4 Connectors == highestComittedUSN in Samba4 ist. Das Kriterium muss in 10 Versuchen hintereinander erfüllt sein ( = 5 * retryrejected). Es gibt dabei keinen Timeout mehr. * "samba-tool ntacl sysvolreset" wird jetzt verwendet.
Wie besprochen, wenn das AD System mehr als 1000 Benutzer hat tritt diese Meldung auf: root@master331:~# univention-ad-takeover 10.201.33.2 Pinging AD IP 10.201.33.2: . Ok, Server IP 10.201.33.2 is online. Password for [DEADLOCK33\Administrator]: Sucessfull determined AD DC FQDN w2k8r2-64.deadlock33.local for given IP 10.201.33.2 Located server w2k8r2-64.deadlock33.local at AD site Default-First-Site-Name in AD SAM database. The local clock differs from the clock on 10.201.33.2 by about 0 seconds. The offest is less than three minutes, that should be good enough for Kerberos. Traceback (most recent call last): File "/usr/sbin/univention-ad-takeover", line 1756, in <module> (ad_server_ip, ad_server_fqdn, ad_server_name) = run_phaseI(ucr, lp, opts, args) File "/usr/sbin/univention-ad-takeover", line 974, in run_phaseI if not check_ad_object_numbers(ucr, remote_samdb): File "/usr/sbin/univention-ad-takeover", line 435, in check_ad_object_numbers ad_user_accounts, ad_computer_accounts = count_ad_object_numbers(ucr, remote_samdb, _license.sysAccountNames) File "/usr/sbin/univention-ad-takeover", line 402, in count_ad_object_numbers attrs=["sAMAccountName", "objectSid"]) _ldb.LdbError: (4, 'LDAP error 4 LDAP_SIZE_LIMIT_EXCEEDED - <> <>')
Zwei Anpassungen waren notwendig: * AD-LDAP-Suche mit paged results control * V2 Lizenz-Support. Es werden jetzt nur noch Benutzerkonten geprüft.
> + - Output dots during initialization of S4 Connector Das funktioniert noch nicht. Ist lastUSN vielleicht ein String?
Ich habe eine FFPU Lizenz (v2), allerdings wird mir keine Meldung angezeigt, dass meine Lizenz nicht ausreicht: Found user 997 objects on the remote server.
(In reply to comment #11) > > + - Output dots during initialization of S4 Connector > > Das funktioniert noch nicht. Ist lastUSN vielleicht ein String? Auch zu einem späteren Zeitpunkt steht die Synchornisation, in meinem Fall bei 5869 / 7873. Besser einen Hinweis auf /var/log/univention/connector-s4-status.log geben und Punkte anzeigen, aber nur alle 10 Sekunden.
samba-tool fsmo seize ist noch nicht erfolgreich: 2012-11-14 13:54:56,899 trying samba-tool fsmo seize --role=schema --force again: 2012-11-14 13:54:56,899 Calling: samba-tool fsmo seize --role=schema --force 2012-11-14 13:54:57,261 ERROR(<type 'exceptions.TypeError'>): uncaught exception - argument 2 must be string, not ldb.Dn 2012-11-14 13:54:57,262 File "/usr/lib/python2.6/dist-packages/samba/netcmd/__init__.py", line 168, in _run 2012-11-14 13:54:57,262 return self.run(*args, **kwargs) 2012-11-14 13:54:57,262 File "/usr/lib/python2.6/dist-packages/samba/netcmd/fsmo.py", line 160, in run 2012-11-14 13:54:57,263 self.seize_role(role, samdb, force) 2012-11-14 13:54:57,263 File "/usr/lib/python2.6/dist-packages/samba/netcmd/fsmo.py", line 119, in seize_rol e 2012-11-14 13:54:57,263 m.dn = ldb.Dn(samdb, self.schema_dn) 2012-11-14 13:54:58,291 trying samba-tool fsmo seize --role=schema --force again: 2012-11-14 13:54:58,291 Calling: samba-tool fsmo seize --role=schema --force 2012-11-14 13:54:58,640 ERROR(<type 'exceptions.TypeError'>): uncaught exception - argument 2 must be string, not ldb.Dn 2012-11-14 13:54:58,641 File "/usr/lib/python2.6/dist-packages/samba/netcmd/__init__.py", line 168, in _run 2012-11-14 13:54:58,641 return self.run(*args, **kwargs) 2012-11-14 13:54:58,641 File "/usr/lib/python2.6/dist-packages/samba/netcmd/fsmo.py", line 160, in run 2012-11-14 13:54:58,641 self.seize_role(role, samdb, force) 2012-11-14 13:54:58,642 File "/usr/lib/python2.6/dist-packages/samba/netcmd/fsmo.py", line 119, in seize_rol e 2012-11-14 13:54:58,642 m.dn = ldb.Dn(samdb, self.schema_dn) 2012-11-14 13:54:58,670 Claiming FSMO role schema failed. Warning: Continuing anyway. Please fix later by running: samba-tool fsmo seize --role=schema --force ii samba4 4.0.0~rc2-1.341.201211141604
* Jetzt wird die richtige Stelle gepatched, upstream patch ist auch angepasst. * check_license ist jetzt gefixt. * Fortschrittsanzeige gibt jetzt ca alle 10 Sek. einen Punkt aus * Es wird auf connector-s4-status.log hingewiesen.
Mit den Anpassungen konnte ich jetzt folgende Punkte erfolgreich testen: - Übernahme einer Windows 2008 R2 Umgebung mit > 1000 Benutzern - Windows 7 Clients, die vorher in der Domäne waren - GPO Übernahme - Weiteren DC in der UCS Domäne - Weiteren DC in der AD Domäne - Mehr AD Benutzer als in der lokalen Lizenz - Diverse falsche Parameter usw. Changelog: OK Der Rest erfolgt über die Produkttests.
UCS 3.1-0 has been released: http://forum.univention.de/viewtopic.php?f=54&t=2125 If this error occurs again, please use "Clone This Bug".