Why?

The move from traditional on-premises IT solutions to cloud services has seen a dramatic change in the way that systems are managed and controlled. The access to services from any location and using any device means that a lot of the traditional management methods are not feasible.

Identity (not the firewall) is the modern control pane. Your user identity (and how ever its protected) is typically the key to your applications, devices and data within the modern workplace so keeping it safe should be paramount.

The UK National Security Agency, any reputable security company or agency will advise you not to use the same password in multiple places, to make it complex, and to not make it simple like Password123 or Comanyname2019 for example.

What is Azure Identity Protection?

Aslong as your organisation uses Microsoft Azure AD – which it will if you use Office 365 (and have Azure AD Premium P1 or P2), Microsoft provides a nifty service (known as Azure Active Directory Identity Protection) that can go a long way in helping organisations guarantee that their users are follow industry (and your) security guidance and that they aren’t using common passwords or passwords that are known to be included in recent data attacks and breaches.

In addition to the automatic protection provided by Microsoft’s Threat Intelligent, Azure Identity Protection also allows you to manually specify up to 1,000 custom passwords. I’d strongly recommend adding (or using) the top 1,000 common passwords which is available on GitHub as a starter and then adding your own organisation’s name, and any common terms used in your company or industry to the list.

If you haven’t used the service before, you can run this in “Audit” mode to allow you to review the number of “hits” against the new policy before enforcing it. Once enforced, when any user tries to set/reset their password, their password is “scored” based on a combination of risks including use of known and common /custom passwords or known breach credential/password. 

How are passwords evaluated?

Whenever a user changes or resets their password, the new password is checked for strength and complexity by validating it against both the global and the custom banned password list (if the latter is configured).

Even if a user’s password contains a banned password, the password may still be accepted if the overall password is strong enough otherwise. A newly configured password will go through the following steps to assess its overall strength to determine if it should be accepted or rejected.

An invalid password reset attempt which is poorly scored as secured, will be rejected and the user will receive an error message similar to the below:

“Unfortunately, your password contains a word, phrase, or pattern that makes your password easily guessable. Please try again with a different password.”

Reviewing the effectiveness

As well as users being informed (and prevented) to setting a password that is “banned”, admins can also see this activity in the Security Logs.

Read more from Microsoft

Microsoft provides a lot more detail and examples on how this works here: