As we’ve dived into the Protected Users security group, we’ll dive into Authentication Policies and Authentication Policy Silos today, as these latter two features are greatly intertwined with the functionality of the Protected Users group and have much in common. But, as we’ll find out, Authentication policies and authentication policy silos also differ greatly from the Protected Users security group.

So, let’s look at Authentication Policies and Authentication Policy Silos!

Introduction

Let’s start with some questions.

What if you wanted to control authentication settings like the Ticket Granting Ticket (TGT) lifetime, but are not happy with the built-in TGT lifetime settings (10 hours and 7 days, respectively) nor the TGT Lifetime settings for Protected Users (4 hours both)?

Or, what if you wanted to control the authentication settings for computer accounts or even service accounts? Since you can’t use membership of the Protected Users group for these types of accounts, how you would you do it?

Or even when the functionality of the Protected Users group perfectly fitted your needs, how would you control where members would actually be allowed to log on. Membership to the Protected Users group doesn’t govern that.

Introducing Authentication Policies

Using Authentication Policies in Active Directory Domain Services, you can set the Ticket Granting Ticket (TGT) lifetime. Also, you can define criteria for device accounts before users are able to sign in with a password or a certificate, and, of course, you can define criteria that users and devices need to meet to authenticate to services running as part of the account.

Introducing Authentication Policy Silos

While the Protected Users group has a pre-defined scope, Authentication Policies do not. Authentication Policy Silos in Active Directory Domain Services perform the scoping for Authentication Policies.

Note:
Alternatively, you can set an Authentication Policy only on a set of objects without using an Authentication Policy Silo, but this is not nearly as effective and might make your Active Directory Domain Services needlessly more complex to manage.

The cool thing about Authentication Policies and Authentication Policy Silos, is that unless computer or user account objects meet the criteria in the rules, a Ticket Granting Ticket (TGT) will not be issued. At all.

Requirements

To gain access to Authentication Policies and Authentication Policy Silos, you need to fulfill a couple of requirements:

• All Domain Controllers in the Active Directory domain must be running at least Windows Server 2012 R2.
• The Active Directory Domain Functional Level (DFL) must be Windows Server 2012 R2.

Note:
There are no requirements on the Active Directory Forest Functional Level (FFL).

• Domain Controllers must be configured to support Dynamic Access Control (DAC) by deploying the required settings in a Group Policy Object (GPO) targeting the Domain Controllers Organizational Unit (OU):

Enable the KDC support for claims, compound authentication, and Kerberos armoring group policy setting under Computer Configuration, Administrative Templates, System and KDC. After you enable it, its option should automatically get configured as Supported:

• After you’ve enabled the Domain Controllers to support Dynamic Access Control (DAC), domain-joined Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2 installations (and up) must be configured to support Dynamic Access Control (DAC), including Kerberos compound claims (device claims).

This is easily achieved by enabling the Kerberos client support for claims, compound authentication, and Kerberos armoring group policy setting under Computer Configuration, Administrative Templates, System and Kerberos:

Deploy this setting in Group Policy Objects (GPOs) targeting the computer accounts throughout the Active Directory domain.

Setting Authentication Policies

Let me show you how to use Authentication Policies and Authentication Policy Silos in an example scenario where we’ll restrict admin access to certain workstations.

Authentication Policies and Authentication Policy Silos are created in the Active Directory Administrative Center (dsac.exe).

Note:
You cannot manage authentication policies and authentication policy silos in Active Directory Users and Computers (dsa.msc).

Creating the policies and silos

First, let’s create the authentication policy silo and authentication policy. This will provide the groundwork for scoping.

1. Open the Active Directory Administrative Center (dsac.exe).
2. Click on Authentication in the left pane.
3. In the main pane select Authentication Policies. Then, in the Tasks pane, click on New under Authentication Policies. Select Authentication Policy from the context menu.
4. Provide a Display name:. For this scenario I’ll choose Restrict Access for Admins, because that closely resembles what we’re trying to achieve here. Of course, you can use a more corporate naming scheme for the display names. Optionally, the Description: field might by the right place to note down incident registration numbers, etc.
5. Optionally, you can limit the lifetime for TGTs for objects in scope for this Authentication Policy. To do this, in the left pane, click User. Select the Specify a Ticket Granting Ticket lifetime for user accounts. option. Then, select a value between 45 and 2147483647 (2^31-1) for the Ticket-Granting-Ticket Lifetime (minutes):.
6. Press OK.
7. In the main pane select Authentication Policy Silos. Then, in the Tasks pane, click on New under Authentication Policy Silos. Select Authentication Policy Silo from the context menu.
8. Provide a Display name:. For this scenario I’ll choose Restrict Access for Admins, because that closely resembles what we’re trying to achieve here.
9. Select Enforce silo policies instead of Only audit silo policies (default).
10. Under Permitted Accounts, add the computer objects for admin workstations and the user objects for admin people.
11. Under Authentication Policy select Use a single policy for all principals that belong to this authentication policy silo.. Then, for The authentication policy that applies to all accounts in this silo: select the previously created Authentication Policy from the drop down list.
12. Press OK.

Assigning the policy

As you’ll notice in the latest screenshot, the Authentication Policy Silo is not applied at this point. Also, you won’t see check marks automatically appear in that column. We are assigning the policy silo manually. Assuming you still have the Active Directory Administrative Center (dsac.exe) open, perform these actions:

1. Click on Authentication in the left pane.
2. Under Authentication Policy Silos, select the Authentication Policy Silo we’ve created. Then, double-click it or right-click it and select Properties from the context menu.
3. Go to the Permitted Accounts section.
4. Double-click on the first item in the list of Permitted Accounts. This will open the Properties of the object.
5. In the left pane click on Silo to go to the Authentication Policy Silo portion of the properties of the object.
6. Under Authentication Policy Silo, select the Assign Authentication Policy Silo option. Then, from the drop-down list select the name for Authentication Policy Silo: you would want to apply.
7. Click OK.
8. Perform these actions for all objects in the list of Permitted Accounts. For these objects, this will set the msDS-AssignedAuthNPolicySilo attribute:

Note:
While you can use the SHIFT and CTRL buttons in the list of Permitted Accounts in the Authentication Policy and press ENTER to access their properties, you can’t assign Authentication Policy Silos to multiple objects through the Graphical User Interface (GUI). To this purpose use the Set-ADAccountAuthenticationPolicySilo PowerShell Cmdlet.

Now, as mentioned before we started to created the Authentication Policies and Authentication Policy Silos, unless the objects meet the criteria in the rules, a Ticket Granting Ticket (TGT) will not be issued. Thus, when you try to authenticate to a domain-joined Windows client, that is not in scope for the Authentication Policy Silo we created (for instance, a device other than the Admin01 through Admin04 computers in scope), you will not be able to log on with the objects in scope (the Jos Haarbos and Hans Worst user objects):

Concluding

Authentication Policies and Authentication Policy Silos enable you to flexibly define policies for user accounts, service accounts and computer accounts for authentication. You can control the scope of these policies, where accounts can log on and to which services they can authenticate to, as well as TGT settings. All within the comfort of the Active Directory Administrative Center (dsac.exe) and PowerShell.

Related blogposts

Ten things you need to be aware of before using the Protected Users Group
New features in AD DS in Windows Server 2012 R2, Part 2: Protected Users
New features in AD DS in Windows Server 2012 R2, Part 1: Introduction

Further reading

Authentication Policies and Authentication Policy Silos
Authentication Policies and Authentication Silos – Restricting Domain Controller Access