Samba4 Migration - Home Verzeichnisse nicht mehr erreichbar

Nach dem Update von Samba3 zu Samba4 können die bestehenden Nutzer nicht mehr auf \server<Nutzername> zugreifen. Soweit ich das gesehen habe wurde beim Import die SID der Nutzer geändert (warum?) aber nicht auf den bestehenden Freigaben.
Wenn ich einen neuen Nutzer nach der Migration anlege kann er auf \server\ zugreifen.
Ich hab schon diverse Log Dateien durchgesehen (listener, connecter-s4, actualise etc.) merkwürdiges entdeckt aber nichts was darauf hinschließen lässt und auf forge.univention.org sowie hier gesucht aber keine Lösung gefunden.
Basis ist ein Testsystem mit UCS 3.2-6 samba3 Domäne (allerdings im Laufe der Zeit aktualisiert von Version 1. irgendwas) . Dann Inplace Update durchgeführt.

Mit stellt sich die Frage warum die SIDs der Nutzer geändert wurden (nur die Teile nach dem letzten Bindestrich) und warum das dann nicht auf den Freigaben etc. angewandet wurde. Gerne stelle ich Logdateien zur Verfügung (welche?).

Hallo,

die RID sollte sich bei der Migration natürlich nicht ändern.
Relevant sind mind. die /var/log/univention/actualise.log, die /var/log/univention/join.log sowie die Ausgabe von “/usr/share/univention-s4-connector/univention-s4-position-sync --dry-run”.
Außerdem am besten noch ein beispielhaftes Benutzerobjekt aus LDAP und AD:univention-ldapsearch -xLLL uid=<benutzer> univention-s4search cn=<benutzer>

Mit freundlichen Grüßen
Janis Meybohm

Anbei die gewünschten Logdateien. Es wurden ein paar Gruppen entfernt, der User “unkenntlich” gemacht und die Password Hashes entfernt. Der Dry Run hat gemeckert das die Gruppe Backup Join in backup join umbenannt werden muss (oder anders rum).

Beim der Administrator ID wurde meiner Erinnerung nach wärend des S4 Syncens die ID geändert.
ldapuser.log (936 Bytes)
s4user.log (1.13 KB)
join.log (8.09 KB)
actualise.log (70.3 KB)

Hallo,

die SID des Benutzers ist doch aber identisch:grep S-1-5-21-2858171826-3451874355-3283966560-11353 * ldapuser.log:sambaSID: S-1-5-21-2858171826-3451874355-3283966560-11353 s4user.log:objectSid: S-1-5-21-2858171826-3451874355-3283966560-11353

Die RID des Administrator wurde geändert da er nicht “der” Administrator war

[quote=“actualise.log”]ImUser 'Administrator' in your existing directory has SID S-1-5-21-2858171826-3451874355-3283966560-5012, expected it to be S-1-5-21-2858171826-3451874355-3283966560-500 ERROR(<class 'samba.provision.ProvisioningError'>): uncaught exception - ProvisioningError: User 'Administrator' in your existing directory does not have SID ending in -500 File "/usr/lib/python2.6/dist-packages/samba/netcmd/__init__.py", line 175, in _run return self.run(*args, **kwargs) File "/usr/lib/python2.6/dist-packages/samba/netcmd/domain.py", line 1399, in run useeadb=eadb, dns_backend=dns_backend, use_ntvfs=use_ntvfs, no_upn=no_upn) File "/usr/lib/python2.6/dist-packages/samba/upgrade.py", line 982, in upgrade_from_samba3 raise ProvisioningError("User 'Administrator' in your existing directory does not have SID ending in -500") [/quote]

Mit freundlichen Grüßen
Janis Meybohm

Das ist richtig das sie jetzt identisch ist, jedoch hat das idmapping das geändert.

Anbei die Datei und hier die entsprechende Zeile.

09.06.15 10:53:01.853  LISTENER    ( PROCESS ) : samba4-idmap: renaming entry for S-1-5-21-2858171826-3451874355-3283966560-5868 to S-1-5-21-2858171826-3451874355-3283966560-11353

Dadurch das alle bestehenden Accounts geändert wurden, kann kein bestehender Account mehr auf sein/ihr Home Laufwerk zugreifen, nur neu angelegte User. Gibt es dafür Abhilfe? Wird so was durch den jährlichen Maintenance Betrag für den Server abgedeckt?

Mit freundlichen Grüßen
Martin
listener.log (76.1 KB)

Hallo,

ich hatte Sie eingangs vermutlich nicht richtig verstanden, mir war daher nicht klar dass die SIDs/RIDs im LDAP und AD konsistent sind.

Wie gesagt wird das “normalerweise” natürlich nicht gemacht und wir unterstützen Sie gerne dabei das zu korrigieren!

Auffällig finde ich dass die SIDs initial korrekt in die idmap geschrieben, knapp eine Stunde später dann aber geändert werden:listener.log:09.06.15 10:01:31.376 LISTENER ( PROCESS ) : samba4-idmap: added entry for S-1-5-21-2858171826-3451874355-3283966560-5868 listener.log:09.06.15 10:53:01.853 LISTENER ( PROCESS ) : samba4-idmap: renaming entry for S-1-5-21-2858171826-3451874355-3283966560-5868 to S-1-5-21-2858171826-3451874355-3283966560-11353
Evtl. ist der Import der Benutzer bei der Provisionierung abgebrochen (Traceback bzgl. des Administrator Kontos mit falscher RID) und die Benutzer wurden dann (nach der Provisionierung) durch den S4-Connector in das AD übertragen. Das hätte dann neue RIDs zur folge da AD für neue Benutzer die RIDs vergibt. Bitte prüfen Sie einmal die /var/log/univention/connector-s4.log von dem Zeitraum bzw. hängen Sie diese an. Wenn ich mit meiner Vermutung richtig liege müssten man dort sehen können dass alle Benutzer “angelegt” werden.

Wenn Sie die Möglichkeit haben die Migration zu wiederholen, würde ich die RID des Administrator vorab korrigieren und prüfen ob die Benutzer dann korrekt übertrage werden.
Wenn das keine Option ist, haben Sie denke ich noch zwei weitere Möglichkeiten:

[ul][li]Den S4-Connector stoppen, alle RIDs im LDAP korrigieren und das AD reprovisionieren (sdb.univention.de/1282)[/li]
[li]Die RIDs für alle Benutzer direkt im AD ändern, der S4-Connector sollte dass dann wieder zurück in das LDAP schreiben. Z.B.:

ldbedit -H /var/lib/samba/private/sam.ldb "objectSid=S-1-5-21-2858171826-3451874355-3283966560-11353" objectSid --controls=local_oid:1.3.6.1.4.1.7165.4.3.16:0

Alle Optionen sollten Sie auf jeden Fall vorab in einer Testumgebung gründlich prüfen.

Mit freundlichen Grüßen
Janis Meybohm

Das Ändern der RID auf 500 hat geholfen. Nach erstem Augenschein läuft jetzt alles mit dem neuen Samba4 Migrationsversuch. In der alten connector-log Datei sind für den Benutzer 4 Einträge vorhanden. Einmal ein add from ucs, dann ein modify from ucs, dann ein modify to ucs und dann nochmal ein modify from ucs.

Ich weiß ja nicht wie viele Leute noch das Samba4 Update machen aber das könnte man ja als Verbesserung mit auf den Weg bringen, die RID des Administrators vor der Migration im Zweifelsfall auf 500 zu setzen (das geht sonst über die Benutzerverwaltung -> Konto -> Relative ID). Hier wiki.univention.de/index.php?tit … to_Samba_4.

Der Thread kann auf erledigt/gelöst gesetzt werden. Vielen Dank für die Hilfe.

Hallo und vielen Dank für die Rückmeldung!

Ich habe die Erkenntnisse aus diesem Fall natürlich an die entsprechenden Stellen weiter geleitet damit die Situation im Produkt und der Dokumentation verbessert werden kann.

Mit freundlichen Grüßen
Janis Meybohm

Mastodon