Kerberos-Fehler auf DC & SSH-Verbindungs-Fehler auf Member

Hallo,

aktuell habe ich folgende Probleme auf dem DC und auf 2 Member-Servern auf dem 3 Member-Server läuft alles einwandfrei. Leider konnte ich mit Hilfe der anderen Einträge noch keine Lösung finden und hoffe auf Hilfe.
Auf allen Systemen läuft UCS 4.2-2 errata231

Auf dem DC erscheint folgende Fehlermeldung in der Systemdiagnose:
Überprüfe Kerberos authentifizierte DNS Updates
Fehler traten auf bei der Ausführung von kinit oder nsupdate.
kinit für den Principal dc$ mit der Password Datei /etc/machine.secret ist fehlgeschlagen.
image

Auf den Member-Servern “MAILSERVER” & “FILESERVER” folgende:
SSH-Verbindung zu anderem UCS Server Fehlgeschlagen!
Die SSH-Verbindung zu mindestens einem anderen UCS Server ist fehlgeschlagen. Die folgende Liste zeigt die betroffenen entfernten Rechner und den Grund für die fehlgeschlagene SSH-Verbindung.

dc.intern.schwarz-baumaschinen.de - Authentifizierung mit dem Maschinen-Konto ist fehlgeschlagen!
dc - Authentifizierung mit dem Maschinen-Konto ist fehlgeschlagen!

Authentifizierung mit dem Maschinen-Konto ist fehlgeschlagen - Der Login auf dem entfernten Rechner mit der uid mailserver$ und dem Passwort aus /etc/machine.secret is fehlgeschlagen. Bitte prüfen Sie /var/log/auth.log auf dem entfernten Rechner für weitere Informationen.
Mailserver
Fileserver

Ich hoffe jemand kann mir helfen!
Danke!

Gruß Daniel

Moin,

hinter dieser Fehlermeldung steckt Folgendes: jeder Computer in der Domäne hat auch ein Passwort. Unter UCS steht es in der Datei /etc/machine.secret. Das Passwort, das in der Datei steht, ist nun nicht mehr das Passwort, das in der Kerberos-Datenbank im Samba-4-Server steht. Das können Sie auf einem der betroffenen Server relativ einfach nachvollziehen, indem Sie versuchen, manuell ein Kerberos-Ticket zu erlangen:

kinit --password-file=/etc/machine.secret $(hostname)\$@$(ucr get kerberos/realm)

Da der Maschinenaccount für viele Dinge benutzt wird, z.B. zum Durchsuchen des LDAP-Verzeichnisses etc., muss das unbedingt behoben werden. Bei Ihren Memberservern ist die einfachste Lösung, die betroffenen Server erneut in die Domäne zu joinen. Dabei gehen keine Daten verloren. Um den Prozess zu starten, geben Sie auf den betroffenen Servern einfach univention-join ein. Bei den angeforderten Logindaten verwenden Sie administrator und das dazugehörige Login.

Nach erfolgreichem Join sollte der oben gezeigte Befehl wieder funktionieren.

Für den DC Master bastele ich momentan selber noch an einer Lösung, die manuelles Setzen des Passworts des Maschinenaccounts beinhaltet. Leider führt das nicht immer zum Erfolg. Ich untersuche noch, warum nicht.

Gruß
mosu

Moin,

so, ich habe den ganzen Prozess nun soweit im Griff, dass das auch mit Kerberos & auf dem DC Master funktionieren sollte.

  1. Das Maschinenpasswort muss einmalig manuell im LDAP-Verzeichnis, im Samba-4-LDAP gesetzt und in die Datei /etc/machine.secret geschrieben werden.
  2. Anschließend muss ein Server-Passwortwechsel angestoßen werden. Dabei wird das Passwort erneut neu gesetzt, aber auch in alle Konfigurationsdateien geschrieben, in denen der Maschinenaccount für Verbindungen zum LDAP genutzt wird. Daher genügt der erste Schritt alleine nicht.

Im Folgenden muss darauf geachtet werden, welche Befehle auf welchem Host ausgeführt werden. Ist der DC Master selber betroffen, so sind alle Befehle auf dem DC Master auszuführen; ist ein anderer Host betroffen, so bitte genau beachten, was wo getan werden muss.

Achtung: in meinen Beispielen nutze ich backup2 als Hostnamen eines betroffenen Beispielsystems. Den müssen Sie natürlich überall durch den tatsächlichen Hostnamen ersetzen.

Neues Passwort erzeugen

Zuerst erzeugt man ein neues Passwort, z.B. wie folgt:

source /usr/share/univention-lib/all.sh
create_machine_password

Dieses Passwort schreibt man auf dem betroffenen Host das neue Passwort in die Datei /etc/machine.secret. Hier ist unbedingt zu beachten, dass ausschließlich das Passwort in der Datei steht — es darf kein Zeichen mehr da sein, auch kein Zeilenumbruch! Daher ist dringend davon abzuraten, einen Editor zu nutzen, weil diese nun mal gerne Zeilenumbrüche einfügen. Am einfachsten geht es wie folgt:

echo -n dasNeuePasswort> /etc/machine.secret

Wichtig ist das -n. Das sollte man anschließend mit ls -l /etc/machine.secret prüfen — die Datei muss exakt so groß sein, wie das Passwort lang ist.

Passwort im OpenLDAP anpassen

Als nächstes setzt man das Passwort des Maschinenaccounts im LDAP neu auf das eben erzeugte. Das kann man über die UMC manuell (zu Computern navigieren, betroffene Maschine anklicken, Passwort eintragen, speichern) machen oder auf der Kommandozeile auf dem DC Master (!) mit udm, z.B. so:

udm computers/domaincontroller_backup modify --binddn cn=admin,$(ucr get ldap/base) --bindpwdfile /etc/ldap.secret --dn cn=backup2,cn=dc,cn=computers,$(ucr get ldap/base) --set password=dasNeuePasswort

Das Beispiel gilt für einen DC Backup namens backup2. Für andere Servertypen müssen das Modul und die DN angepasst werden. Die DN erfährt man auf dem betroffenen Host z.B. mit ucr get ldap/hostdn.

Ob das erfolgreich war, kann man mit folgendem Befehl auf dem betroffenen Host testen, der das OpenLDAP mit den neuen Credentials durchsucht:

ldapsearch -xZZ -D $(ucr get ldap/hostdn) -y /etc/machine.secret -s base

Passwort im Samba-4-LDAP anpassen

Da die Passwörter nicht vom OpenLDAP ins Samba-4-LDAP und damit zu den Kerberos-Accounts synchronisiert werden, setzt man anschließend das Passwort im Samba-4-LDAP mit folgendem Befehl, der ebenfalls auf dem DC Master auszuführen ist:

samba-tool user setpassword 'backup2$' --newpassword=dasNeuePassword

Ob das wiederum erfolgreich war, testet man, indem auf dem betroffenen Host ein Kerberos-Ticket angefordert wird:

kinit --password-file=/etc/machine.secret $(hostname)\$

Im Erfolgsfall gibt das nichts aus, und ein anschließendes klist zeigt ein aktives Token für den Host.

Weitere Aufräumarbeiten

Leider genügt das nicht; es müssen noch weitere Datenstrukturen im Samba-4-LDAP angepasst werden. Der Zustand ist jetzt aber glücklicherweise so, dass alle folgenden Arbeiten vom Univention-Script für den Server-Passwort-Wechsel erledigt werden können. Um diesen manuell anzustoßen, führt man auf dem betroffenen Host die folgenden Befehle aus:

oldval=$(ucr get server/password/interval)
ucr set server/password/interval=0
/usr/lib/univention-server/server_password_change
ucr set server/password/interval=$oldval

Im Erfolgsfall gibt das Script nichts aus. Logmeldungen finden sich in /var/log/univention/server_password_change.log.

Abschließende Tests

Die folgenden Befehle sollten nun auf dem betroffenen Host wieder funktionieren:

univention-ldapsearch
univention-s4search  # das nur, falls auch Samba 4 installiert ist
kinit --password-file=/etc/machine.secret $(hostname)\$
univention-ssh  /etc/machine.secret $(hostname)\$@$(ucr get ldap/master) ls /

Auch sollte die Systemdiagnose in der Univention Management Console keine Kerberos-Probleme mehr zeigen.

Gruß
mosu

1 Like

Hallo,

Danke für die Rückmeldung, inzwischen haben wir wegen anderer Sachen die Systeme komplett neu installiert.
Trotzdem vielen Dank für Ihre Hilfe!

Hallo,

kurze Rückmeldung zu deiner Anleitung…
Nachdem ich auch auf dem neu aufgesetzten System auf dem DC-Master nach einiger Zeit den “kritischen Kerberos-Fehler” hatte, bin ich gerade deine Anleitung zur Behebung mit Erfolg durchgegangen.

Allerdings verstehe ich noch nicht ganz warum dieser Fehler wieder aufgetreten ist…

Dafür noch einmal vielen Dank!:+1:

Mastodon