Öffentliches DNS funktioniert – heißt aber nicht, dass Active Directory auffindbar ist

Das VPN verbindet sich, der Browser öffnet eine öffentliche Seite, und der Laptop kann sich trotzdem nicht an der Domäne anmelden. Der übliche Schluss ist, dass DNS in Ordnung ist, weil Namen aufgelöst werden. Er ist nicht in Ordnung, und der Grund ist, dass ein Browsertest nur eine Abfrage aus einer Kette prüft, die ein domänenangemeldeter Client benötigt. Die Domänenerkennung fragt zuerst nach Diensteinträgen, dann nach den Adressen der Controller, die diese Einträge benennen, und dann nach einer Route zu den Ports, auf denen diese Controller lauschen. Eine öffentliche Antwort erfüllt keinen dieser Schritte.

Der Mythos: Namen werden aufgelöst, also ist DNS erledigt

Dass eine öffentliche Seite aufgelöst wird, sagt nur, dass irgendein Resolver eine A- oder AAAA-Abfrage für einen Namen in einer öffentlichen Zone beantwortet hat. Active Directory nutzt dasselbe Protokoll für eine andere Frage: Wo sind die Dienste der Domäne, und welchen Controller soll dieser Client verwenden. Die Frage wird als SRV-Einträge unter einer nach der Domäne benannten Zone ausgedrückt, und ein rekursiver öffentlicher Resolver hat keinen Grund, sie zu halten.

Fehlt der Eintrag, gibt der Resolver eine negative Antwort zurück, was eine gültige DNS-Antwort und kein Ausfall ist. Der Client greift dann auf zwischengespeicherte Controller-Informationen zurück, falls er welche hat, und genau deshalb kann ein Desktop stundenlang gut aussehen und nach einem Neustart oder einer Passwortänderung scheitern.

Was ein Domänenclient tatsächlich fragt, der Reihe nach

Für eine Domäne wie corp.example lautet die allgemeine Locator-Abfrage _ldap._tcp.dc._msdcs.corp.example. Die SRV-Antworten benennen mögliche Controller und ihre Ports, und danach braucht der Client Adresseinträge für diese Hostnamen, bevor er eine Verbindung öffnen kann. Die standortbewusste Erkennung fügt Abfragen unter der Standort-Subdomäne hinzu, und die Antworten bestimmen, welche Controller bevorzugt werden, nicht welcher zwingend ist.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

Folgen Sie der Kette in dieser Reihenfolge, aus dem Netz, in dem das Problem auftritt. Ein Hostname, der zu einer nicht erreichbaren Adresse aufgelöst wird, ist ein Routingfehler, kein DNS-Fehler. Ein erreichbarer Controller, dessen Locator-Einträge fehlen, ist ein DNS-Fehler, kein Routingfehler. Beide erzeugen ähnliche Benutzerbeschwerden und völlig unterschiedliche Reparaturen.

Warum ein öffentlicher Resolver antwortet und die Anmeldung trotzdem bricht

Wenn der Adapter dem Client einen öffentlichen Resolver gibt, funktionieren öffentliche Namen und der interne Namensraum nicht. Einen zweiten öffentlichen Resolver hinzuzufügen hilft nicht, weil keiner von beiden die Zone hält. Auch die übliche Liste „intern zuerst, öffentlich danach“ verhält sich nicht wie eine Regel pro Domäne: Eine negative Antwort des ersten Servers ist eine legitime Antwort, und der Client versucht den zweiten Server nicht erneut, nur weil die Antwort leer war.

Beide internen Resolver, falls Sie zwei betreiben, müssen den AD-Namensraum halten und aus dem aktuellen Netz des Clients erreichbar sein. Genau das brechen Split-Tunnel-Designs: Das VPN kann das Tunnel-Subnetz tragen, während der interne Resolver auf einem Präfix sitzt, das der Tunnel nicht routet, sodass die Abfrage bei einem Resolver landet, der sie nicht beantworten kann.

Windows wendet außerdem eine Namensauflösungsrichtlinie an, die bestimmte Namensräume an bestimmte Server leiten kann, und die vom Adapter angezeigten DNS-Adressen sind nicht die ganze Geschichte. Die Adapterliste zu ändern, ohne diese Richtlinie zu ändern, kann die effektive Konfiguration unberührt lassen, und deshalb hat eine Reparatur, die angewendet aussieht, keine Wirkung.

Halten Sie DNS und Routen des Tunnels im Einklang

Ein VPN-Profil, das einen Resolver, aber nicht das ihn enthaltende Präfix pusht, erzeugt einen Resolver, den der Client nicht erreichen kann; eines, das das Präfix ohne Resolver pusht, lässt den Client den lokalen fragen. Behandeln Sie das Paar als ein Konfigurationselement, und prüfen Sie beide nach jeder Profiländerung, weil ein umsortierter Push oder eine neue Split-Tunneling-Richtlinie sie trennen kann.

Prüfen Sie auch, was der Client mit der gepushten Einstellung tut. Manche Clients wenden den DNS-Server nur auf die Tunnelschnittstelle an und lassen den Resolver des physischen Adapters stehen, sodass der Gewinner von der Schnittstellenmetrik und dem abgefragten Namen abhängt. Kommt die interne Antwort nur, wenn der physische Adapter deaktiviert ist, ist das der zu reparierende Mechanismus, nicht die Domäneneinträge.

Abnehmen mit einem Erkennungsaufruf und einer echten Operation

Ein brauchbarer Abnahmetest führt die Locator-Abfrage aus und vollzieht dann eine echte authentifizierte Operation, etwa das Öffnen einer verzeichnisgestützten Freigabe oder das Anfordern eines Tickets. Tun Sie das vor dem VPN-Übergang und erneut danach, auf derselben Maschine, ohne Neustart dazwischen. Zwischengespeicherte Anmeldedaten und bereits offene Sitzungen lassen einen kaputten Pfad nur zu gern gesund aussehen, deshalb ist eine erfolgreiche Desktop-Anmeldung nicht der Test.

Die DNS-Client-Empfehlungen von Microsoft ziehen dieselbe Grenze zwischen dem Auflösen des internen Namensraums und dem Weiterleiten öffentlicher Abfragen stromaufwärts, und das ist die Anordnung, die beim Einführen eines VPN erhalten bleiben muss.

Ist die Störung nur langsam statt fehlgeschlagen, halten Sie die Verzögerung von der Diagnose getrennt. Eine Zeitüberschreitung während der Erkennung kann von einem nicht erreichbaren Controller, einem blockierten Port oder einem Resolver kommen, der spät antwortet, und nichts davon beweist das Warten allein. Erfassen Sie die tatsächliche Abfrage, ihre Antwort und den Verbindungsversuch, bevor Sie eine Resolver-Einstellung ändern.