Mastering Active Directory Tiering Best Practices for Enhanced Security

Step 1: Understand the Active Directory Tier Model and Enterprise Access Model

Effective Active Directory security begins with a clear understanding of its inherent value and the pathways an attacker might exploit. The traditional AD tier model provides a hierarchical framework to categorize assets and accounts based on their sensitivity and impact on the enterprise. Microsoft's evolution of this concept into the broader Enterprise Access Model refines this by encompassing cloud resources and different access pathways, but the core principle of preventing lower-tier access from compromising higher tiers remains paramount.

The traditional AD tier model comprises:

• Tier 0 (Control Plane): This tier represents the highest level of trust and control. It includes all assets and accounts that can directly or indirectly control the entire Active Directory forest. This includes Domain Controllers, Active Directory Certificate Services (AD CS), identity management systems, hypervisors hosting these systems, and all accounts within highly privileged AD groups like Domain Admins, Enterprise Admins, Schema Admins, and the built-in Administrator account. Compromise of Tier 0 grants an attacker full control over the enterprise.
• Tier 1 (Management Plane / Data/Workload Plane): This tier encompasses business-critical applications, servers (e.g., Exchange, SQL, application servers), and the administrative accounts used to manage them. In the Enterprise Access Model, this is split into the Management Plane (enterprise-wide IT management) and Data/Workload Plane (per-workload management). While not as universally controlling as Tier 0, compromise of Tier 1 can lead to significant business disruption or data breaches.
• Tier 2 (User Access / App Access): This tier includes all user workstations, user accounts, and devices, as well as application access pathways (APIs). These are common endpoints where an attacker might gain initial access. Compromise of a Tier 2 asset should not, under any circumstances, allow for escalation to Tier 1 or Tier 0.

The fundamental objective of AD tiering is to enforce a hierarchy: administrative credentials for a higher tier must never be used on a lower tier. For instance, a Tier 0 administrator account should only ever log on to a dedicated, hardened Tier 0 Privileged Access Workstation (PAW) and never to a standard user workstation (Tier 2) or even a general server (Tier 1). This 'clean source' principle breaks common attack chains like 'Pass-the-Hash' or 'Credential Theft' where an attacker could otherwise steal Tier 0 credentials from a less secure system.

Step 2: Inventory and Classify All Accounts and Assets

Before any remediation, you must gain full visibility into your current environment. This involves identifying all privileged accounts, critical assets, and existing dependencies. Categorize each based on its potential impact if compromised.

Identify All Privileged Accounts and Their Memberships

Begin by listing members of your most critical Active Directory groups. This forms the baseline for your Tier 0 accounts.

Get-ADGroupMember -Identity "Domain Admins" -Recursive | Select-Object Name, SamAccountName, ObjectClass
Get-ADGroupMember -Identity "Enterprise Admins" -Recursive | Select-Object Name, SamAccountName, ObjectClass
Get-ADGroupMember -Identity "Schema Admins" -Recursive | Select-Object Name, SamAccountName, ObjectClass
Get-ADGroupMember -Identity "Administrators" -Recursive | Select-Object Name, SamAccountName, ObjectClass
Get-ADGroupMember -Identity "Backup Operators" -Recursive | Select-Object Name, SamAccountName, ObjectClass

• -Identity "Group Name": Specifies the security group to query.
• -Recursive: Ensures that members of nested groups are also returned.
• Select-Object Name, SamAccountName, ObjectClass: Displays the name, logon name, and object type for clarity.

Portal alternative: Open 'Active Directory Users and Computers', navigate to the 'Users' container (or 'Builtin' for some groups), locate the desired group, and view its 'Members' tab. For nested groups, you'll need to manually drill down.

Confirmation: Review the output for each command. This raw list will likely contain service accounts, legacy accounts, and potentially even user accounts that should not be there. This is your starting point for remediation.

Identify and Classify Critical Assets

List all Domain Controllers, servers hosting critical applications, and any systems that manage other systems (e.g., WSUS, SCCM, backup servers). These will form your Tier 0 and Tier 1 assets.

Get-ADComputer -Filter 'PrimaryGroupid -eq (Get-ADGroup "Domain Controllers" | Select-Object SID).Value' | Select-Object Name, DNSHostName, OperatingSystem
Get-ADComputer -Filter {OperatingSystem -like "*Server*" -and Name -notlike "*DC*"} | Select-Object Name, DNSHostName, OperatingSystem, @{Name="Description";Expression={(Get-ADComputer $_).Description}}

• The first command retrieves all Domain Controllers.
• The second command lists all other Windows Server operating systems, which you will then manually classify as Tier 1 or Tier 0 (e.g., management servers, critical application servers).
• @{Name="Description";Expression={...}}: This is a calculated property to also retrieve the description attribute, which can contain valuable classification information.

Step 3: Implement Dedicated Privileged Access Workstations (PAWs) and Management Accounts

To break the attack chain, all highly privileged administrative tasks must originate from highly secure, purpose-built workstations using dedicated administrative accounts.

Provision and Harden Privileged Access Workstations (PAWs)

PAWs are hardened, restricted-use computers specifically for sensitive administrative tasks. They should be isolated, patched rigorously, and have minimal software installed. While PAW setup is outside the scope of AD PowerShell, you will configure AD to restrict where privileged accounts can log on.

Create Dedicated Administrative Accounts

Admins should have at least two accounts: a standard user account for daily tasks and a separate, highly privileged account for administrative functions. These privileged accounts should have complex, unique passwords and ideally be protected by Multi-Factor Authentication (MFA) where feasible (e.g., hybrid scenarios with Entra ID MFA).

Restrict Privileged Account Logon Locations

For your Tier 0 administrative accounts, explicitly define the PAWs from which they are allowed to log on. This is a critical control measure.

# Example for a Tier 0 Admin Account
Set-ADUser -Identity "AdminUser_T0" -LogonWorkstations "PAW01,PAW02"

# Example for a Tier 1 Admin Account (if applicable, to restrict to management servers)
Set-ADUser -Identity "AdminUser_T1" -LogonWorkstations "MgmtServer01,MgmtServer02"

• -Identity "AdminUser_T0": Specifies the privileged user account.
• -LogonWorkstations "PAW01,PAW02": Defines a comma-separated list of computer names where the account is permitted to log on. Any logon attempt from an unauthorized workstation will be denied.

Portal alternative: Open 'Active Directory Users and Computers', locate the user account, open 'Properties', go to the 'Account' tab, click 'Log On To...', and specify the allowed computer names.

Confirmation: Attempt to log on with a restricted account from an unauthorized workstation. The logon should fail with an access denied message.

Step 4: Remediate Privileged Service Accounts and Stale Accounts

Service accounts, especially those in privileged groups, and stale user accounts are high-value targets for attackers. Proactive remediation significantly reduces your attack surface.

Identify Service Accounts in Privileged Groups

Service accounts often have long-lived credentials and minimal interactive monitoring, making their compromise particularly dangerous. Use the inventory from Step 2 to identify service accounts (often named with 'svc-' prefix, or identified by their description attribute) that are members of privileged groups.

# This command attempts to find users in 'Domain Admins' group whose description indicates a service account
Get-ADGroupMember -Identity "Domain Admins" -Recursive | Where-Object { $_.objectClass -eq "user" } | ForEach-Object {
    $user = Get-ADUser $_.SamAccountName -Properties Description, servicePrincipalName
    if ($user.Description -like "*Service Account*" -or $user.SamAccountName -like "svc_*") {
        Write-Host "Service Account `t`t: $($user.SamAccountName)"
        Write-Host "Description `t`t: $($user.Description)"
        Write-Host "Member of `t`t: Domain Admins (or nested)"
        Write-Host "---"
    }
}

• This script iterates through members of a privileged group, fetches their description, and flags them if they match common service account patterns. Adjust the `if` condition to match your organization's naming conventions or service account identification methods.

Remediate Service Accounts

Once identified, take immediate action:

• Remove from Privileged Group: If the service account does not legitimately require Domain Admin (or similar Tier 0) privileges, remove it immediately. Delegate only the minimal required permissions using scoped security groups or granular ACLs.
• Migrate to Group Managed Service Accounts (gMSAs): For modern applications and services, gMSAs offer automatic password management, simplified service principal name (SPN) management, and improved security.

# To remove a service account from 'Domain Admins'
Remove-ADGroupMember -Identity "Domain Admins" -Members "ServiceAccountName" -Confirm:$true

# Example for creating a gMSA (requires KDS Root Key to be set on Domain Controllers)
# Add-KdsRootKey -EffectiveImmediately
New-ADServiceAccount -Name "svc_WebApp" -DNSHostName "svc-webapp.yourdomain.com" -PrincipalsAllowedToRetrieveManagedPassword "ApplicationServer1$"
Install-ADServiceAccount -Identity "svc_WebApp"

• Remove-ADGroupMember: Removes a specified member from the group.
• New-ADServiceAccount: Creates a new gMSA.
• -PrincipalsAllowedToRetrieveManagedPassword: Specifies the computer accounts (ending with '$') that are authorized to retrieve the gMSA's password.
• Install-ADServiceAccount: Installs the gMSA on the specified server.

Confirmation: Re-run the `Get-ADGroupMember` command. The service account should no longer appear. For gMSAs, verify the service is running under the new gMSA identity.

Remove Stale Active Directory Accounts

Stale accounts represent an unmonitored attack vector. Identify and disable/delete accounts that haven't logged on for an extended period (Microsoft recommends 90 days).

# Find stale user accounts (not disabled, not service accounts) that haven't logged on in 90+ days
$cutoffDate = (Get-Date).AddDays(-90)
Get-ADUser -Filter * -Properties LastLogonDate, Enabled, Description | Where-Object {
    $_.LastLogonDate -lt $cutoffDate -and $_.Enabled -eq $true -and $_.Description -notlike "*Service Account*" -and $_.SamAccountName -notlike "svc_*"
} | Select-Object Name, SamAccountName, LastLogonDate, Enabled, Description | Export-Csv -Path "C:\Temp\StaleAccounts.csv" -NoTypeInformation

# To disable a stale account (after review)
Disable-ADAccount -Identity "StaleUserSamAccountName"

# To delete a stale account (after monitoring period, e.g., 7-14 days after disabling)
Remove-ADUser -Identity "StaleUserSamAccountName" -Confirm:$true

• -Properties LastLogonDate, Enabled, Description: Retrieves necessary attributes for filtering.
• `Where-Object`: Filters for accounts older than the cutoff date, enabled, and not identified as service accounts (adjust service account filtering as needed).
• Export-Csv: Exports the list for review before action.
• Disable-ADAccount: Disables the specified user account.
• Remove-ADUser: Permanently deletes the user account.

Confirmation: Verify the `Enabled` status of the accounts. For deleted accounts, ensure they no longer appear in AD.

Step 5: Address Dual-Privileged Accounts in Hybrid Environments

In hybrid environments, accounts with high privileges in both on-premises Active Directory and Microsoft Entra ID (formerly Azure AD) create a significant attack surface. A compromise of such an account could lead to full control over both cloud and on-premises resources.

Identify Dual-Privileged Accounts

While direct AD PowerShell commands cannot identify Entra ID roles, you must cross-reference your on-premises privileged group memberships (from Step 2) with your Microsoft Entra ID privileged role assignments (e.g., Global Administrator, Application Administrator, Exchange Administrator).

# Retrieve members of on-premises Domain Admins group
Get-ADGroupMember -Identity "Domain Admins" -Recursive | Select-Object SamAccountName | Export-Csv -Path "C:\Temp\OnPrem_DomainAdmins.csv" -NoTypeInformation

