In Part 1 I described the problem with traditional password security. In Part 2, I’ll be uncovering the possible mitigations through tooling like Azure AD Password Protection, Multi-factor authentication, and more.

Simple Passwords

Azure AD Password Protection has been around for a while, although until recently this was only available for cloud-identities, rather than those based on-prem.

In order to give a good overview in this post, I’m not going to go into how an admin may configure this feature – MS do a good job of that

In summary, however, AAD Password Protection uses an on-premise agent located on a Domain Controller and, due to how AD operates, you’ll need to install the agent on all DCs to ensure it’s consistent.
The Azure AD Password Protection agent validates any password change, requesting a password policy from the Azure AD Password Protection proxy service. At no point is the password itself sent to Azure.

Azure AD Password Protection helps by intercepting a password change attempt (on-prem or cloud) and ensuring not only that the password meets the defined requirements, but also that it is not listed on a known list of bad passwords.

To improve efficiency, Password Protection holds a relatively short list of bad passwords (password, welcome, hello, etc) which it “fuzzy-matches” with the requested new password.
In this fuzzy-match process, Microsoft replace known obfuscation characters (such as @ for a), to distil a password to it’s main form. P@ssw0rd becomes password, $umm3r21 becomes summer21. If the password’s main form is a match for a banned password, then it’s blocked.

The result is, usually, that a user will have a hard time choosing any password that’s easy to guess.

Password expiration best practice

In part 1 I mentioned that some organisations prefer usability over security, and this is shown by having a relatively relaxed password policy. Ideally a minimum of 12 characters should be set, as this will not only increase the time taken to crack significantly, but will also reduce the likelihood of a password being re-used.

If a password is long and complex, there really isn’t much need to force the user to regularly change it.
Expiration policies only protect an account in the situation where the password (or password has) is stolen and can be directly used to gain access to the network. If the password has been stolen, a 60-90 day expiration window is way too long.
“Make the interval shorter?”
When “changing” their password, users typically only make a small (and easy to guess) amendment to their password, such as incrementing the last number. In that case, if the attacker knows the previous password, it’s pretty simple to guess the new one.

Alternatives to passwords with Modern

With users being asked to create and use long, complex passwords, it’s not surprising that this can sometimes translate into a poor user experience, or at least make users feel unduly burdened every time they need to log in.
With Windows Hello for Business, which allows users to login via a gesture such as facial recognition, PIN or fingerprint, users are rarely required to enter their complex password.

This can mean that users often struggle to remember their password after days of not having to enter it. Combine WHfB with Self-Service Password Reset and MFA, and users can quickly and easily choose a new, secure password if they need to, without bothering the helpdesk.

Beyond Passwords

If you haven’t already…. Enforce MFA.

There is really no excuse. Multifactor authentication is your organisations most powerful form of defence in a Cloud Connected world. User identities are accessible in the cloud, so are exploitable from the Internet.
With MFA enabled, an attacker is unlikely to be able to complete their attack, protecting the organisation from disruption or embarrassment.

If you have access to Azure AD Conditional Access (via Azure AD Premium), you should “Enforce MFA” through the use of targeted policies that ensure MFA does not become a nuisance for users. If a user is working on their enrolled corporate device, it’s probably OK to assume it’s the right person and not require MFA; if they move to a non-corp device, then an MFA challenge would be a good idea.


As exploits and attack methods become more sophisticated we must constantly adapt and improve our security posture in order to not be left behind and caught out. In a world where advanced, persistent threats are the norm, it’s even more vital than ever that user identities are secure by design.

Leave a Reply