Step by step guide to setting up Authentication Silos and Policies

What is an Authentication Silo/Policy?

Example Diagram of How the Authentication Silo Works:

In the realm of network security, the protection of sensitive accounts is of paramount importance. Active Directory, a directory service developed by Microsoft for Windows domain networks, offers robust features known as Authentication Silos and Authentication Policies to enhance account security. This article aims to shed light on these two critical features.

What are Authentication Silos?

Authentication Silos are Active Directory objects that encompass users, computers, and services. They serve as a control mechanism to restrict which accounts can be limited based on the organization’s requirements. For instance, an organization might have separate silos for administrators, regular users, and service accounts.

The Role of Authentication Policies

Authentication Policies are rules that outline the authentication restrictions applicable to the members of an authentication policy silo. These policies can specify conditions such as the devices from which members of a certain silo can authenticate or the permissible hours for authentication.
While a policy can be applied to members of an authentication policy silo, it can also be applied independently of silos to restrict a specific account scope. This flexibility allows for the protection of a single account or a small set of accounts by setting a policy on those accounts without necessarily adding the accounts to a silo.

The Synergy of Silos and Policies

The combination of authentication silos and policies provides a mechanism to impose restrictions that safeguard sensitive accounts and minimize the risk of lateral movement by attackers within your network. They form an integral part of a defence-in-depth strategy for protecting your Active Directory environment.
In conclusion, understanding and effectively implementing Authentication Silos and Policies can significantly enhance the security posture of an organization. As cyber threats continue to evolve, leveraging these Active Directory features can provide an additional layer of protection for sensitive accounts, thereby contributing to a more secure and resilient network.

So how to we configure this?

Getting Started

Start by creating a GPO and name it appropriately per your environment, “DC-KDC Hardening” which is applied to the Domain Controller Organisational Unit.  

Domain Controller Group Policy Object

Computer Configuration\Policies\Administrative Templates\System\KDC\

Setting: KDC support for claims, compound authentication and Kerberos armoring

 

Create a client GPO to enable Kerberos Armoring on all client devices, Windows 8 and higher. Link this GPO to all client OU’s. 

Client Side Group Policy Object

Computer Configuration\Policies\Administrative Templates\System\Kerberos\

Setting: Kerberos client support for claims, compound authentication and Kerberos armoring

This will apply the policies to each of the devices in our environment. You may need to do a gpupdate to ensure each device has picked up the new policies. 

To enforce the user account to use Kerberos, it is recommended to add each user to the Protected Users security group. 

User Silos and Policies

Now we can sign in the Domain Controller to start configuring authentication policy silos and authentication policies. 

Open ADAC and browse to Authentication on the left navigation window. 

The following activity is to create a User Silo and User Policy which is specific to user accounts first. We will look at Computer Silos and Policies later on. 

In order to create an authentication silo, you first need to create the policy. So click on authentication policies 

On the right hand ‘Tasks’ navigation pane click on ‘New’ and ‘Authentication Policy’

Give your Policy the appropriate name based on your organisational naming conventions. In this example we are apply this to PKI Users. When testing the operation of this policy you can select ‘Only audit policy restrictions’ to follow event logs to validate access. Enter in a description to explain what the policy does. 

Go to ‘User Sign On’ to specify the access conditions for the policy

Click ‘Edit’ and select ‘Add condition’

Change the third option to the required parameters. This can be AND/OR so depending on what you are required to meet criteria wise.  

NOTE: this is similar to the AND/OR parameters, with ‘Member of any’ the user can be a member of any of the conditions that you stipulate, whereas with ‘Member of all’ they need to be apart of all condition before authentication takes place. 

Specifying the TGT lifetime is not a requirement but it is recommended to specify a value higher than 45 minutes (minimum). If the user account is apart of the “Protected Users” security group, than the default TGT lifetime is 240 minutes. 

Now that a policy has been created, we can now create a Silo. 

