Active Directory Password Policy Best Practices
Active Directory Password Policies: NIST Recommended Best Practices
End-user passwords are one of the weakest components of your overall security protocols. Most users tend to reuse passwords across work and personal accounts. In Microsoft Active Directory, you can use Group Policy to enforce and control many different password requirements, such as complexity, length and lifetime. However, starting from Windows Server 2008 domain functional level, MicroSoft lets administrators define fine-grained policies for different organizational units using the Active Directory Administrative Center or PowerShell.
When developing a strong password policy, there are a number of best practices you should keep in mind. Follow these recommended points to ensure you have a robust password policy in place.
- Reject passwords that are less than 8 characters
This is a straight-forward NIST requirement. It can be easily satisfied with the existing Active Directory password length policy. - Reject chosen passwords if found to be previously compromised
Data breaches occur every day. Obtaining compromised or exposed passwords is a continuous effort. The model is relatively similar to antivirus threat intelligence, and is best left to specialists. - Reject common and likely passwords
Common passwords and likely passwords are found in cracking dictionaries. These word lists with common transformations are built by hackers and evolve. Incorporating them turns the attackers’ weapon into a defensive tool. - Reject context-specific words in passwords
Common password choices also vary by context and location. Consider the name of your business, application, etc. The password blacklist must be enhanced with a custom dictionary to block context-specific passwords. - Consider common variants using fuzzy matching
Attackers conduct basic transformations made during password creation. By normalizing the password (i.e. making it case insensitive, removing leetspeak substitutions, etc.) again, turn attack tactics into defensive measures. - Detect and immediately remediate newly vulnerable passwords
Although more challenging to implement, this is perhaps the most critical requirement. In the current environment, the password that is initially screened and determined to be safe may become vulnerable. Mechanisms are needed to revisit password after initial screening, ideally daily, to detect compromise and automate remediation – including resetting a secure password.
By addressing password policies at both the Administrator and end-User levels, the security of the organization can be drastically improved.
Related Articles
Best Practices for Configuring Group Policy Objects
GPO Best Practices Group Policy makes dealing with your operating system easier and more effective. In addition, this allows you further control over network accounts. This makes your network safer from outsiders. Moreover, it reduces the trusted ...
How to Change Account Lockout Policy using Group Policy Objects in Active Directory
Changing the Active Directory Account Lockout Policy Introduction to Active Directory Account Lockout Policy Account lockout policies are used by IT administrators to lock out an Active Directory account after multiple unsuccessful attempts. It is ...
Change the password of a domain user account using PowerShell
Managing domain user accounts is a crucial task for system administrators, and one of the common tasks is changing a user's password. PowerShell provides a powerful and efficient way to automate this process. In this comprehensive guide, we will ...
Three Best Practices for Securing Active Directory
Active Directory Security: Three Recommended Best Practices Active Directory places a central role in authorizing user access and applications. Hence it is no surprise that organizations, world over depend on it for day-to-day IT operations such as ...
Best Practices | Active Directory FSMO Roles
FSMO Roles in Active Directory In Flexible Single Master Operation, the responsibilities of the single-master are split into separate roles. These roles can be distributed to any domain controller in the enterprise, based on the requirements. This in ...