08.01.2020, aktualisiert um 09:22:19 Uhr

15730

Kerberos Probleme - Zielkontoname ungültig

Moin zusammen ...

... ich stoße hier so langsam an meine fachlichen Grenzen bei der Suche nach einer Lösung für unser Problem:

In fast allen Standorten bei uns kommt es aktuell zu dem Problem, dass Druckerzuordnungen via GPO nicht funktionieren und dass Freigaben nicht verfügbar sind.
Als Meldung kommt im Explorer z.B. beim Aufruf von \\DC1 immer die Meldung "Zielkontoname ist ungültig".

Ein Versuch auf DC2 über CMD mit

net view \\DC1

fragt nach Benutzername und Kennwort
Umgekehrt von DC1 über

net view \\DC2

sehe ich die Freigaben.

"Zielkontoname ungültig" hängt ja meines Wissens nach fast immer irgendwie mit Kerberos zusammen.

Da ich im Explorer und in der CMD über die IP an die Freigaben komme, scheint sich das zu bestätigen, da ja über die IP NTLM statt Kerberos verwendet wird, wenn ich das richtig in Erinnerung habe.

Also habe ich zuerst über repadmin in den META-Daten die Versionen der ntPwdHistory und das Datum von pwdLastSet überprüft.

repadmin /showmeta "cn=DC2,ou=domain controllers,dc=mydomain,dc=lan" DC2

und

repadmin /showmeta "cn=DC2,ou=domain controllers,dc=mydomain,dc=lan" DC1

Beide Angaben auf beiden Servern identisch.
Also sollte es ja eigentlich nicht daran liegen.

DNS Einstellungen sind auch korrekt, denke ich.
DC2 hat DC1 als primary DNS und sich selber als secondary DNS

Jedenfalls zeigt nslookup die korrekten Daten an und ein ping ist sowohl über die IP, den netBIOS-Namen und den FQDN machbar.

Wenn ich allerdings manuell den Kerberosdienst auf DC2 stoppe und deaktiviere und das Computerkennwort zurücksetze über

netdom resetpwd /s:dc1 /ud:admin-account /pd:*

kommt die Bestätigung, dass das Kennwort zurückgesetzt wurde.
Und ab diesem Moment funktioniert wieder alles.
In den META-Daten steht dann auch die korrekten Werte und das korrekte Datum drin.

Allerdings funktioniert es nicht lange. Spätestens am nächsten Morgen ist alles wieder bei "Zielkontoname ungültig".

Hoffe, jmd. hat eine rettende Idee.

Grüße

Der Rico

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 532568

Url: https://administrator.de/forum/kerberos-probleme-zielkontoname-ungueltig-532568.html

Ausgedruckt am: 26.12.2024 um 00:12 Uhr

23 Kommentare

Neuester Kommentar

Hi,
die Uhrzeiten der beteiligten Computer in der Domäne sind synchron? (Abweichung <= +/- 5 min)

E.

Sind sie.
DC1 bekommt seine Zeit von de.pool.ntp.org
DC2 bekommt sie von DC1

w32tm /query /status

liefert eine Stammabweichung von 0.3079982s

Hallo,

Zitat von @RicoPausB:

Sind sie.
DC1 bekommt seine Zeit von de.pool.ntp.org
DC2 bekommt sie von DC1

w32tm /query /status

liefert eine Stammabweichung von 0.3079982s

ist das gemessen, wenn "alles Läuft" oder wenn der Fehler kommt?

und dann noch: IPv4 oder IPv6? wenn IPv6 - wird hier korrekt aufgelöst?

Grüße

lcer

Wurde gerade vorhin gemessen.
Zu dem Zeitpunkt war der Fehler gerade nicht da.

Verbindung läuft ausschließlich über IPv4.

Hallo,

Zitat von @RicoPausB:

Wurde gerade vorhin gemessen.
Zu dem Zeitpunkt war der Fehler gerade nicht da.

Dann messen, wenn der Fahler auftritt

Verbindung läuft ausschließlich über IPv4.

dass heißt, nslookup liefert auf keinem der Server eine ipv6 Adresse aus? (sicherheitshalber auf beiden Server prüfen!) und die Server haben keine IPv6-Zonen bzw. AAAA-records gespeichert?

Grüße

lcer

nslookup liefert nur den fqdn und die IPv4 IP.
IPv6 Zonen haben wir hier noch nicht verwendet.

Allerdings habe ich gerade gesehen, dass DC2 eine Abweichung von rund 2 Minuten hatte, obwohl laut query gerade aktualisiert wurde.

Habe dann via

w32tm /config /syncfromflags:domhier /update
net stop w32time && net start w32time

durchgeführt und die Zeit passte wieder.

Allerdings hat DC2 nun diese Einträge:

