Group and Conquer: Policy Silos

One of the most common use cases for authentication policies is that of creating administrative tiers or application silos, where a well-defined set of user and service accounts are allowed to log on to a well-defined set of computers. You map such silos with authentication policy silos, to which you can assign users, managed service accounts (gMSA), and computers. The silo then determines which authentication policies apply to the silo members: Either one policy for all types of accounts or separate policies per account type.

Policies and silos can be assigned to managed service accounts by PowerShell only. The Set-ADAccountAuthenticationPolicySilo cmdlet can be used for both operations. In both cases, you have to use the -Identity argument to specify the account to assign. The second parameter is either -AuthenticationPolicy or -AuthenticationPolicySilo, depending on the desired assignment. Authentication policies can be assigned to the same security principal both directly and through policy silos (Figure 3). Policies from the silo always take precedence over the directly assigned policies.

Figure 3: A silo provides the link between accounts and policies.

Another useful aspect of silos is the option to use them as a criterion in selecting allowed users and computers (e.g., for issuing service tickets). For example, you can authorize a user account within its own silo to log in interactively. However, if a service is running under that account, only devices from another specific silo can authenticate to that service.

Build an Island

The simplest deployment scenario for authentication policies is to build an authentication silo – that is, a group of computers and a group of users who are the only ones who can log in to those computers (and only there). The following examples show how you can achieve this:

• Create an authentication Island policy.
• Create an authentication policy silo Island silo and set the Island policy for all account types.
• Assign the designated computers and users to the Island silo.
• Edit the Island policy and set the TGT lifetime for user accounts to an appropriate value (600 minutes is the AD default; 240 minutes is the default for Protected Users).
• In the Computer section, create the Access Control Conditions User – Authentication Silo – equals – Island silo .
• Create the same condition in the User section.

As of now, only the Island users can log in to Island computers; all others will receive an error message indicating the authentication firewall. When Island users try to access machines outside their island, they get an error message (Figure 4). For the settings to take effect, you have to restart the Island computers.

Figure 4: Users cannot access computers outside the authentication policy silo.

Monitoring and Troubleshooting

Microsoft has provided a special event log channel Microsoft\Windows\Authentication for monitoring the Kerberos protection functionality. On the domain controllers, the authentication attempts of the protected users are recorded in the log channels Microsoft\Windows\Authentication\ProtectedUserSuccesses-DomainController and Microsoft\Windows\Authentication\ProtectedUserFailures-DomainController .

Failed authentication policy activity can be found in the Microsoft\Windows\Authentication\AuthenticationPolicyFailures-DomainController channel. Regardless of whether the Protected Users group contains members or you have created authentication policies, these protocols are disabled for now. You should also enable them for troubleshooting purposes only by selecting Enable Log from the context menu of the respective event log. Alternatively, you can issue the following PowerShell command on each domain controller:

$logname = "Microsoft-Windows-Authentication/ProtectedUserSuccesses-DomainController"
$log = Get-WinEvent -ListLog $logname
$log.IsEnabled = $true
$log.SaveChanges()

All three channels can be enabled similarly. On the affected member machines, you need to enable the client event log. Again, the fastest way to do this is with PowerShell:

$logname = "Microsoft-Windows-Authentication/ProtectedUser-Client"
$log = Get-WinEvent -ListLog $logname
$log.IsEnabled = $true
$log.SaveChanges()

The logs are very verbose, so their size can quickly reach the default configured limit of 1MB if you have a large number of protected accounts. You can set the size immediately on enabling by adding the $log.MaximumSizeInBytes = 128MB line before SaveChanges() in the PowerShell code above. This addition increases the maximum log size to 128MB. Other useful tools for troubleshooting Kerberos authentication include klist [2] and whoami [3] – specifically, whoami /claims in this case.

When troubleshooting, always keep in mind that authentication policies, as the name suggests, control authentication. All other mechanisms evaluated after successful authentication, such as the revocation of local logon rights or the logon restrictions in AD (attributes logonHours and userWorkstations), remain in force.