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
Can manage and control assets at any level (tier) as required
Can only log on interactively or access assets trusted at the Tier 0 level
Tier 1
Can only manage and control assets at the Tier 1 or Tier 2 level
Can only access assets (via network logon type) that are trusted at the Tier 1 or Tier 0 levels
Can only interactively log on to assets trusted at the Tier 1 level
Tier 2
Can only manage and control assets at the Tier 2 level
Can access assets (via network logon type) at any level as required
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 trough 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.
The lab:
I’ve configured an Active Directory – AD.IMPROSEC.COM.
I’ve added three tiers – Tier 0/1/2 – with the following OU’s:
I’ve skipped the regular AD account; the Tier 2 account is local administrator on workstations (IMPRO-WS01 and IMPRO-WS02).
Tier 1 is local administrator on Tier 1 system (IMPRO-APP) and the Tier 0 account is a member of ‘Domain Admins’ as well of local administrator on Tier 0 systems (IMPRO-DC and IMPRO-PKI).
The Active Directory consists of two workstations, one IIS, one PKI and one Domain Controller.
To summarize the tiers:
Tier 0
Domain Controller - (10.150.0.5)
PKI - (10.150.0.10)
Tier0_nfp
Tier 1
IIS - (10.150.0.15)
Tier1_nfp
Tier 2
Workstations - (10.150.0.30 / 10.150.0.35)
Tier2_nfp
No Group Policy Objects has been created to deny access across tiers, which means the tier0_nfp (DA) account can successfully enter remote PowerShell commands on tier 1 and tier 2 systems as such:
The lab has been created and tiering has been explained, so let’s get into Authentication Policies (AP).
Prerequisites for AP:
Active Directory domain functional level is minimum 2012 R2
Domain Controllers must be 2012 R2 or newer
Clients must be Windows 8 or newer
Objective:
Tiering – Prevent access/lateral movement between tier 0/1/2 – while remaining access to services such as IIS
Even tough tiering needs to be in place, we can’t deny tier 2 workstations access to tier 1 applications such as IIS, DFS and similar. Some tier 0 systems / applications such as domain controllers would also require tier 2 workstations to access these systems over the network, however, these tier 0 systems shouldn’t allow any tier 1-2 identities or systems to logon or otherwise execute anything.
The technical details of AP:
Authentication Policies – Authentication policies defines the lifetime of a kerberos ticket-granting ticket (TGT) as well as the access control conditions for either user or systems defined in the policy.
The AP consists of control conditions that must be met before an account successfully can authenticate and gain access to specific systems, these controls are:
The TGT lifetime for the account, which is set to be non-renewable.
The criteria that device accounts need to meet to sign in with a password or a certificate.
The criteria that users and devices need to meet to authenticate to services running as part of the account.
We’re now ready to create our AP.
Start by creating a new GPO and name it “Tiering – KDC Dynamic Access Control” and link it to the Domain Controller’s OU. Edit the following setting:
Computer Configuration —> Policies —> Administrative Templates —> System —> KDC : KDC support for claims, compound authentication and Kerberos armoring – Enabled: Always provide claims.
This will enable the Domain Controllers to advertise to kerberos clients that claims and compound authentication for Dynamic Access Control (DAC) and kerberos armoring is enabled.
Next we need to enable clients to support DAC as well. Create a new GPO and name it “Tiering – Client Dynamic Access Control”. Link this GPO to all client OU’s. Edit the following setting:
Computer Configuration —> Policies —> Administrative Templates —> System —> Kerberos : Kerberos client support for claims, compound authentication and Kerberos armoring : Enabled.
The IIS, PKI and workstations are now able to support claims, compound authentication and Kerberos armoring.
Now sign into a DC with DA privileges and create the following AP, using Active Directory Administrative Center (ADAC):
Open ADAC and browse to Authentication.
Click “Authentication Policies” and select “New”
Name the AP “Restricted-Tier1-Access”
Select “Enforce policy restrictions” – Always audit before blocking access
Add your Tier 1 accounts in “Accounts”
Go to “User Sign On” and specify a TGT lifetime such as 240.
Click “Edit” and select “Add a condition”
Now change the third column to “Member of any” and select “Add items”
Search for your Tier 1 servers and add them there.
Tier1_nfp is now restricted to IMPRO-APP and will not be able to access Tier 2 workstations.
When attempting to log on IMPRO-WS02, the following screen is presented:
Logging on to IMPRO-APP is still allowed:
Repeat the above each tier and in the end, the following AP should be created:
Attempting to logon trough RDP or locally across tiers will now be denied. We should still be able to access applications, such as IIS and workstations should be able to pull GPO’s from the domain controllers.
Accessing the IIS service from IMPRO-WS02 as tier2_nfp is still no problem:
IMPRO-WS02 can also still pull GPO’s from the domain controller:
Attempting to run as on WS02, using a tier 0 account is also blocked:
Scheduling tasks with tier0 accounts on IMPRO-APP is also denied:
At this moment the tiers are somewhat restricted, however, spawn PowerShell sessions across tier, would still be possible. The picture below, shows that tier0_nfp, logged in on IMPRO-PKI, can successfully authenticate to IMPRO-APP.
Therefore, our tiering is not yet effective enough, it would be very simple to jump between tiers, using WinRM (network logon).
That is because we’re a domain admin as tier0_nfp, and domain administrators gets added to members of ‘Administrators’ when joining computers to the domain.
This may seem as a setback and that AP is not effective, however, managing the local administrators’ group, and other local privileged groups, is big part of tiering.
Every tier should have a local admin GPO mapped, that deletes any member and adds only the needed users/groups.
The above setting adds “Tier2_Workstation_Administrators” and deletes “Domain Admins”.
On tier 0 and tier 1 it is especially important that groups for local administrator access, are divided and split up. No user should be local admin on all servers across tier 0 or tier 1, if that administrator never uses all servers. Please consider using a “DOMAIN\LocalAdmin_%ComputerName%” group with only required accounts for this purpose.
In this environment it could be: “IMPROSEC\LocalAdmin_%ComputerName%” which contain “tier1_nfp”.
The computer translates the variable and add the desired group:
Running a scheduled task looking for new server / workstation names and automatically creating the descried security group for local administrator, is advised when using this specific GPO.
If this GPO is mapped to either Tier 1 or Tier 2 and no group exist for your server / workstation, it will remove all members of the group ‘Administrators’ (except for built-in local Administrator).
A scheduled task could be running with a PowerShell script similar to this:
Get-ADComputer -Filter {(Enabled -eq $true) -and (OperatingSystem -like '*Windows 10*')} -SearchBase “OU=Workstations,OU=Tier2,DC=XXXXX,DC=XXXXXX” | `
ForEach-Object {
$HostName = $_.Name
if (@(Get-ADGroup -Identity "$LocalAdmin_$HostName").Count) {
#Write-Host "$HostName localadmin group exists"
} else {
New-ADGroup -Name "$LocalAdmin_$HostName" -samAccountName "$LocalAdmin_$HostName" `
-Description "Local Administrator Access for $HostName" -Path "OU=LocalAdmins,OU=SecurityGroups,OU=Tier1,DC=XXXXX,DC=XXXXXX" `
-GroupCategory Security -GroupScope DomainLocal
}
}
This concludes my post about tiering your Active Directory with Authentication Policies. I’ve been troubleshooting quite a bit along the way and must say that I still consider AP to be difficult to work with and maintain. AP is a relatively new technology pushed by Microsoft in 2012 R2. I have not seen many posts about AP, nor have I seen that many discussions about it, therefore I wanted to dive in and test it.
I like the idea of Authentication Policies and Authentication Policy Silos, but I do believe that Microsoft will need to work with both technologies, before they will be widely adopted.
I hope you’ve learned a thing or two about Tiering and AP/APS, please reach out if you have any questions regarding either.