Azure AD Password Protection and Smart Lockout are now in Public Preview!
Published Sep 07 2018 04:15 PM 162K Views
First published on CloudBlogs on Jun, 19 2018
Howdy folks,

Many of you know that unfortunately, all it takes is one weak password for a hacker to get access to your corporate resources. Hackers can often guess passwords because regular users are pretty predictable. Regular users create easy to remember passwords, and they reuse the same passwords or closely related ones over and over again. Hackers use brute force techniques like password spray attacks to discover and compromise accounts with common passwords, an attack pattern we told you about back in March .

So today I'm really excited to announce the public preview of Azure AD Password Protection and Smart Lockout. Azure AD Password Protection helps you eliminate easily guessed passwords from your environment, which can dramatically lower the risk of being compromised by a password spray attack. Specifically, these features let you:

  1. Protect accounts in Azure AD and Windows Server Active Directory by preventing users from using passwords from a list of more than 500 of the most commonly used passwords, plus over 1 million character substitution variations of those passwords.
  2. Manage Azure AD Password Protection for Azure AD and on-premises Windows Server Active Directory from a unified admin experience in the Azure Active Directory portal.
  3. Customize your Azure AD smart lockout settings and specify a list of additional company specific passwords to block.

Why you need Azure AD Password Protection

Banned passwords

