Direct Access Network Location Service NLS

Diese Seite ist dem Network Location Service (NLS) beim Einsatz mit Direct Access gewidmet. Dies ist eine essentielle Komponente, damit die Client ermittlen können, wo sie sind und ab sie eine DA-Verbindung benötigen.

Funktionsprinzip

Ein Direct Access Client muss immer zuverlässig erkennen, ob er "im LAN" ist oder eben nicht und einen Tunnel aufbauen kann. Private-IP-Adressen sind aber ebenso wenig ein guter Indikator um von einem privaten LAN auszugehen wie die Erreichbarkeit eines "privaten Servers" per DNS und PING. Microsoft hat daher eine HTTPS-Anfragen auf eine Webseite als Probe vorgesehen, die zwingend per SSL erfolgen muss, bei der auch das Zertifikat geprüft wird. Dieser Server darauf natürlich nur von intern erreichbar sein. Ansonsten würden Clients irrtümlich davon ausgehen, dass Sie im LAN sind, obwohl sie es nicht sind.

Der zusätzliche Aufwand dies über HTTPS abzusichern hat durchaus einen tieferen Grund: Nur so kann sehr sicher verifiziert werden, dass man wirklich den richtigen internen Server erreicht. Es gibt nämlich Provider wie z.B. die Telekom, die Abfragen auf ungültige Namen abfangen und den unbedarften Anwender auf ihre Portalseite umleiten. Auch diverse WiFi-Betreiber leiten den ersten Aufruf eines Clients immer erst mal auf eine Willkommensseite, Anmeldeseite oder Werbung. Teilweise kommt dabei sogar SSL zum Einsatz.

Der NLS-Server

Damit ist klar, dass Sie einen HTTPS-Service mit einem gültigen Zertifikat betreiben müssen. Wo sie den Server betreiben, ist allerdings ihnen frei gestellt. Die Konfiguration im Direct Access erlaubt ihnen den Betrieb mit auf dem Direct Acccess-Server oder die Angabe einer anderen URL.

Der Betrieb auf dem DirectAccess-Server ist für kleine Umgebungen durchaus möglich aber auch kritisch zu sehen. Die Clients starten immer dann die Evaluierung neu, wenn Sie der Netzwerkstack ändert, z.B. Der Client umgestöpselt wird, vom LAN ins WLAN wechselt o.ä. Der Client versucht dann immer diese URL zu erreichen und wenn der Direct Acces Server dann nicht erreichbar ist, dann muss der Client davon ausgehen, dass er extern ist. Er versucht dann einen Tunnel aufzubauen, was natürlich von Intern in der Regel nicht funktioniert.

Es ist daher wichtig, dass der NLS-WebService sehr gut verfügbar ist, Theoretisch können Sie hier einfach einen beliebigen Webserver mit einem Zertifikat nutzen. Das könnte also auch ein Netzwerk-Switch sein, dessen Anmeldeseite per HTTPS erreichbar ist oder ein beliebiges anderes Gerät. Sie müssen dann natürlich an diese Abhängigkeit denken. Wenn Sie in einigen Jahren den Switch einmal tauschen oder nicht an das Zertifikat denken, dann können auch die internen Clients nicht mehr arbeiten.

Denkbar ist auch, dass Sie z.B. auf allen Domänencontrollern einen kleinen statischen IIS laufen lassen, damit eine Anfrage an https://<dnsdomain> erfolgreich beantwortet werden kann.

Ich bin etwas verwundert, dass Microsoft nicht den umgekehrten Weg gewählt hat und die Erreichbarkeit eines externen Servers prüft. Der externe Server könnte ja dann aus dem internen Netzwerk "unerreichbar" gemacht werden, z.B. durch einen PinPoint-DNS-Eintrag oder eine Filterregel im HTTP-Proxy oder der Firewall.

Damit ein Service als NLS-Server agieren kann, müssen nur wenige Kriterien erfüllt sein:

Kriterium  Erfüllt

Webserver, der auf HTTPS reagiert.

Es ist dabei egal, ob das ein IIS, Apache, Nginx, lighttpd oder auch ein Loadbalancer ist. Er muss einfach auf einen HTTPS-GET reagieren. Das können Sie von jedem Client einfach in der PowerShell oder auch im Browser testen.

