다음을 통해 공유

Authentication Policies and Authentication Silos – Restricting Domain Controller Access

  • 아티클

Note: The information in this article is applicable to newer Windows Server versions.

A few new Active Directory features popped up in Windows Server 2012 R2 and should be taken into account when planning or moving to an Active Directory Domain Services environment at Windows Server 2012 R2 levels.  Authentication policies and authentication policy silos are two of these new features and they help administrators define which user accounts can be restricted to log on to specific systems with those accounts. Administrators can configure these new Windows Server 2012 R2 features in the Active Directory Administrative Center or in PowerShell. 

This post is going to step through and show the process for creating an authentication policy and an authentication policy silo, to help administrators leverage an extra layer of security in their AD DS environments.

       

Authentication policy silos

“An authentication policy silo controls which accounts can be restricted by the silo and defines the authentication policies to apply to the members. You can create the silo based on the requirements of your organization. The silos are Active Directory objects for users, computers, and services as defined by the schema in the following table.”

Authentication policies

“An authentication policy defines the Kerberos protocol ticket-granting ticket (TGT) lifetime properties and authentication access control conditions for an account type. The policy is built on and controls the AD DS container known as the authentication policy silo.”

For more detailed information about the two policies above, including information on the Protected Users group, see this Microsoft TechNet Library page at http://technet.microsoft.com/en-us/library/dn486813.aspx

Note: I’ve set these policies as an example for tightening the security of domain controllers.  Authentication policies and authentication policy silos are not limited to domain controllers.  As long as the prerequisites are met, this could apply to any client or server in your AD DS environment.

Prerequisites:

  • All domain controllers in the domain must be based on Windows Server 2012 R2
  • The domain functional level must be Windows Server 2012 R2
  • Domain controllers must be configured to support DAC
  • Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2 domain members must be configured to support DAC, including Kerberos compound claims (device claims)

Meeting the Prerequisites

In my test lab I have two Windows Server 2012 R2 VMs deployed in a forest named “lab.local”.  The forest and domain functional levels were set to Windows Server 2012 R2 during the build out of the test domain and this meets 1 and 2 of the prerequisites.  Next, we’ll need to meet two other prerequisites and then we’ll be able to configure our policies and silos.

Domain controllers must be configured to support DAC

Open the Group Policy Management console – find, right-click and edit the Default Domain Controllers Policy.

Expand out the following location, Computer Configuration\Policies\Administrative Templates\System\KDC, as shown in the image below:

http://kellybush.azurewebsites.net/wp-content/uploads/2014/09/silo-1_thumb.jpg

Double click on “KDC support for claims, compound authentication, and Kerberos armoring”. 

This setting will need to be enabled on the Domain Controllers, see the image below.

http://kellybush.azurewebsites.net/wp-content/uploads/2014/09/silo-2_thumb.jpg

Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2 domain members must be configured to support DAC, including Kerberos compound claims (device claims).

After making the above change, one final prerequisite will be set for the clients in the environment and we will need to enable “Kerberos client support for claims, compound authentication, and Kerberos armoring”

Open the Group Policy Management console – find, right-click and edit the Default Domain Policy.

Expand to the following location, Computer Configuration\Policies\Administrative Templates\System\Kerberos, as shown in the image below.

http://kellybush.azurewebsites.net/wp-content/uploads/2014/09/silo-3_thumb.jpg

Double click on “Kerberos client support for claims, compound authentication, and Kerberos armoring”. 

This setting will need to be enabled on the client systems in the domain, see the image below.

http://kellybush.azurewebsites.net/wp-content/uploads/2014/09/silo-4_thumb.jpg

Note: This policy setting has been set in the Default Domain Policy but this isn’t a requirement.  You may want to set this policy in a different GPO.  The Default Domain Policy has been used here purely as an example.

After making these necessary changes, all the prerequisites have been met.

Creating an Authentication Policy

First, open the Active Directory Administrative Center

In the left pane, select Authentication Policy

In the right pane, select New, and then select Authentication Policy as seen in the image below.

http://kellybush.azurewebsites.net/wp-content/uploads/2014/09/ap-1_thumb.jpg

When the Create Authentication Policy form is opened, there are several things that will need to be checked and edited.

Edit the following settings:

  • Display Name
  • Description

For this example, a Display Name of “Reduce TGT lifetime” had been used and a Description of “This policy reduces the TGT lifetime to 120 minutes” has been chosen**.**

Check to make sure the policy is set to enforce, that the policy is protected from accidental deletion, and that the User is checked to specify a TGT lifetime.  This policy has been set to a lifetime of 120 minutes, if needed Microsoft allows this lifetime to be set as low as 45 minutes. 

For all the changes made and settings configured, see the image below. 

