Initially Isolate Tier 0 Assets with Group Policy to Start Administrative Tiering

 

Hello everyone, my name is Daniel Metzger and I am a Senior Premier Field Engineer for Secure Infrastructure based in Switzerland. In this post, I am going to show you how to use a minimal set of Group Policy objects to isolate domain admins and domain controllers and other Tier 0 assets. If you are not familiar with Microsoft's administrative tiering model, a great starting point would be this article and this one.

 

The approach outlined in this article has the following goals:

1. Prevent exposure of highly privileged domain admin accounts on lower privileged systems
2. Enforce the use of dedicated administrative workstations at least for domain controller access

 

Implementing complete administrative tiering would require additional steps like creating a new structure of Organizational Units (OUs) in Active Directory to securely host Tier 0 assets, apply restricted delegations and security baselines from the Microsoft Security Compliance Toolkit (SCT). This is not covered by this article. The target audience are organizations which have not yet restrictions for the movement of domain admins in their environment.

 

Prerequisites

 

1. An initially empty global security group "Tier0-Users". Its members will be all highly privileged user accounts which must not exposed on systems other than Tier 0. At the very least all domain admins must be added to this group
2. An initially empty global security group "Tier0-Computers". Its members will be all highly privileged computers accounts which must not connect to systems other than Tier 0. At the very least all domain controllers must be added to this group
3. Permissions to create Group Policy objects on the domain level.

 

Create and link the Group Policy objects

 

We need at least two GPOs which both are linked to the domain node:

1. The "T0 Initial Isolation (Computer)" GPO defines the following local security and targets all Windows systems in the domain with security filtering set to "Authenticated Users":
   • "Deny access to this computer from the network" for both the security groups "Tier0-Users" and "Tier0-Computers"
   • "Deny log on as a batch job" for both the security groups "Tier0-Users" and "Tier0-Computers"
   • "Deny log on as a service" for both the security groups "Tier0-Users" and "Tier0-Computers"
   • "Deny log on locally" for both the security groups "Tier0-Users" and "Tier0-Computers"
   • "Deny log on through Terminal Services" for both the security groups "Tier0-Users" and "Tier0-Computers"
2. The "T0 Access (Computer)" GPO defines the following local security policy and targets all Windows systems in Tier 0 with security filtering set to "Tier0-Computers":
   • "Deny access to this computer from the network" is defined but has no one added
   • "Deny log on as a batch job" is defined but has no one added
   • "Deny log on as a service" is defined but has no one added
   • "Deny log on locally" is defined but has no one added
   • "Deny log on through Terminal Services" is defined but has no one added

 

The resulting GPO "T0 Initial Isolation (Computer)" looks like this:

 

 

The resulting GPO "T0 Access (Computer)" looks like this:

 

 

So far we did not add any members to the "Tier0-Users" and "Tier0-Computers" security groups. Even linking both GPOs to the domain node has no impact yet.

 

NOTE: The link order of the two GPOs is extremely important, so you want to test this in a non-production environment first. If the link order is wrong, we block domain admins from logging on to any Windows system in the domain including domain controllers. Although this would protect domain admin credentials as much as possible, it is obviously not a great idea.

 

This shows the correct link order:

1. The Default Domain Controllers Policy is processed first
2. followed by the "T0 Initial Isolation (Computer)" GPO effectively blocking all members of both the "Tier0-Users" and "Tier0-Computers" security groups from logging on to any Windows systems
3. and finally the "T0 Access (Computer)" GPO is applied to Tier 0 systems only removing all "Deny" restrictions for those targets:

 

 

 

The result is that all members of "Tier0-Users" and "Tier0-Computers" are allowed to log on to Tier 0 systems only. This prevents domain admins which are added to the "Tier0-Users" security group from logging on to servers and workstations outside of Tier 0.

 

Things to consider

 

At this point, we still have a few more items to complete to make this work.

• We need to add computer objects to the "Tier0-Computers" security group and have them pick up the new membership by restarting the computers. This is kind of a big bang process as we need to add all domain controllers at once. If we add just a few to pilot the deployment, those domain controllers already added will not be able to connect to domain controllers which are not yet members of the security group. This breaks domain controller replication and SYSVOL access to other domain controllers.

 

Environments with a large number of domain controllers have to carefully plan for this deployment. An approach would be to disable the links for both GPOs until all Domain controllers are added to the "Tier0-Computers" security group and have been restarted, like after applying security updates during maintenance. We would then enable the link for the "T0 Access (Computer)" GPO first, wait for all domain controllers to pick up this change and then enable the link for the "T0 Initial Isolation (Computer)" GPO.

• On the other hand, the "Tier0-Users" security group members can be added gradually. In a first phase we would add just some domain admins to test access to domain controllers and potentially other Tier 0 systems.

 

NOTE: Never add the built-in RID500 Administrator account to "Tier0-Users" as this is our break-glass account for any situation nobody else is able to log on to the domain and for disaster recovery.

 

• I strongly recommend to create new domain admins before they are added to the "Tier0-Users" security group as we do not know how and where the credentials of existing domain admins are exposed already. It might be that they have logged on to Internet connected workstations in Tier 2 in the past being subject to the risk of credential theft and compromise. Newly created domain admins would not be able to log on to lower privileged systems, their credentials are protected. It would be another great idea to add them to the "Protected Users" security group introduced with Windows Server 2012 R2, again the RID500 Administrator being an exception.

 

Dedicated administrative workstations

 

