Anmeldung nicht möglich wegen Verbindungsproblemen zum Domaincontroller

[AndreEx 0]

Hallo zusammen,

 

ich habe vor Kurzem unseren Domänen Controller migriert von Windows Server 2003 auf  Windows Server 2016 (neue Hardware).

Der DC ist virtuell mit HyperV. Wir haben nur einen DC.

 

Sporadisch haben wir in der Firma folgendes Problem:

- Bei der Anmeldung an einem Client oder an einem Server erscheint die Meldung, dass das Kennwort falsch sei, obwohl es richtig eingegeben wird.

-> Ich habe mittels GPO festgelegt, dass die letzten Anmeldungen auf dem Client gespeichert bleiben, sodass das Problem nicht mehr auftaucht. Zumindest dachte ich das...

- Nach der Anmeldung werden die Gruppenrichtlinien nicht aktualisiert. Mittels gpupdate /force erhalte ich die Meldung, dass kein Domänencontroller verfügbar ist.

- Teilweise erhalte ich auch bei der Anmeldung am Client die Meldung, dass kein Authentifizierungsserver verfügbar ist und die Anmeldung mit gespeicherten Anmeldedaten erfolgt ist.

- Wenn ich mich bei einem Server anmelde (wo die Speicherung der letzten Anmeldungen nicht aktiviert ist), erhalte ich wieder die Meldung, dass das Kennwort falsch sei.

- Eine Anmeldung ist nur mit lokalem Admin möglich, damit ich den Server neustarten kann.

- Nach dem Neustart des Domänen Controllers funktioniert alles wieder.

 

Hat jemand eine Idee, woran das liegen könnte?

 

Vielen Dank im Voraus.

 

EDIT:

 

Ich habe folgende Änderung in der Netzwerkkonfiguration des DCs vorgenommen:

- IPv6 habe ich deaktiviert

- Für IPv4 war ein alternative DNS-Server eingetragen, den es nicht mehr gibt.

 

Beide Änderungen habe ich aufgrund von Hinweisen in anderen Foren durchgeführt. Ob das die Ursache gewesen ist, weiß ich nicht.

 

EDIT:

 

- Nun habe ich auch noch festgestellt, dass im DNS in den Eigenschaften von _msdcs.domain.local noch Nameserver eingetragen sind, die es nicht mehr gibt.

- Außerdem habe ich die alten DNS-Einträge unter "DomainDnsZones > _tcp" und "ForestDnsZones > _tcp" entfernt.

bearbeitet 8. August 2018 von AndreEx

[Nobbyaushb 1.580]

Habe nicht alles gelesen, aber warum wird IPv6 deaktiviert?

 

Gerade seit Server 2012 wir intern NUR IPv6 "geredet" und durch "abschalten" an der Netzwerkkarte ist es noch lange nicht aus.

 

Also - Haken wieder rein.

 

Lieber ein stateless IPv6 als keines.

 

Und die DNS-Auflösung sollte man eh immer kontrollieren - wöchentlich.

[AndreEx 0]

Wir hatten vorhin wieder Probleme:

- Anmeldung funktioniert nicht

- Gruppenrichtlinien konnten nicht geladen werden

- DNS funktionierte nicht einwandfrei

Ich vermute, dass die Probleme zusammenhängen und es immernoch "Rückstände" vom alten Windows Server 2003 Domänencontroller gibt.

 

Mit setspn -l habe ich den alten und den neuen Server abgefragt. Dabei ist mir aufgefallen, dass das Dienstkonto "DNS" auch bei dem alten Server noch registriert ist. Das habe ich nun entfernt. Keine Ahnung, ob es damit zusammenhängt.

 

Hat jemand noch eine Idee dazu? Ich werde auf jeden Fall die Ereignisprotokolle durchsuchen und bin weiterhin auf Ursachenforschung.2

[NilsK 3.045]

Moin,

 

prüf dies:

[Was muss ich beim DNS für Active Directory beachten? (Reloaded) | faq-o-matic.net]
https://www.faq-o-matic.net/2007/01/09/was-muss-ich-beim-dns-fuer-active-directory-beachten-reloaded/

 

Vor allem ist wichtig, dass die Clients den richtigen DNS-Server fragen und keinen (!) anderen. Auch nicht als sekundären.

Die Bereinigung der veralteten DNS-Einträge noch mal prüfen und ggf. fortführen.

 

Falsche SPN-Einträge sind problematisch, dürften aber zu den hier geschilderten Phänomenen eher nicht beitragen.

 

