Active Directory Authentication Policies, Silos, Tier 0: The Kerberos Control Almost Nobody Deploys

Active Directory Authentication Policies Silos Tier 0: What They Actually Are

Active directory authentication policies silos tier 0 protection is a single Windows Server 2012 R2 feature that most environments still haven't turned on, even a decade after it shipped. An authentication policy silo is an AD container (objectClass msDS-AuthNPolicySilos) that groups the user, computer, and service accounts you want to protect together. An authentication policy (objectClass msDS-AuthNPolicies) is the ruleset applied to that container — how long a Kerberos ticket-granting ticket (TGT) can live, which devices an account is even allowed to sign in from, and which principals are allowed to authenticate to a service running under that account.

The pitch is simple: your Domain Admins should only ever authenticate from a handful of privileged access workstations (PAWs) and domain controllers. Authentication policies and silos are the mechanism that turns that assumption into something the KDC actually enforces, instead of a rule that lives only in an onboarding document.

Accounts can belong to exactly one silo. Once assigned, the domain controller attaches an authentication-policy-silo claim to the account's Kerberos ticket at sign-in, which claims-aware resources can use for their own access checks — on top of whatever the silo's policy already restricts.

Microsoft's own worked example is a good illustration of the intent: build a "Forest Administrators" silo containing enterprise, schema, and domain admin accounts, then attach a policy so that password- or smartcard-based sign-in from anything other than a domain controller or a designated admin console fails outright. The silo doesn't care how the credential was obtained — phished, replayed, or typed in correctly by the real admin — it only cares whether the source device is on the allow-list.

A single silo can hold all three Active Directory account classes — user, computer, and managed service accounts — but the policy behaves differently per class. Services and computers should never join the Protected Users group: Microsoft's reason is that all incoming authentication fails for those account types, and membership buys them no local protection anyway because the password or certificate is always present on the host. Microsoft also recommends against configuring a TGT lifetime for computer accounts at all. The account-type distinction matters as much as the silo membership itself.

How It Works: TGT Lifetime, Claims, and the Armoring Requirement

Authentication policies act at two points in the Kerberos exchange: the AS exchange (initial sign-in, TGT issuance) and the TGS exchange (service ticket requests). Three things can be restricted:

1. TGT lifetime — set to a shorter, non-renewable value than the domain's default (4 hours is what members of the Protected Users group get automatically). A Tier 0 account with a 1-hour non-renewable TGT is a much smaller window for an attacker who steals a ticket.
2. AllowedToAuthenticateFrom — the set of devices a user can sign in from. This is enforced at the AS exchange.
3. AllowedToAuthenticateTo — the set of principals allowed to authenticate to a service running under this account. Enforced at the TGS exchange.

The device restrictions are where most deployments stall. Checking AllowedToAuthenticateFrom requires Kerberos armoring (FAST): the KDC needs the requesting device's own TGT to validate its identity before it can decide whether that device is on the allow-list. The two Group Policy settings that turn armoring on ship as Not Configured in a default domain — we've covered that gap separately — so on an unmodified domain, sign-in restriction silently doesn't work even though the TGT-lifetime restriction still does. It's a prerequisite here, not an optional hardening extra.

Every authentication policy silo starts in audit-only mode — the PowerShell equivalent of -WhatIf. Audit mode logs what would fail without blocking anything, which is the intended way to burn in a policy before an admin locks themselves out of their own domain.

Why This Control Sits Unused in Most Tier 0 Builds

Three friction points explain why authentication policies and silos rarely leave the pilot stage, even in environments that otherwise take tiered administration seriously.

Domain Functional Level Nobody Revisits

Custom TGT lifetimes need Windows Server 2012 R2 domain functional level on the account domain. Restricting user sign-on needs that same DFL on the account domain with Dynamic Access Control support, plus client devices that support Dynamic Access Control themselves. Restricting service ticket issuance is a requirement on the resource domain, which has to be at 2012 R2 DFL in its own right — so a cross-domain Tier 0 build has two functional levels to check, not one. Plenty of domains raised their DFL years ago for an unrelated reason — a forest trust migration, a schema extension for a different project — and never came back to ask what else that functional level unlocked. Authentication policy silos sit on that list unused because nothing prompts an admin to look for them.

No Override, No Exceptions

Once an account hits the authentication restrictions, there is no workaround — a Domain Admin locked out by an enforced silo is locked out, full stop (RID 500 aside). Microsoft writes its blunt version of this warning about the Protected Users group rather than about silos, but the failure mode is the same one: the authentication restrictions have no workaround, Enterprise Admins and Domain Admins are subject to them like anyone else, and enrolling every member of those groups at once can lock all of them out — including the accounts that would normally fix the problem. Microsoft's separate guidance for authentication policies and silos is procedural rather than reassuring: keep clients and domain controllers on the network, rotate the passwords of protected accounts afterwards, and disable cached logon where you can. That risk profile is enough to make most teams stop at a pilot of one or two test accounts and never move past it.

The Armoring Dependency

Getting real value out of device restrictions requires Kerberos armoring to already be working, and armoring itself is a separate GPO change on both domain controllers and clients that most teams haven't made — see the requirement above. Piloting authentication policies without armoring first means piloting a feature that silently does half of what it's supposed to.

None of these are reasons to skip it. A shortened, non-renewable TGT on Tier 0 accounts directly narrows the window for a stolen ticket — the pass-the-ticket case, where an attacker lifts a legitimate TGT out of memory and replays it while it is still valid.

Be precise about what it does not cover. An authentication policy shapes the ticket the KDC issues: the domain controller returns a non-renewable TGT with the configured lifetime when it answers an AS request, and it checks the sign-on restriction against the armored AS-REQ. A Golden Ticket is forged offline with the krbtgt key and never passes through an AS exchange at all, so it carries whatever lifetime and whatever identity the attacker chose — the silo's TGT lifetime and its sign-on restriction have no hold on it. What can still bite a forged ticket is the TGS-side check: a service whose account carries an AllowedToAuthenticateTo condition is evaluated when the service ticket is requested, not when the TGT was minted. Even that has a boundary — it is still a KDC-side check, and a Silver Ticket is forged against the service's own key and presented straight to the host without the domain controller ever being asked, so no authentication policy ever sees it.

Configuring an Authentication Policy Silo

The full walkthrough is in Microsoft's guide to configuring protected accounts; the shape of it:

1. Enable Kerberos Armoring

Via Group Policy, on domain controllers and clients:

Computer Configuration > Administrative Templates > System > KDC
  "Key Distribution Center (KDC) client support for claims,
   compound authentication and Kerberos armoring" → Enabled, "Always provide claims"

Computer Configuration > Administrative Templates > System > Kerberos (clients)
  "Kerberos client support for claims, compound authentication
   and Kerberos armoring" → Enabled

Confirm with a test sign-in from a domain-joined client before touching any policy — armoring failures are silent otherwise, and you don't want to debug two new features at once.

2. Create the Authentication Policy

Set a TGT lifetime in minutes:

New-ADAuthenticationPolicy -Name "Tier0-AdminPolicy" `
  -UserTGTLifetimeMins 60 `
  -Description "Tier 0 admin accounts - 1h non-renewable TGT"

3. Create the Silo — Unenforced by Default

New-ADAuthenticationPolicySilo -Name "Tier0-Silo"

Every new silo starts in audit mode. Add -Enforce only once the audit period is clean — this is the built-in equivalent of -WhatIf and it's there specifically so a typo in an access-control condition doesn't lock out the account that would have fixed it.

4. Grant Access and Assign Accounts

Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" -Account "da-jsmith"

Get-ADUser -Filter 'Name -like "da-*"' |
  Set-ADAccountAuthenticationPolicySilo -AuthenticationPolicySilo "Tier0-Silo" `
    -AuthenticationPolicy "Tier0-AdminPolicy"

An account has to both be granted access to the silo and have the silo/policy pair assigned to it — granting access alone doesn't enroll the account.

5. Burn In, Then Enforce

Set-ADAuthenticationPolicySilo -Identity "Tier0-Silo" -Enforce $true
Set-ADAuthenticationPolicy -Identity "Tier0-AdminPolicy" -Enforce $true

Both the silo and the policy carry their own Enforce flag — flipping only one of them leaves the other in audit mode, which is a common source of "why didn't this block anything" confusion during rollout.

Detection

The events live in a disabled-by-default operational log — enabling it is step zero for any of this to be visible:

Event Viewer > Applications and Services Logs > Microsoft > Windows >
Authentication > AuthenticationPolicyFailures-DomainController → Enable Log

A spike in 105/106 after a silo goes from audit to enforced is either a legitimate lockout you need to fix (a PAW that isn't on the allow-list yet) or a real attempt to use a Tier 0 credential from somewhere it shouldn't be — both worth paging on.

Remediation

1. Inventory Tier 0 accounts and the exact set of hosts they should ever authenticate from (PAWs, domain controllers — nothing else).
2. Enable Kerberos armoring via GPO on domain controllers and Tier 0-eligible clients; confirm with a test sign-in before touching any policy.
3. Create the authentication policy and silo in audit mode; leave them unenforced for at least one full operational cycle.
4. Enable the AuthenticationPolicyFailures-DomainController log and review 305/306 events for false positives — missing PAWs, forgotten jump hosts.
5. Enforce the silo and the policy. Rotate the passwords of every enrolled account immediately after.
6. Pair this with membership in the Protected Users group for accounts that don't need Kerberos delegation — Protected Users additionally blocks NTLM, DES/RC4 preauth, and both constrained and unconstrained delegation outright. Never add service or computer accounts to Protected Users; every incoming authentication for those account types fails outright.

How EtcSec Detects This

EtcSec's Active Directory audit flags the absence of this control from several angles rather than a single check: NOT_IN_PROTECTED_USERS catches privileged accounts left out of the Protected Users group, WEAK_KERBEROS_POLICY flags a domain that still leaves its maximum ticket lifetime above 10 hours or its renewal window above 7 days, FGPP_NOT_CONFIGURED flags a domain with no fine-grained password policy at all, and the ANSSI-aligned checks ANSSI_R40_NO_PSO_TIER0 and ANSSI_R82_R83_ADMIN_ARCHITECTURE specifically flag Tier 0 admin groups that aren't covered by a dedicated fine-grained policy or a logon-restriction control at all.