Univention Bugzilla – Bug 22866
Update von Samba 3 auf Samba 4
Last modified: 2011-12-13 15:51:00 CET
Es muss eine Beschreibung geben, wie UCS Domänen von Samba 3 nach Samba 4 migriert werden können.
Hier könnte hilfreich sein, wenn Samba4 Unterstützung für http://support.microsoft.com/kb/298713/en-us bieten würde, damit die Windows-Clients vom Samba4-Server angewiesen werden können, auch weiterhin mit NT4 DCs zu reden (quasi mixed-mode für Samba4).
Am Montag 29 August 2011 schrieb Arvid Requate: > Es gibt da ein Control, mit dem man die SID beim Anlegen vorgeben kann. > S4 schlägt vor zur Migration von Samba3-Benutzern das Tool > myldap-pub.py als Grundlage zu nehmen. Verfahren: > > 1. myldap-pub.py erzeugt auf Samba3/OpenLDAP Ldif ein Samba4 Ldif > > 2. Man ruft Samba4 provision auf > > 3. Man importiert per Skript das im ersten Schritt erzeugte LDIF > > 4. Man startet Samba4 > > Im laufenden Betrieb sei das sonst gefährlich, weil man SIDs nicht > doppelt vergeben darf.
Es soll eine Migration von UCS 3.0 / Samba 3 auf UCS 3.0 Samba 4 möglich sein. Hierzu wird ein Upgrade Dokument und vermutlich einige Hilfsskripte veröffentlicht. Eine 1:1 Inplace Migration wäre wünschenswert, aber es ist derzeit fraglich, ob das ohne weiteres möglich ist und ob wir dafür ein Out-of-the-Box Skript bereitstellen können.
Es sollte darauf hingewiesen werden, dass die Netlogon-Skripte unter /var/lib/samba/netlogon nicht mehr verwendet werden. Der neue Pfad ist /var/lib/samba/sysvol/$domainname/scripts
*** Bug 24041 has been marked as a duplicate of this bug. ***
Für eine Inplace Migration scheint statt myldap-pub.py aktuell laut http://thread.gmane.org/gmane.network.samba.internals/56330 eher das Kommando samba-tool domain samba3upgrade der bevorzugte Weg zu sein. Dabei wird der Code aus source4/scripting/python/samba/upgrade.py verwendet.
Wie besprochen, bitte die ersten beiden Szenarien durch testen.
Test des "Update Szenario 1: Aufbau einer neuen Windows Domäne" mit neu generierter DomainSID ergab: 1. Blocker Bug 24225 - Idmapping auf dem Backup-Samba4DC 2. Bug 24222 - Administrator Passwort abgelaufen 3. Wenn das Idmapping auf dem Backup-Samba4DC manuell gefixt ist, funktioniert der Fileserverzugriff auf die Samba4 und auf die Samba3 Domäne. Auf Samba3-Memberservern muss "map untrusted to domain" gesetzt werden für transparente Authentifizierung. 4. Samba4 provision scheint nicht gut damit klar zu kommen, wenn in der Ursprungsdomäne kerberos/realm != domainname ist. In der secrets.ldb finden sich Einträge wie: ----------------------------------------------- servicePrincipalName: DNS/univention.qa servicePrincipalName: DNS/backup35.univention.qa saltPrincipal: host/backup35.univention.qa@UNIVENTION.QA servicePrincipalName: HOST/backup35 servicePrincipalName: HOST/backup35.univention.qa servicePrincipalName: host/backup35.s3upi1.qa servicePrincipalName: ldap/backup35.s3upi1.qa ----------------------------------------------- Der korrekte Principal wäre host/backup35.s3upi1.qa@UNIVENTION.QA Entsprechend meldet samba_dnsupdate z.B. in log.samba RuntimeError: kinit for BACKUP35$@UNIVENTION.QA failed (Cannot contact any KDC for requested realm) 5. Das Login dauert häufig sehr lange in der Phase "Laden der Benutzereinstellung". Im Samba log stehen alle 7-9 Sekunden Meldungen der Art: [2011/10/27 11:43:56, 2] ../source4/nbt_server/dgram/netlogon.c:172(nbtd_mailslot_netlogon_handler) netlogon request to UCS3S4UP1<1c> from 10.200.8.235:138 Das kann aber auch ein Artefakt von Kerberos-Problemen in der Domäne sein.
Der aktuelle Stand der Update-Dokumentation ist jetzt online im Wiki unter http://wiki.univention.de/index.php?title=UCS_3.0_Samba_4
Im S4 Joinskript war jetzt eine Prüfung, ob das Windows Domänenobjekt bereits exitiert und wenn ja, dann ist es davon ausgegangen, dass bereits ein S3 DC installiert ist. Das Windows Domänenobjekt wird aber bereits im base.ldif angelegt, von daher ist es immer da. Es werden jetzt die S3 Service Einträge geprüft.
(In reply to comment #9) > Der aktuelle Stand der Update-Dokumentation ist jetzt online im Wiki unter > http://wiki.univention.de/index.php?title=UCS_3.0_Samba_4 Ein paar Dinge, die mir zum ersten Szenario aufgefallen sind: - Unter "Installation of the first Samba4 DC" ist beschrieben, dass man entweder S4 nicht auswählen sollte oder aber aber nicht joinen soll. Später wird aber nur der Fall betrachtet, dass das S4 Paket nicht ausgewählt wurde. Den letzteren Weg finde ich persönlich besser, da das Joinen gerade in grossen Umgebungen sehr lange dauern kann. - Müssen Dienste auf den DCs nach dem Setzen der Variablen neu gestartet werden? Vermutlich mindestens der Listener. Für das Nachstellen von Bug #2422 habe ich noch ein paar weitere Anpassungen an den Join- und Setup Skripten gemacht.
Der File Zugriff funktioniert, wenn ich mit einem Windows 7 Client aus der S4 Domäne auf ein Share in der S3 Domäne zugreifen. Allerdings nicht auf einem Memberserver, der in der S3 Domäne gejoint ist. Ich habe die local.conf um map untrusted to domain erweitert: ~# cat /etc/samba/local.conf [global] map untrusted to domain = yes
(In reply to comment #12) > Der File Zugriff funktioniert, wenn ich mit einem Windows 7 Client aus der S4 > Domäne auf ein Share in der S3 Domäne zugreifen. Allerdings nicht auf einem > Memberserver, der in der S3 Domäne gejoint ist. > > Ich habe die local.conf um map untrusted to domain erweitert: > > ~# cat /etc/samba/local.conf > [global] > map untrusted to domain = yes Das funktioniert, wenn ich ucr set samba/memberserver/passdb/ldap=yes auf dem Memberserver ausführe.
Setzt man die Gruppenrichtlinie "Network security: LAN Manager authentication level" auf "Send LM & NTLM responses", dann scheint der Zugriff auch auf S3-Domain-Memberserver mit mit samba/memberserver/passdb/ldap=no zu funktionieren: http://technet.microsoft.com/en-us/library/cc738867%28WS.10%29.aspx siehe auch http://lists.samba.org/archive/samba/2010-October/159082.html Analoges gilt für Samba4-Clients, z.B. smbclient3, wo man den gleichen Fehler beobachtet. Hier half es "client ntlmv2 auth = no" zu setzen, siehe http://samba.org/samba/history/samba-3.6.0.html. Unschön ist, dass dies beides Clientseitige Einstellungen sind.
Auch das Szenario 2 ist jetzt auf der Wikiseite beschrieben. Die Empfehlungen aus Comment 11 wurden umgesetzt.
Das inplace samba3update (Szenario 2) funktionierte jetzt auch. Eine Besonderheiten dabei ist: * Bestehende idmap Objekte im OpenLDAP (aus Vertrauensstellungen) übernimmt das samba3upgrade tool nicht. Nach Beheben von Bug 24483 ist dann auch direkt nach Installation/Joinscript von univention-samba4 der smbd erreichbar z.B. per smbclient3 -L localhost -UAdministrator%$(< /etc/samba4.secret) Nach Installation von univention-s4-connector ist das Administratorpasswort dann das gleiche wie im OpenLDAP.
Created attachment 3863 [details] log.samba.bz2
Created attachment 3864 [details] log.smbd.bz2
(In reply to comment #17) > Created an attachment (id=3863) [details] > log.samba.bz2 (In reply to comment #18) > Created an attachment (id=3864) [details] > log.smbd.bz2 Die Logs gehören an Bug #22865.
Ein paar Anmerkungen: * Es sollte noch deutlicher beschrieben werden, dass beim ersten Szenario eine neue Domäne aufgebaut wird und man damit die Möglichkeit hat, schrittweise zu migrieren. Vielleicht am Anfang eine kurze Übersicht, was bei den zwei Szenarien das Ziel ist. * Teilweise ist die Wiki Aufzählung auffällig: http://wiki.univention.de/index.php?title=UCS_3.0_Samba_4#Stepwise_Migration_of_Windows_Clients_to_the_Samba4.2FAD_domain Vor "Alternatively the behavior of the UCS Memberserver can" stehen drei *, besser direkt <pre> anstatt "\n " verwenden. * Die Wiki Seite sollte eigenständig werden. * http://wiki.univention.de/index.php?title=UCS_3.0_Samba_4#Stepwise_Migration_of_UCS_Memberservers_to_the_Samba4.2FAD_domain Dort steht, dass auf den Memberservern S4 installiert werden soll. * http://wiki.univention.de/index.php?title=UCS_3.0_Samba_4#Stepwise_Migration_of_the_UCS_Servers_to_the_Samba4.2FAD_domain Dort steht auch, dass optional auf den Memberservern S4 installiert werden soll. * Funktionale Tests stehen noch aus.
Die Verbesserungsvorschläge sind jetzt umgesetzt.
Beim Szenario 2 kommt diese Meldung: Could not add group name=Authenticated Users ((21, 'Element description has empty attribute in ldb message (CN=Authenticated Users,CN=Groups,DC=deadlock30,DC=local)!')) Could not add group name=World Authority ((21, 'Element description has empty attribute in ldb message (CN=World Authority,CN=Groups,DC=deadlock30,DC=local)!')) ERROR(<type 'exceptions.KeyError'>): uncaught exception - 'No such element' File "/usr/lib/python2.6/dist-packages/samba/netcmd/__init__.py", line 135, in _run return self.run(*args, **kwargs) File "/usr/lib/python2.6/dist-packages/samba/netcmd/domain.py", line 630, in run useeadb=eadb) File "/usr/lib/python2.6/dist-packages/samba/upgrade.py", line 671, in upgrade_from_samba3 add_group_from_mapping_entry(result.samdb, g, logger) File "/usr/lib/python2.6/dist-packages/samba/upgrade.py", line 190, in add_group_from_mapping_entry str(groupmap.sid), groupmap.nt_name, msg[0]['sAMAccountName'][0]) Ich denke der Traceback sollte noch abgefangen werden, da bei der Migration verwirren wird.
Das Samba4 Modul upgrade.py ist jetzt entsprechend gepatched.
Beide Szenarien wurden mehrfach erfolgreich durchgetestet, dabei wurde die Anleitung noch etwas ergänzt.
UCS 3.0-0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"