DirectAccess NLS Monitoring

Der "Network Location Service" ist für den Betrieb von Direct Access eine essentielle Komponente, die hochverfügbar sein muss. Diese Seite behandelt die Verfügbarkeit und das Monitoring.

Was macht der NLS ?

Der Network Location Server ist ein Webeserver, der nur im internen Netzwerk erreichbar sein darf. Die für Direct Access konfigurierten Clients prüfen beim Start oder einem Wechsel der Netzwerkverbindung, ob ein Zugriff auf den Server per HTTP und UCMP möglich ist. Die Serveradresse und die URL wird dem Client dabei über die Direct Access Gruppenrichtlinie mitgeteilt.

Um sicher zu sein, dass der Client wirklich genau den Server erreicht und nicht z.B. im Hotel auf eine Portal-Seite umgeleitet wurde, prüft der Client auch das ausgelieferte Zertifikat des Webservers. Die Konfiguration finden Sie in der Registrierung auf dem Client:

Windows Registry Editor Version 5.00

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

Wenn de Clients diesen Server nicht erreichen, gehen Sie davon aus dass Sie im Internet sind und starten die DirectAccess Verbindung. Wenn die URL aber aufgrund eines Ausfalls nicht verfügbar ist, dann können auch interne Clients nicht mehr mit internen Servern arbeiten, die mit einer Gruppenrichtlinie für DirectAccess konfiguriert sind.. Der NLS-Server sollte auf jeden Fall "verfügbar" und erreichbar sein

Webseite

Welcher Server letztlich eine HTTPS-URL bereitstellt, ist unwichtig. Wenn Sie keinen eigenen anderen Webserver bereitstellt und der Direct Access in einer "Single NIC-Konfiguration" betrieben wird dann installiert DirectAccess eine zweite Webseite auf Port 6200;

Ansonsten wird die Default Webseite genutzt. Siehe auch

Unabhängiger NLS

Sie können aber auch einen anderen Server dafür vorsehen und das ist aus meiner Sicht sogar die bessere Wahl. Denn der DA-Server steht vielleicht mit einem Beim im Internet oder zumindest näher dran, während die NLS-Funktion nur von intern erreichbar sein darf. Sie sollte aber von jedem internen Subnetz und jedem internen Standort erreichbar sein.

Entsprechend gilt es zu prüfen, ob sie nun einen hochverfügbaren Server (Cluster) , oder mehrere Server mit DNS Round Robin oder Hardware Load-Balancer einsetzen. Übrigens können Loadbalancer oft genug schon selbst ein Webserver sein, der als NLS-Service ausreicht.

Sie könnten zusätzlich auch den DNS-Eintrag für den Host an jedem Standort auf einen lokalen wichtigen und damit hoch verfügbaren Service lenken. Sie müssen ja nun nicht auf jedem Domaincontroller einen statische Webseite mit dem Zertifikat veröffentlichen. Vielleicht ist auch ein Router oder Switch, der auf einfache HTTPS-Anfragen mit einem "200OK" antwortet, nicht überlastet. Wichtig ist nur, dass der Client erkennen kann, dass er intern ist.

Stellen Sie sich einen DA-Server in der Zentrale vor und eine WAN-Verbindung zu einer Niederlassung ist ausgefallen. Mit einem lokalen Breakout könnte der Client zwar über das Internet weiter auf zentrale Server zugreifen aber die vielleicht wichtigere lokalen Server sind nicht erreichbar. Eine Ausfallsicherheit im WAN sollten die Router gewährleisten und nicht ein Client.

Verfügbarkeit

Aber spätestens jetzt sollten Sie erkannt haben, wie wichtig die Bereitstellung und auch Überwachung der NLS-Verfügbarkeit ist. Das ist so wichtig, dass Direct Access eine eigene "Probe" dafür hat und im Eventlog die Nichterreichbarkeit des NLS-Services direkt meldet:

Die Eventlog-IDs sind:

10038  Healthy -> Unhealthy
10040  Unhealthy -> Healthy

IISLog Analyse

IISLogfiles können groß und viele sein. Prüfen Sie vorher das Verzeichnis und löschen Sie vielleicht sehr alte Logs. Ich habe auf einem Windows 2012R2-DA-Server im Jahr 2022 schon Logs der letzten 10 Jahre mit mehreren GB gefunden.

Am Beispiel des selbst gehosteten IIS-Servers auf Port 62000 kann ich dann in IISLogs wunderbar nachvollziehen, dass der Server von seiner eigenen ManagementRolle ca. alle 5 Minuten abgefragt wird.

Dieses "Muster" kann ich natürlich nutzen, um auch nachträglich noch Ausfälle des Servers zu analysieren. Ich muss einfach nur die IIS-Logs z.B. per PowerShell einlesen und die Zugriffe auf "/insideoutside" vom UserAgent "RaMgmgtSvc" ermitteln und die zeitlichen Abstände ausfindig machen. Ich habe dazu mal ein einfaches Skript gebaut:

param (
   $iispath="C:\inetpub\logs\LogFiles\W3SVC1\*.*"
)

$oldtimestamp = get-date
Write-Host "Start Processing Logs from $($iispath)"
foreach ($logfile in (get-item -Path $iispath)) {
   Write-Host "Processing $($logfile.fullname)"
   $header = (Get-content -path $logfile -first 4)[-1].replace("#Fields: ","").split(" ")
   Import-CSV `
      -Header $header `
      -Delimiter " " `
      -Path $logfile `
   | where {$_."cs(User-Agent)" -eq "RaMgmtSvc"} `
   | foreach {
         $timestamp = get-date "$($_.date) $($_.time)"
         $deltaminutes = [int]($timestamp - $oldtimestamp).totalminutes
         if ($deltaminutes -gt 5) {
            Write-Host "Outage at $($_.date) $($_.time) Delta $($deltaminutes)"
         }
         $oldtimestamp = $timestamp
  }
}

Es könnte Fehlalarme liefern, wenn die IISLogs nicht in chronologischer Reihenfolge eingelesen werden.

Übrigens können Sie in den IISLog natürlich auch die Zugriffe der Clients sehen:

Hier sollten natürlich nur interne Client als "c-ip" auftreten. Leider nutzt DA keinen eigenen UserAgent dafür und scheint auch erst eine Anfrage auf das Verzeichnis (ohne "/") zu machen, um dann einen Redirect auf "/insideoutside/" zu folgen, der den erwünschten 200OK liefert. Entsprechend könnten Sie auch hier eine Auswertung starten:

param (
   $iispath="C:\inetpub\logs\LogFiles\W3SVC1\*.*"
)

$oldtimestamp = get-date
Write-Host "Start Processing Logs from $($iispath)"
Get-Item -Path $iispath | ForEach-Object  {
   $logfile = $_
   Write-Host "Processing $($logfile.fullname)"
   $header = (Get-content -path $logfile -first 4)[-1].replace("#Fields: ","").split(" ")
   Import-CSV `
      -Header $header `
      -Delimiter " " `
      -Path $logfile `
   | where {$_."cs-uri-stem" -eq "/insideoutside/"}
} | group "c-ip" -NoElement

Das Ergebis ist eine Liste der gefundenen IP-Adressen und der Anzahl der Treffer. Der DA-Server selbst ist aufgrund seiner "Self Checks" natürlich der aktivste Client.

Auswertungen der IISLogs sind sehr effektive Wege nach Fehlern zu suchen und Statistiken nach Diensten, Benutzer, Client und Zeiten zu erhalten. Wenn Sie dies häufiger machen, dann sollten Sie sich die Konsolidierung in einer TimeServiceDatabase wie z.B. Influx, Elastic etc. überlegen. Siehe auch Vorratsspeicherung

Monitoring

Der NLS Health Check prüft seine Erreichbarkeit natürlich nur über "Localhost". Wenn Sie eine Monitoring-Lösung nutzen, die HTTPS-Request absetzen kann, dann bietet sich eine entsprechende Überwachung des NLS-Service an. Das ist sogar interessanter, wenn Sie auf dem Client oder zumindest einem Standort der Clients diese Überwachung starten und damit sehr schnell erkennen können.

Wenn es mehrere NLS-Server als "Cluster" gibt, dann sollten Sie nicht nur den NLS-Namen sondern auch die individuelle Instanz überwachen. Prüfen Sie, ob ihre Lösung aber nicht nur den FQDN oder die IP-Adresse des Servers ansprechen sondern per SNI den richtigen Hostnamen beim TLS-Handshake mitliefern kann, damit sie wirklich den richtigen Server überwachen

DA Service Monitoring

Übrigens können sie von extern auch den DA-Services selbst überwachen. Direct Access nutzt seit Windows 2021R2 nur noch HTTPS und keine GRE/UDP-Verbindungen mehr, die in vielen Umgebungen eh nicht möglich sind und nur den Verbindungsaufbau verzögern.

Da kann ich einen einfachen HTTPS-Check machen.

Invoke-WebRequest https://<DA-ServerFQDN>:443/IPHTTPS -SkipCertificateCheck -Method head

Die Antwort ist natürlich auch minimalistisch:

DA nutzt einfach den "Microsoft-HTTPAPI/2.0" Stack, um die Anfragen anzunehmen. Wenn ihr DA-Server ein privates Zertifikat einer internen PKI nutzt und ihr Prüfclient der ausstellenden RootCA nicht vertraut, dann hilft "-SkipCertificateCheck" bei der Powershell Core weiter

Zusammenfassung

Direct Access bringt eine grundlegende "Selbstüberwachung" seiner Dienste und insbesondere des NLS-Service mit, die zumindest auf dem Server die Erreichbarkeit prüfen und bei Fehlern ins Eventlog schreiben. Damit kann ein Administrator schon hier erste Fehler oder Probleme erkennen.

Allerdings reicht dies aus meiner Sicht nicht aus und sie sollten auf jeden Fall auch eine Überwachung des NLS-Servers von einem anderen Server oder sogar aus den Standorten über entsprechende Probes in ihr Enterprise Monitoring aufnehmen. So können Sie schnell erkennen, wenn aufgrund einer Unerreichbarkeit des NLS ihre Clients z.B. Probleme haben.

Mit der HTTPS-Anfrage auf den NLS hat Microsoft einen einfachen und dokumentierten Weg genutzt, damit ein Client zwischen "drinnen" und "draußen" unterscheiden kann. Auf der anderen Seite frage ich mich schon, warum man z.B. nicht auch die Erreichbarkeit eines Domaincontrollers per LDAPS als "intern" konfigurieren kann. Von denen gibt es sicher mehrere Systeme und dank der dynamischen DNS-Einträge wäre auch das Auffinden eher ein "Plug and Play".

Weitere Links