Authentication policies and silos: restricting where Tier 0 accounts can sign in
Logon restrictions applied through Group Policy depend on the target machine. Authentication policies and silos move the control to the domain controller itself: a domain administrator trying to authenticate from a device outside the silo simply does not get a ticket. A powerful measure that requires prerequisites and an audit phase.
The principle
Available since Windows Server 2012 R2, authentication policies define conditions that the Key Distribution Center (KDC) enforces when issuing Kerberos tickets. An authentication policy silo groups user, computer and service accounts and associates them with one or more policies.
The typical use case: create a "Tier 0" silo containing domain administration accounts, domain controllers and privileged access workstations, then define a policy that only lets those accounts obtain a TGT when they authenticate from a computer in the same silo. A stolen administrator credential replayed from a user workstation becomes useless for Kerberos.
Prerequisites
- Domain functional level of at least Windows Server 2012 R2.
- KDC support for claims and Kerberos armoring, enabled through Group Policy on domain controllers ("KDC support for claims, compound authentication and Kerberos armoring").
- Client-side support, enabled through Group Policy on computers in the silo ("Kerberos client support for claims, compound authentication and Kerberos armoring").
Kerberos armoring (FAST) protects the pre-authentication exchange using the computer's ticket. That is what lets the KDC reliably know which machine the request comes from and evaluate the silo condition. Without armoring on the device, the condition cannot be checked.
Designing the policy
An authentication policy lets you define, among other things:
- the TGT lifetime for the accounts concerned;
- access control conditions on the device the user authenticates from, such as membership of a given silo;
- conditions on which accounts may obtain service tickets for computers in the silo.
Keep it simple: one Tier 0 silo containing named administrative accounts, domain controllers and privileged access workstations. Tier 0 servers other than DCs, such as those hosting a certification authority or a federation service, should be added if they are administered by those accounts.
Kerberos only. Authentication policies apply to Kerberos. To prevent fallback to NTLM, add the same accounts to the Protected Users group. The two measures complement each other.
Start in audit mode
Each policy and silo can be set to audit rather than enforce. In audit mode, the KDC issues tickets but logs requests that would have been denied. These events are recorded on domain controllers in dedicated logs under Microsoft, Windows, Authentication, which must be enabled first.
The approach we recommend:
- enable the prerequisites on domain controllers, then on privileged access workstations;
- create the silo and policy in audit mode and assign accounts and machines;
- analyse the logs for several weeks, covering at least one full operating cycle;
- fix legitimate but unplanned uses: scheduled scripts, consoles installed elsewhere, on-call interventions;
- switch to enforcement, keeping an emergency account outside the silo, documented and monitored.
Limitations to know
Silos control where an account obtains a TGT, not what happens on a compromised machine inside the silo. They therefore replace neither PAW hardening nor monitoring of configuration changes: an attacker with domain admin rights could remove an account from the silo. Monitor changes to policy and silo objects and to account assignment attributes.
What an audit checks
- whether authentication policies and silos exist, and their mode (audit or enforced);
- whether Kerberos armoring is enabled on the KDC and on the relevant clients;
- coverage of Tier 0 accounts by a silo;
- consistency between silo machines and the devices actually used for administration;
- logging of denials and monitoring of silo changes.