Kein login nach ad-takover mehr möglich

german
ad-takeover
ucs-4-2

#1

Hallo,

bin etwas am verzweifeln mit meiner neuen UCS/Samba4-Domäne. Nach dem ich jetzt über mehrere Wochen einen neuen UCS als Member in meiner bestehenden Samba4-AD-Domäne betrieben habe, und langsam alle Dienste migriert hatte, habe ich mich gestern an das “ad-takeover” gewagt, um den alten DC nun endgültig abzulösen. Der takeover-Prozess lief auch ohne Probleme durch, allerdings besteht nun keine Möglichkeit mehr, ich mit einem meiner User einzuloggen. Als “Administrator” weder auf einem der Clients noch im UMC. An den Clients funktioniert nur noch der Login aufgrund von cached logins.

journalctl ist voll mit diesen Fehlermeldungen:

Apr 09 15:48:33 ucs-studio smbd[14140]: nss_ldap: failed to bind to LDAP server ldap://ucs-studio.ad.b3-wohnen.at:7389: Invalid credentials
Apr 09 15:48:33 ucs-studio smbd[14140]: nss_ldap: reconnecting to LDAP server...
Apr 09 15:48:33 ucs-studio smbd[14140]: nss_ldap: failed to bind to LDAP server ldap://ucs-studio.ad.b3-wohnen.at:7389: Invalid credentials
Apr 09 15:48:33 ucs-studio smbd[14140]: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)...
Apr 09 15:48:34 ucs-studio smbd[14140]: nss_ldap: failed to bind to LDAP server ldap://ucs-studio.ad.b3-wohnen.at:7389: Invalid credentials
Apr 09 15:48:34 ucs-studio smbd[14140]: nss_ldap: could not search LDAP server - Server is unavailable

Für mich sieht das fast so aus, als wären beim takeover alle Passwörter zurückgesetzt worden.
Was kann ich jetzt tun?
Gibt es irgendeine Möglichkeit die Passwörter vom alten samba4-DC einzuspielen? Oder auch den takeover rückgängig zu machen und den UCS wie gehabt wieder in den “Member-Status” zurückzusetzen?

Hoffe ihr habt hier ein paar Vorschläge für mich!
Danke, Hans


#2

Also das die samba4-AD-Domäne konnte ich soweit wieder herstellen. Das AD habe ich zur Sicherheit aus einem samba_backup des samba4 AD Domaincontroller zurückgespielt, das LDAP-Verzeichnis des UCS habe ich in etwa nach dieser Anleitung wiederhergestellt (hat allerdings erst funktioniert, als ich mittels univention-app remove adtakeover die entsprechende App wieder deinstalliert habe. Sonst hat er immer wieder nach einiger Zeit den Zugriff verweigert).

Damit ist ein login mit dem “Administrator” in der UMC wieder möglich, allerdings funktioniert diese nicht richtig. Die Übersicht (“Portal”) zeigt alle Elemente mehrmals an:

Die Seite https://ip-to-ucs/univention/management/ bleibt beim Login als “Administrator” vollkommen leer. Beim Login als “root” scheint die “Management”-Seite problemlos zu funktionieren (hilft aber natürlich nicht viel).

Die Logs von

/var/log/univention/management-console-web-server.log
/var/log/univention/management-console-server.log
/var/log/apache2/access.log

zeigen nichts auffälliges.

Weiß nicht, wo ich hier jetzt ansetzen soll. Irgendwelche Ideen?


#3

Moin,

das wird alles vermutlich nicht ganz schnell gehen. Nur so als Warnung vorweg.

Zur Fehlermeldung

diese Fehlermeldung deutet darauf hin, dass sich das Passwort des Rechneraccounts ucs-studio im OpenLDAP geändert hat. Das sollte bei einem Takeover eigentlich nicht geschehen. Warum? Weil:

In einem Univention-LDAP hat, wie auch in einem Active Directory, jeder gejointe Computer ein eigenes Objekt im LDAP-Baum. Das dazugehörige Passwort steht auf jedem Computer in der Datei /etc/machine.secret. Über ACLs wird geregelt, dass Anmeldungen am LDAP mit diesem Objekt gewisse Teilbäume gelesen bzw. geschrieben werden dürfen. Das Rechnerobjekt des DC Masters hat dabei die meisten Rechte.

Der Name des Rechnerobjekts steht in einer UCR-Variable; siehe ucr get ldap/hostdn.

NSS mit LDAP wird unter Univention nun automatisch so konfiguriert, dass es zum Durchsuchen des LDAPs das Computerobjekt zur Anmeldung nutzt. Kommt es nun zu dieser Fehlermeldung, so stimmt das in /etc/machine.secret stehende Passwort nicht mehr mit dem im LDAP beim Rechnerobjekt gespeicherten Passwort überein.

