Keine Verbindung zu Active Directory Server

WSchanz · July 22, 2020, 1:19pm

Hallo allerseits, ich muss jetzt doch mal eure Hilfe bemühen. Ich versuche eine AD-Connector-Verbindung zum AD Windows 2016 Server herzustellen, was mir bei mehreren Installationen seit einigen Tagen nicht mehr gelingt. Vor einer Woche lief alles noch problemlos, dann konnte der UCS keine Authentifikation mehr am Windows AD Server durchführen.
Auch zwei neu aufgesetzte UCS konnten bei der Installation keine Verbindung bekommen so dass es wohl irgendwie am Windows Server liegen muss. Der AD Server wird aber gefunden (Meldung Object aktualisiert etc.)
Die Fehlermeldung lautet

kinit failed:
kinit: krb5_get_init_creds: unable to reach any KDC in realm IBMMN.LOCAL

Das hier funktioniert noch:

root@mmnucs:~# kinit admin@ibmmn.local
admin@ibmmn.local’s Password:
root@mmnucs:~# klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: admin@IBMMN.LOCAL

Issued Expires Principal
Jul 22 15:40:35 2020 Jul 23 01:40:35 2020 krbtgt/ibmmn.local@IBMMN.LOCAL
root@mmnucs:~#

Ich habe bereits DNS-Auflösung Domäne und Computer, Zeit (Abweichung 1 Min), Ping etc. geprüft. Alles OK.

Mir gehen die Ideen aus, ich hoffe ihr könnt mir helfen.

Mornsgrans · July 22, 2020, 8:19pm

Eigentlich sollte die Windows Ereignisanzeige die Versuche protokolliert haben. Entweder unter Anwendung, Sicherheit oder System.
Bei der Gelegenheit auch die Windows Firewall als “Übeltäter” in Erwägung ziehen.

WSchanz · July 23, 2020, 8:44am

Vielen Dank für den Tip - der hat mich zur Lösung geführt
Offenbar hat die automatische Änderung des Passworts des UCS Servers im AD (Standard 21 Tage) nicht korrekt funktioniert. Meine Lösung war das Rücksetzen des Computerobjektes im AD und ein Rejoin. Da ich diesmal aber das Computerobjekt entfernt hatte, waren die Rechte dafür nicht mehr ausreichend. Ich habe das UCS Objekt im AD jetzt in die Gruppe Domain-Controllers aufgenommen und alles funktioniert wieder.
Allerdings habe ich in der /var/log/auth.log immer noch regelmäßig den Fehler

GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Unknown error -1765328248)

Eventuell funktioniert deshalb der Abgleich bei einem neuen PW nicht?

Mornsgrans · July 23, 2020, 11:20am

Wenn ich nach der vollständigen Fehlermeldung google, erhalte ich zahlreiche Treffer bezüglich Kerberos-Error. - Vielleicht hilft dies weiter.

WSchanz · July 30, 2020, 7:20am

Leider muss ich jetzt die Lösung relativieren, das Problem trat unverhofft wieder auf. Aus unerfindlichen Gründen verliert der UCS Server die Authentifizierung am AD-Server. Beide Server wurden weder neu gestartet noch andere Arbeiten an den Systemen wurden vorgenommen. Die Zeit zur Änderung des Machine-PWD ist auch noch nicht abgelaufen (nach Join 21 Tage per default)
Die Fehlermeldung bei KINIT lautet jetzt wieder “kinit: krb5_get_init_creds: unable to reach any KDC in realm IBMMN.LOCAL”
Ich habe auch diesen Beitrag Problem: Kinit unable to reach any KDC in realm versucht aber ab Schritt 3 schlägt es fehl mit:

root@mmnucs:~# host -la ibmmn.local
Trying “ibmmn.local”
Host ibmmn.local not found: 5(REFUSED)

was wieder auf die verlorene Authentifizierung hindeutet.

Hat noch jemand eine Idee?

Mornsgrans · July 30, 2020, 10:43am

root@mmnucs:~# host -la ibmmn.local

Der DNS findet den Server mit dem Ping-Befehl? Der Windows-Server meldet in der Ereignisanzeige auch keinn ungültigen Authentifizierungsversuch?

Achte auch darauf, dass der UCS genug RAM zur Verfügung hat. Zu wenig RAM kann zu LDAP-Fehlern führen.

WSchanz · July 30, 2020, 10:57am

Ping ist auf alles OK

root@mmnucs:~# ping mmn20161
PING MMN20161.IBMMN.local (192.168.2.3) 56(84) bytes of data.
64 bytes from MMN20161.IBMMN.local (192.168.2.3): icmp_seq=1 ttl=128 time=0.865 ms
64 bytes from MMN20161.IBMMN.local (192.168.2.3): icmp_seq=2 ttl=128 time=0.832 ms
^C
— MMN20161.IBMMN.local ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.832/0.848/0.865/0.033 ms
root@mmnucs:~# ping ibmmn.local
PING ibmmn.local(fde2:8acd:e9d3:0:9eb:5ba0:3448:fa76 (fde2:8acd:e9d3:0:9eb:5ba0:3448:fa76)) 56 data bytes
64 bytes from fde2:8acd:e9d3:0:9eb:5ba0:3448:fa76 (fde2:8acd:e9d3:0:9eb:5ba0:3448:fa76): icmp_seq=1 ttl=64 time=1.77 ms
64 bytes from fde2:8acd:e9d3:0:9eb:5ba0:3448:fa76 (fde2:8acd:e9d3:0:9eb:5ba0:3448:fa76): icmp_seq=2 ttl=64 time=0.953 ms
64 bytes from fde2:8acd:e9d3:0:9eb:5ba0:3448:fa76 (fde2:8acd:e9d3:0:9eb:5ba0:3448:fa76): icmp_seq=3 ttl=64 time=1.12 ms
64 bytes from fde2:8acd:e9d3:0:9eb:5ba0:3448:fa76 (fde2:8acd:e9d3:0:9eb:5ba0:3448:fa76): icmp_seq=4 ttl=64 time=1.08 ms
^C
— ibmmn.local ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 0.953/1.235/1.773/0.318 ms
root@mmnucs:~# ping ibmmn.local -4
PING ibmmn.local (192.168.2.3) 56(84) bytes of data.
64 bytes from MMN20161.IBMMN.local (192.168.2.3): icmp_seq=1 ttl=128 time=1.03 ms
64 bytes from MMN20161.IBMMN.local (192.168.2.3): icmp_seq=2 ttl=128 time=0.773 ms
64 bytes from MMN20161.IBMMN.local (192.168.2.3): icmp_seq=3 ttl=128 time=0.897 ms
^C
— ibmmn.local ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2013ms
rtt min/avg/max/mdev = 0.773/0.901/1.034/0.109 ms
root@mmnucs:~# ping mmn20161.ibmmn.local
PING MMN20161.IBMMN.local (192.168.2.3) 56(84) bytes of data.
64 bytes from MMN20161.IBMMN.local (192.168.2.3): icmp_seq=1 ttl=128 time=0.871 ms
64 bytes from MMN20161.IBMMN.local (192.168.2.3): icmp_seq=2 ttl=128 time=0.954 ms
^C
— MMN20161.IBMMN.local ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.871/0.912/0.954/0.051 ms
root@mmnucs:~#

Der Windows-Server hat im Log keine ungültigen Authentifizierungsversuche. Die Authentifizierung des Administrators der Domäne ist auch OK da der Join zumindest teilweise funktioniert:

root@mmnucs:~# net ads join -U Admin machinepass=XXXXERSETZT
Enter Admin’s password:
Using short domain name – IBMMN
Joined ‘MMNUCS’ to dns domain ‘IBMMN.local’
DNS Update for mmnucs.ibmmn.local failed: ERROR_DNS_UPDATE_FAILED
DNS update failed: NT_STATUS_UNSUCCESSFUL

Das fehlgeschlagene DNS-Update hat evtl. etwas mit dem Fehler zu tun, das kam allerdings auch schon als die Verbindung/Authentifikation noch funktionierte.

Der UCS hat 18GB Ram

Interessant ist

root@mmnucs:~# host -la ibmmn.local
Trying “ibmmn.local”
Host ibmmn.local not found: 5(REFUSED)
; Transfer failed.

aber

root@mmnucs:~# host -a ibmmn.local
Trying “ibmmn.local”
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11580
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;ibmmn.local. IN ANY

;; ANSWER SECTION:
ibmmn.local. 600 IN A 192.168.2.3
ibmmn.local. 3600 IN NS mmn20161.ibmmn.local.
ibmmn.local. 3600 IN SOA mmn20161.ibmmn.local. hostmaster.ibmmn.local. 10904 900 600 86400 3600
ibmmn.local. 600 IN AAAA fde2:8acd:e9d3:0:9eb:5ba0:3448:fa76
ibmmn.local. 0 IN TYPE65281 # 20 000100000000000200000E1000000001C0A80203

;; ADDITIONAL SECTION:
mmn20161.ibmmn.local. 3600 IN A 192.168.2.3
mmn20161.ibmmn.local. 3600 IN AAAA 2003:e7:c705:5200:9eb:5ba0:3448:fa76
mmn20161.ibmmn.local. 3600 IN AAAA fde2:8acd:e9d3:0:9eb:5ba0:3448:fa76

Received 247 bytes from 192.168.2.3#53 in 1 ms