Most users think if they have chosen a password that meets a complexity requirement, something like P@$$w0rd1!, they're safe, which is exactly wrong. Attackers know how users create passwords, and there are three general rules to be aware of.
  • They know to account for character substitutions like "$" for "s". "P@$$w0rd" isn't fooling anyone.
  • They also that if there are complexity rules, most people will apply them in the same way: by starting a word with a capital letter and ending the password with a digit or punctuation. (Because of this we've been recommending doing away with complexity rules , and the latest NIST recommendations agree .)
  • They know that requiring users to change their passwords periodically leads to other predictable patterns. For instance, if users have to change their password every quarter, they frequently pick passwords based on sports teams, months or seasons and combine them with the current year.
The fix to all of this is to apply a banned password system when users change their passwords, like Azure AD Password Protection. This is both the NIST recommendation and what we do in the cloud for Microsoft accounts and Azure AD accounts. Today's public preview gives you both the ability to do this in the cloud and on-premises—wherever your users change their passwords—and unprecedented configurability. All this functionality is powered by Azure AD, which regularly updates the databased of banned passwords by learning from billions of authentications and analysis of leaked credentials across the web. By checking all the password set or reset operations for your organization, password protection ensures that only passwords meeting your, and our, standards exist in your directory. Azure AD Password Protection also provides an integrated admin experience to control checks for passwords in your organization, in Azure and on-premises. Please note: Azure AD Premium Password Protection is an Azure AD Premium 1 feature.

Smart Lockout

Smart lockout is our lockout system that uses cloud intelligence to lock out bad actors who are trying to guess your users' passwords. That intelligence can recognize sign-ins coming from valid users and treats those differently than ones that attackers and other unknown sources. This means smart lockout can lock out the attackers while letting your users continue to access their accounts and be productive. Smart lockout is always on for all Azure AD customers with default settings that offer the right mix of security and usability, but you can also customize those settings with the right values for your environment. With banned passwords and smart lockout together, Azure AD password protection ensures your users have hard to guess passwords and bad guys don't get enough guesses to break in. Please note: Azure AD Smart Lockout is included in all versions of Azure AD (including those versions in Office365).

Get started in three simple steps

By default, all Azure AD password set and reset operations for Azure AD Premium users are configured to use Azure AD password protection. To configure a custom list of banned password strings for your organization and to configure Azure AD password protection for Windows Server Active Directory, follow the below simple steps:

Configure the password protection for your tenant

Go to Azure AD Active Directory > Security > Authentication Methods.

Customize your settings

  1. Set your custom 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
  3. Extend banned password protection to Windows Server Active Directory by enabling password protection in Active Directory. Start with the audit mode, which gives you the opportunity to evaluate the current state in your organization. Once an action plan is finalized, flip the mode to Enforced to start protecting users by preventing any weak passwords being used.

Install the Azure AD password protection proxy and domain controller agents in your on-premises environment.

Download the agents from the download center and use the instructions in the password protection deployment guide . Both the domain controller agent and the proxy agent support silent installation which can be leveraged using various deployment mechanisms like SCCM.

That's it! You're now configured to use Azure AD password protection across Azure AD and on-premises. Take a read through our detailed documentation to learn more about this functionality. As always, we're eager to hear from you! Still have more questions for us? Email aadppfeedback@microsoft.com or join us at the Ask Me Anything Session for Azure AD password protection. We look forward to hearing your feedback! Best regards, Alex Simons (Twitter: @Alex_A_Simons ) Director of Program Management Microsoft Identity Division
37 Comments
Steel Contributor

@Alex Simons (AZURE) Any idea when this is going to come out of preview? We want to roll out after testing in the lab since June but have policies against installing preview software in a prod environment.

We're still working on the final plan, but probably won't be GA until Q1 CY19.

Copper Contributor

Are there any reporting ability tied to this yet? Would like to see trends and problem accounts for remediation.

Copper Contributor

Here is what I have found. If your on-premises GPO dictates 8 minimum characters, then the words in banned passowrd list but span at least 5 character os the password in order for it to show as bad. e.g. say you add the word "frogs". If you enter 123frogs it will be rejected. But if you enter 1234frogs, it will be accepted because the banned word only covers the last four required characters.  Also, it states the words must be at least 4 characters. So if we add "frog", this word will never be rejected because it will only ever span half the required password length. 

 

More curious results. I added a 7 character word in the custom list "papanui". I was not able to use papanui1, papanui12, papanui123, but I was able to use papanui1234.  

 

 

Copper Contributor

 Another problem has surfaced. I am investigating the environment, but this seems to interfer with account lockouts. We have the default password policy set to 10 attempts. We notice that once we get to 6 attempts, there is a delay of 30 seconds before allowing us further logon attempts. This appears to reset the count and therefore the threshold of 10 attampts is never reached. I set the Smart lockout threshold in Azure to 12. 

 

More to this, no matter what thresholds are set in Smart Lockout or on-premises Default Domain Policy, on-prem user accounts will never get locked out once agents are installed on domain controllers. We disabled all agents and now the Default Domain Policy takes effect again.

Copper Contributor

Hi Alex,

 

This is a great feature. Some queries though;

1. If we only have one account with an Azure AD prem licence does activating 'Enforce custom list' only apply to that one particular user

 

"updates the databased of banned passwords by learning from billions of authentications and analysis of leaked credentials across the web. By checking all the password set or reset operations for your organization, password protection ensures that only passwords meeting your, and our, standards exist in your directory. " 

 

2. How exactly do we connect with this 'databased of banned passwords' does it happen automatically the moment we enable 'Enforce custom list'?

 

Many thanks,

Microsoft

Lonnard:   on your password examples, be aware that the current algorithm does take into account complexity that is present even once a banned token is detected.    In your example, "frogs" was detected but "1234" gave it enough extra complexity to allow it to be accepted.   The algorithm tries to strike a balance between security and usability in this regard.  The algorithm is tuned fairly often so nothing should be regarded as set in stone.

 

On your lockout issues, I am not aware of any potential interaction between onpremises Azure AD Password Protection DC agents and the Default Domain policy - from AD's perspective, AADPP is just another installed password filter dll.   Would you please contact me offline so I can get a few more details from you on this?

 

 

Microsoft

Hi Callum - on your first question, the current licensing requirement is that all users being synchronized to Azure AD must have a premium license.   The onpremises security benefits of AADPP are still applied though for all other onpremises users that are not being synchronized.

 

On your second question, changes to either the global or per-tenant banned password lists are not immediately pushed down to the onpremises agents (ie, the DC agents running on your DCs).   Instead, the current design uses a polling model where (usually) one DC per domain will poll Azure for the latest policy (banned password lists) once per hour.   This frequency is just a reasonable balance since usually neither list (global or per-tenant) is being changed anywhere near that often.

 

Please feel free to contact me offline if you have further questions.

Copper Contributor

We have implemented the Azure AD Password Protection, and it has completely broken our ability to do self-service password reset with password hash sync and writeback to AD through Azure AD connect. For the passwordreset.microsoftonline.com site or the "Forgot my password" link - no matter how complex or long of a password our users use, it always complains about not enough complexity. This is affecting every user. What could we be missing?

Microsoft

Corey - We would love to help you resolve this issue. Can you please email aadppfeedback@microsoft.com  with the above problem and we can setup a call to help identify where the problem is. Do you have banned passwords deployed on your DCs as well?

Iron Contributor

Is this feature enabled by default of Office 365 cloud tenants? I've just had a user report they've got the error "Choose a password that’s harder for people to guess". I've not enabled this feature myself and they don't current use self-service password resets. We did enable it once but that caused everyone to get the prompt about additional authentication methods which we weren't ready for so turned it off again.

 

Later...

 

Actually we do have self-service password reset enabled but only for three test users. Does the code take this into account when checking the password like:

 

IF (self-service password enabled) AND (all users OR user is in the group) THEN check for common word

        

Copper Contributor

Interesting feature at all.

 

1) Might I ask whether there is a difference between 'AD Password Protection' and 'AD Premium Password Protection'? Most of the time you refer to 'Password Protection', but then it says 'Please note: Azure AD Premium Password Protection is an Azure AD Premium 1 feature.'

 

2) Regarding the 'Smart Lockout' you say 'is always on for all Azure AD customers with default settings' - does this mean it is on right now or starting with GA? And is it on only for customers with premium license, or really all?

 

3) We are interested in a more restricted lockout (10 minutes instead of around 1). If this is the only thing we want to configure, do we need to have a premium license for all of our AD users or is this included in B2C basically?

 

Thank you.

Microsoft

Hi Christopher, 

 

1) We apologize for the confusion. Password Protection for cloud authentications requires any paid license. If you would like to have banned password support on your on-premise active directory, you need a premium license. 

 

2) Great question. It is in fact on for everyone already, regardless of license and GA. All users are under the default setting of 10 failed sign-in attempts -> 60 second lockout period, unless a tenant admin has configured the settings themselves. 

 

3) Configuring lockout only requires any paid license. A premium license is not necessary - an AAD basic license will do. 

 

Please let me know if you have any other questions. 

Copper Contributor

Hi Rohini,

 

great news! Thanks for clarifying this.

 

Is there a specific right neccessary for changing the lockout duration? Because our collegue, who is responsible for the B2C settings, is not able to change settings regarding the 'Password protection' topic. You mentioned the 'tenant admin' - he is 'global admin' - I can not see a difference from https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-ro...

 

Sorry, to bother you once more.

Thanks, Christopher

 

Update: Screenshot slightly modified... 02-18-2019

 

 

Azure Auth.jpg

 

 

 

Copper Contributor

Quick question. If I enable the custom list is it going to disable the default list that you are providing?

Steel Contributor

Please go GA. has testing not completed? I cant put non GA services into our Prod environment...

Microsoft

Amy, the answer is no.  If you enable the custom list it augments the Microsoft-maintained global list.

Microsoft

Robert, trust me we're working on it.  Should be go GA this quarter (before end of March).   Thank you for the interest though - really appreciate hearing that.

Microsoft

Christopher, 

You're right, by tenant admin I meant global admin, so the blade should be visible to him. What license are you using? You mentioned B2C. Is your global admin trying to change the settings for the end consumer? 

 

 

 

Deleted
Not applicable

Hi,

 

I think I know the answer to this already. Is there the functionality to allow for multiple policies to be applied to different user accounts? I am looking to propose password never expires for non privileged accounts and enforce "secure" passwords, preferably passphrases to be used. I know tools like Thycotic, Manage Engine etc, have varying policies available.

 

If I were to use MS ADPP, would I still be reliant on FGPP for unique policies for PRIV accounts?

 

JD

Copper Contributor

Rohini,

 

we are part of a MS EA agreement and though use a basic license with AD.

 

The intention is to change settings for customers that sign up with 'our' B2C AD...

 

Kind regards,

Christopher

Microsoft

Hi JD808717,

 

Sorry but we do not support scoping the Azure AD Password Protection policy to a subset of users, whether we are talking about users at the Azure level or (when deployed and enabled) in the on-premises Active Directory environment.  

 

With respect to Active Directory FGPP, it's the same basic answer:   AADPP will always be in effect regardless of whether a FGPP policy is in effect for a given user account or not.  

 

If you see this answer and have time to reply, I wouldn't mind hearing the reasons that you think downgrading password security levels for some of your users is a good idea (honest question :)).  

 

thx,

Jay

Deleted
Not applicable

Hi Jay,

 

We are going to enable password never expires, but I do not want the password never expires policy to be applied to our Domain Admins \ Enterprise Admins etc.

 

So having differing policies that can be applied to a subset of users would be of benefit.

 

JD

Microsoft

Hi JD,

 

This probably won't be a surprise to you, but setting password-never-expires is not a recommended security best practice.  If you deploy Azure AD Password Protection in your AD forest, it's probably ok to increase MaxPasswordAge by some factor - but not password-never-expires.

 

