MFA and SSPR Administration

Multi-Factor Authentication (MFA) is a security mechanism that requires users to present two or more verification factors to gain access to a resource. The factors fall into three categories: something you know (password), something you have (phone, hardware token), and something you are (biometric). MFA drastically reduces the risk of credential theft because an attacker must compromise multiple factors. In Microsoft 365, MFA is enforced via Conditional Access policies or per-user MFA configuration.

When a user signs in, Azure AD evaluates the authentication request. If the user is subject to an MFA requirement (via Conditional Access or per-user MFA), Azure AD issues a challenge. The user must complete the second factor within a specified time window (default 10 minutes). The authentication flow: 1. User provides primary credentials (username/password). 2. Azure AD validates the credentials and checks if MFA is required. 3. If required, Azure AD sends a challenge to the user's registered authentication methods (e.g., push notification to Microsoft Authenticator). 4. The user approves the sign-in request (e.g., tap approve on phone). 5. Azure AD completes the authentication and issues tokens.

Azure AD supports multiple authentication methods for MFA and SSPR: - Microsoft Authenticator app: Push notification or OTP (one-time passcode). - SMS: Text message with a 6-digit code. - Voice call: Automated call with a code. - OATH hardware tokens: TOTP tokens (e.g., RSA SecurID). - FIDO2 security keys: Passwordless authentication. - Windows Hello for Business: Biometric or PIN. - Certificate-based authentication: Smart cards.

Each method has a default timeout or retry limit. For example, SMS codes expire after 5 minutes, and the user has 3 attempts to enter the correct code before being locked out for 30 seconds.

SSPR allows users to reset their own passwords without administrator intervention, reducing helpdesk tickets. SSPR requires users to register authentication methods before they can reset. The registration can be enforced via a registration campaign or manually. When a user initiates a password reset, they must prove their identity by providing a specified number of authentication methods (e.g., two methods). The reset process: 1. User navigates to the SSPR portal (https://passwordreset.microsoftonline.com). 2. User enters their username and completes a CAPTCHA. 3. User answers security questions or provides codes from registered methods. 4. Azure AD verifies the identity. 5. User sets a new password, which must meet the tenant's password policy.

Microsoft recommends using combined registration for MFA and SSPR, which allows users to register authentication methods once for both services. This is configured in Azure AD > User settings > Combined registration. When enabled, users see a single registration experience at https://aka.ms/mfasetup.

Registration campaigns are a feature that nags users to register for MFA and SSPR. Administrators can configure the campaign to target users who are required to use MFA but haven't registered. The campaign sends reminders via email and in the Microsoft 365 admin center. This is configured in Azure AD > Security > Authentication methods > Registration campaign.

MFA is typically enforced via Conditional Access policies. For example, a policy can require MFA for all users when accessing cloud apps from untrusted locations. The policy evaluates signals such as user, location, device, and application. If the policy requires MFA, Azure AD challenges the user. Conditional Access policies can also require a specific authentication method (e.g., require Microsoft Authenticator).

Per-user MFA is a legacy configuration that can be enabled for individual users. When enabled, the user is required to use MFA every time they sign in, regardless of location or device. This is less flexible than Conditional Access and is not recommended for new deployments. To enable per-user MFA, go to Azure AD > Users > Per-user MFA. Note that per-user MFA overrides Conditional Access policies if both are configured.

Security Defaults is a baseline security policy for tenants created after October 2019. It enforces MFA for all users, blocks legacy authentication, and requires administrators to use MFA. Security Defaults can be disabled if you use Conditional Access. It is a good starting point for small organizations.

To check MFA registration status for a user:

Get-MgUser -UserId user@domain.com -Property Id, StrongAuthenticationRequirements | Select-Object -ExpandProperty StrongAuthenticationMethods

To check SSPR status:

Get-MgUser -UserId user@domain.com -Property Id, PasswordPolicies | Select-Object -ExpandProperty PasswordPolicies

To enable per-user MFA:

$user = Get-MsolUser -UserPrincipalName user@domain.com
$user.StrongAuthenticationRequirements.Add(@{RelyingParty = "*"})
Set-MsolUser -UserPrincipalName user@domain.com -StrongAuthenticationRequirements $user.StrongAuthenticationRequirements

Azure AD Password Protection blocks weak passwords and common variations. When a user resets their password via SSPR, the new password is checked against the banned password list. If the password is weak, the reset fails. This is configured in Azure AD > Security > Authentication methods > Password protection.

MFA is available with all Microsoft 365 licenses, but some features require premium licenses: - Azure AD Free: MFA via Security Defaults or per-user MFA (limited methods). - Azure AD Premium P1: Conditional Access policies for MFA, SSPR with cloud-only users. - Azure AD Premium P2: Risk-based Conditional Access, Identity Protection, and SSPR with writeback for on-premises users.

SSPR requires Azure AD Premium P1 or P2 for on-premises password writeback. Cloud-only SSPR is available with P1.

A multinational company with 50,000 users needs to enforce MFA for all cloud app access. The solution is to create a Conditional Access policy targeting all users and all cloud apps, requiring MFA. They exclude a group of service accounts that use modern authentication (e.g., Microsoft Authenticator for service accounts). They also configure trusted IPs for corporate offices to reduce MFA prompts. The policy includes a session control to require re-authentication every 24 hours. Once deployed, the helpdesk sees a 60% reduction in account compromise incidents. The biggest challenge is user adoption; they use registration campaigns and training to ensure users register their methods. Performance is not an issue because Azure AD handles the authentication flow.

A hybrid organization with on-premises Active Directory wants users to reset their own passwords. They enable SSPR for all users and configure password writeback to sync new passwords to on-premises AD via Azure AD Connect. They require two authentication methods (mobile phone and email). They also enable combined registration. The SSPR portal is customized with the company logo. After deployment, helpdesk calls drop by 40%. A common misconfiguration is not setting the correct permissions for the Azure AD Connect service account to write passwords back. They monitor the writeback via the Azure AD Connect health dashboard.

A financial services firm uses Azure AD Premium P2 to implement risk-based MFA. They configure Conditional Access policies that require MFA when sign-in risk is medium or above, and require password change when user risk is high. They use Identity Protection to detect leaked credentials and anonymous IP addresses. This minimizes friction for low-risk sign-ins while protecting high-risk ones. The challenge is tuning the risk thresholds to balance security and user experience. They set sign-in risk policy to require MFA for medium and above, and user risk policy to block or force password change for high risk. They also set up alerts for risky users.