Network Location Awareness
Warum kann ich meine Server nicht mehr per RDP erreichen und warum laufen einige Dienste nicht? Vielleicht ist es ja nur, dass der NLASVC ihr LAN nicht als "Domain" oder "Private" sondern irrtümlich als Public erkannt hat. Sie können das Netz auch nicht manuelle auf "Domain" umstellen, sondern maximal auf "Privat". Diese Seite beschreibt, wie der NLASVC erkennt, wozu ein Netzwerk gehört und warum es manchmal daneben geht.
Das Problem
Wenn Sie dann irgendwie anders auf den Server gekommen sind, z.B. per virtuellem KVM, per ILO, DRAC, Intel-ME-Board oder auch per Hyper-V/VMWare-Konsole oder klassische mit Kabel und Monitor, dann kontrollieren Sie bitte zuerst einmal die Zone ihres Netzwerks.
Bei Windows 10 uns neuer gibt es ebenfalls eine Netzwerk Statusanzeige:
Ein "Public "sollten Sie nicht sehen, wen ihre Server in einer Domäne ist und die Domain Controller über dieses LAN erreichen kann. Ein Public sehen Sie durchaus auf der ein oder anderen Karte, z.B. auf dem externen Interface eines Exchange Edge Server, eines Skype for Business Edge oder auch vielleicht eines Web Application Proxy. Quasi alle Systeme die zwei oder mehr Netzwerkkarten und eine davon eben nicht mit den internen DCs sprechen kann oder natürlich auf Systemen, die gar nicht in einer Domäne Mitglied sind und daher maximal manuell ein Netzwerk von "Public" auf "Privat" umgestellt wurde.
Zonen
Seit Windows Vista gibt es schon die Möglichkeit auf den Netzwerkkarten entsprechende Profile anzuwenden. Erst seit Windows 7/Windows 2008 ist diese Einstellung nicht mehr Global sondern pro Netzwerkkarte anzuwenden und es gibt drei Optionen.
- Öffentlich
Der Client ist in einem "unsicheren" Netzwerk und sollte daher möglichst keine Dienste selbst anbieten - Privat
Der Client steht "zuhause" und erlaubt deutlich mehr. - Domain
Der Domain-Joined Client hat erkannt, dass er im Firmennetzwerk ist.
Während Sie "Öffentlich" und "Privat" selbst einstellen können, ist die Einstellung von "Domain" komplett automatisiert und kann nicht von Hand einer Verbindung zugewiesen werden.
Erkennung (NCSI)
Für die Erkennung ist bei Windows ein eigener Dienst Namens "NLASVC" (Network Location Service) zuständig, der automatisch gestartet wird und immer dann aktiv wird, wenn sich ein "Netzwerk-Link" verändert, d.h. sich irgendetwas bei den Netzwerkkarten ändert. Das kann auch ein Wechsel im WLAN oder der Auf/Abbau eines VPN sein. Auch beim Hochfahren wird entsprechend eine Erkennung durchgeführt. Da stellt sich die Frage, woran Windows diese Erkennung fest macht.
Microsoft does not recommend disabling
the NCSI probes. Several operating system components and
applications rely on NCSI. For example, if NCSI does not
function correctly, Microsoft Outlook may not be able to
connect to a mail server, or Windows may not be able to
download updates even if the computer is connected to the
internet
Quelle: An Internet Explorer or Edge window opens when your
computer connects to a corporate network or a public network
https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/internet-explorer-edge-open-connect-corporate-public-network.
Zuerst gibt es einmal die grundlegende Verbindung, deren Parameter auch in der Registrierung zu finden sind.
Im Schlüssel "Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet" gibt es jede Menge Parameter, die NLASVC konfigurieren.
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet] "ActiveDnsProbeContent"="131.107.255.255" "ActiveDnsProbeContentV6"="fd3e:4f5a:5b81::1" "ActiveDnsProbeHost"="dns.msftncsi.com" "ActiveDnsProbeHostV6"="dns.msftncsi.com" "ActiveWebProbeContent"="Microsoft Connect Test" "ActiveWebProbeContentV6"="Microsoft Connect Test" "ActiveWebProbeHost"="www.msftconnecttest.com" "ActiveWebProbeHostV6"="ipv6.msftconnecttest.com" "ActiveWebProbePath"="connecttest.txt" "ActiveWebProbePathV6"="connecttest.txt" "CaptivePortalTimer"=dword:00000000 "CaptivePortalTimerBackOffIncrementsInSeconds"=dword:00000005 "CaptivePortalTimerMaxInSeconds"=dword:0000001e "EnableActiveProbing"=dword:00000001 "PassivePollPeriod"=dword:0000000f "StaleThreshold"=dword:0000001e "WebTimeout"=dword:00000023
Hier sehen Sie auch die Gegenstelle, die sie einfach per Browser testen können:
Millionen von Client fordern diese URL und kleine Text-Datei von Microsoft ab, um die Verbindung zum Internet zu prüfen. Früher gab es noch eine andere URL:
Vor Windows 1607 http://www.msftncsi.com/ncsi.txt Ab Windows 1607 http://www.msftconnecttest.com/connecttest.txt
In Grenzen können Sie die Funktion des NLASVC auch per Gruppenrichtlinien anpassen:
Computer Configuration -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication settings -> Network ->Network Connectivity Status Indicator "Corporate Website probe URL" = Webseite der Firma als Testgegenstelle "Corporate DNS Probe Host Name" = DNS-Name, der auf eine IP-Adresse (A-Record) auflöst "Corporate DNS Probe Host Address = "erwartete IP Adresse als Antwort"
- NCSI active probes and the network
status alert
https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/internet-explorer-edge-open-connect-corporate-public-network#ncsi-active-probes-and-the-network-status-alert - Network Connectivity Status Indicator
https://de.wikipedia.org/wiki/Network_Connectivity_Status_Indicator - How to Fix Connect Attempts to
www.msftconnecttest.com on Windows Server
2016
https://networkproguide.com/fix-connect-attempts-to-www-msftconnecttest-com-windows-server-2016/ - Should I block
http://www.msftncsi.com/ncsi.txt on my
Barracuda Product?
https://campus.barracuda.com/product/websecuritygateway/knowledgebase/50160000000auwRAAQ/should-i-block-http-www-msftncsi-com-ncsi-txt-on-my-barracuda-product/
Fallstricke
Auf Clients funktioniert NLASVC fast immer problemlos aber auf Servern habe ich schon die ein oder andere Problem analysiert. Server haben normalerweise eine "feste" Netzwerkkarte mit stabiler Verbindung. Wenn die Verbindung mal "wackelt", dann ist das auch kein Problem, weil der NLASVC wieder nachschaut und in der Regel die Verbindung korrekt wieder konfiguriert. Knifflig wird es, wenn beim Hochfahren die Erkennung fehlschlägt. Im schlimmsten Fall wird die Netzwerkverbindung auf "Public" (also Internet) gestellt und die meisten Administratoren bemerken das zuerst einmal daran, dass Sie per RDP nicht mehr auf den Server kommen. Da die Netzwerkverbindung dann sich nicht mehr ändert, gibt es für NLASVC auch keinen Grund wieder nachzuschauen. Ich habe bislang folgende Situationen nachstellen können, bei denen diese Deadlock-Situation entstehen kann.
- Logische Switch Probleme
"Eigentlich sollte es heute kein Problem sein, dass sich zwei Endgeräte auf Verbindungsparameter einigen. Solange Sie sich nicht "einigen" passiert auch nicht, da NLASVC erkennt, dass der Link nicht steht. Problematisch wird es, wenn der Link aus Sicht des Netzwerktreibers steht aber dennoch keine Daten übertragen werden. Das kann durchaus ein Softwarefehler des Treibers sein. Es kann aber auch daran liegen, dass der "Next Hop", in der Regel der Switch, die Pakete noch nicht weiterleitet. Prüfen Sie mal, ob ihr Switch hier "Funktionen" hat, die ein sofortiges Durchleiten von Paketen nach der Herstellung des Link verhindern. (Stichwort, Firewall, Authentifizierung, MAC-Verifikation, Fastpath - Netzwerklink mit Virtualisierung
Auch für virtuelle Maschinen kann es solche Probleme geben, da der Gast über den virtuellen Switch nicht erkennen kann, ob der Host auch einen "Link" hat. Gerade wenn der Host nach einem Update neu gestartet hat und viele VMs zeitgleich angestartet werden ist es denkbar, dass der Gast schon loslegen will aber die darunter liegende Schicht noch gar nicht "Ready" ist. In dem Fall hilft es oft, wenn die VMs erst verspätet gestartet werden. - Alle DCs down
Das sollte nicht passieren aber wenn ein Windows Update o.ä. dafür sorgt, dass alle DCs zeitgleich gepatched und gebootet werden, dann kann das schon passieren. Ein DC muss auch nicht down. Es reicht die "Nichterreichbarkeit" durch ihren Server z.B. weil ein Firmware-Update auf dem Switch zwar einen "Link" suggeriert aber doch keine Übertragung möglich ist.
Das alles hängt immer damit zusammen, wie NLASVC arbeitet. Das es irgendwas mit der Verbindung am Anfang zu tun hat ist immer dann wahrscheinlich wenn ein Neustart des Diensts NLASVC das Problem löst.
So funktioniert NLASVC
Der Dienst "NLASVC" ist auf jedem halbwegs modernen Windows Betriebssystem enthalten und steht auch auf "automatisch".
Aktiv wird er aber nur zu zwei Zeiten.
- Wenn ihr Computer startet (oder aus dem Suspend/Himernation-Mode zurück kommt)
- Wenn sich "etwas" am Netzwerk ändert.
Eine Änderung am Netzwerk kann ganz klassisch "Kabel gezogen" sein, d.h. ein echter "Link Loss". Aber auch eine Änderung bezüglich der WLAN-SSID triggert den NLASVC wieder an, seine Umgebung zu befragen und die Firewall-Zonen auf den Verbindungen ggfls. anzupassen. Auch ein VPN sollte über eine virtuelle Netzwerkkarte o.ä., Windows bescheid sagen, dass es aufgebaut wurde. Auch eine Netzwerk-Authentifizierung (8021.x) kann den NLASVC antriggern. Es könnte sich ja nun die Erreichbarkeit bestimmter Dienste geändert haben. Wie sie schon an der Firewall sehen können, gibt es drei Bereiche für Netzwerke:
Auf einer Netzwerkkarte können Sie selbst zwischen den Einstellungen "Öffentlich" und "Privat" wechseln. Anscheinend nutzt Windows dann die MAC-Adresse des Default Gateway, um das Netzwerk später wieder zu erkennen und die vermeintlich richtig Einstellung anzuwenden. Die Einstellung "Domänenprofil" hingegen können Sie nicht auswählen. Diese ermittelt NLASVC eigenständig und nur auf Clients, die auch in einer Domäne Mitglied sind. Der Client versucht dann nämlich per LDAP einen Domain Controller zu erreichen und nur wenn das klappt, geht der Client auch davon aus, dass er in einem "Domänennetzwerk" ist. Damit ist natürlich klar, dass Sie nie einen DC direkt ins Internet stellen sollten.
Ein Schlüssel ist dabei die Information, wo der Client vorher die Gruppenrichtlinien bezogen hat. Der Client vergleicht die aktuelle Antwort mit einer früher erhaltenen Information zur DNS-Domäne und das ist quasi der "Schlüssel". Damit kommt natürlich auch wieder die DHCP-Option zum Domänennamen ins Spiel, die einer Netzwerkkarte eine DNS-Domäne zuweisen kann. Das spiegelt sich auch in der Registrierung wieder.
In dem Schlüssel "NetworkName" steht normalweise die DNS-Domäne des ADForests den NLASVC mit den gefundenen Antworten vergleicht.
- Network Location Awareness Service
Provider (NLA)
https://docs.microsoft.com/en-us/windows/win32/winsock/network-location-awareness-service-provider-nla--2 - Windows Firewall Network Determination
http://www.frickelsoft.net/blog/?p=32 - How to force network profile redetection
with NLA and Windows Firewall
https://www.sevecek.com/EnglishPages/Lists/Posts/Post.aspx?ID=72
“In order to detect Domain network profile correctly, the NLA service must be able to issue LDAP UDP ping against the PDC of the domain and if such a machine is not yet accessible for any reason, it falls back to Public network profile“
Zusätzlich macht der Client auch noch eine HTTP-Anfrage auf einen Server zu machen um zu prüfen, ob er in das Internet kommt. Der Client prüft dabei auch noch, ob der Inhalt überein stimmt. Probieren Sie es doch einfach mal aus
PS C:\> (Invoke-WebRequest http://www.msftncsi.com/ncsi.txt -UseBasicParsing).content Microsoft NCSI
Das hat aber nicht direkt etwas mit den drei Firewall-Einstellungen zu tun sondern nur, ob ihr Client anzeigt, dass eine Verbindung zum Internet besteht
- The Network Connection Status Icon
https://blogs.technet.microsoft.com/networking/2012/12/20/the-network-connection-status-icon/ - Network Location Awareness (NLA) and how
it relates to Windows Firewall Profiles
https://blogs.technet.microsoft.com/networking/2010/09/08/network-location-awareness-nla-and-how-it-relates-to-windows-firewall-profiles/
Troubleshooting mit Eventlog
Die beste Option die Arbeit des NLASVC zu analysieren ist das Windows Eventlog. Es gibt ein eigenes Eventlog für den NLASVC
Hier sollten Sie fündig werden, da hier alle "Disconnects" und Verbindung mit ihrem Status sehen. Hier sehen Sie einmal meine Verbindung im Homeoffice.
Log Name: Microsoft-Windows-NetworkProfile/Operational Source: Microsoft-Windows-NetworkProfile
Folgende Events habe ich bislang gefunden:
Level |
EventID |
Description: |
---|---|---|
Information |
10000 |
Network Connected Name: Identifying... Desc: Identifying... Type: Unmanaged State: Connected,IPV4 (Local),IPV6 (Local) Category: Public |
Information |
10001 |
Network Disconnected Name: msxfaq.net Desc: msxfaq.net Type: Managed State: Disconnected Category: Domain Authenticated |
Information |
10000 |
Network Connected Name: msxfaq.net Desc: msxfaq.net Type: Managed State: Connected,IPV4 (Internet),IPV6 (Local) Category: Domain Authenticated |
Information |
4001 |
Eingegebener Status: Das Netzwerk wird identifiziert. Schnittstellen-GUID: {90a254eb-1f67-4eda-942d-41e92b19d065} |
Information |
4002 |
Übergang zu Status: Das Netzwerk wurde identifiziert. Schnittstellen-GUID: {c566ef7e-d476-40c7-8078-c0e35be4ebb0} |
Information |
4003 |
Übergang zu Status: Nicht identifiziertes Netzwerk. Schnittstellen-GUID: {60bc6758-df32-4876-b9dd-28f13f3cb098} |
Wer mag kann also aus den Events durchaus nachverfolgen, wo ein Client wann aktiv war. Für den NLASVC gibt es aber noch ein zweites Eventlog:
Log Name: Microsoft-Windows-NlaSvc/Operational Source: Microsoft-Windows-NetworkProfile
Folgende Events habe ich bislang gefunden:
Level |
EventID |
Description: |
---|---|---|
Error |
4343 |
LDAP authentication on interface {8F2D5AF2-7F6C-4587-A1EE-B38DE5... |
Error |
4205 |
Error Gateway resolution failed on interface {3443304C-5A6D-4B04-8E6F-... |
Für die Fehlersuche ist dies nützlich, wenn Sie mal schauen wollen, ob ein "Link" geflackert hat. Per PowerShell geht das recht elegant:
PS C:\> Get-WinEvent -LogName "Microsoft-Windows-NlaSvc/Operational" ProviderName: Microsoft-Windows-NlaSvc TimeCreated Id Level Message ----------- -- ----- ------- 10/23/2016 11:20:43 PM 4343 Error LDAP authentication on interface {3443304C-5A6D-4B04-8E6F-4228C2... 7/3/2016 11:19:14 PM 4343 Error LDAP authentication on interface {3443304C-5A6D-4B04-8E6F-4228C2... 6/8/2016 9:16:59 AM 4205 Error Gateway resolution failed on interface {3443304C-5A6D-4B04-8E6F-... 3/10/2015 1:02:38 PM 4343 Error LDAP authentication on interface {8F2D5AF2-7F6C-4587-A1EE-B38DE5... 3/10/2015 1:02:31 PM 4343 Error LDAP authentication on interface {8F2D5AF2-7F6C-4587-A1EE-B38DE5...
msftconnecttest.com-Standort
Der Host www.msftconnecttest.com hat natürlich eine zentrale Rolle für alle Windows Clients und muss verfügbar sein. Das geht ab besten durch viele Server, die weltweit verteilt sind und per DNS passend aufgelöst werden. Ein deutscher Client muss ja nicht in Redmond nachfragen. Microsoft nutzt dazu interessanterweise nicht seine eigenen Datacenter, von denen Sie dank Azure ja genug hätte, sondern baut auf Content Delivery Provider auf. Die haben den Vorteil, dass Sie sogar Server in der Nähe oder direkt bei den Zugangsprovider haben.
Die erste Information bekommen Sie durch einen NSLOOKUP, bei dem bei mir schon ein Server bei Akamai erscheint.
C:\> nslookup www.msftconnecttest.com Nicht autorisierende Antwort: Name: a1961.g2.akamai.net Addresses: 185.22.140.10 185.22.140.18 Aliases: www.msftconnecttest.com ncsi-geo.trafficmanager.net www.msftncsi.com.edgesuite.net
Wenn ich dann einen Traceroute starten, dann sehen Sie bei meinem Glasfaseranschluss, dass das Zielsystem gar nicht weit weg ist.
C:\> tracert www.msftconnecttest.com Routenverfolgung zu a1961.g2.akamai.net [185.22.140.18] über maximal 30 Hops: 1 2 ms 1 ms 1 ms fritz.box [192.168.178.1] 2 8 ms 6 ms 6 ms 100.124.1.57 3 10 ms 5 ms 6 ms 100.127.1.132 4 9 ms 5 ms 6 ms 100.127.1.131 5 6 ms 6 ms 6 ms 185.22.46.145 6 12 ms 8 ms 7 ms 185.22.140.18 Ablaufverfolgung beendet.
Die IP-Adresse 185.22.140.18 gehört in dem Fall sogar noch in den Netzwerkbereich von Deutsche Glasfaser.
https://ipinfo.io/AS60294/185.22.140.0/22
Das bedeutet im Umkehrschluss aber auch, dass die Prüfung natürlich nur "lokale" Störungen erkennen kann. Wenn das Problem aber beim Uplink des Providers zum eigentlichen Internet ist, dann wird ihr Client ein "OK" melden. Das ist aber nicht anders möglich, denn Sie können ja nicht "Das Internet" mit seinen Millionen Systemen und WAN-Links überwachen.
Weitere Links
- End2End ClientCheck
- Network Location Awareness
https://technet.microsoft.com/en-us/library/Cc753545(v=WS.10).aspx
http://download.microsoft.com/download/5/6/4/5649F06A-BA09-41B8-A270-22AC5BC67C44/Windows%207%20Network%20Location.doc - Network Location Awareness (NLA) and how
it relates to Windows Firewall Profiles
https://blogs.technet.microsoft.com/networking/2010/09/08/network-location-awareness-nla-and-how-it-relates-to-windows-firewall-profiles/ - Network Location Awareness
https://technet.microsoft.com/en-us/library/43bea15e-5d4c-4b81-a7e4-b17c2fe53d47 - Network Location Awareness Service
Provider (NLA)
https://docs.microsoft.com/en-us/windows/win32/winsock/network-location-awareness-service-provider-nla--2 - Test for Internet Connectivity the
Windows Way
https://www.codeproject.com/Tips/1077317/Test-for-Internet-Connectivity-the-Windows-Way - http://www.dell.com/downloads/global/power/ps1q10-20100101-Chaudhary.pdf
-
Network Connectivity Status Indicator
https://de.wikipedia.org/wiki/Network_Connectivity_Status_Indicator - After 2 years, I have finally solved my
"Slow Hyper-V Guest Network Performance"
issue.
https://www.reddit.com/r/sysadmin/comments/2k7jn5/after_2_years_i_have_finally_solved_my_slow/ - How to force network profile redetection
with NLA and Windows Firewall
https://www.sevecek.com/EnglishPages/Lists/Posts/Post.aspx?ID=72
“In order to detect Domain network profile correctly, the NLA service must be able to issue LDAP UDP ping against the PDC of the domain and if such a machine is not yet accessible for any reason, it falls back to Public network profile“ - The Network Connection Status Icon
https://blogs.technet.microsoft.com/networking/2012/12/20/the-network-connection-status-icon/ - Windows Troubleshooter Guide/Network
Location Awareness
https://en.wikibooks.org/wiki/Windows_Troubleshooter_Guide/Network_Location_Awareness - Forcing Windows to identify a
special-purpose network
https://harryjohnston.wordpress.com/2013/02/03/forcing-windows-to-identify-a-special-purpose-network/ - Network Location Awareness Service
Provider (NLA)
https://msdn.microsoft.com/de-de/library/windows/desktop/ms739931(v=vs.85).aspx - Network Location Awareness Service: How
It Can Ruin Your Day (and How To Fix It)
https://newsignature.com/articles/network-location-awareness-service-can-ruin-day-fix/ - Microsoft Connection Test (NCSI) and
office 365
https://purepcs.co.uk/kb/microsoft-connection-test-ncsi-and-office-365/ - How to Fix Connect Attempts to
www.msftconnecttest.com on Windows Server
2016
https://networkproguide.com/fix-connect-attempts-to-www-msftconnecttest-com-windows-server-2016/ - Restart-Service NlaSvc -Force
https://serverfault.com/questions/39767/what-settings-does-windows-use-to-determine-network-location
Based on recent experimentation (with Server 2012, but I suspect earlier versions are similar) on non-domain, statically configured networks the NLA service uses the link-layer (MAC) address of the default gateway to identify the network. - Windows Firewall Network Determination
http://www.frickelsoft.net/blog/?p=32 - Should I block
http://www.msftncsi.com/ncsi.txt on my
Barracuda Product?
https://campus.barracuda.com/product/websecuritygateway/knowledgebase/50160000000auwRAAQ/should-i-block-http-www-msftncsi-com-ncsi-txt-on-my-barracuda-product/