This solution implements Tier Level isolation as described in the blog "Protection Tier 0 the modern way". It prepares your Active Directory forest to support Kerberos Authentication Policies, creating prerequisites to isolate Tier 0 or Tier 1 and automate the Tier 0 / Tier 1 user management. The Kerberos Authentication Policy ensure privileged accounts must use Kerberos as authentication protocol and can only request Kerberos TGT on predefined computers. The solution automates the management of Tier 0 and Tier 1 users with Kerberos Authentication Policies through scripts. One script adds AD-Computer objects to an AD group included in the Kerberos Authentication Policy claim. Another script applies the policy to Tier 0 / Tier 1 users in the correct OU, and for Tier 0, removes users from privileged groups if they are not located in the correct OU. The user management script ensures that users are added to the protected users group and removes users from privileged groups if they are not part of the administrator OU. This solution can manage Tier 0 and Tier 1 users within a single Active Directory Domain or across the entire Active Directory Forest. It utilizes scheduled tasks that run on your primary Active Directory domain, typically the Forest Root domain.

Install the solution into you Active Directory environment

Adds computer to the Kerberos Authentication claim group

Applies the Kerberos Authentication Policy to the Tier Level administrators

Preparation Before you start installing TierLevelIsolation, there are a few preparatory steps that need to be done. Make sure you have all the necessary materials and tools on hand.

1. Download the latest version of TierLevelIsolation
2. Classify the files as trusted (remove the "mark of the web" attribute)
3. The installation process requires Enterprise Administrator permissions.
4. The installation can be done on a member server on which the Active Directory PowerShell modules and the Group Policy Powershell modules are installed.
5. (optional) After a review of the files, the files should be signed
6. Administration

The installation process is started via the install.ps1 script. The installation script guides you through the configuration and creates the required resource. The install.ps1 script should be run as an enterprise administrator to avoid access issues with the Kerberos Authentication Police.

The script provides a list of the Active Directory domains in the current forest. Here you have to make a selection in which domains the tier-level isolation should take place.

In the next step, the tier levels for which the TierLevelIsolation is to be used are defined

Here you have to specify the path in which the Tier0 administrators are stored. The path can be specified as a relative path (without the domain components e.g. OU=Admins,OU=Tier 0,OU=Admin), in which case the same OU structure will be applied in all domains. If the OU structures in the individual domains differ, this should be defined individually for each OU (e.g. OU=Admins,OU=Tier 0,OU=Admin,DC=contoso,DC=com) If there are Tier 0 users in different OU structures, both relative and fully qualified DN can be specified

This is the path where Tier 0 service accounts are stored. Tier 0 service accounts differ from user accounts in that they are not assigned a Kerberos authentication policy, even though they are in AD privileged groups. Again, multiple paths can be specified as relative DN or fully qualified DN.

Is one or more path to the Tier 0 computer objects.

The name of the Tier 0 Kerberos Authentication Policy.

Is the realtive path where the Tier 1 Administrator accounts are stored. If the path is specified as a relative DN, the OU structure must be present in all domains. Again, multiple DistinguishedNames can be specified.

This setting has no function at the moment

Is the absolute or relative DistinguishedName in which the server objects are stored.

Is the name of the Tier 1 Kerberos Authentication Policy

Is the name of the computer group to be included in the Tier 0 computer. This group is created in the Standard Users container. The group should be moved to a Tier 0 managed OU

Is the name of the group in which the Tier 1 computers are included. This group is created in the Standard Users container.

This setting determines whether Tier 0 / Tier 12 users are automatically added to the Protected User group. [0] All user objects stored in the Tier 0 Admin OU are automatically added to the Protected Users group [1] All user objects stored in the Tier 1 Admin OU are automatically added to the Protected Users group [2] Both Tier 0 and Tier 1 user objects are added to the Protectd Users group [3] Neither Tier 0 nor Tier 1 administrators will be added to the Protected Users group

If the answer to this question is Y, all user objects from the following groups will be removed, unless they are in the Tier 0 Admin OU, Tier 0 Service Account OU, the Built Administrator and not a GMSA.

In a multi-domain forest, a GMSA is needed to manage the users in the forest domains. The SAM account name must be entered here. The GMSA is created on demand and added to the Enterprise Administrators group

