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