Jorge's Quest For Knowledge!

All You Need To Know About Identity And Security On-Premises And In The Cloud. It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2009-08-05) Different GPOs For HUBs And For Branch DCs

Posted by Jorge on 2009-08-05


If you are using writable DCs (RWDCs) in Branch Offices you want to optimize authentication as best as possible by:

  • Allowing HUB DCs (DCs in datacenters) to register ALL possible service records (domain-wide and site wide) and therefore service whatever AD client that requests authentication
  • Allowing Branch Office DCs to register ONLY service records for site-wide authentication and therefore service only clients in the same AD site as the DC itself

REMARK: RODCs by default only register site-wide SRV records, so for an RODC this is not needed!

Registration of SRV records for RWDCs happens automatically by default and by default ALL SRV records are registered. So you have to tell the DC NOT to register certain SRV records. With regards to the Dc locator process I suggest you also read the following posts:

This post is HOW to tell a DC NOT to register certain SRV records. You have a few options:

  1. Configure the registry of RWDCs in question
  2. Keep RWDCs in Domain Controllers OU and use different GPOs including group filtering
  3. Create one child OU in the Domain Controllers OU, put the BO RWDCs in that child OU, use separate GPO linked to that child OU which reconfigures the registration of the SRV records for those RWDCs
  4. Create multiple child OUs, put each BO RWDC in its own child OU, use separate GPO for each child OU linked to that child OU which reconfigures the registration of the SRV records for those RWDCs

AD.(1)

In W2K you had to configure the registry of each BO RWDC. Another solution was to create your custom ADM file and load that in the GPO that was targeting the BO RWDCs as specified in (2), (3) or (4). The main disadvantage was that custom ADM files tattoo the registry, meaning that undoing the setting was done through the usage of an exact reverse/opposite setting.

AD.(2)

In W2K3 new GPO settings were introduced for this, so it was not need to use custom ADMs. The default available ADMs did not tattoo the registry whereas undoing meant you have to remove the GPO setting and set it to NOT CONFIGURED.

So to use this option you could do the following:

  • Create a Global Security Group (e.g. "GSG_HUB-DCs") for the DCs in the HUB locations
  • Add ALL HUB DCs (non-BO DCs) as member to that group
  • Create a new GPO (e.g. "Branch Office DCs GPO Settings") and link it to the Domain Controllers OU
  • For the GPO "Branch Office DCs Settings" configure which DC locator records should NOT be registered
    • "Computer Configuration\Administrative Templates\System\Net Logon\DC Locator\DNS Records"
      • "DC Locator DNS records not registered by the DCs"
        • Dc DcByGuid Gc GcIpAddress GenericGc Kdc Ldap LdapIpAddress Rfc1510Kdc Rfc1510Kpwd Rfc1510UdpKdc Rfc1510UdpKpwd
  • For the GPO "Branch Office DCs Settings" configure DENY READ & APPLY for the global security group "GSG_HUB-DCs"
  • Make sure the order of applying GPOs is:
    • "Default Domain Controller" GPO
      then
    • "Branch Office DCs Settings" GPO

The procedure for this is:

  • Adding a new HUB RWDC:
    • Install Windows Server and promote to DC
    • Computer account automatically added to Domain Controllers OU
    • Add new HUB DC to group "GSG_HUB-DCs" (if you forget this step the new HUB DC will behave as a BO DC by first applying the Default Domain Controllers GPO and then the "Branch Office DCs GPO Settings" GPO. It will therefore only auth. clients which query DNS for DCs that provide site-wide auth. for THAT site.
    • Done!
  • Adding a new BO RWDC:
    • Install Windows Server and promote to DC
    • Computer account automatically added to Domain Controllers OU
    • Done!

REMARK: the thought here is that it is most likely to add an additional or new BO RWDC then a HUB RWDC. You can of course turn it around and use the group for BO RWDCs and the group then needs READ+APPLY and you need to remove APPLY for Auth. Users.

AD.(3)

I do not have much problem of creating child OUs beneath the Domain Controllers OU. As long as you keep the DC computers accounts within the scope of that OU there should be no problem. Besides that, some apps that expect the accounts to be directly in the Domain Controllers OU (e.g. DCDIAG will report an error about this, but in the case of a child OU you can ignore it)

So to use this option you could do the following:

  • Create ONE new child OU beneath the Domain Controllers OU
  • Create a new GPO (e.g. "Branch Office DCs GPO Settings") and link it to the new child OU
  • For the GPO "Branch Office DCs Settings" configure which DC locator records should NOT be registered
    • "Computer Configuration\Administrative Templates\System\Net Logon\DC Locator\DNS Records"
      • "DC Locator DNS records not registered by the DCs"
        • Dc DcByGuid Gc GcIpAddress GenericGc Kdc Ldap LdapIpAddress Rfc1510Kdc Rfc1510Kpwd Rfc1510UdpKdc Rfc1510UdpKpwd

The procedure for this is:

  • Adding a new HUB RWDC:
    • Install Windows Server and promote to DC
    • Computer account automatically added to Domain Controllers OU
    • Done!
  • Adding a new BO RWDC:
    • Install Windows Server and promote to DC
    • Computer account automatically added to Domain Controllers OU
    • Move computer account to child OU for BO RWDCs (if you forget this step, the new BO RWDC will also auth. clients which query DNS for DCs that provide domain-wide auth.)
    • Done!

 

AD.(4)

This option can become quite a mess as you end up with a separate child OU and a separate GPO (or link one GPO to multiple OUs, but then what is the value of having multiple OUs?) for each BO having an RWDC. I do not recommend going for this option.

If I had to make a choice it would be either [2] or [3]. Choose whatever is easier for you to manage. If you ask Microsoft you will most likely hear to use [2].

!!! You should NOT (NEVER!!!) create multiple OUs under the Domain Controllers OU to delegate permissions to "non-Domain Admins"!!!

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

5 Responses to “(2009-08-05) Different GPOs For HUBs And For Branch DCs”

  1. […] For more information about how to configure RWDCs NOT to register specific mnemonics see this blog post. RODCs by default only register site-wide SRV records, so no need to use a GPO to tell the RODC not […]

  2. Richard said

    What about linking the GPO to the sites containers? Then its automatic and “cleaner” for DCDIAG etc.

    • Jorge said

      that can be quite a lot of work if you have lots of AD sites. Besides that, when you link to sites it also applies to other computers (not just DCs) in the same site. To prevent the last part you could filter it with the Domain Controllers security principal to make sure only DCs in that AD site will apply the GPO.

      There is a much much much easier way to achieve this, that I have never described. Using a GPO filtered by a WMI query is my favorite way of doing this!

      Regards,
      Jorge

  3. Alexander said

    Technet claims that options 3 and 4 is not supported by microsoft (moving dc in child ou even inside domain controllers ou).

    We are link GPO to the sites containers and implements security filtering (with Domain Controllers global security group).

    • Jorge said

      Although I explain option 3 and 4, it is just for completeness and I would never suggest to either implement option 3 or 4. The better approaches are option 2 or the approach where you link GPOs to sites targeting DCs only (as you explain) and my personal favorite is similar to option 2, but instead of using group filtering rather using WMI filtering.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: