Active Directory Security Best Practices

Hackers are breaking the systems for profit. Before, it was about intellectual curiosity and pursuit of knowledge and thrill, and now hacking is big business.

- Kevin Mitnick

Kevin Mitnick was once known as the world's most wanted hacker. Most of the cyber security laws that exist today were first introduced to the world because of him. For anyone who is interested in cyber security, I highly recommend his book Ghosts in the Wires. It not only talks about his life as a hacker, but it also explains the evolution of the "hacker" over time. He started hacking into phone systems first and then, as technology developed, he challenged himself with breaking into computer systems. For him, it wasn't about profit, but today, things are way more complicated. According to https://vz.to/2Zm81bn, 90% of data breaches are finically motivated. Hackers are targeting more valuable assets such as intellectual property, state secrets...

AD authentication

AD uses Kerberos version 5 as the authentication protocol between the domain controller and the clients. Kerberos v5 became the default authentication protocol for Windows Server from Windows Server 2003. It is not a Microsoft proprietary protocol; it is an open standard. Therefore, AD can work with any application or service that supports the same standard.

The Kerberos protocol

The Kerberos protocol is built to protect authentication between the server and the client in an open network.

The main concept behind authentication is that two parties first agree on a password (secret) and then use it to identify and verify their genuineness:

Figure 16.1: Authentication by using a secret

In the preceding example, Dave and server A have a communication link. They often exchange confidential data. To protect this communication, they agree to use a common secret code (1234) to verify their identities before exchanging data. When Dave makes the initial connection, he passes his secret to server A and says Hey! I'm Dave. Then, server A checks the secret to see whether it's true. If it's correct, it identifies him as Dave and allows further communication.

Figure 16.2: Man-in-the-middle attack

Communication between Dave and server A happens in an open network, which means that other systems and users...

Authentication in an AD environment

Let's go ahead and revisit our previous example, to see how the authentication process works in an AD environment:

Figure 16.4: Authentication process in AD

The following list summarizes the steps involved in the authentication process:

1. Dave sends the username and his long-term key to the KDC (domain controller).
2. The KDC checks the username and long-term key with its database and verifies the identity. Then, it generates a TGT. It includes a copy of a session key, which the KDC uses to communicate with Dave. This is encrypted using the KDC's long-term key. It also includes a copy of a session key that Dave can use to communicate with the KDC.
3. The KDC responds to Dave with its TGT.
4. Dave decrypts his key using his long-term key and the retrieved session key. His system creates a new request, which includes the TGT and the timestamp encrypted by the session key and service ID. Once the request is...

Delegating permissions

The Kerberos protocol itself was built to prevent identity compromise. This is all good on paper, but in reality, attackers use many different methods and tools to attack AD environments. Therefore, it is important to know the features, techniques, and tools that we can use to protect AD environments further.

In an AD environment, there are different types of management tasks. Managing domain controllers, adding, modifying, and removing users, adding, managing, and removing groups, resetting passwords, and adding devices to a domain are just some examples. In a structured IT department, these management tasks can be assigned to different job roles.

As an example, let's assume that Rebeladmin Corp.'s IT department has first-line (first support contact), second-line (intermediate), and third-line (senior) IT teams. When considering the AD management tasks, first-line engineers are usually involved with tasks such as user password resets, setting...

Predefined AD administrator roles

AD has predefined administrator roles. Each of these roles has predefined permissions attached to them. If a user needs these role permissions, their account needs to be added to the relevant security group. These security groups are predefined groups:

• Enterprise Admins: This is the highest AD role permission that can be applied in the AD forest. The accounts that are part of this group can modify the logical and physical topology of the AD infrastructure. This also allows you to perform schema changes. This role is capable of managing other role memberships (Enterprise Admins, Schema Admins, and Domain Admins).
• Schema Admins: Members of this group can modify the AD schema. This is only included in the forest root domain as the schema is handled on the forest level.
• Domain Admins: This is the highest AD role permission that can be applied in an AD domain. When adding the first domain controller to the forest, the default administrator...

Using object ACLs

