Tags: Active Directory, Netzwerk, DNS, Troubleshooting, IPv6
Wenn man Tools wie die Gruppenrichtlinienverwaltung oder AD-Benutzer und -Computer öffnet, dann kann es vorkommen, dass diese die Domäne nicht finden. Verantwortlich dafür sind fast immer Netzwerkprobleme im Allgemeinen und solche mit DNS im Besonderen. Eine spezielle Rolle spielt dabei die IPv6-Konfiguration.
Ist man mit der Meldung konfrontiert, dass ein Programm sich nicht mit der Domäne verbinden kann, dann wird man erst ein paar naheliegende Ursachen ausschließen. Dazu gehört, dass man die Verfügbarkeit eines Domänen-Controllers prüft, etwa mit ping.
Ist dieser damit erreichbar, dann wirft man noch einen Blick in die hosts-Datei, ob hier möglicherweise ein ungültiger Eintrag für die Domäne oder einen DC enthalten ist. Passt bis hierher alles soweit, dann sollte man seine Aufmerksamkeit der DNS-Konfiguration zuwenden.
DNS-Server prüfen
Eine gängige Ursache für die fehlende Verbindung zu einem DC besteht darin, dass dem Rechner ein falscher (öffentlicher) DNS-Server zugeordnet ist. In diesem fehlen dann die SRV-Einträge für die DCs des Active Directory.
Mit Hilfe des Befehls
Test-NetConnection -TraceRoute <Name-der-Domäne>
kann man im ersten Schritt prüfen, ob sich der Namen der Domäne auflösen lässt.
Schlägt dieser Test fehl, dann lässt sich mit nslookup das Fehlen der erwähnten SRV-Einträge verifizieren. Dazu gibt man folgende Befehle ein:
nslookup
set type=all
_ldap._tcp.dc._msdcs.<DomainName>
quit
In der dritten Zeile muss man natürlich die eigene Domäne einsetzen. Wenn man explizit den PDC ansprechen möchte, dann gibt man dort
_ldap._tcp.pdc._msdcs.<DomainName>
ein.
Zugewiesene DNS-Server abfragen
Bestätigt sich hier der Verdacht, dass der Client einen falschen DNS-Server nutzt, dann prüft man den entsprechenden Eintrag in den IP-Einstellungen. Dies kann man etwa mit dem PowerShell-Cmdlet
Get-DnsClientServerAddress | Format-List
oder über
ipconfig /all
tun.
Herkunft der DNS-Konfiguration ermitteln
Sind hier nicht die richtigen DNS-Server eingetragen, dann muss man nun herausfinden, woher der Rechner diese Konfiguration bezieht. Dabei sollte man nicht nur die Konfiguration von IPv4 prüfen, sondern auch von IPv6.
Selbst wenn die IPv4-Einstellungen in Ordnung sind, kann die Domäne bei einer ungültigen IPv6-Einstellung für den DNS-Server nicht gefunden werden, weil Windows standardmäßig IPv6 bevorzugt.
Mit Hilfe der Befehle
netsh interface ipv4 show dnsservers
bzw.
netsh interface ipv6 show dnsservers
lässt sich feststellen, ob die DNS-Server manuell oder über DHCP zugewiesen wurden.
Alternativ steht dafür auch die GUI für die Adaptereinstellungen zur Verfügung.
DHCP-Konfiguration korrigieren
Liegt eine unzutreffende manuelle Konfiguration der DNS-Server vor, dann kann man diese an Ort und Stelle korrigieren. Bezieht das Interface seine Einstellung für die DNS-Server über DHCP, dann sollte man die Option 006 für den betreffenden IPv4-Bereich prüfen und falls nötig, gleich korrigieren.
Bei IPv6 ist der Fall etwas komplizierter, weil dort DHCP als Alternative zur manuellen Konfiguration nicht unbedingt nötig ist. Dort gibt es die Stateless Address Autoconfiguration (SLAAC), mit der sich die IPv6-Clients eine Grundkonfiguration selbst erstellen. Jeder Host bekommt dabei das globale Präfix und die IPv6-Adresse des DNS-Servers über den Router (RDNSS-Option).
Wenn man gerade in kleineren Netzwerken nicht auf eine Stateful Address Configuration wechseln will, um die IPv6-Konfiguration explizit zuzuweisen, dann besteht eine Lösung darin, IPv4 über IPv6 zu priorisieren.
Dazu muss man einen Schlüssel namens DisabledComponents in der Registry unter HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters anlegen. Am einfachsten speichert man dazu folgenden Code in einer Datei mit der Endung .reg und führt diese durch Doppelklick aus:
Microsoft rät hingegen davon ab, IPv6 zu deaktivieren, weil das die Funktionsfähigkeit des Systems beeinträchtigen könnte. Die Priorisierung von IPv4 sollte genügen, damit die Clients einen Domain Controller wieder erreichen können.
Zusammenfassung
In den meisten Fällen liegt der fehlenden Konnektivität zu einer AD-Domäne ein Netzwerkproblem zugrunde. Wenn man einige einfache Ursachen ausgeschlossen hat, etwa ob ein DC online ist, dann kann man sich an die Analyse der DNS-Konfiguration machen.
Ein falsch zugewiesener DNS-Server ohne SRV-Einträge für die DCs kann sich dann als Übeltäter erweisen. Es reicht nicht, wenn die IPv4-Einstellungen in Ordnung sind, weil Windows IPv6 bevorzugt. In diesem Fall hilft es, IPv4 über IPv6 zu priorisieren.
Täglich Know-how für IT-Pros mit unserem Newsletter
Verwandte Beiträge
Weitere Links
3 Kommentare
ich hatte das heute in meinem Lab weil ich der MS Empfehlung folge und IPv6 nicht deaktiviere. Da es präferiert genutzt wird, kam es zum malheur.
Also dank ISP nun doch erstmal IPv6 deaktivieren da sonst natürlich über diese Public Adressen kein internes DNS funktionierte.
Danke fuer diese 'Bestaetigung'. In der Tat scheint das 'Problem' mit IPv6 (DNS) noch haeufiger bei MS Windows 11 aufzutreten, weswegen wir es (pauschal) ueberall erst mal 'deaktiviert' haben. Vielen Dank fuer den Hinweis. Ich dacht' schon, ich/wir sei/en meschugge... :-)
Gerne Olaf, ich werde versuchen das mit dem Windows Server Team zu klären. Technisch ist das erklärbar, IPv6 wird bevorzugt vor IPv4 genutzt. Es scheint jedoch kein Fallback zu passieren. In der Praxis ist es jedoch mit Dual Stack Technologien wie DS-Lite schlecht vereinbar.