Troubleshooting tips for Microsoft Entra (formerly Azure AD) banned password list

Not all implementations of Microsoft Entra Password Protection (formerly Azure AD Password Protection) go smoothly. This blog explores some quirks with the banned password lists, and offers remediation and troubleshooting tips related to banned password list in Microsoft Entra.  

Understanding the Scoring System 

Many teams get tripped up when establishing their password policies in Entra ID (formerly Azure AD) and for good reason. First, there are two banned password lists. One is the Global Banned Password List, which is not a list of leaked passwords and does not fulfill compliance recommendations for a password deny list. Instead, it relies solely on Microsoft’s own analysis of what is being used in various Entra ID (formerly Azure AD) environments. The other is the Custom Banned Password list, which is Microsoft’s competitive offering to Specops Password Policy’s custom dictionary lists.

While the banned password list contains terms, you might believe to be banned, there’s some grey area. AD uses a scoring system for each created password. Each password must score 5 or higher to gain acceptance. This scoring is tallied using the following criteria:   

• How many unique characters a password candidate contains.
• Whether or not they contain (wholly or partially) terms from either custom or global banned passwords lists. 
• Whether a password is viable even after normalization (via character substitution) is complete. 
• The “edit distance” of added or deleted characters, which assesses how close those changes are in relation to the original (or banned) password. This prevents users from simply dropping a letter or tacking one onto a banned term, in hopes of passing. 

Users might be surprised when their passwords are rejected. For example, a substring match might flag a problematic term within a password (like someone’s name), and reject it, even though the complete password isn’t banned. Also, users can’t simply alter a banned password by adding or dropping a single character. Consequently, if abcdef is banned, AD will reject variations like abcdefg, or 1abcdef. Something like abc1def would be acceptable, however.  

The password loophole 

Interestingly, AD awards passwords a point for each banned word detected, thus pushing that password’s score closer to 5.  

That seems counterintuitive. After all, why should AD reward users for including a banned term? The idea is that wasted (banned) character strings within a potential password still contribute to overall password complexity.  

Banned password lists aren’t updating 

When it comes to Microsoft Entra (formerly Azure AD) banned passwords, some different rules are at play depending on your deployment. When you first create the custom list, or make changes to the list already in play, these changes may not push automatically. For example, a user could create a password using a banned word, even though that word was just added. Changes to global lists are pushed automatically in Entra ID (formerly Azure AD), but it can take a few minutes. 

Using a third-party solution 

Entra ID (formerly Azure AD) and many existing external tools don’t provide great user feedback. For example, password rejections generate a generic error message for users. Entra ID (formerly Azure AD) admins cannot customize these alerts.    

Third-party tools like Specops Password Policy give admins greater control over user feedback.  

• The flagged word that’s banned in a given dictionary, so users don’t include it moving forward 
• The rules users have satisfied 
• The rules users must still follow to make their password compliant 

Security improvements 

With Specops Password Policy and Breached Password Protection used in concert, companies can block over 4 billion compromised passwords in Active Directory. These compromised passwords include ones used in real attacks today or are on known breached password lists, making it easy to comply with industry regulations such as NIST or NCSC. Our research team’s attack monitoring data collection systems update the service daily and ensure networks are protected from real world password attacks happening right now. The Breached Password Protection service blocks these banned passwords in Active Directory with customizable end-user messaging that helps reduce calls to the service desk.  

Added flexibility 

Specops Password Policy can target any GPO level, group, computer, or user with complexity and passphrase settings. Custom dictionaries and breached lists are automatically updated and applied. Finally, lists may be stored locally or in the cloud. Specops is accommodating to your environmental setup, and helps alleviate many common problems that Entra ID (formerly Azure AD) users face.