w32tm /query /status
Sprungindikator: 0(keine Warnung)
Stratum: 1 (Primärreferenz - synchron. über Funkuhr)
Präzision: -6 (15.625ms pro Tick)
Stammverzögerung: 0.0000000s
Stammabweichung: 10.0000000s
Referenz-ID: 0x4C4F434C (Quellname:  "LOCL")  
Letzte erfolgr. Synchronisierungszeit: 08.01.2020 12:56:52
Quelle: Local CMOS Clock
Abrufintervall: 6 (64s)

Die Quelle ist nicht mehr DC1 ?!

reden wir von einer VM?

Als Du die externe Zeitquelle am DC1 eingetragen hast, hast Du hoffentlich nicht die NTP-Konfiguration irgendwelcher anderen DC's oder Member dieser Gesamtstruktur geändert (vom Standard abweichend)?

Tun wir ...
Läuft auf PROXMOX5
"use local time for RTC" ist aber deaktiviert.

Auf jeden Fall passt jedoch die Uhrzeit

Zitat von @emeriks:

Als Du die externe Zeitquelle am DC1 eingetragen hast, hast Du hoffentlich nicht die NTP-Konfiguration irgendwelcher anderen DC's oder Member dieser Gesamtstruktur geändert (vom Standard abweichend)?

Ich hoffe nicht!
Habe auf dem PDC folgendes eingerichtet:

w32tm /config /manualpeerlist:"0.de.pool.ntp.org 1.de.pool.ntp.org 2.de.pool.ntp.org"   
        /syncfromflags:manual /reliable:yes /update"  
net stop w32time && net start w32time

Das steht dort auch immer noch drin:

w32tm /query /status
Sprungindikator: 0(keine Warnung)
Stratum: 3 (Sekundärreferenz - synchr. über (S)NTP)
Präzision: -6 (15.625ms pro Tick)
Stammverzögerung: 0.0268901s
Stammabweichung: 0.0601638s
Referenz-ID: 0x9F4504B5 (Quell-IP:  159.69.4.181)
Letzte erfolgr. Synchronisierungszeit: 08.01.2020 14:30:19
Quelle: 1.de.pool.ntp.org
Abrufintervall: 10 (1024s)

w32tm /query /peers
Anzahl Peers: 3

Peer: 1.de.pool.ntp.org
Status: Aktiv
Verbleibende Zeit: 931.0542338s
Modus: 1 (Symmetrisch aktiv)
Stratum: 2 (Sekundärreferenz - synchr. über (S)NTP)
PeerAbrufintervall: 10 (1024s)
HostAbrufintervall: 10 (1024s)

Peer: 2.de.pool.ntp.org
Status: Aktiv
Verbleibende Zeit: 931.0542572s
Modus: 1 (Symmetrisch aktiv)
Stratum: 2 (Sekundärreferenz - synchr. über (S)NTP)
PeerAbrufintervall: 10 (1024s)
HostAbrufintervall: 10 (1024s)

Peer: 0.de.pool.ntp.org
Status: Aktiv
Verbleibende Zeit: 927.9525935s
Modus: 1 (Symmetrisch aktiv)
Stratum: 2 (Sekundärreferenz - synchr. über (S)NTP)
PeerAbrufintervall: 10 (1024s)
HostAbrufintervall: 10 (1024s)

An den Standort-DC wurde es dann so gemacht:

w32tm /config /syncfromflags:domhier /update
net stop w32time && net start w32time

Wobei ich aktuell wie gesagt einen DC als VM habe, der immer auf "Local CMOS clock" steht. (Uhrzeit ist aber korrekt)

Zitat von @RicoPausB:
An den Standort-DC wurde es dann so gemacht:

Und warum nicht nichts? So, wie es korrekt gewesen wäre?

Edit:
Schau mal HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type
Da muss "NT5DS" drin stehen.

Zitat von @emeriks:
Und warum nicht nichts? So, wie es korrekt gewesen wäre?

Weil fast alles VM sind, die auf "Local CMOS clock" standen.
Jedenfalls besteht das Problem aktuell nur bei einem. Alle anderen haben aktuell den DC1 als source drin.

https://docs.microsoft.com/en-us/windows-server/networking/windows-time- ...
Abschnitt "Time Synchronization in an AD DS Hierarchy"

Zitat von @emeriks:
Schau mal HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type
Da muss "NT5DS" drin stehen.

steht drin

Zitat von @lcer00:

Wurde gerade vorhin gemessen.
Zu dem Zeitpunkt war der Fehler gerade nicht da.

Dann messen, wenn der Fahler auftritt

auf DC2 ist der Fehler nach einem Neustart wieder da ...

w32tm /query /status
Sprungindikator: 0(keine Warnung)
Stratum: 4 (Sekundärreferenz - synchr. über (S)NTP)
Präzision: -6 (15.625ms pro Tick)
Stammverzögerung: 0.0509358s
Stammabweichung: 0.0950255s
Referenz-ID: 0x94FB23D2 (Quell-IP:  IP-von-DC1)
Letzte erfolgr. Synchronisierungszeit: 08.01.2020 16:14:02
Quelle: DC1.mydomain.lan
Abrufintervall: 10 (1024s)

