Active Directory Authentication Policy Silos: Audit Kerberos Scope Before Enforcement

Active Directory authentication policies and authentication policy silos help contain privileged identities to the users, computers, and services that need them. A policy can define Kerberos ticket lifetime and authentication access conditions; a silo groups accounts and associates the relevant user, computer, or service policies. In audit mode, domain controllers log potential restriction failures without denying the authentication. In enforced mode, a policy can deny ticket requests that do not meet its rules. This is a high-impact identity change: an incorrect device or service restriction can block administrative access, automation, or a production service.

Do not confuse authentication policy silos with fine-grained password policies, Group Policy OUs, or the Protected Users group. They operate on different parts of authentication. They are also not a simple toggle to “make admins safer”: the Kerberos path, policy scope, silo membership, account-to-silo access, DC support, and authentication flow all matter. Begin with a read-only inventory and audit-mode pilot, preserve a recovery path, and enforce only after real logon and service-ticket use has been observed across a complete operational cycle.

Understand the objects and enforcement boundary

An authentication policy defines settings for account types and can include TGT lifetime and access conditions. A silo is an Active Directory object that groups user accounts, computer accounts, and managed service accounts under a common protection model. Silos can associate separate policies for users, computers, and services. An account must be granted access to the silo and linked directly or through silo membership in the supported manner. Assigning a policy object alone does not prove the account will receive the intended restrictions.

Audit and enforcement are materially different. A non-enforced policy/silo allows the authentication flow to continue while domain controllers log where policy conditions might block it. An enforced policy can deny Kerberos authentication that violates the configured access conditions. Authentication policies can restrict TGT lifetime and service access, and the exact checks depend on the request type and Kerberos protection/armoring conditions. Map the actual users, devices, service identities, and SPNs before writing an access descriptor.

The feature is part of Active Directory Domain Services and is documented for Windows Server 2016 through 2025. Validate functional-level and domain-controller prerequisites against the current Microsoft protected-accounts guidance for the deployed forest. Ensure domain controllers, clients, service accounts, and application protocols use supported Kerberos paths. Do not assume that NTLM fallback has the same restriction semantics; inventory legacy protocols and treat them as separate exposure to remediate.

Build a principal and service dependency inventory

For each proposed silo, identify human privileged accounts, workstation or PAW accounts, server computer accounts, managed service accounts, services that use those identities, allowed logon devices, target servers, SPNs, delegated access, and emergency access. Include scheduled tasks, service control managers, IIS application pools, backup agents, remote management, cluster operations, and offline recovery. A policy that allows an administrator to obtain a TGT from a privileged workstation can still deny a later service ticket to a required target if the target account/device relationship is not included.

Capture current Kerberos behavior before changing policy: account types, device names, target service names, ticket lifetimes, authentication methods, and relevant domain-controller events. Use sign-in and service telemetry to find infrequent maintenance jobs that run monthly or during a disaster. Ask application owners to confirm all service identity dependencies; a graph based only on recent logs can miss a dormant recovery path.

Import-Module ActiveDirectory -ErrorAction Stop

Get-ADAuthenticationPolicy -Filter * |
    Select-Object Name, Enforce, UserTGTLifetimeMins,
        ComputerTGTLifetimeMins, ServiceTGTLifetimeMins

Get-ADAuthenticationPolicySilo -Filter * -Properties * |
    Select-Object Name, Enforce, UserAuthenticationPolicy,
        ComputerAuthenticationPolicy, ServiceAuthenticationPolicy

This is an inventory, not proof that every account is correctly assigned. Validate available properties with the Active Directory module on the domain and confirm the schema/version before automating a report. Review policy and silo ACLs as well as membership. Protect the export because it reveals privileged identity topology and service relationships.

Design the policy in audit mode

Write the intended allowed-from and allowed-to relationships before configuring policy. Use least-privilege resource groups and administrative workstations, and ensure every account type gets the correct policy. TGT lifetime reductions may shorten the usable ticket window but can increase authentication traffic and affect long-running tasks; measure the effect and validate renewal semantics. Use an approved policy design and avoid copying an SDDL from another domain without translating each SID and verifying its meaning.

Authentication policy objects are created in audit mode by default unless -Enforce is specified. A small test policy with a deliberately chosen TGT lifetime can be created under -WhatIf for change review; the lifetime value below is an example, not a universal recommendation.

$policyName = 'Tier0-User-Audit'
$policy = New-ADAuthenticationPolicy `
    -Name $policyName `
    -UserTGTLifetimeMins 60 `
    -ProtectedFromAccidentalDeletion $true `
    -WhatIf

After review, create the approved policy without -WhatIf, then inspect it from a known domain controller. Do not add authentication allowlists until their SDDL and access semantics are independently reviewed. Use the ADAC protected-accounts workflow or a peer-reviewed script generated against documented objects; do not paste a broad “Domain Users” or “Authenticated Users” descriptor to silence audit findings.

