Authentication Policies and Authentication Policy Silos Deployment

Authentication policies are policies that allow you to restrict access to resources for specific users and services. Silos, on the other hand, allow you to group multiple accounts in the same space, making it easier for tiering* an environment. Both authentication policies and silos can affect three types of accounts:

• User accounts

• Service accounts (MSA)

• Computer accounts

In the case of user accounts, the restrictions are based on the behavior of Protected Users members:

• NTLM is not allowed.

• RC4 and DES are blocked in Kerberos authentication.

• Kerberos delegation is not allowed, either constrained or unconstrained.

In addition to this base, we can also customize:

• The validity period of Kerberos tickets.

• Whether NTLM is allowed in certain scenarios.

• The machines on which Kerberos tickets can be obtained.

Authentication policies make advanced use of Kerberos, employing some less common technologies such as:

• FAST Armoring: Extra protection for tickets, which better safeguards the Kerberos PAC (Privilege Access Certificate), where the permissions and usage of the authenticated account are described.

• Compound Authentication: A double PAC is generated for both the user and the machine. This allows the user's authentication to be tied to a specific device.

This last point is key to authentication policies. User accounts attempting to authenticate will not be able to do so except on one of the allowed devices. The Kerberos Key Distribution Center (KDC) service itself will block authentication and report an error event whether this happens. There are only two cases in which the authentication policy will not enforce two-factor authentication:

1. If the account to be authenticated is the built-in Administrator (S-1-5-21-<domain>-500). This account is not affected by device restriction. In any case, it's possible to disable this account if you already have other accounts with Domain Admin permissions.

2. If the account to be authenticated is a computer account, computers cannot verify if they are authenticating from a specific computer because… they are themselves.

Keep in mind that delegations and memberships in Active Directory are usually done at the user and service level, not at the machine level. Furthermore, computers automatically renew their keys using a large number of characters to prevent brute-force attacks. That said, it's possible to obtain a computer's AES256 key by accessing its memory, although this constitutes an advanced compromise of the machine.

Tier Model

When we talk about "tiering" or a tier model, we're referring to a system of segregating domain entities into levels. Each of these levels represents a higher or lower rank of privileges and domain management. Tier models can have as many levels as necessary. A fairly simple example could be:

• Tier 0: Domain Controllers and Domain Admins

• Tier 1: Servers and operators

• Tier 2: Client computers and unprivileged users

Properly implemented, this segregation would prevent what are known as "lateral movements". A Tier 2 user would not be able to access a Tier 1 server, nor could a Domain Admin account be used to access a Tier 1 server, for example. Achieving such a fully functional model requires multiple configurations, including the aforementioned authentication policies.

Configuring Authentication Policies and Silos

Authentication policies and silos require the following prerequisites:

1. Domain with a Windows Server 2012 R2 functional level or higher.

2. On all machines, enable "Future Encryption Types" in the "Configure Encryption Types Allowed for Kerberos" security policy.

3. Enable the "Support Dynamic Access Control and Kerberos armoring" policy for both KDC on Domain Controllers and all Kerberos clients.

Once these prerequisites are met, you will need to restart both the Domain Controllers and the other machines to which these GPOs are applied. Authentication policies and silos are created in Active Directory: Administrative Center.

From this point on, if you have never configured authentication policies and silos, I strongly recommend that you follow the exact steps I will describe later or in the video, as you may encounter configuration errors and erratic behavior for several reasons:

• An account can only have one authentication policy or one silo assigned. You cannot have more than one, nor can you assign both: either a policy or a silo. Furthermore, after assigning it, you must "confirm" it.

• The built-in administrator account is not affected by silos or authentication policies.

• Audit mode does not work with silos, only with authentication policies. For silo-related events to appear, forced mode must be enabled. Furthermore, forced mode must be configured after creating the policy.

• Kerberos clients must be restarted for authentication policies to take effect.

• Although authentication policies can be used without silos, they require configuration on each computer individually. It is better to use silos to group multiple users, services, and computers.

Steps to follow:

1. Create an authentication policy. Give it a name, mark it as forced, and save it.

2. Create a silo. Add computer, user, and MSA accounts. Important: The first time, leave an emergency account, a member of Domain Admins, outside the silo. Incorrectly configuring the silo could result in the loss of all domain access. The built-in 'administrator' account is also valid, as it is not affected by authentication policies.

3. We choose an authentication policy, the one we created in the first step.

4. Save the silo, but go back into it to set the mode to enforced and make further configurations.

5. Confirm the chosen accounts. This requires using the command Set-ADAccountAuthenticationPolicySilo or confirming it in Active Directory: Administrative Center (except for MSA accounts, which cannot be confirmed via the graphical interface).

6. Access the silo to review and verify that all accounts are confirmed with the green tick.

7. Return to the authentication policy, verify that the silo is confirmed, and modify the conditions for obtaining user and service tickets: (User.AuthenticationSilo Equals "Nombre_Silo").

8. Restart the machines that are part of the silo.

Once everything is configured, we can try logging into a machine within the silo with a user account from the silo. It should be possible. However, if we try to log in with the same user on a machine that is not in the silo, authentication should fail.

And not only will this fail, but pass the hash, pass the key, and pass the certificate attacks will be completely blocked for that user. In an upcoming article, we will show how these attacks are blocked in real time.