Going back to your main question:

 

>>So having differing policies that can be applied to a subset of users would be of benefit.

 

Setting password-never-expires seems orthogonal to deploying Azure AD Password Protection.  Regardless of whether or not a password will expire or not, it is still a good idea to try to make sure that that password is not easily guessable.

 

If the concern here is that those users who do NOT have password-never-expires may be "upset" by being forced to select stronger passwords, well I would say that for most customers this is considered a relatively minor cost that is easily accepted given the larger security benefits.  If those users are highly privileged such as Domain\Enterprise Admins, then this is even more true.

 

Jay

 

 

 

 

Deleted
Not applicable

Hi Jay,

 

Thanks for getting back to me promptly!

 

NIST and even MS, recommend that you do not change your password frequently, simply due to the fact that people will increment their password or only change it subtly.

 

I wouldn't want to enable password never expires without additional tools and advice to prevent users from entering weak \ leaked passwords and have differing policies applied to priv accounts.

 

 

 

 

Copper Contributor

Alex we are deploying this and we ran into a question. While auditing the last 4 days of events we see a not insignificant amount of PasswordChangeAuditOnlyFailures as well less PasswordSetAuditOnlyFailures. My question is what is the difference between a Change and a Set and can that be added to the documentation somewhere?

Microsoft

Hi Eric,

 

A password change is what happens when a user changes their password, eg they use their current password to log into Windows, but are then prompted to choose a new password.

 

A password set (or reset) is what happens when someone (usually a higher-privileged account, eg a Domain Admin) decides to arbitrarily replace the password on an account with a new password, ie using Powershell or the Active Directory Users and Computers mgmt snapin.  Usually the person doing this does not have knowledge of the old password.  You will also see "password set" events when a brand new user account is being created for the first time. 

 

I hope this clarifies the difference, let me know if it does not.  And I will add these descriptions to the docs, probably from the Azure AD Password Protection faq topic:

 

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-pre...

 

thanks!

 

Jay

Brass Contributor

Hi @JaySimmons ,

 

Can I just confirm something? Half our organisation is currently licensed for Azure AD P1, but the others are only O365 E3. If I implement AADPP for on premise, will the policies successfully apply across all users without issue? Would the current licensing have any impact on being able to use the feature?

We are looking to go full Azure AD P1 in the near future, but just happen to need to AADPP features before that order goes in.

Thanks for any help.

Regards,
Chris Vella

Microsoft

Hi Chris, that's a good question and I honestly don't know the answer.  I've forwarded the question to some other folks here at Microsoft, hopefully we will have an answer posted soon.

Microsoft

Hi Chris,

 

Great question. Having an O365 E3 license grants you Azure AD P1 privileges. So for your users that have the E3 license, they're effectively P1 users in AAD. Sounds like all your users have either an E3 or P1 license, and if that's the case, you're good to go 🙂 Your current licensing satisfies the requirements to use Smart Lockout, Banned Passwords, and the Active Directory features. 

Brass Contributor

Hi @Rohini Goyal ,

Thanks for your response. Can I please clarify a little further? You mentioned that O365 E3 grants Azure AD P1 privileges. This seems strange, as O365 E3 does not give us an AAD P1 license. M365 E3 and EMS E3 would, but not O365 E3. Are the P1 privileges mentioned different to an actual license in this case, i.e. the O365 E3 does not give an actual license but is suitably high enough to enable access to AAD P1 features even without being actually licensed for it?

Thank you again for helping me with this. Cheers.

Regards,
Chris Vella

Brass Contributor

Hi @Rohini Goyal ,

Any chance of getting a response to the above? Otherwise, is there someone that I may be able to make contact with to clarify specifically? Thanks. 


Regards,
Chris Vella

Edit: Now that the products are GA the licensing has been clarified to require an Azure AD P1 or greater.

Brass Contributor
I'm not sure of the position of AAD SmartLockout vs ADFS Extranet Smart Lockout ? Could someone details the benefits vs ESL ? thanks
Copper Contributor

We're getting ready to go live with Azure AD Password Protection.  I have some questions related to rollout strategy.  It seems as if this feature is either on or off, there's not really a great way for a phased deployment (other than installing on just a subset of Domain Controllers).  But that isn't a great option since you can't control which DC a user gets directed to for a password change.

Our on-premise Group Policy for password complexity is as follows:

  • Cannot contain name and/or username
  • 8 character minimum
  • Must use 3 of the following 4 requirements
    • Uppercase letters
    • Lowercase letters
    • Base 10 digit
    • Special character
  • Password age limit = 105 days (at which point they must change their password)

