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.

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.

Get the SDDL for the authentication policy user access control condition using PowerShell (Image Credit: Russell Smith)

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.

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.

Testing the 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.

Check that domain admins cannot start a process on a member server (Image Credit: Russell Smith)

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:

PowerShell

1

runas/user:domainadmin2@ad.contoso.com notepad

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.

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.

PowerShell

1

Get-ADUser-Identitycontosodc1admin-PropertiesAuthenticationPolicySilo

Sponsored

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.