5 Steps to A Secure Active Directory Environment

Secure Active Directory Environment

Active Directory is used as a central element for authentication in many companies. Therefore, domain controllers are also the focus of attackers. If these systems are compromised, the entire network is often at risk. However, security can be significantly increased with on-board tools.

5 Steps to a secure Active Directory environment

Especially accounts with elevated privileges and administrator accounts are often the focus of attackers. In order to optimally secure Active Directory, small and medium-sized companies should also take their cue from enterprise environments, which in most cases are looking for significantly more security in the Active Directory environment.

When attackers penetrate a network, they typically do so through a single endpoint. Once this endpoint, for example, an insecure PC, server, router, or other network device, has been taken over, it is important to gather information about the network. Only with sufficient information can an attacker efficiently spy on the rest of the network or carry out further attacks.

This spying is also called reconnaissance, or “recon” for short, spies on the network. Pass-the-hash attacks directly target user accounts in Active Directory. Of course, user accounts with privileged rights are of particular interest here. These can be administrator accounts, but also user accounts that have been given the right to change user passwords, for example.

READ:  What Is A Botnet?

Because with user changes, attackers can gain access to other accounts besides PtH. PtH attacks rely not only on user passwords but on the hashes assigned to a user account after authentication. Simply put, these are tickets into Active Directory.

Step 1: Use administrator account prudently and divide rights

Administrator accounts should be used very prudently in Active Directory environments. First of all, different administrator accounts should be used for the different server applications in the company. Administrator accounts for SQL servers, should not also be used for Exchange, or to manage Active Directory.

If such an account is compromised, then all other server services are also at risk. Windows servers offer various user groups for this purpose, which are available by default and should also be used. Especially in overall structures, these default groups in the root domain are particularly important.

Step 2: No unnecessary logins with administrator accounts

In secure AD environments, it makes sense to use accounts with elevated privileges as little as possible. Logon should always be performed only with the administrator account that is set up for the respective server service.

If a workstation is suspected of being compromised or insecure, administrators should never log on to the system with the administrator account. In general, it makes sense to avoid logging on to computers that are connected to the Internet. Therefore, the administrators’ workstations, which are used to manage the environment, should not be connected to the Internet.

READ:  What is Common Criteria?

Step 3: Use multifactor login and administrator-at-a-time accounts

In general, it may be necessary to use multifactor authentication (MFA) for administrator accounts. In addition, you should also rely on administrator-on-time accounts. In such an infrastructure, administrator accounts are given the right to perform a certain administrative task only for a certain time. Once the task is completed, or the time has expired, the rights are removed.

Step 4: Use read-only domain controllers at insecure sites

In locations where the domain controllers are not positioned in protected server rooms, read-only domain controllers should be used. One way to secure domain controllers in branch offices is to use read-only domain controllers (RODC).

These domain controllers receive replicated information from the normal domain controllers and do not accept changes from administrators themselves.

An RODC provides a complete Active Directory, but without stored passwords. This folder on the RODC is read-only. Although an RODC can also store passwords, it can only store exactly those that an administrator specifies. When using RODCs, the following processes are handled when a user logs on:

  1. A user logs in to the RODC site. 2.
  2. The RODC checks whether the user’s password has been replicated to the server. If so, the user is logged in. 3.
  3. If the password is not available on the RODC, the login request is forwarded to a full-fledged DC.
  4. If the login is successful, a Kerberos ticket is assigned to the RODC.
  5. The RODC now issues the user a Kerberos ticket of its own, with which the user works. By the way, group memberships and group policies are not sent over the WAN line. This information is stored on the RODC.
  6. Next, the RODC attempts to replicate this user’s password to its database from a full-fledged DC. Whether this succeeds or fails depends on the particular group membership.
  7. The next time this user logs in, the described process starts all over again.
READ:  What Is a Security Vulnerability?

Step 5: Using managed service accounts – Managed Service Accounts

Managed service accounts are an innovation since Windows Server 2008 R2 and have been significantly improved in Windows Server 2012 R2. In Windows Server 2016, managed service accounts still work in much the same way as they did in Windows Server 2012 R2. Administrators can use one managed service account for multiple servers.

For this purpose, Microsoft has developed the grouped managed service accounts (gMSA) in addition to the already managed service accounts (MSA). Administrators can manage the managed service accounts in PowerShell. The Managed Service Accounts GUI freeware makes it much easier to create managed service accounts in Windows Server 2016.