Invoke-Webrequest https://nls.msxfaq.de:62000/insideoutside

Gültiges SSL-Zertifikat

Der WebServer muss ein gültiges Zertifikat ausliefern. Die betrifft alle Faktoren:

  • Name muss mit dem Hostname in der Probe-URI übereinstimmen
  • Gültigkeitsdatum
  • CRL muss erreichbar sein
  • CRL muss verifizierbar sein

Wenn der NLS-Dienst auf dem DA-Server betrieben wird, dann könnten Sie auch mit einem Self Signed-Zertifikat arbeiten. Das Assistent addiert dann aber den Thumbprint des Zertifikats über die Gruppenrichtlinie auf dem Client.

DNS A-Eintrag

Der Hostname in der URL muss über DNS auflösbar sein. Die Verwendung eines CNAME-Eintrags ist übrigens nicht möglich.

ICMP-Erreichbarkeit

Der Server muss auch per "PING" erreichbar sein. Wer also intern ICMP mal gerne sperrt, stört Direct Access

 

Darf nicht aus dem Internet erreichbar sein!

Der NLS-Service darf nicht aus dem Internet erreichbar sein. Dazu gehören auch "Wildcard"-DNS-Einträge, die jeden Namen auf z.B.: ihre Webseite umleiten, die dann noch mit einem "Wildcard"-Zertifikat ausgestattet sein könnte. In dem Fall würde der Client auch von Extern davon ausgehen, dass er im Intranet ist.

 

Monitoring

Es ist essentiall, dass der NLS von internen Client erreichbar ist. Daher sollten Sie diese Funktion überwachen.

 

Auch wenn die Versuchung groß ist, sollten Sie NICHT einen bestehenden WebServer für diese Aufgabe heran ziehen. Viele Firmen nutzen ja heute schon Exchange mit einem CAS-Array und Loadbalancer. Da würde sich es ja anbieten, diese URL einfach als NLS-Probe zu konfigurieren. Damit bauen Sie aber eine Abhängigkeit von einem ganz anderen Produkt ein. Spätestens wenn in ein paar Jahren wieder die Exchange Konfiguration "angepasst" wird oder Sie z.B. nach Office 365 umziehen, müssen sie auch wieder DirectAccess anpassen.

NLS auf Windows DA

Wenn Sie den NLS-Service auf dem DirectAccess Server selbst installieren, dann installiert der Assistent direkt einen kleinen IIS mit, der eigentlich nur eine Seite hat:

Das reicht für die Antworten an den Client aus. Der Assistent bindet den IIS dann auch an die Port 80 und 443. Der im IIS-Log schaut, kann anhand der Logs auch gut ermitteln, welche Clients intern den NLS-Service fragen:

2015-12-22 09:55:08 192.168.100.30 GET /insideoutside/ - 443 - 192.168.103.4 - - 200 0 0 0

Per Powershell kann man sich schnell einen Überblick beschaffen, welche Clients den NLS Server so angesprochen haben.

# Bitte den Pfad zur aktuellen IIS-Logdatei anpassen
Import-CSV `
   -path C:\inetpub\logs\LogFiles\W3SVC1\u_ex151222.log `
   -delimiter " " `
   -Header ("date","time","s-ip","cs-method","cs-uri-stem",
             "cs-uri-query","s-port","cs-Username","c-ip",
             "cs(User-Agent)","cs(Referer)","sc-status",
             "sc-substatus","sc-win32-status","time-taken") `
| where {$_."cs-uri-stem" -eq "/insideoutside/"} `
| group c-ip -NoElement

Count Name
----- ----
  150 192.168.100.30
    4 192.168.103.82
    2 192.168.102.34
    3 192.168.103.58
    1 192.168.103.86
    2 192.168.102.35
    2 192.168.103.18
    2 192.168.102.40
    1 192.168.102.11
    1 192.168.103.75

So kann zumindest schnell geprüft werden, welche Clients gerade intern aktiv sind. Eine zyklische Abfrage habe ich aber noch nicht erkennen können.

NLS Konfiguration auf dem Client

Über die Gruppenrichtlinien bekommt der Client die URL für den NLS-Server vergeben, wie man in der Berichtsansicht von GPMC gut sehen kann.

Die Konfiguration ist auch über GPMC möglich:

Allerdings sollten Sie immer beachten, dass der Direct Access Konfigurationsassistent die Einstellungen auch wieder ändert.

In der Registrierung landen diese Werte dann an der folgenden Stelle:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\CorporateConnectivity]
"WebProbeUrl"="http://directaccess-WebProbeHost.msxfaq.de"
"DnsProbeHost"="directaccess-corpConnectivityHost.msxfaq.de"
"DnsProbeContent"="fdac:5932:7945:7777::7f00:1"
"SitePrefixes"="fdac:5932:7945:1::/64,fdac:5932:7945:7777::/96,fdac:5932:7945:1000::1/128,fdac:5932:7945:1000::2/128"
"DomainLocationDeterminationUrl"="https://nls.msxfaq.de"

Wenn Sie einen Direct Access Server mit nur einer Netzwerkkarte installieren, dann ist der letzte Wert geändert.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\CorporateConnectivity]
"DomainLocationDeterminationUrl"="https://nls.msxfaq.de:62000/insideoutside"

Wie der Client die Erkennung durchführt und welches Ergebnis er ermittelt, können Sie auf dem Client z.B.: im NCSI Eventlog sehen:

Die wesentlichen Events sind hierbei.

  • 4009 Erkennung wird gestartet
  • 4010 Erkennung beendet
  • 4012 Verbindung fehlerhaft, d.h. Client ist "OUTSIDE" 

Ein schneller Blick liefert auch die Powershell mit "Get-DAConnectionStatus"

 

Sonderfall Windows DA mit einer Netzwerkkarte

Die meisten Firmen haben direkt Access mit zwei Netzwerkkarten installiert. Eine Karte ist davon im internen LAN und die zweite Karte aus dem Internet direkt oder in einer gerouteten DMZ erreichbar. In diesem Fall kann der NLS-Service problemlos auf der internen Netzwerkkarte betrieben werden während auf der externen Netzwerkkarte dann DirectAccess, ADFSProxy, IPHTTPS, IPTUNNEL (SSTP-RAS) Pakete annehmen können. Sobald Sie aber nur eine Netzwerkkarte betreiben und DirectAccess damit intern per NAT erreichbar machen, kann der NLS-Service auf dem Server selbst nicht mehr auf Port 443 lauschen. Das spiegelt sich auch in den entsprechenden IIS-Bindungen ab.

Die Adresse 443 ist hier nicht sichtbar. Der Assistent für Direct Access ändert aber den Eintrag in der Gruppenrichtlinie entsprechend um.

Das ist so aber in der GUI nicht zu sehen. Damit ist aber auch verständlich, warum Sie die Direct Access Topologie nicht im Betrieb einfach umstellen können, sondern die Konfiguration zuerst gelöscht und dann wieder eingetragen werden muss. Das bedeutet aber auch, dass Client mit einer DA-Richtlinie den neuen Server so erst mal nicht erreichen und von extern auch kein Update der Gruppenrichtlinien möglich ist. Aber auch interne Clients werden mit der alten GPO noch den alten Port 443 prüfe, der nicht mehr da ist, dann versuchen von innen mit Direct Access zu kommunizieren und damit auch nicht weiter arbeiten können.

So eine Umstellung muss also entsprechend gut geplant sein oder Sie schaffen einen "Fallback", indem Sie z.B. SSTP parallel zu lassen. Das Problem tritt nicht auf, wenn der NLS-Service auf einem anderen Server genutzt wird.

Schaut man sich die Bindungen mit dem Tool HttpSysConfig (https://httpsysconfig.codeplex.com/) an, dann sieht man auf einem durchschnittlichen Direct Access Server, der zugleich auch ADFS und WAP macht,. folgende Bindungen

Man sieht hier aber weder die Bindungen des IIS noch die Bindungen des SSTP-VPNs. Letzteres ist per Powershell zumindest ermittelbar.

PS C:\> Get-NetIPHttpsConfiguration

PolicyStore       : ActiveStore
ConfigurationType : Local
Profile           :
ProfileActivated  :
State             : Enabled
ServerURL         : https://da.msxfaq.de:443/IPHTTPS
Type              : Server
AuthMode          :
StrongCRLRequired :

Ob die DirectAccess Dienste also wirklich gebunden und aktiv sind, erkennen Sie am einfachsten daran, ob es funktioniert.

Weitere Links