Breached password detection with Azure AD

by Posted on

Introduction

This post serves to demonstrate the ability to implement on-premises breached password checking in a hybrid Azure AD environment that allows for self-service password resets.

This is more of a proof-of-concept than an explicit guide – you may well find that the information outlined here does not meet your business requirements. I mostly wanted to confirm that this was indeed possible.

In this instance, I’ll be using my Pwned Passwords password filter on the on-premises side for detection, however you could use any of the various password filters around.

End Goals

By combining the information outlined here with a DLL like my Pwned Passwords filter on-premises, alongside my C# project to detect in-use breached passwords, you could theoretically eradicate breached passwords from your hybrid environment 🙂

Requirements

In order to implement breached password reset detection for Azure AD, you’ll need

  • A breached password filter on your on-premises domain controllers
  • One of the following licenses on your tenant (for self-service password resets):
    Azure AD Premium P1
    Azure AD Premium P2
    Enterprise Mobility + Security E3 or A3
    Enterprise Mobility + Security E5 or A5
    Microsoft 365 E3 or A3
    Microsoft 365 E5 or A5
    Microsoft 365 F1
    Microsoft 365 Business

Getting Started

To start with, you’ll need a password filter on-premises. While you definitely don’t need to go with my filter, I’ve put some general instructions at the end of my first post here.

Once you’ve got an on-premises solution deployed, you’ll need to enable Azure AD Connect with password writeback – it’s the password writeback requirement that will require Azure self-service resets to be verified against your on-premises domain’s password requirements.

Posts such as this one do a great job of explaining how to set up password writeback, even going to great detail to discuss what permissions are required for the AD Connect account.

However, I’ll give a quick rundown on the process –

  1. On your AAD Connect server, start the Azure AD Connect configuration wizard
  2. Choose ‘Customise synchronisation options’
  3. Connect to Azure AD
  4. Select relevant OUs or domain filters
  5. On the ‘Optional features’ page, select ‘Password writeback’
  6. Select ‘Configure’

Once password writeback is successfully configured, you’ll need to allow your users to have access to self-service password resets in Azure.

This is somewhat more involved, especially if you’re rolling this out to a large amount of users. Once again, Microsoft have some great docs on planning deployment of self-service resets, through to actual deployment and testing.

Once you’ve got your self-service password reset portal in place, all that’s left to do is test it with a non-Administrator user, with a known breached password, and observe the result!

Conclusion

Thanks for reading. This has been my fourth, and likely final, post covering Troy Hunt’s amazing Pwned Passwords service. Through this series of posts, I’ve covered on-premises breached password reset detection, to utilising the online k-Anonymity model with resets, as well as checking currently used passwords against the data set.

With this post, I hope to have covered all possible facets, but I’m sure I’ve missed something somewhere, so please let me know if that’s the case!

As always, if you have any issues with anything here, or would like any extra information/further projects, please let me know 🙂