User or group access permissions to a shared folder are managed by the ACL. Similarly, we can define permissions to AD objects by using ACLs. This can be applied to individual objects or to the AD site/domain/Organizational Unit (OU), and then the same permissions can be forced onto lower-level objects.

As an example, I have a security group called First Line Engineers, and Liam is a member of this group. Liam is an engineer in the Europe office. In the AD environment, Liam should be allowed to add user objects under any sub-OU that is under the Europe OU. However, he should not be allowed to delete any objects that are under it. Let's see how we can do this using ACLs:

1. Log in to the domain controller as a domain admin/enterprise admin.
2. Review the group membership using the following command:

   Get-ADGroupMember "First Line Engineers"
   

3. Go to Active Directory Users and Computers (ADUC), right-click on the Europe...

Using the delegate control method in AD

The delegate control method also works similarly to ACLs, but it simplifies privilege management as it uses the following:

• The Delegation of Control Wizard can be used to apply delegated permissions
• A predefined task list is available via the wizard and we can easily map permissions to these tasks

This wizard contains the following predefined tasks, which can be used to assign permissions:

• Create, delete, and manage user accounts
• Reset user passwords and force a password to change at the next logon
• Read all user information
• Create, delete, and manage groups
• Modify the membership of a group
• Manage Group Policy links
• Generate Resultant Set of Policy (Planning)
• Generate Resultant Set of Policy (Logging)
• Create, delete, and manage inetOrgPerson accounts
• Reset inetOrgPerson passwords and force a password change at the next logon
• Read all the inetOrgPerson...

Implementing fine-grained password policies

Complex passwords are a basic security setting that any administrator uses. In the AD environment, password complexity settings and account lockout settings can be configured by using GPO settings, which are located at Computer Configuration | Policies | Windows Settings | Security Settings | Account Policies. Before Windows Server 2008, there was only one password policy and account lockout policy setting that could be applied to users. With Windows Server 2008, Microsoft introduced fine-grained password policies, which allow administrators to create different password and account lockout policy settings for individual users or groups. This allows you to protect privileged accounts using stronger policies than regular user accounts. This feature continued with every AD DS version after 2008 and is available with AD DS 2022 as well.

Once, I was working on an AD audit for a hedge fund. As part of the report, I recommended that they use...

Limitations

Fine-grained password policies have the following limitations:

• Fine-grained password policies can only be applied to users and global security groups. They can't be applied to OUs.
• By default, only domain admins/enterprise admins can set up/manage/delete fine-grained password policies. It is possible to delegate permission to other users if required.
• The minimum domain functional level is Windows Server 2008.

When you use fine-grained password policies, some objects may have multiple fine-grained password policies applied. However, only one password policy can be applied to an object at a given time. It is not possible to merge multiple policies either. So how do we know what is the winning policy? Or how can we enforce a policy? Let's find out the answers in the next section.

Resultant Set of Policy (RSoP)

RSoP uses the attribute value of msDS-PasswordSettingsPrecedence, which is associated with each password policy, to decide the winning policy. A precedence value is an integer value an administrator can define. A lower precedence value means higher priority. If multiple password policies are applied to the same object, the password policy with the lower precedence value wins.

The following list further explains how password policies work in an infrastructure:

• There are two ways to link an object to a password policy. The first method is via a directly linked policy. The second method is via group membership. If the policy targets a security group, its members will automatically link to the password policy. However, if a fine-grained password policy is linked to an object, it will be the winning policy.
• If there's no directly linked policy, the object will consider the lowest policy precedence. These policies are inherited from...

Configuration

There are two ways to apply fine-grained password policies. The first option is to use Active Directory Administrative Center (ADAC), and the other options are to use PowerShell cmdlets or ADSI Edit.

In ADAC, go to System | Password Settings Container. Then, right-click and go to New | Password Settings. This will open up a window where we can define the policy settings:

Figure 16.12: Password policy settings

In the policy window, we can define the policy name, precedence, and account lockout policy settings. Directly Applies To is the place where we can define the users or security groups this new policy should target. In the preceding example, I added the First Line Engineers security group as the target.

Fine-grained password policies can also be created using PowerShell:

