Hallo,
Ich hab noch ein weiteres Problem. Ich kriege bei der Systemdiganose immer folgende Probleme:
Wie fixe ich das am besten und in welcher Reihenfolge ?
Moin,
was für eine Serverrolle hat der? Der Hostname pdc$ suggeriert, dass es der DC Master in der Domäne ist. Stimm das?
Gruß
mosu
Ja stimmt !
Gruss
po3nter
Huhu,
der fehlschlagende Test »KDC Erreichbarkeit« ist höchstwahrscheinlich derjenige, den wir uns anschauen sollten, denn die zwei anderen sehen sehr nach Folgefehlern davon aus.
Bitte zeigen Sie mal die Ausgabe der folgenden Befehle:
ucr get kerberos/kdc
ucr get kerberos/defaults/dns_lookup_kdc
lsof -Pni:88
Gruß
mosu
Erstmal danke für die Antwort :
ucr get kerberos/kdc
127.0.0.1
ucr get kerberos/defaults/dns_lookup_kdc
keine Ausgabe
lsof -Pni:88
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
samba 1240 root 24u IPv6 19579 0t0 TCP [::1]:88 (LISTEN)
samba 1240 root 30u IPv6 19580 0t0 UDP [::1]:88
samba 1240 root 34u IPv4 19583 0t0 TCP 127.0.0.1:88 (LISTEN)
samba 1240 root 35u IPv4 19584 0t0 UDP 127.0.0.1:88
samba 1240 root 38u IPv4 19587 0t0 TCP 192.168.11.2:88 (LISTEN)
samba 1240 root 39u IPv4 19588 0t0 UDP 192.168.11.2:88
Moin
das KDC läuft also, und auch auf der konfigurierten Adresse, das ist schon mal gut. Probieren Sie bitte, sich ein Token für den User Administrator zu holen und anschließend nachzuschauen, ob das auch geklappt hat:
kinit administrator@$(ucr get kerberos/realm)
klist
Ersteres sollte bis auf die Passwortaufforderung keine Ausgabe erzeugen, und letzteres sollte ein Token auflisten.
Gruß
mosu
nach klist kommt die ausgabe:
Credentials cache: FILE:/tmp/krb5cc_0
Principal: administrator@HUF.INTRANETIssued Expires Principal
Nov 24 13:20:30 2017 Nov 24 23:20:16 2017 krbtgt/HUF.INTRANET@HUF.INTRANET
Moin,
das sieht doch gut aus. Das bedeutet nämlich, dass Kerberos sehr wohl funktioniert.
Meine Vermutung ist, dass das Passwort, dass in /etc/machine.secret steht, nicht mehr zum Maschinen-Account im LDAP passt. Du kannst das Passwort im LDAP aber mit folgenden Befehlen einfach neu setzen:
old_value=$(ucr get server/password/interval)
ucr set set server/password/interval=0
/usr/lib/univention-server/server_password_change
ucr set set server/password/interval=${old_value}
Der Vorgang wird in /var/log/univention/server_password_change.log protokolliert, und mehr zu dem Thema gibt’s in diesem FAQ-Eintrag.
Schau anschließend im Servercheck erneut nach.
Gruß
mosu
1 Like
Hallo und servus zusammen,
@moritz vielen Dank erstmal.
Ich habe die Befehle ausgeführt.
Allerdings quittiert er mit
failed to change server password for cn=pdc,cn=dc,cn=computers,dc=huf,dc=intranet
Es scheint ein wohl ein Problem mit den maschine.secrets zu geben.
Gibt es denn eine Möglichkeit diese neu zu vergeben? Eine Art re-Init?
Viele Grüße,
Ralph
Moin,
ja, das geht. Führen Sie die folgenden Befehle aus:
echo -n neuesGeheimesPasswort> /etc/machine.secret
udm computers/domaincontroller_master modify --dn $(ucr get ldap/hostdn) --set password=$(</etc/machine.secret)
ldapsearch -x -ZZ -s base -D $(ucr get ldap/hostdn) -y /etc/machine.secret dn
Der zweite Befehl sollte so etwas ausgeben:
Object modified: cn=master,cn=dc,cn=computers,dc=mbu-test,dc=intranet
Der dritte sollte dann eine erfolgreiche LDAP-Suche durchführen, bei der ein Treffer (eine Zeile mit dn:) erscheint.
Klappt das, so führen Sie anschließend unbedingt noch mal die Prozedur zum Server-Passwort-Wechsel durch, denn dabei wird noch eine Ecke mehr gemacht, als nur das Passwort dieses einen LDAP-Objekts anzupassen.
Gruß
mosu