We would like to change our policy as follows (everything not listed below will remain the same as what's listed above):

  • 10 character minimum
  • Must use 4 of 4 requirements (upper, lower, base 10, special char)
  • Password age limit = 0 (passwords no longer expire, per recommendation from Microsoft)

 

We currently have AADPP enabled in Audit Only mode.  Once we flip the switch to Enforce, what can we expect?  Will users with weak and/or banned passwords be prompted to change their password immediately?  Since we are changing from "Passwords expire every 105 days" to "Passwords never expire", how can we effectively roll this feature out to the masses, and get them to set a stronger password?

We need this to have a little disruption as possible because, as we all know, updating your password can be a disruptive event; especially for a mobile workforce.

 

The documentation doesn't really have much guidance on what to expect once you go live, and doesn't give any recommendations on how to enable the feature while switching the on-premise group policy to no longer expire passwords.  Do you have any guidance or suggestions to help with this?

Microsoft

Hi @Junior049 ,

 

As you describe, it's a bit painful to produce a deterministic phased outcome when it comes to rolling a password change across your entire user base. Flipping the switch from Audit to Enforce has no effect on the expiration time of the existing passwords in your directory. Azure AD Password Protection does not attempt to influence or control password expiration times.   So the only time the new Enforce mode actually has any impact or effect is when a user changes their password.   

 

I’d suggest taking a look at the expiration time distribution of the currently stored passwords of your users. While there may be some clustering on certain days of the week (eg, Mondays) I would expect a fairly even distribution of expected pwd expirations across your current 105 day expiration window. With that in mind, one approach would be to flip to Enforce but leave your 105 days max-pwd-age policy as-is.   You would then simply wait out the subsequent 105 days as the users change their passwords day-by-day and week-by-week. There will likely be some non-zero extra support costs during this time as users find that their favorite weak passwords are now getting rejected.   (At least the support costs are spread out across time though.)   At the end of that 105 days – ie, after all your users have gone through at least one password change with Enforce enabled – you can then change max-pwd-age to the new desired (longer) period. 

 

If waiting 105 days is too long, then you can drive things faster with a bit more work: first flip to Enforce mode, then manually set the “User must change password at next logon” flag on a selected set of accounts every day or every week.   This approach will still incur some level of expected increased support costs of course.

 

I’m not sure how the “mobile” aspect of your user base affects this discussion – it sounds like you’ve already trained your users to change their passwords every 105 days, so if you choose to force them to change early that should not be a never-before-seen event, even for mobile users.   Please clarify if I’ve misunderstood some part of the mobile aspect.

 

The other thing we’ve recommended is some level of pre-education of users before you flip to Enforce mode.   I’ll admit I don’t have any data that would say how effective such education might be, but a broad company-wide “heads-up about upcoming stricter password enforcement” email might help to reduce support costs (and I don't see how it could hurt).   We have some previously published guidance here:   Microsoft Password Guidance

 

Anyway, these are just some approaches I came up with off the top of my head.   I know AADPP doesn’t do anything specifically to assist in the rollout, but on the other hand you can already control most of the rollout timing using existing Active Directory tooling. 

 

I hope this helps,

Jay

Copper Contributor

Thanks Jay, this is helpful! 

 

Regarding the challenges with mobile users, I was just referring to how disruptive a password change event can be.  It's bad enough when a user is on-prem; change password, true-up your MFA with all the O365 resources, update password on all your mobile devices, true-up MFA on those, etc.  If a user is remote they have to follow very specific steps in the proper sequence when updating their password, in order to ensure their computer receives the updated credential and updates their offline profile accordingly. 

 

Updating your password has just becoming increasingly difficult for non-technical employees now that their data and resources they access is mixed between on-prem and the cloud, many of them have multiple mobile devices, then throw in MFA, SSO and maybe a VPN and they tend to get confused.  Smiley LOL

 

Thanks again for the guidance!  These a good suggestions which will help with our upcoming enforcement of Azure AD Password Protection!

Copper Contributor

Same question as @Chris_Vella  , we have a mixture of licenses in our tenant. Majority are Office 365 E3 users and a subset of users have an EMS E3 license. Can a single EMS E3 license satisfy the requirements for ALL USERS to use Azure AD password protection for a hybrid environment? 

Version history
Last update:
‎Jul 24 2020 01:56 AM
Updated by: