Simple measures for more security in AD (Part 3): Admin Tiers

The basic How the Admin Tiers work was already described in part 1 of this article series, this article now deals with setting up admin tiers in an existing environment. Basically, it makes sense if you already have at least one Admin Host was installed.

By and large, this article is first about configuring and enforcing the admin tiers. Further measures can be implemented later to further improve security. However, if Admin Tiers and Admin Host are already configured and are also used according to the principle, you are already a big step further in terms of security.

Create user accounts and groups

At least three new user accounts and three new groups are required for the administration of servers and clients within the Active Directory to function in accordance with the admin tiers. A new group is created in the Active Directory for each Admin Tier (Tier 0, Tier 1, Tier 2). In addition, at least one user account is created for each admin tier.

In my example environment, I have created the "Administration" OU and within it the "Administrative Groups" and "Administrative Accounts" OUs. Within the OUs, I then created the groups "Tier0Admins", "Tier1Admins" and "Tier2Admins":

In my example environment, there are only 3 administrative accounts "Tier0Admin", Tier1Admin" and "Tier2Admin". This is the case, for example, in small environments/companies where one person administers all three tiers. If there are several administrators with different roles, several administrative accounts are also required for each tier. For example, if there is a help desk that provides support for client problems, then each client admin receives a tier 2 admin account. The same applies to server administrators: If there is a team of employees who manage and administer the servers, each of the admins gets their own Tier 1 admin account.

The number of people who receive a Tier 0 admin account should be as manageable as possible, but here too, each of the domain admins receives their own Tier 0 admin account.

The administrative users are now assigned to the corresponding groups. Tier 0 admins are assigned to the "Tier0Admins" group, Tier 1 admins to the "Tier1Admins" group and Tier 2 admins to the "Tier2Admins" group:

Finally, the "Tier0Admins" group becomes a member of the "Domain Admins" group:

Important: A Tier Admin account may not be assigned "across tiers". A Tier 1 Admin account may only be a member of the Tier 1 Admins group, but not of the Tier2Admins or Tier0Admins group. An account that has administrative authorizations on servers may therefore not have administrative authorizations on clients.

Once the users and groups have been created, the OU structure can be expanded or created.

Create OU structure

It is not necessary to create a new OU structure in order to implement the Admin Tiers, but it does make it easier to keep an overview. The Admin Tiers can usually also be integrated into existing OU structures, but it is then usually somewhat more difficult to maintain an overview, so it makes sense to create new OUs for the Admin Tiers, especially when introducing the Admin Tiers into existing environments.

An existing environment could have the following OU structure, for example:

There is a "Clients" OU in which all computer accounts of the PCs and notebooks are managed. All server computer accounts are stored in the "Servers" OU. The computer accounts of the domain controllers are located in the "Domain Controllers" OU. The servers and clients are not yet classified here, this will follow later.

In order to create an OU structure for the three admin tiers, three new OUs can now be created in this example environment: Tier 0, Tier 1 and Tier 2.

As PCs and laptops are assigned to Tier 2, a new OU with the name "Tier 2" can be created within the "Clients" OU. As servers can be in Tier 0 or Tier 1, the "Tier 1" and "Tier 0" OUs are created below the "Server" OU:

When adding new computers to the Active Directory, the computer accounts are created in the "Computers" OU by default, which is somewhat unfavorable for the Admin Tiers (more on this later).

Another OU can be specified so that new computer accounts (servers and clients) are no longer created in the "Computers" OU. With the following command, all new computer accounts are created in the "Clients" OU and no longer in the "Computers" OU:

New servers and clients therefore end up in the Clients OU, so that a classification of the new computers is carried out and the admin tiers are enforced, group policies can be used. These group policies are now created.

Note: If an OU structure has already been created in the company, this can in most cases be used further or extended accordingly. To ensure that the admin tiers are implemented and maintained, it is important to classify the systems and assign the group policies. How many OUs there are and what they are called is irrelevant as long as the classification of the computers to the corresponding tiers and the assignment of the group policies to the OUs is correct.

Create group policies

Group policies are now used to ensure that no Tier 1 administrators can log on to Tier 2 systems and that Tier 0 administrators cannot log on to Tier 1 and Tier 2 systems. This requires two new group policies, in this case the two (still empty) group policies are called "Standard security tier 1" and "Standard security tier 2":

The "User configuration settings" can be deactivated for both policies:

Now the GPO "Standard Security Tier 1" can be edited first. In this GPO, the Tier 0 admins must now be denied logon (Lower Tier Logon, see last image in this section):

The following 5 settings are therefore configured for the "Tier0Admins" group:

• Deny logon as batch job
• Deny login as a service
• Deny logon via Remote Desktop Services
• Deny local login
• Deny access from the network to this computer

Here is an overview of the settings for the "Standard security tier 1" group policy:

The same 5 settings are now edited in the "Standard Security Tier 2" GPO, but the Tier0Admins and Tier1Admins are denied login. Here is an overview of the settings for the "Standard Security Tier 2" GPO:

The two GPOs can be adjusted accordingly so that the accounts of the Admin Tier groups now also have local administrator rights on the respective systems. In the GPO "Standard Security Tier 2", the group "Tier2Admins" is added to the local group "Administrators":

