Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
Azure AD Password Protection is now generally available!
Published Apr 02 2019 09:00 AM 187K Views

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:

 

Azure AD Password protection 1.jpg

 

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

56 Comments
Brass Contributor

Hi @Alex Simons (AZURE), 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#glob...)

  • 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...

Copper Contributor

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

 

Microsoft

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 here. 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

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

Microsoft

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 here). This will require MFA for your tenant administrators (or staff members) alongside having a strong password with Password Protection. 

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...

Brass Contributor

Hi Alex

 

It stated that "Preview customers MUST update the agents to the latest version (1.2.116.0 or higher) immediately."

 

According to the installation guide, then the domain controllers must be rebooted when the agent is installed. But will the GA build autodetect the old client and update it or do we need to uninstall, reboot, install and reboot before we are able to use the GA version?

Copper Contributor

Thumbs UP!  It's a good start. 

Microsoft

Hi @bjarneabraham,

 

The DC agent installer has supported in-place upgrade for quite awhile.   If you already have an earlier version installed, just run the GA DC agent installer over the top of the older one - it will still require one reboot, but not two.

 

Jay

 
Microsoft

Hi @CyberEagle,

 

The custom banned password list supports 1000 tokens.  Please see this link in the docs.  

 

Note that you may want to also review the algorithm details which are documented on this page.   If overall size of the list is a concern, you don't want to waste entries in your custom banned password list by adding tokens which are highly duplicative or overlapping.   Understanding the algorithm details makes it possible to better leverage the custom banned password list .

 

hth,

Jay

 

Brass Contributor

Hi @Rohini Goyal ,

 

Thanks for your reply! I also am no fan of security theater...I'd put frequent password expiration (anything <120 days) highest on that list. However, we also have to make regulators and auditors happy, and I was hoping to kill two birds with one stone here.

 

I understand the primary purpose of this tool is block password spray attacks, but I would urge you to consider letting us play with the required points score. This is because many of us are interested in applying the latest NIST guidance to drop complexity requirements and periodic expiration, provided we can also tweak the length requirements and block against a banned password list.

 

This solution is getting us soooo very close to that point, I think giving us the ability to tweak the score would just make this product so much more valuable. And to be clear, I'm not looking to plug anything ridiculous like 20, just bumping it up to 7 or 8 would make it perfect.

 

Fingers crossed!

 

Carlos

Copper Contributor

@Jay Simmons Thanks for the reply, I just noticed that in the document and changed my comment, but you were quicker lol.  

Copper Contributor
Hey Alex. Is the word list you're using international, or is this currently configured for American English common passwords?
Microsoft

Hey @CDubbs 

 

The list does contain a few international words but majority the list is English common passwords and character patterns. The primary goal of the global banned password list is to protect all users from the most common passwords bad actors use during attacks.

 

Microsoft

Hey @CDubbs 

 

The list does contain a few international words but majority the list is English common passwords and character patterns. The primary goal of the global banned password list is to protect all users from the most common passwords bad actors use during attacks.

 

Iron Contributor