Das ist ziemlich schlecht, weil diese Credentials für so zimelich alles genommen werden, was aufs LDAP zugreift.

Sauberer Ausgangszustand

Bevor Sie aber weitermachen, sollten Sie zuerst sicherstellen, dass das aus dem Backup wiederhergestellte System auch konsistent ist, was die Synchronisation zwischen dem UCS-OpenLDAP und dem UCS-Samba4 (nicht zu verwechseln mit Ihrem alten Samba4-AD-DC!) betrifft. Dazu läuft der Dienst univention-s4connector.

Führen Sie bitte mal univention-s4connector-list-rejected auf. Werden hier Konflikte (»rejects«) angezeigt? Falls ja, so müssen Sie diese Konflikte zu allererst mal auflösen. Hier gibt es einen Support-Datenbank-Eintrag zu dem Thema.

Doppelte Einträge

Als nächstes zur Frage der doppelten Einträge in der UMC. Die anzuzeigenden Einträge stehen in der Datei /var/www/ucs-overview/entries.json. Schauen Sie bitte in der mal nach, ob dort die Einträge auch wirklich mehrfach vorhanden sind, oder ob sie nur mehrfach angezeigt werden. Falls mehrfach vorhanden: erzeugen Sie die Datei bitte mit ucr commit /var/www/ucs-overview/entries.json neu, und schauen Sie erneut nach.

Die entries.json wird letztlich aus gesetzten UCR-Variablen erzeugt. Posten Sie bitte mal die Ausgabe folgender Suche: ucr search --brief ucs/web/overview/entries

Takeover

Wenn Sie das System bisher als Mitglied in einem AD betrieben haben, so haben Sie vermutlich die App »Active Directory Connection« (heißt adconnector in der Ausgabe von univention-app list) installiert. Vielleicht ist es sinnvoll, diese zuerst zu deinstallieren, direkt bevor Sie den nächsten Übernahmeversuch starten.

Weiterhin sollte die Takeover-App in der aktuellen Reparaturphase sicherheitshalber noch mal entfernt werden.

Gruß,
mosu


#4

Hallo mosu,

erstmal danke für deine Vorschläge.

Das sehe ich mittlerweile auch so und werde voraussichtlich den UCS neu aufsetzen. Dürfte im Endeffekt die schnellere und sauberere Lösung sein.
Trotzdem werde ich deine Lösungsvorschläge kurz testen, alleine um mich etwas mehr mit den Interna von UCS vertraut zu machen.[quote=“Moritz_Bunkus, post:3, topic:5449”]
diese Fehlermeldung deutet darauf hin, dass sich das Passwort des Rechneraccounts ucs-studio im OpenLDAP geändert hat. Das sollte bei einem Takeover eigentlich nicht geschehen. Warum? Weil:

In einem Univention-LDAP hat, wie auch in einem Active Directory, jeder gejointe Computer ein eigenes Objekt im LDAP-Baum. Das dazugehörige Passwort steht auf jedem Computer in der Datei /etc/machine.secret. Über ACLs wird geregelt, dass Anmeldungen am LDAP mit diesem Objekt gewisse Teilbäume gelesen bzw. geschrieben werden dürfen. Das Rechnerobjekt des DC Masters hat dabei die meisten Rechte.

Der Name des Rechnerobjekts steht in einer UCR-Variable; siehe ucr get ldap/hostdn.

NSS mit LDAP wird unter Univention nun automatisch so konfiguriert, dass es zum Durchsuchen des LDAPs das Computerobjekt zur Anmeldung nutzt. Kommt es nun zu dieser Fehlermeldung, so stimmt das in /etc/machine.secret stehende Passwort nicht mehr mit dem im LDAP beim Rechnerobjekt gespeicherten Passwort überein.

Das ist ziemlich schlecht, weil diese Credentials für so zimelich alles genommen werden, was aufs LDAP zugreift.
[/quote]

Wenn ich das richtig verstanden habe, ist dient die Datei /etc/machine.secret der Authentifizierung am LDAP des
am UCS-openLDAP? IMHO ist das doch zur Authentifizierung des Computerkontos am ActiveDirectory?!

Mag sein das ich mich irre, aber ich bin mir ziemlich sicher, dass samba4 erst mit der Installation von AD-Takeover als dependency installiert wurde (also kann es diese Synchronisation davor wohl nicht gegeben haben?).
Außerdem wurden sowohl samba4 als auch univention-s4connector bei der Deinstallation der App wieder entfernt. Das war auch nötig, denn vor der Deinstallation wurde, wie erwähnt, immer kurz nach dem Restore des LDAP die fehlerhafte Authentifizierung wieder schlagend. Das kann aber evtl. an eben jener Inkonsistenz zwischen UCS-OpenLDAP und dem UCS-Samba4 gelegen haben.

