Active Directory

Der falsche Anmeldeserver und Netlogon 5719

Der falsche Anmeldeserver und Netlogon 5719

Ausgangssituation

Active Directory Umgebung mit einem zentralen (Hub) Standort und mehreren Aussenstandorten (Spoke).
Domänenfunktionsebene: Windows Server 2008 R2
Domänencontroller: Windows Server 2012
Clients: Windows 7 x86 SP1

 

Problembeschreibung

Der Anwender startet seinen Rechner an dem zenralen Standort, meldet sich an und merkt, dass die Anmeldung langsam ist. Der Anmeldeserver des Computers wird geprüft (echo %logonserver%) und man stellt fest, dass dieser Domänencontroller an einem entfernten Standort liegt.
Nach einem Neustart des betroffenen Clients wird festgestellt, dass der Client einen korrekten Anmeldeserver (aus dem zentralen Standort, Name: Headquarters) ausgewählt hat.

 

Theorie

Wie genau der Client seinen Anmeldeserver findet, wird in vielen Artikeln erklärt. Hier kurz die wichtigste Information aus KB314861 und dem folgenden Blog:

  1. Client does a DNS search for DC’s in _LDAP._TCP.dc._msdcs.domainname
  2. DNS server returns list of DC’s.
  3. Client sends an LDAP ping to a DC asking for the site it is in based on the clients IP address (IP address ONLY! The client’s subnet is NOT known to the DC).
  4. DC returns…
  5. The client’s site or the site that’s associated with the subnet that most matches the client’s IP (determined by comparing just the client’s IP to the subnet-to-site table Netlogon builds at startup).
  6. The site that the current domain controller is in.
  7. A flag (DSClosestFlag=0 or 1) that indicates if the current DC is in the site closest to the client.
  8. The client decides whether to use the current DC or to look for a closer option.
  9. Client uses the current DC if it’s in the client’s site or in the site closest to the client as indicated by DSClosestFlag reported by the DC.
  10. If DSClosestFlag indicates the current DC is not the closest, the client does a site specific DNS query to: _LDAP._TCP.sitename._sites.domainname (_LDAP or whatever service you happen to be looking for) and uses a returned domain Controller.

 

Troubleshooting

  • Der Wert des nachfolgenden Registrierungsschlüssels wurde überprüft, um herauszufinden, ob der Client den richtigen Standort zugewiesen bekommen hat.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Netlogon\Parameters\DynamicSiteName

Das war auch der Fall:

HQ

 

  • Das Systemlog des betroffenen Clients wurde analysiert und man konnte Folgendes daraus erkennen:

Die erste Anmeldung erfolgte gegen 06.45 morgens. Bei dieser wurden zwei Ereignisse geloggt, die im Zusammenhang mit dem Fehlverhalten stehen:

Log Name:     System
Source:       NETLOGON
Date:         12.11.2014 06:45:31
Event ID:     5719
Level:         Error
Description:
This computer was not able to set up a secure session with a domain controller in domain CONTOSO due to the following:
There are currently no logon servers available to service the logon request.
This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.

und

Log Name:     System
Source:       Microsoft-Windows-DNS-Client
Date:         12.11.2014 06:45:31
Event ID:     1014
Level:         Warning
User:         NETWORK SERVICE
Description:
Name resolution for the name _ldap._tcp.dc._msdcs.contoso.com timed out after none of the configured DNS servers responded.

 

Eine Recherche im Internet zeigt, dass mit grosser Wahrscheinlichkeit dieses Fehlverhalten in Folge von Netzwerkproblemen auftaucht:

Event 5719:
Event ID 5719 is logged when you start a Domain Member
https://support.microsoft.com/kb/938449/en-us

Auszug aus dem Artikel:

“This issue may occur for any of the following reasons:
– You are using a Gigabit network adapter and the Netlogon service starts before the network is ready.
– Solutions that verify the health of the new network member delay the network connection and your ability to access domain controllers. If you have an automatic Direct Access channel connection enabled, this may also require more time to perform than Netlogon allows.
– The 802.1X authentication process delays connections to the domain controllers.
– The client experiences a delay to retrieve an IP address from the DHCP server. This delays the display of the network interface.”

 

Event 1014:
Event ID 1014: Microsoft Windows DNS Client
https://social.technet.microsoft.com/wiki/contents/articles/3336.event-id-1014-microsoft-windows-dns-client.aspx

