How to Implement the Active Directory Tier Model for Essential Eight ML2

Implementing the Active Directory Tier Model is the most effective single control you can apply to meet ACSC Essential Eight ML2 privileged access requirements — it structurally prevents credential theft from propagating from a compromised workstation all the way to your domain controllers.

Australian organisations chasing ML2 compliance frequently underestimate how technically specific the Tier Model implementation needs to be. A written policy saying "admins use separate accounts" is not sufficient. The controls must be technically enforced through Group Policy, Authentication Policies, and privileged access workstations (PAWs). This guide walks you through exactly how to do that.

Why the Tier Model Matters for ML2

The ACSC Essential Eight Maturity Level 2 requires privileged accounts that are not used for unprivileged activities, are protected with multi-factor authentication, and are restricted from accessing environments they do not administer. These requirements map precisely to the classic three-tier administrative model popularised by Microsoft (since superseded in Microsoft's own guidance by the Enterprise Access Model) and reflected in widely used identity hardening guidance.

The core problem the model solves is credential reuse across privilege boundaries. When a Domain Admin logs on to a regular workstation to check email, their credentials are cached on that workstation. If the workstation is later compromised by malware, the attacker harvests those cached credentials and escalates directly to domain-level control. The Tier Model makes this attack path technically impossible.

Before you begin implementation, run a free Active Directory assessment to establish your current privileged account posture — specifically how many accounts have Tier 0 privileges today and where those accounts are currently logging on.

Understanding the Three Tiers

Tier 0 — Identity Infrastructure

Tier 0 contains Active Directory itself: domain controllers, ADFS servers, Azure AD Connect servers, PKI infrastructure (certificate authority servers), and any system that can directly control the identity plane. Admin accounts at this tier are Domain Admins, Enterprise Admins, Schema Admins, and any accounts with replication rights or the ability to modify domain controller GPOs.

Tier 1 — Servers and Applications

Tier 1 covers member servers: application servers, database servers, web servers, file servers, backup infrastructure, and management systems like SCCM or SCOM. Tier 1 admins manage these systems but must never log on to domain controllers (Tier 0) or workstations (Tier 2) using their Tier 1 privileged credentials.

Tier 2 — Workstations and User Devices

Tier 2 is the end-user device layer: desktops, laptops, and mobile-managed devices. Tier 2 admin accounts (typically helpdesk) can log on to workstations but must not use those accounts on servers or domain controllers.

Step-by-Step Implementation

Step 1 — Audit Your Current Privileged Accounts

Before building tier structure, you need to know what you are working with. Run the following PowerShell audit to identify all accounts with elevated AD privileges:

# Identify members of sensitive groups
$sensitiveGroups = @(
    'Domain Admins',
    'Enterprise Admins',
    'Schema Admins',
    'Administrators',
    'Group Policy Creator Owners',
    'Account Operators',
    'Backup Operators',
    'Print Operators',
    'Server Operators'
)

foreach ($group in $sensitiveGroups) {
    Write-Host "--- $group ---"
    Get-ADGroupMember -Identity $group -Recursive |
        Select-Object Name, SamAccountName, ObjectClass |
        Format-Table -AutoSize
}

Document every account surfaced. Most Australian organisations discover they have significantly more accounts with Domain Admin membership than expected — service accounts added during system deployments are a common source.

Step 2 — Create the Tier OU Structure

Build a dedicated Organisational Unit structure that reflects your tiers. This is where tier-specific Group Policy Objects and fine-grained password policies will be applied.

Domain Root
├── Tier0
│   ├── Accounts
│   ├── Groups
│   └── Service Accounts
├── Tier1
│   ├── Accounts
│   ├── Groups
│   └── Service Accounts
├── Tier2
│   ├── Accounts
│   ├── Groups
│   └── Service Accounts
└── PAW
    ├── Tier0-PAWs
    ├── Tier1-PAWs
    └── Tier2-PAWs

Move all existing privileged accounts into the appropriate OU. This takes time because you need to verify each account's actual usage before assigning a tier.

Step 3 — Enforce Logon Restrictions via Group Policy

The critical technical control is preventing Tier 0 accounts from logging on to Tier 1 or Tier 2 systems. This is done through the "Deny log on locally" and "Deny log on through Remote Desktop Services" User Rights Assignments on member servers and workstations.

Create a GPO named Tier-Boundary-Enforcement and configure the following under Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment:

• Deny log on locally: Add Tier 0 admin groups
• Deny log on through Remote Desktop Services: Add Tier 0 admin groups
• Deny access to this computer from the network: Add Tier 0 admin groups

Link this GPO to all member server and workstation OUs. This single control, properly deployed, eliminates the most common lateral movement path seen in Australian ransomware incidents.

Step 4 — Implement Authentication Policies (Windows Server 2012 R2 and Later)

Authentication Policies provide a more robust enforcement mechanism than GPO logon restrictions. They use Kerberos armoring to restrict which accounts can authenticate to which computers, enforced by the domain controller rather than the target system.

Apply in audit mode first. Enforcing an Authentication Policy or silo on the first pass can lock Tier 0 accounts out of every system — including your domain controllers — if the SDDL or silo membership is wrong. Create the policy and silo with -Enforce $false (audit mode), validate the SDDL condition, confirm Tier 0 accounts and PAWs are correctly assigned to the silo, and review the authentication audit events. Only switch to -Enforce $true once you have proven the boundaries hold in audit mode.

# REVIEW FIRST. Create in AUDIT mode (-Enforce $false) so a mistake cannot lock out Tier 0.
# Validate the SDDL and silo membership, review audit events, THEN re-run with -Enforce $true.

# Create an Authentication Policy for Tier 0 accounts (audit mode)
New-ADAuthenticationPolicy -Name 'Tier0-AuthPolicy' `
    -UserAllowedToAuthenticateTo 'O:SYG:SYD:(XA;OICI;CR;;;WD;(@USER.ad://ext/AuthenticationSilo == "Tier0Silo"))' `
    -Enforce $false `
    -Description 'Restricts Tier 0 accounts to Tier 0 PAWs only'

# Create an Authentication Policy Silo (audit mode)
New-ADAuthenticationPolicySilo -Name 'Tier0Silo' `
    -UserAuthenticationPolicy 'Tier0-AuthPolicy' `
    -ComputerAuthenticationPolicy 'Tier0-AuthPolicy' `
    -ServiceAuthenticationPolicy 'Tier0-AuthPolicy' `
    -Enforce $false

Authentication Policy Silos require the domain functional level to be Windows Server 2012 R2 or higher, which should be the case for any organisation seeking ML2 compliance. After you have assigned Tier 0 accounts and PAWs to the silo and confirmed, from the audit events, that no legitimate logon would be blocked, re-run the commands (or use Set-ADAuthenticationPolicy / Set-ADAuthenticationPolicySilo) with -Enforce $true to enforce the boundary.

Step 5 — Deploy Privileged Access Workstations

PAWs are dedicated, hardened devices used exclusively for administrative tasks at their respective tier. They are not used for email, web browsing, or any unprivileged activity. For Tier 0 administration, a PAW should be a physically separate device or a securely managed virtual machine accessible only from a known-good host.

Essential PAW hardening controls aligned with the ACSC ISM:

1. Windows Defender Credential Guard enabled
2. Windows Defender Application Control (WDAC) policy — application whitelisting
3. No internet access from PAW (outbound firewall rules)
4. BitLocker full-disk encryption with TPM+PIN
5. Local Administrator Password Solution (LAPS) for local admin accounts
6. Audit logging forwarded to a centralised SIEM
7. MFA required for all logon — hardware security key preferred for Tier 0

Step 6 — Implement Just-In-Time (JIT) Privileged Access

Rather than granting permanent membership in privileged groups, implement JIT access so elevated rights are granted only for the duration of a maintenance window. Microsoft's Privileged Identity Management (PIM) in Entra ID, or third-party PAM solutions, can enforce this.

For purely on-premises environments without Azure AD, a simpler approach uses time-bound group membership via PowerShell scheduled tasks, though a dedicated PAM solution is significantly more robust.

Step 7 — Configure Fine-Grained Password Policies per Tier

Tier 0 accounts require stricter password policies than standard accounts. Use Password Settings Objects (PSOs) to enforce:

• Tier 0: minimum 20-character passphrase, maximum 365-day expiry, lockout after 5 attempts
• Tier 1: minimum 16-character passphrase, maximum 365-day expiry
• Tier 2: minimum 14-character passphrase or MFA without password expiry

Step 8 — Validate and Test the Boundaries

Before declaring implementation complete, test that the tier boundaries actually hold. Attempt to:

• Log on to a member server using a Tier 0 account (should be denied)
• Log on to a domain controller using a Tier 1 account (should be denied)
• Authenticate a Tier 0 account from a non-PAW device (should be denied if Authentication Policies are enforced)

Document all test results. This evidence is directly useful when a compliance auditor or penetration tester assesses your ML2 posture.

Common Mistakes Australian Organisations Make

Service accounts with Domain Admin rights: This is overwhelmingly the most common finding in Australian AD environments. Application vendors historically requested Domain Admin for their service accounts. Audit every service account and reduce privileges to the minimum required. The AD Tier Model pillar guide covers service account remediation in detail.

Delegated OUs with implicit Tier 0 access: Accounts with write access to Domain Controller OUs, or with GenericAll permissions on Domain Admins group objects, are effectively Tier 0 even if they are not in any admin group. ACL auditing is essential.

PAWs that are also general-purpose workstations: A PAW that is also used for email and web browsing provides no security benefit. Enforce this through WDAC application control policies.

Mapping to Essential Eight ML2 Controls

Next Steps

The Tier Model is a foundational control but it is not a complete ML2 solution on its own. You also need to address credential hygiene, Kerberos configuration (Protected Users group, AES encryption enforcement), and LAPS deployment across all managed systems.

Start with a structured Active Directory assessment to understand which of these controls are already in place and where your highest-risk gaps are. This gives you a prioritised implementation roadmap rather than a generic checklist.