Since domain admins as members of the "Tier0-Users" security group are going to be able to access Tier 0 systems only, they cannot log on to some workstation in the domain to connect to a domain controller. This is what we want primarily, of course – to get domain admins off Internet connected, unsecure workstations. But they still need to be able to log on to domain controllers every now and then.

 

This is where dedicated administrative workstations come into play. At first these workstations do not have to be fully fledged Privileged Access Workstations (PAWs). Laptops running the latest version of Windows 10 with Credential Guard, Device Guard, Local Administrator Password Solution (LAPS) and the hardening Security Compliance Toolkit (SCT) baselines applied plus blocked Internet access would be a very good start. These administrative workstations would be added to the "Tier0-Computers" security group also and act as endpoints to directly connect to domain controllers either running the needed Remote Server Administration Tools (RSAT) or employing SSL-secured Remote Desktop (RDPS) sessions.

 

More things to consider

 

So far, we have discussed domain admins and domain controllers only. But there are other systems to be considered:

• Certification authorities (CAs) are important Tier 0 systems, too. They issue certificates to domain controllers, for example, to enable secure LDAP sessions (LDAPS) between domain controllers and from LDAP clients. If CAs are not accessible to domain controllers over the network, domain controllers cannot successfully request or renew certificates.

 

We could add CAs to the "Tier0-Computers" security group to avoid he problem. But maybe you do not trust your PKI because its administrators have been exposed to lower privileged systems in the past or / and is not built according to best practices. You decide to leave them for the moment while planning for a migration soon, the new issuing CAs being "Tier0-Computers" from the very first moment of their existence.

 

For this use case I will introduce a solution based on a third, temporary GPO a little bit later in this article.

• Windows Server Update Services (WSUS) running on hosts not being members of the "Tier0-Computers" security group also block access from domain controllers. The recommendation here is to build at least one dedicated Tier 0 WSUS instance operated as "Tier0-Computers" system providing updates to domain controllers, servers and administrative workstations in Tier 0 only.
• The Print Spooler system service running by default on domain controllers with desktop experience (a.k.a. full Graphic User Interface) contains a thread called the printer pruner. This thread is responsible for removing stale network printers published in Active Directory. The printer pruner by default contacts the printer queues on print servers every 8 hours to determine whether they are still available. If network printers cannot be reached for 24 hours, they get pruned. Since isolating domain controllers from Tier 1 systems actually blocks the printer pruner from talking to print servers, all published network printers would disappear after a day from the directory.

 

We need to disable the Print Spooler service on all domain controllers which is another recommendation when conducting Active Directory security assessments with customers. Additionally we must set the policy setting "Allow Pruning of Published Printers policy" to Disabled. This step requires processual changes as domain controllers will not prune orphaned printer queues in Active Directory anymore. This task needs to go back to where it belongs to, and that is the folks operating print servers.

• Any services managing domain controllers and other Tier 0 systems using agent installations must be built solely for Tier 0 or need to be removed for Tier 0 completely. Examples would be System Center Configuration Manager (SCCM), endpoint protection, backup, etc. Remember that Tier 0 consists of domain controllers and all users and system which have write access to them directly or indirectly.

 

I see organizations either investing in dedicated Tier 0 services or replacing them with built-in Windows tools. They use Windows Server Backup (wbadmin.exe) instead of third-party backup solutions (which would be our recommendation for Active Directory disaster recovery, anyway). Microsoft Deployment Toolkit (MDT) and WSUS replace SCCM since task sequences for Tier 0 systems are not that complicated as we have here a very restricted set of services provided. With Windows Server 2016, I see organizations shifting to Windows Defender for Tier 0 hosts instead of using antivirus and anti-malware solutions from third parties. These changes further reduce the footprint of Tier 0 as much as possible.

 

Define temporary exceptions in an additional GPO

 

If organizations want to just isolate domain controllers initially, they can introduce an additional security group and another domain level GPO to grant domain controllers network access to a small number of other servers, like certification authorities or WSUS hosts. This would be a short-term temporary situation to gain some time to properly build those services in Tier 0 dedicated to Tier 0 systems.

 

We would need:

1. A global security group "T1-SystemsAccessibleTo-T0-System". Its members are Windows hosts to be accessible over the network to isolated domain controllers in an early stage of the Tier 0 building process
2. The "T1 Access for T0 Systems (Computer)" GPO defines the following local security policy and targets Windows systems in the "T1-SystemsAccessibleTo-T0-System" security group:
   • "Deny access to this computer from the network" for only the security group "Tier0-Users"

 

The resulting GPO "T1 Access for T0 Systems (Computer)" looks like this:

 

 

 

The link order would require this GPO setting to be applied to target systems after the "T0 initial Isolation (Computer)" GPO to work as expected:

 

 

 

The resulting settings for members of the "T1-SystemsAccessibleTo-T0-System" security group is:

• "Deny access to this computer from the network" for the security group "Tier0-Users"
• "Deny log on as a batch job" for both the security groups "Tier0-Users" and "Tier0-Computers"
• "Deny log on as a service" for both the security groups "Tier0-Users" and "Tier0-Computers"
• "Deny log on locally" for both the security groups "Tier0-Users" and "Tier0-Computers"
• "Deny log on through Terminal Services" for both the security groups "Tier0-Users" and "Tier0-Computers"

 

This allows domain controllers to access those hosts over the network (network type 3) while credentials of domain admins are still isolated in Tier 0.