Home
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
31 Comments
Super 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.

Occasional Visitor

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

Frequent Visitor

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.  

 

 

Frequent Visitor

 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.

Senior Member

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.

Senior Member

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?

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

        

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. 

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

 

 

 

Senior Member

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

Super 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? 

 

 

 

New Contributor

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

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

New Contributor

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

 

 

 

 

New Contributor

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.

 

 

 

 

Established Member

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

Frequent Visitor

Hi @Jay Simmons ,

 

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. 

Frequent Visitor

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