# (Requires Azure AD PowerShell module, not part of AD DS module, for Entra ID roles)
# Get-MsolRoleMember -RoleObjectId (Get-MsolRole -RoleName "Global Administrator").ObjectId | Select-Object EmailAddress
# Compare these lists manually or programmatically through scripting (e.g., in Python or a more advanced PowerShell script combining modules).

• The AD PowerShell command extracts the on-premises privileged accounts.
• The conceptual Azure AD PowerShell command (not run here, but implied for cross-referencing) would list members of Entra ID roles.

Remediate Dual-Privileged Accounts

Once identified, prioritize remediation:

• Separate Roles: The strongest recommendation is to separate cloud and on-premises administrative roles into distinct accounts. For instance, an account that is a Global Administrator in Entra ID should not be a Domain Admin on-premises.
• Reduce Privileges: If separation isn't immediately feasible, reduce privileges in one or both environments to enforce least privilege.
• Implement Just-in-Time (JIT) Access: Utilize Microsoft Entra Privileged Identity Management (PIM) to enforce approval workflows and limit standing access for accounts that must retain elevated privileges, particularly in Entra ID. While PIM primarily applies to Entra ID, the principle of JIT access should be extended to on-premises AD through other means where possible.

# Example of reducing on-premises privilege (e.g., if the user needs to remain a Global Admin in Entra ID)
Remove-ADGroupMember -Identity "Domain Admins" -Members "DualPrivilegedUser" -Confirm:$true
# Then, delegate specific, minimal permissions as needed for on-premises tasks.

Confirmation: Verify the account is no longer a member of the highly privileged AD group and that its Entra ID roles are also appropriate and protected by PIM.

Step 6: Enforce Least Privilege and Continuous Monitoring

Tiering is not a one-time configuration; it requires ongoing vigilance. Continually enforce the principle of least privilege and establish robust monitoring capabilities.

Delegate Permissions, Do Not Grant Full Control

Avoid granting full administrative rights where granular permissions suffice. Delegate specific tasks (e.g., password resets for an OU, managing specific DNS records) to lower-tier administrative accounts or helpdesk staff.

# Granting specific permissions to an OU (Example: Allow 'Helpdesk' group to reset passwords in 'Users' OU)
# This is a complex operation best handled through the 'Delegation of Control Wizard' or AD ACL Editor for precision.
# Example command to review existing ACLs (read-only):
Get-ACL "AD:OU=Users,DC=yourdomain,DC=com" | Format-List

• Get-ACL: Retrieves the Access Control List for the specified Active Directory object (e.g., an Organizational Unit).
• Reviewing ACLs is crucial for identifying over-permissive delegations.

Portal alternative: Right-click on an OU in 'Active Directory Users and Computers', select 'Delegate Control...', and follow the wizard to grant specific permissions to groups or users.

Continuous Audit and Monitoring

Regularly audit privileged group memberships, account activity, and security event logs. Look for anomalous logon patterns, unexpected group changes, or new administrative accounts.

• Review privileged group memberships frequently.
• Utilize tools like Microsoft Defender for Identity for real-time detection of suspicious activities (e.g., unusual logons, lateral movement attempts, reconnaissance).
• Implement a Security Information and Event Management (SIEM) system to centralize and analyze security logs from Domain Controllers and other critical assets.

# Regularly check for new members in sensitive groups (compare to previous audit)
Get-ADGroupMember -Identity "Domain Admins" -Recursive | Select-Object SamAccountName | Export-Csv -Path "C:\Temp\DomainAdmins_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation

# Example of checking recent successful logons for a specific Domain Controller (requires audit policy configured)
Get-WinEvent -FilterHashTable @{LogName='Security';ID=4624;Keywords=0x8020000000000000} -MaxEvents 100 | Where-Object {$_.Properties[5].Value -like "*DC01*"} | Select-Object TimeCreated, @{n='AccountName';e={$_.Properties[5].Value}}, @{n='LogonType';e={$_.Properties[8].Value}}

Confirmation: Automated alerts from your SIEM or Defender for Identity should flag any attempts to add users to privileged groups or unusual activity from Tier 0 accounts.