Restrict Privileged Accounts with Authentication Silos in Windows Server 2012 R2

In the second part of this two-part series, I’m going to continue showing you how to restrict the use of domain administrator accounts using an authentication policy and silo in Windows Server 2012 R2. In the first article, we covered how to create an authentication policy in Windows Server 2012 R2. Before continuing with the configuration, let’s step back and look at the SDDL that was used in with the Set-ADAuthenticationPolicy cmdlet from Part 1.

UserAllowedToAuthenticateFrom SDDL

You probably noticed in the Set-ADAuthenticationPolicy cmdlet, an unintelligible Security Descriptor Definition Language (SDDL) string used to set the access control condition value for the -UserAllowedToAuthenticateFrom parameter. Initially, the only way to determine the SDDL is to configure the access control condition in the GUI using the Active Directory Administrative Center (ADAC), and then to use Get-ADAuthenticationPolicy to retrieve all the properties for the policy, which includes the SDDL, so that it can be used to automate configuration in the future.

To configure the SDDL for the access control condition in the GUI:

• On a domain controller or device with the Remote Server Administration Tools (RSAT) installed, open Server Manager using the blue icon on the desktop taskbar or from the Start screen. You will need to be logged in as a domain administrator.
• In Server Manager, select Active Directory Administrative Center from the Tools menu.
• In ADAC, click Authentication in the left panel.
• In the list of authentication policies on the right, double click 2hr_Admin_TGT.
• In the 2hr_Admin_TGT window, click User in the left panel.
• Below User, click Edit to the right of the box for defining conditions to restrict devices that can request a TGT for the user accounts assigned to the policy.
• In the Edit Access Control Conditions dialog, click Add a condition in the bottom left corner.
• In the drop-down menus starting from the left, set the condition to User, AuthenticationSilo, Equals, Value, type Restricted_Admin_Logon in the last box and then click OK.
• Click OK in the 2hr_Admin_TGT window and close ADAC.

Now open a PowerShell console and run the command below:

In the output, you’ll see the
UserAllowedToAuthenticateFrom attribute populated with the SDDL we specified in the Set-ADAuthenticationPolicy
cmdlet.

Account Configuration

Completing the silo configuration involves a two-step process for computer, user, and service accounts. They must be given permission to access the authentication silo, and then associated with the silo.

Permit Domain Controllers and Domain Admins to Access the Silo

In the cmdlet below, I’m enumerating domain controllers using Get-ADDomainController and then piping the results to a ForEach loop to permit each DC access to the Reduced_Admin_Logon silo using the Grant-ADAuthenticationPolicySiloAccess cmdlet.

​
Similarly, I'm doing the same thing here for user accounts in the

Domain Admins

 group using the

Get-ADGroupMember

 cmdlet.

​

To check that the configuration has applied correctly, list the domain accounts permitted access to the silo:

​
Or for more detailed information, you can run:

​

Associate Domain Computer and User Accounts with a Silo

Once the relevant accounts have permission to access the silo, they must be associated with it. To associate DC computer accounts in the ad.contoso.com domain with the silo:

​
Now let's associate accounts in the

Domain Admins

 group with the silo:

​

To check that the above configuration has been successfully applied, run the cmdlet below. In the output, you'll be able to see which accounts are associated with the Restricted_Admin_Logon silo, and the values of the

msDS-AuthNPolicySiloMembersBL

 and

msDS-AssignedAuthNPolicySilo

AD attributes for the returned objects.

msDS-AuthNPolicySiloMembersBL

gets populated when an AD account object has permission to access a silo, and

msDS-AssignedAuthNPolicySilo

once the object is associated with a silo.

​
Before you start testing the new policy and silo, run

klist purge

 in a command prompt on DCs that are associated with the silo, and then reboot the servers to renew Kerberos TGTs. In my domain I have two domain administrator accounts. If all is well after the DC(s) have rebooted, I should still be able to use the built-in administrator account that I removed from the

Domain Admins

 group without any restrictions.

Domain Accounts and Member Servers

A second account, domainadmin2, is located in the Domain Admins group, and as such is subject to logon restrictions determined by the authentication policy and silo. And don’t forget that domainadmin2 is also a member of the Protected Users group, which applies further restrictions on how the account can be used, such as limiting its ability to log in using Remote Desktop. CONTOSOSRV1 is a member server in my domain. I don’t have physical access to it because it’s running in the cloud, so I must log in using Remote Desktop with the built-in administrator account, which I’ve already added to the local Remote Desktop Users group on CONTOSOSRV1.

To check that domainadmin2 has restricted access to CONTOSOSRV1, all I need to do is fire up a command prompt on CONTOSOSRV1, and use the runas command to launch a process using alternative credentials:

​
Enter the password for

domainadmin2

 when prompted, and you should receive an access denied message. If you run the same command on a domain controller, Notepad will start because

domainadmin2

 is allowed to authenticate from DCs, but not domain members.

You can also see how authentication policy is applied to accounts. Below I'm checking

domainadmin2

 and CONTOSODC1, the one and only DC in my domain.

​src="https://petri.com/wp-content/uploads/petri-imported-images/1725487414-Figure8.jpg" alt="Check the AuthenticationPolicySilo AD attribute for user and computer accounts (Image Credit: Russell Smith)" width="840" height="684" /> Check the AuthenticationPolicySilo AD attribute for user and computer accounts (Image Credit: Russell Smith)[/caption]

In the output, I can see that both account objects are associated with the Restricted_Admin_Logon silo. But in the cmdlet below, the built-in administrator account (contosodc1admin), isn't associated with an authentication policy silo, and as such can log on to CONTOSOSRV1 without any restrictions.

​

Authentication Silos in Practice

Active Directory has a delegated security model that’s designed so that domain admin privileges are not required to carry out most administrative jobs. Regular server maintenance tasks, such as reboots, patching, Event Log monitoring, and backup etc., can also be carried out without domain administrator rights.

Even if you have a good strategy in place for managing your severs, restricting the devices from which domain administrators can log in is all well and good, but once access is achieved, authentication silos and other controls can be easily disabled. Nevertheless, implementing the controls I’ve demonstrated results in domain administrators being locked out of the domain unless they have physical access to a domain controller.

And assuming physical access to DCs is restricted, then these controls add an additional layer of security. Restricting the use of domain administrator accounts is just one potential use for authentication policies and silos in Windows Server 2012 R2 domains. But ultimately, whether authentication silos prove useful in your environment, largely depends on the model in place for securing and administering your systems.