Auszug aus dem Artikel:

“Customers have reported the following scenarios as possible causes for this event:
– TCP/IP Offload is enabled for a network adapter
– TCP/IP v6 is enabled and their ISP does not yet support TCP/IP v6.
– The spanning tree “portfast” setting is not enabled on your servers switch ports.
– Router and PC communicating on different channel or standard.”

 

  • Da ein DHCP-Problem eine der möglichen Ursachen ist (siehe oben: „The client experiences a delay to retrieve an IP address from the DHCP server.”), wurde der Status der aktuellen DHCP-Lease des Benutzers überprüft. Es wurden keine Probleme festgestellt.

 

  • Es konnte kein tieferes Troubleshooting gemacht werden, da die Protokollierung des Netlogons standardmässig nicht eingeschaltet ist. Die weiteren Troubleshooting-Schritte bzw. Datensammlung sollten dann erfolgen, wenn das Problem aktuell besteht.

 

  • Im Anschluss wurde die Protokollierung des Anmeldedienstes gemäss dem folgenden Artikel aktiviert:

Enabling debug logging for the Net Logon service
https://support.microsoft.com/kb/109626

„As an alternate method, you can set the dbflag without using the registry. To do this run the following command from a command prompt:

nltest /dbflag:0x2080ffff

After you finish debugging, you can run the nltest /dbflag:0x0 command from a command prompt to reset the debug flag to 0.“

 

  • Die Logdatei “Netlogon.log” wurde analysiert und es wurde zum Zeitpunkt des Fehlverhaltens festgestellt, dass keine Namensauflösung für die Zone _ldap._tcp.Headquarters._sites.dc._msdcs.contoso.com möglich ist. Hier Auszug aus dem Log:

Der Anmeldedienst auf dem Client erkennt bei der Initialisierung anhand der Informationen in der Registrierung richtig, dass der Standort „Headquarters“ ist:

11/24 06:59:55 [INIT]   SiteName (1) = Headquarters
11/24 06:59:55 [SITE] Setting site name to ‘Headquarters’

 

Die Domäne wird auch richtig erkannt:

 

11/24 06:59:55 [DNS] Set DnsForestName to: CONTOSO:COM
11/24 06:59:55 [DOMAIN] CONTOSO: Adding new domain
11/24 06:59:55 [DOMAIN] Setting our computer name to CONWS02 CONWS02.contoso.com
11/24 06:59:55 [DOMAIN] Setting Netbios domain name to CONTOSO
11/24 06:59:55 [DOMAIN] Setting DNS domain name to contoso.com.
11/24 06:59:55 [DOMAIN] Setting Domain GUID to e0CONTOSO-a812-2b97-9661-6288496dd251

 

Als Nächstes versucht der Anmeldedienst einen SRV-Eintrag in der entsprechenden Zone (Headquarters) aufzulösen:

 

11/24 07:00:07 [CRITICAL] NetpDcGetDcNext: _ldap._tcp.Headquarters._sites.dc._msdcs.contoso.com.: Cannot Query DNS. 1460 0x5b4
11/24 07:00:07 [CRITICAL] NetpDcGetNameIp: contoso.com.: No data returned from DnsQuery.
11/24 07:00:07 [MISC] NetpDcGetName: NetpDcGetNameIp returned 1355

 

Zwei Fehlermeldungen sind bei der fehlgeschlagenen Namensauflösung zu sehen:

 

  • Cannot Query DNS. 1460 0x5b4

Wenn man diese mit „net helpmsg„ auflöst erhält man:

0x5b4 = 1460 = „This operation returned because the timeout period has expired“

Untitled

 

  • Die zweite Fehlermeldung erscheint infolge von der fehlschlagenden DNS-Namensauflösung:

1355 = „The specified domain either does not exist or could not be contacted“

Untitled2

 

Exakt zum selben Zeitpunkt werden auch die oben erwähnten Events(Warnung, DNS Client Event 1014 und Fehler, NETLOGON 5719) auf dem betroffenen Client geloggt:

Capture

 

Der NETLOGON-Fehler wird von dem Dienst auch im Log vermerkt:

 

11/24 07:00:11 [MISC] Eventlog: 5719 (1) “CONTOSO” 0xc000005e 7f14dcc8 6c48a92f f9c5d616 c111129e   …./.Hl……..
11/24 07:00:11 [SESSION] CONTOSO: NlSetStatusClientSession: Set connection status to c000005e
11/24 07:00:11 [SESSION] CONTOSO: NlSessionSetup: Session setup Failed

 

Der Anmeldedienst versucht weiterhin für mehr als eine Minute den Namen eines Domänencontrollers aufzulösen. Dabei wird versucht irgendeinen Domänencontroller in der Domäne aufzulösen, was auch nicht funktioniert:

 

11/24 07:00:07 [CRITICAL] NetpDcGetDcNext: _ldap._tcp.Headquarters._sites.dc._msdcs.contoso.com.: Cannot Query DNS. 1460 0x5b4
11/24 07:00:07 [CRITICAL] NetpDcHandlePingResponse: contoso.com.: Failed DNS resolution for CONNY01.contoso.com (none): 0x5b4
11/24 07:00:07 [CRITICAL] NetpDcGetDcNext: _ldap._tcp.Headquarters._sites.dc._msdcs.contoso.com.: Cannot Query DNS. 1460 0x5b4
11/24 07:00:07 [CRITICAL] NetpDcHandlePingResponse: contoso.com.: Failed DNS resolution for CONWS01.contoso.com (none): 0x5b4
11/24 07:00:07 [CRITICAL] NetpDcGetDcNext: _ldap._tcp.Headquarters._sites.dc._msdcs.contoso.com.: Cannot Query DNS. 1460 0x5b4
11/24 07:00:07 [CRITICAL] NetpDcHandlePingResponse: contoso.com.: Failed DNS resolution for CONDK01.contoso.com (none): 0x5b4

 

Das Problem mit der Namensauflösung dauert genau bis 11/24 – 07:01:34 Uhr. Zu dieser Zeit ist das Problem, das die Namensauflösung verhindert, behoben und der Anmeldedienst kann den Namen des nächsten, per Zufall ausgewählten Domänencontrollers, auflösen und versucht eine Sitzung aufzubauen:

 

11/24 07:01:34 [MISC] NetpDcHandlePingResponse: contoso.com.: Successful DNS resolution for CONMO01.contoso.com (none)
11/24 07:01:34 [MISC] DsGetDcName function returns 0: Dom:(null) Acct:(null) Flags: IP TIMESERV AVOIDSELF BACKGROUND
11/24 07:01:34 [SESSION] CONTOSO: NlSessionSetup: Try Session setup

 

Danach wird die Sitzung zum Domänencontroller erfolgreich aufgebaut:

 

11/24 07:01:34 [PERF] NlAllocateClientSession: New Perf Instance (000000000041B4B8): “\\CONMO01”
ClientSession: 000000000129D780

 

Die Frage an der Stelle ist „Warum funktioniert die DNS-Auflösung während der Zeit (07:00:07 – 07:01:34) nicht?“

 

Diese Frage wird beantwortet wenn man das Systemlog des betroffenen Clients zu dem gleichen Zeitpunkt (07:01:34) genauer untersucht. Was passiert zu dieser Uhrzeit, dass die Namensauflösung wieder funktioniert?

Hier der Screenshot vom Eventlog:

Capture2

Man sieht, dass zu diesem Zeitpunkt, genau gegen 07:01:34, diverse Dienste auf dem Client initialisiert und gestartet werden.
Wenn man diese einzeln kontrolliert sieht man, dass der folgende Dienst auch dabei ist:

 

Network List Service

Capture3

 

Dieser Dienst ist einer der kritischen Netzwerkdienste ohne den das Netzwerk nicht vollständig initialisiert ist:

Capture4

 

 

Ergebnis

Also das eigentliche Problem ist, dass das Netzwerk auf dem betroffenen Client zu spät initialisiert wird. Bis das nicht der Fall ist, kann auch keine Namensauflösung stattfinden.
Dass es hier um ein Netzwerkproblem geht, kann man herausfinden, wenn man die Ursachen für die beiden Events in den o.g. Artikel liest:

 

Event 5719:
Event ID 5719 is logged when you start a Domain Member
https://support.microsoft.com/kb/938449/en-us

Auszug aus dem Artikel:

“This issue may occur for any of the following reasons:

– You are using a Gigabit network adapter and the Netlogon service starts before the network is ready.
– Solutions that verify the health of the new network member delay the network connection and your ability to access domain controllers. If you have an automatic Direct Access channel connection enabled, this may also require more time to perform than Netlogon allows.
– The 802.1X authentication process delays connections to the domain controllers.
– The client experiences a delay to retrieve an IP address from the DHCP server. This delays the display of the network interface.”

 

Event 1014:
Event ID 1014: Microsoft Windows DNS Client
http://social.technet.microsoft.com/wiki/contents/articles/3336.event-id-1014-microsoft-windows-dns-client.aspx

Auszug aus dem Artikel:

“Customers have reported the following scenarios as possible causes for this event:
– TCP/IP Offload is enabled for a network adapter
– TCP/IP v6 is enabled and their ISP does not yet support TCP/IP v6.
– The spanning tree “portfast” setting is not enabled on your servers switch ports.
– Router and PC communicating on different channel or standard.”

 

Empfohlene Aktionen

Es existierten unterschiedliche Ursachen für dieses Fehlverhalten und somit auch unterschiedliche Lösungen. Um die exakte Ursache in dem Fall zu bestimmen, muss man der Reihe nach die Möglichkeiten ausschliessen, indem man nach jeder Aktion Tests durchführt bis das Problem nicht mehr auftaucht:

 

1. Netzwerkkartentreiber aktualisieren

 

2. Die erweiterten TCP/IP-Funktionalitäten auf dem Clients mit den folgenden Befehlen deaktivieren:

netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
£
netsh interface tcp set global autotuning=disabled
netsh int tcp set heuristics disabled
netsh int tcp set global congestionprovider=ctcp

Was Microsoft dazu sagt:

TCP Offloading/Chimney & RSS…What is it and should I disable it?
https://blogs.technet.com/b/onthewire/archive/2014/01/21/tcp-offloading-chimney-amp-rss-what-is-it-and-should-i-disable-it.aspx

 

3. Kerberos über TCP erzwingen

How to force Kerberos to use TCP instead of UDP in Windows
https://support.microsoft.com/kb/244474/en-us

 

4. Deaktivieren der Funktion “Media Sense” für TCP/IP

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
Value Name: DisableDHCPMediaSense
Data Type: REG_DWORD
Value Data: 1
Value Range: Boolean (0=False, 1=True)
Default: 0 (False)

Beachten Sie dabei, dass der Key “DISABLEDhcpMediaSense” heisst, also muss man den Wert 1 (True) konfigurieren.

 

5. Den Anmeldedienst auf “Delayed Start” konfigurieren.

How to delay loading of specific services
https://support.microsoft.com/kb/193888/en-us

oder den Vorschlag aus dem folgenden Artikel implementieren und den Anmeldedienst dazu zwingen auf die Antwort des Domänencontrollers abzuwarten:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters
Value Name: ExpectedDialupDelay
Data Type: REG_DWORD
Data Value is in seconds (default=0)
Data Range is between 0 and 600 seconds (10 minutes)

 

6. Die restlichen Vorschläge aus dem folgenden Artikel können auch hilfreich sein

Event ID 5719 is logged when you start a Domain Member
https://support.microsoft.com/kb/938449/en-us

 

 

Linksammlung mit hilfreichen Links

Event ID 5719 is logged when you start a Domain Member
https://support.microsoft.com/kb/938449/en-us

Finding a Domain Controller in the Closest Site (DsGetSiteName API)
https://technet.microsoft.com/en-us/library/cc978016.aspx

How DNS Support for Active Directory Works
https://technet.microsoft.com/en-us/library/cc759550%28v=ws.10%29.aspx

Domain Controller Locator : an overview
https://blogs.technet.com/b/arnaud_jumelet/archive/2010/07/05/domain-controller-locator-an-overview.aspx

Windows 7 und TCP/IP-Optimierungen
https://blog.knecht-ruprecht.info/2011/07/windows-7-und-tcpip-optimierungen.html

TCPChimney und Receive Side Scaling (RSS) und Network Direct Memory Access
https://www.msxfaq.de/verschiedenes/tcpchimney_und_rss.htm

TCP Offloading/Chimney & RSS…What is it and should I disable it?
https://blogs.technet.com/b/onthewire/archive/2014/01/21/tcp-offloading-chimney-amp-rss-what-is-it-and-should-i-disable-it.aspx

Netlogon 5719 and the Disappearing Domain [Controller] https://blogs.technet.com/b/instan/archive/2008/09/18/netlogon-5719-and-the-disappearing-domain.aspx

 

 

 

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.