One of the benefits of using Azure Active Directory (Azure AD) is the flexibility it gives you when it comes to managing passwords. Most companies choose to deploy Azure AD as an extension to their existing on-premises Active Directory. They do so to add single sign on and federation capabilities for online apps like Salesforce and Docusign. Azure AD also allows users to manage or reset passwords on a self-service basis without contacting the help desk.
What are the basics of Azure password policy, and how do you get this all set up? That’s what I’ll tackle in this piece.
Basic Password Policy Restrictions
The most basic of password policies for Microsoft Azure AD include simple complexity and history limitations. You can use simple alphabetical characters (A to Z), including both upper- and lowercase letters; the numerals 0 through 9; and standard keyboard symbols (@ # $ % ^ & * – _ ! + = [ ] { } | : ‘ , . ? / ` ~ “ ( ) ;). You are not allowed to use Unicode characters or spaces in your password. The password length is set to 8 characters minimum and 16 characters maximum. To be considered strong, the password must not have a dot (.) immediately preceding the at sign (@) and also contain any three (1) lowercase characters, (2) uppercase characters, (3) numbers, and (4) allowed symbols. By default, passwords expire every 90 days, and users are notified to change their password 14 days before that expiration. From a password history point of view, the system restricts the last password that was used—so a user has to come up with a new password rather than just cycling the same one over and over again. The expiration duration and notification can be configured through PowerShell using the Set-MsolPasswordPolicy cmdlet, which you can find within the Azure AD Module.
If users enter their password incorrectly 10 times in a row, Azure AD will lock the account for one minute. If incorrect password entries continue, the system again will lock the user out and then increase the duration of each lockout period as a method of deflecting and mitigating brute force attacks.
Integration with Azure Password Management Features
One of the biggest advantages of using Azure AD is the ability for users to manage their own passwords. This means users can set and reset passwords via a self-service portal rather than filing a help desk ticket and waiting for a delegated administrator to service the request. The Azure AD password management tools work if you are an exclusively cloud-based organization (which is probably not most organizations, especially if you are interested in single sign on) or if you have synchronized your Azure AD tenant to an on-premises Active Directory, which makes the solution especially attractive.
There are a few steps to implementing the policy required to activate these self-service password management features. To get started:
- Open the Azure classic portal, which can be found at https://manage.windowsazure.com, and then click on Active Directory on the left side of the screen
- Click the directory you want to configure, and then on the next screen, click the CONFIGURE tab
- Scroll down and click Yes for the “Users enabled for password reset” option and then customize the: additional policy controls that appear for access restrictions, the group that performs password resets, and the additional authentication methods available to users who want to reset their passwords
Next, you will need to specify the contact information for all of your users so that it can be used for password resets. If you have directory synchronization enabled through Azure AD Connect, and your users’ properties on your on-premise’s active directory with deployment configured correctly, then those contact details will automatically write into the Azure AD tenant. Otherwise, you will need to edit users either on the Azure portal, within Office 365, or through PowerShell to edit properties for users. You will want to add alternate e-mail addresses and mobile phone numbers that can receive text messages that contain one-time passcodes for multifactor authentication purposes.
You can also set it up so users can provide their own details by sending them to http://aka.ms/ssprsetup and when they sign in to the Access Panel at http://myapps.microsoft.com (if this is part of your users’ workflow). They can also be forced to provide details if you choose Yes to “Require users to register when signing in to the access portal.”
A big piece of making this work is having Azure AD Connect set up properly and your firewall configured, which we will tackle in another piece.
If you need more tips about Azure AD password security check out our another blog from Russell Smith.