Similar steps apply, click on Authentication Policy Silos in the left navigation window and select New, Authentication Policy Silo. 

This is a bit more “lean” than the policies but allows for a central control or “silo” of the policies. Here you can define the permitted accounts that the silo is assigned to, and the Authentication Policy that is applied to the users within the Silo. 

*You have the option to use a single policy or separate policies for Users, Computers and Service Accounts. 

In this example we are only linking a single policy

Click Ok to save the Silo.

Note – once you save the config, you cannot change the name of the silo. 

To apply users to the “Permitted Accounts” section you can do one of two methods.

1. Click Add and search for the user account – you can only specify user, computer or service accounts – no group objects.

 

Then double click on the user account to open up the user in ADAC, then click Silo, check the box to “Assign Authentication Policy Silo and click the dropdown to select the appropriate Silo. Click OK. 

This then applied the Silo to the User Account. Which embeds the Silo into Attribute Editor for the user. Note: this can only be edited by a Domain Admin or appropriately delegated permission. 

When you open the Silo you can then see that the user is now assigned to the Silo

2. You can remove one extra step by going in directly to the user account first and apply the silo though ADAC which will automatically assign the user to the silo. 

 

Testing what we have configured

At this stage we have the silo and policy set to audit mode so we will still be able to access the server. 

So when you login to the server it will go through the motions of the assigned user account silo and show the resultant event in event viewer. 

Open up the Domain Controller and navigate to the Event Viewer

Navigate to “Applications and Services Log à Microsoft à Windows à Authentication à AuthenticationPolicyFailures-DomainControllers” NOTE: You will need to enable this log prior to events being recorded. Right click on the event and click “Enable Log”.

This log will show all the failures of the Silos and Policies with appropriate information to assist with troubleshooting.

This error highlights that a Kerberos ticket will be issued, but it will be denied due to an Authentication Policy being enforced. This error is telling us that the Device is not apart of the conditional access requirements of the User Policy. To fix this, ensure that the Computer Object is part of the Security group we defined in the Authentication Policy 

Once the computer account is in the group there will be no errors appear in the event log – I have cleared the log for this documentation purpose.

Lets turn the silo into Enforced Mode:

Example – If I now try and login to another server using the pki-admin account the following error with appear:

COMPUTER: FITZ-FP

This error stipulates that your account cannot login to this device. The DC will also show an error – again, the device is not apart of the security group. 

Computer Silos and Policies

There is a similar process for computer silos and policies except we are going to explicitly apply the silo to the computers and allow user security groups to have access. Now the reason behind doing it this way is to provide an extra layer of security to the devices. 

 

Computer Policy

You will notice that this section is slightly different from the User Policy, this is due to the actions required. Basically, what we are accomplishing here is allowing user accounts within the above security group to have access to the policy. In testing, adding user accounts to this option defined what accounts the computer object accepted to authenticate. 

Computer Silo

This will produce a new error. This error is stating that the computer is protected by an authentication firewall i.e. Authentication Silo and that the account being used (file-admin) does not have the rights to authenticate. 

Used in conjunction with one another the User Silo will allow a user to only authenticating within its configured jurisdiction and the Computer Silo will only allow a user inside of scope to authenticate to it. 

The primary reason behind configuring the model this way is to restrict where a user account can authenticate to and to also stop the computer from allowing user accounts to authenticate. 

Example:-

PKI is apart of a silo to only allow PKI-admingroup users 

File-admin user account wants to gain access – but – due to the User being apart of a User Silo (File-UserSilo) but it is also not apart of the Computer Silo Group. So access is denied.

Std-user1 is trying to access FITZ-PKI so even though the user is not apart of a Silo, it will be rejected from the Computer Silo because it is not a member of the appropriate security group. 

This example, we are blocking lateral movement attempts to different services in the tiering model. Reducing the damage that could occur should a high privileged account become compromised - lessening to a small subset of a tier than an entire tier or AD.