Sie betreuen ein über mehrere Standorte verteiltes Active Directory? Sinnigerweise halten Sie dann in jedem (größeren) Standort einen (oder mehrere) Domain Controller vor, um die Benutzer nicht über WAN Verbindungen authentifizieren zu müssen. Soweit so gut. Wenn Sie aber nicht dem jeweiligen Standort auch die jeweiligen Subnetze zu ordnen, können Sie sich eigentlich auch die Erstellung der Standorte sparen. Logischerweise weiß zwar ein Client welche IP er hat, aber nicht in welchen Teil der Welt er sich befindet.

Nehmen wir mal an, Sie betreiben Ihren zentralen Standort in Frankfurt, eine Außenstelle in Tokio und eine in Seattle. Ihr gesamtes Netzwerk besteht aus einem Class A (10.0.0.0) Netz. In Frankfurt ist das Subnetz 10.10.10.0/24, in Tokio das Subnetz 10.10.20.0/24 und in Seattle das Subnetz 10.10.30.0/24 aktiv.

Die Konfiguration Ihrer Standorte sieht so aus:

Es sollte Ihnen auffallen, dass für den Standort Seattle kein Subnetz definiert ist. In Seattle steht zwar ein DC, der die Anmeldungen, etc. schnell verarbeiten kann, viele der vorhandenen Clients werden diesen aber ignorieren.

Ein Client, der Domain Member ist, fragt seinen konfigurierten DNS nach einem Domaincontroller, der in authentifizieren kann. Der DNS (und das kann natürlich der lokal vorhandene in Seattle sein) gibt einen in Frage kommenden DC zurück. Da das Netz des Clients keinem Standort zugeordnet ist, kann das auch ein DC in Tokio sein. Das bedeutet, der Client in Seattle würde den Weg über Frankfurt nach Tokio wählen, um sich zu authentifizieren. Wenn nun Logonscripts etc. konfiguriert sind, kann dann die Anmeldung schon mal einige Zeit dauern.

Wenn ein Client in Tokio versucht sich zu authentifizieren, erhält er nur den DC in Tokio, weil seine IP ja einem Standort zugeordnet ist.

Fügen Sie das Subnetz aus Seattle einfach dem Standort Seattle hinzu und das Problem ist gelöst.

Tipp:

Bei einem Kunden, der weltweit über 25 Standorte betreibt, hatte ich das Problem, dass in einigen Standorten lokale Admins immer wieder Netze kreierten, in denen dann Clients waren, die in die Domäne gejoined wurden. Diese Netze waren aber nie den jeweiligen Standorten zu geordnet. Somit kam es häufig zu Beschwerden wegen verzögerter Authentifizierungen und ähnlichem.

Um heraus zu finden, welche Netze und Clients von so etwas betroffen sind, hilft Ihnen die entsprechende Log Datei. Diese finden Sie auf jedem DC unter %SystemRoot%\debug\netlogon.log. IP Adressen können da auch mehrfach erscheinen, weil bei jedem Zugriff auf einen DC ein Eintrag geschrieben wird. Die Datei ist nach folgendem Muster aufgebaut:

12/15 10:37:54 Domain: NO_CLIENT_SITE: Clientname 10.30.0.12
12/15 10:37:54 Domain: NO_CLIENT_SITE: Clientname 10.30.0.15
12/15 10:37:56 Domain: NO_CLIENT_SITE: Clientname 10.30.0.34
12/15 10:37:54 Domain: NO_CLIENT_SITE: Clientname 10.30.0.15
12/15 10:37:54 Domain: NO_CLIENT_SITE: Clientname 10.30.0.12
12/15 10:37:54 Domain: NO_CLIENT_SITE: Clientname 10.30.0.15
12/15 10:37:54 Domain: NO_CLIENT_SITE: Clientname 10.30.0.15

Wenn nun, wie im Falle meines Kunden, ein richtiger Wildwuchs ensteht, fragen Sie am besten alle DCs weltweit (in regelmäßigen Abständen) nach Ihren Eintragungen in der netlogon.log ab. Dabei hilft Ihnen das folgende PowerShell Script.

$DCs = Get-ADDomainController -Filter *

$IPs = $DCs | % {$DC=$_.name ; import-csv (“\\”+$DC+”\c$\Windows\Debug\netlogon.log”) -Delimiter ” ” -Header “Date”,”Time”,”Domain”,”Hostname”,”Site”,”IP”}

$IPs | select IP – unique

Als Ergebnis erhalten Sie nur noch die IP Adressen, die betroffen sind:

IP
—
10.30.0.12
10.30.0.15
10.30.0.34

Sollte nun die Fehlkonfiguration der Standorte und der zugehörigen Subnetze behoben sein, macht es Sinn, die netlogon.log weltweit zu leeren, um an der Stelle sauber zu sein. Dazu verwenden Sie das CMDLet Clear-Content. Da die netlogon.log vom NETLOGON Service gebunden ist, müssen Sie diesen vorher stoppen und anschließend wieder starten.

$DCs | % {$DC=$_.name ; Get-Service -ComputerName $DC netlogon |Stop-Service ; clear-content (“\\”+$DC+”\c$\Windows\Debug\netlogon.log”) ; Get-Service -ComputerName $DC netlogon | Start-Service}