Azure Gets Longer Passwords

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

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.

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


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

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.

Leave a Reply