Creating enforceable, common-sense password policies has become increasingly critical in today’s business world. One major variable in that equation is terminology. While some words (or strings of characters) are fair game, others are taboo.
Thankfully, Active Directory lets admins define permitted terms with relative ease. The same goes for banned passwords. These are accordingly stored within Active Directory’s Banned Passwords List. This article will cover why an administrator might choose to exclude words, and how they may do so.
Why Exclude Words via Password Policy?
Let’s first consider an outside example: the four-digit PIN. Despite the simplicity of shorter passcodes, users still tend to pick predictable number sequences, like 0000 or 1234. These codes are easy to remember. Unfortunately, they’re also top of mind for thieves with stolen cards, mobile devices and online banking accounts.
Additionally, users often create codes that correspond with personal information, including addresses, birthdates or partial phone numbers. As a bad actor, wouldn’t you explore these obvious avenues first? Passwords have thus always taken center stage in the battle between security and convenience.
The comparison between PINs and alphanumeric passwords, of course, isn’t fully ‘apples to apples.’ However, similar principles reign supreme. It wouldn’t be wise for General Motors employees to include GeneralMotors or GM within their passwords – or terms like vehicle names and prominent office locations. You don’t want to make unauthorized access a relative cakewalk.
Security Breaches and Past Leaks
Lax password policies quickly create issues in the event of brute-force attacks. An attacker will submit flurries of password combinations in hopes of choosing the correct one. As mentioned, it’s a virtual certainty that company-specific terms will be vulnerable. Deferring to obscure combinations will keep remote hackers at bay. These passwords will outlast brute-force efforts, as SecOps teams work to eliminate the threat.
That said, Active Directory Password Policy doesn’t solely focus on excluding ‘easy’ words. Even compliant passwords might be involved in data leaks. It’s important to ban exposed passwords, as these are no longer deemed secure. Continued audits help companies recover from attacks whilst thwarting future ones.
Now that we’ve answered the why, how can admins go about excluding words via Active Directory?
How to Exclude Words within Active Directory Password Policy
At the most basic level, Active Directory’s default complexity option will provide some options out of the box. Company names aren’t all we need to worry about. Users must avoid using strings containing too many account-related characters (such as first name or last name) as well. Domain Password Policy can limit users from using revealing, sequential letters. These characters are inherently more ‘guessable.’ This enforces de facto exclusion of certain terms.
In a similar vein, Active Directory admins may establish password filters. These leverage DLL files for domain accounts, both for 32-bit and 64-bit computers. This requires three main components:
- A system registry key
- A Notification Packages subkey
- An existing password complexity setting or greater Password Policy
Passwords must satisfy any complexity requirements unless this option is disabled. Admins may apply these filters to all relevant domain controllers. This is another way of accomplishing what we’ve outlined in the preceding paragraph, though not calling upon a formal list of excluded words.
Via supplemental programming (e.g. with PowerShell) admins can write their own password DLL filters. This process is more time consuming than working within the GUI. However, it grants more control over both password complexity and character requirements.
Navigation Instructions
It’s worth noting that default password policies are applied to all computers within a domain. This Group Policy Object defines broad guidelines for all users. It’s possible to edit a Password Policy by following this hierarchy:
Group Policy Management > Domains > Chosen Domain > Group Policy Objects > Right-click + Edit.
This launches a new sidebar from which one’s settings are accessible. Next, it’s necessary to navigate to Password Policy. Admins must follow this file path:
Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Account Policies\\Password Policy
PowerShell users may instead view these policies using a single cmdlet:
Get-ADDefaultDomainPasswordPolicy
Moving On from Broad Policies
Determining password policies for an entire organization is often sufficient. However, admins may find a team-specific Password Policy is prudent. Instead of applying multiple, new Group Policy Objects (GPOs) to an Organizational Unit (OU), creating fine-grained password policies is required. Only the default domain policy’s password policy will otherwise apply.
Fine-grained policies leverage Active Directory Administrative Center (ADAC). Admins will have to install Remote Server Administrator Tools (RSAT) then launch ADAC to get started. The process is simple thereafter:
- Click on the domain
- Select the System folder
- Select Password Settings Container, and click New in the righthand Tasks sidebar
- In the opened Create Password Settings screen, admins can outline password policies and apply them to certain groups or individual users (which you can name or specify)
Security concerns differ from team to team, depending on function or controlled data. Crafting bespoke password policies is commonly needed for compliance reasons. Sensitive industries – typically subject to government regulations – have stringent security requirements that manifest themselves within Active Directory’s password settings.
What If We’re Using Active Directory with Azure?
The great thing about the Azure-AD tandem is that it permits direct usage of a banned passwords list. Admins can create lists of up to 1000 unique terms or phrases. These passwords or fragments are barred from user accounts for a number of reasons, and often for those we’ve outlined in our introduction. This applies to cloud and hybrid environments alike.
Submitted passwords are checked against one’s list(s) of excluded words. Any string match is flagged. The user receives feedback that their password was rejected, and must create a new one that meets organizational requirements. This article on banned passwords lists assesses how passwords are evaluated and scored, and any resulting implications.
Third-Party Tooling
Open and closed-source tools often step in when native configurations aren’t enough. Password policies are no different in this regard. Longstanding tools like OpenPasswordFilter (GitHub here) have given admins the ability to create dual dictionaries and apply them to Active Directory. The tool’s DLLs can be loaded via LSASS, according to its documentation.
For example, each list contains banned passwords and character strings. However, one checks passwords for complete matches to excluded words; the other checks for partial matches. If a password is forbidden, the user is told to create a new password. Maintaining the dictionary is key here, as the security landscape constantly changes. A service executable keeps everything up-to-date.
Specops Software also provides its own tool for password management. The solution supports six different dictionary types:
- Custom
- Compliance, via Specops’ Master List
- Common keyboard sequences and combinations
- LinkedIn hash leaks
- Adobe password leaks
- Gawker password leaks
In conjunction with add-ons, Specops Password Policy accounts for billions of banned passwords. This banned list is updated continuously in response to leaks and other security events.
In any case, we recommend that passwords meet or exceed 15 characters in length. It’s also recommended to put password age requirements in place. Even the best third-party solutions must play well with Active Directory. It’s important that such applications support one another, upholding the security of your infrastructure as a result.
