Active Directory: what you need to know about password security

I. Introduction

For many organizations, Active Directory (AD) is at the heart of identity management in their Windows environment. It stores valuable user authentication information, including passwords. To guarantee their security, Active Directory uses specific mechanisms and hash functions to avoid storing passwords in clear text.

The aim of this article is to explain how passwords are stored in the AD database and what the security risks are. We will also present a free solution for identifying password weaknesses.

II. How does Active Directory store passwords?

The Active Directory database is contained in the file NTDS.ditstored by default in the C:WindowsntdsNTDS.dit. Its structure is based on a set of tables designed to store Active Directory information. Some of these tables store information on objects (users, computers, groups, etc.), others on the links between these objects, as well as on the objects' security descriptors, known as ACE (Access Control Entries).

This famous file NTDS.dit also stores a sensitive piece of data: the cryptographic fingerprints of passwords, i.e. the password hash. This means that user passwords are not stored unencrypted in Active Directory.

A hash algorithm calculates the hash of a password before saving it in the database. This is a "one-way function" (OWF) mechanism, described in Microsoft's documentation as follows: " A "one-way function" is a term used to describe a one-way mathematical transformation of data. Transformed data can only be converted by encryption in one direction, and cannot be inverted. "

On paper, a password hash may seem unbreakable, but it's not that simple. If an attacker manages to steal a hash, he can attempt to "crack" it to obtain the password in clear text. There are several known methods, from the simple brute force attack to the Rainbow Tables-based method. This is why the choice of algorithm is so important. Some are more robust than others. The evolution of machines, and the associated computing power, jeopardizes the robustness of certain algorithms (MD4, MD5, LM, for example).

Active Directory uses the following two hash functions:

• LM Hash (LAN Manager Hash)
• NT Hash (linked to NTLM)

Note: Active Directory passwords are not salted. As a reminder, salting consists in adding a random part to a password before sending it to the hash function. This increases resistance to certain attacks, notably brute force attacks.

A. The LM Hash method

The LM format is the oldest, and has been considered obsolete for almost 20 years. LM Hash is unique in that it supports only 14 characters. Here are the main steps in the mechanism used:

• If the password is less than 14 characters long, a padding action completes the string to equal 14 characters (NULL).
• Convert all passwords to uppercase (case insensitive)
• Divides the password into two 7-character blocks.
• Uses DES (Data Encryption Standard) to encrypt each block, which are then assembled.

Note: if the password is longer than 15 characters, the value generated will be incomplete and cannot be used to authenticate the user.

You should be aware that LM Hash generation has been disabled by default since Windows Vista and Windows Server 2008. Microsoft also offers a Group Policy Setting (GPO) to force its deactivation. This can be useful in environments where history means the setting is still active (for backward compatibility reasons).

You can configure this setting from the Group Policy Editor. It can be found in the following location: Computer configuration > Policies > Windows settings > Security settings > Local policies > Security option.

This parameter is entitled: "Network security: do not store LAN Manager level hash values on next password change". This parameter must be defined and activated. This is already the default behavior with Windows Server 2008 and later versions.

Please note that, this Group Policy setting is not available on Windows Server 2025. This is no surprise, since Microsoft has improved security in this area in Windows Server 2025. In fact, this sentence from Microsoft's website serves as a transition for the rest of this article: "NTLMv1 has been removed in Windows Server 2025, all other versions of NTLM, including LANMAN and NTLMv2, are no longer under active feature development and are not recommended."

B. The NT Hash method

In the 90s, Microsoft introduced a new password protection format to Windows: NT (New Technology). This dates back to the days of Windows NT, so the choice of this name is probably no coincidence. Today, Active Directory still relies on this method to store passwords in the Active Directory. Incidentally, the NT hash is linked to an authentication protocol you're probably familiar with: NTLM, version 1 of which is strongly discouraged.

NT Hash is obtained using the MD4 algorithm, used for hashing passwords, instead of the DES algorithm used by LM. There are also other notable differences:

• Password length: it can handle passwords of up to 256 characters, but there is a limit of 127 characters in the AD administration console.
• Case-sensitive: unlike LM Hash, NT Hash is case-sensitive, increasing the security of the hash.
• Single hash: the password is hashed in a single operation, without being split into two blocks.

The NT hash of a password is stored in the Active Directory database and represents sensitive data.

III. Reversible password encryption

A. The "Save password using reversible encryption" option

We're now going to talk about an option present in every AD object belonging to the user class, which represents a security risk.

At-risk accounts are those with the "Save password using reversible encryption" option activated in the account options. Enabling this option offers the opportunity to recover the password in clear text, which does not respect the "one-way function" mechanism mentioned above. However, if you check this option on an account, the effect is not immediate: the next password for the user in question will be stored reversibly.

Note: this concept is also available when creating a refined password policy, and is entitled "Store password using reversible encryption". The option then applies to all accounts to which the password policy applies.

When this option is enabled, it will have an impact on the ms-DS-User-Encrypted-Text-Password-Allowed. There's no need to search for it using the attribute editor or by browsing the Active Directory schema - you won't find it! In fact, Microsoft documentation mentions that the state of this attribute is visible through the attribute UserAccountControl.

So, with Active Directory, this attribute is not visible in the list of schema attributes. In contrast, it is visible in ADAM (Active Directory Application Mode), a version of Active Directory designed exclusively for applications (to play the role of LDAP directory only, without the authentication layer). Think of ADAM as an ancestor of the ADLDS role.

• Active Directory - Discovering the UserAccountControl attribute

By running a PowerShell script (which you can find in the article cited above), you can "convert" the UserAccountControl value and display the active flags. In the case of the user for whom the option was previously enabled, we can see the presence of the flag named ENCRYPTED_TEXT_PWD_ALLOWED. It proves that the option has been checked in the account settings and that it has a direct impact on the value of the attribute UserAccountControl.

Using PowerShell, you can list all Active Directory accounts where the "Save password using reversible encryption" option is checked:

Get-ADUser -filter {AllowReversiblePasswordEncryption -eq $True} -Properties "AllowReversiblePasswordEncryption"

B. Read a password stored in the clear in AD

When this option is checked, it is possible to recover AD passwords in clear text, without having to go through the "password cracking" stage that we'll discuss later in this article. One technique involves exploiting the DCSync attack using a tool such as Mimikatz or Impacket.

Read our articles on the DCSync attack to find out more:

• Active Directory: what is the DCSync attack?
• Active Directory: how to detect DCSync exploitation within a domain?

If we take the example of Mimikatz, the command below allows you to obtain the cleartext password for a specific user.

mimikatz # lsadump::dcsync /domain:it-connect.local /user:florian.burnel

The result in pictures:

The same applies to Impacket's secretsdump:

impacket-secretsdump -just-dc IT-CONNECT.LOCAL/<VULNERABLE_DCSYNC_ACCOUNT>@192.168.14.201

The result in pictures:

Finally, the cmdlet Get-ADReplAccount of the DSInternals module also helps us achieve our goal. It must have authorizations similar to those of the DCSync attack.

Get-ADReplAccount -SamAccountName florian.burnel -Domain it-connect -Server SRV-ADDS-01

The result in pictures:

As you can see, thanks to the "Save password using reversible encryption" option, it's possible to recover the password directly. However, there are a number of prerequisites for this, including the DCSync attack, which requires several prerequisites.

IV. Extracting Active Directory password hashes

Warning - The following is for information and educational purposes only, and should only be applied in a context where you have the necessary authorizations.

There are several tools available for extracting password hashes stored in the Active Directory database. The first step is to make a copy of the ntds.dit database to extract the information. The problem is that you can't simply copy and paste this file onto an online domain controller, as it is protected.

A number of more or less noisy methods are available, to be applied according to the context. These include the following native tools ntdsutil, vssadmin and DiskShadow (adding the tool reg). There is also an offensive tool called Invoke-NinjaCopywhich is a PowerShell script.

For example, the following command (which is actually a sequence of commands) allows you to export information by saving the data. The ifm refers to the creation of support for the installation of a domain controller from USB media (IFM).

