Azure AD Password Protection is now generally available!

[Alex Simons (AZURE)]

Howdy folks!

Many of you have already been using Azure AD Password Protection in public preview. Azure AD Password Protection allows you to eliminate easily guessed passwords and customize lockout settings for your environment. Using it can significantly lower the risk of compromise by a password spray attack. Best part, it’s available for both cloud and hybrid environments. We’d like to thank all the customers who have tried the preview and provided us valuable feedback.

Today, I’m excited to announce this feature is now generally available! 

To help users avoid choosing weak and vulnerable passwords, we updated the banned password algorithm. Using the global banned password list that Microsoft updates and the custom list you define, Azure AD Password Protection now blocks a wider range of easily guessable passwords.

Read our detailed documentation to learn more about how password strength is evaluated and how Azure AD Password Protection can help block weak passwords in your organization.

Getting started

Azure AD Password Protection can easily be configured from the Azure AD portal. First, sign-in to Azure Portal with a global administrator account. Next, navigate to the Azure Active Directory and then to the Authentication methods blade, where you’ll see Password protection, as shown below:

 

Configure Azure AD Password Protection

1. Customize your smart lockout threshold (number of failures until the first lockout) and duration (how long the lockout period lasts).
2. Enter the banned password strings for your organization in the textbox provided (one string per line) and turn on enforcement of your custom list. We strongly recommend this for all customers that have multiple brands and products that their users identify with.
3. Extend banned password protection to your Active Directory by enabling Password Protection for Windows Server Active Directory. Start with audit mode, which runs Password Protection in “what if” mode. Once you’re ready for enforcing Password Protection, flip the mode to Enforced to start protecting users by preventing any weak passwords being used.

Note: All synced users must be licensed to use Azure AD Password Protection for Windows Server Active Directory.

Protecting your on-premises environment

To use Azure AD Password Protection on our Windows Server Active Directory, download the agents from the download center and use the instructions in the Password Protection deployment guide.

Once a global administrator has enabled Password Protection for Windows Server Active Directory, security administrators can take it from there and complete the registration for both proxy agents and Active Directory forests. Both the domain controller agent and the proxy agent support silent installation that can be leveraged using various deployment mechanisms like SCCM.

Note: Preview customers MUST update the agents to the latest version (1.2.125.0 or higher) immediately. The current agents will stop working after July 1, 2019.

As always, we're eager to hear from you! Still have more questions for us? Email aadppfeedback@microsoft.com. We look forward to hearing your feedback!

Best regards,

Alex Simons (@Alex_A_Simons )

Corporate VP of Program Management

Microsoft Identity Division

[ChadWst]

Jay Simmons

Yes it does. We are implimenting in a DEV forest and I'm making some notes what to look for as we walk through the setup. Thx!

[Jay Simmons]

Glad to hear that.

One quick note for anyone else who may be reviewing this blog post and still has questions.  We can also answer ad-hoc inquiries over email using the aadppfeedback@microsoft.com alias.  That option may be easier and more efficient than back-and-forth'ing in the comment section.   

Jay Simmons

[EricBender]

I have  a question on the requirements side of things.  Can this function operate with the use of a 3rd party AD synchronization tool?  I thought I read somewhere that the password protection has to have AD Connect (or whatever the flavor is at the current state).  Our security team is pushing to use Okta as the Directory sync product for our Hybrid environment.  Can I get a confirmation of what the specific requirements are in relation to the synchronization methods in regards to user/directory synchronization to support the password protection functions.

[Jay Simmons]

Hi @EricBender,

The onpremises behavior of Azure AD Password Protection does not have any dependency on which specific synchronization tool is being used.  So while I cannot recommend using Okta in your environment, it should not block or interfere with AADPP.

thx,

Jay

[Andrew Thompson]

Is there a way to audit changes made to the password protection policy?  Examples being, changes to the banned password list, and changing from enforced to audit mode etc?

Thanks in advance!

[BenJun]

Found this article and am about to deploy this to our structure.

The main reason for that would be, to have a smart lockout szenario if an attacker tries bruteforce/password spray against the MS365 architecture.

The banned password list isnt really neccessary.

So would it be possible, to activate this all in AzureAD but dont install the 

• AzureADPasswordProtectionDCAgent
• AzureADPasswordProtectionProxy

on premise?

Or would it result in AzureAD Sync fail as local set passwords could possibly be on the banned password list?

Is there another method to have the smart lockout set up without using the method described in the article?

Hope someone still answers this as this articel is not the neweset ;)

Thx in advanced!