Introduction to Active Directory banned password lists

(Last updated on January 19, 2021)

Cloud security has become a chief concern for security admins as platforms increase in popularity. These solutions are used daily and host a vast array of resources that teams must be able to securely access from anywhere. These remote drives and repositories are critical. They hold project documentation, ecosystem data, contact information, and business intelligence. 

The most common first line of defense is the login process. Password-driven authentication (normally) ensures that only verified users may breach the castle walls. No method is foolproof, however. Authentication has been a decades-long pain point for vendors and teams alike.

Enhancing security

Ongoing battles between convenience and galvanization have always impacted security. While we’d all love to make our passwords 1234 and call it a day, these passwords are painfully predictable. That undermines systemic security, thus granting bad actors greater opportunities to wreak havoc. 

A watchful eye has been turned towards Windows-based systems, which are far-and-away, the most popular. Teams leveraging Windows Server will also be familiar with Active Directory (AD). Admins use AD to oversee resources and user permissions. Password management is therefore a major component—and especially blocking weak passwords. We’ll explore how admins lockdown their networks via Active Directory.

Active directory banned password lists

Now under the Azure umbrella, Active Directory is often used to nix bad passwords completely. User attitudes toward security have historically been nonchalant. Accordingly, user education has an important role. How do teams respond when users inevitably deviate from guidelines? 

Administrators know that certain passwords should be automatically untouchable. These include any humorously-cliched regulars like password1111, and even qwerty. Just like Kubernetes professionals know that single-endpoint vulnerabilities can be catastrophic, sysadmins know that a poor password can topple the house of cards. 

Normally a password is ‘scored’ during creation, depending on its alphanumeric complexity, the system evaluates its strength. Longer, diverse passwords are typically favorable. That’s why you’ll see iCloud Keychain and other authentication managers suggest highly-convoluted passwords. They’re incredibly difficult to crack. 

Banned password lists offer an added layer of protection. How does this happen? Active Directory compares a potential password to lists of banned passwords. That password is rejected if there’s a match. The same process occurs during password changes and resets. Users must try again until requirements are satisfied.

Generating the lists

These banned password lists are created in two ways. Azure Active Directory maintains a default, global list of bad passwords. No admin action is needed here. Instead, the AD Identity Protection identifies these via continual data analysis. The following can condemn certain passwords:

  • They’re too common
  • They form the basis for other known, weak passwords (i.e. they’re root words)
  • They were involved in prior data breaches

These global lists are based on internal data, not external data. These rely on security telemetry, meaning routine audits are performed throughout Azure’s infrastructure and records. Analytical procedures by Active Directory staff members benefit all users. The same goes for organizations. Each enterprise AD user is known as a tenant, and password rules are applied to all users within a tenant. 

These lists are kept private for security purposes. Furthermore, local or regional terms might apply to users worldwide.

Applying custom rules

While companies can rely purely on global lists, sometimes organizations may have more-stringent requirements. There are many buzzwords that exist within organizations as well. Product names, acronyms, locations, and terminology are common knowledge. For this reason, including them within one’s password doesn’t follow best practices. Combinations and variants of key terms are also problematic. 

Companies know this, which is why certain phrases are blocked. Attackers will tackle the lowest-hanging fruit first, thus, it’s time to do some pruning. Any custom lists are automatically merged with global lists. 

That said, Active Directory limits custom banned password lists to 1,000 entries. Admins must decide which terms are paramount. That means adopting the hacker mentality and closely analyzing which passwords are vulnerable.

Password spray attacks

A common attack method is the spray attack, in which a handful of passwords are simultaneously attempted across numerous accounts. The goal isn’t to compromise scores of accounts, it’s to access those with subpar protections. Hackers test common passwords to achieve this. 

Thankfully, Active Directory banned passwords lists can thwart these efforts with ease. The same safeguards that save users from themselves can protect accounts. If those common passwords aren’t in play, then attackers have no ammunition.

What if my setup is hybridized?

The best thing about Active Directory is that it’s setup-agnostic. Security isn’t only essential for those running cloud-only systems. Many companies maintain on-premises components. The configuration process is slightly different; Active Directory requires admins to install Active Directory Domain Services agents atop local servers. 

Because these agents mesh with AD, all password changes are subject to banned password list scrutiny. The rules applied within Azure are extended to the datacenter—with one caveat. Password strength is critical, meaning that passwords containing banned terminology can be accepted. The complete password is potentially eligible if strong enough according to the scoring system.

What exactly happens?

  1. A password is normalized, in which banned passwords are matched to sets which are weaker. Case changes and character substitutions occur if necessary; this prevents users from setting variations of banned passwords that remain risky.
  2. A password is verified. Microsoft uses “fuzzy matching” and substring analysis to evaluate strength; if a password contains a successive string of banned characters, that password is rejected even when one character has been altered.
  3. A password is scored, where it’s evaluated based on its inclusion (or exclusion) of unique characters. Each unique character is worth one point. Passwords containing banned passwords must include varying degrees of differentiation. Only passwords with a score of five or higher are accepted.

Read more about Microsoft’s password scoring method here.

Teams hoping to bolster security will find tremendous value in Active Directory banned passwords lists.

Specops Password Policy offers a breached password protection service that allows organizations to block over 2 billion compromised passwords. The service blocks users from choosing banned passwords, and informs the user as to why they cannot use the passwords.

Contact us to start your free trial of Specops Password Policy.

tyler charboneau author

Written by

Tyler Charboneau

Tyler is a professional content writer with unabashed enthusiasm for technology—and a love for making the complex appear simple. He has a deep interest in software, hardware, and what makes complicated systems ‘tick.’ His pursuits include writing for multiple, online engineering and tech publications, including Adam the Automator. Content partners include All About Circuits, Autodesk, Nordic APIs, and others. Tyler has produced client works for nearly three years.
Website: www.tylercharboneau.com
LinkedIn: www.linkedin.com/in/tyler-charb-writes

Back to Blog