Wie ist denn der alte DC entfernt worden?

 

Gruß, Nils

 

[AndreEx 0]

Moin und danke für die schnelle Meldung.

 

Ich habe den Windows Server 2003 DC zu einen Windows Server 2008 DC migriert und den 2003 DC heruntergestuft.

Von 2008 habe ich dann schließlich auf 2016 migriert und den 2008er DC wiederum heruntergestuft.

 

Der 2003 Server (ehem. DC) befindet sich noch im Netz (mit demselben DNS-Namen und derselben IP). Sollten also tatsächlich noch alte Einträge vorhanden gewesen sein (ein paar hatte ich hatte ich ja bereits bereinigt (siehe oben)), ist der 2003 Server noch "ansprechbar", kann aber nichts mehr machen. Darin habe ich die Ursache für die Probleme gesehen. Vielleicht irre ich mich komplett.

 

Ich habe noch nicht alle Ereignisse angeschaut und recherchiert. Das erste Ereignis, das im jüngsten Vorfall auf dem Client aufgetreten ist, lautet:

 

Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "serverex$" empfangen. Der verwendete Zielname war cifs/serverex. Dies deutet darauf hin, dass der Zielserver das vom Client bereitgestellte Token nicht entschlüsseln konnte. Dies kann auftreten, wenn der Ziel-Serverprinzipalname (SPN) nicht bei dem Konto registriert ist, das der Zieldienst verwendet. Stellen Sie sicher, dass der Ziel-SPN nur bei dem Konto registriert ist, das vom Server verwendet wird. Dieser Fehler kann auch auftreten, wenn das Kennwort für das Zieldienstkonto nicht mit dem Kennwort übereinstimmt, das im Kerberos-KDC (Key Distribution Center) für den Zieldienst konfiguriert ist. Stellen Sie sicher, dass der Dienst auf dem Server und im KDC beide für die Verwendung des gleichen Kennworts konfiguriert sind. Wenn der Servername nicht vollqualifiziert ist und sich die Zieldomäne (MAILWORK.LOCAL) von der Clientdomäne (MAILWORK.LOCAL) unterscheidet, prüfen Sie, ob sich in diesen beiden Domänen Serverkonten mit gleichem Namen befinden, oder verwenden Sie den vollqualifizierten Namen, um den Server zu identifizieren.

 

Deswegen habe ich mir die SPNs anzeigen lassen und den SPN für den Dienst DNS beim alten Server entfernt.

 

Sagt dir/euch das o.a. Ereignis was?

[NilsK 3.045]

Moin,

 

also hattest du zusätzlich zum 2003-DC einen 2008-DC installiert und den 2003 dann heruntergestuft? Danach hattest du zusätzlich zum 2008-DC einen 2016-DC installiert und dann den 2008 heruntergestuft? Hattest du vor den jeweiligen Herunterstufungen geprüft, dass beide DCs ordentlich miteinander kommunizieren und die Replikation lief? Wieviel Zeit lag zwischen den einzelnen Vorgängen? Waren zwischendurch die IP-Konfigurationen der Clients angepasst worden?

 

Führe mal 

dcdiag /E > C:\Pfad\Datei.txt

aus. Werden im Ergebnis Fehler oder Probleme gemeldet?

 

Gruß, Nils

 

[AndreEx 0]

vor 17 Minuten schrieb NilsK:

also hattest du zusätzlich zum 2003-DC einen 2008-DC installiert und den 2003 dann heruntergestuft? Danach hattest du zusätzlich zum 2008-DC einen 2016-DC installiert und dann den 2008 heruntergestuft?

Ja, genau

vor 17 Minuten schrieb NilsK:

Hattest du vor den jeweiligen Herunterstufungen geprüft, dass beide DCs ordentlich miteinander kommunizieren und die Replikation lief? Wieviel Zeit lag zwischen den einzelnen Vorgängen? Waren zwischendurch die IP-Konfigurationen der Clients angepasst worden?

Ja, die Replizierung habe ich geprüft. Da war ich sehr vorsichtig. Da ich die Replizierung manuell angestoßen habe, habe ich nicht auf die Zeit geachtet. Die IP-Konfiguration habe ich angepasst. Allerdings habe ich nun festgestellt, dass bei manchem Server in den IPv4-Einstellungen noch ein sekundärer DNS Server hinterlegt gewesen ist. Das hatte ich aber bereits bereinigt (siehe meinen ersten Post).

 

