Domain Controller thinks its on a Public Network

Question

We have a Server 2008 R2 ~~Primary~~ Domain Controller that seems to have amnesia when it comes to working out what kind of network it is on. The (only) network connection is identified at startup as a 'Public Network'.

Yet, if I disable and then re-enable the connection, it happily figures out that it is actually part of a domain network.

Is this because AD Domain Services is not started when the network location is initially worked out?

This issue causes some headaches with Windows Firewall Rules (which I am more than aware can be solved in other ways) so I am mostly just curious to see if anyone knows why this happens.

Please, repeat with me: "there is no Primary Domain Controller, and there has never been since Windows 2000". — Massimo, Feb 21 '12 at 20:35
My sincere apologies. Web Developer having to look after a Windows Network! — Matt Renner, Feb 21 '12 at 20:40
How many domain controllers do you have? When we do maintenance sometimes techs reboot both our domain controllers at the same time! which is not very intelligent (even though its the middle of the night) when you can just stagger the reboots to keep all services up and running. — Brian D., Jan 03 '17 at 17:02
Just to add some additional information for this frustrating issue: http://blogs.technet.com/b/networking/archive/2010/09/08/network-location-awareness-nla-and-how-it-relates-to-windows-firewall-profiles.aspx and there is a hotfix for Windows 7 and 2008 R2 https://support.microsoft.com/en-us/kb/2524478 — Lee Thompson, May 14 '15 at 16:52
Updated link for @LeeThompson's referenced blog post: http://web.archive.org/web/20171105103250/https://blogs.technet.microsoft.com/networking/2010/09/08/network-location-awareness-nla-and-how-it-relates-to-windows-firewall-profiles/ — Minkus, Jan 27 '21 at 17:33

marsh-wiggle · Answer 1 · 2018-11-29T15:51:39.160

Whether the network of a domain controller is classified as domain network doesn't depend on the gateway configuration.

The behaviour of a false network classification can be caused the NLA (network location awareness) service starts before the domain is available. In this case the public or private network is chosen and not corrected afterwards.

How to check if this fault situation is given
When the domain controller after rebooting is in the public network, restart the NLA service or disconnect / reconnect the network. The domain controller should be in the domain network afterwards.

How to solve it
It may help to set the NLA Service to delayed start. Better, check why the domain needs long to be present. It seems that the domain needs longer to start when there are multiple network cards.

When it doesn't help
When neither speeding up the loading of the domain nor the delay of NLA help and the error is caused by the long loading of the domain (look: "how to check..."), then there are some more things that can be done.

Write a script for restarting it an run it with the scheduler (dangerous)

Shift the loading of the NLA service to the end of the service starts, changing the load order in the registry (dangerous)

The following Registry entry sets the dependencies to NSI RpcSs TcpIp Dhcp Eventlog NTDS DNS:

REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc]
"DependOnService"=hex(7):4e,53,49,00,52,70,63,53,73,00,54,63,70,49,70,00,44,68,\
63,70,00,45,76,65,6e,74,6c,6f,67,00,4e,54,44,53,00,44,4e,53,00,00

Execute "IPCONFIG /RENEW" from scheduler at startup with a delay of 1 or 2 minutes (better than starting NLA service)
Restart the NLA service manually after every reboot (but: "IPCONFIG /RENEW" should be preferred)!

One more cause can also be when the domain controller has two or more IPs configured (on the same or on other network cards) and the additional networks aren't configured in the DNS.

Reproduction of the behaviour
On a test domain controller (single DC!) I deleted the default gateway entry and set the DNS Server to delayed start. Doing this the domain needed long to get loaded and the network was classified as public. After disconnecting and reconnecting the network cable, the network was classified correctly as domain network.

Edit

gratefully from the comments of Daniel Fisher lennybacon and Joshua Hanley:

How to add a dependency for NlaSvc to DNS and NTDS

run sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDS from CMD (use sc.exe if you're running it in PowerShell). If you want to double-check the existing dependencies before adding DNS and NTDS, use sc qc nlasvc

This is the answer to our situation where a secondary / backup domain controller in Azure (connected via VPN to on-premises DC), was consistently stuck on the private network location and after restarting NLA it resolved correctly to domain network. I've made the change to delay start and it resolved our issue. — Jaans, May 30 '15 at 12:14
This worked for me! Had this problem for months now and finally decided to figure it out. — notbad.jpeg, Jun 30 '15 at 02:34
here MS blog with info about NLA https://blogs.technet.microsoft.com/networking/2010/09/08/network-location-awareness-nla-and-how-it-relates-to-windows-firewall-profiles/ — Tilo, May 10 '17 at 18:14
I added a dependency for NlaSvc to DNS and NTDS. Works like charm. — Daniel Fisher lennybacon, Nov 20 '17 at 10:17
To do what @DanielFisherlennybacon did, run "sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDS" from CMD (use sc.exe if you're running it in PowerShell). If you want to double-check the existing dependencies before adding DNS and NTDS, use "sc qc nlasvc". — Joshua Hanley, Nov 29 '18 at 15:22
@Tilo's MS blog post is down but available here: http://web.archive.org/web/20171105103250/https://blogs.technet.microsoft.com/networking/2010/09/08/network-location-awareness-nla-and-how-it-relates-to-windows-firewall-profiles/ — Minkus, Jan 27 '21 at 17:20

score 18 · Accepted Answer · answered Feb 21 '12 at 20:34

18

Do you have a default gateway on that connection? Does it reply to ping requests?

Windows uses gateways to identify networks; if it doesn't have a gateway configured, or if it can't succesfully ping it, it will not be able to identify the network it's connected to and will assume it's a public one.

answered Feb 21 '12 at 20:34

Massimo

68,714
56
196
319

We do - The gateway is also a Server 2008 R2 Machine running Forefront Threat Management Gateway, which the DC can ping. – Matt Renner Feb 21 '12 at 20:39
Does your DC have more than one NIC installed and in use?? – John Homer Feb 21 '12 at 20:43
Nope, just the one. – Matt Renner Feb 21 '12 at 20:45
13

Got it - inadvertently had IPv6 turned on so it must have been trying to find the gateway through v6. Turned that off and it works fine. – Matt Renner Feb 21 '12 at 22:12
4

This is definitely wrong. On a domain contoller the firewall status is not affected by the default gateway. – Layer8 Nov 27 '18 at 14:43

John Homer · Answer 3 · 2016-08-18T16:09:17.353

I've seen similar behavior standing up a 2008 R2 AD server. The thing that got me was having more than one NIC enabled, even though it wasn't in use. Once I disabled the unused NICs and rebooted, the problem went away.

The exact windows feature you're up against here is called NLA (Network Location Awareness). I don't know enough about it to claim to be an expert, but I know there's some interesting information out there on the intertubes about how it all works, or is supposed to work.

score 0 · Answer 4 · answered Jun 09 '22 at 06:35

Implementation of marsh-wiggle's excellent answer in Ansible:

- name: Set dependencies of NLA service
  ansible.windows.win_service:
    name: nlasvc
    dependencies:
      - DNS
      - NTDS
    dependency_action: add
  notify: restart nlasvc

where restart nlasvc calls the following handler:

- name: restart nlasvc
  ansible.windows.win_service:
    name: nlasvc
    state: restarted
    force_dependent_services: yes

score 0 · Answer 5 · answered Jun 14 '22 at 21:32

I had a similar event on a stand-alone 2016 Active Directory DS server. Server showed in a Public network. The initial symptom was that DNS lookups would fail against this server using NSLookup. Attempts to open DNS manager resulted in an access denied message.

There were system event logs for LSA Event 40960 and NETLOGON 5781. Under Application and Services Logs > DNS there were DNS-Server-Service 4000 events logged.

This pointed to the server's machine password. The solution was stopping KDC, purging the list, resetting the machine's secret and restarting KDC.

net stop kdc
klist purge
netdom resetpwd /server:127.0.0.1 /userd:domainname.local\administrator /passwordd:*
net start kdc

A random password hash was generated and stored in the machine and in Active Directory. After restarting Active Directory Directory Services functionality was restored. A restart is recommended.

score 0 · Answer 6 · answered Nov 20 '19 at 15:00

In my case, the server was DMZ and many firewall rules blocking the server to talk to domain controllers. In this case, you will need to open up Firewalls (hardware FW) to allow servers to communicate. Also to run a test, connect the server to network where firewall rules are allowing communications between client and servers.

score -4 · Answer 7 · answered Jan 22 '16 at 13:12

After installing a new domain controller, you may find that the "WINDOWS FIREWALL" does not get set properly to "DOMAIN: ON". This is a result of bad installation defaults provided by Microsoft. To fix this, clear the IP6 DNS settings on the network connection from "::0" back to automatic. Also, clear the IP6 Forwarders from the DNS server.

Domain Controller thinks its on a Public Network

7 Answers7

Linked