Securing Active Directory (AD) is not a simple task, but nonetheless a task that every organization should be focused on, if they want to increase their defensive capabilities when it comes to lateral movement and exploitation in their network/AD.
My colleague Slavi wrote a great and comprehensive guide to securing Windows environments where he touches upon Active Directory Tiering. I highly recommend reading this article’s section about the model tiering as a primer, since this post will take it even further.
Active Directory tiering has been around for a while and is considered very effective against lateral movement in Active Directory. Tiering consists of compartmentalizing Active Directory identities and systems. A typical tier model consists of 3 tiers, named Tier 0, Tier 1 and Tier 2.
A breakdown of each tier has already been described in the earlier mentioned ‘Securing Windows Environments’ post and can be seen here as well:
• Tier 0 - Direct Control of enterprise identities in the environment. Tier 0 includes accounts, groups, and other assets that have direct or indirect administrative control of the Active Directory forest, domains, or domain controllers, PKI and all the assets in it. The security sensitivity of all Tier 0 assets is equivalent as they are all effectively in control of each other.
• Tier 1 - Control of enterprise servers and applications. Tier 1 assets include server operating systems, cloud services, and enterprise applications. Tier 1 administrator accounts have administrative control of a significant amount of business value that is hosted on these assets.
• Tier 2 - Control of user workstations and devices. Tier 2 administrator accounts have administrative control of a significant amount of business value that is hosted on user workstations and devices.
The administrative accounts in those tiers have the following access rights and permissions defined:
• Tier 0
o Can manage and control assets at any level (tier) as required
o Can only log on interactively or access assets trusted at the Tier 0 level
• Tier 1
o Can only manage and control assets at the Tier 1 or Tier 2 level
o Can only access assets (via network logon type) that are trusted at the Tier 1 or Tier 0 levels
o Can only interactively log on to assets trusted at the Tier 1 level
• Tier 2
o Can only manage and control assets at the Tier 2 level
o Can access assets (via network logon type) at any level as required
o Can only interactively log on to assets trusted at Tier 2 level
When tiering has been implemented in the Active Directory a typical all-around administrator would utilize the following accounts:
Tier 0: Administrator account – For logging in to Domain Controllers or otherwise manage the Active Directory forest/domain. Systems effected: Domain Controllers, PKI, AAD Connect, Identity Management systems etc.
Tier 1: Administrator account – For logging in to the applications servers or otherwise manage the applications utilized in the environment. System effected: MSSQL, Web Servers, DFS etc.
Tier 2: Administrator account – For logging in to workstation or otherwise manage the tier 2 systems, typically seen utilized in helpdesk or similar. Systems effected: Workstations, Printers, mobile devices etc.
Tier 2: Production account – Regular AD account. Should be used when logging into workstations, using mail, web browsers or similar. Systems effected: Workstations and/or mobile devices.
For the time being this seems very theoretical and this post aims to show a practical approach to effectively tiering Active Directory.
What I’ve usually seen when tiering is implemented, is this:
A security group for each tier. Each security group containing all the accounts of each tier.
A GPO for each tier. Each GPO using “Deny logon locally” (type 1) and “Deny logon trough Terminal Services” (type 10) in order to prevent e.g. Tier 1 and Tier 2 to logon in Tier 0.
The above solution is missing quite a bit of configuration, to be effective tiering. One configuration that is missing is the utilization of all the following GPO settings:
• Deny access to this computer from the network (type 2)
• Deny logon as a batch job (type 3)
• Deny logon as a service (type 4)
• Deny logon locally
• Deny logon through Terminal Services
Without usage of the first three settings, an attacker would still be able to access Tier 0 systems from Tier 1 systems using many different techniques. Those techniques including simple PowerShell remoting, creating scheduled tasks on the remote system, creating services on the remote system, connecting with WMI, DCOM, SMB or other techniques, the list goes on.
Another misconfiguration is the lack of compartmentalizing. With Active Directory tiering it is crucial that user access rights are defined based on ‘least-privilege’ and need, and not based on which tier the system is attached to.
A MSSQL server would usually be classified as a tier 1 system alongside an IIS server. However, the MSSQL server utilizes different Service Accounts and many different permissions than an IIS server.
If both servers are placed in the same OU, with the same “Tier 0 Deny Access” and “Tier 2 Deny Access” GPO’s that would drastically diminish the tiering since the MSSQL Service Account would have permissions to access the IIS server.
If I gained access to this MSSQL Service Account, I could potentially stop the DHCP server from handing out leases, which would not be ideal.
However, if each system had its own OU (for clarity and administration) and each their own GPO for deny/allowing access, based on the actual account/service accounts needed on the specific system the tiering would be much more effective.
Practically this would mean creating a GPO called “Tier 1 – MSSQL User Rights Assignment”, linking it to the MSSQL OU and granting the usual MSSQL Service Accounts the windows privileges they require, such as:
• Log on as a Service
• Replace a process-level token
• Adjust memory quotas for a process
• Increase a process working set
• The list goes on
The same would be done for DHCP and other Tier 0/1/2 systems. This would be very effective tiering, since an exploited MSSQL Service Accounts (e.g. Kerberoast) would not be able to take down your DHCP or other tier 1 system such as DFS.
This is all great and very effective, but I want to highlight another way of tiering Active Directory, using Authentication Policies.
I’ve chosen to focus on just the Authentication Policies, since this will be a smaller lab. In a bigger environment with heavy tiering and specific needs, Authentication Policy Silos could be created alongside Authentication Policies to support their needs.