23
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 fragt nach Benutzername und Kennwort
Umgekehrt von DC1 über 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.
und
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
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
... 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 \\DC1Umgekehrt von DC1 über
net view \\DC2"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 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:*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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 532568
Url: https://administrator.de/contentid/532568
Printed on: April 19, 2024 at 07:04 o'clock
23 Comments
Latest comment
Hi,
die Uhrzeiten der beteiligten Computer in der Domäne sind synchron? (Abweichung <= +/- 5 min)
E.
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
liefert eine Stammabweichung von 0.3079982s
DC1 bekommt seine Zeit von de.pool.ntp.org
DC2 bekommt sie von DC1
w32tm /query /status
Hallo,
und dann noch: IPv4 oder IPv6? wenn IPv6 - wird hier korrekt aufgelöst?
Grüße
lcer
Zitat von @RicoPausB:
Sind sie.
DC1 bekommt seine Zeit von de.pool.ntp.org
DC2 bekommt sie von DC1
liefert eine Stammabweichung von 0.3079982s
ist das gemessen, wenn "alles Läuft" oder wenn der Fehler kommt?Sind sie.
DC1 bekommt seine Zeit von de.pool.ntp.org
DC2 bekommt sie von DC1
w32tm /query /statusund 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.
Zu dem Zeitpunkt war der Fehler gerade nicht da.
Verbindung läuft ausschließlich über IPv4.
Hallo,
Dann messen, wenn der Fahler auftritt
Grüße
lcer
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 durchgeführt und die Zeit passte wieder.
Allerdings hat DC2 nun diese Einträge:
Die Quelle ist nicht mehr DC1 ?!
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 w32timeAllerdings 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)
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
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!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)?
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 w32timeDas 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 w32timeWobei ich aktuell wie gesagt einen DC als VM habe, der immer auf "Local CMOS clock" steht. (Uhrzeit ist aber korrekt)
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.
Edit:
Schau mal HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type
Da muss "NT5DS" drin stehen.
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"
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 drinSchau mal HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type
Da muss "NT5DS" drin stehen.
Zitat von @lcer00:
Dann messen, wenn der Fahler auftritt
Wurde gerade vorhin gemessen.
Zu dem Zeitpunkt war der Fehler gerade nicht da.
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.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 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
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.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?
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
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
Jedenfalls finde ich weder ausgestellte in der aktuellen Zertifizierungsstelle noch irgendwelche in certmgr.msc auf DC1 /DC2
Hallo,
Wenn beim Verbindungsaufbau ein falsches / altes angeboten wird, gibt es Probleme.
Grüße
lcer
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..Nicht das ich wüsste ...
Jedenfalls finde ich weder ausgestellte in der aktuellen Zertifizierungsstelle noch irgendwelche in certmgr.msc auf DC1 /DC2
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.
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:
DC2 hat von unserer CA auf DC1 vier Zertifikate erhalten.
Aus vier Zertifikatsvorlagen:
- Domänencontroller (DomainController)
- Domänencontrollerauthentifizierung
- Kerberos-Authentifizierung
- Verzeichnis-E-Mail-Replikation
Zitat von @lcer00:
Wenn beim Verbindungsaufbau ein falsches / altes angeboten wird, gibt es Probleme.
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
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:
meiner kommt mit einem Zertifikat nach Vorlage "Domänencontroller" (Original, Zertifizierungsstelle Server 2012R2). Also habt ihr selbst Zertifikate zusätzliche erstellt.
Zitat von @RicoPausB:
DC2 hat von unserer CA auf DC1 vier Zertifikate erhalten.
Aus vier Zertifikatsvorlagen:
- Domänencontroller (DomainController)
- Domänencontrollerauthentifizierung
- Kerberos-Authentifizierung
- Verzeichnis-E-Mail-Replikation
Zitat von @lcer00:
Wenn beim Verbindungsaufbau ein falsches / altes angeboten wird, gibt es Probleme.
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
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.