Das Verzeichnis /var/www/ucs-overview/ ist bei mir vollkommen leer?!

ucr search --brief ucs/web/overview/entries:

ucs/web/overview/entries/.*/description.*: <empty>
ucs/web/overview/entries/.*/icon: <empty>
ucs/web/overview/entries/.*/label.*: <empty>
ucs/web/overview/entries/.*/link: <empty>
ucs/web/overview/entries/.*/port_http: <empty>
ucs/web/overview/entries/.*/port_https: <empty>
ucs/web/overview/entries/.*/priority: <empty>
ucs/web/overview/entries/admin/invalid-certificate-list/description/de: Liste der widerrufenen Zertifikate
ucs/web/overview/entries/admin/invalid-certificate-list/description: List of withdrawn certificates
ucs/web/overview/entries/admin/invalid-certificate-list/label/de: Zertifikat-Sperrliste
ucs/web/overview/entries/admin/invalid-certificate-list/label: Certificate revocation list
ucs/web/overview/entries/admin/invalid-certificate-list/link: ../ucsCA.crl
ucs/web/overview/entries/admin/invalid-certificate-list/priority: 91
ucs/web/overview/entries/admin/root-certificate/description/de: Zertifikat der Zertifizierungsstelle für die UCS-Domäne ad.b3-wohnen.at
ucs/web/overview/entries/admin/root-certificate/description: Certificate of the Certification Authority for UCS domain ad.b3-wohnen.at
ucs/web/overview/entries/admin/root-certificate/label/de: Wurzelzertifikat
ucs/web/overview/entries/admin/root-certificate/label: Root certificate
ucs/web/overview/entries/admin/root-certificate/link: ../ucs-root-ca.crt
ucs/web/overview/entries/admin/root-certificate/priority: 90
ucs/web/overview/entries/admin/ucs-local-to-domain/description/de: Zentrale Portal-Webseite für die UCS-Domäne
ucs/web/overview/entries/admin/ucs-local-to-domain/description/fr: Page web du portail central du domaine UCS
ucs/web/overview/entries/admin/ucs-local-to-domain/description: Central portal web page for the UCS domain
ucs/web/overview/entries/admin/ucs-local-to-domain/icon: /univention/portal/portal-logo.svg
ucs/web/overview/entries/admin/ucs-local-to-domain/label/de: Univention Portal
ucs/web/overview/entries/admin/ucs-local-to-domain/label/fr: Portail Univention
ucs/web/overview/entries/admin/ucs-local-to-domain/label: Univention Portal
ucs/web/overview/entries/admin/ucs-local-to-domain/link: /univention/portal/
ucs/web/overview/entries/service/dudle/description/de: Terminfindung und Abstimmungen einfach durchführen
ucs/web/overview/entries/service/dudle/description: Schedule events and execute polls very easy
ucs/web/overview/entries/service/dudle/icon: /univention-management-console/js/dijit/themes/umc/icons/scalable/apps-dudle_20160201.svg
ucs/web/overview/entries/service/dudle/label/de: Dudle - Termine & Umfragen
ucs/web/overview/entries/service/dudle/label: Dudle - Termine & Umfragen
ucs/web/overview/entries/service/dudle/link: /dudle
ucs/web/overview/entries/service/dudle/port_http: 80
ucs/web/overview/entries/service/dudle/port_https: 443
ucs/web/overview/entries/service/kopano-webapp/description/de: WebApp | Kopano Sharing & Communication Software
ucs/web/overview/entries/service/kopano-webapp/description: WebApp | Kopano Sharing & Communication Software
ucs/web/overview/entries/service/kopano-webapp/icon: /univention-management-console/js/dijit/themes/umc/icons/scalable/apps-kopano-webapp_20170102133543.svg
ucs/web/overview/entries/service/kopano-webapp/label/de: Kopano WebApp
ucs/web/overview/entries/service/kopano-webapp/label: Kopano WebApp
ucs/web/overview/entries/service/kopano-webapp/link: /webapp
ucs/web/overview/entries/service/kopano-webapp/port_http: 80
ucs/web/overview/entries/service/kopano-webapp/port_https: 443

Wie gesagt, danke für die Hilfe, aber ich werde wohl ein sauberes neues System aufsetzen (und ein ordentliches Backup vor dem nächsten “Takeover-Versuch” :wink:).


#5

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