Alex (why can't I at mention your user name?) - The Docs page says that licensing is Azure AD P1 or P2 to use the custom banned list. I see the settings page in my Office 365 E3 and Office 365 E5 tenants (two separate ones), and I can enter words in the list and save the list, although my two tenants don't have P1 or P2. There's no warning that the words won't be enforced because of the lack of P1 and P2. Is this expected behaviour?

Iron Contributor

Alex - given the list of custom banned passwords is really a list of custom banned words that can't be used in a password (subject to the complexity rule), why is the section and field called what it is? "Custom banned words" and "Custom banned word list" would more accurately reflect the reality, IMO.

Copper Contributor
MFA was not supported when this feature was in public preview. How will MFA support change as this feature is made publicly available?
Microsoft

Hi @HideyukiSekiya,

 

MFA support (for the Register-Proxy and Register-Forest) cmdlets was not available in the initial public preview release on 6/15/2018.    MFA support was added in the first public preview update (version 1.2.10.0) on 8/17/2018 - see the release description here - and has been supported ever since.

 

I will also point out something that has changed from the earlier public preview days: the Register-Proxy and Register-Forest cmdlets each now support three different authentication “modes”: interactive (authentication dialog pops up), device code (for UI-less platforms like Windows Server Core), and silent (password-based). The first two will work fine with MFA-required accounts, the last one does not (but the last one is mainly intended for testing purposes anyway). 

 

hth,

Jay

Copper Contributor

Hi Alex, banned password is a great feature. To the question of @CDubbs: along with the recommendations of the password guidance it would make sense that common tokens are localized. 

Microsoft

Hi @Michael Sampson 

 

Using Azure AD Password Protection does require having an Azure AD P1 or P2 license. Although Azure portal may allow you to access and configure the page without having a premium license, you will technically be out of license compliance. 

 

Copper Contributor

@Jay Simmons In the password protection portal it is no where mentioned that a Microsoft global ban list is included. Is this in use by default, even without enabling the custom ban list?

 

Thanks,

 

Steven

Iron Contributor

Thanks @Rohini Goyal. That's an "interesting" design choice on Microsoft's side to allow a customer to use capability they are not licensed for (and to give no UI prompts / warnings), and then to use the "technically out of license compliance" line. Why this choice, as opposed to trimming functionality to what the customer has licensed for? This is probably a MUCH larger discussion than just AD Password Protection though.

Microsoft

@Steven Bink that is correct.  The global banned list is always in effect for all supported scenarios.

Iron Contributor

@Steven Bink Yes, the global list is used by default for all customers, without a given org having to do anything to the custom list. It is mentioned in Microsoft Docs.

Microsoft

@Michael Sampson  We can definitely do a better job addressing our licensing requirements in product rather than simply relying on documentation. Thanks for the feedback!

Iron Contributor

Nice. I like that answer @Rohini Goyal. Thank you. I look forward to seeing how you do so.

Copper Contributor

Any idea what are these Forest Entropy objects in our config partition? These objects were not there after initial deployment. They showed up after we installed DC Agents to large number of domain controllers. Anybody else seeing this?

 

Capture.PNG

Copper Contributor

@Jay Simmons Can current passwords be assessed? Microsoft now suggest to not expire passwords, so would be nice if these passwords can be checked with current banned lists.

 

Thanks,

 

 

Steven

Microsoft

Hi Steven,

 

Passwords are only assessed when a user changes or resets their password. Current passwords aren't assessed as of today, but we're looking into expanding Password Protection so that current passwords are checked as well. 

 

Copper Contributor

I am unable to make any changes to Password Protection Settings - they are greyed out. I'm logged in as a Global Admin. We are a non-profit using Azure to Sync Office 365 with AD.

 

Any Ideas? 

Microsoft

Hi @Brajesh Panda ,

 

The presence of multiple Forest Entropy objects looks like a minor but fairly benign bug - thanks for reporting this.  These objects are used to contain a random piece of entropy that is used by all of the DC agents across the forest.  If you installed multiple DC agents around the same time, the possibility does exist that multiple of these would get created;  the bug is that we don't auto-delete the extra ones.  For now, please feel free to manually delete all but one of them.

 

thx,

Jay

Brass Contributor
Hi, is there any reason to go for the Windows Server Active Directory integration if Password Hash Syncronisation and Password Writeback is enabled and users are mainly changing their password in Azure? When changing the password in Azure, both the on-premise password policy (thanks to Password Writeback) and the Password Protection algorithm will be used, am I right? Sebastian
Microsoft

@meilrich What license do you have for your tenant? Using Password Protection requires having a paid AAD or any equivalent license that grants you Azure AD P1. 

Copper Contributor

@Rohini Goyal we're using Azure AD Connect to sync with our office 365 account. We have non-profit subscriptions, so my guess is this not available to us. Too bad!

Iron Contributor

@meilrich If Azure AD Connect is pushing a password from Windows Server AD to Azure AD, then my sense would be the fundamental problem is not licensing (that's probably an issue too), but rather Azure AD never assesses the password because that is set in Windows Server AD and then pushed / one-way synced to Azure AD. With the right licensing AND the installation of agents on Windows Server AD, the list of words in the banned passwords list can be checked first by Windows Server AD, and then synced up to Azure AD.

 

I look forward to hearing the authoritative answer from @Rohini Goyal though.

Copper Contributor

Hi,

I have an issue with Azure Password Protection. In fact, the proxy service is showing the event 10005. "System.Net.WebException: Cannot connect to the remote server ----> System.Net.Sockets.SocketException: No connection established with the target computer ..... 20.190.129.2:443

System.Net.Socket.Socket.EndConnect(IAsyncResult asyncResult)

 

In Sysvol the Azure Password Protection folders still Empty !

 

Please Help

Microsoft

Hi @MaherRiahi,

 

If you are running the AADPP proxy server behind a firewall, please make sure the appropriate ports and names are opened up.  Also, please make sure TLS 1.2 is supported between the AADPP proxy server and the outside network - that is another cause of this issue.

 

Jay

Copper Contributor

It is great to see Microsoft finally implement a password filter for AD.  I have enabled the feature in a test tenant and a test On Prem Domain Controller, it was fairly straightforward to do as the documentation is comprehensive and easy to follow.

It would be good to see the feature extended to include the ability to define the character set that constitutes Complex Passwords.  I've seen that requested a number of times over the years and indeed implemented 3rd party products to allow that.

Great work! (although I do also agree with the contributor saying that we should be moving away from passwords now, but that will still take more time...) 

Microsoft

Hi @Alastair Cain ,

 

Thanks for the feedback. We'll take this into account for future updates to Password Protection. We're glad you're using Password Protection and found that the documentation was easy follow. That said, if you have any suggestions or pointers we should add to the documentation to make it easier to deploy, let us know! We're always looking for ways to improve :) 

 

Thanks!

Copper Contributor

Hi,

one question relating to the normalization applied during the password normalization and its documentation at [1]:

 

The documentation mentions that "1" will be substituted with "l" (lower case L, step 1). In the consecutive steps, the digit 1 is not substituted by a lower case L and in the case of the password "C0ntos0Blank12", normalized to "contosoblank12" is counted towards the score of a password. Should this not be normalized to "CONTOSOBLANKL2" (just for illustration in uppercase)? While this example is still rejected, other password examples might lead to different outcomes if the 1/L makes a difference between a score of 4 or 5...

 

I also cross-posted this on the documentation feedback / issue tracker [2]

 

 

 

 

[1] https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad#how-...

[2] https://github.com/MicrosoftDocs/azure-docs/issues/30326

Brass Contributor

Great!

I was using it but I didn't Know that I would need to install an agent. Now I know why I was stucked and thing that wasn't working properly.

 

 

Brass Contributor

NIST 800-53, Control IA-5 (1)(b) states we need to enforce a minimum number of character changes when passwords are created. This can be done on-prem with password filters, but how would we comply with this requirement in Azure?

Copper Contributor

Hi,

 

Another question:

Is there a possibility to have a custom message for end users when they try use a password from the banned list, informing them of the reason why their password is not accepted?

 

Microsoft

Hi @TomWillems ,

 

Currently, there is no ability to customize the error message for password strength. The custom and global list need to be kept secret to ensure it's not exposed to bad actors. We don't recommend having a custom message to the user that indicates their password is not strong enough due to a specific word/phrase they are using. That inherently exposes the banned lists. 

Copper Contributor

Thx for the feedback @Rohini Goyal

 

I understand the need to keep the banned password list secret, but I do not see how having a custom error message has any impact on this. If a malicious actor is capable of executing password changes, he would be able to determine the banned password list through trial and error whether there is a custom error message or not.

 

Even though we communicate our password policy to our end user population through a separate channel, it would be very helpful to offer some guidance at the time they are changing their password.

Microsoft

Hi 

    I have two question? Many thanks if you have any idea.

   1)  Does the Azure Password Protection take effect to the on-prem AD users who haven't sync to AAD? 

   2) Is it possible to make exclusion on some users? 

Microsoft

Hi @Harry_Li ,

 

Onpremises AADPP currently validates passwords for all password change requests that it receives, and yes this does include non-sync'd users.  

 

We do not currently support any way to exclude users from protection.  This is a capability that a few customers have asked for but it's not on the roadmap yet.

 

Thanks,

Jay

Brass Contributor
@Alex Simons (AZURE) Quick question about the Register-AzureADPasswordProtectionForest command that is run to register a forest. Since Enterprise Admin credentials are needed during Forest registration, I’m curious what AD attribute is set in On-premise AD to validate if this runs correctly?
Microsoft

Hi @ChadWst ,

 

Successful invocations of the Register-AzureADPasswordProtectionForest cmdlet cause a new serviceConnectionPointObject to be created in a dedicated (new) container in the AD configuration NC.  For example:

 

CN=Forest Certs,CN=Azure AD Password Protection,CN=Services,CN=Configuration,DC=bpl,DC=com

 

The new SCP contains an encrypted certificate and other information that is then used by the DC agents across the forest to encrypt and sign traffic sent to Azure.  I should caveat though, these are implementation-level details and subject to change.  

 

Does this help?

 

thanks,

Jay

 

 

 

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