Forum Discussion
Marius_Roma
Mar 04, 2021Brass Contributor
Firewall issues in a Windows 10 member PC
I am performing some tests in a lab environment. I installed a Windows Server 2019 server and promoted it to a domain controller for the root domain of a new forest. I installed a Windows 10 client...
Marius_Roma
Mar 05, 2021Brass Contributor
Many thanks for your answer.
Let me clarify: I did not set anything. I simply installed Windows 10 "next" "next" "next".
I joined the PC (a VM) to a domain.
At that point I discovered that the firewall was enabled for all the networks (private, public and domain).
My questions are:
- Is it the standard behavior?
- Am I missing any relevant step?
- Should the firewall stay enabled for a Windows 10 member PC, even if it does limit some domain funcions (i.e. Group Policy Results)?
- What is the best practice?
Regards
marius
Let me clarify: I did not set anything. I simply installed Windows 10 "next" "next" "next".
I joined the PC (a VM) to a domain.
At that point I discovered that the firewall was enabled for all the networks (private, public and domain).
My questions are:
- Is it the standard behavior?
- Am I missing any relevant step?
- Should the firewall stay enabled for a Windows 10 member PC, even if it does limit some domain funcions (i.e. Group Policy Results)?
- What is the best practice?
Regards
marius
Dave Patrick
Mar 05, 2021MVP
Yes, firewall should be on and all members should get the domain network profile that allows all ports for active directory functions.
When NLA starts to detect the network location, the machine will contact a domain controller via port 389. If this detection is successful, it will get the domain firewall profile (allowing for correct ports) and we cannot change the network location profile.
If the domain was not found or process failed, NLA will let you to determine which firewall profile will be used, private or public.
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:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\NetworkList\Nla\Cache\IntranetForests
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.
So I'd check the domain controller and problem client both have the static address of DC listed for DNS and no others such as router or public DNS