The 3 AM Page That Started This Playbook
It was 03:14 when the SOC at one of our financial services clients flagged a Tier 0 admin credential authenticating from a workstation in the call center VLAN. The account had no business touching that subnet. By the time we traced the session, the attacker had already pivoted twice. Root cause was simple: privileged accounts could log on from anywhere in the forest. We rebuilt the access model around enforced authentication policies the following week, and that exact alert has not fired since.
Enforced authentication policies in Active Directory are the control that would have stopped that intrusion at the front door. They restrict where a Kerberos TGT can be issued from and how long it lives, mapped to MITRE ATT&CK T1078.002 (Valid Accounts: Domain Accounts) and T1558 (Steal or Forge Kerberos Tickets). This article walks through the build, the gotchas, and the detection logic we layer on top.
What an Authentication Policy Actually Enforces
A policy object stores two things that matter for hardening: a user TGT lifetime, and a conditional SDDL expression describing which devices the user is allowed to authenticate from. When you create the policy with -Enforce, the KDC rejects ticket requests that violate the conditions. Without that switch, the policy runs in audit-only mode and only writes 4820/4821 events. Audit mode is useful for the first 14 days. After that, it is a false sense of security.
My opinion: most environments stall in audit mode forever because nobody owns the cutover. Pick a date, communicate it, flip the switch. The data you collect after week two is the same data you had at week two.
Prerequisites Before You Touch a Cmdlet
The KDC and client side both need claims, compound authentication, and Kerberos armoring enabled. Edit the Default Domain Controllers Policy, then navigate to Computer Configuration > Policies > Administrative Templates > System > KDC and enable KDC support for claims, compound authentication, and Kerberos armoring. Mirror the setting on workstations under System > Kerberos for Kerberos client support. Skip this and your policy will deploy cleanly and do nothing.
Building Your First Enforced Policy
The minimum viable policy is two lines. This creates a policy named AuthenticationPolicy02 with enforcement on from the start:
New-ADAuthenticationPolicy -Name "AuthenticationPolicy02" -Enforce
To set a non-default TGT lifetime, say 60 minutes for short-lived admin sessions:
New-ADAuthenticationPolicy -Name "AP_1hr_TGT" -UserTGTLifetimeMins 60 -Enforce
For Tier 0 work, you want both the lifetime and the source-device restriction. The SDDL string is the part most engineers get wrong on the first attempt. Here is the pattern we deploy for protected admin accounts that should only authenticate from a dedicated Privileged Access Workstation group called T0Computers:
Import-Module ActiveDirectory
$policyName = 'Tier 0 Access'
$computerGroup = 'T0Computers'
$tgtLifetime = 240
$groupSID = (Get-ADGroup -Identity $computerGroup).SID.Value
$fromSDDL = "O:SYG:SYD:(XA;OICI;CR;;;WD;((Member_of_any {SID($groupSID)}) || (Member_of_any {SID(ED)})))"
$authNPolicyParms = @{
'Name' = $policyName
'Enforce' = $true
'UserTGTLifetimeMins' = $tgtLifetime
'UserAllowedToAuthenticateFrom' = $fromSDDL
}
New-ADAuthenticationPolicy @authNPolicyParms
The 240-minute TGT matches the Protected Users group default. The SDDL allows authentication only from devices in T0Computers or Enterprise Domain Controllers. Everything else gets a KDC_ERR_POLICY response.
Authentication Policy Silos: The Wrapper That Ties It Together
A standalone policy applies to one principal at a time. A silo groups users, computers, and managed service accounts so the policy travels with the membership. The workflow is five steps: enable DC claims support, enable compound claims on in-scope devices, create the policy, create the silo, assign the silo. We assign silos to privileged user objects through Set-ADAccountAuthenticationPolicySilo rather than dropping accounts into Protected Users alone, because silos give you the device condition that Protected Users does not.
The Break-Glass Warning You Cannot Skip
Do not assign an authentication policy to break-glass accounts. If the policy or the silo gets corrupted, those accounts are how you recover. The documented exception is the default Administrator account with RID 500, which can carry a policy because it has out-of-band recovery paths. For every other emergency account, keep them outside the silo, monitor them aggressively, and rotate the credentials after each use. A client we onboarded last year had locked themselves out of their forest doing exactly this. Recovery took 11 hours and a DSRM boot.
Detection Engineering Around the Policy
Enforcement without telemetry leaves you blind to attempts. Three event IDs do the heavy lifting on the DCs: 4820 (TGT denied by policy), 4821 (TGS denied by policy), and 4624 with logon type 3 from unexpected source workstations. A starter KQL rule for Microsoft Sentinel:
SecurityEvent
| where EventID in (4820, 4821)
| where TargetUserName !endswith "$"
| summarize Attempts = count(), Sources = make_set(IpAddress) by TargetUserName, bin(TimeGenerated, 5m)
| where Attempts > 3
The five-minute bin and three-attempt threshold cut alert fatigue while still catching credential spraying attempts against silo members. Tune the threshold based on your baseline. Our mean time to detect on this rule across four client environments runs under 90 seconds from first denied TGT to analyst notification.
Caveats Worth Knowing Before You Deploy
Authentication policies do not protect against attacks that bypass Kerberos entirely. NTLM authentication ignores them. If your privileged accounts can still authenticate over NTLM, an attacker with hash material walks around the control. Pair policy enforcement with NTLM auditing and a phased block. Also, the SDDL editor in ADAC is fragile. Build conditions in PowerShell, version them in Git, and treat the policy object as code. We have seen GUI edits silently strip clauses more than once.
The other caveat is service account sprawl. Every MSA or gMSA that runs as a privileged identity needs to be in the silo too, or the service breaks at the next ticket renewal. Inventory first, enforce second.
What to Do Monday Morning
Pick one privileged group. Build the policy in audit mode. Watch 4820 and 4821 events for two weeks. Flip -Enforce to $true. Add the SIEM rule. Document the silo membership in your change management system. If you want help scoping this for your environment or running the cutover with us on the bridge, reach out at clients.sse.to/contact.php.
For related hardening work, see our walkthrough on reading and writing the Windows Registry with PowerShell and the Intune compliance policies guide for the device-trust side of the same control plane. The technique maps cleanly to MITRE ATT&CK credential access tactics and supports the identity pillar of the NIST Zero Trust Architecture.