net view \\DC1
Systemfehler 5 aufgetreten.

Im Explorer kommt wieder "Zielkontoname ist ungültig"

Check der META-Daten via Repadmin zeigt identische Einträge auf DC1 und DC2, wobei ich mir die Einträge für DC1 auf DC2 nicht ansehen kann.

repadmin /showmeta "cn=dc1,ou=domain controllers,dc=mydomain,dc=lan" DC1

auf DC2 ausgeführt liefert als Ergebnis:

DsBindWithCred mit dc1 ist fehlgeschlagen mit Status -2146893022 (0x80090322): Der Zielprinzipalname ist falsch.

Hallo
Ist das eigentlich das System mit dem 6MonateToten DC? Wenn ja, wer ist denn nun der FSMO-Rolleninhaber?

Gibt das Eventlog nach dem Neustart noch andere Fehler aus?

Grüße

lcer

Zitat von @lcer00:

Hallo
Ist das eigentlich das System mit dem 6MonateToten DC? Wenn ja, wer ist denn nun der FSMO-Rolleninhaber?

Gibt das Eventlog nach dem Neustart noch andere Fehler aus?

Ja, das ist die Umgebung, die mal einen "6MonateToten DC" hatte.
Der ist aber mittlerweile komplett raus und nicht wieder in Betrieb gegangen. Gab auch lange keine Probleme.
FSMO Rollen hat jetzt komplett der DC1.

Das Eventlog checke ich ...

Sind noch irgendwelche vom alten dc ausgrstellte Computerzertifikate auf den Neuen Servern installiert?

Grüße

lcer

Nicht das ich wüsste ...
Jedenfalls finde ich weder ausgestellte in der aktuellen Zertifizierungsstelle noch irgendwelche in certmgr.msc auf DC1 /DC2

Hallo,

Zitat von @RicoPausB:

Nicht das ich wüsste ...
Jedenfalls finde ich weder ausgestellte in der aktuellen Zertifizierungsstelle noch irgendwelche in certmgr.msc auf DC1 /DC2

der DC sollte ein gültiges Domänencontrollerzertifikat haben - ab besten auch nur eins unter Computerzertifikate->Eigene..

Wenn beim Verbindungsaufbau ein falsches / altes angeboten wird, gibt es Probleme.

Grüße

lcer

Zitat von @lcer00:
Wenn beim Verbindungsaufbau ein falsches / altes angeboten wird, gibt es Probleme.

DC2 hat von unserer CA auf DC1 vier Zertifikate erhalten.
Aus vier Zertifikatsvorlagen:
- Domänencontroller (DomainController)
- Domänencontrollerauthentifizierung
- Kerberos-Authentifizierung
- Verzeichnis-E-Mail-Replikation

Keine alten /ungültigen Zertifikate vorhanden.

Zitat von @RicoPausB:

Zitat von @lcer00:
Wenn beim Verbindungsaufbau ein falsches / altes angeboten wird, gibt es Probleme.

meiner kommt mit einem Zertifikat nach Vorlage "Domänencontroller" (Original, Zertifizierungsstelle Server 2012R2). Also habt ihr selbst Zertifikate zusätzliche erstellt.

Dann würde ich die Zertifikate einzeln überprüfen, ob der jeweilige Verwendungszweck passt, ob die Sperrlisten erreichbar sind und so weiter.

Grüße

lcer

Zitat von @lcer00:

Zitat von @RicoPausB:

Zitat von @lcer00:
Wenn beim Verbindungsaufbau ein falsches / altes angeboten wird, gibt es Probleme.

meiner kommt mit einem Zertifikat nach Vorlage "Domänencontroller" (Original, Zertifizierungsstelle Server 2012R2). Also habt ihr selbst Zertifikate zusätzliche erstellt.

Ich habe kein einziges Zertifikat zusätzlich erstellt.
Alle diese Vorlagen haben von vorn herein existiert (Original, Zertifizierungsstelle Server 2016).

Die DC haben von der CA alle am gleichen Tag ein Cert vom Typ DomainController erhalten.
Und ein paar Tage später haben alle DC die anderen drei erhalten.
Warum, wenn nicht nötig ?! Keine Ahnung ...

Sperrlisten gibt es jedenfalls keine und gültig sind auch alle noch bis 04/2020.

Frage Microsoft Windows Netzwerk

Mehr von RicoPausB

Hetzner Proxmox vSwitch pfSense VPN - ProblemeRicoPausB - 2 Kommentare

HETZNER PROXMOX vswitch pfsenseRicoPausB - 5 Kommentare

IPsec Tunnel plötzlich ohne TrafficRicoPausB - 4 Kommentare

Export-csv nur bestimmte SpaltenRicoPausB - 4 Kommentare

Heiß diskutiert