Azure AD modern authentication, self-service password reset (SSPR)

Some information regarding MFA and registration of verification methods is newly described in

Azure AD licenses and features

Azure Active Directory offers various services and features depending on the Azure AD license level. The editions are Free, Office 365 Apps (formerly Basic), Premium P1, and Premium P2. We can see which edition we have in the Azure AD Admin Center under Overview section Basic information - License. Once we have a higher license for one user, we see the entire Tenant with this license. We should use higher functions only for users who have been assigned the given license.

According to the information, Azure AD Free is part of basic Office 365, Azure, Dynamics 365, Intune, and Power Platform subscriptions. Azure AD for Office 365 apps is included in Office 365 E1, E3, E5, F1, and F3. Azure AD Premium P1 is part of Microsoft 365 E3, Microsoft 365 Business Premium, and Enterprise Mobility + Security (EMS) E3. Azure AD Premium P2 is included in Microsoft 365 E5 and EMS E5. We can also purchase Premium P1 and P2 separately.

Basic features are also in Azure AD free, but they may be significantly limited compared to the higher edition. This applies to the functions we focus on here, Self-Service Password Reset (SSPR) and Multi-Factor Authentication (MFA).

Azure AD free

According to the documentation, Azure AD free includes

Self-Service Password Change for cloud users
Multi-Factor Authentication

Azure AD for Office 365 apps

Additional features are added with Azure AD for Office 365 apps such as

Company branding (customization of logon & logout pages, access panel)
Self-service password reset for cloud users

Azure AD Premium P1

Many more are added by Azure AD Premium P1

Self-service password reset/change/unlock with on-premises write-back
Azure AD Join: self-service bitlocker recovery, enterprise state roaming
Conditional Access

Azure AD Premium P2

The Azure AD Premium P2 edition adds Identity Protection and Identity Governance features

Vulnerabilities and risky accounts detection
Privileged Identity Management (PIM)

SSPR and MFA

So in Free and Office 365 apps, SSPR only works for cloud users; to work with synchronized users from on-premises, we need Premium P1. Similarly, for better use of MFA, based on Conditional Access, we also need Premium P1.

Modern Authentication

Modern Authentication is an identity management method that offers more secure user authentication and authorization. The term modern authentication encompasses a combination of authentication and authorization methods between client and server. It includes authentication methods (such as multi-factor authentication, smart card authentication), authorization methods (Open Authorization (OAuth)), conditional access policies (Conditional access policies, Mobile Application Management).

Legacy Authentication refers to long-used protocols like Kerberos, NTLM, CHAP, etc., which generally don't work well over the internet. Basic Authentication is often used, which is very simple (uses plain text username and password, only encoded using base64, so it must be combined with SSL), but has a number of vulnerabilities.

Modern Authentication is a group of protocols designed to increase the security of cloud resources. For example, Security Assertion Markup Language (SAML), WS-Federation, OAuth. Their goal is to move away from the username/password method and instead use token-based claims. During authentication, an access token is generated, which determines what access the requester has. Tokens are time-limited and can be revoked.

For Microsoft services, we can recognize the type of authentication by the appearance of the login dialog. The first image is Basic Authentication, the second is Modern Authentication.

Enabling Password Writeback

The procedure is well described in the official documentation. Here's just brief info.

We need to set (or check) permissions for the account used by Azure AD Connect (it may be an account with a name similar to MSOL_432e1e4ab312). These are Permissions Reset password and Properties Write lockoutTime, Write pwdLastSet (in my environment, everything was set automatically, even Read/Write all properties for Descendant User objects).

I don't understand what the information in the official documentation means: Extended rights for "Unexpire Password" on the root object of each domain in that forest, if not already set. I couldn't find more information about this anywhere.

The second step is to run Azure AD Connect - Customize synchronization options and under Optional Feature enable Password writeback.

Password Policies

If we have user accounts synchronized from On-Premises AD DS to Azure AD, there are two versions of password requirements, password expiration, and account lockout. By default, the cloud password policy (password complexity requirements) is not applied to accounts synchronized from On-Premises along with the password hash, and they are set to Never Expire. Also, the Force Password Change on Next Logon property doesn't work (doesn't synchronize).

On-Premises AD DS

