When a user logs in, SSPR and/or MFA may ask for additional information in order to confirm that the user is who he claims he is.

As an Administrator, you can define via policy which authentication methods should be made available to users who have been enabled for SSPR and/or MFA. That said, certain authentication methods aren’t available for all features.

When designing an authentication strategy, an Administrator should configure more than the minimum required number of authentication methods for a given solution in case some users don’t have access to some of them.

Authentication methods that are available include Password, Security Questions, Email Address, Microsoft Authenticator app, OATH Hardware token, SMS, Voice call, and App passwords.

Password is available for both MFA and SSPR. Security questions and email addresses can be used only with SSPR. Microsoft authenticator app is currently available for MFA but is, however, in public preview for SSPR as well. Conversely, OATH Hardware token is available for SSPR but in preview for MFA.

SMS and Voice call are both available for MFA usage, as well as SSPR usage; but app passwords can only be used for MFA – and even in those cases, it can only be used in certain conditions.

The Azure AD password is considered an authentication method. It’s the only authentication method that cannot be disabled.

Security questions are available to non-admin users. When using security questions, they should be used in conjunction with a second authentication method, because they are inherently less secure than other methods because it’s entirely possible that other people may know the answers to the questions for another user.

It’s important to note that a user’s security questions are stored privately and securely on the user object in the directory – and they can only be answered by the user during registration. There is no way for an administrator to be able to read or modify a user's questions or the answers to those questions.

There are close to 40 predefined questions that you can use. Common predefined questions include those such as “In what city did you meet your first spouse/partner?”, “In what city did your parents meet?”, “What is your mother's middle name?”, and stuff like that. It’s easy to see why security questions are considered less secure than other authentication methods.

If you REALLY want to use security questions, you can improve their security slightly by using custom security questions instead of the standard out of the box questions. When using custom security questions, you need to remember that the maximum length of a custom security question is 200 characters.

In cases where you decide to use security questions, keep in mind that the minimum answer character limit is three characters and the maximum answer character limit is 40 characters. Users can't answer the same question more than one time, nor can they provide the same answer to more than one question.

The number of questions defined must be greater than or equal to the number of questions that were required to register.

If you plan to use email address with SSPR, Microsoft recommends using an email account that does not require the user's Azure AD password for access.

The Microsoft Authenticator app provides added security to Azure AD work and school accounts, as well as Microsoft accounts – and it’s available for Android, iOS, and Windows Phone.

However, end users cannot register their mobile apps when registering for self-service password reset. Instead, they can register their mobile apps by vising https://aka.ms/mfasetup or by visiting https://aka.ms/setupsecurityinfo.

There are several options available when using the authenticator app. You can use Notification through mobile app, a verification code, or OATH hardware tokens (which is in preview at the time of this course publication).

When using Notification through mobile app, the Microsoft Authenticator helps prevent unauthorized access to accounts by pushing a notification to the user’s smartphone or tablet. The user can then view the notification and select the Verify option if it's legitimate. If it’s not, the user can select Deny instead.

The Microsoft Authenticator app and even other third-party apps can be used as a software token to generate an OATH verification code when authenticating. After a user provides his username and password, the user must enter the code provided by the app into the sign-in screen. This verification code provides a second form of authentication that can help mitigate stolen credentials and compromised accounts.

OATH is an open standard that dictates how one-time password, or OTP, codes are generated. Azure Active Directory supports using both 30 and 60 second OATH-TOTP SHA-1 tokens. Such tokens can be procured from the vendor of your choice. It’s important to note that secret keys are limited to 128 characters.

As such, they might not be compatible with all tokens. At the time of this course publication, OATH hardware tokens are being supported as part of a public preview, so confirm with Microsoft documentation if they are still supported.

To use tokens, you must upload them via a CSV file that includes the UPN, serial number, secret key, time interval, manufacturer, and model. The example on you screen shows what a typical CSV would look like. The header row must be included in the CSV file.

Users may have a combination of up to 5 OATH hardware tokens or authenticator applications such as the Microsoft Authenticator app configured for use at any time.

There are two options available to users when using mobile phones. In cases where users wish to use their mobile phones for password reset without the number being visible in the directory, the administrator should not populate the mobile number in the directory. Instead, the users should populate their Authentication Phone attribute via the password reset registration portal. What this does is allow administrators to see this information in the user's profile, without it being published elsewhere.

Phone numbers must be in the format of +CountryCode PhoneNumber to work properly.

Note the space between the country code and the phone number. This is a requirement.

It’s also important to note that Password reset does not support phone extensions. If you try to append an extension to the number, it will be removed before the call is placed.

When using Text Message, an SMS message, which includes a verification code, is sent to the specified mobile phone number. The user needs to enter the verification code provided in the sign-in interface to continue.

Using the “phone call” option causes an automated voice call to be made to the phone number provided. In this case, the user must answer the call and press # in the phone keypad to authenticate.

The “office phone” option produces an automated voice call that’s made to the phone number that’s been provided. In this case, the user must answer the call and press # in the phone keypad to authenticate.

For this option to work properly, phone numbers must be in the format +CountryCode PhoneNumber, for example, +1 4255551234. The office phone attribute is managed by the administrator, not the end user.

As was the case with the ”mobile phone” option, there needs to be a space between the country code and the phone number. And it’s also important to note that password reset does not support phone extensions. Extensions are removed before the call is placed.

Not all apps support multi-factor authentication. For example, some non-browser apps don’t multi-factor authentication. In these cases, an app password can be used to allow users to authenticate to the non-MFA app.

However, it’s important to note that if you enforce MFA through Conditional Access policies instead of doing so via “per-user MFA”, you cannot create app passwords. This is because apps that use Conditional Access policies to manage access do not need app passwords.

If your organization is federated for SSO with Azure AD, there are some key issues to be aware of if you plan to use Azure MFA:

For example, when using an app password, the app password is verified by Azure AD directly. This means federation is bypassed altogether during the authentication process. Federation is only used when setting up app passwords. 

It’s also important to note that on-prem Client Access Control settings are not honored by App Password, nor are any on-prem authentication logging or auditing capabilities available for app passwords.

When using app passwords, users cannot, by default, create app passwords. If users need to be allowed to create app passwords, enable the Allow users to create app passwords to sign into non-browser applications option under service settings.

LECTURES: Course Introduction - What is Authentication - Designing an Authentication Method - Configuring Multi-Factor Authentication - Accessing MFA Service Settings - Enable SSPR - Sign-in Activity Reports in the Azure Active Directory Portal - Using Sign-in Activity Reports in the Azure Active Directory Portal - Azure Active Directory Monitoring - Implement MFA - Manage User Settings with Azure Multi-Factor Authentication in the Cloud - Manage MFA for Users - Reports in Azure Multi-Factor Authentication - Configure Application Registration in Azure AD - How to Configure Application Registration in Azure AD - What is Azure AD Application Proxy - Configure Azure AD Application Proxy - Azure Active Directory B2B - Add Guest Users to Your Directory in the Azure Portal - Conclusion