The proliferation and misuse of domain administrator accounts is one of the biggest security risks posed to systems in Windows Active Directory (AD) domains. In this first part of a two-part series, I’ll show you how to restrict use of domain admin accounts to domain controllers (DCs) in Windows Server 2012 R2 domains by enabling support for additional Kerberos features. I’ll also show you how to create a new authentication policy and silo.
Authentication Policies and Silos
Authentication policies and silos are a new feature in Windows Server 2012 R2, and in conjunction with claims-based authentication, allows system administrators to restrict the use of domain user, computer, and service accounts in the domain.
Accounts assigned domain administrator privileges should always be kept to an absolute minimum, and IT staff should never be assigned domain administrator privileges on a permanent basis. Applying additional controls to restrict where domain administrator accounts can be used, allows organizations to release the accounts when changes need to be applied to domain controllers, with the knowledge that they should be used according to best practice, and specifically preventing their use from devices that are likely to be compromised, such as end user workstations.
Before applying any of the restrictive measures described in this article, you’ll need to develop a strategy for providing IT staff access to servers, clients and AD without granting them permanent domain administrator privileges.
Prerequisites
Before you can configure authentication policies and silos in your domain, there are several requirements that must be met.
As authentication policies rely on Kerberos authentication, privileged users in your domain should be placed in the Protected Users group, because among other things, this prevents them from logging in using the NTLM authentication protocol. The one exception is that service accounts should not be placed in the Protected Users group, as all incoming authentication requests would be rejected.
As users in the Protected Users group can’t connect to servers remotely, using either Remote Desktop or the default PowerShell Remoting endpoint, I’ve removed the built-in administrator account from the Domain Admins group so that I’ve always got one domain administrator that isn’t restricted by any of the settings applied in this article. The built-in domain administrator account is a member of the Administrators group, so removing it from the Domain Admins group doesn’t prevent me from using the account to access domain controllers.
One consequence of removing the built-in administrator account from the Domain Admins group is that the account will no longer be able to connect to clients or member servers using Remote Desktop, without adding it to the Remote Desktop Users group on each device. This shouldn’t present a problem in a production environment, as it’s not recommended to use accounts with domain administrator privileges for regular administration tasks. Another strategy for remotely accessing servers and clients for administration purposes should be in place.
To remove an account from the Domain Admins group, use the PowerShell cmdlet below. In my domain, the default domain administrator account is contosodc1admin.
To quickly add members of the Domain Admins group to the Protected Users group, use the cmdlet below.
Enable Support for Claims, Compound Authentication and Kerberos Armoring
There are two group policy settings that must be configured to enable Kerberos support for authentication policies and silos in a domain. The KDC support for claims, compound authentication, and Kerberos armoring setting under Computer Configuration > Policies > Administrative Templates > System > KDC must be set to Supported for domain controllers. Link the GPO to the Domain Controllers OU.
The Group Policy Management dialog screen. (Image Credit: Russell Smith)
For all domain members (Windows 8 and Windows Server 2012 or later), Kerberos client support for claims, compound authentication, and Kerberos armoring should be set to Enabled under Computer Configuration > Policies > Administrative Templates > System > Kerberos. Link the GPO to the domain.
For more information on creating and linking Group Policy Objects (GPOs), see How to Create and Link a Group Policy Object in Active Directory on the Petri IT Knowledgebase.
Create an Authentication Policy and Silo
Before creating a silo, we'll define an authentication policy that sets the lifetime of the Kerberos Ticket Granting Ticket (TGT). Domain accounts must have a configured TGT lifetime for silos to work. The cmdlets in this article can be run from a domain controller as a domain administrator or from a domain-joined device where the Active Directory Module for Windows PowerShell is installed. You should run these commands as a domain administrator.
First let’s create a new authentication policy and set the TGT lifetime for the policy to two hours using the New-ADAuthenticationPolicy cmdlet. After a two hour period, users must re-authenticate. The default TGT lifetime in AD is four hours.
If you're experimenting with silos and authentication policies for the first time, you might want to omit the –enforce parameter from both the New-ADAuthenticationPolicy and New-ADAuthenticationPolicySilo cmdlets so that both are set to audit only mode.
Before setting the access conditions for the policy, let's create a new silo that applies the previously created authentication policy to computer, service, and user accounts:
Now set the access control conditions to restrict the devices that can request a TGT for the user accounts assigned to the policy. In other words, the following configuration restricts users to which our authentication policy applies, to only interact with computer accounts associated with the Restricted_Admin_Logon silo.
There will be no user accounts linked directly to our authentication policy, but instead they are assigned indirectly in the silo.
We will also associate our domain controller computer accounts with the Restricted_Admin_Logon silo later. And don't worry, I'll translate the SDDL in the cmdlet below into plain English in the second part of this series.
Before continuing, let's check the configuration of the authentication policy. In the output, you should see the UserAllowedToAuthenticateFrom and UserTGTLifetimeMins AD attributes populated according to the values we assigned using PowerShell.
The Get-ADAuthenticationPolicy cmdlet in Windows PowerShell. (Image Credit: Russell Smith)
Enforce Policy and Silo
If you decide to omit the –Enforce parameter from the New-ADAuthenticationPolicy and New-ADAuthenticationPolicySilo cmdlets at this stage, you can always enforce the authentication policy and silo later using the cmdlets below:
In part two of this series, I’ll show you how the mysterious SDDL that appears in the Set-ADAuthenticationPolicy cmdlet above was determined, and then complete the configuration by associating the necessary AD account objects with the silo, and testing the results on a member server in the domain.
There will be no user accounts linked directly to our authentication policy, but instead they are assigned indirectly in the silo. We will also associate our domain controller computer accounts with the Restricted_Admin_Logon silo later. And don't worry, I'll translate the SDDL in the cmdlet below into plain English in the second part of this series.
There will be no user accounts linked directly to our authentication policy, but instead they are assigned indirectly in the silo.
We will also associate our domain controller computer accounts with the Restricted_Admin_Logon silo later. And don't worry, I'll translate the SDDL in the cmdlet below into plain English in the second part of this series.