In the internal AD DS environment, we use Group Policy to set password policies.

Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy

Here we can set password requirements, for example, a minimum of 8 characters and complex (must contain characters from at least 3 different categories, must not contain the username). And password change requirements (expiration), minimum and maximum age, password history.

Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy

Here we set account lockout. For example, that after 5 incorrect passwords in a row, the account is blocked for 30 minutes. We can also set after what time the counter of failed attempts is reset.

Cloud Azure AD

Azure AD has firmly defined password requirements by default. It's a minimum of 8 characters (maximum 256) from 3 different categories (lowercase letters, uppercase letters, numbers, allowed symbols). It also automatically uses a global list of weak or compromised passwords (Global banned password list), which cannot be used. And we can define our own list (Custom banned password list). Other protective mechanisms of Azure AD Password Protection are also used. We can use the Banned password list for On-Premises AD DS through an agent installed on DC.

In Azure AD, password expiration is not enabled by default. We can set it in

Microsoft 365 admin center - Settings - Org settings - Security & Privacy - Password expiration policy

For account lockout, Smart Lockout is used, configuration is in

Azure Active Directory admin center - Security - Authentication methods - Password protection

We set the number of failed logins that lead to lockout, and the minimum lockout duration. Smart behavior is in many things. If an account is repeatedly locked, it's for an increasingly longer time. The hash of the last three failed attempt passwords is monitored, and if the same password is used, the failed attempt counter doesn't increase.

If an account in the cloud is locked, an administrator cannot unlock it. The set time must elapse, or the user can use SSPR and perform a password reset.

Self-Service Password Reset / Change / Unlock (SSPR)

Azure AD SSPR (Self-Service Password Reset) allows users to change or reset their password (forgotten password) or unlock their account without administrator intervention. Direct link Microsoft Online password reset.

SSPR can be turned off (None), enabled for a group of users (Selected), or enabled for all users (All). After enabling, users typically need to fill in contact information (authentication methods) that will be used for SSPR. Until then, the service cannot be used.

Note: By default, administrators (members of all admin roles) always have SSPR enabled and are required to use 2 verification methods. We can see this information in the Administrator Policy section.

Note: MS states that we should only enable it for users with the appropriate license. Currently, no license check is performed.

Password change (or account unlock) with Password Writeback occurs in On-Premises AD DS immediately. Before execution, it checks if the appropriate service is running on-premises and if communication is working. The entered password is sent encrypted to on-premises, the user is looked up, and an attempt is made to change the password. If the password doesn't meet on-premises password policies, an error is returned and the password isn't changed. Even if the cloud password policy were stricter, the on-premises policy is used here (when synchronizing password hashes to the cloud, the cloud policy isn't checked).

Combined security information registration

Combined security information registration for Azure Active Directory overview

If combined security information registration isn't enabled, users must register authentication methods separately for SSPR (Self-Service Password Reset) and for MFA (Multi-Factor Authentication). Enabling it changes the application (appearance) for registering authentication methods (it also allows registration of authentication apps).

Enabling is highly recommended (and necessary for some other functions). It's done simply

Azure Active Directory admin center - User settings in the link Manage user feature preview settings
item Users can use the combined security information registration experience

Authentication methods

What authentication and verification methods are available in Azure Active Directory?

Here we assume that we have combined security information registration enabled. Then we can use most methods for both SSPR and multi-factor authentication (MFA). But some are exceptions, for example, email can't be used for MFA. Windows Hello for Business can't be used for SSPR.

Note: Descriptions of authentication methods differ in various places in Microsoft documentation. They are affected by usage and settings, and it's possible that MS is continuously expanding the options.

Verification most often works by sending or generating a verification code. The user enters this in the self-service portal (SSPR) or in the login dialog (for MFA). The second option is confirmation (notification). Microsoft always recommends registering multiple methods to have a backup.

Mobile app notification - approval of push notifications using Approve in the Microsoft Authenticator app (other apps are probably not supported)
Mobile app code - the app generates a verification code (OATH verification code) every 30 seconds, so it's an OATH software token, doesn't need internet connection, other apps are also supported (like Google Authenticator)
Email - a verification code is sent to the email
Mobile phone - we enter a mobile phone number, then we can receive a verification code via SMS (Text my mobile phone) or an automated call, the user accepts it and confirms with the # key (Call my mobile phone)
Office phone - we enter a landline phone number, an automated call is available, the user accepts it and confirms with the # key (Call my office phone)
Security questions - security questions that we select and provide answers to

Enabling and setting up SSPR

Azure Active Directory admin center - Password reset in the Properties section we enable it.

in the Authentication methods section we select whether 1 or 2 methods are required for verification, and which ones are allowed

Note: If we choose one method, we can't enable Mobile app notification.

The page also has a link to documentation that describes combined security information registration.

in the Registration section we can enable users to see a form for entering authentication methods at their next login (enabled by default)

Users can enter and manage this information even without this option, in their profile under Security Info https://aka.ms/setupsecurityinfo. Or an administrator can enter it in Azure AD in the user account settings (under Authentication methods). As a suggestion, they can be synchronized from On-Premises AD (alternative email address and mobile phone).

we use the On-premises integration section if we've enabled Password Writeback to get changes to on-Premises AD DS

Probably Write back passwords to your on-premises directory? is automatically enabled. With the second option Allow users to unlock accounts without resetting their password? we can allow unlocking of accounts in on-Premises AD without changing the password. When Password Reset is in progress, the account is always unlocked.

Audit and usage monitoring

Authentication Methods Activity

Reports are available in various places, each containing slightly different information.

Azure Active Directory admin center - Security - Authentication Methods - Activity
Azure Active Directory admin center - Users - Sign-ins
Azure Active Directory admin center - Password reset in the Audit logs and Usage & insights sections

The last place concerns SSPR. In the Audit log we see the history of SSPR use by users. In Usage & insights we see usage statistics and detailed lists of users who have SSPR enabled or have registered methods for SSPR or MFA (including a list of methods).

User usage of SSPR

Registration of authentication methods

Set up your Security info from a sign-in prompt

If we enable SSPR for a user, and we have set to require registration at login, then at the next login using modern authentication (for example, via browser) information will be displayed that more information needs to be entered. We can go through the wizard and set up authentication methods or skip it (it will be displayed again at the next login).

The appearance and options depend on whether we have combined security information registration enabled or not (image below).

It may be necessary to enter one or two methods, different methods may be offered depending on the situation. Microsoft Authenticator app is offered as the main option, but we can choose a different method.

Users can manage their authentication methods in their My Account by clicking on Security info. Adding a phone or email is intuitive. We enter the details and a verification code is sent, which we must enter in the next step to confirm.

Note: If we already have a method set up, then when we next access the Security info page (and thus have the option to change methods) we must use strong authentication. That is, use the set method for login.

Autentizační metody - My Account - Security info

Note: Some information may be set from the company directory (such as mobile phone), but it needs to be verified to be usable.

The Microsoft Authenticator app offers the most options, supporting both code generation (OATH software token) and notifications. It can be used for SSPR and MFA as well as for passwordless sign-in. The app is added by scanning a QR code from the screen and then confirming.

The app usually works well and quickly displays notifications (if it's running in the background and the system doesn't terminate it). When occasionally a notification doesn't come automatically, you need to launch the app. If the notification still doesn't appear, you can manually trigger a notification check. There's a button on the top right bar. Once, the notification still wasn't coming for me. I turned off WiFi and switched to mobile data, and it arrived immediately.

Account unlock, forgotten password

We can start SSPR with a direct link https://passwordreset.microsoftonline.com/ (shortcut https://aka.ms/sspr) or click on Forgot my password on the login page.

If we use password hash synchronization (PHS), when a user account is locked in On-Premises AD DS, it remains unlocked in Azure AD. It's the same the other way around, when locked in the cloud it remains unlocked in internal AD DS.

Note: You can change your password (if you are logged in) in the account management at My Account - Change Password.

We can perform

password reset - I forgot my password - set a new password without knowing the old one, and at the same time unlock the account. This is possible for both cloud and On-Premises accounts. The change is immediate.
account unlock - I know my password, but still can't sign in - only for On-Premises accounts, unlocks the account in the internal AD DS. If the account is also locked in the cloud, it will not be unlocked. This option must be enabled.

In the next step, we perform verification. Options are offered according to the settings and registered methods.