Microsoft Enables Longer Azure Active Directory Passwords

Azure Active Directory Passwords Can Now Go to 256 Characters

Yesterday’s announcement by Microsoft that they had removed the 16-character limit for passwords in Azure Active Directory had been coming for a while. It takes time for Microsoft to deploy such a fundamental change across all the places in their cloud systems where passwords can be changed. The first leaks that something was happening came in late April when people noticed that the user interface in components like the Azure AD portal and Office 365 Admin Center offered administrators the chance to set 256-character passwords. This was discussed on Twitter, even if I didn’t believe the story at the time (Figure 1).

Twitter reveals 256-character AAD passwords on 24 April (image credit: Tony Redmond)
Figure 1: Twitter reveals 256-character AAD passwords on 24 April (image credit: Tony Redmond)

The new password limit is also mentioned in the Microsoft 365 User Management blog for April 2019 (posted on 7 May). You can’t say that Microsoft didn’t give us hints that this was coming.

Sweet Sixteen Was Too Short

Azure Active Directory 16 characters passwords go back to the early days of the Microsoft cloud. Recent feedback from customers emphasized the need for Microsoft to do better both by increasing the limit and allowing spaces to support pass phrases.

Using the New Limit

Now that Azure Active Directory supports 256-character passwords, should you force users to create longer passwords?

The obvious answer is no. At least, not yet. Changing passwords can be disruptive and a reasonable amount of preparation is needed to ensure that everyone from individual users to the help desk is prepared.

Expiring Passwords

Many Office 365 tenants, including mine, follow Microsoft’s recommendation to use non-expiring passwords (or rather “don’t require mandatory periodic password resets for user accounts”). This advice first surfaced in November 2017 and is based on the premise that you take other steps to protect accounts, such as making sure that multi-factor authentication is used (definitely for any sensitive account, preferably for all user accounts).

You can change the password policy for the tenant to force users to update passwords as they expire (Figure 2). However, if you’ve been using a non-expiring policy for the last year or so, it’s likely that switching policies will result in a flood of resets. As administrators and help desk staff are all too aware, password resets often cause users to seek help as they cope with new passwords across various devices and applications.

Changing the password policy for an Office 365 tenant
Figure 2: Changing the password policy for an Office 365 tenant (image credit: Tony Redmond)

A More Precise Approach

To avoid disruption, it’s best to take a more phased approach.

First, consider if your organization can use longer passwords (and take account of Microsoft’s password policies and restrictions for Azure Active Directory). Moving from a 16-character password to 20 characters might not improve your security profile much if you only rely on passwords. Longer passwords create more work for hackers to process, but eventually they’ll get there. Or passwords will be compromised elsewhere and combined with user email addresses (often the same as user principal names) in an attack. That’s why it’s good to check if email addresses are compromised in known dumps of user information.

Second, if you decide to go ahead and ask users to set longer passwords, make sure that you have some user education available to help people understand what to do and when they should do it. For instance, if you’re going to ask them to set 20-character passwords, explain why this is a good thing and when they will be asked to set a new password, such as the next time they connect to Office 365 (Figure 3). It’s also a good idea to explain the change password prompts displayed by common clients such as Outlook, Office browser clients, and Office mobile clients.

A user resets their password
Figure 3: A user resets their password (image credit: Tony Redmond)

Automating Password Resets

You can update user accounts individually to force a password reset, but some automation is preferable if you need to deal with hundreds of accounts. Forcing the entire organization to reset passwords at one time is not a great idea. It’s better to divide and conquer by processing selected groups of users.

This PowerShell code selects a group of mailboxes that do not have custom attribute 14 set to “N” and forces a password reset for their accounts.

$Mbx = (Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited -Filter {CustomAttribute14 -ne "N" } | Select DisplayName, ExternalDirectoryObjectId)
ForEach ($M in $Mbx) {
   Set-MsolUserPassword -ObjectId $M.ExternalDirectoryObjectId -ForceChangePasswordOnly $True -ForceChangePassword $True 
Write-Host "Password Reset created for" $M.DisplayName }

This code uses the older MSOL module. You can do the same thing with the newer Azure AD V2 module. I chose the older module because to code is more straightforward. Some scanning on the network will no doubt reveal other approaches to the task. The important thing is that only process a select group of accounts at one time.

Contemplating Long Passwords

My personal account is pretty well protected already so I haven’t yet decided if I will extend myself to a longer password. I like the idea of using spaces in passwords because I think a phrase is often easier to remember, so that’s probably my next step. In the interim, I’ll think about why the outer limit is 256 characters and if someone out there really wants to set such a long password. And how often they input an incorrect password when they try to connect…