Lithnet Password Protection for Active Directory


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.


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.

The Author

Christian Knermann is Head of IT-Management at Fraunhofer UMSICHT, a German research institute. He's written freelance about computing technology since 2006.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=