Domänenmitglieder schlagen bei der Authentifizierung fehl, wenn der Domänencontroller heruntergefahren wird

  • Artikel

In diesem Artikel wird ein Problem behoben, bei dem die Anwendung Benutzer nicht authentifizieren kann, wenn Sie einen Domänencontroller (DC) herunterfahren.

Gilt für: Fenster 10 – alle Editionen, Windows Server 2012 R2

Ursprüngliche KB-Nummer: 2683606

Symptome

Die Anwendungen in der Domäne verwenden NT Local Area Network Manager (NTLM) oder Kerberos , um Benutzer zu authentifizieren. Einige Anwendungen weisen ein Muster auf, bei dem die Clients häufig wieder eine Verbindung mit dem Anwendungsserver herstellen.

Anwendungen sind hauptsächlich betroffen, wenn sie NTLM verwenden. Anwendungen, die Kerberos verwenden, können ebenfalls betroffen sein, wenn die Überprüfung des Kerberos-Berechtigungsattributzertifikats (PAC) für von der Anwendung akzeptierte Authentifizierungen verwendet wird. Es ist nicht möglich, diese Überprüfungen in allen Fällen zu deaktivieren.

Wenn Sie in diesem Fall einen Domänencontroller herunterfahren, authentifiziert die Anwendung benutzer möglicherweise erst, wenn der Domänencontroller im Netzwerk nicht reagiert und das Domänenmitglied einen anderen Domänencontroller für die Authentifizierung ausgewählt hat.

In den Diagnoseprotokollen und Netzwerkablaufverfolgungen werden möglicherweise Anmeldefehler bei Benutzeranmeldungsfehlern oder der Fehler 0xc0000064 STATUS_NO_SUCH_USER angezeigt, in dem Das angegebene Konto ist nicht vorhanden angezeigt wird. Wenn Sie Kerberos verwenden, wird möglicherweise Fehler 6, KDC_ERR_C_PRINCIPAL_UNKNOWN angezeigt.

Ursache

Es können zwei Probleme auftreten:

  1. Wenn sich der Domänencontroller in der Herunterfahrphase befindet, werden aktuelle Clients normalerweise angewiesen, einen anderen Domänencontroller für die Authentifizierung zu verwenden, indem der Fehlercode 0xc00000dc (STATUS_INVALID_SERVER_STATE) verwendet wird. Es gibt einen Codepfad, in dem dieses Problem nicht auftritt.

  2. Der Server vermeidet nicht, auf neue Clients in UDP-Abfragen (User Datagram Protocol) von Netlogon zu reagieren. Außerdem vermeiden die Clients, die den Fehler erhalten haben, dass sich der DC im Herunterfahren befindet, nicht, denselben DC bei der späteren DC-Suche auszuwählen.

Wenn ein Client den DC während des Herunterfahrens auswählt, schlagen NTLM- oder Kerberos-Anforderungen erneut fehl. An diesem Punkt wechselt der Client in einen negativen Cachemodus und schlägt bei späteren Authentifizierungsanforderungen fehl.

Im Fall von NTLM ist der Client der Anwendungsserver, sodass er neue Clients erst akzeptieren kann, wenn ein funktionierender Domänencontroller ausgewählt wurde.

Lösung

Um das Problem zu vermeiden, beenden Sie den Netlogon-Dienst auf dem DC, bevor Sie das Herunterfahren oder neu starten. Um diese Aktion zu automatisieren, geben Sie den Stopptask in ein lokales Herunterfahren-Skript für den Domänencontroller ein. Führen Sie die folgenden Schritte aus, um zur lokalen Gruppenrichtlinie zu gelangen:

  1. Gpedit.msc starten

  2. Öffnen Sie die Struktur Einstellungen , und navigieren Sie zu Computerkonfiguration > Windows Einstellungen > Skripts > Herunterfahren.

  3. Geben Sie in der neuen Skriptbefehlszeile ein net stop netlogon && net stop kdc.

Obwohl Sie den Registrierungsparameter NegativeCachePeriod auf einen niedrigen Wert festlegen können, wird das Problem durch diese Änderung nicht vollständig vermieden, da der Client häufiger nach einem alternativen Domänencontroller sucht.

Weitere Informationen

Im Netlogon.log des Clients wird der Fehlercode angezeigt, der vom Domänencontroller STATUS_INVALID_SERVER_STATE wird:

<Date><Time> [CRITICAL] NlPrintRpcDebug: EEInfo konnte für I_NetLogonSamLogonEx nicht abgerufen werden: 1761 (kann für 0xc00000dc legitim sein)
<Date><Time> [CRITICAL]<-Domäne>: NlpUserValidateHigher: Zugriff nach status verweigern: 0xc00000dc 0
<Date><Time> [SESSION]<-Domäne>: NlSetStatusClientSession: Festlegen der Verbindung status auf c00000dc
<Date><Time> [SESSION] <domain>: NlSetStatusClientSession: Unbind from server \\<dc-name1>.<Domänen-FQDN> (TCP) 1.

Die Ergebnisse, wenn der Client versucht, den DC beim Herunterfahren als einer der DCs zu verwenden:

<Date><Time> [SESSION] <-Domäne>: NlSessionSetup: Sitzungseinrichtung ausprobieren
<Date><Time> [SESSION] <-Domäne>: NlDiscoverDc: Synchrone Ermittlung starten
<Date><Time> [MISC] NetpDcInitializeContext: DSGETDC_VALID_FLAGS ist c01ffff1
<Datum></Uhrzeit> [MAILSLOT] NetpDcPingListIp: <Domäne>: UDP-Ping an 10.10.103.87 gesendet
<Date><Time> [SESSION] NETLOGON_CONTROL_TC_QUERY Funktion empfangen.
<Datum><Uhrzeit> [MAILSLOT] NetpDcPingListIp: <Domäne>: UDP-Ping an 10.10.103.93 gesendet
<Datum><Uhrzeit> [MAILSLOT] NetpDcPingListIp: <Domäne>: UDP-Ping an 10.10.103.92 gesendet

Der zweite Ping wird beim Herunterfahren an den DC gesendet.

Der DC antwortet, obwohl er den Fehler bereits an den Client zurückgegeben hat:

<Date><Time> [LOGON] HM-REBOOT: SamLogon: Transitive Network logon of <domain>\test1 from HM-REBOOT-SRV1 (via HM-REBOOT-SRV1) Entered
<Date><Time> [LOGON] HM-REBOOT: SamLogon: Transitive Network logon of <domain>\test1 from HM-REBOOT-SRV1 (via HM-REBOOT-SRV1) Returns 0xC00000DC
...
<Datum><Uhrzeit> [MAILSLOT] Empfangener Ping von HM-REBOOT-SRV1 <\domain> (NULL) auf UDP LDAP
<Date><Time> [MAILSLOT] <domain>: Ping response 'Sam Logon Response Ex' (NULL) to \\<member server> Site: Default-First-Site-Name on UDP LDAP
<Date><Time> [MAILSLOT] <domain>: Ping response 'Sam Logon Response Ex' (NULL) to \\<member server> Site: Default-First-Site-Name on UDP LDAP

Nächste Schritte

Referenz für "NegativeCachePeriod":