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.
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:
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
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.
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
group using the
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:
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
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
AD attributes for the returned objects.
gets populated when an AD account object has permission to access a silo, and
once the object is associated with a silo.
Before you start testing the new policy and silo, run
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
group without any restrictions.
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
when prompted, and you should receive an access denied message. If you run the same command on a domain controller, Notepad will start because
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
and CONTOSODC1, the one and only DC in my domain.
src="https://petri-media.s3.amazonaws.com/2014/12/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.
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.