I am writing this blog post because we get a lot of questions regarding how NLA determines a network profile and how it relates to Firewall Profiles as the two are often confused.
First let’s start with what NLA does. For each network interface the PC is connected to, NLA aggregates the network information available to the PC and generates a globally unique identifier (GUID) to identify each network. In other words, it creates a Network Profile for any network it connects to. The Windows Firewall then uses that information to apply rules from the appropriate Windows Firewall Profile. This allows you to apply a different set of Firewall rules depending on which network you are connected to. For example, a Public network could get a very restrictive set of rules, a Home network could get a less restrictive set of rules, and a Managed network could get a set of rules determined by an administrator. NLA can be used for more but I want to focus on how it interacts with the Windows Firewall.
So how does NLA determine which network it is connected to? It depends on which Windows version you are using.
In Windows XP and Windows Server 2003, detection is pretty basic and there are only 2 network profiles: Domain and Standard. If the Connection Specific DNS Name matches the “HKEY_Local_Machine\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\NetworkName” registry value, you get the Domain Profile. Otherwise, you get the Standard Profile. You can find more detail about Windows XP in the following Cable Guy article: http://technet.microsoft.com/en-us/library/bb878049.aspx
Since the Firewall in Windows XP only supported two firewall profiles, this system worked pretty well. The problem was that people don’t connect to just two kinds of networks and found they wanted a restricted set of firewall rules when connected to a public hotspot and a less restrictive set when they were at home, in addition to the firewall rules required by their admin. In Windows Vista, Microsoft introduced a new set of firewall profiles: Domain, Public, and Private. The idea is that any new\unidentified network will get the Public (most restrictive) profile to start with. If you are then found to be on the domain network, you will get the Domain (managed) profile provided by your administrator. That leaves the Private profile for users to configure in their own (semi – trusted) environment. To support the Private profile, network detection had to be enhanced. This was accomplished by gathering various characteristics about the network and using that information to create a network profile and assign a unique GUID that could be used to identify that network. Network identification still starts the same way that Windows XP did by determining if you are on the domain and if that fails it will try to match to a Network profile. The important thing to remember about Windows Vista is that you now have 3 profile choices but you can only have a single active Firewall Profile. So if the machine is multi-homed with a VPN connection, for example, you only get one Profile for all interfaces.
The big change in Windows 7 from Windows Vista is that now you can have multiple active profiles. The same network identification process takes place, but it is done for each interface. So now, for example, a VPN interface can have the domain profile assigned while the physical interface can get the public profile and be protected.
Note: Not all VPN clients work this way. The Microsoft VPN client registers as a network interface and will get an associated Firewall Profile, but third-party VPN clients may not register and thus would not get an associated Profile. The VPN connection will still work but the system will not be protected by the Microsoft Firewall on that VPN interface.
In all cases, detection starts the same way that it does in Windows XP. If the Connection Specific DNS Name matches the “HKEY_Local_Machine\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\NetworkName” registry key then the machine will attempt to contact a Domain Controller via LDAP. If both these steps succeed, you will get the Domain profile. It is important to note that if the steps succeed, processing stops here. This allows you to roam across multiple access points in the same domain without having to stop and identify each of them individually.
If the above steps are complete and a match to the domain was not found, NLA will evaluate the network characteristics to see if it can identify a match. If there is a profile created for that network (not to be confused with the Firewall Profile) the interface will get the Firewall profile associated with that network either Private or Public. If the network is not identified by one of the above methods it will remain with the Public profile.
Note: By default all new/unidentified interfaces get the Public Profile.
So how does it know which profile to associate with a network? Good question. The user is prompted when a new network is identified. They have a choice of Home, Work, or Public.
Home and Work will both give you the Private profile while Public will of course give you the Public profile. I am often asked if this can later be changed; the answer is yes. In the Network and Sharing Center, there is a link to “Customize” the network settings.
Note: Customization does not apply to the Domain profile as it is determined by your administrator.
Generally, the next question I am asked is about the characteristics that are used to identify a network. Based on pieces of information I have collected myself and from this MSDN article that provides information on what NLA can tell you about the network, I have put together the following table that I think covers what is used to identify a network.
This table shows the list of network characteristics NLA provides and indicates how applications may use them:
Indicates when the computer is managed by a domain controller.
Typically, computers that are part of a corporate network are members of a domain that is managed by one or more domain controllers. Therefore, the presence of such a domain controller usually indicates that the network is a corporate network. Applications may use this indication to attempt to discover and connect to corporate resources. Applications may also use this indication to apply policy or settings that are specific to the corporate network.
Indicates the bandwidth of a TCP connection.
Applications may adjust their behavior based on the bandwidth of a TCP connection. For example, if the bandwidth to a mail server is low, then a mail client application may choose to download only the headers of messages, rather than entire messages.
Indicates connection to the Internet.
Applications can use this as an indication that they can discover and connect to servers on the Internet or establish a virtual private network (VPN) connection to the corporate network via the Internet.
Primary DNS Suffix
The name of the domain for which the computer is a member or the DNS suffix of the computer's full computer name.
Domain names are closely related to the infrastructures of networks and as a consequence remain relatively static. When a computer moves around or returns to a given network, their Internet Protocol (IP) address may change, but their domain name suffix is likely to be the same. Applications can use this as a hint that the computer is connected the same network and apply policy or settings accordingly. However, the DNS suffix can be spoofed. Therefore, for applications where accurate network determination is needed, the DNS suffix should not be used as the only network identifier.
Indicates that the domain controller (DC) of the domain for which the computer is a member has authenticated the computer.
When the DC has authenticated the computer, applications may have a degree of confidence that the computer is on the corporate network and use this indication to apply policy or settings that are specific to the corporate network.
Host IP address
The IP address of the computer.
If the IP address of the computer is a public IP address, then remote applications can use it to establish a connection to the computer. For example, a help and support application could relay the computer's IP address to the corporation's help and support center, along with a description of the issues it might be experiencing so that a technician may connect to the computer to assist.
The subnet mask of the subnet to which the computer is connected.
The subnet mask is used along with the host IP address to obtain the network ID of the subnet.
Subnet IP address
The network ID of the subnet to which the computer is connected.
Applications may require a more granular network definition than a domain wide network. The network ID allows applications to identify the specific subnet to which the computer is connected. Group policy may be applied per subnet. As a result, it may also be useful for help and support applications to note the subnet to which the user is connected in order for a technician to resolve any issues. The subnet network ID is the host IP address logically ANDed with the subnet mask.
Default Gateway IP address
The IP address of the default gateway.
Like domain controllers, gateways (routers) on a subnet are also relatively static. Although the user may roam within a network and connect at different places, when they are configured with the same default gateway, it is likely that they are on the same subnet. Thus, applications may use the default gateway IP address as an indication that the user is on a particular subnet. Applications that require a more granular network definition than a domain wide network may also use the default gateway IP address. This is particularly useful on home networks because home users typically do not have their own domain.
Indicates whether the computer is connected to a network on which a Windows Internet Name Service (WINS) server is present.
In some enterprises, WINS may be used to resolve Network Basic Input/Output System (NetBIOS) names into IP addresses. In such enterprises, the presence of a WINS server may be used as an indication that the network is a corporate network.
When connected to a Wireless Network
Default Gateway MAC address
The MAC address is more unique than an IP address and therefore makes a better characteristic
Whether the PC is 802.1x authenticated to the given network
The “unknown” status has been covered by one of my colleagues in a different blog so I won’t go into detail here but I’ll provide a link if you would like to read more about it.
It simply means that Windows cannot uniquely identify the network and will apply the public profile. Generally this is because there is not default gateway and it is not a domain joined machine.
You can use Group Policy to force certain settings. For example you can set unidentified networks to get the Private Profile by default.
There are four policies available beneath Computer Configuration->Windows Settings->Security Settings->Network List Manager Policies:
NLA attempts to identify the network you are connecting to so that you can apply an appropriate set of Firewall rules based on the connection type. It attempts to match the Connection Specific DNS suffix to the domain you are joined to, and if they match you get the Domain firewall profile. Windows Vista adds the additional requirement of successfully connecting to a DC. If that does not succeed, other networks are identified using various infrastructure characteristics and then a unique GUID is assigned to form a Network Profile.
Lastly, I want to share additional technical information about how and where NLA stores information in Windows Vista and later.
Another question I am often asked is about what calls are made when determining if the domain is accessible. This article has the most thorough description I know of:
980873 A computer cannot identify the network when the computer is running Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2, and is a member of a child domain
The Network Location Awareness (NLA) service expects to be able to enumerate the domain’s forest name to choose the right network profile for the connection. The service does this by calling DsGetDcName on the forest root name and issuing an LDAP query on UDP port 389 to a root Domain Controller. The service expects to be able to connect to the PDC in the forest domain to populate the following registry subkey:
If something hinders the DNS name resolution or the connection attempt to the DC, NLA is not able to set the appropriate network profile on the connection.
Most info regarding NLA will be stored under the following three places:
Historical data can be found under the Cache key:
Profiles are stored under the profiles key. Notice the GUID:
And managed Networks are stored under the Signatures\Managed key:
While unmanaged networks are stored under Signatures\Unmanged:
I think that about sums it up for now; I hope you find this information useful.
- David Pracht
Dear Enterprise Networking Team,
I want to test DirectAccess in virtual environment, so i've installed to WS2008R2 virtual machine, wich serves as ipv4/v6 router from test to production network additional NIC, and configuret it with random non-private ip addresses
no default router, no dns.
Windows detects this NIC as Domain, so i cannot enable DirectAccess. This NIC connected to virtual network dedicated for win7 test clients only.
What should i do o make this NIC detected as Public?
MCITP: EA, EMA, VA; MCSA
Could you explain how NLA is affected by IPSec?
Great article! Could you edit with some details about Windows 8?
Can you explain, how to retrigger the Network Location Awareness Network identification process, if a third-Party VPN-Product network adapter doesn't registrate itself?
Simple way is to restart the NlaSvc-Service, but NlaSvc depends on WWANSvc, which is restartet too. Unfortunately that doesn't work if a WWAN Connection is active.