Modernize your approach to passwords with the Azure AD identity platform

Yes, we don’t like passwords, but let’s take a practical look at what we can do to make it easier for our users while increasing security.
When I talk to my customers about passwords, I use the following checklist to optimize their approach to passwords.
- Involve your users
- Use strong authentication
- Start banning commonly attacked passwords
- Turn off traditional complexity, and expiration rules
- Protect against leaked credentials
- Implement self-service password reset
Involve your users
When you change your approach to password, your users must be involved. You can use the following section as input to draft your user communication.
- Your password no longer expires — an NO you shouldn’t switch from 3 months expiration to annually because you want to establish a notion of: “If we ask you to change your password in the future, it is only because we are convinced that your password has been compromised.” You want to avoid that attackers can predict the users next password (research), because they might choose one very similar to their previous password, therefore your users need to be aware WHY you ask them to change their password. However, it makes sense to have a last periodic password change after you installed a block list like Azure AD Password Protection to increase the quality of existing passwords. Because Azure AD Identity Protection Leaked Credentials will only detect username/password PAIRS not in general weak passwords.
- An example how to build good passwords: Advocate and establish a culture of passphrases opposed to passwords — “…a longer phrase like “I often like working Mondays” will generally be more secure than shorter combinations of characters that are hard to remember, such as “$Le90pch”.” — Stephan Wiefling
- Which requirements must a password meet in the future: Common passwords are blocked, minimum length of 12 characters, a decent password history, one change per day BUT no complexity nor expiration — There are valid points to require 15 characters or even longer passwords if you have to consider brute force attacks against portals without lockout protections and password cracking as attack vector. Ultimately, it is a risk assessment for your specific environment, a cloud-only environment, with lockout policies and other brute force and password spray protections on all portals, has a lower risk with a minimum length of 12 than a legacy on-prem / hybrid environment, in which, in the worst case, it is not even clear how many login pages there are. Resources: NIST see SP 800–63B Memorized Secret Verifiers, BSI see “ORP.4.A8 Regelung des Passwortgebrauchs”, Microsoft and latest research for the 12 characters minimum
- Highlight that this change can make users’ life easier, the above points (No expiration, No complexity, Use of phase phrases) are pleasant for users
- Please choose a password which you use exclusively for work related purposes (no re-use for non-work related purposes)
- Advertise Passwordless alternatives — more details in the “Use strong authentication” section of this article
- What if you have forgotten your password? — Advertise self-service password reset option, more details in the “Implement self-service password reset” section of this article
Now let’s have a look at the Azure AD features for technical implementation, I will not go into detail here but rather link to the official documentation of the features to reach the respective checklist item. Many of my customers are confused without the following overview which feature has to be activated to reach the respective checklist item.
Use strong authentication
Azure AD pieces involved:
You should have a good Conditional access concept which will require you to look into the following topics for strong authentication:
- Trusted devices via Hybrid Azure AD Join or Intune device compliance
- Traditional MFA methods such as SMS & OATH software tokens
- Azure AD offers several passwordless options, analyzes the personas in your environment and start working on offering them fitting passwordless alternatives
- Risk based authentication that is based on Identity Protection
- Ensure users are registered for strong authentication
- Licensing information
Start banning commonly attacked passwords
Pieces involved: Azure AD Password Protection (Cloud, On-prem)
- Yes it works on your on-prem DCs by installing agents on them
- No you don't have to sync your password hashes for it (but you should for other reasons)
- No you don’t have to enable password write back for it (but you should for other reasons)
- No you don’t have to sync users between on-prem AD and Azure AD for it (but you should for other reasons)
- Licensing information
Turn off traditional complexity, and expiration rules
Pieces involved:
- Azure AD Password expiration policy via Microsoft 365 Admin Center
- AD-DS password policy via default domain policy or fine-grained password policies
- No licensing requirements
Protect against leaked credentials
Pieces involved:
- Requires Azure AD Connect Password Hash Synchronization (PHS) in hybrid environments, NO it’s not your NTHash. And you want PHS anyways for: leaked credential reporting, for your business continuity plan if you use PTA or ADFS and as your new authentication method when you migrate off ADFS to reduce attack surface and prepare for a cloud-only future.
- Leaked Credentials will trigger a HIGH user risk in identity protection
- Your conditional access policy will trigger on the high user risk and require an secure password change
- The user will have to perform MFA prior to setting a new password, hence they must be registered for strong authentication.
- In a hybrid environment the password must be written back to on-prem, hence you need AADC Password Writeback
- No you don’t have to install agents on your DCs for that
- Licensing information
Implement self-service password reset
Pieces involved:
- Azure AD Self-service Password Reset (SSPR)
- Strong authentication registration
- AADC Password Writeback
- Requires Azure AD Premium P1 or P2