5 Active Directory Mistakes You Should Avoid

While AD remains a critical part of enterprise infrastructure, it’s also a breeding ground for avoidable mistakes and legacy pitfalls. To ensure that your systems run smoothly and securely, here are five things we really don’t want to see in your AD setup.

1.    Not Using “Protected Users” Security Group

In an ideal secure environment, robust tiered modeling ensures that highly privileged users never log in to regular workstations.

However, in real-world scenarios, we often observe highly privileged accounts being used on non-administrative workstations. This practice significantly increases the risk of credential theft and other attacks if an attacker gains admin access to the workstation. Examples of such risks include:

• Session hijacking
• Token impersonation
• Credentials dumping

Microsoft has a decent solution which can provide great protection with minimum effort and cost: adding high privilege users to the “protected users” security group.

According to Microsoft, this solution provides the following:

• Credential delegation (CredSSP) doesn’t cache the user’s plain text credentials even when the user enables the “Allow delegating default credentials” Group Policy setting.
• For Windows 8.1 and later and Windows Server 2012 R2 and later, Windows Digest doesn’t cache the user’s plaintext credentials even when they’ve enabled Windows Digest.
• NTLM stops caching the user’s plaintext credentials or NT one-way function (NTOWF).
• Kerberos stops creating Data Encryption Standard (DES) or RC4 keys. Kerberos also doesn’t cache the user’s plaintext credentials or long-term keys after acquiring the initial Ticket Granting Ticket (TGT).
• The system doesn’t create a cached verifier at user sign-in or unlock, so member systems no longer support offline sign-in.

Even though it’s not a perfect solution, it’s a nice layer of security that can make the attacker’s life a bit harder.

Protected Users global security group memberships restrict members to only use Advanced Encryption Standards (AES) for Kerberos. Members of the Protected Users group must be able to authenticate using AES.

2.    NTLM v1 Enabled

NTLMv1 (NT LAN Manager version 1) was introduced in 1993 as part of the Windows NT operating system. At the time, it provided a relatively secure method for authentication, given the technology and computing power available.

At the time, plaintext password transmission ruled the networking world in ways that were vulnerable to interception and cracking. Net-NTLMv1 introduced hashed authentication and eliminated plaintext password transmission.

NTLM(NTHash) is the hashing algorithm used for modern Windows systems, while Net-NTLM is the protocol that uses the NTHash in a challenge/response between server and client.

A few words about challenge/response:

When a user logs in, the client hashes the password and discards the plaintext. It sends the username to the server, which generates an 8-byte challenge (nonce) and sends it back. The client encrypts the challenge with the hashed password and returns the response. The server forwards the username, challenge, and response to the domain controller, which retrieves the stored password hash, encrypts the challenge, and compares it to the response. If they match, authentication succeeds. The plaintext password is never transmitted.

Today, legacy systems from the era of NTLMv1 remain in use within critical infrastructure environments. Forcing domain controllers to maintain backward compatibility due to the inability to modernize foundational systems.

So, what seems to be the problem?

Using this protocol can cause the following issues:

• Gaining credentials using LLMNR or NBNS poisoning and crack it offline
• Executing NTLM relay attacks without being constrained by the defense mechanisms applied to NTLMv2, enabling the attacker to escalate privileges and gain high-level access within the domain.

Consider disabling NTLMv1, especially if you don’t have legacy systems that require backwards compatibility.

Audit NTLMv1 authentication events reference: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/active-directory-hardening-series—part-1-%E2%80%93-disabling-ntlmv1/3934787

3.    ADIDNS Poisoning

This high-severity vulnerability is seen in the wild, as DNS is essential for the proper functioning of Active Directory services.

Typically, Active Directory Domain Services (AD DS) is installed as part of domain services, providing integrated storage and replication for DNS records (ADIDNS). By default, any member of the “authenticated users” security group is permitted to create records. This allows users to create records that do not already exist (using LDAP and dynamic updates).

Wildcard DNS records further amplify this issue by enabling the DNS server to function similarly to LLMNR/NBNS spoofing. When a wildcard record is created, the DNS server uses it to respond to name requests that do not explicitly match existing records in the zone. This can be abused by an attacker to set up a listener and respond to those DNS requests, coercing* authentication and performing NTLM relay attacks or harvest hashes and crack them offline.

