Summary: Microsoft PFE, Ian Farr, talks about using Windows PowerShell to handle Authentication Policy Silos.

Microsoft Scripting Guy, Ed Wilson, is here. This weekend we have a two-part series from Ian Farr. To read more of Ian's previous guest posts, see these Hey, Scripting Guy! Blog posts.

Legend has it that there exists a great, gilded tome of Active Directory wisdom, maintained by learned elders with long, white beards and silver sandals…

Rumour has it that I might have just made that up!

If such a book were to exist, it should contain the following advice:

• The Domain Admins group should contain a small number of secondary logon accounts for trusted individuals.
  This is known.
• Enterprise Admins and Schema Admins groups should be empty and only populated when required.
  This is known.
• Members of high-privileged groups should only log on to selected servers, for example, enterprise admins only log on to domain controllers.
  This is known.

And it’s the last point that today’s post is about: How do we define and enforce the scope of authentication for high-privileged accounts? The answer lies in new functionality introduced in Windows Server 2012 R2: Authentication Policy Silos.

Here’s what the official documentation has to say about Authentication Policy Silos:

“…Authentication Policy Silos and the accompanying policies provide a way to contain high-privilege credentials to systems that are only pertinent to selected users, computers, or services. Silos can be defined and managed in Active Directory Domain Services (AD DS) by using the Active Directory Administrative Center and the Active Directory Windows PowerShell cmdlets…”

 

Enter Windows PowerShell

Hmmm…Windows PowerShell cmdlets! I wrote a short post about identifying the new cmdlets available in the Active Directory module for Windows PowerShell in Windows Server 2012 R2. If you are interested in learning more, read Cmdlets Roasting on an Open Fire. Here are the cmdlets in all their glory:

I’m going to focus on these cmdlets today:

• New-ADAuthenticationPolicy
• Set-ADAuthenticationPolicy
• New-ADAuthenticationPolicySilo
• Grant-ADAuthenticationPolicySiloAccess
• Get-ADAuthenticationPolicySilo
• Set-ADAccountAuthenticationPolicySilo

I’ll use them to create an Authentication Policy and associated Authentication Policy Silo to ensure that domain admins can only log on to read-write domain controllers.

Prerequisites

Before we can deploy an Authentication Policy and an Authentication Policy Silo, there are some important prerequisites to mention:

• A domain functional level set to Windows Server 2012 R2.
• Domain controllers need to have the Supported option configured for the “KDC support for claims, compound authentication, and Kerberos armoring” Group Policy.
  This is located at: Computer Configuration/Policies/Administrative Templates/System/KDC.
• Clients need to have the “Kerberos client support for claims, compound authentication, and Kerberos armoring” Group Policy enabled.
  This is located at: Computer Configuration/Policies/Administrative Templates/System/Kerberos.

Protected users

It’s also recommended that high-privileged accounts be members of the Protected Users security group. This group has proactive security enhancements designed to prevent credential theft. Members of this group will not be able to:

• Authenticate with NTLM.
• Use DES or RC4 encryption types in Kerberos preauthentication.
• Be delegated with unconstrained or constrained delegation.
• Renew the Kerberos ticket-granting-tickets (TGTs) beyond the initial four hour lifetime.

Here’s how I added my domain admins to the Protected Users group:

$PrivUsers = Get-ADGroupMember -Identity "Domain Admins"

Add-ADGroupMember -Identity "Protected Users" -Members $PrivUsers

   Note  My demonstration assumes that my Domain Admins group contains only secondary logon accounts.

Authentication Policy

With the prerequisites satisfied, the first thing to do is create an Authentication Policy. This defines Kerberos TGT properties and access control conditions. There are two parts to the process when using Windows PowerShell. Here’s step one:

New-ADAuthenticationPolicy -Name "Reduced_Admin_TGT" `

                           -Description "Authentication policy to set 2 hour Ticket Granting Ticket for administrators" `

                           -UserTGTLifetimeMins 120 `

                           -Enforce `

                           -ProtectedFromAccidentalDeletion $True

In this example, the New-ADAuthenticationPolicy cmdlet creates a policy called Reduced_Admin_TGT, with a shortened TGT lifetime of two hours for users. The policy is enforced (it is recommended that you use audit mode prior to enforcing the policy).

We now have an Authentication Policy that reduces the TGT lifetime of any user in the scope. Step two adds an access control condition. The condition will associate the Authentication Policy with the Authentication Policy Silo that we’ll create next. Here’s how to add a condition for the user TGT lifetime setting that we configured in the last step:

Set-ADAuthenticationPolicy -Identity "Reduced_Admin_TGT" `

                           -UserAllowedToAuthenticateFrom "O:SYG:SYD:(XA;OICI;CR;;;WD;(@USER.ad://ext/AuthenticationSilo == `"Controlled_Admin_Logon`"))"