Once your policy is populated, click OK in the lower right corner.

http://kellybush.azurewebsites.net/wp-content/uploads/2014/09/ap-2_thumb.jpg

Now that an authentication policy has been created, an authentication policy silo to contain the users and domain controllers will need to be configured.

Creating an Authentication Policy Silo

Open or navigate back to the Active Directory Administrative Center

In the left pane, select Authentication Policy Silos

In the right pane, select New, and then select Authentication Policy Silo as seen in the image below.

http://kellybush.azurewebsites.net/wp-content/uploads/2014/09/ap-silo-1_thumb.jpg

As with the Authentication Policy form, there are several items in the Authentication Policy Silo form that will need to be checked and edited.

Edit the following settings:

  • Display Name
  • Description

For this example, a Display Name of “Silo – Domain Controllers and Domain Admins” has been given and a Description of “Authentication policy silo to control and restrict Domain Admin accounts to Domain Controllers only” was selected**.**

Check to make sure the policy is set to enforce and that the policy is protected from accidental deletion.  Under the Authentication Policy section, select the authentication policy created in the previous step.

For all the changes made and settings configured, see the image below. 

http://kellybush.azurewebsites.net/wp-content/uploads/2014/09/ap-silo-2_thumb.jpg

After the above changes have been made, select the accounts that will be placed in the silo.  In the Permitted Accounts section click add and define the accounts for the silo. 

For this example, kbush-adm was selected and two domain controllers that make up “lab.local”.

Permitted Accounts:

  • kbush-adm
  • LABDC001
  • LABDC002

For all the changes made and settings configured, see the image below. 

http://kellybush.azurewebsites.net/wp-content/uploads/2014/09/ap-silo-3_thumb.jpg

For Permitted Accounts, nothing has been assigned. 

http://kellybush.azurewebsites.net/wp-content/uploads/2014/09/ap-silo-4_thumb.jpg

Double-click on the test account, in this case kbush-adm, and in the left pane select Silo. Notice in the image below, there are no silos associated with the kbush-adm account.

http://kellybush.azurewebsites.net/wp-content/uploads/2014/09/ap-silo-5_thumb.jpg

Tick the Assign Authentication Policy Silo box and select the authentication policy silo created earlier. When finished, click OK in the lower right corner.

http://kellybush.azurewebsites.net/wp-content/uploads/2014/09/ap-silo-6_thumb.jpg

Once this has been done for the user or users, it will need to be repeated for the computer accounts as well. When this has been completed for all accounts and computer accounts, the assigned column may still not reflect that the accounts are assigned – they are. 

Close the authentication policy silo and reopen the silo.  Once this has been completed all the accounts should be noted as assigned.

http://kellybush.azurewebsites.net/wp-content/uploads/2014/09/ap-silo-7_thumb.jpg

Final step

Finally, open or navigate back to the Active Directory Administrative Center

In the left pane, select Authentication Policy then in then select the “Reduce TGT lifetime” policy by double-clicking it. When the policy form opens select User from the left pane.

For the defined conditions click the Edit button on the right side of the configuration form.

http://kellybush.azurewebsites.net/wp-content/uploads/2014/09/conditions_thumb.jpg

The Edit Access Control Conditions dialog box will appear, select Add a condition.

http://kellybush.azurewebsites.net/wp-content/uploads/2014/09/conditions-2_thumb.jpg

The following condition will need to be added:

  • User
  • AuthenticationSilo
  • Equals
  • Value
  • Silo – Domain Controllers and Domain Admins

For all the changes made and settings configured, see the image below.

http://kellybush.azurewebsites.net/wp-content/uploads/2014/09/conditions-3_thumb.jpg

Testing

Log on to both domain controllers (or domain controller), open PowerShell and type “klist purge” , without the quotes, and reboot the systems. This will purge all the TGTs and speed up testing.

http://kellybush.azurewebsites.net/wp-content/uploads/2014/09/klist_thumb.jpg

Once the tickets have been purged and the systems have been rebooted, the kbush-adm  account (or your test account) will be denied the right to log on to systems that are not defined by the authentication policy silo.

http://kellybush.azurewebsites.net/wp-content/uploads/2014/09/prevented_thumb.jpg

Recap

After meeting the prerequisites and creating the authentication policies and authentication policy silos, administrators can limit specific accounts to only be able to logon to specific servers.  Following these steps will stop privileged users from signing onto computers that could potentially pose a security risk because of cached credentials.  Requiring privileged administrators to follow a standard policy for authentication is just one more tool in reducing the attack surface of an AD DS implementation.

 

http://kellybush.azurewebsites.net/wp-content/uploads/2014/09/stop-win-7_thumb.jpg