locked
domain controller server profile "domain" and "public" RRS feed

  • Question

  • May I know what difference between server profile "domain" and "public"?

    For domain controller, network profile should be "domain" and "public"?

    Any issue if we found domain controller, network profile show "public?

    We shutdown all 2008 R2 domain controllers for power maintenance. Network profile is "domain" before, it became "public" after power on, all services up and normal.I wanted to know what difference between server profile "domain" and "public"? 

    Any Issue if domain controllers using "public" network profile?

    thanks


    Q K

    Sunday, January 27, 2019 3:07 AM

All replies

  • The profile should be domain. Public profile is more restrictive and doesn't allow for correct ports for domain services traffic.

    When NLA starts to detect the network location, the machine will contact the domain controller via port 389. If this detection 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 have the static address of DC listed for DNS and no others such as router or public DNS

    You can also try restarting the Network Location Awareness service then check the profile again. Its possible on the first DC that NLA did checks before active directory domain services were available.

     

    (please don't forget to mark helpful replies as answer)

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.



    Sunday, January 27, 2019 3:27 AM
  • Hi,

    Domain.  The Windows operating system automatically identifies networks on which the computer can authenticate access to a domain controller for the domain to which the computer is joined. You cannot manually assign a network to this location.

    Public.  With the exception of domain networks, all networks are initially categorized as public. Networks that represent direct connections to the Internet or that are in public places, such as airports and coffee shops, should be left public.

    Please refer to the link below:

    https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc754893(v%3dws.10)

    The issue may be related to NLA(Network Location Awareness), please refer to the link:

    https://blogs.technet.microsoft.com/networking/2010/09/08/network-location-awareness-nla-and-how-it-relates-to-windows-firewall-profiles/  

    Best regards,

    Travis


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, January 28, 2019 2:36 AM
  • Hi,

    Just checking in to see if the information provided was helpful.

    Please let us know if you would like further assistance.

    Best Regards,

    Travis


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Tuesday, January 29, 2019 6:53 AM