Preventing Domain Controller promotions, cloning and demotions in Windows Server 2012

Reading Time: 3 minutes

In many organizations, Active Directory is the identity and access corner stone to their networking environments. No wonder then, organizations want extended control and auditing on admins and their whereabouts.

Many 3rd party solutions exist to help organizations achieve these goals, but most of them rely on a system where Domain Controllers have agents, communicating with a centralized control and/or auditing server. In these cases, you’d want to limit Domain Controller promotions and demotions.

In Windows Server 2012, limiting Domain Controller promotions and demotions is easier than ever.

 

Pre-Windows Server 2012

If you wanted to prevent Domain Controller promotions in Windows 2000 Server, Windows Server 2003 (R2) and Windows Server 2008 (R2) environments, you’d use on these methods:

  • Limiting membership of the Domain Admins group.
  • Use Delegation of Control to prevent people from creating computer objects in the Domain Controllers Organizational Unit (OU).

Note:
This is a quick fix, that I’ve seen applied a couple of times, but should really be part of a broader Delegation of Control and ACL’ing inside Active Directory, based on the information here.

  • Modify the NTFS Access Control List (ACL) on dcpromo.exe through your (virtual) server installation template and/or Group Policy Preferences.
  • Create IPSec rules for Replication traffic between known Domain Controllers, preventing new Domain Controllers from replicating.

Preventing Domain Controller demotions, however, is a different story. Even if you’re able to prevent it using the methods above, a rogue admin can still demote the server using dcpromo.exe /forceremoval

Note:
Domain Controller cloning is not available in previous versions of Windows Server, prior to Windows Server 2012.

 

Windows Server 2012

Now, in Windows Server 2012, all of the methods above still work, although method 3 would not achieve much, since dcpromo.exe merely exists for legacy scripting.

Note:
Domain Controller promotions are now performed using the Install-ADDSDomainController, Install-ADDSDomain and Install-ADDSForest PowerShell Cmdlets, while demotions are now performed with Uninstall-ADDSDomainController.

Instead, a separate Service has been created to perform Domain Controller promotions, cloning and demotions. In Windows Server 2012, all these actions are performed by the DS Role Server Service (dsrolesvc).

Through Group Policy, this service can be set to disabled:

DSRoleServiceGroupPolicy

Additional security can be added by clicking the Edit Security… button and specifying who has Full, Write, Delete, Read and/or Start, stop and pause access. This way, the (group of) people able to promote, demote and clone Domain Controllers can be defined.

Note:
Since a Windows Server 2012-based Active Directory environment has NTLM authentication disabled by default, proposed Windows Server 2012-based Domain Controllers need to be joined to the domain, before they can be promoted to Domain Controllers.

Note:
When the Active Directory forest is operated on the Windows Server 2012 Forest Functional Level (FFL), the promotion of  pre-Windows Server 2012 Domain Controllers will be unavailable.

Now, of course, since we’re using Group Policies, we’ll also need to look at the security of the Group Policy itself. The Group Policy Management Console (GPMC) should be your tool of choice here, too. Locate the Group Policy you’ve created earlier under the Group Policy Objects node in the left pane and click on the Delegation tab in the right pane. Next, click the Advanced… button in the bottom right corner.

When you apply the Group Policy, make sure the link between the Group Policy and the Organizational Unit (OU), Active Directory site or Active Directory domain is Enforced, when admins have the ability to create other (disagreeing) Group Policies on lower levels.

Note:
In the Group Policy Management Console, you can define who can create Group Policy Objects. By default, the Domain Admins and Group Policy Creator Owners will have these permissions. These permissions can be changed on the Delegation tab of the Group Policy Objects node.

With the Group Policy in place, we can utilize our 3rd party auditing solution to monitor changes to this Group Policy itself and new computer objects in the Domain Controllers Organizational Unit (OU).

 

Concluding

In Windows Server 2012, Active Directory admins gain an important new tool to restrict Domain Controller promotions, demotions and cloning: the DS Role Server Service (dsrolesvc).

When combining strict access to starting this service and the methods already available from before, a Security admin has full control over its servers operating as Domain Controllers.

Further reading

HOW TO: Delegate the ability to add a domain controller to the domain (using minimum permissions)
DS Role Service Disabled
Troubleshooting Domain Controller Deployment

Related Posts

New features in AD DS in Windows Server 2012, Part 2: New Promotion Process
KnowledgeBase: "The service cannot be started" error during Active Directory Domain Services configuration

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.