« Previous 1 2 3 4
Lithnet Password Protection for Active Directory
P@ssw0rdis@s3cr3t!
Testing Existing Passwords
The rules of the game defined by GPO immediately affect any attempts by users to change their password. Even an admin setting a new password for a user account in the Active Directory Users and Computers console cannot override the rules. What about passwords that existed before you established the set of rules for LPP, though? This is where the Test-IsADUserPasswordCompromised
cmdlet can help. For a single user account, you can run it to check whether it uses a password known to be compromised:
Test-IsADUserPasswordCompromised -UPN <paul.ahner@knermann.local>
The cmdlet returns True or False. You can test all the user accounts in your environment in one fell swoop with a PowerShell script provided by Lithnet [8]. It writes all user accounts with blank passwords or passwords on the HIBP list to a CSV file so you can inform the affected users and prompt them to change their passwords.
Note that the cmdlet reads the hash value of the password from the AD database, not the password itself. Consequently, the cmdlet can only check whether the password is known in HIBP. The tool does not determine whether the password meets your other complexity requirements. Furthermore, reading a hash value also requires very far-reaching permissions. The account in whose context you use the cmdlet and the script must be a member of the Domain Admins group or have at least the Replicating Directory Changes All (DS-Replication-Get-Changes-All) permission, which is popular among users of the Mimikatz tool, which can be abused in a DCSync attack [9]. Accordingly, you should only use the tool and script on trusted devices, preferably directly on a domain controller.
Conclusions
Lithnet Password Protection for Active Directory proves to be far more flexible than Microsoft's onboard tools. Unlike the onboard tools, LPP supports variable rules that check the length of a password as a function of its complexity. The only disadvantage is that LPP does not improve the Windows client's ability to communicate problems. If a password does not pass your set of rules, Windows will only return an uninformative default message to the end user with no indication of exactly which condition prevented the password from being changed. The introduction of LPP needs to be accompanied by an organizational campaign to make your users aware of the need for secure passwords and an explanation of the new rules.
Infos
- BSI: Creating secure passwords: https://www.bsi.bund.de/DE/Themen/Verbraucherinnen-und-Verbraucher/Informationen-und-Empfehlungen/Cyber-Sicherheitsempfehlungen/Accountschutz/Sichere-Passwoerter-erstellen/sichere-passwoerter-erstellen_node.html (in German)
- NIST Password Recommendations: https://www.netsec.news/summary-of-the-nist-password-recommendations-for-2021/
- How secure is my password?: https://www.security.org/how-secure-is-my-password/
- Password filter: https://docs.microsoft.com/en-us/windows/win32/secmgmt/password-filters
- Lithnet Password Protection: https://github.com/lithnet/ad-password-protection
- Published passwords: https://haveibeenpwned.com/Passwords
- Lithnet event logging and reporting: https://github.com/lithnet/ad-password-protection/wiki/Event-logging-and-reporting
- Audit of existing passwords: https://github.com/lithnet/ad-password-protection/wiki/Audit-existing-passwords
- DCSync attacks against the Active Directory: https://hkeylocalmachine.com/?p=928
« Previous 1 2 3 4
Buy this article as PDF
(incl. VAT)