Das Ergebnis der Diagnos habe ich in den Anhang eingefügt. Ich habe nur die Fehlermeldungen dringelassen. Vermutlich müssen die Fehler erst einmal beseitigt werden, oder?

 

Besten Dank für deine Hilfe.

Zusammenfassung Fehlermeldungen.txt

[NilsK 3.045]

Moin,

 

als erstes korrigierst du die Zeitserver-Einstellungen:

 

https://www.gruppenrichtlinien.de/de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo/

 

Dann etwas abwarten und den Report neu erzeugen. Dann weitersehen.

 

Gruß, Nils

 

[djmaker 95]

Öffne auf einem Server oder Client mal das cmd und poste die Ausgabe von

 

NetDOM /query FSMO

 

hier.

[AndreEx 0]

vor 4 Stunden schrieb djmaker:

Öffne auf einem Server oder Client mal das cmd und poste die Ausgabe von

 

NetDOM /query FSMO

 

hier.

Das Ergebnis ist in Ordnung. Hier wird überall der Domänencontroller angezeigt. Darauf habe ich auch bei der Migration des DCs geachtet.

 

vor 6 Stunden schrieb NilsK:

Dann etwas abwarten und den Report neu erzeugen. Dann weitersehen.

Habe die Gruppenrichtlinien gesetzt und zusätzlich noch die Zeitsynchronisation zwischen Hyper-V-Host und VMs deaktiviert. Es gibt dazu unterschiedliche Meinungen im Internet, Letztendlich habe ich mich dazu entschieden, sie zu deaktivieren. Erschien mir logisch, da der Hyper-V-Host selbst nicht mit dem DC die Zeit synchronisieren kann.

 

Die Diagnose sind schon viel besser aus.

 

Ich werde morgen noch einmal genauer schauen und die restlichen Fehler hier mitteilen.

 

Vielen Dank bis dahin! Das war ein guter Hinweis, Nils.

 

[NorbertFe 2.277]

vor 9 Stunden schrieb AndreEx:

Erschien mir logisch, da der Hyper-V-Host selbst nicht mit dem DC die Zeit synchronisieren kann.

 

Warum nicht?

[MurdocX 1.002]

vor 9 Stunden schrieb AndreEx:

Habe die Gruppenrichtlinien gesetzt und zusätzlich noch die Zeitsynchronisation zwischen Hyper-V-Host und VMs deaktiviert. Es gibt dazu unterschiedliche Meinungen im Internet, Letztendlich habe ich mich dazu entschieden, sie zu deaktivieren.

Das war richtig so  Sonst wird immer die falsche Zeit synchronisiert.

[NorbertFe 2.277]

Solange alle gleich falsch laufen ist das ja egal ;)

[AndreEx 0]

Am 9.8.2018 um 19:55 schrieb NilsK:

Moin,

 

als erstes korrigierst du die Zeitserver-Einstellungen:

 

https://www.gruppenrichtlinien.de/de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo/

 

Dann etwas abwarten und den Report neu erzeugen. Dann weitersehen.

 

Gruß, Nils

 

Hallo Nils,

 

ich bin totoal begeistert, weil die Anmeldeprobleme seitdem nicht wieder aufgetreten sind. Also nochmals tausend Dank!

 

Im dcdiag habe ich nur noch eine einzige Fehlermeldung:

 

******ANFANG******

      Starting test: SystemLog

         Fehler. Ereignis-ID: 0x00002720

            Erstellungszeitpunkt: 08/15/2018   10:35:02

            Ereigniszeichenfolge:

            Durch die Berechtigungseinstellungen für "Anwendungsspezifisch" wird dem Benutzer "NT-AUTORITÄT\SYSTEM" (SID: S-1-5-18) unter der Adresse "LocalHost (unter Verwendung von LRPC)" keine Berechtigung vom Typ "Lokal Aktivierung" für die COM-Serveranwendung mit der CLSID

         ......................... Der Test SystemLog für SERVERDC ist fehlgeschlagen.

******ENDE******

 

Durch ein anderes Forum bin ich auf die folgende Seite gekommen:

https://support.microsoft.com/de-de/help/4022522/dcom-event-id-10016-is-logged-in-windows-10-and-windows-server-2016

Dort steht, dass man diese Meldung ignorieren kann. Das werde ich auch erst einmal tun.

 

Nochmals herzlichen Dank für Eure super Unterstützung.

 

Ich markiere das Thema als erledigt.