KLIST PURGE Delete and request a new Kerberos ticket (e.g. dir \\SYSVOL). Afterwards, you have the requested Kerberos ticket with KLIST Indicate. In the TGT displayed, the value "Cache Flags" should be set to 0x41 -> PRIMARY FAST The group policy settings for Kerberos Amoring are made only in the local domain. For all other domains in the AD-Forest, the settings must be manually completed.

If Kerberos Amoring is not available validate:

This enables support for Kerberos Amoring for all client computers. This is done via the setting: Administrative Templates\System\Kerberos\Kerberos Amoring

In this group policy, Kerberos Amoring is enabled at the domain level. The following settings are made for this purpose: Administrative Template\System\KDC\Kerberos Amoring Support mode Administrative Templates\System\Kerberos\Kerberos Amoring

Once installed, you will need to enable TierLevelIsolation. Activation is done via the Tier Level Isolation group policy. This policy group consists of 5 Schedule Tasks that run on the current domain. The schedule tasks are:

Group Policy Preference does not allow you to create a Schedule Task in the context of a GMSA. This task of this Schedule Task is to change the Schedule Tasks Tier 0 User Management / Tier 1 User Management from SYSTEM to the GMSA context

The task of this schedule task is to add or remove computer objects from the Tier 0 server group Both user Schedule Tasks have the trigger disabled by default to ensure that Tier 0 administrators are not locked out. In the first step, the two schedule tasks "Tier 0 Computer Management" and "Tier 1 Computer Management" should be adapted. The default setting is that the task starts daily at 12 p.m. and then repeats every 10 minutes.

This Schedule Task adds the Tier 0 Kerberos Authentication Policy to Tier 0 administrators

The task of this schedule task is to add or remove computer objects from the Tier 1 server group

This Schedule Task adds the Tier 0 Kerberos Authentication Policy to Tier 0 administrators

Once the Computer Management task has been started for the first time, all computer objects must appear in the Tier 0 Computer group. Once this is done, make sure that the Tier 0 Member Server objects have been restarted.

Both user Schedule Tasks have the trigger disabled by default to ensure that Tier 0 administrators are not locked out. In the first step, the two schedule tasks "Tier 0 Computer Management" and "Tier 1 Computer Management" should be adapted. The default setting is that the task starts daily at 12 p.m. and then repeats every 10 minutes. Once the Computer Management task has been started for the first time, all computer objects must appear in the Tier 0 Computer group. Once this is done, make sure that the Tier 0 Member Server objects have been restarted. Subsequently, the TierLevel isolation based on "Kerberos Authentication Polices" was to be tested. To do this, the Kerberos Authentication Policy is to add a Tier 0 user and validate the logon with this user object. The test is successful if this user can only authenticate on a Tier 0 member server or a domain controller. (RDP from an unprotected system is not supported) The test can be repeated with several users. Once the administrators are familiar with Kerberos Authentication Policy based Administration, the Tier 0 user management task is enabled in the TierLevelIsolation Group Policy. To do this, the trigger in the "Tier 0 User Management" tab must be set to active in the Group Policy in the Preferences/Schedule Task. The Taks starts at 12a.m. by default and repeats every 10 minutes. Depending on the environment, these values can be adjusted

Monitoring is done in the Application Event log. For detailed information, a debug log file is also created. The path to the log file is logged as Windows events Source:TierLevelIsolation 1000 or Source:TierLevelIsolation 2000.

To monitor the computer management functions, look for the following events in the event log: |Event ID| Type| Description| Trigger| 1000 Information Starting the Computer Management Script This event is triggered when the Computer Management Script is executed. This event ID should appear every 10 minutes. 1302 Information Adding a Computer Object to the Tier 0 Computer Group If a new computer object is detected in a Tier 0 computer OU, it is added to the Tier Level Isolation Computer group 1304 Warning Removing a Computer Object from Tier Level OU If a Computer Object is removed from the Tier Level OU, this Object is also removed from the group. 1401 Information Adding a Computer Object to the Tier 0 Computer Group If a new computer object is detected in a Tier 1 computer OUs, it is added to the Tier Level Isolation Computer group