Even if the wildcard record already exists, attackers can abuse DNS record creation for different types of attacks:

1. Coerce authentication externally to an attacker-controlled IP address.
2. Internal phishing campaigns—creating a similar host name and hope for a victim to make a typo.

Microsoft has not yet released an official fix for this issue. However, we recommend restricting the ability to add DNS records, including wildcard records, to administrators only. Additionally, creating a wildcard record can prevent other users from modifying, deleting, or creating a new wildcard record.

Wildcard DNS records can potentially disrupt the DNS resolution order in some legacy systems due to the DNS resolution process.

*coercing refers to forcing a windows host to connect to the relay/listener server using various techniques such as PetitePotam, PrinterBug, etc. 

4.    Kerberoasting

It’s hard to believe we’re still saying this in 2025, but kerberoasting remains an issue. This attack method continues to linger, and honestly, it’s well past time we crossed it off our checklist for good.

This is an easy-peasy, lemon-squeezy abuse method when gaining access to an internal domain network as a domain user.

Authenticated users are able to request a Kerberos ticket for a specified Service Principal Name (SPN). The obtained ticket is encrypted using the hash of the service account’s password linked to that SPN. (An SPN is an attribute that ties a service to a user account within the AD). An attacker can take the SPN to crack the password hash offline and gain the password of the service account.

We recommend configuring AES encryption for Kerberos tickets instead of RC4 and enforcing strong passwords for service accounts.

5.    Weak password practices, insecure hashing and encryption algorithms.

LM hashing:

Even though LM hashes are extremely old and vulnerable, we still see those hashes in the wild. But some of you may ask, what’s the problem with LM hashes?

• The LM hashing algo is built to support only up to 14 characters long and if it’s less than 14, it will add zeros.
• LM hashing uses the same string in the encryption process.
• The password is converted to uppercase.
• There is no salting mechanism, so the same password will always generate the same hash.

…and many more.

All the above makes LM hashes easier to crack within minutes.

So why on earth are organizations using LM these days?

• Default legacy leftovers
• Compatibility requirement to legacy systems

Even if LM hash is disabled in your domain, it doesn’t necessarily mean that it is eliminated or not present.

Reversible encryption:

The “store passwords using reversible encryption” policy setting in Active Directory controls whether passwords are stored in a manner that allows them to be decrypted. This setting uses a reversible encryption scheme, enabling the retrieval of passwords during the authentication process.

It is primarily designed to support legacy applications that require passwords in plain text to function correctly.

Weak password practices:

Though Microsoft is pushing towards a passwordless world, most organizations today still use password-based mechanisms.

But people LOVE easy and memorable passwords, especially if they are required to access various services using different accounts.

As long as passwords and users are in a relationship, we will see the following problems:

1. Easy guessable patterns (Winter2024, orgname2024). Every company has a different pattern; the hacker just needs to figure it out.
2. Username in the password (username: john, password: John123).
3. No complexity (passwords like 123456789).
4. Well known passwords (everyone loves qwerty123).

Another critical issue is password reuse. Users often recycle the same password across multiple accounts, increasing the risk that a breach in one system could compromise others.

How Can You Reduce the Risk?

Insecure hashing and encryption algorithms:

Seriously now, if LM is enabled, disable it and change all passwords.

• If LM is disabled, and your domain exists since server 2003 or below, change the password for any user that hadn’t changed their password in over 10 years.
• If you hate changing GPOs, you can always force a password length of 15 characters to avoid usage.

For more information: https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/prevent-windows-store-lm-hash-password

For reversible encryption, ensure that the “store passwords using reversible encryption” policy is turned off.

Weak password practices:

1. Minimize the usage of password-based authentications
2. Implement MFA on every password-based authentication.
3. Blacklist known passwords and disallow usage of username in the password creation process. For more information:  https://learn.microsoft.com/en-us/windows/win32/secmgmt/strong-password-enforcement-and-passfilt-dll

Outro

Let’s focus on keeping Active Directory environments secure, efficient, and free of unnecessary risks. Addressing these common pitfalls now can save us from bigger headaches down the line. Here’s to smarter AD management, stronger security, and fewer “if it works, no need to change” and “no, this is just a temporary configuration” moment. Let’s focus on streamlined, resilient Active Directory operations—because a little prevention beats a lot of repair.