Blog Post

Microsoft Entra Blog
2 MIN READ

Azure AD Password Protection is now generally available!

Alex_Simons's avatar
Alex_Simons
Icon for Microsoft rankMicrosoft
Apr 02, 2019

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

Updated Jul 24, 2020
Version 8.0

56 Comments

  • Dave82's avatar
    Dave82
    Copper Contributor

    Why keep wasting time on tackling a symptom or the problem, when the actual problem is the existence of passwords in the first place...get rid of them. I should not have to remember any passwords. I want to go password-less.

     

    The amount of total time wasted by everyone writing down username/password site combinations in a password manager, excel file, or whatever is getting pretty ridiculous and the fact that we are still doing this and losing billions to this type of fraud in 2019 baffles me.

     

    MS/Google/Apple and the rest need to start an industry push to support FIDO U2F with hardware wallets (i.e. a Ledger or equivalent) and blockchain. I should be able to have something on my keyring and be able to login to any computer or website without ever needing to remember my password. I should be able to use a single token for ALL my logins. I'm pretty sure you can have fingerprint/PIN on top and just invalidate the token if it is ever lost or stolen (and keep the seed restore password somewhere safe like a safe).

     

    I think there's a Windows 10 login app that technically allows you to login password-less but it's only in beta. But we need all the large IT companies to support password-less FIDO U2F as an OPTION so at least it's there for the security conscious that want to use it. Banks are ironically the worst at this, most only send OTP via SMS...

  • Rohini Goyal's avatar
    Rohini Goyal
    Brass Contributor

    Hi Craig,

     

    This is something that has been brought to our attention a few times. Staff members tend to have access to more privileged information and should absolutely have strong account security, but it's harder for younger students to configure complex passwords. However, gaining access to a student account can be just as bad, which is why we don't recommend having separate policies for different user groups. That said, we would love to hear more about your scenario, and if you're looking to discuss this further, please reach out to aadppfeedback@microsoft.com. 

     

    If your staff members are admins on the tenant and you would like to add an extra level of security for them, I would recommend enabling Baseline Protection: Require MFA for Admins (more information https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/baseline-protection). This will require MFA for your tenant administrators (or staff members) alongside having a strong password with Password Protection. 

  • Craig Debbo's avatar
    Craig Debbo
    Brass Contributor

    Any suggestion for us. We're a school district. We have two distinct users. Staff and Students. Staff need strong passwords (and MFA). Students need simpler passwords without MFA. Any suggestions or possibility to have this feature offer differentiated support for our different user groups. Simplest would be to exclude students from Password Protection - but I can't. It's all or nothing. Next best might be to set a different 'score' for the user groups.

    thanks

  • Rohini Goyal's avatar
    Rohini Goyal
    Brass Contributor

    Hey Carlos,

     

    Great Questions!

     

    Let me start by saying - this feature is really all about preventing password guessing. Attacks like phishing, keystroke logging, and third party breach are really password independent, and database breaking (e.g. getting an offline copy of the data for brute forcing) is a completely different sort of threat. So focusing now on password guessing - most of this is done today via low-and-slow attacks across multiple customers and tens of thousands of accounts, but using only a few passwords (we typically detect and shut down the attack very quickly, and rate limiting and lockout technologies provide further friction to attackers).

     

    So: we are trying to keep your users from having passwords that can be guessed.

     

    1. [Can you change # of points required] We have looked at it, but our focus right now is ensuring that the algorithm we use defeats *all* guessing attacks as described above. We have been working with the red teams of some great preview customers to help us get this right. Rather than asking you to tweak the algo, we want to just do it right. If the current thresholds aren't doing the trick, we'd rather make it stronger for *everyone* (without adding friction just for "security theater"). We’ve updated the global banned password list and the banned password algorithm many times during the course of public preview. These changes will help expand the set of passwords being blocked. But if you are finding that there are patterns/guesses that the current algo isn't blocking, we would LOVE for you to reach out to us here or DM our GPM Alex Weinert on Twitter (@alex_t_weinert) , so that we can tune it further.

     

    1. [How does it work?] In a nutshell, what we are doing is analyzing our current attackers' patterns and maintaining a shorter (~2000 word) base banned word list. From there, we normalize for case and common substitutions (so "P@$$w0rD" becomes "password") and ban all of those permutations. Any matches here are collapsed for point value, so while you can use a string like password or 123 in a password, there has to be enough entropy around it to make it a valid password, e.g. "123asd*%spasswordV$" would be allowed. The algorithm is fully outlined https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad#global-banned-password-list. We don’t need to have every single weak password combination in the global list because the algorithm will take care of that for us. Additionally, blocking all passwords previously seen for any user is problematic – users will get frustrated coming up with a password no-one else has every thought of.

     

    Broadly, I think that excessively strict rules do harm, not good - you are forcing people to rely on cut and paste, killing usability, etc. What we really need is client device bound credentials which use PKI to transmit non-replayable, cryptographically strong nonces for login and break the back of all of these password vulnerabilities (FIDO2!) - in the meantime, we want to prevent password guessing without generating unnecessary user friction. Check out https://aka.ms/passwordguidance for the studies that back this.

     

    Thanks,

    Rohini

  • Richard Diver's avatar
    Richard Diver
    Copper Contributor

    This is a fantastic solution and will really help customers to enforce stronger passwords, until the day we can completely remove passwords ;)

     

  • Hi Alex_Simons, congrats on this going GA!

     

    Two questions: 

    1. Will we ever be able to play with the weak password cutoff and set a value higher than 5 points?

     

    I would really like to set something higher and align with the on-prem password length policy. I can't wait to turn off password complexity, but I don't feel comfortable doing that unless I can also make AAD Password Protection a bit stricter on password strength.

     

    I think the latest guidance (at least from NIST) is telling us to focus on length and ignore complexity, but the third leg of the stool NIST talks about is checking against a banned password list.

     

    2. Will we be able to get more color on the global banned password list?

     

    What it seems a lot of other people do is pull in the HIBP list (like on Github!), which we know has hundreds of millions of password hashes to check against. Clearly you're doing something quite different for the global banned password list, because instead of dropping 10GB of hashes on my SYSVOL share, I only see 100KB of data in the PasswordPolicies folder.

     

    It would be really helpful if we can get some color on what's happening under the hood. I understand you can't share any content of the lists, and clearly the normalizing technique dramatically reduces the data you need to look at vs password hashes which need to have every possible variation.

     

    But basically, can you tell us a bit more than this? (from https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad#global-banned-password-list)

    • Therefore the Azure AD Identity Protection team continually look for commonly used and compromised passwords. They then block those passwords that are deemed too common in what is called the global banned password list. 

     

    Thanks again! We have been waiting for this to go GA for a while...