Create or update a silo with Enforce disabled during the audit period. Before associating a principal, grant the account permission to join the silo, then assign the user/computer/service policy and silo. These are directory writes. Keep them scoped to a pilot account and pilot device, use -WhatIf where supported, and verify the target object GUID and domain before applying.

$testUser = Get-ADUser -Identity 'adm.pilot'
$siloName = 'Tier0-Users-Audit'
$policyName = 'Tier0-User-Audit'

Grant-ADAuthenticationPolicySiloAccess `
    -Identity $siloName -Account $testUser -WhatIf

Set-ADAccountAuthenticationPolicySilo `
    -Identity $testUser `
    -AuthenticationPolicySilo $siloName `
    -AuthenticationPolicy $policyName `
    -WhatIf

The preview does not validate the policy’s security descriptor or prove the account’s operational access. Follow Microsoft’s supported ordering and silo configuration procedure, and apply the real change only after approval. Do not assign a production administrator or service identity to an enforced silo simply to test whether the policy object exists.

Observe audit events across domain controllers

Audit-mode evidence is recorded on domain controllers in the Authentication policy failure log. Microsoft documents event 305 for potential TGT restriction failures and event 306 for potential service-ticket restriction failures; enforced-denial events use related IDs such as 105 and 106. The event includes relevant account, device, policy, and silo details. Collect events from every domain controller that handles the pilot’s authentication, account for log retention, and normalize clocks before correlating service requests.

$since = (Get-Date).AddDays(-14)
$logName = 'Microsoft-Windows-Authentication/AuthenticationPolicyFailures-DomainController'

Get-WinEvent -FilterHashtable @{
    LogName = $logName
    Id = 305, 306
    StartTime = $since
} -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, MachineName, Id, Message

Confirm the exact channel name through Event Viewer or wevtutil el on the target domain controller; event-channel display names can vary by Windows release. Collect logs remotely through approved Windows Event Forwarding or SIEM collection rather than querying one DC and assuming it represents the forest. Interpret each event against the account, resource, client, and policy conditions. A clean event log is meaningful only if the pilot generated all expected logon and service-ticket flows and collection was healthy.

Move from audit to enforcement with rollback controls

Establish explicit exit criteria: all critical authentication paths have been observed, expected audit denials have been resolved or accepted, emergency access is tested, help-desk and on-call staff know the recovery procedure, and domain-controller event collection is complete. Run the pilot through patching, backup, service restart, scheduled tasks, remote administration, and a representative failover or disaster-recovery rehearsal. For long-running service identities, include the longest realistic ticket and job lifecycle.

Enforce in rings by a specific silo and account type. Change one policy at a time and preserve the prior policy and silo state. Re-test a known allowed route and known denied route, inspect DC events, and monitor service health. A temporary rollback may require clearing enforcement or changing account-to-silo association through supported AD cmdlets, followed by replication and renewed ticket acquisition. Already-issued Kerberos tickets can outlive a configuration change until expiration or purge; plan how clients and services will obtain new tickets and avoid creating a simultaneous mass sign-out.

Do not remove a protected account from a silo under pressure without confirming the change reaches the domain controllers and the user can obtain the needed tickets. Keep at least one tested break-glass path outside the experimental control, protect it separately, and make its use monitored and approved. Do not let the rollback account become an unmonitored permanent administrator bypass.

Troubleshoot denials by ticket stage

Separate TGT issuance from service-ticket issuance. If a user cannot get a TGT, examine the user’s authentication policy, client device, claims/armoring support, account membership, and DC event. If TGT succeeds but access to a server fails, inspect the service-ticket stage, target service’s computer/service account, SPN, silo restrictions, and the user’s allowed-to-authenticate conditions. A generic application failure can be caused by denied ticket issuance even when network TCP connectivity is healthy.

Compare the affected account with a working peer, including direct policy assignment, silo membership, global security group membership, target SPNs, computer account identity, and policy enforcement flags. Verify AD replication and query the account from more than one relevant DC. Do not “fix” a denial by broadening the allowed device/resource SDDL without tracing which check failed. Preserve the event and the exact policy version as evidence.

Maintain silos as an identity control

Review membership, account-to-silo permissions, access descriptors, and associated user/computer/service policies at every privileged-access review. Remove retired computer accounts and services through their normal lifecycle, and update policies when PAW or server names change. Protect silo and policy objects from accidental deletion and alert on membership, enforcement, access-control, and policy changes. Keep the audit duration long enough to include rare but business-critical workflows.

Authentication policy silos are one layer in a privileged-access architecture, not a substitute for separate admin accounts, tiering, credential protection, device hardening, Protected Users, managed service accounts, and monitoring. Keep policy intent, exception owners, tested rollback, and event evidence together. Reassess the design after domain functional-level changes, application modernization, Kerberos configuration changes, or new administrative platforms.

Related:

Sources: