In this article, we will explore why and how to block the use of certain passwords for Active Directory user accounts. In an Active Directory environment, password security is a critical factor in protecting user accounts against cyberattacks. However, even with a strict password policy in place, some users or administrators may still choose weak passwords or ones that can be easily guessed. To strengthen the security of your domain, it is possible to prevent the use of specific passwords.
Why block certain passwords?
There are several scenarios in which it is advisable to prevent users or administrators from setting specific passwords.
The larger and older an Active Directory environment becomes, the higher the likelihood of poor practices and notable weaknesses. Throughout my career as a pentester, I have conducted numerous internal penetration tests in companies of different sizes, levels of maturity, and industries. In many cases, password reuse across multiple user accounts allowed me to compromise several accounts, including privileged ones, which sometimes led to the complete compromise of the domain.
To strengthen security and increase resilience against cyberattacks, it may be necessary to block specific passwords, especially when they arise from the following situations.
Common initial password for all accounts
A common practice within administration teams is to assign the same initial password (often referred to as a default password) to every new user, with the instruction to change it as soon as possible. A typical example of such a password could be “Welcome2024!”.
However, this password change is not always enforced, especially when it is not technically required. In many cases, it is possible to find user accounts still configured with this password even years after their creation, either because they were never used, or because the password change requirement was not applied (e.g., technical accounts, test accounts, or so-called temporary accounts).
In such situations, and when aiming to put an end to this poor security practice, it can be useful to specifically block this password from being used in future account creations or password resets.
Poor password reset procedures
Another situation I have frequently encountered is related to password resets. When a user forgets their password (which often happens after coming back from vacation, especially when a complex password policy is in place), administrators sometimes take the easy route by resetting it to the same predefined value, such as “ResetPassword!”. They might then inform the user with a message like: “I’ve reset your account with the default password.”
As a result, many users end up knowing this password and may attempt to compromise a colleague’s account with it. This practice can also be exploited by an attacker who gains knowledge of the password, for example, after compromising the company’s ticketing system.
Lack of originality when changing passwords
When the practice of assigning a common default password to all users is in place, users often end up making only minor, predictable changes when a password update is required, for example: “Welcome2025!” or “ResetPassword1!”.
In such cases, and particularly when aiming to eliminate the use of default passwords left over from outdated practices, it can be useful to block not only the default password itself but also its weak derivatives (“Welcome2025!”, “Welcome2026!”, etc.).
This restriction should apply not only to users but also to administrators and Help Desk staff.
It is also important to note the general lack of originality when users create passwords. Based on my experience reviewing numerous passwords in compromised Active Directory environments, the vast majority follow a handful of predictable patterns such as:
- [CompanyName]2024
- [PartnerName][AnniversaryDate]
- [RegionName][PostalCode]
- [ChildName][BirthDate]
Some of these patterns, particularly those containing the company name, region, or department, can and should also be blocked if the right tools are available.
Compromised passwords
It can also be wise to block the use of passwords that are already known to be compromised. In practice, several situations may reveal that a password or account has been exposed, for example, during a digital forensic investigation following a breach or suspicious incident, or through OSINT (Open Source Intelligence) research conducted by your security team or an external provider.
The idea behind this approach is to proactively search open sources to identify whether user accounts, credentials, or passwords have leaked and are being sold on the Dark Net. If a compromised credential is discovered, the account should of course be disabled, its password reset, and that password added to the banned password list. This ensures that it can never be reused, neither by the affected user nor by anyone else.
What are the risks?
The risks associated with using a compromised password, or the same weak password across multiple accounts, are obviously significant. They include the compromise of user accounts by a black box attacker (one who only has network access and no valid AD credentials at the start), or by another user attempting identity theft. In some cases, this can even lead to privilege escalation, such as gaining access to an administrator account.
In practice, once an attacker uncovers a password during a cyberattack, especially if it follows an intelligible structure, it almost inevitably triggers brute force or password spraying attempts. The attacker will then try to answer the question: “Do other users share the same password, or a weak variation of it?”
It is also worth noting that IT teams often discover the widespread use of common passwords only after events such as:
- a forensic investigation following a breach,
- a penetration test that led to domain compromise and the extraction/analysis of the NTDS.DIT Active Directory database,
- a periodic audit of Active Directory passwords,
- or a review of organizational procedures for managing the user account lifecycle.
If none of these situations have yet occurred in your environment, it is time to consider proactive measures (ideally before the first scenario happens!). Now that we have established the risks, let’s explore the measures you can take to prevent the use of specific passwords within Active Directory.
Password Policies in Active Directory
The first step toward strengthening the overall robustness of passwords is, of course, enforcing an appropriate password policy within Active Directory.
This policy allows you to define several criteria to ensure that all newly created or modified passwords (after the policy is applied, an important detail) meet a minimum standard of complexity and format. These criteria typically include:
- Minimum password length
- The requirement to use special characters, numbers, uppercase, and lowercase letters
- Periodic password renewal
However, the native password policy features in Active Directory do not allow administrators to block specific passwords from being used. For example, the password “Welcome2024!” may fully comply with your policy, but it is still predictable, and Microsoft does not provide built-in tools to prevent its use.
Likewise, even if a compromised password is discovered through OSINT research, there is no way to guarantee that this password is not currently in use by one of your users.
Banned Password Filters in Active Directory: What Are the Technical Solutions?
To go beyond the default password policy, we can look at specific tools that explicitly prevent users or administrators from setting certain passwords.
As mentioned earlier, this need often arises following a compromise, a penetration test, an AD password audit, or a change in password assignment procedures.
A common improvement in account provisioning practices is to decide: “We’re no longer using this default password, new ones will be randomly generated instead.” Unfortunately, bad habits are hard to break, and in many cases, technical tools are necessary to enforce such restrictions effectively.
Using Microsoft Entra Password Protection
If your on-premises Active Directory is connected to an Azure tenant through Entra ID Connect, you can leverage Microsoft Entra Password Protection (formerly Azure AD Password Protection) to block common or weak passwords using custom lists. It relies on a Microsoft-managed database of disallowed passwords, which can be extended with your own banned password list.
Here is what the configuration interface for this feature looks like:
Even though your on-premises AD can be protected with this feature, it is important to note that Microsoft Entra Password Protection is not a free tool. In fact, synchronized users must be covered by a Microsoft Entra ID Premium P1 or P2 license in order to benefit from this protection.
If you are unable to use Microsoft Entra Password Protection to block specific passwords, there are alternative solutions available.
The Specops Password Policy Solution
As a paid, third-party alternative, Specops Password Policy (SPP) offers a wide range of features for securing and auditing AD passwords, including:
- Detection of compromised passwords already present in Active Directory
- Creation of an unlimited, custom dictionary of blocked words and passwords specific to your organization
- Blocking the use of usernames, consecutive characters, or incremental passwords when setting a password
- Prevention of compromised passwords from being used (during ongoing attacks)
- Management of password expiration and user assistance
- And more.
The feature that allows administrators to explicitly block specific passwords is particularly relevant in this context. Below is an example of how Specops Password Policy handles this restriction:
This solution makes it possible to build a comprehensive dictionary of words and passwords to be blocked. The entries you add to this list should, of course, include those identified in the scenarios mentioned earlier: poor password creation habits, account resets, as well as passwords already known to be compromised. You should also consider including weak variations of these passwords in your blocklist.
On that note, Specops Password Policy includes a feature that automatically blocks variations of blacklisted passwords. It generates possible derivatives using common substitution patterns or incremental naming (e.g., “Bienvenue2024!” becoming “Bi3nvenue2O24” or “Bienvenue2025”). This eliminates the need to manually anticipate every possible case.
Specops Password Policy goes far beyond simply blocking specific passwords. For instance, it allows administrators to prohibit identical or consecutive characters and even define custom regular expressions to prevent certain patterns from being used in passwords.
Returning to the earlier point about blocking compromised passwords, Specops Password Policy provides a feature called Breached Password Protection. This service compares the hashes of Active Directory user passwords against a continuously updated list of known compromised password hashes.
This database contains over 4 billion entries collected from major data breaches and passwords used in real-world attacks. Specops also enriches this list with intelligence gathered from its own honeypots.
Whenever a password change is attempted in Active Directory, the service checks the new password against this database. If it matches a banned entry, the system blocks the change and alerts the user.
User awareness
User awareness is another tool, imperfect, but essential, for strengthening password robustness within Active Directory. While security policies and password filters can be enforced, the human factor often remains the weakest link in the security chain. It is therefore crucial to train users by explaining what constitutes a strong password and why adopting robust, unique password practices is necessary.
A powerful way to raise awareness is by relying on concrete examples, especially if the organization has already been the target of an attack. Users are far more receptive when they realize that these risks are not theoretical, but very real.
Internal statistics can also be particularly impactful if results from a security audit of your information system are available. If users have already been forced to reset their passwords, a live demonstration during a training session can be highly effective. For instance, showing problematic examples such as “Welcome2024!” followed by “Welcome2025!” helps illustrate why small variations of the same password do not provide adequate security.
In addition to awareness training, it can be valuable to actively test password robustness, either through broader technical audits (such as penetration tests) or targeted audits focused specifically on Active Directory passwords.
Conclusion
In this article, we have examined situations where passwords, though technically compliant and seemingly strong, may still be shared across multiple user accounts, thus creating significant security risks. We also reviewed the consequences of these practices and, most importantly, the available solutions to block specific passwords for Active Directory user accounts.
Preventing the use of certain passwords in Active Directory is therefore an essential security measure to reduce the risk of account compromise and strengthen your organization’s overall resilience against cyberattacks.