New-ADFineGrainedPasswordPolicy -Name "Domain Admin Password Policy" -Precedence 1 ` 
-MinPasswordLength 12 -MaxPasswordAge "30" -MinPasswordAge "...

Pass-the-hash attacks

If a client needs to authenticate into a server successfully, the client needs to prove their identity. This is done by using a username and password. The client needs to present its username and password to the authentication server, and it will verify the identity. There are legacy protocols and systems that send this information in cleartext, even in an open network. Telnet is a good example of this. If someone is listening to traffic (packet capturing) on a Telnet session, they can easily capture a password as it is transmitted in cleartext.

Modern authentication protocols are well aware of these types of threats and use different technologies to encrypt credentials or create cryptographic hashes for identity verification. Cryptographic hash means a password string is transformed into a fixed-length digest using an algorithm.

Earlier, in the Authentication in an AD environment section, we saw how Kerberos authentication works using hash values. When...

The Protected Users security group

The Protected Users security group was introduced with Windows Server 2012 R2 and continued in Windows Server 2022. This group was developed to provide highly privileged accounts with better protection from credential theft attacks. Members of this group have non-configurable protection applied. To use the Protected Users group, the Primary Domain Controller (PDC) should be running with a minimum of Windows Server 2012 R2 and the client computers should be running with a minimum of Windows 8.1 or Windows 2012 R2.

If a member of this group logs in to Windows 8.1, Windows Server 2012 R2, Windows 10, Windows Server 2016, Windows Server 2019, or Windows Server 2022, then we can expect the following:

• Members of this group cannot use NTLM, digest authentication, or CredSSP for authentication. Plain-text passwords are not cached. So, any of the devices using these protocols will fail to authenticate to the domain.
• Kerberos's long...

Restricted admin mode for RDP

In a typical identity infrastructure attack, the first target is usually a regular user account or an endpoint. This is because highly privileged accounts and critical systems have advanced protection compared to end user devices (in most environments). A typical end user account does not have the privileges or capabilities to do much damage, but a privileged account does. Once an attacker completes an initial breach, the next thing they are looking to do is to get their hands on a privileged account.

If they start to mess around in an endpoint by doing things such as deleting files, increasing CPU/RAM usage, and damaging applications, then the end user will contact the IT department for help. IT department engineers are usually members of Enterprise Admins, Domain Admins, or at least a local administrator group of the endpoint. To log in and troubleshoot, engineers have to use their privileged accounts. If the attackers are running programs for password...

Authentication policies and authentication policy silos

The basic rule in PtH attack protection is to prevent trusted users from appearing on untrusted systems. Rebeladmin Corp. uses an MS SQL farm to run its databases. During the SQL Server setup, engineers use service accounts. It is obvious that these SQL service accounts should be used only with SQL Server. If the accounts appear on a receptionist's computer, something is definitely wrong. With Windows Server 2012 R2, Microsoft introduced authentication policies and policy silos that can be used to limit the use of highly privileged accounts to selected systems.

Authentication policies

Authentication policies can be used to specify the Kerberos protocol TGT validity period and access control conditions to restrict user sign-on.

Authentication policy silos

Authentication policy silos are similar to containers where we can assign user accounts, computer accounts, and service accounts. Then, these accounts can be managed by the authentication policies.

This feature requires the following prerequisites:

• All domain controllers in the domain must be based on Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, or Windows Server 2022.
• The domain's functional level must be Windows Server 2012 R2 or higher
• Domain controllers must be configured to support Dynamic Access Control (DAC)
• Windows 8, Windows 8.1, Windows 10, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, and Windows Server 2022 domain members must be configured to support DAC

Once all the prerequisites are in place, we can look into the configuration of authentication policies.

Creating authentication policies

Before we create policies, we need to enable DAC support for domain controllers and devices. DAC allows administrators to apply access control permissions and restrictions based on rules that can include the characteristics of the resources.

To enable DAC for domain controllers, perform the following steps:

1. Go to the Group Policy Management MMC.
2. Edit Default Domain Controllers Policy.
3. Go to Computer Configuration | Policies | Administrative Templates | System | KDC.
4. Click on Enabled to enable KDC support for claims, compound authentication, and Kerberos armoring.
5. Under Options, select Always provide claims and click on OK. This will ensure that it always returns claims for accounts and supports the RFC behavior to advertise Flexible Authentication Secure Tunneling (FAST):

   

Figure 16.21: Enabling KDC support for claims, compound authentication, and Kerberos armoring policy setting

To enable DAC...

Creating authentication policy silos

Now that we have created the authentication policy, the next step is to create a new authentication policy silo. My requirement is to create a policy silo to prevent the user account Peter from accessing REBEL-PC01.

Policy silos can be created using ADAC or the New-ADAuthenticationPolicySilo PowerShell cmdlet:

Figure 16.23: Creating new authentication policy silos

In this demo, let's create a new authentication policy silo called Restricted_REBEL_PC01:

New-ADAuthenticationPolicySilo -Name Restricted_REBEL_PC01 -UserAuthenticationPolicy AP_1hr_TGT -ComputerAuthenticationPolicy AP_1hr_TGT -ServiceAuthenticationPolicy AP_1hr_TGT -Enforce

In the preceding command, -UserAuthenticationPolicy, -ComputerAuthenticationPolicy, and -ServiceAuthenticationPolicy refer to the authentication policies that will be attached to the policy silo. Here, we are only using one policy, but if needed, the policy silo can be attached to multiple...

Secure LDAP

In an on-prem AD environment, there can be applications or services that require integration with AD. An AD-integrated application or service can query for AD users, authenticate, modify objects, and so on. This integration process is usually done using the Lightweight Directory Access Protocol (LDAP). By default, this LDAP connection between the client (application, service) and server (domain controller) is not encrypted. With this default configuration, a man-in-the-middle attacker can capture packets between the LDAP client and server, modify them, and then send the modified packets back to the server.

The LDAP server will not see the difference and reply to these forged requests with a decision. Microsoft is well aware of this vulnerability.

On August 13, 2019, Microsoft released a security advisory report, recommending to enable LDAP channel binding and LDAP signing to the LDAP client and server. For more information, refer to https://bit.ly/3CRmr0B...

Microsoft Local Administrator Password Solution (LAPS)

In a business, when setting up new servers or computers, most of the time administrators are using one common password for the local administrator account. This account is usually used as a backdoor by administrators for software installation/uninstallation, to log in when domain authentication is not working, for operating system troubleshooting, and so on. Most of the time, this password is a non-complex one as well. I have seen some people use well-known passwords like "Pa$$w0rd" for local administrator accounts. When someone leaves the company, we usually change their domain password or disable their accounts. But these local administrator accounts remain the same, as changing passwords on local accounts is a time-consuming, complex process.

However, in a typical identity attack, a compromised local administrator account allows attackers to perform PtH attacks and laterally move within the organization by compromising...

On-prem Azure AD Password Protection

In the very first chapter of this book, I mentioned the weaknesses of passwords and why we should consider passwordless authentication.

Passwords are guessable. As engineers, even if we enforce strong password policies, users always use passwords they can easily remember. Most of the time these passwords contain the company name, department name, product name, sports teams, current year, and so on. This makes it easier for attackers to guess the passwords based on dictionary attacks. Hackers don't break in, they log in, and unfortunately, dictionary attacks, particularly password spray attacks, are still one of the most commonly used techniques to find out the login details of an account.

Azure AD Password Protection can ban a list of common passwords globally to protect user accounts from dictionary attacks. However, this is not going to eliminate the threat of dictionary attacks because this all depends on the content of the password...

Summary

AD infrastructure security is a broad topic to cover in one chapter. AD security is not just dependent on AD DS; it is related to every layer of the OSI 7-layer model. At the beginning of the chapter, we learned about Kerberos authentication and what exactly happens behind the scenes when a user tries to access a resource in the AD environment. Then, we moved on to delegated permission control, where we learned about how we can delegate permissions to users, allowing them to only do specific administrative tasks. After that, we moved on to the Pass-the-hash attacks section, where we learned about PtH attacks.

Microsoft has introduced new tools and features that can be used to prevent PtH attacks. The Protected Users security group, restricted RDP mode, authentication policies, and authentication policy silos are some of them. In this chapter, we learned about how these tools work and how we can implement them in the AD environment. Then, we moved on to Microsoft LAPS....