Direct Access Namensauflösung - NRPT

Da bei Direct Access der Clients quasi sowohl "intern" als auch im Internet ist, muss natürlich die Namensauflösung diesen Umstand berücksichtigen. Es ist also nicht hilfreich, wenn der PC weiter nur die "Internet"-DNS-Server befragt. Fragt er aber nur die internen DNS-Server der Firma, dann müssen diese natürlich auch eine externe Auflösung zulassen. Es gibt aber auch den Bedarf eines "geteilten" Namensraums, bei dem der Client z.B. nur interne Namen gegen die internen DNS-Server auflöst aber für alle übrigen Anfragen weiter das Internet nutzt.

NRPT - Name Resolution Policy Table

Ich vermute mal, dass die wenigsten Administratoren sich bisher überhaupt um diese Funktion in Windows gekümmert haben. Direct Access ist die erste bekannte Anwendung, die damit aktiv arbeitet. Aber wenn Sie einmal verstanden haben, was NRPT leisten kann, dann werden Sie sehr schnell auf ganz andere Gedanken kommen.

In einem IP-Netzwerk ist eine Namensauflösung per DNS üblich. Der Client bekommt die DNS-Server in der Regel über eine DHCP-Anfrage. Bei Systemen mit statischen IP-Adressen werden die DNS-Server meist in der Netzwerkkarte hinterlegt. Wer auf so einem Windows System mit IPCONFIG /ALL sich die Netzwerkkarten anschaut, bekommt die DNS-Server mit angezeigt und Programme wie NSLOOKUP verbinden sich wie selbstverständlich mit einem der DNS-Server um Daten zu erhalten.

Das ist aber nur die halbe Wahrheit, wenn in Wirklichkeit prüft der DNS-Resolver von Windows jeden Namen gegen die NRPT-Tabelle, welche auf dem Computer lokal per Gruppenrichtlinie gepflegt werden kann. Über eine Liste können Namen oder Domänen zu anderen DNS-Servern aufgelöst werden. Sogar Proxy-Server können so gesetzt werden.

Damit kann ein Administrator sehr flexibel richtige Regeln für die Namensauflösung umsetzen, was gerade bei Split-DNS besonders interessant ist.

Achtung:
Diese Funktion gib es meines Wissens nur für Windows und nicht für MAC, Unix, Android, Tablets etc. Bedenken Sie daher immer, dass eine Lösung auch andere Client bedienen muss.

Insofern sind andere Ansätze wie z.B. PinpointDNS und WPad auch weiterhin aktuell.

NRPT in GPMC.MSC

Auch der Assistent für Direct Access ist nur eine GUI um im Hintergrund eine Gruppenrichtlinie entsprechend zu pflegen. Selbst die Powershell-Commandlets ändern die Direct Access Gruppenrichtlinien. Daher können Sie natürlich auch mit GPMC die Richtlinien anschauen. Sie können über die GPMC sogar Einstellungen vornehmen, die über die Direct Access Powershell Commandlets erreichbar sind aber nicht über die GUI.  Allerdings sollten Sie hier genau aufpassen, da der Direct Access Assistent die Einstellungen auch wieder ausliest und bei Unstimmigkeiten den Dienst versagt.

Ein Backup der Gruppenrichtlinien ist vorher anzuraten

Hier ein Bild der NRPT-Einstellungen in einer Gruppenrichtlinie.

Ganz unten sehen die die (leere) Tabelle. Die erste Spalte betrifft den "Namespace" als Filter/Match-Kriterium, anhand dessen dann z.B. DNS-Server aber auch WebProxyServer hinterlegt werden können.

NRPT und NSLOOKUP

Die meisten Administratoren verlassen sich bei DNS-Prüfungen nicht auf den schnöden PING, sondern nutzen munter NSLOOKUP. Damit laufen sie aber zumindest bei Direct Access auf der falschen Spur. NSLOOKUP.EXE umgeht nämlich den lokalen Resolver und damit auch die NRPT. NSLookup nimmt sich einen der in den Netzwerkkarten konfigurierten DNS-Server und fragt dann gezielt diesen Server nach den eingegebenen Namen. Damit kann das natürlich nicht funktionieren.

Um die DNS-Funktion von Direct Access zu verifizieren muss man den Resolver des Betriebssystems nutzen und das geht auf der Kommandozeile am einfachsten mit einem PING, der Powershell (Ab Windows 2012 und Windows 8) oder .NET-Klassen.

Ausnahmen mit Direct Access