ntdsutil "activate instance ntds" "ifm" "create full C:\Temp\NTDS" quit quit

In addition to creating a copy of the ntds.dit database, it is also necessary to export the Registry hive corresponding to the "C:\Windows\system32\config\SYSTEM" path, as it contains the key for decrypting the directory database.

Secondly, password hashes can be read using a variety of tools. One example is the PowerShell module DSInternals. Here's an example:

# Charger la clé
$BootKey = Get-BootKey -SystemHivePath "C:\TEMP\NTDS\registry\SYSTEM"

# Lister les informations sur tous les comptes Active Directory
Get-ADDBAccount -All -DBPath "C:\TEMP\NTDS\Active Directory\ntds.dit" -BootKey $BootKey

It is then possible to target a specific account, for example, the Administrateur domain account.

Get-ADDBAccount -DistinguishedName "CN=Administrateur,CN=Users,DC=it-connect,DC=local" -DBPath "c:\temp\NTDS\Active Directory\ntds.dit" -BootKey $BootKey

If we take a closer look at the information returned by the command, we can see the NTHash value: 2b391dfc6690cc38547d74b8bd8a5b49 ! The LMHash is empty, which is consistent with a Windows Server 2025 environment.

It is also possible to obtain a compact list with only the account names and the HashNT. So we can see something interesting (and worrying in production): the Administrateur and florian.burnel accounts have the same password! The hash is identical between these two accounts, and in the absence of salting, we necessarily have the same value.

This value can be exploited with other tools in an attempt to crack the password. This reinforces the idea that it is essential to use strong passwords, so that they are very difficult to break.

A tool like Hashcat can be used to perform brute force or dictionary attacks on the NTHash obtained above. The example below is based on the use of a password dictionary represented by the file passwords.txtwhile the value to be broken is present in the file named hashes.txt. Each time there is a positive result, it will be added to the output file. cracked.txt.

hashcat -m 1000 -a 0 -o cracked.txt hashes.txt passwords.txt

The -m is used to specify the type of hash: the value 1000 corresponds to NTLM. The -a 0 is used to specify that this is an attack based on a dictionary file. A few seconds later, Hashcat has completed its analysis and we can see that it has succeeded in breaking the password! The domain administrator therefore uses the password P@ssword! !

2b391dfc6690cc38547d74b8bd8a5b49:P@ssword!

This is a very simple case of an unacceptable password in production. Nevertheless, it shows the risks associated with the use of weak passwords, and potentially, the use of compromised passwords.

V. Auditing Active Directory passwords

When it comes to auditing Active Directory passwords, there's one free tool that immediately springs to mind: Specops Password Auditor. It's not the only tool of its kind, but it has the advantage of being accessible via a graphical interface, and above all, of generating a ready-to-use report in French.

This software will analyze the following points in particular:

• Password policy compliance (ANSSI, CNIL, NIST, BSI, etc.)
• Accounts with empty passwords
• Accounts with leaked passwords (compromised passwords)
• Accounts with identical passwords
• Domain administrator accounts
• Administrator accounts not protected against delegation
• Inactive administrator and user accounts
• Accounts where password is not required
• Accounts where the password never expires
• Accounts where the password is set to expire
• Accounts with expired passwords
• Password age for each user/administrator account
• List of password policies with key characteristics (including entropy)
• Use / assignment of password policies

This free software is based on a local password database containing over 1 billion compromised passwords. For further analysis, you'll need to upgrade to Specops Password Policy, a pay-as-you-go solution with more features and a database containing over 4 billion passwords.

You can find our full presentation article on this page (and our YouTube video).

• Identify compromised Active Directory passwords

VI. Conclusion

As we have seen, Active Directory relies on several algorithms for password hashing. NT hash is the only one we're likely to come across on recent environments, and yet it's not without its faults.

This article highlights two key recommendations:

• Do not use the "Save password using reversible encryption" option on user accounts (audit regularly!).
• Use strong passwords for user accounts, to protect against attacks targeting NT Hash (and LM Hash).