Moin,
Definitiv, das hätte ich auch selber noch vorgeschlagen, wollte aber zumindest vorher versuchen, dem Problem etwas auf die Spur zu kommen — auch weil Sie geschrieben hatten, dass Sie schon mehrere Dienste umgezogen hatten.
Sowohl als auch.
Unter Univention leben zwei LDAP-Verzeichnisse gleichzeitig: das OpenLDAP auf Port 7389 und das von Samba 4 gestellte LDAP auf Port 389 (ersteres immer, letzteres nur dann, wenn Samba 4 auch installiert ist). Es gibt eine Zwei-Wege-Synchronisation der Inhalte, die durch den bereits erwähnten Dienst S4-Connector (Prozess univention-s4connector) implementiert wird. Wenn ein Objekt im Samba-4-LDAP geändert wird, so wird diese Änderung nach wenigen Sekunden auch ins OpenLDAP repliziert und umgekehrt.
Dabei werden u.a. auch die Passwörter repliziert, sowohl von Benutzer- als auch von Rechnerkonten, sodass immer dasselbe Passwort benutzt wird, egal, ob sich der Benutzer nun an einem Windows-Arbeitsplatz (also Kerberos-Authentifizierung vom Windows-Client über das Samba 4 mit dem Samba-4-LDAP-Inhalt) oder z.B. am installierten Owncloud (Authentifizierung gegenüber dem OpenLDAP) anmeldet.
Die Verwaltungssoftware auf einem UCS DC Master nutzt wiederum das Rechnerkonto des DC Masters, um sich am OpenLDAP anzumelden und dort die Änderungen vorzunehmen. Ist auch Samba 4 installiert, so werden die Änderungen wie erwähnt durch den S4-Connector zum Samba-4-LDAP repliziert.
Ich vermute, dass bei Ihnen letztlich grob Folgendes passiert ist:
- Wie erwähnt, exisitert im UCS-OpenLDAP immer ein Computerkonto für den UCS-DC-Master. Das dazugehörige Passwort steht in
/etc/machine.secret.
- Es existiert im alten Nicht-UCS-Samba-4-AD bei Ihnen ein Computerkonto für den UCS-DC-Master. Dieses Computerkonto hat ein anderes Passwort als das, das auf dem UCS-DC-Master in
machine.secret steht.
- Beim AD-Takeover wird auf dem UCS Samba 4 installiert, und alle Computer- und Benutzerkonten werden vom Nicht-UCS-Samba-4 ins UCS-Samba-4 synchronisiert. Dabei kommt das falsche Rechnerpasswort vom Nicht-UCS-Samba-4 in den UCS-Samba-4.
- Nun wird auf dem UCS-DC-Master aber auch der S4-Connector aktiv und repliziert das gerade kopierte Computerkonto des DC Master vom UCS-Samba-4 ins UCS-OpenLDAP. Dabei wird das falsche Passwort nun auch ins OpenLDAP repliziert.
- Dass das Passwort auf diese Weise von außen hereinkommt, ist beim AD-Takeover-Prozess nicht vorgesehen, und daher bekommt UCS diese Änderung nicht wirklich mit und belässt
machine.secret auf dem alten Wert.
- Von da an kann sich die Verwaltungssoftware nicht mehr mit dem Rechnerkonto und dem Passwort aus
machine.secret anmelden.
Dass das Problem bei Ihnen immer wieder auftritt, sobald Sie Samba 4 & den S4-Connector installieren, liegt vermutlich daran, dass beim Entfernen von Samba 4 der Inhalt des Samba-4-LDAPs nicht mit gelöscht wird. Nach erneuter Installation der Pakete sieht der S4-Connector somit wieder den (falschen) Inhalt vom Samba-4-LDAP und repliziert wieder fleißig in Richtung UCS.
Man könnte nun versuchen, Samba 4 zu deinstallieren, den alten Inhalt komplett zu löschen (primär /var/lib/samba/private), und zu hoffen, dass bei erneuter Installation das besser wird.
Die sauberste Variante ist aber wirklich, den UCS einmal komplett neu aufzusetzen.
Beim AD Takeover sollten Sie aufgrund der Beschreibung oben am besten aus dem alten Nicht-UCS-Samba-4 das Computerkonto des UCS DC Masters herauslöschen, bevor Sie den Takeover-Prozess erneut versuchen.
Huch? Nutzen Sie bereits UCS 4.2? Ich hab hier bisher nur 4.1-4er Testmaschinen, und es kann gut sein, dass sich da der Speicherort geändert hat.
Bei einer Neuinstallation von UCS sollten allerdings auch die Probleme mit doppelten Einträgen wieder verschwinden; insofern müssen wir das nicht zwangsläufig weiter untersuchen.
LG,
mosu
).