Die wichtigste Aufgabe der NRPT ist die Umleitung von DNS-Anfragen nach bestimmten Namen zu einem anderen DNS-Server. Zum einen kann so sichergestellt werden, dass Client per Default den lokalen DNS-Server im Internet fragt, aber bei der Auflösung von Namen der internen Domäne natürlich durch den Tunnel den DNS-Server in der Firma abfragt. Nun gibt es aber durchaus Dienste, die durch den Tunnel zwar erreichbar wären, aber dennoch besser außen herum laufen sollen. Hier stelle ich eine Liste von Servern vor, die Sie vielleicht als Ausnahme nicht über den Firmen-DNS-Server auflösen lassen sollten.

Split DNS
Die meisten dieser Hinweise sind nur relevant, wenn Sie eine Split-DNS-Konfiguration, .d.h. wenn der DNS-Namensraum im Internet und im Intranet identisch sind. Wenn ihr interner DNS-Namensraum z.B. firma.intern ist, dann benötigen Sie eigentlich gar keine Ausschlüsse.

Hosts Beschreibung

CRL-Verteilpunkte

Viele Firmen habe mittlerweile eine private Zertifizierungsstelle (Siehe Firmen CA) und wenn diese Zertifikate auch extern genutzt werden, sollte die URL für die Rückrufliste (Siehe CRL) natürlich auch publiziert werden. Gerade bei "Split-DNS" Umgebungen ist der Pfad extern als auch intern der gleiche. Wenn nun Direct Access eben Zertifikate dieser CA verwendet, dann möchte der Client die Gültigkeit prüfen. Die per Gruppenrichtlinie verteilte NRTP in Direct Access weist den Client aber per Default an, interne Namen intern aufzulösen.
Die CRL kann normalweise auch ohne Direct Access erreicht werden und sollte daher in den Ausnahmen erscheinen

IPHTTPS-Server

Wenn der Direct Access Zugang per HTTPS erreichbar machen und der Name dieses Zugangs den gleichen DNS-Suffix wie ihre interne Domäne hat, dann müssen Sie diesen Namen ebenfalls "ausschließen".

Lync Server (Speziell AV-Edge)

Ein besonderer Fall ist der Lync Edge Server. Wenn Sie z.B. die Audio-Daten nicht durch den Direct Access-Tunnel senden wollen, weil die ja auch eine TCP-Verbindung oder sogar ein HTTPS-Tunnel sein kann, dann sollten Sie die Namen der Edge-Server ebenfalls aus dem Tunnel ausschließen, so dass Lync diese Namen über den externen DNS auflöst und er dann auch normal wie ein externer Client mit dem Edge kommuniziert. Dies ist nicht unsicherer aber führt zu einer besseren Audioqualität. Audio/Video muss nicht durch einen per TCP gesicherte Verbindung mit "Retransmits" getunnelt werden. Aber auch andere Dienste von Lync (z.B. Webservices, SIP, WebConf) können eventuell besser am Tunnel vorbei geführt werden, z.B. weil die Server intern nicht über IPv6 erreichbar sind (Routing) und IPv4 er mit UAG möglich ist.

Vergessen Sie auch nicht z.B. "_sipinternaltls._tcp.<sipdomain>, da ansonsten der Client auch von extern den internen Server auflöst, aber solange Lync kein IPv6 unterstützt, ist das nicht hilfreich.

Auch "Meet/join/LyncWeb" und andere Dienste, die per IPv6 nicht erreichbar sind.

Veröffentlichte Webseiten

Überlegen sie was ein Anwender erwartet, wenn er extern unterwegs ist und eine URL eingibt, die er "normalweise" aus dem Internet auch als extern erreichen möchte. Dies kann auch Webseiten betreffen, die durch Direct Access gar nicht erreichbar sind, weil diese in einer DMZ stehen oder noch kein IPV4 unterstützen. Solche Namen sollten Sie auch in der Ausschlussliste aufführen, damit der Zugriff von Extern weiter möglich ist. Dies trifft natürlich nicht zu, wenn die gerade dem Anwender auch von unterwegs so arbeiten lassen wollen, als wäre er intern.

OWA, ADFS, RDP-Gateway

Auch ohne Direct Access gibt es sichere Zugänge zu bestimmten Diensten. Wenn diese nicht ausgeschlossen werden, dann werden diese auch von "intern" angesprochen. Speziell wenn Direct Access vielleicht nicht geht, weil ein Provider dies blockt, lasse ich diese Dienste auch "außen herum" laufen.

VPN-Server

Wenn Clients sich außer per Direct Access auch per Dialup-VPN verbinden können, dann sollten Sie den Namen diese Zugangssystems auch auf die Ausschlussliste setzen

Autodiscover

Wer Exchange einsetzt aber OWA und RPC/HTTP an Direct Access vorbei leitet, sollte auch an Autodiscover denken. Autodiscover kommt mit Outlook sowieso nur zum Einsatz, wenn keine Verbindung zum DC möglich ist aber andere Dienste könnten dadurch ebenfalls gestört werden, vor allem wenn Autodiscover nicht per IPv6 erreichbar und kein NAT64 aktiv ist.

UAG-Portale

Wenn sie UAG einrichten, dann kann damit nicht nur Direct Access "optimiert" und NAT64/DNS64 angeboten werden, sondern sie können damit auch eine Portallösung für Webseiten und interne Dienste bereit stellen. Schade, wenn Sie diese Funktion unterwegs nutzen möchten aber Sie dank "Direct Access" wieder intern sind.

Office 365 ADFS

Wer Office 365 hybrid einsetzt, muss den Clients einen Zugang zu ADFS-Server ermöglichen. Externe Clients müssen diese nicht durch DA erreichen, sondern können auch extern zugreifen, wenn Sie den ADFS-Server als Ausnahme definieren.

WPAD

Da Direct Access auch über IPHTTP funktioniert, kann eine funktionierende WPAD-Konfiguration das System verwirren. Der Client muss und sollte natürlich einen lokalen WPAD-Service nutzen, um überhaupt per IPHTTP zum DA-Server zu kommen. Wenn der Tunnel aber besteht, dann sollte die interne WPAD-Konfiguration natürlich kompatibel zu DA sein. Dazu gehört u.a., dass die per WPAD übermittelten Proxy-Server über ihren Namen und nicht über ihre unerreichbare IPv4-Adresse genutzt werden. Oder sie schließen WPAD direkt über die NRPT aus, damit der Client gar nicht erst durch den Tunnel geht..

Maximal können hier 1000 Einträge gepflegt werden. Aber diese Grenze sollte bei einem guten Design nicht erreicht werden. Bei Windows 2012R2-finden Sie die Stelle im "Remote Access"-Assistenten unter Punkt 3: "Infrastruktur Setup Server" unter DNS.

Jeder Eintrag, der hier gelistet wird, wird über den angegebenen DNS-Server aufgelöst. Sie sehen hier gut, dass z.B. sip.netatwork.de (Lync/Skype für Business), aber auch get.netatwork.de, owa.netatwork.de und natürlich crl.netatwork.de (CRL der PKI) ohne DNS-Server hinterlegt sind. Diese (und andere) Namen werden also über die DNS-Server des Betriebssystem aufgelöst. Der Eintrag "netatwork.de" sorgt dafür, dass Anfragen mit diesem Namen dann wieder an die IPv6-Adresse des Direct Access Servers geroutet werden.

NRPT mit NETSH

Die aktuelle Einstellung bzw. wirksame Einstellung kann per "netsh namespace show policy" ermittelt werden:

Auch der Befehl "netsh dns show state" liefert Informationen:

NRPT in der Registrierung

Wer etwas tiefer nachschaut findet auch die Einstellungen direkt im Policy-Zeit der Registrierung.

Für Administratoren (die hier etwas ändern dürfen) ist es für die Fehlersuche auch möglich, hier etwas zu ändern. Sie erkennen aber in beiden Fällen, dass die "Infrastrukturserver", die für die interne DNS-Auflösung zuständig sind, hier hinterlegt sind. Es muss also eine DNS-Auflösung über IPV6 möglich sein.

Manchmal kommt anscheinend aber auch DA durcheinander. Hier sieht man eine DNS-Bindung auf meiner Gigabit-Karte, die an der Stelle "falsch" ist. Ich bin zu dem Zeitpunkt extern aber mit Direct Access über einen UAG verbunden.

Hier ist aber zu erkennen, dass auch die internen DNS-Server eingetragen wurden. Auf den ersten Blick scheint das ja gut zu sein, vor allem weil es ja auch erst mal funktioniert. Aber leider umgeht mein Clients damit die NRPT-Tabelle bezüglich internen IPv4-Servern. Hier soll er nicht die DNS-Server direkt fragen, sondern per NRPT die DNS64-Server der UAG, damit dieser intern die IPv4-Adresse suchen und in eine IPv6-Adresse für mich übersetzen kann. Mit dieser falschen Einstellung bekomme ich hingegen die IPv4-Adresse per DNS aufgelöst aber kann diese nicht erreichen.

NRPT und Powershell

Auf dem Direct Acces Server gibt es einige Powershell Commandlets, die eine Modifikation der Direct Access Gruppenrichtlinie bezüglich NRPT erlauben.

Add-DAClientDNSConfiguration `
   -DnsSuffix ‘www.mywebsite.com’ `
   -proxyserver ‘myproxy.mydomain.com:8080’

Auch auf dem Client gibt es ab Windows 8 einige Powershell-Befehle, um den Status von Direct Access und der NRPT anzuzeigen

Weitere Links