Authentication policies and silos for Tier 0 accounts

Deny-logon GPOs are the backbone of tiering, but they are enforced by each target computer. If a GPO does not apply, if a server sits in the wrong OU, or if an attacker controls a machine and simply ignores its local policy, a Tier 0 password or hash is still accepted by the domain. Authentication policies and silos move that decision to the KDC: a Tier 0 account can only get a TGT from an approved device, whatever the device itself thinks.

This guide covers how authentication silos actually evaluate, the prerequisites (including Kerberos armoring), how to build a Tier 0 silo, how to roll it out in audit mode, and how to verify it. The short overview lives in Tier 0 and privileged access. This is the implementation.

How policies and silos work

Two object types live in CN=AuthN Policy Configuration,CN=Services in the configuration partition:

• Authentication policy (msDS-AuthNPolicy): per object type (user, computer, service), it sets a TGT lifetime and two conditions written in SDDL: allowed to authenticate from (which devices may request the account's TGT) and allowed to authenticate to (which accounts may request service tickets to this service).
• Authentication policy silo (msDS-AuthNPolicySilo): groups accounts and assigns one policy per object type. Membership is two-sided: the silo lists permitted members in msDS-AuthNPolicySiloMembers, and each account points to its silo in msDS-AssignedAuthNPolicySilo. Both are needed.

When a silo member authenticates, the KDC adds a silo claim to the TGT. A policy condition can then say "the device requesting this TGT must be a member of the Tier0 silo". Because the device identity comes from the computer's own TGT used for FAST armoring, the feature depends on armoring and claims support end to end.

Each policy and silo has an enforce flag. Without it, the KDC evaluates the rules and logs what would have failed, but allows the request. That audit mode is the core of a safe rollout.

Prerequisites

• Domain functional level Windows Server 2012 R2 or higher, and every DC running Windows Server 2012 R2 or later.
• KDC claims and armoring support on all DCs: Computer Configuration > Policies > Administrative Templates > System > KDC > KDC support for claims, compound authentication and Kerberos armoring set to Enabled with Supported. Do not jump to Always provide claims or Fail unarmored authentication requests for this project.
• Client support on every device in the silo: Computer Configuration > Policies > Administrative Templates > System > Kerberos > Kerberos client support for claims, compound authentication and Kerberos armoring set to Enabled. Windows 8 / Server 2012 and later support it.
• Protected Users membership for the same Tier 0 accounts is strongly recommended. It forces AES, blocks NTLM and delegation, and sets a default 240-minute TGT, which complements the silo. See Protected Users.
• A complete inventory of Tier 0 accounts and devices, including PAWs and Tier 0 jump servers.

# Check functional level and DC operating systems
(Get-ADDomain).DomainMode
Get-ADDomainController -Filter * | Select-Object HostName, OperatingSystem

Design decisions

Settle three questions before creating anything.

Scope of the silo. Start with one silo for Tier 0 human administrators and the devices they use. Resist adding service accounts, Entra Connect sync accounts or backup accounts in the first iteration. Their authentication patterns are harder to predict, and a failure there is an outage rather than an inconvenienced admin. A second silo for Tier 0 service accounts can follow once the first has been stable for a few months.

TGT lifetime. A shorter TGT limits how long a stolen ticket can be replayed. Four hours (240 minutes) matches the Protected Users default and fits an admin work session. Going shorter mostly produces re-authentication prompts without meaningful gain; going longer undoes part of the benefit. If an account is in both Protected Users and a policy, the policy's lifetime applies.

Which direction to restrict. Allowed to authenticate from on the user policy is the tiering control: it keeps Tier 0 credentials off lower-tier devices. Allowed to authenticate to on a computer or service policy is the reverse: it restricts which accounts may obtain service tickets to Tier 0 servers. That second control is powerful for dedicated Tier 0 systems such as a PAM vault or an offline CA's management host, but on DCs it would block every user in the domain, so do not apply it there.

Build the Tier 0 silo in audit mode

The pattern: one silo, one user policy that restricts where Tier 0 users may authenticate from, and one computer policy for the Tier 0 devices themselves (usually lifetime only, no restrictive conditions).

$siloName = 'Tier0-Silo'

# Condition: the device requesting the TGT must be a member of the Tier0 silo
$fromSilo = "O:SYG:SYD:(XA;OICI;CR;;;WD;(@USER.ad://ext/AuthenticationSilo == `"$siloName`"))"

# User policy: 4-hour TGT, only from silo devices. No -Enforce yet: audit mode.
New-ADAuthenticationPolicy -Name 'Tier0-Users' `
    -Description 'Tier 0 admins: TGT only from Tier 0 devices' `
    -UserTGTLifetimeMins 240 `
    -UserAllowedToAuthenticateFrom $fromSilo `
    -ProtectedFromAccidentalDeletion $true

# Computer policy for PAWs and Tier 0 servers: no conditions, default lifetime
New-ADAuthenticationPolicy -Name 'Tier0-Computers' `
    -Description 'Tier 0 devices' -ProtectedFromAccidentalDeletion $true

# Silo in audit mode
New-ADAuthenticationPolicySilo -Name $siloName `
    -UserAuthenticationPolicy 'Tier0-Users' `
    -ComputerAuthenticationPolicy 'Tier0-Computers' `
    -ServiceAuthenticationPolicy 'Tier0-Computers' `
    -ProtectedFromAccidentalDeletion $true

The @USER in an allowed to authenticate from condition refers to the device account that armors the request, not to the admin. That is intentional, and it is the most common point of confusion when reading these policies.

Assign members

Add Tier 0 users, PAWs, Tier 0 jump servers and, if admins log on to DC consoles, the DCs themselves. Each member needs both steps:

$members = @(
    Get-ADGroupMember 'Tier0-Accounts' | ForEach-Object { Get-ADUser $_ }
    Get-ADGroupMember 'Tier0-Devices'  | ForEach-Object { Get-ADComputer $_ }
)

foreach ($m in $members) {
    # Permit the account in the silo (msDS-AuthNPolicySiloMembers)
    Grant-ADAuthenticationPolicySiloAccess -Identity $siloName -Account $m
    # Point the account at the silo (msDS-AssignedAuthNPolicySilo)
    Set-ADAccountAuthenticationPolicySilo -Identity $m -AuthenticationPolicySilo $siloName
}

Do not add service accounts, gMSAs or break-glass accounts to this silo during the first phase. Break-glass accounts should stay outside the silo, heavily monitored, with their password in a physical safe.

Collect audit data

Silo decisions are logged on DCs in dedicated operational logs that are disabled by default:

# Run on every DC
wevtutil sl "Microsoft-Windows-Authentication/AuthenticationPolicyFailures-DomainController" /e:true
wevtutil sl "Microsoft-Windows-Authentication/ProtectedUserFailures-DomainController" /e:true

In AuthenticationPolicyFailures-DomainController, the audit-mode events are 305 (a TGT would have been refused by the policy) and 306 (a service ticket would have been refused). Their enforced counterparts are 105 and 106, and 101 records an NTLM authentication blocked by a policy. Let audit mode run for at least one full admin cycle, including month-end tasks, patch nights and on-call rotations.

Get-ADDomainController -Filter * | ForEach-Object {
    Get-WinEvent -ComputerName $_.HostName -FilterHashtable @{
        LogName = 'Microsoft-Windows-Authentication/AuthenticationPolicyFailures-DomainController'
        Id      = 305, 306
    } -ErrorAction SilentlyContinue
} | Select-Object MachineName, TimeCreated, Id, Message

Every hit is either an admin authenticating from a non-Tier 0 device (a process problem to fix) or a Tier 0 device missing from the silo (a membership problem to fix).

Enforce

Once the audit log is quiet, enforce the policy first, then the silo:

Set-ADAuthenticationPolicy -Identity 'Tier0-Users' -Enforce $true
Set-ADAuthenticationPolicySilo -Identity 'Tier0-Silo' -Enforce $true

Enforce on a Tuesday morning with an admin at a DC console, not on a Friday evening. If something goes wrong, -Enforce $false on the silo takes effect as soon as it replicates.

A policy with allowed to authenticate from conditions also blocks NTLM network logons for its users unless you explicitly allow them with the policy's UserAllowedNTLMNetworkAuthentication setting. Leave that off for Tier 0.

Monitor the silo itself

Once enforced, the silo is a Tier 0 control, and tampering with it is an attack signal. With Audit Directory Service Changes enabled on DCs, changes to msDS-AssignedAuthNPolicySilo on accounts and to the policy and silo objects in the configuration partition generate event 5136. Alert on any such change outside a change window, and on any enforced-mode event 105 or 106 for a Tier 0 account, which means either a mistake or someone trying to use a Tier 0 credential from the wrong place.

Verify

# Silo configuration and enforcement state
Get-ADAuthenticationPolicySilo -Identity 'Tier0-Silo' -Properties * |
    Select-Object Name, Enforce, UserAuthenticationPolicy, ComputerAuthenticationPolicy, msDS-AuthNPolicySiloMembers

# Every Tier 0 account is assigned to the silo
Get-ADGroupMember 'Tier0-Accounts' | Get-ADUser -Properties msDS-AssignedAuthNPolicySilo |
    Where-Object { -not $_.'msDS-AssignedAuthNPolicySilo' } | Select-Object SamAccountName
# Should return nothing

Then test functionally. From a PAW, sign in with a Tier 0 account and run klist: the TGT's end time should reflect the 240-minute lifetime. From a standard workstation, attempt a runas /user: with the same account: it must fail, and the DC should log event 105 alongside a 4768 failure with result code 0xC (KDC_ERR_POLICY). Record both tests as evidence for audits.

What it breaks

• Admins on non-Tier 0 devices: any Tier 0 logon from a laptop, a Tier 1 server or a helpdesk workstation fails. That is the goal, but it surfaces every undocumented habit on day one.
• Scheduled tasks and services running as silo members fail if they run on a device outside the silo. Move them to gMSAs outside Tier 0 or bring the host into Tier 0 deliberately.
• Non-Windows and legacy clients without armoring support (older Linux, macOS tools, network appliances using an admin's AD credentials) cannot authenticate as silo members.
• Cross-forest administration: device claims do not transit trusts by default, so Tier 0 admins of one forest cannot be silo-restricted to devices in another forest without additional claim transformation work.
• DC recovery: in a forest recovery where DCs are rebuilt, the silo still applies. Keep a documented break-glass account outside the silo, as covered in the forest recovery plan.

Related reading: Kerberos and authentication for the armoring and encryption layer underneath silos, privileged access workstations for the devices you place in the silo, and the Tier 0 area overview.