Here is an overview with the corresponding group assignment for "Standard Security Tier 2":

Here is the overview for "Standard Security Tier 1":

The two new group policies are now linked to the corresponding OUs, the "Standard Security Tier 1" policy is linked to all OUs that contain Tier 1 systems. "Standard Security Tier 2" is linked to the OUs that contain Tier 2 systems:

OUs with Tier 0 systems do not initially receive any special GPOs. Without a special policy, only members of the Domain Admins group can usually log on to Tier 0 systems (OU Domain Controllers, Server/Tier0) anyway. In this case, this would be the Tier0Admins user and the "Administrator" account. The "Administrator" account will be deactivated later on. The "Lower Tier Logon" is therefore already prevented in this case if the systems are classified accordingly:

Classify Admin Tiers systems

Classifying the systems is the biggest challenge, here you have to check exactly which animal a system belongs to. In theory, it is quite simple:

• Domain controllers are Tier 0 systems
• All servers are Tier 1 systems
• All clients are Tier 2 systems

However, the reality is somewhat different. Exchange servers, for example, have very far-reaching authorizations in the Active Directory, so Exchange servers are more likely to be assigned to Tier 0 than Tier 1. When classifying systems, the control a system has over other systems must be taken into account.

For example, if there is a backup solution that has an agent on the server, domain controller and clients and the agent is also operated with a domain account, the backup solution counts as a Tier 0 system. Let's assume that the backup software runs with domain admin rights for the sake of simplicity (it's so easy and you don't have to worry about the corresponding authorizations), an attacker could compromise the account of the backup software on a client and use this account to log on to servers and domain controllers. However, this is exactly what the admin tiers are designed to prevent.

To keep Tier 0 as small as possible, you need to take a close look at the software used and reconfigure it accordingly if necessary. Backup software does not have to run with Domain Admin rights and can usually use different accounts for servers and clients. Many other software is also often started with Domain Admin rights, for example inventory and documentation programs.

Especially in mature environments, you have to take the trouble to check programs, services and servers so that they can be assigned to the tiers accordingly. In most cases, some configuration work is also necessary so that a client or server can no longer potentially control higher tiers.

As soon as it is clear which system belongs to which tier, the computer accounts can be moved to the corresponding OUs. I have made the classification for my small example environment as follows:

The domain controllers remain in the "Domain Controllers" OU and are not moved to the "Server / Tier 0" OU. The two Exchange servers EX1 and EX2 are classified as Tier 0 systems as they were not installed in split permission mode. The other servers are Tier 1 systems and all clients have been classified as Tier 2 systems.

Note: If Exchange Server has not been installed in split permission mode and a DAG stores the file share witness on a file server, the file server also belongs to Tier 0. In this case, a dedicated file server could be used for the FSW, which does not offer shares for users.

Testing the Admin Tiers

After the group policies have been applied to the systems, you can test whether the lower tier logon is successfully denied. It should therefore no longer be possible to log on to Tier 1 and Tier 2 systems with the Tier0Admin user. Tier 1 admins are not allowed to log on to Tier 2 systems.

The following message appears if a user wants to log on to an unauthorized animal (in this case via console/local):

The same applies to RDP connections:

Logons to the respective systems of the same animal are not denied (Same Tier Logon).

So far, neither the "Domain Admins" group nor the "Administrator" account has been restricted, so if something has gone wrong, it is still possible to log in to the systems with the "Administrator" account or another member of the "Domain Admins" group. The "Administrator" account can be deactivated after successful testing, the restriction of the "Domain Admins" group is part of the next article.

Deactivate and rename administrator account

Once the user login has been tested, the "Administrator" account can be renamed and deactivated. Only the respective users are now used to administer the various admin tiers. The "Administrator" account is no longer required:

In addition, the account can also be renamed. Although this does not change the SID, changing the user name causes many automated scripts to fail:

The account is no longer used, so it does not hurt to rename the account. After the account has been deactivated, it is worth searching the Windows event log for failed logins of the "Administrator" account. It could be that tasks or other programs are still using the account, which can then be reconfigured accordingly.

Finally, the critical groups should also be checked to see whether, for example, other accounts have domain admin authorizations. These groups should therefore be checked once:

• Domain Admins
• Scheme admins
• Organization Admins

Note: Schema or organization admin permissions are normally required so rarely that you can authorize an account here if necessary. For example, if you need to update or extend the schema, it is sufficient to give yourself the corresponding rights with the Tier0Admin before the process and remove them again after the process.

Further measures

The implementation of the admin tiers is not yet complete at this point, but once you have reached this point, you are a big step further. Ideally, you now already have a normal client for your daily work, an admin host that is only used for administration and admin tiers that enforce basic security guidelines for privileged accounts.

Im nächsten Artikel werden dann noch weitere Maßnahmen bezüglich der Admin Tiers umgesetzt. Dies sind im wesentlichen die folgenden 3 Punkte:

• Beschränkung der Gruppe “Domain-Admins”
• Security Zones – Mehrere Administratoren je Tier
• Umgang mit nicht klassifizierten Systemen
• Auditierung

Another issue is the local "Administrator" account on servers and clients. This is where LAPS comes into play. LAPS is expected to be configured the article after next.