Introduction
One of the recommendations to protect privileged accounts from credential theft is to prevent administrative accounts from exposing credentials to unsecure computers, on this post I will show you how to protect administrative accounts using Authentication Policies and Silos.
Definition
A quick definition from Microsoft web site.
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.
Scenario
The company Lab.dz is following MS best practices 😉 . The environment is configured with tiering model and T0 Admins are using dedicated administrative workstation to access T0 Servers. For more information about tiering model please read the article.
Ok, let’s discover lab.dz environment. Lab.dz contain one domain controller DC01, two member servers MEM01 and MEM02 and some client computers, domain admins are using a dedicated administrative workstation named PAW0 to access domain controllers. During the next steps we will configure Authentication policy and Silos to ensure that domains admins are unable to authenticate to any device except DC01 and PAW0.
Here the input we need.
Who are T0 Admins? two administartors Amine and Mehdi.
On which computers Amine and Mehdi should have access? It’s easy 🙂 The domain controller DC01 and the administartive workstation PAW0.
Step by Step
Now we will go through a step by step to configure Authentication Policy and Silos.
1) Ensure that domain Functional level is 2012 R2 or higher.
Lab.dz domain has DFL of 2016.
2) Configure domain controllers KDC to support claims, compound authentication and Kerberos armoring.
All what we need to do is to enable the policy setting: KDC support for claims, compound authentication and Kerberos armoring under the path.
Computer Configuration\Policies\Administrative Templates\System\KDC
In my lab environment, the setting is enabled on default domain controller policy.
You can confirm application of the setting on domain controllers by checking the attribute msDS-SupportedEncyptionTypes of the krbtgt account. The attribute will take the value of 5000.
3) Configure client computers with the setting Kerberos client support for claims, compound authentication and Kerberos armoring.
All what we need to do here is to enable the policy setting: Kerberos client support for claims, compound authentication and Kerberos armoring under the path.
Computer Configuration\Policies\Administrative Templates\System\Kerberos
In my lab environment, the setting is enabled on default domain policy.
4) Configure the Authentication Policy and the Authentication Policy Silo.
Open Active Directory Administrative Center.
Under the Authentication node, right click Authentication Policies and create a new authentication policy.
Give it a name and make sure to select Enforce Policy restriction. in my example the authentication policy is named T0-Authentication-Policy.
On the User Sign On part you can optionally reduce user TGT lifetime. In my example I reduced TGT lifetime to two hours. Click OK to create the authentication policy.
Under the Authentication node, right click Authentication Policy Silos and create a new authentication policy silo.
Give it a name and make sure to select Enforce silo policies. in my example the authentication policy silo is named T0Silo.
On the Permitted Accounts part add the accounts that need to be member of the silo.
On the Authentication Policy part:
- Select Use a single policy for all principals that belong to this authentication policy silo
- Select T0-Authentication-Policy and click OK to create to create the authentication policy slilo.
We will go through properties of the accounts: DC01, PAW0, Amine, Mehdi and assign them T0Silo Authentication Policy Silo. I will show the steps for DC01.
Right click DC01 and click properties.
Assign T0Silo and click OK.
If you return to the authentication policy silo T0Silo you will see the green mark indicating that accounts are assigned.
Finally, go back to T0-Authentication-Policy.
Right click and click properties.
On User Sign On part click Edit
Click Add a condition.
Put the condition as on the screenshot below and click OK.
Click OK to validate the condition.
We must restart the computers member of the silo T0Silo so computers will detect they are on T0Silo (restart will force computer re-authentication with AuthenticationSilo claim).
After restarting DC01 and PAW0, the user Mehdi can logon on DC01 and PAW0 but not on MEM01 and MEM02.
Troubleshooting
There is a specific log named AuthenticationPolicyFailures-DomainController which is disabled by default. The log is located under this path:
Application and Services Logs –> Microsoft –> Windows –> Authentication
We enable this log on DC01. This should be enabled on all domain controllers.
As an example, below the event 105 indicating user mehdi unable to authenticate on the device PAW0.
This was before restarting the computer PAW0 🙂 . The computer doesn’t have the authenticationsilo claim yet 😉 . This was resolved by restarting PAW0.
Another point help in troubleshooting is to have the visibility about user and device claims. This can be enabled easily by using Advanced Audit Policy Configuration. On Default Domain Policy I enabled Audit User/Device claims as you can see on the screenshot below.
As an example, on PAW0 we can see the events 4626 related to User/Device claims.
Event 4626 indicating computer claims, this usually happen after computer restart.
Account Name: PAW0$
User Claims: ad://ext/AuthenticationSilo <String>: “T0Silo”
Event 4626 indicating user claims, this usually happen after user logon.
Account Name: Mehdi
User Claims: ad://ext/AuthenticationSilo <String>: “T0Silo”
To display user claims you can simply type whomai /claims
Conclusion
Authentication policy and Authentication policy silos is the strongest way to prevent your high privilege accounts from being used on unsecure computers. I will recommend protecting all domain administrators with authentication policy except the built-in administrator. This account will give you the ability to authenticate on your domain controllers in case of problems with authentication policy and silos. But what about the built-in administrator ? it doesn’t need protection from credential theft !!! The best protection for the built-in administrator is to not using it for day to day administration tasks.
Thanks for reading 🙂
You must log in to post a comment.