In this command, the identity is our new Authentication Policy. However, the next parameter is where it gets interesting…

The UserAllowedtoAuthenticateFrom parameter will associate an access control condition with the User portion of an Authentication Policy (you can also have Service or Computer account settings in an Authentication Policy).

In this instance, we’re adding a reference to the “ad://ext/AuthenticationSilo” claim ID, with a value matching the name of the silo: “Controlled_Admin_TGT”, which we’ll create in the next section. This determines which devices users can authenticate from—that is, only those devices in the silo.

Authentication Policy Silo

Now to create the Authentication Policy Silo. An Authentication Policy Silo has to be associated with an existing Authentication Policy.

New-ADAuthenticationPolicySilo -Name "Controlled_Admin_Logon" `

                               -Description "Authentication policy silo to control the scope of logon for administrators" `

                               -UserAuthenticationPolicy "Reduced_Admin_TGT" `

                               -ComputerAuthenticationPolicy "Reduced_Admin_TGT" `

                               -ServiceAuthenticationPolicy "Reduced_Admin_TGT" `

                               -Enforce `

                               -ProtectedFromAccidentalDeletion $True

Here, we configure all the account classes in the silo (User, Computer, and Service accounts) to reference the “Reduced_Admin_TGT” policy. 

You might be thinking that the reduced TGT lifetime from that policy only applies to User accounts… and you’d be right. However, the silo won’t be configured correctly unless all three account types have an associated policy, despite the policy only containing User settings.

Also, I’m enforcing this policy silo. (You would first choose to only audit Authentication Policy Silo outside of a lab.)

Sanity check one

We have:

• All domain admins in the Protected Users group.
• An enforced Authentication Policy that restricts user TGTs to two hours and has an access control condition that only allows users to authenticate from devices within a named Authentication Policy Silo.
• An enforced Authentication Policy Silo that references the aforementioned Authentication Policy.

Onward, dear reader…

Permit accounts

Now, we grant accounts access to the new silo. First let’s add our domain controllers. These will be the devices the users are allowed to authenticate from.

Get-ADDomainController -Filter {IsReadOnly -eq $False} |

ForEach-Object {Grant-ADAuthenticationPolicySiloAccess -Identity "Controlled_Admin_Logon" -Account $_.ComputerObjectDN}

Here we get all read-write domain controllers and supply each computer object’s distinguished name to the Grant-ADAuthenticationPolicySiloAccess cmdlet, which will update the “Controlled_Admin_Logon” Authentication Policy Silo.

Next, let’s add our domain admins to the Authentication Policy Silo. These users will be subject to the “Reduced_Admin_TGT” Authentication Policy, so they will have a two hour TGT and will only be able to authenticate from devices within the same Authentication Policy Silo.

Get-ADGroupMember -Identity "Domain Admins" |

ForEach-Object {Grant-ADAuthenticationPolicySiloAccess -Identity "Controlled_Admin_Logon" -Account $_.DistinguishedName}

Let’s check on the last two actions.

List the members of the silo:

(Get-ADAuthenticationPolicySilo -Identity "Controlled_Admin_Logon").Members

Here is an example from my lab:

Now, I'm also going to run this command:

(Get-ADAuthenticationPolicySilo -Identity "Controlled_Admin_Logon").Members |

Get-ADObject -Properties msDS-AuthNPolicySiloMembersBL

Here’s the output from my lab:

I get the members of the silo and pipe them to Get-ADObject. I also ask for the msDS-AuthNPolicySiloMemberBL attribute, which has been recently populated with the distinguished name of the silo object as a result of adding the User and Computer accounts to the Authentication Policy Silo. (BL stands for back link.)

Associate the accounts

We’re almost there… the final step is to associate the account objects with the new Authentication Policy Silo. We use Set-ADAccountAuthenticationPolicySilo for that. First let’s update each read-write domain controller account with the assistance of an interesting LDAP filter:

Get-ADComputer -LDAPFilter "(&(&(&(samAccountType=805306369)(useraccountcontrol:1.2.840.113556.1.4.803:=8192))))" |

Set-ADAccountAuthenticationPolicySilo –AuthenticationPolicySilo "Controlled_Admin_Logon"

Next, let’s update each Domain Admin account:

Get-ADGroupMember -Identity "Domain Admins" |

Set-ADAccountAuthenticationPolicySilo –AuthenticationPolicySilo "Controlled_Admin_Logon"

Again, let's check our progress. We'll enumerate the silo members, this time asking for an additional attribute: msDS-AssignedAuthNPolicySilo.

(Get-ADAuthenticationPolicySilo -Identity "Controlled_Admin_Logon").Members |

Get-ADObject -Properties msDS-AuthNPolicySiloMembersBL, msDS-AssignedAuthNPolicySilo

Tomorrow we will go to my lab and do some work.

~Ian

Thanks, Ian. I am looking forward to visiting your lab tomorrow.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy