Cloud MS - AZURE Multi Authentication

Contents
Authentication Documentation
Overview
What is authentication?
Quickstart
Configure password reset
Tutorials
1 Enable MFA for Applications
2 Enable a SSPR pilot
Enable SSPR on-premises integration
Integrate Azure Identity Protection
Concepts
Authentication methods
Passwordless authentication
Combined registration
Password reset
How password reset works
Password reset options
Password reset policies
What license do I need?
On-premises integration
Multi-Factor Authentication
How MFA works
License your users
Manage an Auth Provider
Security guidance
MFA for Office 365
MFA FAQ
Azure AD password protection
Eliminate weak passwords in the cloud
Eliminate weak passwords on-premises
Resilient access controls
How-to guides
Self-service password reset
Deploy self-service password reset
Pre-register authentication data
Enable password writeback
SSPR for Windows clients
Cloud-based MFA
Deploy cloud-based MFA
Per user MFA
User and device settings
Configure settings
Directory Federation
Windows Server 2016 AD FS Adapter
Federation Services
Use AD FS
RADIUS Integration
Use existing network policy servers
Advanced configuration for NPS extension
Azure VPN and Azure MFA
Remote Desktop Gateway
VPN
Combined registration
Enable combined registration
Troubleshoot combined registration
Azure AD password protection
Configure the banned password list
Deploy Azure AD password protection
Configure Azure AD password protection
Monitor Azure AD password protection
Troubleshoot Azure AD password protection
Frequently asked questions
On-premises agent version history
Azure AD smart lockout
Passwordless
Passwordless security keys
Passwordless phone sign-in
Windows Hello for Business
Certificate-based authentication
Get started with certificate auth
CBA on Android Devices
CBA on iOS Devices
Reporting
Usage and insights
SSPR Reports
MFA Reports
Data collection
MFA Server
Deploy MFA on-premises
Install the user portal
Mobile App Web Service
Configure high availability
Upgrade MFA Server
Upgrade from PhoneFactor
Windows Authentication
IIS web apps
Directory Integration
LDAP Authentication
RADIUS Authentication
Active Directory
Directory Federation
Use AD FS 2.0
Use Windows Server 2012 R2 AD FS
RADIUS Integration
Remote Desktop Gateway
Advanced VPN Configurations
NPS extension errors
Troubleshoot
Troubleshoot SSPR
SSPR FAQ
MFA FAQ
NPS extension
Reference
MFA user guide
Code samples
Azure PowerShell cmdlets
Service limits and restrictions
Resources
Azure feedback forum
MSDN forum
Pricing
Service updates
Stack Overflow
Videos
What methods are available for authentication?
5/21/2019 • 2 minutes to read • Edit Online
We hear reports in the news, passwords being stolen, and identities being compromised. Requiring a second factor
in addition to a password immediately increases the security of your organization. Microsoft Azure Active Directory
(Azure AD ) includes features, like Azure Multi-Factor Authentication (Azure MFA) and Azure AD self-service
password reset (SSPR ), to help administrators protect their organizations and users with additional authentication
methods.
There are many scenarios that include: signing in to an application, resetting their password, enabling Windows
Hello, and others, your users may be asked to provide additional verification that they are who they say they are.
Additional verification may come in the form of authentication methods such as:
A code provided in an email or text message
A phone call
A notification or code on their phone
Answers to security questions
Azure MFA and Azure AD self-service password reset give administrators control over configuration, policy,
monitoring, and reporting using Azure AD and the Azure portal to protect their organizations.
Self-service password reset

Self-service password reset provides your users the ability to reset their password, with no administrator
intervention, when and where they need to.
Self-service password reset includes:
Password change: I know my password but want to change it to something new.
Password reset: I can't sign in and want to reset my password using one or more approved authentication
methods.
Account unlock: I can't sign in because my account is locked out and I want to unlock using one or more
approved authentication methods.
Azure Multi-Factor Authentication (MFA) is Microsoft's two-step verification solution. Using administrator
approved authentication methods, Azure MFA helps safeguard your access to data and applications, while meeting
the demand for a simple sign-in process.
License requirements
Using this feature requires an Azure AD Premium P1 license. To find the right license for your requirements,
see Comparing generally available features of the Free, Basic, and Premium editions.
Next steps
The next step is to dive in and configure self-service password reset and Azure Multi-Factor Authentication.
To get started with self-service password reset, see the enable SSPR quickstart article.
Learn more about self-service password reset in the article, How it works: Azure AD self-service password reset
Learn more about Azure Multi-Factor Authentication in the article, How it works: Azure Multi-Factor
Authentication
Quickstart: Self-service password reset
In this quickstart, you walk through configuring self-service password reset (SSPR ) as a simple means for IT
administrators to enable users to reset their passwords or unlock their accounts.
Prerequisites
A working Azure AD tenant with at least a trial license enabled.
An account with Global Administrator privileges.
A non-administrator test user with a password you know, if you need to create a user see the article Quickstart:
Add new users to Azure Active Directory.
A pilot group to test with that the non-administrator test user is a member of, if you need to create a group see
the article Create a group and add members in Azure Active Directory.
Enable self-service password reset

1. From your existing Azure AD tenant, on the Azure portal under Azure Active Directory select Password
reset.
2. From the Properties page, under the option Self Service Password Reset Enabled, choose Selected.
From Select group, choose your pilot group created as part of the prerequisites section of this article.
Click Save.
3. From the Authentication methods page, make the following choices:
Number of methods required to reset: 1
Methods available to users:
Email
Mobile app code (preview)
Click Save.
4. From the Registration page, make the following choices:
Require users to register when they sign in: Yes
Set the number of days before users are asked to reconfirm their authentication information: 365
Test self-service password reset

Now lets test your SSPR configuration with a test user. Since Microsoft enforces strong authentication
requirements for Azure administrator accounts, testing using an administrator account may change the outcome.
For more information regarding the administrator password policy, see our password policy article.
1. Open a new browser window in InPrivate or incognito mode, and browse to https://aka.ms/ssprsetup.
2. Sign in with a non-administrator test user, and register your authentication phone.
3. Once complete, click the button marked looks good and close the browser window.
4. Open a new browser window in InPrivate or incognito mode, and browse to https://aka.ms/sspr.
5. Enter your non-administrator test users' User ID, the characters from the CAPTCHA, and then click Next.
6. Follow the verification steps to reset your password
Clean up resources
It's easy to disable self-service password reset. Open your Azure AD tenant and go to Properties > Password
Reset, and then select None under Self Service Password Reset Enabled.
Next steps
In this quickstart, you’ve learned how to quickly configure self-service password reset for your cloud-only users.
To find out how to complete a more detailed roll out, continue to our roll out guide.
Roll out self-service password reset
Tutorial: Complete an Azure Multi-Factor
Authentication pilot roll out
In this tutorial, you walk you through configuring a Conditional Access policy enabling Azure Multi-Factor
Authentication (Azure MFA) when logging in to the Azure portal. The policy is deployed to and tested on a specific
group of pilot users. Deployment of Azure MFA using Conditional Access provides significant flexibility for
organizations and administrators compared to the traditional enforced method.
Enable Azure Multi-Factor Authentication
Test Azure Multi-Factor Authentication
Prerequisites
A working Azure AD tenant with at least a trial license enabled.
An account with Global Administrator privileges.
A non-administrator test user with a password you know for testing, if you need to create a user see the article
Quickstart: Add new users to Azure Active Directory.
A pilot group to test with that the non-administrator user is a member of, if you need to create a group see the
article Create a group and add members in Azure Active Directory.
Enable Azure Multi-Factor Authentication

1. Sign in to the Azure portal using a Global Administrator account.
2. Browse to Azure Active Directory, Conditional Access
3. Select New policy
4. Name your policy MFA Pilot
5. Under users and groups, select the Select users and groups radio button
Select your pilot group created as part of the prerequisites section of this article
Click Done
6. Under Cloud apps, select the Select apps radio button
The cloud app for the Azure portal is Microsoft Azure Management
Click Select
Click Done
7. Skip the Conditions section
8. Under Grant, make sure the Grant access radio button is selected
Check the box for Require multi-factor authentication
Click Select
9. Skip the Session section
10. Set the Enable policy toggle to On
11. Click Create
Test Azure Multi-Factor Authentication

To prove that your Conditional Access policy works, you test logging in to a resource that should not require MFA
and then to the Azure portal that requires MFA.
1. Open a new browser window in InPrivate or incognito mode and browse to
https://account.activedirectory.windowsazure.com.
Log in with the test user created as part of the prerequisites section of this article and note that it should
not ask you to complete MFA.
Close the browser window.
2. Open a new browser window in InPrivate or incognito mode and browse to https://portal.azure.com.
Log in with the test user created as part of the prerequisites section of this article and note that you
should now be required to register for and use Azure Multi-Factor Authentication.
Close the browser window.
Clean up resources
If you decide you no longer want to use the functionality you have configured as part of this tutorial, make the
following change.
1. Sign in to the Azure portal.
2. Browse to Azure Active Directory, Conditional Access.
3. Select the Conditional Access policy you created.
4. Click Delete.
Next steps
In this tutorial, you have enabled Azure Multi-Factor Authentication. Continue on to the next tutorial to see how
Azure Identity Protection can be integrated into the self-service password reset and Multi-Factor Authentication
experiences.
Evaluate risk at sign in
Tutorial: Complete an Azure AD self-service password
reset pilot roll out
In this tutorial, you will enable a pilot roll out of Azure AD self-service password reset (SSPR ) in your organization
and test using a non-administrator account.
It is important that any testing of self-service password reset be done with non-administrator accounts. Microsoft
manages the password reset policy for administrator accounts and requires the use of stronger authentication
methods. This policy does not allow the use of security questions and answers, and requires the use of two
methods for reset.
Test SSPR as a user
Prerequisites
A Global Administrator account

2. Browse to Azure Active Directory and select Password reset.
3. Start with a pilot group by enabling self-service password for a subset of users in your organization.
From the Properties page, under the option Self Service Password Reset Enabled, choose Selected
and pick a pilot group.
Only members of the specific Azure AD group that you choose can use the SSPR functionality. We
recommend that you define a group of users and use this setting when you deploy this
functionality for a proof of concept. Nesting of security groups is supported here.
Ensure the users in the group you picked have been appropriately licensed.
Click Save
4. On the Authentication methods page
Set the Number of methods required to reset to 1
Choose which Methods available to users your organization wants to allow. For this tutorial check the
boxes to enable Email, Mobile phone, Office phone, Mobile app notification (preview) and
Mobile app code (preview).
Click Save
5. On the Registration page
Select Yes for Require users to register when signing in.
Set Number of days before users are asked to reconfirm their authentication information to 180.
Click Save
6. On the Notifications page
Set Notify users on password resets option to Yes.
Set Notify all admins when other admins reset their password to Yes.
7. On the Customization page
Microsoft recommends that you set Customize helpdesk link to Yes and provide either an email
address or web page URL where your users can get additional help from your organization in the
Custom helpdesk email or URL field.
For this tutorial we will leave Customize helpdesk link set to No.
Self-service password reset is now configured for cloud users in your pilot group.
Test SSPR as a user

Test self-service password reset using a non-administrator test user that is a member of your pilot group. Be
aware that if you use an account that has any administrator roles assigned to it the authentication
methods and number may be different than what you selected as Microsoft manages the administrator
policy.
1. Open a new InPrivate or incognito mode browser window.
2. Using a test user register for self-service password reset using the registration portal located at
https://aka.ms/ssprsetup.
3. Using the same test user browse to the self-service password reset portal https://aka.ms/sspr and attempt to
reset your password using the information you provided in the previous step.
4. You should be able to successfully reset your password.
Clean up resources
If you decide you no longer want to use the functionality you have configured as part of this tutorial, make the
following change.
2. Browse to Azure Active Directory and select Password reset.
3. From the Properties page, under the option Self Service Password Reset Enabled, choose None.
4. Click Save
Next steps
In this tutorial, you have enabled Azure AD self-service password reset. Continue on to the next tutorial to see how
an on-premises Active Directory Domain Services infrastructure can be integrated into the self-service password
reset experience.
Enable SSPR on-premises writeback integration
Tutorial: Enabling password writeback
In this tutorial, you will enable password writeback for your hybrid environment. Password writeback is used to
synchronize password changes in Azure Active Directory (Azure AD ) back to your on-premises Active Directory
Domain Services (AD DS ) environment. Password writeback is enabled as part of Azure AD Connect to provide a
secure mechanism to send password changes back to an existing on-premises directory from Azure AD. You can
find more detail about the inner workings of password writeback in the article, What is password writeback.
Enable password writeback option in Azure AD Connect
Enable password writeback option in self-service password reset (SSPR )
Prerequisites
Access to a working Azure AD tenant with at least a trial license assigned.
An account with Global Administrator privileges in your Azure AD tenant.
An existing server configured running a current version of Azure AD Connect.
Previous self-service password reset (SSPR ) tutorials have been completed.
Enable password writeback option in Azure AD Connect

To enable password writeback we will first need to enable the feature from the server that you have installed Azure
AD Connect on.
1. To configure and enable password writeback, sign in to your Azure AD Connect server and start the Azure AD
Connect configuration wizard.
2. On the Welcome page, select Configure.
3. On the Additional tasks page, select Customize synchronization options, and then select Next.
4. On the Connect to Azure AD page, enter a global administrator credential, and then select Next.
5. On the Connect directories and Domain/OU filtering pages, select Next.
6. On the Optional features page, select the box next to Password writeback and select Next.
7. On the Ready to configure page, select Configure and wait for the process to finish.
8. When you see the configuration finish, select Exit.
Enable password writeback option in SSPR

Enabling the password writeback feature in Azure AD Connect is only half of the story. Allowing SSPR to use
password writeback completes the loop thereby allowing users who change or reset their password to have that
password set on-premises as well.
2. Browse to Azure Active Directory, click on Password Reset, then choose On-premises integration.
3. Set the option for Write back passwords to your on-premises directory, to Yes.
4. Set the option for Allow users to unlock accounts without resetting their password, to Yes.
5. Click Save
Next steps
In this tutorial, you have enabled password writeback for self-service password reset. Leave the Azure portal
window open and continue to the next tutorial to configure additional settings related to self-service password
reset before you roll out the solution in a pilot.
Evaluate risk at sign in
Tutorial: Use risk events to trigger Multi-Factor
Authentication and password changes
In this tutorial, you will enable features of Azure Active Directory (Azure AD ) Identity Protection, an Azure AD
Premium P2 feature that is more than just a monitoring and reporting tool. To protect your organization's
identities, you can configure risk-based policies that automatically respond to risky behaviors. These policies, can
either automatically block or initiate remediation, including requiring password changes and enforcing Multi-
Factor Authentication.
Azure AD Identity Protection policies can be used in addition to existing Conditional Access policies as an extra
layer of protection. Your users may never trigger a risky behavior requiring one of these policies, but as an
administrator you know they are protected.
Some items that may trigger a risk event include:
Users with leaked credentials
Sign-ins from anonymous IP addresses
Impossible travel to atypical locations
Sign-ins from infected devices
Sign-ins from IP addresses with suspicious activity
Sign-ins from unfamiliar locations
More information about Azure AD Identity Protection can be found in the article What is Azure AD Identity
Protection
Enable Azure MFA registration
Enable risk-based password changes
Enable risk-based Multi-Factor Authentication
Prerequisites
Access to a working Azure AD tenant with at least a trial Azure AD Premium P2 license assigned.
An account with Global Administrator privileges in your Azure AD tenant.
Have completed the previous self-service password reset (SSPR ) and Multi-Factor Authentication (MFA)
tutorials.
Enable risk-based policies for SSPR and MFA

Enabling the risk-based policies is a straightforward process. The steps below will guide you through a sample
configuration.
Enable users to register for Multi-Factor Authentication
Azure AD Identity Protection includes a default policy that can help you to get your users registered for Multi-
Factor Authentication and easily identify the current registration status. Enabling this policy does not start
requiring users to perform Multi-Factor Authentication, but will ask them to pre-register.
2. Click on All services, then browse to Azure AD Identity Protection.
3. Click on MFA registration.
4. Set Enforce Policy to On.
a. Setting this policy will require all of your users to register methods to prepare to use by Multi-Factor
Authentication.
5. Click Save.
Enable risk-based password changes

Microsoft works with researchers, law enforcement, various security teams at Microsoft, and other trusted sources
to find username and password pairs. When one of these pairs matches an account in your environment, a risk-
based password change can be triggered using the following policy.
1. Click on User risk policy.
2. Under Conditions, select User risk, then choose Medium and above.
3. Click "Select" then "Done"
4. Under Access, choose Allow access, and then select Require password change.
5. Click "Select"
7. Click Save
Enable risk-based Multi-Factor Authentication
Most users have a normal behavior that can be tracked, when they fall outside of this norm it could be risky to
allow them to just sign in. You may want to block that user or maybe just ask them to perform a Multi-Factor
Authentication to prove that they are really who they say they are. To enable a policy requiring MFA when a risky
sign-in is detected, enable the following policy.
1. Click on Sign-in risk policy
2. Under Conditions, select User risk, then choose Medium and above.
3. Click "Select" then "Done"
4. Under Access, choose Allow access, and then select Require multi-factor authentication.
5. Click "Select"
7. Click Save
Clean up resources
If you have completed testing and no longer want to have the risk-based policies enabled, return to each policy
you want to disable, and set Enforce Policy to Off.
What are authentication methods?
As an administrator, choosing authentication methods for Azure Multi-Factor Authentication and self-service
password reset (SSPR ) it is recommended that you require users to register multiple authentication methods.
When an authentication method is not available for a user, they can choose to authenticate with another method.
Administrators can define in policy which authentication methods are available to users of SSPR and MFA. Some
authentication methods may not be available to all features. For more information about configuring your policies
see the articles How to successfully roll out self-service password reset and Planning a cloud-based Azure Multi-
Factor Authentication
Microsoft highly recommends Administrators enable users to select more than the minimum required number of
authentication methods in case they do not have access to one.
AUTHENTICATION METHOD USAGE
Password MFA and SSPR
Security questions SSPR Only
Email address SSPR Only
Microsoft Authenticator app MFA and public preview for SSPR
OATH Hardware token Public preview for MFA and SSPR
SMS MFA and SSPR
Voice call MFA and SSPR
App passwords MFA only in certain cases

OATH Hardware tokens for MFA and SSPR and Mobile app notification or Mobile app code as methods for Azure AD self-service
password reset are public preview features of Azure Active Directory. For more information about previews, see Supplemental
Terms of Use for Microsoft Azure Previews
Password
Your Azure AD password is considered an authentication method. It is the one method that cannot be disabled.
Security questions
Security questions are available only in Azure AD self-service password reset to non-administrator accounts.
If you use security questions, we recommend using them in conjunction with another method. Security questions
can be less secure than other methods because some people might know the answers to another user's questions.
NOTE
Security questions are stored privately and securely on a user object in the directory and can only be answered by users
during registration. There is no way for an administrator to read or modify a user's questions or answers.
Predefined questions
In what city did you meet your first spouse/partner?
In what city did your parents meet?
In what city does your nearest sibling live?
In what city was your father born?
In what city was your first job?
In what city was your mother born?
What city were you in on New Year's 2000?
What is the last name of your favorite teacher in high school?
What is the name of a college you applied to but didn't attend?
What is the name of the place in which you held your first wedding reception?
What is your father's middle name?
What is your favorite food?
What is your maternal grandmother's first and last name?
What is your mother's middle name?
What is your oldest sibling's birthday month and year? (e.g. November 1985)
What is your oldest sibling's middle name?
What is your paternal grandfather's first and last name?
What is your youngest sibling's middle name?
What school did you attend for sixth grade?
What was the first and last name of your childhood best friend?
What was the first and last name of your first significant other?
What was the last name of your favorite grade school teacher?
What was the make and model of your first car or motorcycle?
What was the name of the first school you attended?
What was the name of the hospital in which you were born?
What was the name of the street of your first childhood home?
What was the name of your childhood hero?
What was the name of your favorite stuffed animal?
What was the name of your first pet?
What was your childhood nickname?
What was your favorite sport in high school?
What was your first job?
What were the last four digits of your childhood telephone number?
When you were young, what did you want to be when you grew up?
Who is the most famous person you have ever met?
All of the predefined security questions are translated and localized into the full set of Office 365 languages based
on the user's browser locale.
Custom security questions
Custom security questions are not localized. All custom questions are displayed in the same language as they are
entered in the administrative user interface, even if the user's browser locale is different. If you need localized
questions, you should use the predefined questions.
The maximum length of a custom security question is 200 characters.
Security question requirements
The minimum answer character limit is three characters.
The maximum answer character limit is 40 characters.
Users can't answer the same question more than one time.
Users can't provide the same answer to more than one question.
Any character set can be used to define the questions and the answers, including Unicode characters.
The number of questions defined must be greater than or equal to the number of questions that were required
to register.
Email address
Email address is available only in Azure AD self-service password reset.
Microsoft recommends the use of an email account that would not require the user's Azure AD password to
access.
Microsoft Authenticator app

The Microsoft Authenticator app provides an additional level of security to your Azure AD work or school account
or your Microsoft account.
The Microsoft Authenticator app is available for Android, iOS, and Windows Phone.
NOTE
Users will not have the option to register their mobile app when registering for self-service password reset. Instead, users
can register their mobile app at https://aka.ms/mfasetup or in the security info registration preview at
https://aka.ms/setupsecurityinfo.
Notification through mobile app

The Microsoft Authenticator app can help prevent unauthorized access to accounts and stop fraudulent
transactions by pushing a notification to your smartphone or tablet. Users view the notification, and if it's
legitimate, select Verify. Otherwise, they can select Deny.
WARNING
For self-service password reset when only one method is required for reset, verification code is the only option available to
users to ensure the highest level of security.
When two methods are required users will be able to reset using EITHER notification OR verification code in addition to any
other enabled methods.
If you enable the use of both notification through mobile app and verification code from mobile app, users who
register the Microsoft Authenticator app using a notification are able to use both notification and code to verify
their identity.
NOTE
If your organization has staff working in or traveling to China, the Notification through mobile app method on Android
devices does not work in that country. Alternate methods should be made available for those users.
Verification code from mobile app

The Microsoft Authenticator app or other third-party apps can be used as a software token to generate an OATH
verification code. After entering your username and password, you enter the code provided by the app into the
sign-in screen. The verification code provides a second form of authentication.
WARNING
For self-service password reset when only one method is required for reset verification code is the only option available to
users to ensure the highest level of security.
Users may have a combination of up to five OATH hardware tokens or authenticator applications such as the
Microsoft Authenticator app configured for use at any time.
OATH hardware tokens (public preview)

OATH is an open standard that specifies how one-time password (OTP ) codes are generated. Azure AD will
support the use of OATH-TOTP SHA-1 tokens of the 30-second or 60-second variety. Customers can procure
these tokens from the vendor of their choice. Secret keys are limited to 128 characters, which may not be
compatible with all tokens.
OATH hardware tokens are being supported as part of a public preview. For more information about previews,
see Supplemental Terms of Use for Microsoft Azure Previews
Once tokens are acquired they must be uploaded in a comma-separated values (CSV ) file format including the
UPN, serial number, secret key, time interval, manufacturer, and model as the example below shows.
upn,serial number,secret key,time interval,manufacturer,model

Helga@contoso.com,1234567,1234567890abcdef1234567890abcdef,60,Contoso,HardwareKey
NOTE
Make sure you include the header row in your CSV file as shown above.
Once properly formatted as a CSV file, an administrator can then sign in to the Azure portal and navigate to
Azure Active Directory, MFA Server, OATH tokens, and upload the resulting CSV file.
Depending on the size of the CSV file, it may take a few minutes to process. Click the Refresh button to get the
current status. If there are any errors in the file, you will have the option to download a CSV file listing any errors
for you to resolve.
Once any errors have been addressed, the administrator then can activate each key by clicking Activate for the
token to be activated and entering the OTP displayed on the token.
Users may have a combination of up to five OATH hardware tokens or authenticator applications such as the
Microsoft Authenticator app configured for use at any time.
Phone options
Mobile phone
Two options are available to users with mobile phones.
If users don't want their mobile phone number to be visible in the directory, but they still want to use it for
password reset, administrators should not populate it in the directory. Users should populate their
Authentication Phone attribute via the password reset registration portal. Administrators can see this
information in the user's profile, but it's not published elsewhere.
To work properly, phone numbers must be in the format +CountryCode PhoneNumber, for example, +1
4255551234.
NOTE
There needs to be a space between the country code and the phone number.
Password reset does not support phone extensions. Even in the +1 4255551234X12345 format, extensions are removed
before the call is placed.
Text message
An SMS is sent to the mobile phone number containing a verification code. Enter the verification code provided in
the sign-in interface to continue.
Phone call
An automated voice call is made to the phone number you provide. Answer the call and press # in the phone
keypad to authenticate
IMPORTANT
Starting in March of 2019 the phone call options will not be available to MFA and SSPR users in free/trial Azure AD tenants.
SMS messages are not impacted by this change. Phone call will continue to be available to users in paid Azure AD tenants.
This change only impacts free/trial Azure AD tenants.
Office phone
An automated voice call is made to the phone number you provide. Answer the call and presses # in the phone
keypad to authenticate.
4255551234.
The office phone attribute is managed by your administrator.
IMPORTANT
NOTE
Troubleshooting phone options

Common problems related to authentication methods using a phone number:
Blocked caller ID on a single device
Troubleshoot device
Wrong phone number, incorrect country code, home phone number versus work phone number
Troubleshoot user object and configured authentication methods. Ensure correct phone numbers are
registered.
Wrong PIN entered
Confirm user has used the correct PIN registered in Azure MFA Server.
Call forwarded to voicemail
Ensure user has phone turned on and that service is available in their area or use alternate method.
User is blocked
Have administrator unblock the user in the Azure portal.
SMS is not subscribed on the device
Have the user change methods or activate SMS on the device.
Faulty telecom providers (No phone input detected, missing DTMF tones issues, blocked caller ID on multiple
devices, or blocked SMS across multiple devices)
Microsoft uses multiple telecom providers to route phone calls and SMS messages for authentication. If
you are seeing any of the above issues have a user attempt to use the method at least 5 times within 5
minutes and have that user's information available when contacting Microsoft support.
App Passwords
Certain non-browser apps do not support multi-factor authentication, if a user has been enabled for multi-factor
authentication and attempt to use non-browser apps, they are unable to authenticate. An app password allows
users to continue to authenticate
If you enforce Multi-Factor Authentication through Conditional Access policies and not through per-user MFA,
you cannot create app passwords. Applications that use Conditional Access policies to control access do not need
app passwords.
If your organization is federated for SSO with Azure AD and you are going to be using Azure MFA, then be aware
of the following details:
The app password is verified by Azure AD and therefore bypasses federation. Federation is only used when
setting up app passwords. For federated (SSO ) users, passwords are stored in the organizational ID. If the user
leaves the company, that info has to flow to organizational ID using DirSync. Account disable/deletion may
take up to three hours to sync, which delays disable/deletion of app passwords in Azure AD.
On-premises Client Access Control settings are not honored by App Password.
No on-premises authentication logging/auditing capability is available for app passwords.
Certain advanced architectural designs may require using a combination of organizational username and
passwords and app passwords when using two-step verification with clients, depending on where they
authenticate. For clients that authenticate against an on-premises infrastructure, you would use an
organizational username and password. For clients that authenticate against Azure AD, you would use the app
password.
By default, users cannot create app passwords. If you need to allow users to create app passwords, select the
Allow users to create app passwords to sign into non-browser applications option under service
settings.
Next steps
Enable self service password reset for your organization
Enable Azure Multi-Factor Authentication for your organization
Enable combined registration in your tenant
End-user authentication method configuration documentation
What is passwordless?
Multi-factor authentication (MFA) is a great way to secure your organization, but users get frustrated with the
additional layer on top of having to remember their passwords. Passwordless authentication methods are more
convenient because the password is removed and replaced with something you have plus something you are or
something you know.
SOMETHING YOU HAVE SOMETHING YOU ARE OR KNOW
Passwordless Phone or security key Biometric or PIN
Each organization has different needs when it comes to authentication. Microsoft currently offers Windows Hello,
our for Windows PCs. We are adding the Microsoft Authenticator app and FIDO2 security keys to the
passwordless family.
Microsoft Authenticator App

Allow your employee’s phone to become a passwordless authentication method. You may already be using the
Microsoft Authenticator App as a convenient multi-factor authentication option in addition to a password. But now,
it’s available as a passwordless option.
It turns any iOS or Android phone into a strong, passwordless credential by allowing users to sign in to any
platform or browser by getting a notification to their phone, matching a number displayed on the screen to the one
on their phone and then using their biometric (touch or face) or PIN to confirm.
FIDO2 security keys
FIDO2 security keys are an unphishable standards-based passwordless authentication method that can come in
any form factor. Fast Identity Online (FIDO ) is an open standard for passwordless authentication. It allows users
and organizations to leverage the standard to sign in to their resources without a username or password using an
external security key or a platform key built into a device.
For public preview, employees can use external security keys to sign in to their Azure Active Directory Joined
Windows 10 machines (running version 1809 or higher) and get single-sign on to their cloud resources. They can
also sign in to supported browsers.
While there are many keys that are FIDO2 certified by the FIDO Alliance, Microsoft requires some optional
extensions of the FIDO2 CTAP specification to be implemented by the vendor to ensure maximum security and the
best experience.
A security key MUST implement the following features and extensions from the FIDO2 CTAP protocol to be
Microsoft-compatible:
WHY IS THIS FEATURE OR EX TENSION

# FEATURE / EX TENSION TRUST REQUIRED?
1 Resident key This feature enables the security key to

be portable, where your credential is
stored on the security key.
2 Client pin This feature enables you to protect your

credentials with a second factor and
applies to security keys that do not
have a user interface.
WHY IS THIS FEATURE OR EX TENSION
# FEATURE / EX TENSION TRUST REQUIRED?
3 hmac-secret This extension ensures you can sign in

to your device when it's off-line or in
airplane mode.
4 Multiple accounts per RP This feature ensures you can use the
same security key across multiple
services like Microsoft Account and
Azure Active Directory.
The following providers offer FIDO2 security keys of different form factors that are known to be compatible with
the paswordless experience. Microsoft encourages customers to evaluate the security properties of these keys by
contacting the vendor as well as FIDO Alliance.
PROVIDER CONTACT
Yubico https://www.yubico.com/support/contact/
Feitian https://www.ftsafe.com/about/Contact_Us
HID https://www.hidglobal.com/contact-us
Ensurity https://ensurity.com/contact-us.html
eWBM https://www.ewbm.com/page/sub1_5
If you are a vendor and want to get your device on this list, contact Fido2Request@Microsoft.com.
FIDO2 security keys are a great option for enterprises who are very security sensitive or have scenarios or
employees who aren’t willing or able to use their phone as a second factor.
What scenarios work with the preview?

Administrators can enable passwordless authentication methods for their tenant
Administrators can target all users or select users/groups within their tenant for each method
End users can register and manage these passwordless authentication methods in their account portal
End users can sign in with these passwordless authentication methods
Microsoft Authenticator App: Will work in scenarios where Azure AD authentication is used, including
across all browsers, during Windows 10 Out Of Box (OOBE ) setup, and with integrated mobile apps on
any operating system.
Security keys: Will work on lock screen for Windows 10 version 1809 or higher and the web in
supported browsers like Microsoft Edge.
Next steps
Enable FIDO2 security key passwordlesss options in your organization
Enable phone-based passwordless options in your organization
External Links
FIDO Alliance
FIDO2 CTAP specification
Combined security information registration (preview)
Before combined registration, users registered authentication methods for Azure Multi-Factor Authentication and
self-service password reset (SSPR ) separately. People were confused that similar methods were used for Multi-
Factor Authentication and SSPR but they had to register for both features. Now, with combined registration, users
can register once and get the benefits of both Multi-Factor Authentication and SSPR.
Before enabling the new experience, review this administrator-focused documentation and the user-focused
documentation to ensure you understand the functionality and effect of this feature. Base your training on the user
documentation to prepare your users for the new experience and help to ensure a successful rollout.
Azure AD combined security information registration is not currently available to national clouds like Azure US
Government, Azure Germany, or Azure China 21Vianet.
Combined security information registration for Multi-Factor Authentication and Azure Active Directory (Azure AD) self-service
password reset is a public preview feature of Azure AD. For more information about previews, see Supplemental Terms of Use for
Microsoft Azure Previews.
IMPORTANT
Users who are enabled for both the original preview and the enhanced combined registration experience will see the new
behavior. Users who are enabled for both experiences will see only the new My Profile experience. The new My Profile aligns
with the look and feel of combined registration and provides a seamless experience for users. Users can see My Profile by
going to https://myprofile.microsoft.com.
My Profile pages are localized based on the language settings of the computer accessing the page. Microsoft
stores the most recent language used in the browser cache, so subsequent attempts to access the pages will
continue to render in the last language used. If you clear the cache, the pages will re-render. If you want to force a
specific language, you can add ?lng=<language> to the end of the URL, where <language> is the code of the
language you want to render.
Methods available in combined registration

Combined registration supports the following authentication methods and actions:
REGISTER CHANGE DELETE
Microsoft Authenticator Yes (maximum of 5) No Yes
Other authenticator app Yes (maximum of 5) No Yes
Hardware token No No Yes
Phone Yes Yes Yes
Alternate phone Yes Yes Yes
Office phone No No No
Email Yes Yes Yes
Security questions Yes No Yes

REGISTER CHANGE DELETE
App passwords Yes No Yes
NOTE
App passwords are available only to users who have been enforced for Multi-Factor Authentication. App passwords are not
available to users who are enabled for Multi-Factor Authentication via a Conditional Access policy.
Users can set one of the following options as the default Multi-Factor Authentication method:
Microsoft Authenticator – notification.
Authenticator app or hardware token – code.
Phone call.
Text message.
As we continue to add more authentication methods to Azure AD, those methods will be available in combined
registration.
Combined registration modes

There are two modes of combined registration: interrupt and manage.
Interrupt mode is a wizard-like experience, presented to users when they register or refresh their security
info at sign-in.
Manage mode is part of the user profile and allows users to manage their security info.
For both modes, users who have previously registered a method that can be used for Multi-Factor Authentication
will need to perform Multi-Factor Authentication before they can access their security info.
Interrupt mode
Combined registration respects both Multi-Factor Authentication and SSPR policies, if both are enabled for your
tenant. These policies control whether a user is interrupted for registration during sign-in and which methods are
available for registration.
Here are several scenarios in which users might be prompted to register or refresh their security info:
Multi-Factor Authentication registration enforced through Identity Protection: Users are asked to register
during sign-in. They register Multi-Factor Authentication methods and SSPR methods (if the user is enabled
for SSPR ).
Multi-Factor Authentication registration enforced through per-user Multi-Factor Authentication: Users are
asked to register during sign-in. They register Multi-Factor Authentication methods and SSPR methods (if the
user is enabled for SSPR ).
Multi-Factor Authentication registration enforced through Conditional Access or other policies: Users are asked
to register when they use a resource that requires Multi-Factor Authentication. They register Multi-Factor
Authentication methods and SSPR methods (if the user is enabled for SSPR ).
SSPR registration enforced: Users are asked to register during sign-in. They register only SSPR methods.
SSPR refresh enforced: Users are required to review their security info at an interval set by the admin. Users
are shown their info and can confirm the current info or make changes if needed.
When registration is enforced, users are shown the minimum number of methods needed to be compliant with
both Multi-Factor Authentication and SSPR policies, from most to least secure.
For example:
A user is enabled for SSPR. The SSPR policy required two methods to reset and has enabled mobile app code,
email, and phone.
This user is required to register two methods.
The user is shown authenticator app and phone by default.
The user can choose to register email instead of authenticator app or phone.
This flowchart describes which methods are shown to a user when interrupted to register during sign-in:
If you have both Multi-Factor Authentication and SSPR enabled, we recommend that you enforce Multi-Factor
Authentication registration.
If the SSPR policy requires users to review their security info at regular intervals, users are interrupted during
sign-in and shown all their registered methods. They can confirm the current info if it's up-to-date, or they can
make changes if they need to.
Manage mode
Users can access manage mode by going to https://aka.ms/mysecurityinfo or by selecting Security info from My
Profile. From there, users can add methods, delete or change existing methods, change the default method, and
more.
Key usage scenarios

Set up security info during sign-in
An admin has enforced registration.
A user has not set up all required security info and goes to the Azure portal. After entering the user name and
password, the user is prompted to set up security info. The user then follows the steps shown in the wizard to set
up the required security info. If your settings allow it, the user can choose to set up methods other than those
shown by default. After completing the wizard, users review the methods they set up and their default method for
Multi-Factor Authentication. To complete the setup process, the user confirms the info and continues to the Azure
portal.
Set up security info from My Profile
An admin has not enforced registration.
A user who hasn't yet set up all required security info goes to https://myprofile.microsoft.com. The user selects
Security info in the left pane. From there, the user chooses to add a method, selects any of the methods available,
and follows the steps to set up that method. When finished, the user sees the method that was just set up on the
Security info page.
Delete security info from My Profile
A user who has previously set up at least one method navigates to https://aka.ms/mysecurityinfo. The user
chooses to delete one of the previously registered methods. When finished, the user no longer sees that method
on the Security info page.
Change the default method from My Profile
A user who has previously set up at least one method that can be used for Multi-Factor Authentication navigates
to https://aka.ms/mysecurityinfo. The user changes the current default method to a different default method.
When finished, the user sees the new default method on the Security info page.
Next steps
Enable combined registration in your tenant
SSPR and MFA usage and insights reporting
Available methods for Multi-Factor Authentication and SSPR
Configure self-service password reset
Configure Azure Multi-Factor Authentication
How it works: Azure AD self-service password reset
How does self-service password reset (SSPR ) work? What does that option mean in the interface? Continue
reading to find out more about Azure Active Directory (Azure AD ) SSPR.
Mobile app notification and Mobile app code as methods for Azure AD self-service password reset are public preview features of
Azure Active Directory. For more information about previews, see Supplemental Terms of Use for Microsoft Azure Previews
How does the password reset portal work?

When a user goes to the password reset portal, a workflow is kicked off to determine:
How should the page be localized?
Is the user account valid?
What organization does the user belong to?
Where is the user’s password managed?
Is the user licensed to use the feature?
Read through the following steps to learn about the logic behind the password reset page:
1. The user selects the Can't access your account link or goes directly to https://aka.ms/sspr.
Based on the browser locale, the experience is rendered in the appropriate language. The password
reset experience is localized into the same languages that Office 365 supports.
To view the password reset portal in a different localized language append "?mkt=" to the end of the
password reset URL with the example that follows localizing to Spanish
https://passwordreset.microsoftonline.com/?mkt=es-us.
2. The user enters a user ID and passes a captcha.
3. Azure AD verifies that the user is able to use this feature by doing the following checks:
Checks that the user has this feature enabled and has an Azure AD license assigned.
If the user does not have this feature enabled or have a license assigned, the user is asked to
contact their administrator to reset their password.
Checks that the user has the right authentication methods defined on their account in accordance with
administrator policy.
If the policy requires only one method, then it ensures that the user has the appropriate data
defined for at least one of the authentication methods enabled by the administrator policy.
If the authentication methods are not configured, then the user is advised to contact their
administrator to reset their password.
If the policy requires two methods, then it ensures that the user has the appropriate data defined
for at least two of the authentication methods enabled by the administrator policy.
If the authentication methods are not configured, then the user is advised to contact their
administrator to reset their password.
If an Azure administrator role is assigned to the user, then the strong two-gate password policy is
enforced. More information about this policy can be found in the section Administrator reset
policy differences.
Checks to see if the user’s password is managed on-premises (federated, pass-through authentication,
or password hash synchronized).
If writeback is deployed and the user’s password is managed on-premises, then the user is
allowed to proceed to authenticate and reset their password.
If writeback is not deployed and the user’s password is managed on-premises, then the user is
asked to contact their administrator to reset their password.
4. If it's determined that the user is able to successfully reset their password, then the user is guided through the
reset process.
If SSPR is enabled, you must select at least one of the following options for the authentication methods.
Sometimes you hear these options referred to as "gates." We highly recommend that you choose two or more
authentication methods so that your users have more flexibility in case they are unable to access one when
they need it. Additional details about the methods listed below can be found in the article What are authentication
methods?.
Mobile app notification (preview )
Mobile app code (preview )
Email
Mobile phone
Office phone
Security questions
Users can only reset their password if they have data present in the authentication methods that the administrator
has enabled.
IMPORTANT
WARNING
Accounts assigned Azure Administrator roles will be required to use methods as defined in the section Administrator reset
policy differences.
Number of authentication methods required
This option determines the minimum number of the available authentication methods or gates a user must go
through to reset or unlock their password. It can be set to either one or two.
Users can choose to supply more authentication methods if the administrator enables that authentication method.
If a user does not have the minimum required methods registered, they see an error page that directs them to
request that an administrator reset their password.
Mobile app and SSPR (Preview)
When using a mobile app, like the Microsoft Authenticator app, as a method for password reset, you should be
aware of the following caveats:
When administrators require one method be used to reset a password, verification code is the only option
available.
When administrators require two methods be used to reset a password, users are able to use EITHER
notification OR verification code in addition to any other enabled methods.
NUMBER OF METHODS REQUIRED TO

RESET ONE TWO
Mobile app features available Code Code or Notification
Users do not have the option to register their mobile app when registering for self-service password reset from
https://aka.ms/ssprsetup. Users can register their mobile app at https://aka.ms/mfasetup, or in the new security
info registration preview at https://aka.ms/setupsecurityinfo.
WARNING
You must enable the Converged registration for self-service password reset and Azure Multi-Factor Authentication (Public
preview) before users will be able to access the new experience at https://aka.ms/setupsecurityinfo.
Change authentication methods

If you start with a policy that has only one required authentication method for reset or unlock registered and you
change that to two methods, what happens?
NUMBER OF METHODS REGISTERED NUMBER OF METHODS REQUIRED RESULT
1 or more 1 Able to reset or unlock
1 2 Unable to reset or unlock
2 or more 2 Able to reset or unlock
If you change the types of authentication methods that a user can use, you might inadvertently stop users from
being able to use SSPR if they don't have the minimum amount of data available.
Example:
1. The original policy is configured with two authentication methods required. It uses only the office phone
number and the security questions.
2. The administrator changes the policy to no longer use the security questions, but allows the use of a mobile
phone and an alternate email.
3. Users without the mobile phone or alternate email fields populated can't reset their passwords.
Registration
Require users to register when they sign in
Enabling this option requires a user to complete the password reset registration if they sign in to any applications
using Azure AD. This workflow includes the following applications:
Office 365
Azure portal
Access Panel
Federated applications
Custom applications using Azure AD
When requiring registration is disabled, users can manually register. They can either visit https://aka.ms/ssprsetup
or select the Register for password reset link under the Profile tab in the Access Panel.
NOTE
Users can dismiss the password reset registration portal by selecting cancel or by closing the window. But they are
prompted to register each time they sign in until they complete their registration.
This interrupt doesn't break the user's connection if they are already signed in.
Set the number of days before users are asked to reconfirm their authentication information
This option determines the period of time between setting and reconfirming authentication information and is
available only if you enable the Require users to register when signing in option.
Valid values are 0 to 730 days, with "0" meaning users are never asked to reconfirm their authentication
information.
Notifications
Notify users on password resets
If this option is set to Yes, then users resetting their password receive an email notifying them that their password
has been changed. The email is sent via the SSPR portal to their primary and alternate email addresses that are
on file in Azure AD. No one else is notified of the reset event.
Notify all admins when other admins reset their passwords
If this option is set to Yes, then all administrators receive an email to their primary email address on file in Azure
AD. The email notifies them that another administrator has changed their password by using SSPR.
Example: There are four administrators in an environment. Administrator A resets their password by using SSPR.
Administrators B, C, and D receive an email alerting them of the password reset.
If you install, configure, and enable Azure AD Connect, you have the following additional options for on-premises
integrations. If these options are grayed out, then writeback has not been properly configured. For more
information, see Configuring password writeback.
This page provides you a quick status of the on-premises writeback client, one of the following messages is
displayed based on the current configuration:
Your On-premises writeback client is up and running.
Azure AD is online and is connected to your on-premises writeback client. However, it looks like the installed
version of Azure AD Connect is out-of-date. Consider Upgrading Azure AD Connect to ensure that you have
the latest connectivity features and important bug fixes.
Unfortunately, we can’t check your on-premises writeback client status because the installed version of Azure
AD Connect is out-of-date. Upgrade Azure AD Connect to be able to check your connection status.
Unfortunately, it looks like we can't connect to your on-premises writeback client right now. Troubleshoot
Azure AD Connect to restore the connection.
Unfortunately, we can't connect to your on-premises writeback client because password writeback has not
been properly configured. Configure password writeback to restore the connection.
Unfortunately, it looks like we can't connect to your on-premises writeback client right now. This may be due to
temporary issues on our end. If the problem persists, Troubleshoot Azure AD Connect to restore the
connection.
Write back passwords to your on-premises directory
This control determines whether password writeback is enabled for this directory. If writeback is on, it indicates
the status of the on-premises writeback service. This control is useful if you want to temporarily disable password
writeback without having to reconfigure Azure AD Connect.
If the switch is set to Yes, then writeback is enabled, and federated, pass-through authentication, or password
hash synchronized users are able to reset their passwords.
If the switch is set to No, then writeback is disabled, and federated, pass-through authentication, or password
hash synchronized users are not able to reset their passwords.
Allow users to unlock accounts without resetting their password
This control designates whether users who visit the password reset portal should be given the option to unlock
their on-premises Active Directory accounts without having to reset their password. By default, Azure AD unlocks
accounts when it performs a password reset. You use this setting to separate those two operations.
If set to Yes, then users are given the option to reset their password and unlock the account, or to unlock their
account without having to reset the password.
If set to No, then users are only be able to perform a combined password reset and account unlock operation.
On-premises Active Directory password filters
Azure AD self-service password reset performs the equivalent of an admin-initiated password reset in Active
Directory. If you are using a third-party password filter to enforce custom password rules, and you require that
this password filter is checked during Azure AD self-service password reset, ensure that the third-party password
filter solution is configured to apply in the admin password reset scenario. Azure AD password protection for
Windows Server Active Directory is supported by default.
Password reset for B2B users

Password reset and change are fully supported on all business-to-business (B2B ) configurations. B2B user
password reset is supported in the following three cases:
Users from a partner organization with an existing Azure AD tenant: If the organization you're
partnering with has an existing Azure AD tenant, we respect whatever password reset policies are enabled on
that tenant. For password reset to work, the partner organization just needs to make sure that Azure AD
SSPR is enabled. There is no additional charge for Office 365 customers, and it can be enabled by following
the steps in our Get started with password management guide.
Users who sign up through self-service sign-up: If the organization you're partnering with used the self-
service sign-up feature to get into a tenant, we let them reset the password with the email they registered.
B2B users: Any new B2B users created by using the new Azure AD B2B capabilities will also be able to reset
their passwords with the email they registered during the invite process.
To test this scenario, go to https://passwordreset.microsoftonline.com with one of these partner users. If they have
an alternate email or authentication email defined, password reset works as expected.
NOTE
Microsoft accounts that have been granted guest access to your Azure AD tenant, such as those from Hotmail.com,
Outlook.com, or other personal email addresses, are not able to use Azure AD SSPR. They need to reset their password by
using the information found in the When you can't sign in to your Microsoft account article.
Next steps
The following articles provide additional information regarding password reset through Azure AD:
How do I complete a successful rollout of SSPR?
Reset or change your password
Register for self-service password reset
Do you have a licensing question?
What data is used by SSPR and what data should you populate for your users?
What authentication methods are available to users?
What are the policy options with SSPR?
What is password writeback and why do I care about it?
How do I report on activity in SSPR?
What are all of the options in SSPR and what do they mean?
I think something is broken. How do I troubleshoot SSPR?
I have a question that was not covered somewhere else
Customize the Azure AD functionality for self-service
password reset
IT professionals who want to deploy self-service password reset (SSPR ) in Azure Active directory (Azure AD ) can
customize the experience to match their users' needs.
Customize the "Contact your administrator" link

Self-service password reset users have a "Contact your administrator" link available to them in the password reset
portal. If a user selects this link, it will do one of two things:
If left in the default state:
Email is sent to your administrators and asks them to provide assistance in changing the user's password.
See the sample email below.
If customized:
Sends your user to a webpage or email address specified by the administrator for assistance.
TIP
If you customize this, we recommend setting this to something users are already familiar with for support
WARNING
If you customize this setting with an email address and account that needs a password reset the user may be unable to ask
for assistance.
Sample email
The contact email is sent to the following recipients in the following order:
1. If the password administrator role is assigned, administrators with this role are notified.
2. If no password administrators are assigned, then administrators with the user administrator role are notified.
3. If neither of the previous roles are assigned, then the global administrators are notified.
In all cases, a maximum of 100 recipients are notified.
To find out more about the different administrator roles and how to assign them, see Assigning administrator roles
in Azure Active Directory.
Disable "Contact your administrator" emails
If your organization does not want to notify administrators about password reset requests, you can enable the
following configuration:
Enable self-service password reset for all end users. This option is under Password Reset > Properties. If you
don't want users to reset their own passwords, you can scope access to an empty group. We don't recommend
this option.
Customize the helpdesk link to provide a web URL or mailto: address that users can use to get assistance. This
option is under Password Reset > Customization > Custom helpdesk email or URL.
Customize the AD FS sign-in page for SSPR

Active Directory Federation Services (AD FS ) administrators can add a link to their sign-in page by using the
guidance found in the Add sign-in page description article.
To add a link to the AD FS sign-in page, use the following command on your AD FS server. Users can use this page
to enter the SSPR workflow.
Set-ADFSGlobalWebContent -SigninPageDescriptionText "<p><A href='https://passwordreset.microsoftonline.com'

target='_blank'>Can’t access your account?</A></p>"
Customize the sign-in page and access panel look and feel
You can customize the sign-in page. You can add a logo that appears along with the image that fits your company
branding.
The graphics you choose are shown in the following circumstances:
After a user enters their username
If the user accesses the customized URL:
By passing the whr parameter to the password reset page, like
https://login.microsoftonline.com/?whr=contoso.com
By passing the username parameter to the password reset page, like
https://login.microsoftonline.com/?username=admin@contoso.com
Find details on how to configure company branding in the article Add company branding to your sign-in page in
Azure AD.
Directory name
You can change the directory name attribute under Azure Active Directory > Properties. You can show a
friendly organization name that is seen in the portal and in the automated communications. This option is the most
visible in automated emails in the forms that follow:
The friendly name in the email, for example “Microsoft on behalf of CONTOSO demo”
The subject line in the email, for example “CONTOSO demo account email verification code”
Next steps
Password policies and restrictions in Azure Active
Directory
This article describes the password policies and complexity requirements associated with user accounts in your
Azure Active Directory (Azure AD ) tenant.
Administrator reset policy differences

Microsoft enforces a strong default two-gate password reset policy for any Azure administrator role this
policy may be different from the one you have defined for your users and cannot be changed. You should always
test password reset functionality as a user without any Azure administrator roles assigned.
With a two-gate policy, administrators don't have the ability to use security questions.
The two-gate policy requires two pieces of authentication data, such as an email address, authenticator app, or
a phone number. A two-gate policy applies in the following circumstances:
All the following Azure administrator roles are affected:
Helpdesk administrator
Service support administrator
Billing administrator
Partner Tier1 Support
Partner Tier2 Support
Exchange administrator
Skype for Business administrator
User administrator
Directory writers
Global administrator or company administrator
SharePoint administrator
Compliance administrator
Application administrator
Security administrator
Privileged role administrator
Intune administrator
Application proxy service administrator
Dynamics 365 administrator
Power BI service administrator
Authentication administrator
Privileged Authentication administrator
If 30 days have elapsed in a trial subscription; or
A vanity domain is present, such as contoso.com; or
Azure AD Connect is synchronizing identities from your on-premises directory
Exceptions
A one-gate policy requires one piece of authentication data, such as an email address or phone number. A one-
gate policy applies in the following circumstances:
It's within the first 30 days of a trial subscription; or
A vanity domain isn't present (*.onmicrosoft.com); and
Azure AD Connect isn't synchronizing identities
UserPrincipalName policies that apply to all user accounts

Every user account that needs to sign in to Azure AD must have a unique user principal name (UPN ) attribute
value associated with their account. The following table outlines the policies that apply to both on-premises
Active Directory user accounts that are synchronized to the cloud and to cloud-only user accounts:
PROPERTY USERPRINCIPALNAME REQUIREMENTS
Characters allowed A–Z

a-z
0–9
'.-_!#^~
Characters not allowed Any "@" character that's not separating the username
from the domain.
Can't contain a period character "." immediately
preceding the "@" symbol
Length constraints The total length must not exceed 113 characters
There can be up to 64 characters before the "@"
symbol
There can be up to 48 characters after the "@" symbol
Password policies that only apply to cloud user accounts

The following table describes the password policy settings applied to user accounts that are created and managed
in Azure AD:
PROPERTY REQUIREMENTS
Characters allowed A–Z

a-z
0–9
@#$%^&*-_!+=[]{}|\:‘,.?/`~"();
blank space
Characters not allowed Unicode characters.

Cannot contain a dot character "." immediately
preceding the "@" symbol”.
PROPERTY REQUIREMENTS
Password restrictions A minimum of 8 characters and a maximum of 256

characters.
Requires three out of four of the following:
Lowercase characters.
Uppercase characters.
Numbers (0-9).
Symbols (see the previous password
restrictions).
Password expiry duration Default value: 90 days.

The value is configurable by using the
Set-MsolPasswordPolicy cmdlet from the Azure
Active Directory Module for Windows PowerShell.
Password expiry notification Default value: 14 days (before password expires).

The value is configurable by using the
Set-MsolPasswordPolicy cmdlet.
Password expiry Default value: false days (indicates that password

expiry is enabled).
The value can be configured for individual user
accounts by using the Set-MsolUser cmdlet.
Password change history The last password can't be used again when the user changes
a password.
Password reset history The last password can be used again when the user resets a
forgotten password.
Account lockout After 10 unsuccessful sign-in attempts with the wrong

password, the user is locked out for one minute. Further
incorrect sign-in attempts lock out the user for increasing
durations of time. Smart lockout tracks the last three bad
password hashes to avoid incrementing the lockout counter
for the same password. If someone enters the same bad
password multiple times, this behavior will not cause the
account to lockout.
Set password expiration policies in Azure AD

A global administrator or user administrator for a Microsoft cloud service can use the Microsoft Azure AD
Module for Windows PowerShell to set user passwords not to expire. You can also use Windows PowerShell
cmdlets to remove the never-expires configuration or to see which user passwords are set to never expire.
This guidance applies to other providers, such as Intune and Office 365, which also rely on Azure AD for identity
and directory services. Password expiration is the only part of the policy that can be changed.
NOTE
Only passwords for user accounts that are not synchronized through directory synchronization can be configured to not
expire. For more information about directory synchronization, see Connect AD with Azure AD.
Set or check the password policies by using PowerShell
To get started, you need to download and install the Azure AD PowerShell module. After you have it installed,
you can use the following steps to configure each field.
Check the expiration policy for a password
1. Connect to Windows PowerShell by using your user administrator or company administrator credentials.
2. Execute one of the following commands:
To see if a single user’s password is set to never expire, run the following cmdlet by using the UPN (for
example, aprilr@contoso.onmicrosoft.com) or the user ID of the user you want to check:
Get-AzureADUser -ObjectId <user ID> | Select-Object @{N="PasswordNeverExpires";E={$_.PasswordPolicies

-contains "DisablePasswordExpiration"}}
To see the Password never expires setting for all users, run the following cmdlet:
Get-AzureADUser -All $true | Select-Object UserPrincipalName, @{N="PasswordNeverExpires";E=

{$_.PasswordPolicies -contains "DisablePasswordExpiration"}}
Set a password to expire

To set the password of one user so that the password expires, run the following cmdlet by using the
UPN or the user ID of the user:
Set-AzureADUser -ObjectId <user ID> -PasswordPolicies None
To set the passwords of all users in the organization so that they expire, use the following cmdlet:
Get-AzureADUser -All $true | Set-AzureADUser -PasswordPolicies None
Set a password to never expire

To set the password of one user to never expire, run the following cmdlet by using the UPN or the user
ID of the user:
Set-AzureADUser -ObjectId <user ID> -PasswordPolicies DisablePasswordExpiration
To set the passwords of all the users in an organization to never expire, run the following cmdlet:
Get-AzureADUser -All $true | Set-AzureADUser -PasswordPolicies DisablePasswordExpiration

WARNING
Passwords set to -PasswordPolicies DisablePasswordExpiration still age based on the pwdLastSet attribute.
If you set the user passwords to never expire and then 90+ days go by, the passwords expire. Based on the
pwdLastSet attribute, if you change the expiration to -PasswordPolicies None , all passwords that have a
pwdLastSet older than 90 days require the user to change them the next time they sign in. This change can affect
a large number of users.
Next steps
The following articles provide additional information about password reset through Azure AD:
Reset or change your password.
Register for self-service password reset.
Licensing requirements for Azure AD self-service
password reset
Azure Active Directory (Azure AD ) comes in several editions: Free, Premium P1, and Premium P2. There are
several different features that make up self-service password reset, including change, reset, unlock, and writeback,
that are available in the different editions of Azure AD. This article tries to explain the differences. More details of
the features included in each Azure AD edition can be found on the Azure Active Directory pricing page.
Compare editions and features

Azure AD self-service password reset is licensed per user, to maintain compliance organizations are required to
assign the appropriate license to their users.
Self-Service Password Change for cloud users
I am a cloud-only user and know my password.
I would like to change my password to something new.
This functionality is included in all editions of Azure AD.
Self-Service Password Reset for cloud users
I am a cloud-only user and have forgotten my password.
I would like to reset my password to something I know.
This functionality is included in Azure AD Premium P1 or P2, or Microsoft 365 Business.
Self-Service Password Reset/Change/Unlock with on-premises writeback
I am a hybrid user my on-premises Active Directory user account is synchronized with my Azure AD
account using Azure AD Connect. I would like to change my password, have forgotten my password, or
been locked out.
I would like to change my password or reset it to something I know, or unlock my account, and
have that change synchronized back to on-premises Active Directory.
This functionality is included in Azure AD Premium P1 or P2, or Microsoft 365 Business.
WARNING
Standalone Office 365 licensing plans don't support "Self-Service Password Reset/Change/Unlock with on-premises
writeback" and require a plan that includes Azure AD Premium P1, Premium P2, or Microsoft 365 Business for this
functionality to work.
Additional licensing information, including costs, can be found on the following pages:
Azure Active Directory pricing site
Azure Active Directory features and capabilities
Enterprise Mobility + Security
Microsoft 365 Enterprise
Microsoft 365 Business service description
Enable group or user-based licensing

Azure AD now supports group-based licensing. Administrators can assign licenses in bulk to a group of users,
rather than assigning them one at a time. For more information, see Assign, verify, and resolve problems with
licenses.
Some Microsoft services are not available in all locations. Before a license can be assigned to a user, the
administrator must specify the Usage location property on the user. Assignment of licenses can be done under
the User > Profile > Settings section in the Azure portal. When you use group license assignment, any users
without a usage location specified inherit the location of the directory.
Next steps
What is password writeback?
Having a cloud-based password reset utility is great but most companies still have an on-premises directory where
their users exist. How does Microsoft support keeping traditional on-premises Active Directory (AD ) in sync with
password changes in the cloud? Password writeback is a feature enabled with Azure AD Connect that allows
password changes in the cloud to be written back to an existing on-premises directory in real time.
Password writeback is supported in environments that use:
Active Directory Federation Services
Password hash synchronization
Pass-through authentication
WARNING
Password writeback will stop working for customers who are using Azure AD Connect versions 1.0.8641.0 and older when
the Azure Access Control service (ACS) is retired on November 7th, 2018. Azure AD Connect versions 1.0.8641.0 and older
will no longer allow password writeback at that time because they depend on ACS for that functionality.
To avoid a disruption in service, upgrade from a previous version of Azure AD Connect to a newer version, see the article
Azure AD Connect: Upgrade from a previous version to the latest
Password writeback provides:

Enforcement of on-premises Active Directory password policies: When a user resets their password, it is
checked to ensure it meets your on-premises Active Directory policy before committing it to that directory. This
review includes checking the history, complexity, age, password filters, and any other password restrictions that
you have defined in local Active Directory.
Zero-delay feedback: Password writeback is a synchronous operation. Your users are notified immediately if
their password did not meet the policy or could not be reset or changed for any reason.
Supports password changes from the access panel and Office 365: When federated or password hash
synchronized users come to change their expired or non-expired passwords, those passwords are written back
to your local Active Directory environment.
Supports password writeback when an admin resets them from the Azure portal: Whenever an admin
resets a user’s password in the Azure portal, if that user is federated or password hash synchronized, the
password is written back to on-premises. This functionality is currently not supported in the Office admin
portal.
Doesn’t require any inbound firewall rules: Password writeback uses an Azure Service Bus relay as an
underlying communication channel. All communication is outbound over port 443.
NOTE
Administrator accounts that exist within protected groups in on-premises AD can be used with password writeback.
Administrators can change their password in the cloud but cannot use password reset to reset a forgotten password. For
more information about protected groups, see Protected accounts and groups in Active Directory.
Licensing requirements for password writeback

Self-Service Password Reset/Change/Unlock with on-premises writeback is a premium feature of Azure
AD. For more information about licensing, see the Azure Active Directory pricing site.
To use password writeback, you must have one of the following licenses assigned on your tenant:
Azure AD Premium P1
Azure AD Premium P2
Enterprise Mobility + Security E3 or A3
Microsoft 365 E3 or A3
Microsoft 365 F1
Microsoft 365 Business
WARNING
writeback" and require that you have one of the preceding plans for this functionality to work.
How password writeback works

When a federated or password hash synchronized user attempts to reset or change their password in the cloud,
the following actions occur:
1. A check is performed to see what type of password the user has. If the password is managed on-premises:
A check is performed to see if the writeback service is up and running. If it is, the user can proceed.
If the writeback service is down, the user is informed that their password can't be reset right now.
2. Next, the user passes the appropriate authentication gates and reaches the Reset password page.
3. The user selects a new password and confirms it.
4. When the user selects Submit, the plaintext password is encrypted with a symmetric key created during the
writeback setup process.
5. The encrypted password is included in a payload that gets sent over an HTTPS channel to your tenant-
specific service bus relay (that is set up for you during the writeback setup process). This relay is protected
by a randomly generated password that only your on-premises installation knows.
6. After the message reaches the service bus, the password-reset endpoint automatically wakes up and sees
that it has a reset request pending.
7. The service then looks for the user by using the cloud anchor attribute. For this lookup to succeed:
The user object must exist in the Active Directory connector space.
The user object must be linked to the corresponding metaverse (MV ) object.
The user object must be linked to the corresponding Azure Active Directory connector object.
The link from the Active Directory connector object to the MV must have the synchronization rule
Microsoft.InfromADUserAccountEnabled.xxx on the link.
When the call comes in from the cloud, the synchronization engine uses the cloudAnchor attribute to look
up the Azure Active Directory connector space object. It then follows the link back to the MV object, and
then follows the link back to the Active Directory object. Because there can be multiple Active Directory
objects (multi-forest) for the same user, the sync engine relies on the
Microsoft.InfromADUserAccountEnabled.xxx link to pick the correct one.
8. After the user account is found, an attempt to reset the password directly in the appropriate Active Directory
forest is made.
9. If the password set operation is successful, the user is told their password has been changed.
NOTE
If the user's password hash is synchronized to Azure AD by using password hash synchronization, there is a chance
that the on-premises password policy is weaker than the cloud password policy. In this case, the on-premises policy is
enforced. This policy ensures that your on-premises policy is enforced in the cloud, no matter if you use password
hash synchronization or federation to provide single sign-on.
10. If the password set operation fails, an error prompts the user to try again. The operation might fail because:
The service was down.
The password they selected did not meet the organization's policies.
Unable to find the user in local Active Directory.
The error messages provide guidance to users so they can attempt to resolve without administrator
intervention.
Password writeback security

Password writeback is a highly secure service. To ensure your information is protected, a four-tiered security
model is enabled as the following describes:
Tenant-specific service-bus relay
When you set up the service, a tenant-specific service bus relay is set up that's protected by a randomly
generated strong password that Microsoft never has access to.
Locked down, cryptographically strong, password encryption key
After the service bus relay is created, a strong symmetric key is created that is used to encrypt the
password as it comes over the wire. This key only lives in your company's secret store in the cloud, which
is heavily locked down and audited, just like any other password in the directory.
Industry standard Transport Layer Security (TLS )
1. When a password reset or change operation occurs in the cloud, the plaintext password is encrypted
with your public key.
2. The encrypted password is placed into an HTTPS message that is sent over an encrypted channel by
using Microsoft SSL certs to your service bus relay.
3. After the message arrives in the service bus, your on-premises agent wakes up and authenticates to the
service bus by using the strong password that was previously generated.
4. The on-premises agent picks up the encrypted message and decrypts it by using the private key.
5. The on-premises agent attempts to set the password through the AD DS SetPassword API. This step is
what allows enforcement of your Active Directory on-premises password policy (such as the complexity,
age, history, and filters) in the cloud.
Message expiration policies
If the message sits in service bus because your on-premises service is down, it times out and is removed
after several minutes. The time-out and removal of the message increases security even further.
Password writeback encryption details
After a user submits a password reset, the reset request goes through several encryption steps before it arrives in
your on-premises environment. These encryption steps ensure maximum service reliability and security. They are
described as follows:
Step 1: Password encryption with 2048-bit RSA Key: After a user submits a password to be written back to
on-premises, the submitted password itself is encrypted with a 2048-bit RSA key.
Step 2: Package-level encryption with AES -GCM: The entire package, the password plus the required
metadata, is encrypted by using AES -GCM. This encryption prevents anyone with direct access to the
underlying ServiceBus channel from viewing or tampering with the contents.
Step 3: All communication occurs over TLS/SSL: All the communication with ServiceBus happens in an
SSL/TLS channel. This encryption secures the contents from unauthorized third parties.
Automatic key roll over every six months: All keys roll over every six months, or every time password
writeback is disabled and then re-enabled on Azure AD Connect, to ensure maximum service security and
safety.
Password writeback bandwidth usage
Password writeback is a low -bandwidth service that only sends requests back to the on-premises agent under the
following circumstances:
Two messages are sent when the feature is enabled or disabled through Azure AD Connect.
One message is sent once every five minutes as a service heartbeat for as long as the service is running.
Two messages are sent each time a new password is submitted:
The first message is a request to perform the operation.
The second message contains the result of the operation, and is sent in the following circumstances:
Each time a new password is submitted during a user self-service password reset.
Each time a new password is submitted during a user password change operation.
Each time a new password is submitted during an admin-initiated user password reset (only from
the Azure admin portals).
Message size and bandwidth considerations
The size of each of the message described previously is typically under 1 KB. Even under extreme loads, the
password writeback service itself is consuming a few kilobits per second of bandwidth. Because each message is
sent in real time, only when required by a password update operation, and because the message size is so small,
the bandwidth usage of the writeback capability is too small to have a measurable impact.
Supported writeback operations

Passwords are written back in all the following situations:
Supported end-user operations
Any end-user self-service voluntary change password operation
Any end-user self-service force change password operation, for example, password expiration
Any end-user self-service password reset that originates from the password reset portal
Supported administrator operations
Any administrator self-service voluntary change password operation
Any administrator self-service force change password operation, for example, password expiration
Any administrator self-service password reset that originates from the password reset portal
Any administrator-initiated end-user password reset from the Azure portal
Unsupported writeback operations

Passwords are not written back in any of the following situations:
Unsupported end-user operations
Any end user resetting their own password by using PowerShell version 1, version 2, or the Azure AD
Graph API
Unsupported administrator operations
Any administrator-initiated end-user password reset from PowerShell version 1, version 2, or the Azure
AD Graph API
Any administrator-initiated end-user password reset from the Microsoft 365 admin center
WARNING
Use of the checkbox "User must change password at next logon" in on-premises Active Directory administrative tools like
Active Directory Users and Computers or the Active Directory Administrative Center is not supported. When changing a
password on-premises do not check this option.
Next steps
Enable password writeback using the Tutorial: Enabling password writeback
How it works: Azure Multi-Factor Authentication
The security of two-step verification lies in its layered approach. Compromising multiple authentication factors
presents a significant challenge for attackers. Even if an attacker manages to learn the user's password, it is useless
without also having possession of the additional authentication method. It works by requiring two or more of the
following authentication methods:
Something you know (typically a password)
Something you have (a trusted device that is not easily duplicated, like a phone)
Something you are (biometrics)
Azure Multi-Factor Authentication (MFA) helps safeguard access to data and applications while maintaining
simplicity for users. It provides additional security by requiring a second form of authentication and delivers strong
authentication via a range of easy to use authentication methods. Users may or may not be challenged for MFA
based on configuration decisions that an administrator makes.
How to get Multi-Factor Authentication?

Multi-Factor Authentication comes as part of the following offerings:
Azure Active Directory Premium or Microsoft 365 Business - Full featured use of Azure Multi-Factor
Authentication using Conditional Access policies to require multi-factor authentication.
Azure AD Free or standalone Office 365 licenses - Use pre-created Conditional Access baseline protection
policies to require multi-factor authentication for your users and administrators.
Azure Active Directory Global Administrators - A subset of Azure Multi-Factor Authentication
capabilities are available as a means to protect global administrator accounts.
NOTE
New customers may no longer purchase Azure Multi-Factor Authentication as a standalone offering effective September 1st,
2018. Multi-factor authentication will continue to be an available feature in Azure AD Premium licenses.
Supportability
Since most users are accustomed to using only passwords to authenticate, it is important that your organization
communicates to all users regarding this process. Awareness can reduce the likelihood that users call your help
desk for minor issues related to MFA. However, there are some scenarios where temporarily disabling MFA is
necessary. Use the following guidelines to understand how to handle those scenarios:
Train your support staff to handle scenarios where the user can't sign in because they do not have access to
their authentication methods or they are not working correctly.
Using Conditional Access policies for Azure MFA Service, your support staff can add a user to a group
that is excluded from a policy requiring MFA.
Consider using Conditional Access named locations as a way to minimize two-step verification prompts. With
this functionality, administrators can bypass two-step verification for users that are signing in from a secure
trusted network location such as a network segment used for new user onboarding.
Deploy Azure AD Identity Protection and trigger two-step verification based on risk events.
Next steps
Step-by-step Azure Multi-Factor Authentication deployment
How to get Azure Multi-Factor Authentication
When it comes to protecting your accounts, two-step verification should be standard across your organization.
This feature is especially important for accounts that have privileged access to resources. For this reason,
Microsoft offers basic two-step verification features to Office 365 and Azure Active Directory (Azure AD )
Administrators for no extra cost. If you want to upgrade the features for your admins or extend two-step
verification to the rest of your users, you can purchase Azure Multi-Factor Authentication in several ways.
IMPORTANT
This article is meant to be a guide to help you understand the different ways to buy Azure Multi-Factor Authentication. For
specific details about pricing and billing, you should always refer to the Multi-Factor Authentication pricing page.
Available versions of Azure Multi-Factor Authentication

The following table describes the differences between three versions of multi-factor authentication:
VERSION DESCRIPTION
Multi-Factor Authentication for Office 365 This version is managed from the Office 365 or Microsoft 365
Microsoft 365 Business portal. Administrators can secure Office 365 resources with
two-step verification. This version is part of an Office 365 or
Microsoft 365 Business subscription.
Multi-Factor Authentication for Azure AD Administrators Users assigned the Azure AD Global Administrator role in
Azure AD tenants can enable two-step verification at no
additional cost.
Azure Multi-Factor Authentication Often referred to as the "full" version, Azure Multi-Factor
Authentication offers the richest set of capabilities. It provides
additional configuration options via the Azure portal,
advanced reporting, and support for a range of on-premises
and cloud applications. Azure Multi-Factor Authentication is a
feature of Azure Active Directory Premium.
NOTE
New customers may no longer purchase Azure Multi-Factor Authentication as a standalone offering effective September 1st,
2018. Multi-factor authentication will continue to be available as a feature in Azure AD Premium licenses.
Feature comparison of versions

The following table provides a list of the features that are available in the various versions of Azure Multi-Factor
Authentication.
NOTE
This comparison table discusses the features that are part of each version of Multi-Factor Authentication. If you have the full
Azure Multi-Factor Authentication service, some features may not be available depending on whether you use MFA in the
cloud or MFA on-premises.
MULTI-FACTOR MULTI-FACTOR
AUTHENTICATION FOR OFFICE AUTHENTICATION FOR AZURE AZURE MULTI-FACTOR
FEATURE 365 AD ADMINISTRATORS AUTHENTICATION
Protect Azure AD admin ● ● (Azure AD Global ●

accounts with MFA Administrator accounts only)
Mobile app as a second ● ● ●

factor
Phone call as a second ● ● ●

factor
SMS as a second factor ● ● ●
App passwords for clients ● ● ●

that don't support MFA
Admin control over ● ● ●

verification methods
Protect non-admin accounts ● ●

with MFA
PIN mode ●
Fraud alert ●
MFA Reports ●
One-Time Bypass ●
Custom greetings for phone ●

calls
Custom caller ID for phone ●

calls
Trusted IPs ●
Remember MFA for trusted ● ● ●

devices
MFA for on-premises ●

applications
IMPORTANT
How to turn on Azure Multi-Factor Authentication for Azure AD

Administrators
Users assigned the Global Administrator role in Azure AD tenants can enable two-step verification for their Azure
AD Global Admin accounts at no additional cost. If you are using a Microsoft Account, you can register for multi-
factor authentication using the guidance found in the Microsoft account support article, About two-step
verification. If you are not using a Microsoft Account, turn on multi-factor authentication for Global Admins using
the guidance found in the article How to require two-step verification for a user or group.
How to purchase Azure Multi-Factor Authentication

Purchase licenses that include Azure Multi-Factor Authentication, like Azure Active Directory Premium, or a
license bundle that includes Azure AD Premium, or Conditional Access and assign them to your users in Azure
Active Directory.
Consumption-based licensing
Consumption-based licensing is no longer available to new customers effective September 1, 2018.
Effective September 1, 2018 new auth providers may no longer be created. Existing auth providers may continue
to be used and updated. Multi-factor authentication will continue to be an available feature in Azure AD Premium
licenses.
When using an Azure Multi-Factor Authentication Provider, there are two usage models available that are billed
through your Azure subscription:
1. Per Enabled User - For enterprises that want to enable two-step verification for a fixed number of
employees who regularly need authentication. Per-user billing is based on the number of users enabled for
MFA in your Azure AD tenant and your Azure MFA Server. If users are enabled for MFA in both Azure AD
and Azure MFA Server, and domain sync (Azure AD Connect) is enabled, then we count the larger set of
users. If domain sync isn't enabled, then we count the sum of all users enabled for MFA in Azure AD and
Azure MFA Server. Billing is prorated and reported to the Commerce system daily.
NOTE
Billing example 1: You have 5,000 users enabled for MFA today. The MFA system divides that number by 31, and
reports 161.29 users for that day. Tomorrow you enable 15 more users, so the MFA system reports 161.77 users for
that day. By the end of the billing cycle, the total number of users billed against your Azure subscription adds up to
around 5,000.
Billing example 2: You have a mixture of users with licenses and users without, so you have a per-user Azure MFA
Provider to make up the difference. There are 4,500 Enterprise Mobility + Security licenses on your tenant, but 5,000
users enabled for MFA. Your Azure subscription is billed for 500 users, prorated and reported daily as 16.13 users.
2. Per Authentication - For enterprises that want to enable two-step verification for a large group of users
who infrequently need authentication. Billing is based on the number of two-step verification requests,
regardless of whether those verifications succeed or are denied. This billing appears on your Azure usage
statement in packs of 10 authentications, and is reported daily.
NOTE
Billing example 3: Today, the Azure MFA service received 3,105 two-step verification requests. Your Azure
subscription is billed for 310.5 authentication packs.
It's important to note that you can have licenses, but still get billed for consumption-based configuration. If you
set up a per-authentication Azure MFA Provider, you are billed for every two-step verification request, even those
done by users who have licenses. If you set up a per-user Azure MFA Provider on a domain that isn't linked to
your Azure AD tenant, you are billed per enabled user even if your users have licenses on Azure AD.
Next steps
For more pricing details, see Azure MFA Pricing.
Choose whether to deploy Azure MFA in the cloud or on-premises
When to use an Azure Multi-Factor Authentication
Provider
Two-step verification is available by default for global administrators who have Azure Active Directory, and Office
365 users. However, if you wish to take advantage of advanced features then you should purchase the full version
of Azure Multi-Factor Authentication (MFA).
An Azure Multi-Factor Auth Provider is used to take advantage of features provided by Azure Multi-Factor
Authentication for users who do not have licenses.
NOTE
Effective September 1st, 2018 new auth providers may no longer be created. Existing auth providers may continue to be
used and updated, but migration is no longer possible. Multi-factor authentication will continue to be available as a feature
in Azure AD Premium licenses.
Caveats related to the Azure MFA SDK

Note the SDK has been deprecated and will only continue to work until November 14, 2018. After that time, calls
to the SDK will fail.
What is an MFA Provider?

There are two types of Auth providers, and the distinction is around how your Azure subscription is charged. The
per-authentication option calculates the number of authentications performed against your tenant in a month. This
option is best if you have a number of users authenticating only occasionally. The per-user option calculates the
number of individuals in your tenant who perform two-step verification in a month. This option is best if you have
some users with licenses but need to extend MFA to more users beyond your licensing limits.
Manage your MFA Provider

You cannot change the usage model (per enabled user or per authentication) after an MFA provider is created.
If you purchased enough licenses to cover all users that are enabled for MFA, you can delete the MFA provider
altogether.
If your MFA provider is not linked to an Azure AD tenant, or you link the new MFA provider to a different Azure
AD tenant, user settings and configuration options are not transferred. Also, existing Azure MFA Servers need to
be reactivated using activation credentials generated through the MFA Provider. Reactivating the MFA Servers to
link them to the MFA Provider doesn't impact phone call and text message authentication, but mobile app
notifications stop working for all users until they reactivate the mobile app.
Removing an authentication provider
Cau t i on
There is no confirmation when deleting an authentication provider. Selecting Delete is a permanent process.
Authentication providers can be found in the Azure portal > Azure Active Directory > MFA > Providers. Click
on listed providers to see details and configurations associated with that provider.
Before removing an authentication provider, take note of any customized settings configured in your provider.
Decide what settings need to be migrated to general MFA settings from your provider and complete the migration
of those settings.
Azure MFA Servers linked to providers will need to be reactivated using credentials generated under Azure portal
> Azure Active Directory > MFA > Server settings. Before reactivating, the following files must be deleted
from the \Program Files\Multi-Factor Authentication Server\Data\ directory on Azure MFA Servers in your
environment:
caCert
cert
groupCACert
groupKey
groupName
licenseKey
pkey
When you have confirmed that all settings have been migrated, you can browse to the Azure portal > Azure
Active Directory > MFA > Providers and select the ellipses ... and select Delete.
WARNING
Deleting an authentication provider will delete any reporting information associated with that provider. You may want to
save activity reports before deleting your provider.
NOTE
Users with older versions of the Microsoft Authenticator app and Azure MFA Server may need to re-register their app.
Next steps
Configure Multi-Factor Authentication settings
Security guidance for using Azure Multi-Factor
Authentication with Azure AD accounts
Two-step verification is the preferred choice for most organizations that want to enhance their authentication
process. Azure Multi-Factor Authentication (MFA) helps companies meet their security and compliance
requirements while providing a simple sign-in experience for their users. This article covers some tips that you
should consider when planning for the adoption of Azure MFA.
Deploy Azure MFA in the cloud

There are two ways to enable Azure MFA for all your users.
Buy licenses for each user (Either Azure MFA, Azure AD Premium, or Enterprise Mobility + Security)
Create a Multi-Factor Auth Provider and pay per-user or per-authentication
Licenses
If you have Azure AD Premium or Enterprise Mobility + Security licenses, you already have Azure MFA. Your
organization doesn't need anything additional to extend the two-step verification capability to all users. You only
need to assign a license to a user, and then you can turn on MFA.
When setting up Multi-Factor Authentication, consider the following tips:
Do not create a per-authentication Multi-Factor Auth Provider. If you do, you could end up paying for
verification requests from users that already have licenses.
If you don't have enough licenses for all your users, you can create a per-user Multi-Factor Auth Provider to
cover the rest of your organization.
Azure AD Connect is only required if you are synchronizing your on-premises Active Directory environment
with an Azure AD directory. If you use an Azure AD directory that is not synchronized with an on-premises
instance of Active Directory, you do not need Azure AD Connect.
Multi-Factor Auth Provider
If you don't have licenses that include Azure MFA, then you can create an MFA Auth Provider.
When creating the Auth Provider, you need to select a directory and consider the following details:
You do not need an Azure AD directory to create a Multi-Factor Auth Provider, but you get more functionality
with one. The following features are enabled when you associate the Auth Provider with an Azure AD directory:
Extend two-step verification to all your users
Offer your global administrators additional features, such as the management portal, custom greetings,
and reports.
If you synchronize your on-premises Active Directory environment with an Azure AD directory, you need
DirSync or AAD Sync. If you use an Azure AD directory that is not synchronized with an on-premises instance
of Active Directory, you do not need DirSync or AAD Sync.
Choose the consumption model that best suits your business. Once you select the usage model, you can’t
change it. The two models are:
Per authentication: charges you for each verification. Use this model if you want two-step verification for
anyone that accesses a certain app, not for specific users.
Per enabled user: charges you for each user that you enable for Azure MFA. Use this model if you have
some users with Azure AD Premium or Enterprise Mobility Suite licenses, and some without.
Supportability
Since most users are accustomed to using only passwords to authenticate, it is important that your company
brings awareness to all users regarding this process. This awareness can reduce the likelihood that users call your
help desk for minor issues related to MFA. However, there are some scenarios where temporarily disabling MFA is
necessary. Use the following guidelines to understand how to handle those scenarios:
Train your technical support staff to handle scenarios where the user can't sign in because the mobile app or
phone is not receiving a notification or phone call. Technical support can enable a one-time bypass to allow a
user to authenticate a single time by "bypassing" two-step verification. The bypass is temporary and expires
after a specified number of seconds.
Consider the Trusted IPs capability in Azure MFA as a way to minimize two-step verification. With this feature,
administrators of a managed or federated tenant can bypass two-step verification for users that are signing in
from the company’s local intranet. The features are available for Azure AD tenants that have Azure AD
Premium, Enterprise Mobility Suite, or Azure Multi-Factor Authentication licenses.
Best Practices for an on-premises deployment

If your company decided to leverage its own infrastructure to enable MFA, then you need to deploy an Azure
Multi-Factor Authentication Server on-premises. The MFA Server components are shown in the following diagram:
*Not installed by default **Installed but not enabled by default

Azure Multi-Factor Authentication Server can secure cloud resources and on-premises resources by using
federation. You must have AD FS and have it federated with your Azure AD tenant. When setting up Multi-Factor
Authentication Server, consider the following details:
If you are securing Azure AD resources using Active Directory Federation Services (AD FS ), then the first
verification step is performed on-premises using AD FS. The second step is performed on-premises by
honoring the claim.
You don't have to install the Azure Multi-Factor Authentication Server your AD FS federation server. However,
the Multi-Factor Authentication Adapter for AD FS must be installed on a Windows Server 2012 R2 running
AD FS. You can install the server on a different computer, as long as it is a supported version, and install the AD
FS adapter separately on your AD FS federation server.
The Multi-Factor Authentication AD FS Adapter installation wizard creates a security group called PhoneFactor
Admins in your Active Directory, and then adds your AD FS service account to this group. Verify that the
PhoneFactor Admins group was created on your domain controller, and that the AD FS service account is a
member of this group. If necessary, add the AD FS service account to the PhoneFactor Admins group on your
domain controller manually.
User Portal
The user portal allows self-service capabilities and provides a full set of user administration capabilities. It runs in
an Internet Information Server (IIS ) web site. Use the following guidelines to configure this component:
Use IIS 6 or greater
Install and register ASP.NET v2.0.507207
Ensure that this server can be deployed in a perimeter network
App Passwords
If your organization is federated for SSO with Azure AD and you are going to be using Azure MFA, then be aware
of the following details:
The app password is verified by Azure AD and therefore bypasses federation. Federation is only used when
setting up app passwords.
For federated (SSO ) users, passwords are stored in the organizational ID. If the user leaves the company, that
info has to flow to organizational ID using DirSync. Account disable/deletion may take up to three hours to
sync, which delays disable/deletion of app passwords in Azure AD.
On-premises Client Access Control settings are not honored by App Password.
No on-premises authentication logging/auditing capability is available for app passwords.
Certain advanced architectural designs may require using a combination of organizational username and
passwords and app passwords when using two-step verification with clients, depending on where they
authenticate. For clients that authenticate against an on-premises infrastructure, you would use an
organizational username and password. For clients that authenticate against Azure AD, you would use the app
password.
By default, users cannot create app passwords. If you need to allow users to create app passwords, select the
Allow users to create app passwords to sign into non-browser applications option.
Additional Considerations
Use this list for additional considerations and guidance for each component that is deployed on-premises:
Set up Azure Multi-Factor Authentication with Active Directory Federation Service.
Set up and configure the Azure MFA Server with RADIUS Authentication.
Set up and configure the Azure MFA Server with IIS Authentication.
Set up and configure the Azure MFA Server with Windows Authentication.
Set up and configure the Azure MFA Server with LDAP Authentication.
Set up and configure the Azure MFA Server with Remote Desktop Gateway and Azure Multi-Factor
Authentication Server using RADIUS.
Set up and configure synchronization between the Azure MFA Server and Windows Server Active Directory.
Deploy the Azure Multi-Factor Authentication Server Mobile App Web Service.
Advanced VPN Configuration with Azure Multi-Factor Authentication for Cisco ASA, Citrix Netscaler, and
Juniper/Pulse Secure VPN appliances using LDAP or RADIUS.
Next steps
While this article highlights some best practices for Azure MFA, there are other resources that you can also use
while planning your MFA deployment. The list below has some key articles that can assist you during this process:
Reports in Azure Multi-Factor Authentication
The two-step verification registration experience
Azure Multi-Factor Authentication FAQ
Frequently asked questions about Azure Multi-Factor
Authentication
This FAQ answers common questions about Azure Multi-Factor Authentication and using the Multi-Factor
Authentication service. It's broken down into questions about the service in general, billing models, user
experiences, and troubleshooting.
General
Q: How does Azure Multi-Factor Authentication Server handle user data?
With Multi-Factor Authentication Server, user data is stored only on the on-premises servers. No persistent user
data is stored in the cloud. When the user performs two-step verification, Multi-Factor Authentication Server sends
data to the Azure Multi-Factor Authentication cloud service for authentication. Communication between Multi-
Factor Authentication Server and the Multi-Factor Authentication cloud service uses Secure Sockets Layer (SSL ) or
Transport Layer Security (TLS ) over port 443 outbound.
When authentication requests are sent to the cloud service, data is collected for authentication and usage reports.
Data fields included in two-step verification logs are as follows:
Unique ID (either user name or on-premises Multi-Factor Authentication Server ID )
First and Last Name (optional)
Email Address (optional)
Phone Number (when using a voice call or SMS authentication)
Device Token (when using mobile app authentication)
Authentication Mode
Authentication Result
Multi-Factor Authentication Server Name
Multi-Factor Authentication Server IP
Client IP (if available)
The optional fields can be configured in Multi-Factor Authentication Server.
The verification result (success or denial), and the reason if it was denied, is stored with the authentication data. This
data is available in authentication and usage reports.
Q: What SMS short codes are used for sending SMS messages to my users?
In the United States Microsoft uses the following SMS short codes:
97671
69829
51789
99399
In Canada Microsoft uses the following SMS short codes:
759731
673801
Microsoft does not guarantee consistent SMS or Voice-based Multi-Factor Authentication prompt delivery by the
same number. In the interest of our users, Microsoft may add or remove Short codes at any time as we make route
adjustments to improve SMS deliverability. Microsoft does not support short codes for countries/regions besides
the United States and Canada.
Billing
Most billing questions can be answered by referring to either the Multi-Factor Authentication Pricing page or the
documentation about How to get Azure Multi-Factor Authentication.
Q: Is my organization charged for sending the phone calls and text messages that are used for
authentication?
No, you are not charged for individual phone calls placed or text messages sent to users through Azure Multi-
Factor Authentication. If you use a per-authentication MFA provider, you are billed for each authentication but not
for the method used.
Your users might be charged for the phone calls or text messages they receive, according to their personal phone
service.
Q: Does the per-user billing model charge me for all enabled users, or just the ones that performed two-
step verification?
Billing is based on the number of users configured to use Multi-Factor Authentication, regardless of whether they
performed two-step verification that month.
Q: How does Multi-Factor Authentication billing work?
When you create a per-user or per-authentication MFA provider, your organization's Azure subscription is billed
monthly based on usage. This billing model is similar to how Azure bills for usage of virtual machines and websites.
When you purchase a subscription for Azure Multi-Factor Authentication, your organization only pays the annual
license fee for each user. MFA licenses and Office 365, Azure AD Premium, or Enterprise Mobility + Security
bundles are billed this way.
Learn more about your options in How to get Azure Multi-Factor Authentication.
Q: Is there a free version of Azure Multi-Factor Authentication?
In some instances, yes.
Multi-Factor Authentication for Azure Administrators offers a subset of Azure MFA features at no cost for access to
Microsoft online services, including the Azure portal and Microsoft 365 admin center. This offer only applies to
global administrators in Azure Active Directory instances that don't have the full version of Azure MFA through an
MFA license, a bundle, or a standalone consumption-based provider. If your admins use the free version, and then
you purchase a full version of Azure MFA, then all global administrators are elevated to the paid version
automatically.
Multi-Factor Authentication for Office 365 users offers a subset of Azure MFA features at no cost for access to
Office 365 services, including Exchange Online and SharePoint Online. This offer applies to users who have an
Office 365 license assigned, when the corresponding instance of Azure Active Directory doesn't have the full
version of Azure MFA through an MFA license, a bundle, or a standalone consumption-based provider.
Q: Can my organization switch between per-user and per-authentication consumption billing models at
any time?
If your organization purchases MFA as a standalone service with consumption-based billing, you choose a billing
model when you create an MFA provider. You cannot change the billing model after an MFA provider is created.
AD tenant, user settings and configuration options are not transferred. Also, existing Azure MFA Servers need to be
reactivated using activation credentials generated through the new MFA Provider. Reactivating the MFA Servers to
link them to the new MFA Provider doesn't impact phone call and text message authentication, but mobile app
notifications will stop working for all users until they reactivate the mobile app.
Learn more about MFA providers in Getting started with an Azure Multi-Factor Auth Provider.
Q: Can my organization switch between consumption-based billing and subscriptions (a license-based
model) at any time?
If your directory has a per-user Azure Multi-Factor Authentication provider, you can add MFA licenses. Users with
licenses aren't be counted in the per-user consumption-based billing. Users without licenses can still be enabled for
MFA through the MFA provider. If you purchase and assign licenses for all your users configured to use Multi-
Factor Authentication, you can delete the Azure Multi-Factor Authentication provider. You can always create
another per-user MFA provider if you have more users than licenses in the future.
If your directory has a per-authentication Azure Multi-Factor Authentication provider, you are always billed for
each authentication, as long as the MFA provider is linked to your subscription. You can assign MFA licenses to
users, but you'll still be billed for every two-step verification request, whether it comes from someone with an MFA
license assigned or not.
Q: Does my organization have to use and synchronize identities to use Azure Multi-Factor
Authentication?
If your organization uses a consumption-based billing model, Azure Active Directory is optional, but not required. If
your MFA provider is not linked to an Azure AD tenant, you can only deploy Azure Multi-Factor Authentication
Server on-premises.
Azure Active Directory is required for the license model because licenses are added to the Azure AD tenant when
you purchase and assign them to users in the directory.
Manage and support user accounts

Q: What should I tell my users to do if they don’t receive a response on their phone?
Have your users attempt up to 5 times in 5 minutes to get a phone call or SMS for authentication. Microsoft uses
multiple providers for delivering calls and SMS messages. If this doesn't work please open a support case with
Microsoft to further troubleshoot.
If the steps above do not work hopefully all your users configured more than one verification method. Tell them to
try signing in again, but select a different verification method on the sign-in page.
You can point your users to the End-user troubleshooting guide.
Q: What should I do if one of my users can't get in to their account?
You can reset the user's account by making them to go through the registration process again. Learn more about
managing user and device settings with Azure Multi-Factor Authentication in the cloud.
Q: What should I do if one of my users loses a phone that is using app passwords?
To prevent unauthorized access, delete all the user's app passwords. After the user has a replacement device, they
can recreate the passwords. Learn more about managing user and device settings with Azure Multi-Factor
Authentication in the cloud.
Q: What if a user can't sign in to non-browser apps?
If your organization still uses legacy clients, and you allowed the use of app passwords, then your users can't sign in
to these legacy clients with their username and password. Instead, they need to set up app passwords. Your users
must clear (delete) their sign-in information, restart the app, and then sign in with their username and app
password instead of their regular password.
If your organization doesn't have legacy clients, you should not allow your users to create app passwords.
NOTE
Modern authentication for Office 2013 clients
App passwords are only necessary for apps that don't support modern authentication. Office 2013 clients support modern
authentication protocols, but need to be configured. Now modern authentication is available to any customer running the
March 2015 or later update for Office 2013. For more information, see the blog post Updated Office 365 modern
authentication.
Q: My users say that sometimes they don't receive the text message, or they reply to two-way text
messages but the verification times out.
Delivery of text messages and receipt of replies in two-way SMS are not guaranteed because there are
uncontrollable factors that might affect the reliability of the service. These factors include the destination
country/region, the mobile phone carrier, and the signal strength.
If your users often have problems with reliably receiving text messages, tell them to use the mobile app or phone
call method instead. The mobile app can receive notifications both over cellular and Wi-Fi connections. In addition,
the mobile app can generate verification codes even when the device has no signal at all. The Microsoft
Authenticator app is available for Android, IOS, and Windows Phone.
If you must use text messages, we recommend using one-way SMS rather than two-way SMS when possible. One-
way SMS is more reliable and it prevents users from incurring global SMS charges from replying to a text message
that was sent from another country/region.
Q: Can I change the amount of time my users have to enter the verification code from a text message
before the system times out?
In some cases, yes.
For one-way SMS with Azure MFA Server v7.0 or higher, you can configure the timeout setting by setting a
registry key. After the MFA cloud service sends the text message, the verification code (or one-time passcode) is
returned to the MFA Server. The MFA Server stores the code in memory for 300 seconds by default. If the user
doesn't enter the code before the 300 seconds have passed, their authentication is denied. Use these steps to
change the default timeout setting:
1. Go to HKLM\Software\Wow6432Node\Positive Networks\PhoneFactor.
2. Create a DWORD registry key called pfsvc_pendingSmsTimeoutSeconds and set the time in seconds that
you want the Azure MFA Server to store one-time passcodes.
TIP
If you have multiple MFA Servers, only the one that processed the original authentication request knows the verification code
that was sent to the user. When the user enters the code, the authentication request to validate it must be sent to the same
server. If the code validation is sent to a different server, the authentication is denied.
For two-way SMS with Azure MFA Server, you can configure the timeout setting in the MFA Management Portal.
If users don't respond to the SMS within the defined timeout period, their authentication is denied.
For one-way SMS with Azure MFA in the cloud (including the AD FS adapter or the Network Policy Server
extension), you cannot configure the timeout setting. Azure AD stores the verification code for 180 seconds.
Q: Can I use hardware tokens with Azure Multi-Factor Authentication Server?
If you are using Azure Multi-Factor Authentication Server, you can import third-party Open Authentication (OATH)
time-based, one-time password (TOTP ) tokens, and then use them for two-step verification.
You can use ActiveIdentity tokens that are OATH TOTP tokens if you put the secret key in a CSV file and import to
Azure Multi-Factor Authentication Server. You can use OATH tokens with Active Directory Federation Services
(ADFS ), Internet Information Server (IIS ) forms-based authentication, and Remote Authentication Dial-In User
Service (RADIUS ) as long as the client system can accept the user input.
You can import third-party OATH TOTP tokens with the following formats:
Portable Symmetric Key Container (PSKC )
CSV if the file contains a serial number, a secret key in Base 32 format, and a time interval
Q: Can I use Azure Multi-Factor Authentication Server to secure Terminal Services?
Yes, but if you are using Windows Server 2012 R2 or later you can only secure Terminal Services by using Remote
Desktop Gateway (RD Gateway).
Security changes in Windows Server 2012 R2 changed how Azure Multi-Factor Authentication Server connects to
the Local Security Authority (LSA) security package in Windows Server 2012 and earlier versions. For versions of
Terminal Services in Windows Server 2012 or earlier, you can secure an application with Windows Authentication.
If you are using Windows Server 2012 R2, you need RD Gateway.
Q: I configured Caller ID in MFA Server, but my users still receive Multi-Factor Authentication calls from
an anonymous caller.
When Multi-Factor Authentication calls are placed through the public telephone network, sometimes they are
routed through a carrier that doesn't support caller ID. Because of this, caller ID is not guaranteed, even though the
Multi-Factor Authentication system always sends it.
Q: Why are my users being prompted to register their security information? There are several reasons that
users could be prompted to register their security information:
The user has been enabled for MFA by their administrator in Azure AD, but doesn't have security information
registered for their account yet.
The user has been enabled for self-service password reset in Azure AD. The security information will help them
reset their password in the future if they ever forget it.
The user accessed an application that has a Conditional Access policy to require MFA and hasn’t previously
registered for MFA.
The user is registering a device with Azure AD (including Azure AD Join), and your organization requires MFA
for device registration, but the user has not previously registered for MFA.
The user is generating Windows Hello for Business in Windows 10 (which requires MFA) and hasn’t previously
registered for MFA.
The organization has created and enabled an MFA Registration policy that has been applied to the user.
The user previously registered for MFA, but chose a verification method that an administrator has since
disabled. The user must therefore go through MFA registration again to select a new default verification
method.
Errors
Q: What should users do if they see an “Authentication request is not for an activated account” error
message when using mobile app notifications?
Tell them to follow this procedure to remove their account from the mobile app, then add it again:
1. Go to your Azure portal profile and sign in with your organizational account.
2. Select Additional Security Verification.
3. Remove the existing account from the mobile app.
4. Click Configure, and then follow the instructions to reconfigure the mobile app.
Q: What should users do if they see a 0x800434D4L error message when signing in to a non-browser
application?
The 0x800434D4L error occurs when you try to sign in to a non-browser application, installed on a local computer,
that doesn't work with accounts that require two-step verification.
A workaround for this error is to have separate user accounts for admin-related and non-admin operations. Later,
you can link mailboxes between your admin account and non-admin account so that you can sign in to Outlook by
using your non-admin account. For more details about this solution, learn how to give an administrator the ability
to open and view the contents of a user's mailbox.
Next steps
If your question isn't answered here, please leave it in the comments at the bottom of the page. Or, here are some
additional options for getting help:
Search the Microsoft Support Knowledge Base for solutions to common technical issues.
Search for and browse technical questions and answers from the community, or ask your own question in the
Azure Active Directory forums.
If you're a legacy PhoneFactor customer and you have questions or need help resetting a password, use the
password reset link to open a support case.
Contact a support professional through Azure Multi-Factor Authentication Server (PhoneFactor) support. When
contacting us, it's helpful if you can include as much information about your issue as possible. Information you
can supply includes the page where you saw the error, the specific error code, the specific session ID, and the ID
of the user who saw the error.
Eliminate bad passwords in your organization
Industry leaders tell you not to use the same password in multiple places, to make it complex, and to not make it
simple like “Password123”. How can organizations guarantee that their users are following best-practice
guidance? How can they make sure users aren't using weak passwords, or even variations on weak passwords?
The initial step in having stronger passwords is to provide guidance to your users. Microsoft's current guidance on
this topic can be found at the following link:
Microsoft Password Guidance
Having good guidance is important, but even with that we know that many users will still end up choosing weak
passwords. Azure AD Password Protection protects your organization by detecting and blocking known weak
passwords and their variants, as well as optionally blocking additional weak terms that are specific to your
organization.
For more information about current security efforts, see the Microsoft Security Intelligence Report.
Global banned password list

The Azure AD Identity Protection team constantly analyzes Azure AD security telemetry data looking for
commonly used weak or compromised passwords, or more specifically, the weak base terms that often are used as
the basis for weak passwords. When such weak terms are found, they are added to the global banned password
list. The contents of the global banned password list are not based on any external data source. The global banned
password list is based entirely on the ongoing results of Azure AD security telemetry and analysis.
Whenever a new password is changed or reset for any user in any tenant in Azure AD, the current version of the
global banned password list is used as the key input when validating the strength of the password. This validation
results in much stronger passwords for all Azure AD customers.
NOTE
Cyber-criminals also use similar strategies in their attacks. Therefore Microsoft does not publish the contents of this list
publicly.
Custom banned password list

Some organizations may want to improve security even further by adding their own customizations on top of the
global banned password list in what Microsoft calls the custom banned password list. Microsoft recommends that
terms added to this list are primarily focused on organizational-specific terms such as:
Brand names
Product names
Locations (for example, such as company headquarters)
Company-specific internal terms
Abbreviations that have specific company meaning.
Once terms are added to the custom banned password list, they will be combined with the terms in the global
banned password list when validating passwords.
NOTE
The custom banned password list is limited to having a maximum of 1000 terms. It is not designed for blocking extremely
large lists of passwords. In order to fully leverage the benefits of the custom banned password list, Microsoft recommends
that you first review and understand the password evaluation algorithm (see How are passwords evaluated) before adding
new terms to the custom banned list. Understanding how the algorithm works will enable your enterprise to efficiently
detect and block large numbers of weak passwords and their variants.
For example: consider a customer named “Contoso”, that is based in London, and that makes a product named
“Widget”. For such a customer, it would be wasteful as well as less secure to try to block specific variations of these
terms such as:
"Contoso!1"
"Contoso@London"
"ContosoWidget"
"!Contoso"
"LondonHQ"
...etcetera
Instead, it is much more efficient and secure to block only the key base terms:
"Contoso"
"London"
"Widget"
The password validation algorithm will then automatically block weak variants and combinations of the above.
The custom banned password list and the ability to enable on-premises Active Directory integration is managed
using the Azure portal.
Password spray attacks and third-party compromised password lists

One key Azure AD password protection benefit is to help you defend against password spray attacks. Most
password spray attacks do not attempt to attack any given individual account more than a few times since such
behavior greatly increases the likelihood of detection, either via account lockout or other means. The majority of
password spray attacks therefore rely on submitting only a small number of the known weakest passwords against
each of the accounts in an enterprise. This technique allows the attacker to quickly search for an easily
compromised account while at the same time avoiding potential detection thresholds.
Azure AD password protection is designed to efficiently block all known weak passwords that are likely to be used
in password spray attacks, based on real-world security telemetry data as seen by Azure AD. Microsoft is aware of
third-party websites that enumerate millions of passwords that have been compromised in previous publicly
known security breaches. It is common for third-party password validation products to be based on brute-force
comparison against those millions of passwords. Microsoft feels that such techniques are not the best way to
improve overall password strength given the typical strategies used by password spray attackers.
NOTE
The Microsoft global banned password list is not based whatsoever on any third-party data sources, including compromised
password lists.
Although the Microsoft global banned list is small in comparison to some third-party bulk lists, its security effects
are amplified by the fact that it is sourced from real-world security telemetry on actual password spray attacks,
plus the fact that the Microsoft password validation algorithm uses smart fuzzy-matching techniques. The end
result is that it will efficiently detect and block millions of the most common weak passwords from being used in
your enterprise. Customers who choose to add organization-specific terms to the custom banned password list
also benefit from the same algorithm.
Additional information on password-based security issues may be reviewed at Your Pa$$word doesn't matter.
On-premises hybrid scenarios

Protecting cloud-only accounts is helpful but many organizations maintain hybrid scenarios including on-premises
Windows Server Active Directory. The security benefits of Azure AD password protection may also be extended
into your Windows Server Active Directory environment via the installation of on-premises agents. Now users and
administrators who change or reset passwords in Active Directory are required to comply with the same password
policy as cloud-only users.
How are passwords evaluated

Whenever a user changes or resets their password, the new password is checked for strength and complexity by
validating it against the combined list of terms from the global and custom banned password lists (if the latter is
configured).
Even if a user’s password contains a banned password, the password may still be accepted if the overall password
is strong enough otherwise. A newly configured password will go through the following steps to assess its overall
strength to determine if it should be accepted or rejected.
Step 1: Normalization
A new password first goes through a normalization process. This technique allows for a small set of banned
passwords to be mapped to a much larger set of potentially weak passwords.
Normalization has two parts. First, all uppercase letters are changed to lower case. Second, common character
substitutions are performed, for example:
ORIGINAL LETTER SUBSTITUTED LETTER
'0' 'o'
'1' 'l'
'$' 's'
'@' 'a'
Example: assume that the password “blank” is banned, and a user tries to change their password to “Bl@nK”. Even
though “Bl@nk” is not specifically banned, the normalization process converts this password to “blank”, which is a
banned password.
Step 2: Check if password is considered banned
Fuzzy matching behavior
Fuzzy matching is used on the normalized password to identify if it contains a password found on either the global
or the custom banned password lists. The matching process is based on an edit distance of one (1) comparison.
Example: assume that the password “abcdef” is banned, and a user tries to change their password to one of the
following:
‘abcdeg’ (last character changed from ‘f ’ to ‘g’) ‘abcdefg’’(g’ appended to end ) ‘abcde’ (trailing ‘f ’ was deleted from
end )
Each of the above passwords does not specifically match the banned password "abcdef". However, since each
example is within an edit distance of 1 of the banned term ‘abcdef’, they are all considered as a match to “abcdef”.
Substring matching (on specific terms )
Substring matching is used on the normalized password to check for the user’s first and last name as well as the
tenant name (note that tenant name matching is not done when validating passwords on an Active Directory
domain controller).
Example: assume that we have a user, Pol, who wants to reset their password to “P0l123fb”. After normalization,
this password would become “pol123fb”. Substring matching finds that the password contains the user’s first
name “Pol”. Even though “P0l123fb” was not specifically on either banned password list, substring matching found
“Pol" in the password. Therefore this password would be rejected.
Score Calculation
The next step is to identify all instances of banned passwords in the user's normalized new password. Then:
1. Each banned password that is found in a user’s password is given one point.
2. Each remaining unique character is given one point.
3. A password must be at least five (5) points for it to be accepted.
For the next two examples, let’s assume that Contoso is using Azure AD Password Protection and has “contoso” on
their custom list. Let’s also assume that “blank” is on the global list.
Example: a user changes their password to “C0ntos0Blank12”
After normalization, this password becomes “contosoblank12”. The matching process finds that this password
contains two banned passwords: contoso and blank. This password is then given a score:
[contoso] + [blank] + [1] + [2] = 4 points Since this password is under five (5) points, it will be rejected.
Example: a user changes their password to “ContoS0Bl@nkf9!”.
After normalization, this password becomes “contosoblankf9!”. The matching process finds that this password
contains two banned passwords: contoso and blank. This password is then given a score:
[contoso] + [blank] + [f] + [9] + [!] = 5 points Since this password is at least five (5) points, it is accepted.
IMPORTANT
Please note that the banned password algorithm along with the global list can and do change at any time in Azure based on
ongoing security analysis and research. For the on-premises DC agent service, updated algorithms will only take effect after
the DC agent software is re-installed.
License requirements
AZURE AD PASSWORD PROTECTION WITH AZURE AD PASSWORD PROTECTION WITH
GLOBAL BANNED PASSWORD LIST CUSTOM BANNED PASSWORD LIST
Cloud-only users Azure AD Free Azure AD Premium P1 or P2
Users synchronized from on-premises Azure AD Premium P1 or P2 Azure AD Premium P1 or P2

Windows Server Active Directory
NOTE
On-premises Windows Server Active Directory users that not synchronized to Azure Active Directory also avail the benefits
of Azure AD password protection based on existing licensing for synchronized users.
Additional licensing information, including costs, can be found on the Azure Active Directory pricing site.
What do users see

When a user attempts to reset a password to something that would be banned, they see the following error
message:
Unfortunately, your password contains a word, phrase, or pattern that makes your password easily guessable.
Please try again with a different password.
Next steps
Configure the custom banned password list
Enable Azure AD password protection agents on-premises
Enforce Azure AD password protection for Windows
Server Active Directory
Azure AD password protection is a feature that enhances password policies in an organization. On-premises
deployment of password protection uses both the global and custom banned-password lists that are stored in
Azure AD. It does the same checks on-premises as Azure AD for cloud-based changes.
Design principles
Azure AD password protection is designed with these principles in mind:
Domain controllers never have to communicate directly with the internet.
No new network ports are opened on domain controllers.
No Active Directory schema changes are required. The software uses the existing Active Directory container
and serviceConnectionPoint schema objects.
No minimum Active Directory domain or forest functional level (DFL/FFL ) is required.
The software doesn't create or require accounts in the Active Directory domains that it protects.
User clear-text passwords never leave the domain controller, either during password validation operations or at
any other time.
The software is not dependent on other Azure AD features; for example Azure AD password hash sync is not
related and is not required in order for Azure AD password protection to function.
Incremental deployment is supported, however the password policy is only enforced where the Domain
Controller Agent (DC Agent) is installed. See next topic for more details.
Incremental deployment
Azure AD password protection supports incremental deployment across domain controllers in an Active Directory
domain but it's important to understand what this really means and what the tradeoffs are.
The Azure AD password protection DC agent software can only validate passwords when it is installed on a
domain controller, and only for password changes that are sent to that domain controller. It is not possible to
control which domain controllers are chosen by Windows client machines for processing user password changes.
In order to guarantee consistent behavior and universal password protection security enforcement, the DC agent
software MUST be installed on all domain controllers in a domain.
Many organizations will want to do careful testing of Azure AD password protection on a subset of their domain
controllers prior to doing a full deployment. Azure AD password protection does support partial deployment, ie
the DC agent software on a given DC will actively validate passwords even when other DCs in the domain do not
have the DC agent software installed. Partial deployments of this type are NOT secure and are NOT
recommended other than for testing purposes.
Architectural diagram
It's important to understand the underlying design and function concepts before you deploy Azure AD password
protection in an on-premises Active Directory environment. The following diagram shows how the components of
password protection work together:
The Azure AD Password Protection Proxy service runs on any domain-joined machine in the current Active
Directory forest. Its primary purpose is to forward password policy download requests from domain
controllers to Azure AD. It then returns the responses from Azure AD to the domain controller.
The password filter DLL of the DC Agent receives user password-validation requests from the operating
system. It forwards them to the DC Agent service that's running locally on the domain controller.
The DC Agent service of password protection receives password-validation requests from the password filter
DLL of the DC Agent. It processes them by using the current (locally available) password policy and returns the
result: pass or fail.
How password protection works

Each Azure AD Password Protection Proxy service instance advertises itself to the domain controllers in the forest
by creating a serviceConnectionPoint object in Active Directory.
Each DC Agent service for password protection also creates a serviceConnectionPoint object in Active
Directory. This object is used primarily for reporting and diagnostics.
The DC Agent service is responsible for initiating the download of a new password policy from Azure AD. The
first step is to locate an Azure AD Password Protection Proxy service by querying the forest for proxy
serviceConnectionPoint objects. When an available proxy service is found, the DC Agent sends a password
policy download request to the proxy service. The proxy service in turn sends the request to Azure AD. The proxy
service then returns the response to the DC Agent service.
After the DC Agent service receives a new password policy from Azure AD, the service stores the policy in a
dedicated folder at the root of its domain sysvol folder share. The DC Agent service also monitors this folder in
case newer policies replicate in from other DC Agent services in the domain.
The DC Agent service always requests a new policy at service startup. After the DC Agent service is started, it
checks the age of the current locally available policy hourly. If the policy is older than one hour, the DC Agent
requests a new policy from Azure AD via the proxy service, as described previously. If the current policy isn't older
than one hour, the DC Agent continues to use that policy.
Whenever an Azure AD password protection password policy is downloaded, that policy is specific to a tenant. In
other words, password policies are always a combination of the Microsoft global banned-password list and the
per-tenant custom banned-password list.
The DC Agent communicates with the proxy service via RPC over TCP. The proxy service listens for these calls on
a dynamic or static RPC port, depending on the configuration.
The DC Agent never listens on a network-available port.
The proxy service never calls the DC Agent service.
The proxy service is stateless. It never caches policies or any other state downloaded from Azure.
The DC Agent service always uses the most recent locally available password policy to evaluate a user's password.
If no password policy is available on the local DC, the password is automatically accepted. When that happens, an
event message is logged to warn the administrator.
Azure AD password protection isn't a real-time policy application engine. There can be a delay between when a
password policy configuration change is made in Azure AD and when that change reaches and is enforced on all
domain controllers.
Azure AD password protection acts as a supplement to the existing Active Directory password policies, not a
replacement. This includes any other 3rd-party password filter dlls that may be installed. Active Directory always
requires that all password validation components agree before accepting a password.
Forest/tenant binding for password protection

Deployment of Azure AD password protection in an Active Directory forest requires registration of that forest
with Azure AD. Each proxy service that is deployed must also be registered with Azure AD. These forest and proxy
registrations are associated with a specific Azure AD tenant, which is identified implicitly by the credentials that
are used during registration.
The Active Directory forest and all deployed proxy services within a forest must be registered with the same
tenant. It is not supported to have an Active Directory forest or any proxy services in that forest being registered
to different Azure AD tenants. Symptoms of such a mis-configured deployment include the inability to download
password policies.
Download
The two required agent installers for Azure AD password protection are available from the Microsoft Download
Center.
Next steps
Create a resilient access control management strategy
with Azure Active Directory
NOTE
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as
of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be
a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the
date of publication.
Organizations that rely on a single access control, such as multi-factor authentication (MFA) or a single network
location, to secure their IT systems are susceptible to access failures to their apps and resources if that single access
control becomes unavailable or misconfigured. For example, a natural disaster can result in the unavailability of
large segments of telecommunications infrastructure or corporate networks. Such a disruption could prevent end
users and administrators from being able to sign in.
This document provides guidance on strategies an organization should adopt to provide resilience to reduce the
risk of lockout during unforeseen disruptions with the following scenarios:
1. Organizations can increase their resiliency to reduce the risk of lockout before a disruption by implementing
mitigation strategies or contingency plans.
2. Organizations can continue to access apps and resources they choose during a disruption by having
mitigation strategies and contingency plans in place.
3. Organizations should make sure they preserve information, such as logs, after a disruption and before they
roll back any contingencies they implemented.
4. Organizations that haven’t implemented prevention strategies or alternative plans may be able to implement
emergency options to deal with the disruption.
Key guidance
There are four key takeaways in this document:
Avoid administrator lockout by using emergency access accounts.
Implement MFA using Conditional Access (CA) rather than per-user MFA.
Mitigate user lockout by using multiple Conditional Access (CA) controls.
Mitigate user lockout by provisioning multiple authentication methods or equivalents for each user.
Before a disruption
Mitigating an actual disruption must be an organization’s primary focus in dealing with access control issues that
may arise. Mitigating includes planning for an actual event plus implementing strategies to make sure access
controls and operations are unaffected during disruptions.
Why do you need resilient access control?
Identity is the control plane of users accessing apps and resources. Your identity system controls which users and
under which conditions, such as access controls or authentication requirements, users get access to the
applications. When one or more authentication or access control requirements aren’t available for users to
authenticate due to unforeseen circumstances, organizations can experience one or both of the following issues:
Administrator lockout: Administrators can’t manage the tenant or services.
User lockout: Users can’t access apps or resources.
Administrator lockout contingency
To unlock admin access to your tenant, you should create emergency access accounts. These emergency access
accounts, also known as break glass accounts, allow access to manage Azure AD configuration when normal
privileged account access procedures aren’t available. At least two emergency access accounts should be created
following the emergency access account recommendations.
Mitigating user lockout
To mitigate the risk of user lockout, use Conditional Access policies with multiple controls to give users a choice of
how they will access apps and resources. By giving a user the choice between, for example, signing in with MFA or
signing in from a managed device or signing in from the corporate network, if one of the access controls is
unavailable the user has other options to continue to work.
Microsoft recommendations
Incorporate the following access controls in your existing Conditional Access policies for organization:
1. Provision multiple authentication methods for each user that rely on different communication channels, for
example the Microsoft Authenticator app (internet-based), OATH token (generated on-device), and SMS
(telephonic).
2. Deploy Windows Hello for Business on Windows 10 devices to satisfy MFA requirements directly from device
sign-in.
3. Use trusted devices via Azure AD Hybrid Join or Microsoft Intune Managed devices. Trusted devices will
improve user experience because the trusted device itself can satisfy the strong authentication requirements of
policy without an MFA challenge to the user. MFA will then be required when enrolling a new device and when
accessing apps or resources from untrusted devices.
4. Use Azure AD identity protection risk-based policies that prevent access when the user or sign-in is at risk in
place of fixed MFA policies.
NOTE
Risk-based policies require Azure AD Premium P2 licenses.
The following example describes policies you must create to provide a resilient access control for user to access
their apps and resources. In this example, you will require a security group AppUsers with the target users you
want to give access to, a group named CoreAdmins with the core administrators, and a group named
EmergencyAccess with the emergency access accounts. This example policy set will grant selected users in
AppUsers, access to selected apps if they are connecting from a trusted device OR provide strong authentication,
for example MFA. It excludes emergency accounts and core administrators.
CA mitigation policies set:
Policy 1: Block access to people outside target groups
Users and Groups: Include all users. Exclude AppUsers, CoreAdmins, and EmergencyAccess
Cloud Apps: Include all apps
Conditions: (None)
Grant Control: Block
Policy 2: Grant access to AppUsers requiring MFA OR trusted device.
Users and Groups: Include AppUsers. Exclude CoreAdmins, and EmergencyAccess
Cloud Apps: Include all apps
Conditions: (None)
Grant Control: Grant access, require multi-factor authentication, require device to be compliant. For
multiple controls: Require one of the selected controls.
Contingencies for user lockout
Alternatively, your organization can also create contingency policies. To create contingency policies, you must
define tradeoff criteria between business continuity, operational cost, financial cost, and security risks. For example,
you may activate a contingency policy only to a subset of users, for a subset of apps, for a subset of clients, or from
a subset of locations. Contingency policies will give administrators and end users access to apps and resources,
during a disruption when no mitigation method was implemented. Understanding your exposure during a
disruption helps reduce your risk and is a critical part of your planning process. To create your contingency plan,
first determine the following business requirements of your organization:
1. Determine your mission critical apps ahead of time: What are the apps that you must give access to, even with a
lower risk/security posture? Build a list of these apps and make sure your other stakeholders (business, security,
legal, leadership) all agree that if all access control goes away, these apps still must continue to run. You are
likely going to end up with categories of:
Category 1 mission critical apps that cannot be unavailable for more than a few minutes, for example
Apps that directly affect the revenue of the organization.
Category 2 important apps that the business needs to be accessible within a few hours.
Category 3 low-priority apps that can withstand a disruption of a few days.
2. For apps in category 1 and 2, Microsoft recommends you pre-plan what type of level of access you want to
allow:
Do you want to allow full access or restricted session, like limiting downloads?
Do you want to allow access to part of the app but not the whole app?
Do you want to allow information worker access and block administrator access until the access control
is restored?
3. For those apps, Microsoft also recommends you plan which avenues of access you will deliberately open and
which ones you will close:
Do you want to allow browser only access and block rich clients that can save offline data?
Do you want to allow access only for users inside the corporate network and keep outside users blocked?
Do you want to allow access from certain countries or regions only during the disruption?
Do you want policies to the contingency policies, especially for mission critical apps, to fail or succeed if
an alternative access control is not available?
A contingency Conditional Access policy is a disabled policy that omits Azure MFA, third-party MFA, risk-based
or device-based controls. Then, when your organization decides to activate your contingency plan, administrators
can enable the policy and disable the regular control-based policies.
IMPORTANT
Disabling policies that enforce security on your users, even temporarily, will reduce your security posture while the
contingency plan is in place.
Configure a set of fallback policies if a disruption in one credential type or one access control mechanism
impacts access to your apps. Configure a policy in disabled state that requires Domain Join as a control, as a
backup for an active policy that requires a third-party MFA provider.
Reduce the risk of bad actors guessing passwords, when MFA is not required, by following the practices in the
password guidance white paper.
Deploy Azure AD Self-Service Password Reset (SSPR ) and Azure AD Password Protection to make sure users
don’t use common password and terms you choose to ban.
Use policies that restrict the access within the apps if a certain authentication level is not attained instead of
simply falling back to full access. For example:
Configure a backup policy that sends the restricted session claim to Exchange and SharePoint.
If your organization uses Microsoft Cloud App Security, consider falling back to a policy that engages
MCAS and then MCAS Allows read-only access but not uploads.
Name your policies to make sure it is easy to find them during a disruption. Include the following elements in
the policy name:
A label number for the policy.
Text to show, this policy is for emergencies only. For example: ENABLE IN EMERGENCY
The disruption it applies to. For example: During MFA Disruption
A sequence number to show the order you must activate the policies.
The apps it applies to.
The controls it will apply.
The conditions it requires.
This naming standard for the contingency policies will be as follows:
EMnnn - ENABLE IN EMERGENCY: [Disruption][i/n] - [Apps] - [Controls] [Conditions]
The following example: Example A - Contingency CA policy to restore Access to mission-critical

Collaboration Apps, is a typical corporate contingency. In this scenario, the organization typically requires MFA
for all Exchange Online and SharePoint Online access, and the disruption in this case is the MFA provider for the
customer has an outage (whether Azure MFA, on-premises MFA provider, or third-party MFA). This policy
mitigates this outage by allowing specific targeted users access to these apps from trusted Windows devices only
when they are accessing the app from their trusted corporate network. It will also exclude emergency accounts and
core administrators from these restrictions. The targeted users will then gain access to Exchange Online and
SharePoint Online, while other users will still not have access to the apps due to the outage. This example will
require a named network location CorpNetwork and a security group ContingencyAccess with the target users,
a group named CoreAdmins with the core administrators, and a group named EmergencyAccess with the
emergency access accounts. The contingency requires four policies to provide the desired access.
Example A - Contingency CA policies to restore Access to mission-critical Collaboration Apps:
Policy 1: Require Domain Joined devices for Exchange and SharePoint
Name: EM001 - ENABLE IN EMERGENCY: MFA Disruption[1/4] - Exchange SharePoint - Require
Hybrid Azure AD Join
Users and Groups: Include ContingencyAccess. Exclude CoreAdmins, and EmergencyAccess
Cloud Apps: Exchange Online and SharePoint Online
Conditions: Any
Grant Control: Require Domain Joined
State: Disabled
Policy 2: Block platforms other than Windows
Name: EM002 - ENABLE IN EMERGENCY: MFA Disruption[2/4] - Exchange SharePoint - Block access
except Windows
Users and Groups: Include all users. Exclude CoreAdmins, and EmergencyAccess
Conditions: Device Platform Include All Platforms, exclude Windows
State: Disabled
Policy 3: Block networks other than CorpNetwork
Name: EM003 - ENABLE IN EMERGENCY: MFA Disruption[3/4] - Exchange SharePoint - Block access
except Corporate Network
Users and Groups: Include all users. Exclude CoreAdmins, and EmergencyAccess
Conditions: Locations Include any location, exclude CorpNetwork
State: Disabled
Policy 4: Block EAS Explicitly
Name: EM004 - ENABLE IN EMERGENCY: MFA Disruption[4/4] - Exchange - Block EAS for all users
Users and Groups: Include all users
Cloud Apps: Include Exchange Online
Conditions: Client apps: Exchange Active Sync
State: Disabled
Order of activation:
1. Exclude ContingencyAccess, CoreAdmins, and EmergencyAccess from the existing MFA policy. Verify a user in
ContingencyAccess can access SharePoint Online and Exchange Online.
2. Enable Policy 1: Verify users on Domain Joined devices who are not in the exclude groups are able to access
Exchange Online and SharePoint Online. Verify users in the Exclude group can access SharePoint Online and
Exchange from any device.
3. Enable Policy 2: Verify users who are not in the exclude group cannot get to SharePoint Online and Exchange
Online from their mobile devices. Verify users in the Exclude group can access SharePoint and Exchange from
any device (Windows/iOS/Android).
4. Enable Policy 3: Verify users who are not in the exclude groups cannot access SharePoint and Exchange off the
corporate network, even with a domain joined machine. Verify users in the Exclude group can access SharePoint
and Exchange from any network.
5. Enable Policy 4: Verify all users cannot get Exchange Online from the native mail applications on mobile devices.
6. Disable the existing MFA policy for SharePoint Online and Exchange Online.
In this next example, Example B - Contingency CA policies to allow mobile access to Salesforce, a business
app’s access is restored. In this scenario, the customer typically requires their sales employees access to Salesforce
(configured for single-sign on with Azure AD ) from mobile devices to only be allowed from compliant devices. The
disruption in this case is that there is an issue with evaluating device compliance and the outage is happening at a
sensitive time where the sales team needs access to Salesforce to close deals. These contingency policies will grant
critical users access to Salesforce from a mobile device so that they can continue to close deals and not disrupt the
business. In this example, SalesforceContingency contains all the Sales employees who need to retain access and
SalesAdmins contains necessary admins of Salesforce.
Example B - Contingency CA policies:
Policy 1: Block everyone not in the SalesContingency team
Name: EM001 - ENABLE IN EMERGENCY: Device Compliance Disruption[1/2] - Salesforce - Block All
users except SalesforceContingency
Users and Groups: Include all users. Exclude SalesAdmins and SalesforceContingency
Cloud Apps: Salesforce.
Conditions: None
State: Disabled
Policy 2: Block the Sales team from any platform other than mobile (to reduce surface area of attack)
Name: EM002 - ENABLE IN EMERGENCY: Device Compliance Disruption[2/2] - Salesforce - Block All
platforms except iOS and Android
Users and Groups: Include SalesforceContingency. Exclude SalesAdmins
Cloud Apps: Salesforce
Conditions: Device Platform Include All Platforms, exclude iOS and Android
State: Disabled
Order of activation:
1. Exclude SalesAdmins and SalesforceContingency from the existing device compliance policy for Salesforce.
Verify a user in the SalesforceContingency group can access Salesforce.
2. Enable Policy 1: Verify users outside of SalesContingency cannot access Salesforce. Verify users in the
SalesAdmins and SalesforceContingency can access Salesforce.
3. Enable Policy 2: Verify users in the SalesContingency group cannot access Salesforce from their Windows/Mac
laptops but can still access from their mobile devices. Verify SalesAdmin can still access Salesforce from any
device.
4. Disable the existing device compliance policy for Salesforce.
Deploy password hash sync even if you are federated or use pass-through authentication
User lockout can also occur if the following conditions are true:
Your organization uses a hybrid identity solution with pass-through authentication or federation.
Your on-premises identity systems (such as Active Directory, AD FS, or a dependent component) are
unavailable.
To be more resilient, your organization should enable password hash sync, because it enables you to switch to
using password hash sync if your on-premises identity systems are down.
Enable password hash sync using the Azure AD Connect wizard, regardless whether your organization uses
federation or pass-through authentication.
IMPORTANT
It is not required to convert users from federated to managed authentication to use password hash sync.
During a disruption
If you opted for implementing a mitigation plan, you will be able to automatically survive a single access control
disruption. However, if you opted to create a contingency plan, you will be able to activate your contingency
policies during the access control disruption:
1. Enable your contingency policies that grant targeted users, access to specific apps, from specific networks.
2. Disable your regular control-based policies.
Depending on which mitigations or contingencies are used during a disruption, your organization could be
granting access with just passwords. No safeguard is a considerable security risk that must be weighed carefully.
Organizations must:
1. As part of your change control strategy, document every change and the previous state to be able to roll back
any contingencies you implemented as soon as the access controls are fully operational.
2. Assume that malicious actors will attempt to harvest passwords through password spray or phishing attacks
while you disabled MFA. Also, bad actors might already have passwords that previously did not grant access to
any resource that can be attempted during this window. For critical users such as executives, you can partially
mitigate this risk by resetting their passwords before disabling MFA for them.
3. Archive all sign-in activity to identify who access what during the time MFA was disabled.
4. Triage all risk events reported during this window.
After a disruption
Undo the changes you made as part of the activated contingency plan once the service is restored that caused the
disruption.
1. Enable the regular policies
2. Disable your contingency policies.
3. Roll back any other changes you made and documented during the disruption.
4. If you used an emergency access account, remember to regenerate credentials and physically secure the new
credentials details as part of your emergency access account procedures.
5. Continue to triage all risk events reported after the disruption for suspicious activity.
6. Revoke all refresh tokens that were issued using PowerShell to target a set of users. Revoking all refresh tokens
is important for privileged accounts used during the disruption and doing it will force them to reauthenticate
and meet the control of the restored policies.
Emergency options
In case of an emergency and your organization did not previously implement a mitigation or contingency plan,
then follow the recommendations in the Contingencies for user lockout section if they already use Conditional
Access policies to enforce MFA. If your organization is using per-user MFA legacy policies, then you can consider
the following alternative:
1. If you have the corporate network outbound IP address, you can add them as trusted IPs to enable
authentication only to the corporate network.
a. If you don’t have the inventory of outbound IP addresses, or you required to enable access inside and
outside the corporate network, you can add the entire IPv4 address space as trusted IPs by specifying
0.0.0.0/1 and 128.0.0.0/1.
IMPORTANT
If you broaden the trusted IP addresses to unblock access, risk events associated with IP addresses (for example, impossible
travel or unfamiliar locations) will not be generated.
NOTE
Configuring trusted IPs for Azure MFA is only available with Azure AD Premium licenses.
Learn more
Azure AD Authentication Documentation
Manage emergency-access administrative accounts in Azure AD
Configure named locations in Azure Active Directory
Set-MsolDomainFederationSettings
How to configure hybrid Azure Active Directory joined devices
Windows Hello for Business Deployment Guide
Password Guidance - Microsoft Research
What are conditions in Azure Active Directory Conditional Access?
What are access controls in Azure Active Directory Conditional Access?
Deploy Azure AD self-service password reset
Self-service password reset (SSPR ) is an Azure Active Directory feature that enables employees to reset their
passwords without needing to contact IT staff. Employees must register for or be registered for self-service
password reset before using the service. During registration, the employee chooses one or more authentication
methods enabled by their organization.
SSPR enables employees to quickly get unblocked and continue working no matter where they are or the time
of day. By allowing users to unblock themselves, your organization can reduce the non-productive time and high
support costs for most common password-related issues.
Help users get registered quickly by deploying SSPR alongside another application or service in your
organization. This action will generate a large volume of sign-ins and will drive registration.
Before deploying SSPR, organizations may want to determine how many password reset related help desk calls
happen over time and the average cost of each call. They can use this data post deployment to show the value
SSPR is bringing to your organization.
How SSPR works

1. When a user attempts to reset a password, they must verify their previously registered authentication method
or methods to prove their identity.
2. Then the user enters a new password.
a. For cloud-only users, the new password is stored in Azure Active Directory. For more information, see
the article How SSPR works.
b. For hybrid users, the password is written back to the on-premises Active Directory via the Azure AD
Connect service. For more information, see the article What is password writeback.
Licensing considerations
Azure Active Directory is license per-user meaning each user has to have an appropriate license for the features
they utilize.
More information about licensing can be found on the Azure Active Directory pricing page
Enable combined registration for SSPR and MFA

Microsoft recommends that organizations enable the combined registration experience for SSPR and multi-
factor authentication. When you enable this combined registration experience, users need only select their
registration information once to enable both features.
The combined registration experience does not require organizations to enable both SSPR and Azure Multi-
Factor Authentication to use. The combined registration experience provides organizations a better user
experience compared to the traditional individual components. More information about combined registration,
and how to enable, can be found in the article Combined security information registration (preview )
Plan the configuration

The following settings are required to enable SSPR along with recommended values.
AREA SETTING VALUE
SSPR Properties Self-service password reset enabled Selected group for pilot / All for
production
Authentication methods Authentication methods required to Always 1 more than required for reset
register
Authentication methods required to One or two

reset
Registration Require users to register when signing Yes

in
Number of days before users are asked 90 – 180 days

to re-confirm their authentication
information
Notifications Notify users on password resets Yes
Notify all admins when other admins Yes

reset their password
AREA SETTING VALUE
Customization Customize helpdesk link Yes
Custom helpdesk email or URL Support site or email address
On-premises integration Write back passwords to on-premises Yes

AD
Allow users to unlock account without Yes

resetting password
SSPR properties recommendations

When enabling Self-service password reset, choose a security group to be used during the pilot.
When you plan to launch the service more broadly, we recommend using the All option to enforce SSPR for
everyone in the organization. If you cannot set to all, select the appropriate Azure AD Security group or AD
group synced to Azure AD.
Set Authentication methods required to register to at least one more than the number required to reset.
Allowing multiple gives users flexibility when they need to reset.
Set Number of methods required to reset to a level appropriate to your organization. One requires the least
friction, while two may increase your security posture.
See What are authentication methods for detailed information on which authentication methods are available
for SSPR, pre-defined security questions, and how to create customized security questions.
Registration settings
Set Require users to register when signing in to Yes. This setting means that the users are forced to register
when signing in, ensuring that all users are protected.
Set Number of days before users are asked to re-confirm their authentication information to between
90 and 180 days, unless your organization has a business need for a shorter time frame.
Notifications settings
Configure both the Notify users on password resets and the Notify all admins when other admins reset
their password to Yes. Selecting Yes on both increases security by ensuring that users are aware when their
password has been reset, and that all admins are aware when an admin changes a password. If users or admins
receive such a notification and they have not initiated the change, they can immediately report a potential
security breach.
Customization
It’s critical to customize the helpdesk email or URL to ensure users who experience problems can quickly get
help. Set this option to a common helpdesk email address or web page that your users are familiar with.
If you have a hybrid environment, ensure that Write back passwords to on-premises AD is set to Yes. Also
set the Allow users to unlock account without resetting password to Yes, as it gives them more flexibility.
Changing/Resetting passwords of administrators
Administrator accounts are special accounts with elevated permissions. To secure them, the following restrictions
apply to changing passwords of administrators:
On-premises enterprise administrators or domain administrators cannot reset their password through SSPR.
They can only change their password in their on-premises environment. Thus, we recommend not syncing
on-prem AD admin accounts to Azure AD.
An administrator cannot use secret Questions & Answers as a method to reset password.
Environments with multiple identity management systems
If there are multiple identity management systems within an environment such as on-premises identity
managers like Oracle AM, SiteMinder, or other systems, then passwords written to Active Directory may need to
be synchronized to the other systems using a tool like the Password Change Notification Service (PCNS ) with
Microsoft Identity Manager (MIM ). To find information on this more complex scenario, see the article Deploy the
MIM Password Change Notification Service on a domain controller.
Plan deployment and support for SSPR

Engage the right stakeholders
When technology projects fail, they typically do so due to mismatched expectations on impact, outcomes, and
responsibilities. To avoid these pitfalls, ensure that you are engaging the right stakeholders, and that stakeholder
roles in the project are well understood by documenting the stakeholders and their project input and
accountability.
Communications plan
Communication is critical to the success of any new service. Proactively communicate with your users how to
use the service and what they can do to get help if something doesn’t work as expected. Review the Self-service
password reset rollout materials on the Microsoft download center for ideas on how to plan your end-user
communication strategy.
Testing plan
To ensure that your deployment works as expected, you should plan out a set of test cases you will use to
validate the implementation. The following table includes some useful test scenarios you can use to document
your organizations expected results based on your policies.
BUSINESS CASE EXPECTED RESULT
SSPR portal is accessible from within the corporate network Determined by your organization
SSPR portal is accessible from outside the corporate network Determined by your organization
Reset user password from browser when user is not enabled User is not able to access the password reset flow
for password reset
Reset user password from browser when user has not User is not able to access the password reset flow
registered for password reset
User signs in when password reset registration is enforced User is prompted to register security information
User signs in when password reset registration has been User is not prompted to register security information
completed
SSPR portal is accessible when the user does not have a Is accessible
license
Reset user password from Windows 10 AADJ or H+AADJ User can reset password
device lock screen after user has registered
BUSINESS CASE EXPECTED RESULT
SSPR registration and usage data are available to Is available via audit logs
administrators in near real time
Support plan
While SSPR does not typically create user issues, it is important to have support staff prepared to deal with
issues that may arise.
While an administrator can change or reset the password for end users through the Azure AD portal, it is better
to help resolve the issue via a self-service support process.
In the operational guide section of this document, create a list of support cases and their likely causes, and create
a guide for resolution.
Auditing and reporting
After deployment, many organizations want to know how or if self-service password reset (SSPR ) is really being
used. The reporting feature that Azure Active Directory (Azure AD ) provides helps you answer questions by
using prebuilt reports.
Audit logs for registration and password reset are available for 30 days. Therefore, if security auditing within a
corporation requires longer retention, the logs need to be exported and consumed into a SIEM tool such as
Azure Sentinel, Splunk, or ArcSight.
In a table, like the one below, document the backup schedule, the system, and the responsible parties. You may
not need separate auditing and reporting backups, but you should have a separate backup from which you can
recover from an issue.
FREQUENCY OF DOWNLOAD TARGET SYSTEM RESPONSIBLE PARTY
Auditing backup
Reporting backup
Disaster recovery backup
Implementation
Implementation occurs in three stages:
Configure users and licenses
Configure Azure AD SSPR for registration and self-service
Configure Azure AD Connect for password writeback
Communicate the change
Begin implementation of the communications plan that you developed in the planning phase.
Ensure groups are created and populated
Reference the Planning password authentication methods section and ensure the group(s) for the pilot or
production implementation are available, and all appropriate users are added to the groups.
Apply licenses
The groups you are going to implement must have the Azure AD premium license assigned to them. You can
assign licenses directly to the group, or you can use existing license policies such as through PowerShell or
Group-Based Licensing.
Information about assigning licenses to groups of users can be found in the article, Assign licenses to users by
group membership in Azure Active Directory.
Configure SSPR
Enable groups for SSPR
1. Access the Azure portal with an administrator account.
2. Select All Services, and in the Filter box, type Azure Active Directory, and then select Azure Active Directory.
3. On the Active Directory blade, select Password reset.
4. In the properties pane, select Selected. If you want all users enabled, Select All.
5. In the Default password reset policy blade, type the name of the first group, select it, and then click Select at
the bottom of the screen, and select Save at the top of the screen.
6. Repeat this process for each group.
Configure the authentication methods
Reference your planning from the Planning Password Authentication Methods section of this document.
1. Select Registration, under Require user to register when signing in, select Yes, and then set the number of
days before expiration, and then select Save.
2. Select Notification, and configure per your plan, and then select Save.
3. Select Customization, and configure per your plan, and then select Save.
4. Select On-premises integration, and configure per your plan, and then select Save.
Enable SSPR in Windows
Windows 10 devices running version 1803 or higher that are either Azure AD joined or hybrid Azure AD joined
can reset their passwords at the Windows login screen. Information and steps to configure this capability can be
found in the article Azure AD password reset from the login screen
Configure password writeback
Steps to configure password writeback for your organization can be found in the article How -to: Configure
password writeback.
Manage SSPR
Required roles to manage features associated with self-service password reset.
BUSINESS ROLE/PERSONA AZURE AD ROLE (IF NECESSARY)
Level 1 Helpdesk Password administrator
Level 2 Helpdesk User administrator
SSPR Administrator Global administrator
Support scenarios
To enable your support team success, you can create an FAQ based on questions you receive from your users.
The following table contains common support scenarios.
SCENARIOS DESCRIPTION
User does not have any registered authentication methods A user is trying to reset their password but does not have
available any of the authentication methods that they registered
available (Example: they left their cell phone at home and
can’t access email)
SCENARIOS DESCRIPTION
User is not receiving a text or call on their office or mobile A user is trying to verify their identity via text or call but is
phone not receiving a text/call.
User cannot access the password reset portal A user wants to reset their password but is not enabled for
password reset and therefore cannot access the page to
update passwords.
User cannot set a new password A user completes verification during the password reset flow
but cannot set a new password.
User does not see a Reset Password link on a Windows 10 A user is trying to reset password from the Windows 10 lock
device screen, but the device is either not joined to Azure AD, or the
Intune device policy is not enabled
You may also want to include information such as the following for additional troubleshooting.
Which groups are enabled for SSPR.
Which authentication methods are configured.
The access policies related to on or of the corporate network.
Troubleshooting steps for common scenarios.
You can also refer to our online documentation on troubleshooting self-service password reset to understand
general troubleshooting steps for the most common SSPR scenarios.
Next steps
Consider implementing Azure AD password protection
Consider implementing Azure AD Smart Lockout
Deploy password reset without requiring end-user
registration
To deploy Azure Active Directory (Azure AD ) self-service password reset (SSPR ), authentication data needs to be
present. Some organizations have their users enter their authentication data themselves. But many organizations
prefer to synchronize with data that already exists in Active Directory. The synced data is made available to Azure
AD and SSPR without requiring user interaction if you:
Properly format the data in your on-premises directory.
Configure Azure AD Connect by using the express settings.
4255551234.
NOTE
Fields populated
If you use the default settings in Azure AD Connect, the following mappings are made:
ON-PREMISES ACTIVE DIRECTORY AZURE AD
telephoneNumber Office phone
mobile Mobile phone
Once a user verifies their mobile phone number, the Phone field under Authentication contact info in Azure AD
will also be populated with that number.
Authentication contact info

A Global Administrator can manually set the Authentication contact info for a user as displayed in the following
screenshot.
If the Phone field is populated and Mobile phone is enabled in the SSPR policy, the user will see that number on
the password reset registration page and during the password reset workflow.
The Alternate phone field is not used for password reset.
If the Email field is populated and Email is enabled in the SSPR policy, the user will see that email on the
password reset registration page and during the password reset workflow.
If the Alternate email field is populated and Email is enabled in the SSPR policy, the user will not see that email
on the password reset registration page, but they will see it during the password reset workflow.
Security questions and answers

The security questions and answers are stored securely in your Azure AD tenant and are only accessible to users
via the SSPR registration portal. Administrators can't see, set, or modify the contents of another users' questions
and answers.
What happens when a user registers

When a user registers, the registration page sets the following fields:
Authentication Phone
Authentication Email
Security Questions and Answers
If you have provided a value for Mobile phone or Alternate email, users can immediately use those values to
reset their passwords, even if they haven't registered for the service. In addition, users see those values when
they register for the first time, and they can modify them if they want to. After they register successfully, these
values will be persisted in the Authentication Phone and Authentication Email fields, respectively.
Set and read the authentication data through PowerShell
The following fields can be set through PowerShell:
Alternate email
Mobile phone
Office phone: Can only be set if you're not synchronizing with an on-premises directory
Use PowerShell version 1
To get started, you need to download and install the Azure AD PowerShell module. After you have it installed,
you can use the steps that follow to configure each field.
Set the authentication data with PowerShell version 1
Connect-MsolService
Set-MsolUser -UserPrincipalName user@domain.com -AlternateEmailAddresses @("email@domain.com")

Set-MsolUser -UserPrincipalName user@domain.com -MobilePhone "+1 1234567890"
Set-MsolUser -UserPrincipalName user@domain.com -PhoneNumber "+1 1234567890"
Set-MsolUser -UserPrincipalName user@domain.com -AlternateEmailAddresses @("email@domain.com") -MobilePhone

"+1 1234567890" -PhoneNumber "+1 1234567890"
Read the authentication data with PowerShell version 1
Connect-MsolService
Get-MsolUser -UserPrincipalName user@domain.com | select AlternateEmailAddresses

Get-MsolUser -UserPrincipalName user@domain.com | select MobilePhone
Get-MsolUser -UserPrincipalName user@domain.com | select PhoneNumber
Get-MsolUser | select DisplayName,UserPrincipalName,AlternateEmailAddresses,MobilePhone,PhoneNumber | Format-

Table
Read the Authentication Phone and Authentication Email options

To read the Authentication Phone and Authentication Email when you use PowerShell version 1, use the
following commands:
Connect-MsolService
Get-MsolUser -UserPrincipalName user@domain.com | select -Expand StrongAuthenticationUserDetails | select
PhoneNumber
Get-MsolUser -UserPrincipalName user@domain.com | select -Expand StrongAuthenticationUserDetails | select
Email
Use PowerShell version 2

To get started, you need to download and install the Azure AD version 2 PowerShell module. After you have it
installed, you can use the steps that follow to configure each field.
To quickly install from recent versions of PowerShell that support Install-Module, run the following commands.
(The first line checks to see if the module is already installed.)
Get-Module AzureADPreview
Install-Module AzureADPreview
Connect-AzureAD
Set the authentication data with PowerShell version 2

Connect-AzureAD
Set-AzureADUser -ObjectId user@domain.com -OtherMails @("email@domain.com")

Set-AzureADUser -ObjectId user@domain.com -Mobile "+1 2345678901"
Set-AzureADUser -ObjectId user@domain.com -TelephoneNumber "+1 1234567890"
Set-AzureADUser -ObjectId user@domain.com -OtherMails @("emails@domain.com") -Mobile "+1 1234567890" -

TelephoneNumber "+1 1234567890"
Read the authentication data with PowerShell version 2
Connect-AzureAD
Get-AzureADUser -ObjectID user@domain.com | select otherMails

Get-AzureADUser -ObjectID user@domain.com | select Mobile
Get-AzureADUser -ObjectID user@domain.com | select TelephoneNumber
Get-AzureADUser | select DisplayName,UserPrincipalName,otherMails,Mobile,TelephoneNumber | Format-Table
Next steps
How-to: Configure password writeback
The following steps assume you have already configured Azure AD Connect in your environment by using the
Express or Custom settings.
1. To configure and enable password writeback, sign in to your Azure AD Connect server and start the Azure
AD Connect configuration wizard.
2. On the Welcome page, select Configure.
3. On the Additional tasks page, select Customize synchronization options, and then select Next.
4. On the Connect to Azure AD page, enter a global administrator credential, and then select Next.
5. On the Connect directories and Domain/OU filtering pages, select Next.
6. On the Optional features page, select the box next to Password writeback and select Next.
7. On the Ready to configure page, select Configure and wait for the process to finish.
8. When you see the configuration finish, select Exit.
For common troubleshooting tasks related to password writeback, see the section Troubleshoot password
writeback in our troubleshooting article.
WARNING
Password writeback will stop working for customers who are using Azure AD Connect versions 1.0.8641.0 and older when
the Azure Access Control service (ACS) is retired on November 7th, 2018. Azure AD Connect versions 1.0.8641.0 and
older will no longer allow password writeback at that time because they depend on ACS for that functionality.
To avoid a disruption in service, upgrade from a previous version of Azure AD Connect to a newer version, see the article
Azure AD Connect: Upgrade from a previous version to the latest
Licensing requirements for password writeback
Self-Service Password Reset/Change/Unlock with on-premises writeback is a premium feature of
Azure AD. For more information about licensing, see the Azure Active Directory pricing site.
To use password writeback, you must have one of the following licenses assigned on your tenant:
Azure AD Premium P1
Azure AD Premium P2
Microsoft 365 F1
Microsoft 365 Business
WARNING
writeback" and require that you have one of the preceding plans for this functionality to work.
Active Directory permissions

The account specified in the Azure AD Connect utility must have the following items set if you want to be in
scope for SSPR:
Reset password
Change password
Write permissions on lockoutTime
Write permissions on pwdLastSet
Extended rights on either:
The root object of each domain in that forest
The user organizational units (OUs) you want to be in scope for SSPR
If you're not sure what account the described account refers to, open the Azure Active Directory Connect
configuration UI and select the View current configuration option. The account that you need to add
permission to is listed under Synchronized Directories.
If you set these permissions, the MA service account for each forest can manage passwords on behalf of the
user accounts within that forest.
IMPORTANT
If you neglect to assign these permissions, then, even though writeback appears to be configured correctly, users will
encounter errors when they attempt to manage their on-premises passwords from the cloud.
NOTE
It might take up to an hour or more for these permissions to replicate to all the objects in your directory.
To set up the appropriate permissions for password writeback to occur, complete the following steps:
1. Open Active Directory Users and Computers with an account that has the appropriate domain
administration permissions.
2. From the View menu, make sure Advanced features is turned on.
3. In the left panel, right-click the object that represents the root of the domain and select Properties >
Security > Advanced.
4. From the Permissions tab, select Add.
5. Pick the account that permissions are being applied to (from the Azure AD Connect setup).
6. In the Applies to drop-down list, select Descendant User objects.
7. Under Permissions, select the boxes for the following options:
Change password
Reset password
8. Under Properties, select the boxes for the following options:
Write lockoutTime
Write pwdLastSet
9. Select Apply/OK to apply the changes and exit any open dialog boxes.
Next steps
What is password writeback?
How to: Enable password reset from the Windows
login screen
For machines running Windows 7, 8, 8.1, and 10 you can enable users to reset their password at the Windows
login screen. Users no longer have to find a device with a web browser to access the SSPR portal.
General prerequisites
An administrator must enable Azure AD self-service password reset from the Azure portal.
Users must register for SSPR before using this feature
Network proxy requirements
Windows 10 devices
Port 443 to passwordreset.microsoftonline.com and ajax.aspnetcdn.com
Windows 10 devices only support machine-level proxy configuration
Windows 7, 8, and 8.1 devices
Port 443 to passwordreset.microsoftonline.com
General limitations
Password reset is not currently supported from a Remote Desktop or from Hyper-V enhanced sessions.
Account unlock, mobile app notification, and mobile app code are not supported.
This feature does not work for networks with 802.1x network authentication deployed and the option “Perform
immediately before user logon”. For networks with 802.1x network authentication deployed it is recommended
to use machine authentication to enable this feature.
Windows 10 password reset

Windows 10 specific prerequisites
Run at least Windows 10, version April 2018 Update (v1803), and the devices must be either:
Azure AD joined
Hybrid Azure AD joined
Hybrid Azure AD joined machines must have network connectivity line of sight to a domain controller to use
the new password and update cached credentials.
If using an image, prior to running sysprep ensure that the web cache is cleared for the built-in Administrator
prior to performing the CopyProfile step. More information about this step can be found in the support article
Performance poor when using custom default user profile.
The following settings are known to interfere with the ability to use and reset passwords on Windows 10
devices
If Ctrl+Alt+Del is required by policy in versions of Windows 10 before v1809, Reset password will not
work.
If lock screen notifications are turned off, Reset password will not work.
HideFastUserSwitching is set to enabled or 1
DontDisplayLastUserName is set to enabled or 1
NoLockScreen is set to enabled or 1
EnableLostMode is set on the device
Explorer.exe is replaced with a custom shell
The combination of the following specific three settings can cause this feature to not work.
Interactive logon: Do not require CTRL+ALT+DEL = Disabled
DisableLockScreenAppNotifications = 1 or Enabled
IsContentDeliveryPolicyEnforced = 1 or True
Enable for Windows 10 using Intune
Deploying the configuration change to enable password reset from the login screen using Intune is the most
flexible method. Intune allows you to deploy the configuration change to a specific group of machines you define.
This method requires Intune enrollment of the device.
Create a device configuration policy in Intune
1. Sign in to the Azure portal and click on Intune.
2. Create a new device configuration profile by going to Device configuration > Profiles > Create Profile
Provide a meaningful name for the profile
Optionally provide a meaningful description of the profile
Platform Windows 10 and later
Profile type Custom
3. Configure Settings
Add the following OMA-URI Setting to enable the Reset password link
Provide a meaningful name to explain what the setting is doing
Optionally provide a meaningful description of the setting
OMA -URI set to ./Vendor/MSFT/Policy/Config/Authentication/AllowAadPasswordReset
Data type set to Integer
Value set to 1
Click OK
Click OK
4. Click Create
5. This policy can be assigned to specific users, devices, or groups. More information can be found in the article
Assign user and device profiles in Microsoft Intune.
Enable for Windows 10 using the Registry
1. Sign in to the Windows PC using administrative credentials
2. Run regedit as an administrator
3. Set the following registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AzureADAccount
"AllowPasswordReset"=dword:00000001
Troubleshooting Windows 10 password reset

The Azure AD audit log will include information about the IP address and ClientType where the password reset
occurred.
When users reset their password from the login screen of a Windows 10 device, a low -privilege temporary account
called defaultuser1 is created. This account is used to keep the password reset process secure. The account itself
has a randomly generated password, doesn’t show up for device sign-in, and will automatically be removed after
the user resets their password. Multiple defaultuser profiles may exist but can be safely ignored.
Windows 7, 8, and 8.1 password reset

Windows 7, 8, and 8.1 specific prerequisites
Patched Windows 7 or Windows 8.1 Operating System.
TLS 1.2 enabled using the guidance found in Transport Layer Security (TLS ) registry settings.
If more than one 3rd party credential provider is enabled on your machine, users will see more than one user
profile on the login screen.
WARNING
TLS 1.2 must be enabled, not just set to auto negotiate
Install
1. Download the appropriate installer for the version of Windows you would like to enable.
Software is available on the Microsoft download center at https://aka.ms/sspraddin
2. Sign in to the machine where you would like to install, and run the installer.
3. After installation, a reboot is highly recommended.
4. After the reboot, at the login screen choose a user and click "Forgot password?" to initiate the password reset
workflow.
5. Complete the workflow following the onscreen steps to reset your password.
Silent installation
For silent install, use the command “msiexec /i SsprWindowsLogon.PROD.msi /qn”
For silent uninstall, use the command “msiexec /x SsprWindowsLogon.PROD.msi /qn”
Troubleshooting Windows 7, 8, and 8.1 password reset
Events will be logged both on the machine and in Azure AD. Azure AD Events will include information about the IP
address and ClientType where the password reset occurred.
If additional logging is required, a registry key on the machine can be changed to enable verbose logging. Enable
verbose logging for troubleshooting purposes only.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{86D2F0AC-2171-46CF-9998-
4E33B3D7FD4F}
To enable verbose logging, create a REG_DWORD: “EnableLogging” , and set it to 1.

To disable verbose logging, change the REG_DWORD: “EnableLogging” to 0.
What do users see

Now that you have configured password reset for your Windows devices, what changes for the user? How do they
know that they can reset their password at the login screen?
When users attempt to sign in, they now see a Reset password or Forgot password link that opens the self-
service password reset experience at the login screen. This functionality allows users to reset their password
without having to use another device to access a web browser.
Your users will find guidance for using this feature in Reset your work or school password
Next steps
Plan authentication methods to allow
Configure Windows 10
Planning a cloud-based Azure Multi-Factor
Authentication deployment
People are connecting to organizational resources in increasingly complicated scenarios. People connect from
organization-owned, personal, and public devices on and off the corporate network using smart phones, tablets,
PCs, and laptops, often on multiple platforms. In this always-connected, multi-device and multi-platform world,
the security of user accounts is more important than ever. Passwords, no matter their complexity, used across
devices, networks, and platforms are no longer sufficient to ensure the security of the user account, especially
when users tend to reuse passwords across accounts. Sophisticated phishing and other social engineering attacks
can result in usernames and passwords being posted and sold across the dark web.
Azure Multi-Factor Authentication (MFA) helps safeguard access to data and applications. It provides an
additional layer of security using a second form of authentication. Organizations can use Conditional Access to
make the solution fit their specific needs.
Prerequisites
Before starting a deployment of Azure Multi-Factor Authentication, there are prerequisite items that should be
considered.
SCENARIO PREREQUISITE
Cloud-only identity environment with modern No additional prerequisite tasks

authentication
Hybrid identity scenarios Azure AD Connect is deployed and user identities are
synchronized or federated with the on-premises Active
Directory Domain Services with Azure Active Directory.
On-premises legacy applications published for cloud access Azure AD Application Proxy is deployed.
Using Azure MFA with RADIUS Authentication A Network Policy Server (NPS) is deployed.
Users have Microsoft Office 2010 or earlier, or Apple Mail for Upgrade to Microsoft Office 2013 or later and Apple mail for
iOS 11 or earlier iOS 12 or later. Conditional Access is not supported by legacy
authentication protocols.
Plan user rollout

Your MFA rollout plan should include a pilot deployment followed by deployment waves that are within your
support capacity. Begin your rollout by applying your Conditional Access policies to a small group of pilot users.
After evaluating the effect on the pilot users, process used, and registration behaviors, you can either add more
groups to the policy or add more users to the existing groups.
User communications
It is critical to inform users, in planned communications, about upcoming changes, Azure MFA registration
requirements, and any necessary user actions. We recommend communications are developed in concert with
representatives from within your organization, such as a Communications, Change Management, or Human
Resources departments.
Microsoft provides communication templates and end-user documentation to help draft your communications.
You can send users to https://myprofile.microsoft.com to register directly by selecting the Security Info links on
that page.
Deployment considerations
Azure Multi-factor Authentication is deployed by enforcing policies with Conditional Access. A Conditional
Access policy can require users to perform multi-factor authentication when certain criteria are met such as:
All users, a specific user, member of a group, or assigned role
Specific cloud application being accessed
Device platform
State of device
Network location or geo-located IP address
Client applications
Sign-in risk (Requires Identity Protection)
Compliant device
Hybrid Azure AD joined device
Approved client application
Use the customizable posters and email templates in multi-factor authentication rollout materials to roll out
multi-factor authentication to your organization.
Enable Multi-Factor Authentication with Conditional Access

Conditional Access policies enforce registration, requiring unregistered users to complete registration at first
sign-in, an important security consideration.
Azure AD Identity Protection contributes both a registration policy for and automated risk detection and
remediation policies to the Azure Multi-Factor Authentication story. Policies can be created to force password
changes when there is a threat of compromised identity or require MFA when a sign-in is deemed risky by the
following events:
Leaked credentials
Sign-ins from anonymous IP addresses
Impossible travel to atypical locations
Sign-ins from unfamiliar locations
Sign-ins from infected devices
Sign-ins from IP addresses with suspicious activities
Some of the risk events detected by Azure Active Directory Identity Protection occur in real time and some
require offline processing. Administrators can choose to block users who exhibit risky behaviors and remediate
manually, require a password change, or require a multi-factor authentication as part of their Conditional Access
policies.
Define network locations

We recommended that organizations use Conditional Access to define their network using named locations. If
your organization is using Identity Protection, consider using risk-based policies instead of named locations.
Configuring a named location
1. Open Azure Active Directory in the Azure portal
2. Click Conditional Access
3. Click Named Locations
4. Click New Location
5. In the Name field, provide a meaningful name
6. Select whether you are defining the location using IP ranges or Countries/Regions
a. If using IP Ranges
a. Decide whether to mark the location as Trusted. Signing in from a trusted location lowers a
user's sign-in risk. Only mark this location as trusted if you know the IP ranges entered are
established and credible in your organization.
b. Specify the IP Ranges
b. If using Countries/Regions
a. Expand the drop-down menu and select the countries or regions you wish to define for this
named location.
b. Decide whether to Include unknown areas. Unknown areas are IP addresses that can't be
mapped to a country/region.
7. Click Create
Plan authentication methods

Administrators can choose the authentication methods that they want to make available for users. It is important
to allow more than a single authentication method so that users have a backup method available in case their
primary method is unavailable. The following methods are available for administrators to enable:
Notification through mobile app
A push notification is sent to the Microsoft Authenticator app on your mobile device. The user views the
notification and selects Approve to complete verification. Push notifications through a mobile app provide the
least intrusive option for users. They are also the most reliable and secure option because they use a data
connection rather than telephony.
NOTE
If your organization has staff working in or traveling to China, the Notification through mobile app method on Android
devices does not work in that country. Alternate methods should be made available for those users.
Verification code from mobile app

A mobile app like the Microsoft Authenticator app generates a new OATH verification code every 30 seconds.
The user enters the verification code into the sign-in interface. The mobile app option can be used whether or not
the phone has a data or cellular signal.
Call to phone
An automated voice call is placed to the user. The user answers the call and presses # on the phone keypad to
approve their authentication. Call to phone is a great backup method for notification or verification code from a
mobile app.
Text message to phone
A text message that contains a verification code is sent to the user, the user is prompted to enter the verification
code into the sign-in interface.
Choose verification options
1. Browse to Azure Active Directory, Users, Multi-Factor Authentication.
2. In the new tab that opens browse to service settings.
3. Under verification options, check all of the boxes for methods available to users.
4. Click on Save.
5. Close the service settings tab.
Plan registration policy

Administrators must determine how users will register their methods. Organizations should enable the new
combined registration experience for Azure MFA and self-service password reset (SSPR ). SSPR allows users to
reset their password in a secure way using the same methods they use for multi-factor authentication. We
recommend this combined registration, currently in public preview, because it’s a great experience for users, with
the ability to register once for both services. Enabling the same methods for SSPR and Azure MFA will allow
your users to be registered to use both features.
Registration with Identity Protection
If your organization is using Azure Active Directory Identity Protection, configure the MFA registration policy to
prompt your users to register the next time they sign in interactively.
Registration without Identity Protection
If your organization does not have licenses that enable Identity Protection, users are prompted to register the
next time that MFA is required at sign-in. Users may not be registered for MFA if they don't use applications
protected with MFA. It's important to get all users registered so that bad actors cannot guess the password of a
user and register for MFA on their behalf, effectively taking control of the account.
Enforcing registration
Using the following steps a Conditional Access policy can force users to register for Multi-Factor Authentication
1. Create a group, add all users not currently registered.
2. Using Conditional Access, enforce multi-factor authentication for this group for access to all resources.
3. Periodically, reevaluate the group membership, and remove users who have registered from the group.
You may identify registered and non-registered Azure MFA users with PowerShell commands that rely on the
MSOnline PowerShell module.
Identify registered users
Get-MsolUser -All | where {$_.StrongAuthenticationMethods -ne $null} | Select-Object -Property

UserPrincipalName | Sort-Object userprincipalname
Identify non-registered users
Get-MsolUser -All | where {$_.StrongAuthenticationMethods.Count -eq 0} | Select-Object -Property

UserPrincipalName | Sort-Object userprincipalname
Convert users from per-user MFA to Conditional Access based MFA

If your users were enabled using per-user enabled and enforced Azure Multi-Factor Authentication the following
PowerShell can assist you in making the conversion to Conditional Access based Azure Multi-Factor
Authentication.
# Disable MFA for all users, keeping their MFA methods intact
Get-MsolUser -All | Disable-MFA -KeepMethods
# Wrapper to disable MFA with the option to keep the MFA methods (to avoid having to proof-up again later)
function Disable-MFA {
[CmdletBinding()]
param(
[Parameter(ValueFromPipeline=$True)]
$User,
[switch] $KeepMethods
)
Process {
Write-Verbose ("Disabling MFA for user '{0}'" -f $User.UserPrincipalName)

$User | Set-MfaState -State Disabled
if ($KeepMethods) {
# Restore the MFA methods which got cleared when disabling MFA
Set-MsolUser -ObjectId $User.ObjectId `
-StrongAuthenticationMethods $User.StrongAuthenticationMethods
}
}
}
# Sets the MFA requirement state

function Set-MfaState {
[CmdletBinding()]
param(
[Parameter(ValueFromPipelineByPropertyName=$True)]
$ObjectId,
$UserPrincipalName,
[ValidateSet("Disabled","Enabled","Enforced")]
$State
)
Process {
Write-Verbose ("Setting MFA state for user '{0}' to '{1}'." -f $ObjectId, $State)
$Requirements = @()
if ($State -ne "Disabled") {
$Requirement =
[Microsoft.Online.Administration.StrongAuthenticationRequirement]::new()
$Requirement.RelyingParty = "*"
$Requirement.State = $State
$Requirements += $Requirement
}
Set-MsolUser -ObjectId $ObjectId -UserPrincipalName $UserPrincipalName `

-StrongAuthenticationRequirements $Requirements
}
}
Plan Conditional Access policies

To plan your Conditional Access policy strategy, which will determine when MFA and other controls are required,
refer to What is Conditional Access in Azure Active Directory?.
It is important that you prevent being inadvertently locked out of your Azure AD tenant. You can mitigate the
impact of this inadvertent lack of administrative access by creating two or more emergency access accounts in
your tenant and excluding them from your Conditional Access policy.
Create Conditional Access policy
1. Sign in to the Azure portal using a global administrator account.
2. Browse to Azure Active Directory, Conditional Access.
3. Select New policy.
4. Provide a meaningful name for your policy.
5. Under users and groups:
On the Include tab, select the All users radio button
On the Exclude tab, check the box for Users and groups and choose your emergency access
accounts.
Click Done.
6. Under Cloud apps, select the All cloud apps radio button.
OPTIONALLY: On the Exclude tab, choose cloud apps that your organization does not require MFA
for.
Click Done.
7. Under Conditions section:
OPTIONALLY: If you have enabled Azure Identity Protection, you can choose to evaluate sign-in risk
as part of the policy.
OPTIONALLY: If you have configured trusted locations or named locations, you can specify to include
or exclude those locations from the policy.
8. Under Grant, make sure the Grant access radio button is selected.
Check the box for Require multi-factor authentication.
Click Select.
9. Skip the Session section.
10. Set the Enable policy toggle to On.
11. Click Create.
Plan integration with on-premises systems

Some legacy and on-premises applications that do not authenticate directly against Azure AD require additional
steps to use MFA including:
Legacy on-premises applications, which will need to use Application proxy.
On-premises RADIUS applications, which will need to use MFA adapter with NPS server.
On-premises AD FS applications, which will need to use MFA adapter with AD FS 2016 or newer.
Applications that authenticate directly with Azure AD and have modern authentication (WS -Fed, SAML, OAuth,
OpenID Connect) can make use of Conditional Access policies directly.
Use Azure MFA with Azure AD Application Proxy
Applications residing on-premises can be published to your Azure AD tenant via Azure AD Application Proxy
and can take advantage of Azure Multi-Factor Authentication if they are configured to use Azure AD pre-
authentication.
These applications are subject to Conditional Access policies that enforce Azure Multi-Factor Authentication, just
like any other Azure AD -integrated application.
Likewise, if Azure Multi-Factor Authentication is enforced for all user sign-ins, on-premises applications
published with Azure AD Application Proxy will be protected.
Integrating Azure Multi-Factor Authentication with Network Policy Server
The Network Policy Server (NPS ) extension for Azure MFA adds cloud-based MFA capabilities to your
authentication infrastructure using your existing servers. With the NPS extension, you can add phone call, text
message, or phone app verification to your existing authentication flow. This integration has the following
limitations:
With the CHAPv2 protocol, only authenticator app push notifications and voice call are supported.
Conditional Access policies cannot be applied.
The NPS extension acts as an adapter between RADIUS and cloud-based Azure MFA to provide a second factor
of authentication to protect VPN, Remote Desktop Gateway connections, or other RADIUS capable applications.
Users that register for Azure MFA in this environment will be challenged for all authentication attempts, the lack
of Conditional Access policies means MFA is always required.
Implementing your NPS server
If you have an NPS instance deployed and in use already, reference Integrate your existing NPS Infrastructure
with Azure Multi-Factor Authentication. If you are setting up NPS for the first time, refer to Network Policy
Server (NPS ) for instructions. Troubleshooting guidance can be found in the article Resolve error messages from
the NPS extension for Azure Multi-Factor Authentication.
Prepare NPS for users that aren't enrolled for MFA
Choose what happens when users that aren’t enrolled with MFA try to authenticate. Use the registry setting
REQUIRE_USER_MATCH in the registry path HKLM\Software\Microsoft\AzureMFA to control the feature behavior. This
setting has a single configuration option.
KEY VALUE DEFAULT
REQUIRE_USER_MATCH TRUE / FALSE Not set (equivalent to TRUE)
The purpose of this setting is to determine what to do when a user is not enrolled for MFA. The effects of
changing this setting are listed in the table below.
SETTINGS USER MFA STATUS EFFECTS
Key does not exist Not enrolled MFA challenge is unsuccessful
Value set to True / not set Not enrolled MFA challenge is unsuccessful
SETTINGS USER MFA STATUS EFFECTS
Key set to False Not enrolled Authentication without MFA
Key set to False or True Enrolled Must authenticate with MFA
Integrate with Active Directory Federation Services

If your organization is federated with Azure AD, you can use Azure Multi-Factor Authentication to secure AD FS
resources, both on-premises and in the cloud. Azure MFA enables you to reduce passwords and provide a more
secure way to authenticate. Starting with Windows Server 2016, you can now configure Azure MFA for primary
authentication.
Unlike with AD FS in Windows Server 2012 R2, the AD FS 2016 Azure MFA adapter integrates directly with
Azure AD and does not require an on-premises Azure MFA server. The Azure MFA adapter is built into Windows
Server 2016, and there is no need for an additional installation.
When using Azure MFA with AD FS 2016 and the target application is subject to Conditional Access policy, there
are additional considerations:
Conditional Access is available when the application is a relying party to Azure AD, federated with AD FS
2016 or newer.
Conditional Access is not available when the application is a relying party to AD FS 2016 or AD FS 2019 and
is managed or federated with AD FS 2016 or AD FS 2019.
Conditional Access is also not available when AD FS 2016 or AD FS 2019 is configured to use Azure MFA as
the primary authentication method.
AD FS logging
Standard AD FS 2016 and 2019 logging in both the Windows Security Log and the AD FS Admin log, contains
information about authentication requests and their success or failure. Event log data within these events will
indicate whether Azure MFA was used. For example, an AD FS Auditing Event ID 1200 may contain:
<MfaPerformed>true</MfaPerformed>
<MfaMethod>MFA</MfaMethod>
Renew and manage certificates

On each AD FS server, in the local computer My Store, there will be a self-signed Azure MFA certificate titled
OU=Microsoft AD FS Azure MFA, which contains the certificate expiration date. Check the validity period of this
certificate on each AD FS server to determine the expiration date.
If the validity period of your certificates is nearing expiration, generate and verify a new MFA certificate on each
AD FS server.
The following guidance details how to manage the Azure MFA certificates on your AD FS servers. When you
configure AD FS with Azure MFA, the certificates generated via the New-AdfsAzureMfaTenantCertificate
PowerShell cmdlet are valid for 2 years. Renew and install the renewed certificates prior to expiration to ovoid
disruptions in MFA service.
Implement your plan

Now that you have planned your solution, you can implement by following the steps below:
1. Meet any necessary prerequisites
a. Deploy Azure AD Connect for any hybrid scenarios
b. Deploy Azure AD Application Proxy for on any on-premises apps published for cloud access
c. Deploy NPS for any RADIUS authentication
d. Ensure users have upgraded to supported versions of Microsoft Office with modern authentication
enabled
2. Configure chosen authentication methods
3. Define your named network locations
4. Select groups to begin rolling out MFA.
5. Configure your Conditional Access policies
6. Configure your MFA registration policy
a. Combined MFA and SSPR
b. With Identity Protection
7. Send user communications and get users to enroll at https://aka.ms/mfasetup
8. Keep track of who’s enrolled
TIP
Government cloud users can enroll at https://aka.ms/GovtMFASetup
Manage your solution

Reports for Azure MFA
Azure Multi-Factor Authentication provides reports through the Azure portal:
REPORT LOCATION DESCRIPTION
Usage and fraud alerts Azure AD > Sign-ins Provides information on overall usage,
user summary, and user details; as well
as a history of fraud alerts submitted
during the date range specified.
Troubleshoot MFA issues

Find solutions for common issues with Azure MFA at the Troubleshooting Azure Multi-Factor Authentication
article on the Microsoft Support Center.
Next steps
What are authentication methods?
Enable converged registration for Azure Multi-Factor Authentication and Azure AD self-service password
reset
Why was a user prompted or not prompted to perform MFA? See the section Azure AD sign-ins report in the
Reports in Azure Multi-Factor Authentication document.
How to require two-step verification for a user
You can take one of two approaches for requiring two-step verification, both of which require using a global
administrator account. The first option is to enable each user for Azure Multi-Factor Authentication (MFA). When
users are enabled individually, they perform two-step verification each time they sign in (with some exceptions,
such as when they sign in from trusted IP addresses or when the remembered devices feature is turned on). The
second option is to set up a Conditional Access policy that requires two-step verification under certain conditions.
TIP
Enabling Azure Multi-Factor Authentication using Conditional Access policies is the recommended approach. Changing user
states is no longer recommended unless your licenses do not include Conditional Access as it will require users to perform
MFA every time they sign in.
Choose how to enable

Enabled by changing user state - This is the traditional method for requiring two-step verification and is
discussed in this article. It works with both Azure MFA in the cloud and Azure MFA Server. Using this method
requires users to perform two-step verification every time they sign in and overrides Conditional Access policies.
Enabled by Conditional Access policy - This is the most flexible means to enable two-step verification for your
users. Enabling using Conditional Access policy only works for Azure MFA in the cloud and is a premium feature
of Azure AD. More information on this method can be found in Deploy cloud-based Azure Multi-Factor
Authentication.
Enabled by Azure AD Identity Protection - This method uses the Azure AD Identity Protection risk policy to require
two-step verification based only on sign-in risk for all cloud applications. This method requires Azure Active
Directory P2 licensing. More information on this method can be found in Azure Active Directory Identity
Protection
NOTE
More information about licenses and pricing can be found on the Azure AD and Multi-Factor Authentication pricing pages.
Enable Azure MFA by changing user state

User accounts in Azure Multi-Factor Authentication have the following three distinct states:
MODERN
NON-BROWSER APPS BROWSER APPS AUTHENTICATION
STATUS DESCRIPTION AFFECTED AFFECTED AFFECTED
Disabled The default state for a No No No

new user not enrolled
in Azure MFA.
MODERN
NON-BROWSER APPS BROWSER APPS AUTHENTICATION
STATUS DESCRIPTION AFFECTED AFFECTED AFFECTED
Enabled The user has been No. They continue to Yes. After the session Yes. After the access
enrolled in Azure work until the expires, Azure MFA token expires, Azure
MFA, but has not registration process is registration is MFA registration is
registered. They completed. required. required.
receive a prompt to
register the next time
they sign in.
Enforced The user has been Yes. Apps require app Yes. Azure MFA is Yes. Azure MFA is
enrolled and has passwords. required at login. required at login.
completed the
registration process
for Azure MFA.
A user's state reflects whether an admin has enrolled them in Azure MFA, and whether they completed the
registration process.
All users start out Disabled. When you enroll users in Azure MFA, their state changes to Enabled. When enabled
users sign in and complete the registration process, their state changes to Enforced.
View the status for a user
Use the following steps to access the page where you can view and manage user states:
1. Sign in to the Azure portal as an administrator.
2. Go to Azure Active Directory > Users and groups > All users.
3. Select Multi-Factor Authentication.
4. A new page that displays the user states opens.

Change the status for a user
1. Use the preceding steps to get to the Azure Multi-Factor Authentication users page.
2. Find the user you want to enable for Azure MFA. You might need to change the view at the top.
3. Check the box next to their name.

4. On the right, under quick steps, choose Enable or Disable.
TIP
Enabled users are automatically switched to Enforced when they register for Azure MFA. Do not manually change the
user state to Enforced.
5. Confirm your selection in the pop-up window that opens.

After you enable users, notify them via email. Tell them that they'll be asked to register the next time they sign in.
Also, if your organization uses non-browser apps that don't support modern authentication, they need to create
app passwords. You can also include a link to the Azure MFA end-user guide to help them get started.
Use PowerShell
To change the user state by using Azure AD PowerShell, change $st.State . There are three possible states:
Enabled
Enforced
Disabled
Don't move users directly to the Enforced state. If you do, non-browser-based apps stop working because the user
has not gone through Azure MFA registration and obtained an app password.
Install the Module first, using:
Install-Module MSOnline
TIP
Don't forget to connect first using Connect-MsolService
This example PowerShell script enables MFA for an individual user:
Import-Module MSOnline
$st = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
$st.RelyingParty = "*"
$st.State = "Enabled"
$sta = @($st)
Set-MsolUser -UserPrincipalName bsimon@contoso.com -StrongAuthenticationRequirements $sta
Using PowerShell is a good option when you need to bulk enable users. As an example, the following script loops
through a list of users and enables MFA on their accounts:
$users = "bsimon@contoso.com","jsmith@contoso.com","ljacobson@contoso.com"
foreach ($user in $users)
{
$st = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
$st.RelyingParty = "*"
$st.State = "Enabled"
$sta = @($st)
Set-MsolUser -UserPrincipalName $user -StrongAuthenticationRequirements $sta
}
To disable MFA, use this script:
Get-MsolUser -UserPrincipalName user@domain.com | Set-MsolUser -StrongAuthenticationMethods @()
which can also be shortened to:
Set-MsolUser -UserPrincipalName user@domain.com -StrongAuthenticationRequirements @()
Convert users from per-user MFA to Conditional Access based MFA

The following PowerShell can assist you in making the conversion to Conditional Access based Azure Multi-Factor
Authentication.
# Disable MFA for all users, keeping their MFA methods intact
Get-MsolUser -All | Disable-MFA -KeepMethods
# Wrapper to disable MFA with the option to keep the MFA methods (to avoid having to proof-up again later)
function Disable-Mfa {
[CmdletBinding()]
param(
[Parameter(ValueFromPipeline=$True)]
$User,
[switch] $KeepMethods
)
Process {
Write-Verbose ("Disabling MFA for user '{0}'" -f $User.UserPrincipalName)

$User | Set-MfaState -State Disabled
if ($KeepMethods) {
# Restore the MFA methods which got cleared when disabling MFA
Set-MsolUser -ObjectId $User.ObjectId `
-StrongAuthenticationMethods $User.StrongAuthenticationMethods
}
}
}
# Sets the MFA requirement state

function Set-MfaState {
[CmdletBinding()]
param(
$ObjectId,
$UserPrincipalName,
[ValidateSet("Disabled","Enabled","Enforced")]
$State
)
Process {
Write-Verbose ("Setting MFA state for user '{0}' to '{1}'." -f $ObjectId, $State)
$Requirements = @()
if ($State -ne "Disabled") {
$Requirement =
[Microsoft.Online.Administration.StrongAuthenticationRequirement]::new()
$Requirement.RelyingParty = "*"
$Requirement.State = $State
$Requirements += $Requirement
}
Set-MsolUser -ObjectId $ObjectId -UserPrincipalName $UserPrincipalName `

-StrongAuthenticationRequirements $Requirements
}
}
Next steps
Why was a user prompted or not prompted to perform MFA? See the section Azure AD sign-ins report in the
Reports in Azure Multi-Factor Authentication document.
To configure additional settings like trusted IPs, custom voice messages, and fraud alerts, see the article
Configure Azure Multi-Factor Authentication settings
Information about managing user settings for Azure Multi-Factor Authentication can be found in the article
Manage user settings with Azure Multi-Factor Authentication in the cloud
Manage user settings with Azure Multi-Factor
Authentication in the cloud
As an administrator, you can manage the following user and device settings:
Require users to provide contact methods again
Delete app passwords
Require MFA on all trusted devices
Manage authentication methods

As an administrator assigned the Authentication Administrator role you can require users to reset their password,
re-register for MFA, or revoke existing MFA sessions from their user object.
1. Reset Password will reset the user's password and assign a temporary password that must be changed on the
next sign in.
2. Require Re-register MFA will make it so that when the user signs in next time, they will be requested to setup a
new MFA authentication method.
3. Revoke MFA Sessions clears the user's remembered MFA sessions and requires them to perform MFA the
next time it is required by the policy on the device.
Require users to provide contact methods again

This setting forces the user to complete the registration process again. Non-browser apps continue to work if the
user has app passwords for them. You can delete the users app passwords by also selecting Delete all existing
app passwords generated by the selected users.
How to require users to provide contact methods again
2. On the left, select Azure Active Directory > Users > All users.
3. On the right, select Multi-Factor Authentication on the toolbar. The multi-factor authentication page opens.
4. Check the box next to the user or users that you wish to manage. A list of quick step options appears on the
right.
5. Select Manage user settings.
6. Check the box for Require selected users to provide contact methods again.
7. Click save.
8. Click close.
Organizations can complete these steps with PowerShell using the following as a guide to clear the
StrongAuthenticationMethods attribute:
$Upn = "theuser@domain.com"
$noMfaConfig = @()
Set-MsolUser -UserPrincipalName $Upn -StrongAuthenticationMethods $noMfaConfig
Delete users existing app passwords

This setting deletes all of the app passwords that a user has created. Non-browser apps that were associated with
these app passwords stop working until a new app password is created.
How to delete users existing app passwords
right.
6. Check the box for Delete all existing app passwords generated by the selected users.
7. Click save.
8. Click close.
Restore MFA on all remembered devices for a user

One of the configurable features of Azure Multi-Factor Authentication is giving your users the option to mark
devices as trusted. For more information, see Configure Azure Multi-Factor Authentication settings.
Users can opt out of two-step verification for a configurable number of days on their regular devices. If an account
is compromised or a trusted device is lost, you need to be able to remove the trusted status and require two-step
verification again.
When checked, Restore multi-factor authentication on all remembered devices users are required to
perform two-step verification the next time they sign in, even if they marked their device as trusted.
How to restore MFA on all suspended devices for a user
right.
6. Check the box for Restore multi-factor authentication on all remembered devices
7. Click save.
8. Click close.
Next steps
Get more information about how to Configure Azure Multi-Factor Authentication settings
If your users need help, point them towards the User guide for two-step verification
This article helps you to manage Multi-Factor Authentication settings in the Azure portal. It covers various topics
that help you to get the most out of Azure Multi-Factor Authentication. Not all of the features are available in
every version of Azure Multi-Factor Authentication.
You can access settings related to Azure Multi-Factor Authentication from the Azure portal by browsing to Azure
Active Directory > MFA.
Settings
Some of these settings apply to MFA Server, Azure MFA, or both.
FEATURE DESCRIPTION
Account lockout Temporarily lock accounts in the multi-factor authentication

service if there are too many denied authentication attempts
in a row. This feature only applies to users who enter a PIN to
authenticate. (MFA Server)
Block/unblock users Used to block specific users from being able to receive Multi-
Factor Authentication requests. Any authentication attempts
for blocked users are automatically denied. Users remain
blocked for 90 days from the time that they are blocked.
FEATURE DESCRIPTION
Fraud alert Configure settings related to users ability to report fraudulent

verification requests
Notifications Enable notifications of events from MFA Server.
OATH tokens Used in cloud-based Azure MFA environments to manage

OATH tokens for users.
Phone call settings Configure settings related to phone calls and greetings for
cloud and on-premises environments.
Providers This will show any existing authentication providers that you
may have associated with your account. New authentication
providers may not be created as of September 1, 2018
Manage MFA Server

Settings in this section are for MFA Server only.
FEATURE DESCRIPTION
Server settings Download MFA Server and generate activation credentials to

initialize your environment
One-time bypass Allow a user to authenticate without performing two-step

verification for a limited time.
Caching rules Caching is primarily used when on-premises systems, such as

VPN, send multiple verification requests while the first request
is still in progress. This feature allows the subsequent requests
to succeed automatically, after the user succeeds the first
verification in progress.
Server status See the status of your on-premises MFA servers including
version, status, IP, and last communication time and date.
Activity report
The reporting available here is specific to MFA Server (on-premises). For Azure MFA (cloud) reports see the sign-
ins report in Azure AD.
Block and unblock users

Use the block and unblock users feature to prevent users from receiving authentication requests. Any
authentication attempts for blocked users are automatically denied. Users remain blocked for 90 days from the
time that they are blocked.
Block a user
2. Browse to Azure Active Directory > MFA > Block/unblock users.
3. Select Add to block a user.
4. Select the Replication Group. Enter the username for the blocked user as username@domain.com. Enter a
comment in the Reason field.
5. Select Add to finish blocking the user.
Unblock a user
2. Browse to Azure Active Directory > MFA > Block/unblock users.
3. Select Unblock in the Action column next to the user to unblock.
4. Enter a comment in the Reason for unblocking field.
5. Select Unblock to finish unblocking the user.
Fraud alert
Configure the fraud alert feature so that your users can report fraudulent attempts to access their resources.
Users can report fraud attempts by using the mobile app or through their phone.
Turn on fraud alerts
2. Browse to Azure Active Directory > MFA > Fraud alert.
3. Set the Allow users to submit fraud alerts setting to On.
4. Select Save.
Configuration options
Block user when fraud is reported: If a user reports fraud, their account is blocked for 90 days or until an
administrator unblocks their account. An administrator can review sign-ins by using the sign-in report, and
take appropriate action to prevent future fraud. An administrator can then unblock the user's account.
Code to report fraud during initial greeting: When users receive a phone call to perform two-step
verification, they normally press # to confirm their sign-in. To report fraud, the user enters a code before
pressing #. This code is 0 by default, but you can customize it.
NOTE
The default voice greetings from Microsoft instruct users to press 0# to submit a fraud alert. If you want to use a
code other than 0, record and upload your own custom voice greetings with appropriate instructions for your users.
View fraud reports

2. Select Azure Active Directory > Sign-ins. The fraud report is now part of the standard Azure AD Sign-ins
report.
Notifications
Configure email addresses here for users who will receive fraud alert emails.
Phone call settings
Caller ID
MFA caller ID number - This is the number your users will see on their phone. Only US -based numbers are
allowed.
NOTE
When Multi-Factor Authentication calls are placed through the public telephone network, sometimes they are routed
through a carrier that doesn't support caller ID. Because of this, caller ID is not guaranteed, even though the Multi-Factor
Authentication system always sends it.
Custom voice messages

You can use your own recordings or greetings for two-step verification with the custom voice messages feature.
These messages can be used in addition to or to replace the Microsoft recordings.
Before you begin, be aware of the following restrictions:
The supported file formats are .wav and .mp3.
The file size limit is 5 MB.
Authentication messages should be shorter than 20 seconds. Messages that are longer than 20 seconds can
cause the verification to fail. The user might not respond before the message finishes and the verification times
out.
Custom message language behavior
When a custom voice message is played to the user, the language of the message depends on these factors:
The language of the current user.
The language detected by the user's browser.
Other authentication scenarios may behave differently.
The language of any available custom messages.
This language is chosen by the administrator, when a custom message is added.
For example, if there is only one custom message, with a language of German:
A user who authenticates in the German language will hear the custom German message.
A user who authenticates in English will hear the standard English message.
Set up a custom message
2. Browse to Azure Active Directory > MFA > Phone call settings.
3. Select Add greeting.
4. Choose the type of greeting.
5. Choose the language.
6. Select an .mp3 or .wav sound file to upload.
7. Select Add.
Custom voice message defaults
Sample scripts for creating custom messages.
MESSAGE NAME SCRIPT
Authentication successful Your sign in was successfully verified. Goodbye.
Extension prompt Thank you for using Microsoft's sign-in verification system.
Please press pound key to continue.
Fraud Confirmation A fraud alert has been submitted. To unblock your account,
please contact your company's IT help desk.
Fraud greeting (Standard) Thank you for using Microsoft's sign-in verification system.
Please press the pound key to finish your verification. If you
did not initiate this verification, someone may be trying to
access your account. Please press zero pound to submit a
fraud alert. This will notify your company's IT team and block
further verification attempts.
Fraud reported A fraud alert has been submitted. To unblock your account, please contact your company's IT
help desk.
Activation Thank you for using the Microsoft's sign-in verification

system. Please press the pound key to finish your verification.
Authentication denied retry Verification denied.
Retry (Standard) Thank you for using the Microsoft's sign-in verification
Greeting (Standard) Thank you for using the Microsoft's sign-in verification
Greeting (PIN) Thank you for using Microsoft's sign-in verification system.
Please enter your PIN followed by the pound key to finish
your verification.
Fraud greeting (PIN) Thank you for using Microsoft's sign-in verification system.
your verification. If you did not initiate this verification,
someone may be trying to access your account. Please press
zero pound to submit a fraud alert. This will notify your
company's IT team and block further verification attempts.
Retry(PIN) Thank you for using Microsoft's sign-in verification system.

your verification.
Extension prompt after digits If already at this extension, press the pound key to continue.
MESSAGE NAME SCRIPT
Authentication denied I'm sorry, we cannot sign you in at this time. Please try again
later.
Activation greeting (Standard) Thank you for using the Microsoft's sign-in verification
Activation retry (Standard) Thank you for using the Microsoft's sign-in verification
Activation greeting (PIN) Thank you for using Microsoft's sign-in verification system.
your verification.
Extension prompt before digits Thank you for using Microsoft's sign-in verification system.
Please transfer this call to extension …
One-time bypass
The one-time bypass feature allows a user to authenticate a single time without performing two-step verification.
The bypass is temporary and expires after a specified number of seconds. In situations where the mobile app or
phone is not receiving a notification or phone call, you can allow a one-time bypass so the user can access the
desired resource.
Create a one -time bypass
2. Browse to Azure Active Directory > MFA > One-time bypass.
3. Select Add.
4. If necessary, select the replication group for the bypass.
5. Enter the username as username@domain.com. Enter the number of seconds that the bypass should last.
Enter the reason for the bypass.
6. Select Add. The time limit goes into effect immediately. The user needs to sign in before the one-time bypass
expires.
View the one -time bypass report
2. Browse to Azure Active Directory > MFA > One-time bypass.
Caching rules
You can set a time period to allow authentication attempts after a user is authenticated by using the caching
feature. Subsequent authentication attempts for the user within the specified time period succeed automatically.
Caching is primarily used when on-premises systems, such as VPN, send multiple verification requests while the
first request is still in progress. This feature allows the subsequent requests to succeed automatically, after the
user succeeds the first verification in progress.
NOTE
The caching feature is not intended to be used for sign-ins to Azure Active Directory (Azure AD).
Set up caching
2. Browse to Azure Active Directory > MFA > Caching rules.
3. Select Add.
4. Select the cache type from the drop-down list. Enter the maximum number of cache seconds.
5. If necessary, select an authentication type and specify an application.
6. Select Add.
MFA service settings

Settings for app passwords, trusted IPs, verification options, and remember multi-factor authentication for Azure
Multi-Factor Authentication can be found in service settings. Service settings can be accessed from the Azure
portal by browsing to Azure Active Directory > MFA > Getting started > Configure > Additional cloud-
based MFA settings.
App passwords
Some applications, like Office 2010 or earlier and Apple Mail before iOS 11, don't support two-step verification.
The apps aren't configured to accept a second verification. To use these applications, take advantage of the app
passwords feature. You can use an app password in place of your traditional password to allow an app to bypass
two-step verification and continue working.
Modern authentication is supported for the Microsoft Office 2013 clients and later. Office 2013 clients including
Outlook, support modern authentication protocols and can be enabled to work with two-step verification. After
the client is enabled, app passwords aren't required for the client.
NOTE
App passwords do not work with Conditional Access based multi-factor authentication policies and modern authentication.
Considerations about app passwords

When using app passwords, consider the following important points:
App passwords are only entered once per application. Users don't have to keep track of the passwords or enter
them every time.
The actual password is automatically generated and is not supplied by the user. The automatically generated
password is harder for an attacker to guess and is more secure.
There is a limit of 40 passwords per user.
Applications that cache passwords and use them in on-premises scenarios can start to fail because the app
password isn't known outside the work or school account. An example of this scenario is Exchange emails that
are on-premises, but the archived mail is in the cloud. In this scenario, the same password doesn't work.
After Multi-Factor Authentication is enabled on a user's account, app passwords can be used with most non-
browser clients like Outlook and Microsoft Skype for Business. Administrative actions can't be performed by
using app passwords through non-browser applications, such as Windows PowerShell. The actions can't be
performed even when the user has an administrative account. To run PowerShell scripts, create a service
account with a strong password and don't enable the account for two-step verification.
WARNING
App passwords don't work in hybrid environments where clients communicate with both on-premises and cloud auto-
discover endpoints. Domain passwords are required to authenticate on-premises. App passwords are required to
authenticate with the cloud.
Guidance for app password names

App password names should reflect the device on which they're used. If you have a laptop that has non-browser
applications like Outlook, Word, and Excel, create one app password named Laptop for these apps. Create
another app password named Desktop for the same applications that run on your desktop computer.
NOTE
We recommend that you create one app password per device, rather than one app password per application.
Federated or single sign-on app passwords

Azure AD supports federation, or single sign-on (SSO ), with on-premises Windows Server Active Directory
Domain Services (AD DS ). If your organization is federated with Azure AD and you're using Azure Multi-Factor
Authentication, consider the following points about app passwords.
NOTE
The following points apply only to federated (SSO) customers.
App passwords are verified by Azure AD, and therefore, bypass federation. Federation is actively used only
when setting up app passwords.
The Identity Provider (IdP ) is not contacted for federated (SSO ) users, unlike the passive flow. The app
passwords are stored in the work or school account. If a user leaves the company, the user's information
flows to the work or school account by using DirSync in real time. The disable/deletion of the account can
take up to three hours to synchronize, which can delay the disable/deletion of the app password in Azure
AD.
On-premises client Access Control settings aren't honored by the app passwords feature.
No on-premises authentication logging/auditing capability is available for use with the app passwords
feature.
Some advanced architectures require a combination of credentials for two-step verification with clients.
These credentials can include a work or school account username and passwords, and app passwords. The
requirements depend on how the authentication is performed. For clients that authenticate against an on-
premises infrastructure, a work or school account username and password a required. For clients that
authenticate against Azure AD, an app password is required.
For example, suppose you have the following architecture:
Your on-premises instance of Active Directory is federated with Azure AD.
You're using Exchange online.
You're using Skype for Business on-premises.
You're using Azure Multi-Factor Authentication.
In this scenario, you use the following credentials:
To sign in to Skype for Business, use your work or school account username and password.
To access the address book from an Outlook client that connects to Exchange online, use an app
password.
Allow users to create app passwords
By default, users can't create app passwords. The app passwords feature must be enabled. To give users the ability
to create app passwords, use the following procedure:
2. On the left, select Azure Active Directory > Users and groups > All users.
4. Under Multi-Factor Authentication, select service settings.
5. On the Service Settings page, select the Allow users to create app passwords to sign in to non-browser
apps option.
Create app passwords
Users can create app passwords during their initial registration. The user has the option to create app passwords
at the end of the registration process.
Users can also create app passwords after registration. For more information and detailed steps for your users,
see What are app passwords in Azure Multi-Factor Authentication?
Trusted IPs
The Trusted IPs feature of Azure Multi-Factor Authentication is used by administrators of a managed or federated
tenant. The feature bypasses two-step verification for users who sign in from the company intranet. The feature is
available with the full version of Azure Multi-Factor Authentication, and not the free version for administrators.
For details on how to get the full version of Azure Multi-Factor Authentication, see Azure Multi-Factor
Authentication.
NOTE
MFA trusted IPs and Conditional Access named locations only work with IPV4 addresses.
If your organization deploys the NPS extension to provide MFA to on-premises applications note the source IP
address will always appear to be the NPS server the authentication attempt flows through.
AZURE AD TENANT TYPE TRUSTED IPS FEATURE OPTIONS
Managed Specific range of IP addresses: Administrators specify a

range of IP addresses that can bypass two-step verification
for users who sign in from the company intranet.
Federated All Federated Users: All federated users who sign in from
inside of the organization can bypass two-step verification.
The users bypass verification by using a claim that is issued by
Active Directory Federation Services (AD FS).
Specific range of IP addresses: Administrators specify a
range of IP addresses that can bypass two-step verification
for users who sign in from the company intranet.
The Trusted IPs bypass works only from inside of the company intranet. If you select the All Federated Users
option and a user signs in from outside the company intranet, the user has to authenticate by using two-step
verification. The process is the same even if the user presents an AD FS claim.
End-user experience inside of corpnet
When the Trusted IPs feature is disabled, two-step verification is required for browser flows. App passwords are
required for older rich client applications.
When the Trusted IPs feature is enabled, two-step verification is not required for browser flows. App passwords
are not required for older rich client applications, provided that the user hasn't created an app password. After an
app password is in use, the password remains required.
End-user experience outside corpnet
Regardless of whether the Trusted IPs feature is enabled, two-step verification is required for browser flows. App
passwords are required for older rich client applications.
Enable named locations by using Conditional Access
2. On the left, select Azure Active Directory > Conditional Access > Named locations.
3. Select New location.
4. Enter a name for the location.
5. Select Mark as trusted location.
6. Enter the IP Range in CIDR notation like 192.168.1.1/24.
7. Select Create.
Enable the Trusted IPs feature by using Conditional Access
2. On the left, select Azure Active Directory > Conditional Access > Named locations.
3. Select Configure MFA trusted IPs.
4. On the Service Settings page, under Trusted IPs, choose from any of the following two options:
For requests from federated users originating from my intranet: To choose this option, select
the check box. All federated users who sign in from the corporate network bypass two-step
verification by using a claim that is issued by AD FS. Ensure that AD FS has a rule to add the
intranet claim to the appropriate traffic. If the rule does not exist, create the following rule in AD FS:
c:[Type== "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork"] => issue(claim = c);
For requests from a specific range of public IPs: To choose this option, enter the IP addresses in
the text box by using CIDR notation.
For IP addresses that are in the range xxx.xxx.xxx.1 through xxx.xxx.xxx.254, use notation like
xxx.xxx.xxx.0/24.
For a single IP address, use notation like xxx.xxx.xxx.xxx/32.
Enter up to 50 IP address ranges. Users who sign in from these IP addresses bypass two-step
verification.
5. Select Save.
Enable the Trusted IPs feature by using service settings
2. On the left, select Azure Active Directory > Users.
5. On the Service Settings page, under Trusted IPs, choose one (or both) of the following two options:
For requests from federated users on my intranet: To choose this option, select the check box.
All federated users who sign in from the corporate network bypass two-step verification by using a
claim that is issued by AD FS. Ensure that AD FS has a rule to add the intranet claim to the
appropriate traffic. If the rule does not exist, create the following rule in AD FS:
c:[Type== "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork"] => issue(claim = c);
For requests from a specified range of IP address subnets: To choose this option, enter the IP
addresses in the text box by using CIDR notation.
For IP addresses that are in the range xxx.xxx.xxx.1 through xxx.xxx.xxx.254, use notation like
xxx.xxx.xxx.0/24.
For a single IP address, use notation like xxx.xxx.xxx.xxx/32.
Enter up to 50 IP address ranges. Users who sign in from these IP addresses bypass two-step
verification.
6. Select Save.
Verification methods
You can choose the verification methods that are available for your users. The following table provides a brief
overview of the methods.
When your users enroll their accounts for Azure Multi-Factor Authentication, they choose their preferred
verification method from the options that you have enabled. Guidance for the user enrollment process is provided
in Set up my account for two-step verification.
METHOD DESCRIPTION
METHOD DESCRIPTION
Call to phone Places an automated voice call. The user answers the call and
presses # in the phone keypad to authenticate. The phone
number is not synchronized to on-premises Active Directory.
Text message to phone Sends a text message that contains a verification code. The
user is prompted to enter the verification code into the sign-
in interface. This process is called one-way SMS. Two-way
SMS means that the user must text back a particular code.
Two-way SMS is deprecated and not supported after
November 14, 2018. Users who are configured for two-way
SMS are automatically switched to call to phone verification
at that time.
Notification through mobile app Sends a push notification to your phone or registered device.
The user views the notification and selects Verify to complete
verification. The Microsoft Authenticator app is available for
Windows Phone, Android, and iOS.
Verification code from mobile app or hardware token The Microsoft Authenticator app generates a new OATH
verification code every 30 seconds. The user enters the
verification code into the sign-in interface. The Microsoft
Authenticator app is available for Windows Phone, Android,
and iOS.
Enable and disable verification methods

5. On the Service Settings page, under verification options, select/unselect the methods to provide to your
users.
6. Click Save.
Additional details about the use of authentication methods can be found in the article What are authentication
methods.
Remember Multi-Factor Authentication

The remember Multi-Factor Authentication feature for devices and browsers that are trusted by the user is a free
feature for all Multi-Factor Authentication users. Users can bypass subsequent verifications for a specified number
of days, after they've successfully signed-in to a device by using Multi-Factor Authentication. The feature
enhances usability by minimizing the number of times a user has to perform two-step verification on the same
device.
IMPORTANT
If an account or device is compromised, remembering Multi-Factor Authentication for trusted devices can affect security. If a
corporate account becomes compromised or a trusted device is lost or stolen, you should restore Multi-Factor
Authentication on all devices.
The restore action revokes the trusted status from all devices, and the user is required to perform two-step verification
again. You can also instruct your users to restore Multi-Factor Authentication on their own devices with the instructions in
Manage your settings for two-step verification.
How the feature works
The remember Multi-Factor Authentication feature sets a persistent cookie on the browser when a user selects the
Don't ask again for X days option at sign-in. The user isn't prompted again for Multi-Factor Authentication from
that same browser until the cookie expires. If the user opens a different browser on the same device or clears their
cookies, they're prompted again to verify.
The Don't ask again for X days option isn't shown on non-browser applications, regardless of whether the app
supports modern authentication. These apps use refresh tokens that provide new access tokens every hour. When
a refresh token is validated, Azure AD checks that the last two-step verification occurred within the specified
number of days.
The feature reduces the number of authentications on web apps, which normally prompt every time. The feature
increases the number of authentications for modern authentication clients that normally prompt every 90 days.
May also increase the number of authentications when combined with Conditional Access policies.
IMPORTANT
The remember Multi-Factor Authentication feature is not compatible with the keep me signed in feature of AD FS,
when users perform two-step verification for AD FS through Azure Multi-Factor Authentication Server or a third-party
multi-factor authentication solution.
If your users select keep me signed in on AD FS and also mark their device as trusted for Multi-Factor Authentication, the
user isn't automatically verified after the remember multi-factor authentication number of days expires. Azure AD
requests a fresh two-step verification, but AD FS returns a token with the original Multi-Factor Authentication claim and
date, rather than performing two-step verification again. This reaction sets off a verification loop between Azure AD
and AD FS.
Enable remember Multi-Factor Authentication

5. On the Service Settings page, manage remember multi-factor authentication, select the Allow users to
remember multi-factor authentication on devices they trust option.
6. Set the number of days to allow trusted devices to bypass two-step verification. The default is 14 days.
7. Select Save.
Mark a device as trusted
After you enable the remember Multi-Factor Authentication feature, users can mark a device as trusted when they
sign in by selecting Don't ask again.
Next steps
Modify Azure AD sign-in page branding
Getting started with Azure Multi-Factor
Authentication and Active Directory Federation
Services
If your organization has federated your on-premises Active Directory with Azure Active Directory using AD FS,
there are two options for using Azure Multi-Factor Authentication.
Secure cloud resources using Azure Multi-Factor Authentication or Active Directory Federation Services
Secure cloud and on-premises resources using Azure Multi-Factor Authentication Server
The following table summarizes the verification experience between securing resources with Azure Multi-Factor
Authentication and AD FS
VERIFICATION EXPERIENCE - BROWSER-BASED APPS VERIFICATION EXPERIENCE - NON-BROWSER-BASED APPS
Securing Azure AD resources using Azure Multi-Factor The first verification step is performed on-premises using
Authentication AD FS.
The second step is a phone-based method carried out
using cloud authentication.
Securing Azure AD resources using Active Directory The first verification step is performed on-premises using
Federation Services AD FS.
The second step is performed on-premises by honoring the
claim.
Caveats with app passwords for federated users:

App passwords are verified using cloud authentication, so they bypass federation. Federation is only actively
used when setting up an app password.
On-premises Client Access Control settings are not honored by app passwords.
You lose on-premises authentication-logging capability for app passwords.
Account disable/deletion may take up to three hours for directory sync, delaying disable/deletion of app
passwords in the cloud identity.
For information on setting up either Azure Multi-Factor Authentication or the Azure Multi-Factor Authentication
Server with AD FS, see the following articles:
Secure cloud resources using Azure Multi-Factor Authentication and AD FS
Secure cloud and on-premises resources using Azure Multi-Factor Authentication Server with Windows Server
2012 R2 AD FS
Secure cloud and on-premises resources using Azure Multi-Factor Authentication Server with AD FS 2.0
Securing cloud resources with Azure Multi-Factor
Authentication and AD FS
If your organization is federated with Azure Active Directory, use Azure Multi-Factor Authentication or Active
Directory Federation Services (AD FS ) to secure resources that are accessed by Azure AD. Use the following
procedures to secure Azure Active Directory resources with either Azure Multi-Factor Authentication or Active
Directory Federation Services.
Secure Azure AD resources using AD FS

To secure your cloud resource, set up a claims rule so that Active Directory Federation Services emits the
multipleauthn claim when a user performs two-step verification successfully. This claim is passed on to Azure AD.
Follow this procedure to walk through the steps:
1. Open AD FS Management.
2. On the left, select Relying Party Trusts.
3. Right-click on Microsoft Office 365 Identity Platform and select Edit Claim Rules.
4. On Issuance Transform Rules, click Add Rule.

5. On the Add Transform Claim Rule Wizard, select Pass Through or Filter an Incoming Claim from the
drop-down and click Next.
6. Give your rule a name.

7. Select Authentication Methods References as the Incoming claim type.
8. Select Pass through all claim values.
9. Click Finish. Close the AD FS Management console.
Trusted IPs for federated users

Trusted IPs allow administrators to by-pass two-step verification for specific IP addresses, or for federated users
that have requests originating from within their own intranet. The following sections describe how to configure
Azure Multi-Factor Authentication Trusted IPs with federated users and by-pass two-step verification when a
request originates from within a federated users intranet. This is achieved by configuring AD FS to use a pass-
through or filter an incoming claim template with the Inside Corporate Network claim type.
This example uses Office 365 for our Relying Party Trusts.
Configure the AD FS claims rules
The first thing we need to do is to configure the AD FS claims. Create two claims rules, one for the Inside
Corporate Network claim type and an additional one for keeping our users signed in.
3. Right-click on Microsoft Office 365 Identity Platform and select Edit Claim Rules…
6. In the box next to Claim rule name, give your rule a name. For example: InsideCorpNet.
7. From the drop-down, next to Incoming claim type, select Inside Corporate Network.
8. Click Finish.
10. On the Add Transform Claim Rule Wizard, select Send Claims Using a Custom Rule from the drop-down
and click Next.
11. In the box under Claim rule name: enter Keep Users Signed In.
12. In the Custom rule box, enter:
c:[Type == "http://schemas.microsoft.com/2014/03/psso"]
=> issue(claim = c);
13. Click Finish.

14. Click Apply.
15. Click Ok.
16. Close AD FS Management.
Configure Azure Multi-Factor Authentication Trusted IPs with Federated Users
Now that the claims are in place, we can configure trusted IPs.
2. Select Azure Active Directory > Conditional Access > Named locations.
3. From the Conditional Access - Named locations blade, select Configure MFA trusted IPs
4. On the Service Settings page, under trusted IPs, select Skip multi-factor-authentication for requests
from federated users on my intranet.
5. Click save.
That’s it! At this point, federated Office 365 users should only have to use MFA when a claim originates from
outside the corporate intranet.
Integrate your existing NPS infrastructure with Azure
The Network Policy Server (NPS ) extension for Azure MFA adds cloud-based MFA capabilities to your
authentication infrastructure using your existing servers. With the NPS extension, you can add phone call, text
message, or phone app verification to your existing authentication flow without having to install, configure, and
maintain new servers.
This extension was created for organizations that want to protect VPN connections without deploying the Azure
MFA Server. The NPS extension acts as an adapter between RADIUS and cloud-based Azure MFA to provide a
second factor of authentication for federated or synced users.
When using the NPS extension for Azure MFA, the authentication flow includes the following components:
1. NAS/VPN Server receives requests from VPN clients and converts them into RADIUS requests to NPS
servers.
2. NPS Server connects to Active Directory to perform the primary authentication for the RADIUS requests and,
upon success, passes the request to any installed extensions.
3. NPS Extension triggers a request to Azure MFA for the secondary authentication. Once the extension
receives the response, and if the MFA challenge succeeds, it completes the authentication request by providing
the NPS server with security tokens that include an MFA claim, issued by Azure STS.
4. Azure MFA communicates with Azure Active Directory to retrieve the user’s details and performs the
secondary authentication using a verification method configured to the user.
The following diagram illustrates this high-level authentication request flow:
Plan your deployment
The NPS extension automatically handles redundancy, so you don't need a special configuration.
You can create as many Azure MFA-enabled NPS servers as you need. If you do install multiple servers, you
should use a difference client certificate for each one of them. Creating a cert for each server means that you can
update each cert individually, and not worry about downtime across all your servers.
VPN servers route authentication requests, so they need to be aware of the new Azure MFA-enabled NPS
servers.
Prerequisites
The NPS extension is meant to work with your existing infrastructure. Make sure you have the following
prerequisites before you begin.
Licenses
The NPS Extension for Azure MFA is available to customers with licenses for Azure Multi-Factor Authentication
(included with Azure AD Premium, EMS, or an MFA stand-alone license). Consumption-based licenses for Azure
MFA such as per user or per authentication licenses are not compatible with the NPS extension.
Software
Windows Server 2008 R2 SP1 or above.
Libraries
These libraries are installed automatically with the extension.
Visual C++ Redistributable Packages for Visual Studio 2013 (X64)
Microsoft Azure Active Directory Module for Windows PowerShell version 1.1.166.0
The Microsoft Azure Active Directory Module for Windows PowerShell is installed, if it is not already present,
through a configuration script you run as part of the setup process. There is no need to install this module ahead
of time if it is not already installed.
Azure Active Directory
Everyone using the NPS extension must be synced to Azure Active Directory using Azure AD Connect, and must
be registered for MFA.
When you install the extension, you need the directory ID and admin credentials for your Azure AD tenant. You
can find your directory ID in the Azure portal. Sign in as an administrator, select the Azure Active Directory icon
on the left, then select Properties. Copy the GUID in the Directory ID box and save it. You use this GUID as the
tenant ID when you install the NPS extension.
Network requirements
The NPS server needs to be able to communicate with the following URLs over ports 80 and 443.
https://adnotifications.windowsazure.com
https://login.microsoftonline.com
Additionally, connectivity to the following URLs is required to complete the setup of the adapter using the
provided PowerShell script
https://provisioningapi.microsoftonline.com
https://aadcdn.msauth.net
Prepare your environment

Before you install the NPS extension, you want to prepare you environment to handle the authentication traffic.
Enable the NPS role on a domain-joined server
The NPS server connects to Azure Active Directory and authenticates the MFA requests. Choose one server for
this role. We recommend choosing a server that doesn't handle requests from other services, because the NPS
extension throws errors for any requests that aren't RADIUS. The NPS server must be set up as the primary and
secondary authentication server for your environment; it cannot proxy RADIUS requests to another server.
1. On your server, open the Add Roles and Features Wizard from the Server Manager Quickstart menu.
2. Choose Role-based or feature-based installation for your installation type.
3. Select the Network Policy and Access Services server role. A window may pop up to inform you of
required features to run this role.
4. Continue through the wizard until the Confirmation page. Select Install.
Now that you have a server designated for NPS, you should also configure this server to handle incoming
RADIUS requests from the VPN solution.
Configure your VPN solution to communicate with the NPS server
Depending on which VPN solution you use, the steps to configure your RADIUS authentication policy vary.
Configure this policy to point to your RADIUS NPS server.
Sync domain users to the cloud
This step may already be complete on your tenant, but it's good to double-check that Azure AD Connect has
synchronized your databases recently.
2. Select Azure Active Directory > Azure AD Connect
3. Verify that your sync status is Enabled and that your last sync was less than an hour ago.
If you need to kick off a new round of synchronization, us the instructions in Azure AD Connect sync: Scheduler.
Determine which authentication methods your users can use
There are two factors that affect which authentication methods are available with an NPS extension deployment:
1. The password encryption algorithm used between the RADIUS client (VPN, Netscaler server, or other) and
the NPS servers.
PAP supports all the authentication methods of Azure MFA in the cloud: phone call, one-way text
message, mobile app notification, and mobile app verification code.
CHAPV2 and EAP support phone call and mobile app notification.
NOTE
When you deploy the NPS extension, use these factors to evaluate which methods are available for your
users. If your RADIUS client supports PAP, but the client UX doesn't have input fields for a verification code,
then phone call and mobile app notification are the two supported options.
In addition, if your VPN client UX does support input filed and you have configured Network Access Policy -
the authentication might succeed, however none of the RADIUS attributes configured in the Network Policy
will be applied to neither the Network Access Device, like the RRAS server, nor the VPN client. As a result, the
VPN client might have more access than desired or less to no access.
2. The input methods that the client application (VPN, Netscaler server, or other) can handle. For example,
does the VPN client have some means to allow the user to type in a verification code from a text or mobile
app?
You can disable unsupported authentication methods in Azure.
Register users for MFA
Before you deploy and use the NPS extension, users that are required to perform two-step verification need to be
registered for MFA. More immediately, to test the extension as you deploy it, you need at least one test account
that is fully registered for Multi-Factor Authentication.
Use these steps to get a test account started:
1. Sign in to https://aka.ms/mfasetup with a test account.
2. Follow the prompts to set up a verification method.
3. Create a Conditional Access policy to require multi-factor authentication for the test account.
Install the NPS extension

IMPORTANT
Install the NPS extension on a different server than the VPN access point.
Download and install the NPS extension for Azure MFA

1. Download the NPS Extension from the Microsoft Download Center.
2. Copy the binary to the Network Policy Server you want to configure.
3. Run setup.exe and follow the installation instructions. If you encounter errors, double-check that the two
libraries from the prerequisite section were successfully installed.
Upgrade the NPS extension
When upgrading an existing NPS extension install, to avoid a reboot of the underlying server complete the
following steps:
1. Uninstall the existing version
2. Run the new installer
3. Restart the Network Policy Server (IAS ) service
Run the PowerShell script
The installer creates a PowerShell script in this location: C:\Program Files\Microsoft\AzureMfa\Config (where C:\ is
your installation drive). This PowerShell script performs the following actions each time it is run:
Create a self-signed certificate.
Associate the public key of the certificate to the service principal on Azure AD.
Store the cert in the local machine cert store.
Grant access to the certificate’s private key to Network User.
Restart the NPS.
Unless you want to use your own certificates (instead of the self-signed certificates that the PowerShell script
generates), run the PowerShell Script to complete the installation. If you install the extension on multiple servers,
each one should have its own certificate.
1. Run Windows PowerShell as an administrator.
2. Change directories.
cd "C:\Program Files\Microsoft\AzureMfa\Config"
3. Run the PowerShell script created by the installer.

.\AzureMfaNpsExtnConfigSetup.ps1
4. Sign in to Azure AD as an administrator.

5. PowerShell prompts for your tenant ID. Use the Directory ID GUID that you copied from the Azure portal
in the prerequisites section.
6. PowerShell shows a success message when the script is finished.
Repeat these steps on any additional NPS servers that you want to set up for load balancing.
If your previous computer certificate has expired, and a new certificate has been generated, you should delete any
expired certificates. Having expired certificates can cause issues with the NPS Extension starting.
NOTE
If you use your own certificates instead of generating certificates with the PowerShell script, make sure that they align to the
NPS naming convention. The subject name must be CN=<TenantID>,OU=Microsoft NPS Extension.
Certificate rollover
With release 1.0.1.32 of the NPS extension, reading multiple certificates is now supported. This capability will help
facilitate rolling certificate updates prior to their expiration. If your organization is running a previous version of
the NPS extension, you should upgrade to version 1.0.1.32 or higher.
Certificates created by the AzureMfaNpsExtnConfigSetup.ps1 script are valid for 2 years. IT organizations should
monitor certificates for expiration. Certificates for the NPS extension are placed in the Local Computer certificate
store under Personal and are Issued To the tenant ID provided to the script.
When a certificate is approaching the expiration date, a new certificate should be created to replace it. This
process is accomplished by running the AzureMfaNpsExtnConfigSetup.ps1 again and keeping the same tenant ID
when prompted. This process should be repeated on each NPS server in your environment.
Configure your NPS extension

This section includes design considerations and suggestions for successful NPS extension deployments.
Configuration limitations
The NPS extension for Azure MFA does not include tools to migrate users and settings from MFA Server to
the cloud. For this reason, we suggest using the extension for new deployments, rather than existing
deployment. If you use the extension on an existing deployment, your users have to perform proof-up again to
populate their MFA details in the cloud.
The NPS extension uses the UPN from the on-premises Active directory to identify the user on Azure MFA for
performing the Secondary Auth. The extension can be configured to use a different identifier like alternate
login ID or custom Active Directory field other than UPN. For more information, see the article, Advanced
configuration options for the NPS extension for Multi-Factor Authentication.
Not all encryption protocols support all verification methods.
PAP supports phone call, one-way text message, mobile app notification, and mobile app verification
code
CHAPV2 and EAP support phone call and mobile app notification
Control RADIUS clients that require MFA
Once you enable MFA for a RADIUS client using the NPS Extension, all authentications for this client are required
to perform MFA. If you want to enable MFA for some RADIUS clients but not others, you can configure two NPS
servers and install the extension on only one of them. Configure RADIUS clients that you want to require MFA to
send requests to the NPS server configured with the extension, and other RADIUS clients to the NPS server not
configured with the extension.
Prepare for users that aren't enrolled for MFA
If you have users that aren't enrolled for MFA, you can determine what happens when they try to authenticate.
Use the registry setting REQUIRE_USER_MATCH in the registry path HKLM\Software\Microsoft\AzureMFA to
control the feature behavior. This setting has a single configuration option:
KEY VALUE DEFAULT
REQUIRE_USER_MATCH TRUE/FALSE Not set (equivalent to TRUE)
The purpose of this setting is to determine what to do when a user is not enrolled for MFA. When the key does
not exist, is not set, or is set to TRUE, and the user is not enrolled, then the extension fails the MFA challenge.
When the key is set to FALSE and the user is not enrolled, authentication proceeds without performing MFA. If a
user is enrolled in MFA, they must authenticate with MFA even if REQUIRE_USER_MATCH is set to FALSE.
You can choose to create this key and set it to FALSE while your users are onboarding, and may not all be enrolled
for Azure MFA yet. However, since setting the key permits users that aren't enrolled for MFA to sign in, you
should remove this key before going to production.
Troubleshooting
NPS extension health check script
The following script is available on the TechNet Gallery to perform basic health check steps when troubleshooting
the NPS extension.
MFA_NPS_Troubleshooter.ps1
How do I verify that the client cert is installed as expected?

Look for the self-signed certificate created by the installer in the cert store, and check that the private key has
permissions granted to user NETWORK SERVICE. The cert has a subject name of CN <tenantid>, OU =
Microsoft NPS Extension
Self-signed certificates generated by the AzureMfaNpsExtnConfigSetup.ps1 script also have a validity lifetime of
two years. When verifying that the certificate is installed, you should also check that the certificate has not expired.
How can I verify that my client cert is associated to my tenant in Azure Active Directory?
Open PowerShell command prompt and run the following commands:
import-module MSOnline
Connect-MsolService
Get-MsolServicePrincipalCredential -AppPrincipalId "981f26a1-7f43-403b-a875-f8b09b8cd720" -ReturnKeyValues 1
These commands print all the certificates associating your tenant with your instance of the NPS extension in your
PowerShell session. Look for your certificate by exporting your client cert as a "Base-64 encoded X.509(.cer)" file
without the private key, and compare it with the list from PowerShell.
The following command will create a file named "npscertificate" on your "C:" drive in format .cer.
import-module MSOnline
Connect-MsolService
Get-MsolServicePrincipalCredential -AppPrincipalId "981f26a1-7f43-403b-a875-f8b09b8cd720" -ReturnKeyValues 1 |
select -ExpandProperty "value" | out-file c:\npscertficicate.cer
Once you run this command, go to your C drive, locate the file and double-click on it. Go to details and scroll
down to "thumbprint", compare the thumbprint of the certificate installed on the server to this one. The certificate
thumbprints should match.
Valid-From and Valid-Until timestamps, which are in human-readable form, can be used to filter out obvious
misfits if the command returns more than one cert.
Why cant I sign in?

Check that your password hasn't expired. The NPS Extension does not support changing passwords as part of the
sign-in workflow. Contact your organization's IT Staff for further assistance.
Why are my requests failing with ADAL token error?

This error could be due to one of several reasons. Use these steps to help troubleshoot:
1. Restart your NPS server.
2. Verify that client cert is installed as expected.
3. Verify that the certificate is associated with your tenant on Azure AD.
4. Verify that https://login.microsoftonline.com/ is accessible from the server running the extension.
Why does authentication fail with an error in HTTP logs stating that the user is not found?
Verify that AD Connect is running, and that the user is present in both Windows Active Directory and Azure
Active Directory.
Why do I see HTTP connect errors in logs with all my authentications failing?
Verify that https://adnotifications.windowsazure.com is reachable from the server running the NPS extension.
Why is authentication not working, despite a valid certificate being present?

If your previous computer certificate has expired, and a new certificate has been generated, you should delete any
expired certificates. Having expired certificates can cause issues with the NPS Extension starting.
To check if you have a valid certificate, check the local Computer Account's Certificate Store using MMC, and
ensure the certificate has not passed its expiry date. To generate a newly valid certificate, rerun the steps under the
section "Run the PowerShell script"
Managing the TLS/SSL Protocols and Cipher Suites

It is recommended that older and weaker cipher suites be disabled or removed unless required by your
organization. Information on how to complete this task can be found in the article Managing SSL/TLS Protocols
and Cipher Suites for AD FS
Additional troubleshooting
Additional troubleshooting guidance and possible solutions can be found in the article Resolve error messages
from the NPS extension for Azure Multi-Factor Authentication.
Next steps
Configure alternate IDs for login, or set up an exception list for IPs that shouldn't perform two-step
verification in Advanced configuration options for the NPS extension for Multi-Factor Authentication
Learn how to integrate Remote Desktop Gateway and VPN servers using the NPS extension
Resolve error messages from the NPS extension for Azure Multi-Factor Authentication
Advanced configuration options for the NPS
extension for Multi-Factor Authentication
The Network Policy Server (NPS ) extension extends your cloud-based Azure Multi-Factor Authentication features
into your on-premises infrastructure. This article assumes that you already have the extension installed, and now
want to know how to customize the extension for you needs.
Alternate login ID
Since the NPS extension connects to both your on-premises and cloud directories, you might encounter an issue
where your on-premises user principal names (UPNs) don't match the names in the cloud. To solve this problem,
use alternate login IDs.
Within the NPS extension, you can designate an Active Directory attribute to be used in place of the UPN for
Azure Multi-Factor Authentication. This enables you to protect your on-premises resources with two-step
verification without modifying your on-premises UPNs.
To configure alternate login IDs, go to HKLM\SOFTWARE\Microsoft\AzureMfa and edit the following registry values:
NAME TYPE DEFAULT VALUE DESCRIPTION
LDAP_ALTERNATE_LOGINID string Empty Designate the name of

_ATTRIBUTE Active Directory attribute
that you want to use instead
of the UPN. This attribute is
used as the AlternateLoginId
attribute. If this registry
value is set to a valid Active
Directory attribute (for
example, mail or
displayName), then the
attribute's value is used in
place of the user's UPN for
authentication. If this
registry value is empty or
not configured, then
AlternateLoginId is disabled
and the user's UPN is used
for authentication.
LDAP_FORCE_GLOBAL_CAT boolean False Use this flag to force the use

ALOG of Global Catalog for LDAP
searches when looking up
AlternateLoginId. Configure
a domain controller as a
Global Catalog, add the
AlternateLoginId attribute to
the Global Catalog, and then
enable this flag.
If LDAP_LOOKUP_FORESTS
is configured (not empty),
this flag is enforced as
true, regardless of the value
of the registry setting. In
this case, the NPS extension
requires the Global Catalog
to be configured with the
AlternateLoginId attribute
for each forest.
LDAP_LOOKUP_FORESTS string Empty Provide a semi-colon

separated list of forests to
search. For example,
contoso.com;foobar.com. If
this registry value is
configured, the NPS
extension iteratively searches
all the forests in the order in
which they were listed, and
returns the first successful
AlternateLoginId value. If
this registry value is not
configured, the
AlternateLoginId lookup is
confined to the current
domain.
To troubleshoot problems with alternate login IDs, use the recommended steps for Alternate login ID errors.
IP exceptions
If you need to monitor server availability, like if load balancers verify which servers are running before sending
workloads, you don't want these checks to be blocked by verification requests. Instead, create a list of IP addresses
that you know are used by service accounts, and disable Multi-Factor Authentication requirements for that list.
To configure an IP allowed list, go to HKLM\SOFTWARE\Microsoft\AzureMfa and configure the following registry value:

IP_WHITELIST string Empty Provide a semi-colon

separated list of IP
addresses. Include the IP
addresses of machines
where service requests
originate, like the NAS/VPN
server. IP ranges and
subnets are not supported.
For example,
10.0.0.1;10.0.0.2;10.0.0.3.
When a request comes in from an IP address that exists in the IP_WHITELIST , two-step verification is skipped. The
IP list is compared to the IP address that is provided in the ratNASIPAddress attribute of the RADIUS request. If a
RADIUS request comes in without the ratNASIPAddress attribute, the following warning is logged:
"P_WHITE_LIST_WARNING::IP Whitelist is being ignored as source IP is missing in RADIUS request in
NasIpAddress attribute."
Next steps
Resolve error messages from the NPS extension for Azure Multi-Factor Authentication
Integrate Azure VPN gateway RADIUS authentication
with NPS server for Multi-Factor Authentication
The article describes how to integrate Network Policy Server (NPS ) with Azure VPN gateway RADIUS
authentication to deliver Multi-Factor Authentication (MFA) for point-to-site VPN connections.
Prerequisite
To enable MFA, the users must be in Azure Active Directory (Azure AD ), which must be synced from either the on-
premises or cloud environment. Also, the user must have already completed the auto-enrollment process for MFA.
For more information, see Set up my account for two-step verification
Detailed steps
Step 1: Create a virtual network gateway
1. Log on to the Azure portal.
2. In the virtual network that will host the virtual network gateway, select Subnets, and then select Gateway
subnet to create a subnet.
3. Create a virtual network gateway by specifying the following settings:

Gateway type: Select VPN.
VPN type: Select Route-based.
SKU: Select a SKU type based on your requirements.
Virtual network: Select the virtual network in which you created the gateway subnet.
Step 2 Configure the NPS for Azure MFA
1. On the NPS server, install the NPS extension for Azure MFA.
2. Open the NPS console, right-click RADIUS Clients, and then select New. Create the RADIUS client by
specifying the following settings:
Friendly Name: Type any name.
Address (IP or DNS ): Type the gateway subnet that you created in the Step 1.
Shared secret: type any secret key, and remember it for later use.
3. On the Advanced tab, set the vendor name to RADIUS Standard and make sure that the Additional
Options check box is not selected.
4. Go to Policies > Network Policies, double-click Connections to Microsoft Routing and Remote
Access server policy, select Grant access, and then click OK.
Step 3 Configure the virtual network gateway
1. Log on to Azure portal.
2. Open the virtual network gateway that you created. Make sure that the gateway type is set to VPN and that
the VPN type is route-based.
3. Click Point to site configuration > Configure now, and then specify the following settings:
Address pool: Type the gateway subnet you created in the step 1.
Authentication type: Select RADIUS authentication.
Server IP address: Type the IP address of the NPS server.
Next steps
Azure Multi-Factor Authentication
Integrate your existing NPS infrastructure with Azure Multi-Factor Authentication
Integrate your Remote Desktop Gateway
infrastructure using the Network Policy Server (NPS)
extension and Azure AD
This article provides details for integrating your Remote Desktop Gateway infrastructure with Azure Multi-Factor
Authentication (MFA) using the Network Policy Server (NPS ) extension for Microsoft Azure.
The Network Policy Server (NPS ) extension for Azure allows customers to safeguard Remote Authentication Dial-
In User Service (RADIUS ) client authentication using Azure’s cloud-based Multi-Factor Authentication (MFA). This
solution provides two-step verification for adding a second layer of security to user sign-ins and transactions.
This article provides step-by-step instructions for integrating the NPS infrastructure with Azure MFA using the
NPS extension for Azure. This enables secure verification for users attempting to sign in to a Remote Desktop
Gateway.
NOTE
This article should not be used with MFA Server deployments and should only be used with Azure MFA (Cloud-based)
deployments.
The Network Policy and Access Services (NPS ) gives organizations the ability to do the following:
Define central locations for the management and control of network requests by specifying who can connect,
what times of day connections are allowed, the duration of connections, and the level of security that clients
must use to connect, and so on. Rather than specifying these policies on each VPN or Remote Desktop (RD )
Gateway server, these policies can be specified once in a central location. The RADIUS protocol provides the
centralized Authentication, Authorization, and Accounting (AAA).
Establish and enforce Network Access Protection (NAP ) client health policies that determine whether devices
are granted unrestricted or restricted access to network resources.
Provide a means to enforce authentication and authorization for access to 802.1x-capable wireless access
points and Ethernet switches.
Typically, organizations use NPS (RADIUS ) to simplify and centralize the management of VPN policies. However,
many organizations also use NPS to simplify and centralize the management of RD Desktop Connection
Authorization Policies (RD CAPs).
Organizations can also integrate NPS with Azure MFA to enhance security and provide a high level of compliance.
This helps ensure that users establish two-step verification to sign in to the Remote Desktop Gateway. For users to
be granted access, they must provide their username/password combination along with information that the user
has in their control. This information must be trusted and not easily duplicated, such as a cell phone number,
landline number, application on a mobile device, and so on. RDG currently supports phone call and push
notifications from Microsoft authenticator app methods for 2FA. For more information about supported
authentication methods see the section Determine which authentication methods your users can use.
Prior to the availability of the NPS extension for Azure, customers who wished to implement two-step verification
for integrated NPS and Azure MFA environments had to configure and maintain a separate MFA Server in the on-
premises environment as documented in Remote Desktop Gateway and Azure Multi-Factor Authentication Server
using RADIUS.
The availability of the NPS extension for Azure now gives organizations the choice to deploy either an on-
premises based MFA solution or a cloud-based MFA solution to secure RADIUS client authentication.
Authentication Flow
For users to be granted access to network resources through a Remote Desktop Gateway, they must meet the
conditions specified in one RD Connection Authorization Policy (RD CAP ) and one RD Resource Authorization
Policy (RD RAP ). RD CAPs specify who is authorized to connect to RD Gateways. RD RAPs specify the network
resources, such as remote desktops or remote apps, that the user is allowed to connect to through the RD
Gateway.
An RD Gateway can be configured to use a central policy store for RD CAPs. RD RAPs cannot use a central policy,
as they are processed on the RD Gateway. An example of an RD Gateway configured to use a central policy store
for RD CAPs is a RADIUS client to another NPS server that serves as the central policy store.
When the NPS extension for Azure is integrated with the NPS and Remote Desktop Gateway, the successful
authentication flow is as follows:
1. The Remote Desktop Gateway server receives an authentication request from a remote desktop user to
connect to a resource, such as a Remote Desktop session. Acting as a RADIUS client, the Remote Desktop
Gateway server converts the request to a RADIUS Access-Request message and sends the message to the
RADIUS (NPS ) server where the NPS extension is installed.
2. The username and password combination is verified in Active Directory and the user is authenticated.
3. If all the conditions as specified in the NPS Connection Request and the Network Policies are met (for example,
time of day or group membership restrictions), the NPS extension triggers a request for secondary
authentication with Azure MFA.
4. Azure MFA communicates with Azure AD, retrieves the user’s details, and performs the secondary
authentication using supported methods.
5. Upon success of the MFA challenge, Azure MFA communicates the result to the NPS extension.
6. The NPS server, where the extension is installed, sends a RADIUS Access-Accept message for the RD CAP
policy to the Remote Desktop Gateway server.
7. The user is granted access to the requested network resource through the RD Gateway.
Prerequisites
This section details the prerequisites necessary before integrating Azure MFA with the Remote Desktop Gateway.
Before you begin, you must have the following prerequisites in place.
Remote Desktop Services (RDS ) infrastructure
Azure MFA License
Windows Server software
Network Policy and Access Services (NPS ) role
Azure Active Directory synched with on-premises Active Directory
Azure Active Directory GUID ID
Remote Desktop Services (RDS ) infrastructure
You must have a working Remote Desktop Services (RDS ) infrastructure in place. If you do not, then you can
quickly create this infrastructure in Azure using the following quickstart template: Create Remote Desktop Session
Collection deployment.
If you wish to manually create an on-premises RDS infrastructure quickly for testing purposes, follow the steps to
deploy one. Learn more: Deploy RDS with Azure quickstart and Basic RDS infrastructure deployment.
Azure MFA License
Required is a license for Azure MFA, which is available through Azure AD Premium or other bundles that include
it. Consumption-based licenses for Azure MFA, such as per user or per authentication licenses, are not compatible
with the NPS extension. For more information, see How to get Azure Multi-Factor Authentication. For testing
purposes, you can use a trial subscription.
The NPS extension requires Windows Server 2008 R2 SP1 or above with the NPS role service installed. All the
steps in this section were performed using Windows Server 2016.
Network Policy and Access Services (NPS ) role
The NPS role service provides the RADIUS server and client functionality as well as Network Access Policy health
service. This role must be installed on at least two computers in your infrastructure: The Remote Desktop Gateway
and another member server or domain controller. By default, the role is already present on the computer
configured as the Remote Desktop Gateway. You must also install the NPS role on at least on another computer,
such as a domain controller or member server.
For information on installing the NPS role service Windows Server 2012 or older, see Install a NAP Health Policy
Server. For a description of best practices for NPS, including the recommendation to install NPS on a domain
controller, see Best Practices for NPS.
Azure Active Directory synched with on-premises Active Directory
To use the NPS extension, on-premises users must be synced with Azure AD and enabled for MFA. This section
assumes that on-premises users are synched with Azure AD using AD Connect. For information on Azure AD
connect, see Integrate your on-premises directories with Azure Active Directory.
To install NPS extension, you need to know the GUID of the Azure AD. Instructions for finding the GUID of the
Azure AD are provided below.
Configure Multi-Factor Authentication

This section provides instructions for integrating Azure MFA with the Remote Desktop Gateway. As an
administrator, you must configure the Azure MFA service before users can self-register their multi-factor devices
or applications.
Follow the steps in Getting started with Azure Multi-Factor Authentication in the cloud to enable MFA for your
Azure AD users.
Configure accounts for two -step verification
Once an account has been enabled for MFA, you cannot sign in to resources governed by the MFA policy until you
have successfully configured a trusted device to use for the second authentication factor and have authenticated
using two-step verification.
Follow the steps in What does Azure Multi-Factor Authentication mean for me? to understand and properly
configure your devices for MFA with your user account.
Install and configure NPS extension

This section provides instructions for configuring RDS infrastructure to use Azure MFA for client authentication
with the Remote Desktop Gateway.
Acquire Azure Active Directory GUID ID
As part of the configuration of the NPS extension, you need to supply admin credentials and the Azure AD ID for
your Azure AD tenant. The following steps show you how to get the tenant ID.
1. Sign in to the Azure portal as the global administrator of the Azure tenant.
2. In the left navigation, select the Azure Active Directory icon.
3. Select Properties.
4. In the Properties blade, beside the Directory ID, click the Copy icon, as shown below, to copy the ID to
clipboard.

Install the NPS extension on a server that has the Network Policy and Access Services (NPS ) role installed. This
functions as the RADIUS server for your design.
IMPORTANT
Be sure you do not install the NPS extension on your Remote Desktop Gateway server.
1. Download the NPS extension.

2. Copy the setup executable file (NpsExtnForAzureMfaInstaller.exe) to the NPS server.
3. On the NPS server, double-click NpsExtnForAzureMfaInstaller.exe. If prompted, click Run.
4. In the NPS Extension For Azure MFA Setup dialog box, review the software license terms, check I agree to the
license terms and conditions, and click Install.
5. In the NPS Extension For Azure MFA Setup dialog box, click Close.
Configure certificates for use with the NPS extension using a PowerShell script
Next, you need to configure certificates for use by the NPS extension to ensure secure communications and
assurance. The NPS components include a Windows PowerShell script that configures a self-signed certificate for
use with NPS.
The script performs the following actions:
Creates a self-signed certificate
Associates public key of certificate to service principal on Azure AD
Stores the cert in the local machine store
Grants access to the certificate’s private key to the network user
Restarts Network Policy Server service
If you want to use your own certificates, you need to associate the public key of your certificate to the service
principal on Azure AD, and so on.
To use the script, provide the extension with your Azure AD Admin credentials and the Azure AD tenant ID that
you copied earlier. Run the script on each NPS server where you installed the NPS extension. Then do the
following:
1. Open an administrative Windows PowerShell prompt.
2. At the PowerShell prompt, type cd ‘c:\Program Files\Microsoft\AzureMfa\Config’ , and press ENTER.
3. Type .\AzureMfaNpsExtnConfigSetup.ps1 , and press ENTER. The script checks to see if the Azure Active
Directory PowerShell module is installed. If not installed, the script installs the module for you.
4. After the script verifies the installation of the PowerShell module, it displays the Azure Active Directory
PowerShell module dialog box. In the dialog box, enter your Azure AD admin credentials and password,
and click Sign In.
5. When prompted, paste the Directory ID you copied to the clipboard earlier, and press ENTER.
6. The script creates a self-signed certificate and performs other configuration changes. The output should be
like the image shown below.
Configure NPS components on Remote Desktop Gateway

In this section, you configure the Remote Desktop Gateway connection authorization policies and other RADIUS
settings.
The authentication flow requires that RADIUS messages be exchanged between the Remote Desktop Gateway
and the NPS server where the NPS Server is installed. This means that you must configure RADIUS client
settings on both Remote Desktop Gateway and the NPS server where the NPS extension is installed.
Configure Remote Desktop Gateway connection authorization policies to use central store
Remote Desktop connection authorization policies (RD CAPs) specify the requirements for connecting to a
Remote Desktop Gateway server. RD CAPs can be stored locally (default) or they can be stored in a central RD
CAP store that is running NPS. To configure integration of Azure MFA with RDS, you need to specify the use of a
central store.
1. On the RD Gateway server, open Server Manager.
2. On the menu, click Tools, point to Remote Desktop Services, and then click Remote Desktop Gateway
Manager.
3. In the RD Gateway Manager, right-click [Server Name] (Local), and click Properties.
4. In the Properties dialog box, select the RD CAP Store tab.
5. On the RD CAP Store tab, select Central server running NPS.
6. In the Enter a name or IP address for the server running NPS field, type the IP address or server name
of the server where you installed the NPS extension.
7. Click Add.
8. In the Shared Secret dialog box, enter a shared secret, and then click OK. Ensure you record this shared
secret and store the record securely.
NOTE
Shared secret is used to establish trust between the RADIUS servers and clients. Create a long and complex secret.
9. Click OK to close the dialog box.
Configure RADIUS timeout value on Remote Desktop Gateway NPS
To ensure there is time to validate users’ credentials, perform two-step verification, receive responses, and respond
to RADIUS messages, it is necessary to adjust the RADIUS timeout value.
1. On the RD Gateway server, open Server Manager. On the menu, click Tools, and then click Network
Policy Server.
2. In the NPS (Local) console, expand RADIUS Clients and Servers, and select Remote RADIUS Server.
3. In the details pane, double-click TS GATEWAY SERVER GROUP.
NOTE
This RADIUS Server Group was created when you configured the central server for NPS policies. The RD Gateway
forwards RADIUS messages to this server or group of servers, if more than one in the group.
4. In the TS GATEWAY SERVER GROUP Properties dialog box, select the IP address or name of the NPS
server you configured to store RD CAPs, and then click Edit.
5. In the Edit RADIUS Server dialog box, select the Load Balancing tab.
6. In the Load Balancing tab, in the Number of seconds without response before request is considered
dropped field, change the default value from 3 to a value between 30 and 60 seconds.
7. In the Number of seconds between requests when server is identified as unavailable field, change
the default value of 30 seconds to a value that is equal to or greater than the value you specified in the
previous step.
8. Click OK two times to close the dialog boxes.

Verify Connection Request Policies
By default, when you configure the RD Gateway to use a central policy store for connection authorization policies,
the RD Gateway is configured to forward CAP requests to the NPS server. The NPS server with the Azure MFA
extension installed, processes the RADIUS access request. The following steps show you how to verify the default
connection request policy.
1. On the RD Gateway, in the NPS (Local) console, expand Policies, and select Connection Request
Policies.
2. Double-click TS GATEWAY AUTHORIZATION POLICY.
3. In the TS GATEWAY AUTHORIZATION POLICY properties dialog box, click the Settings tab.
4. On Settings tab, under Forwarding Connection Request, click Authentication. RADIUS client is
configured to forward requests for authentication.
5. Click Cancel.
Configure NPS on the server where the NPS extension is installed

The NPS server where the NPS extension is installed needs to be able to exchange RADIUS messages with the
NPS server on the Remote Desktop Gateway. To enable this message exchange, you need to configure the NPS
components on the server where the NPS extension service is installed.
Register Server in Active Directory
To function properly in this scenario, the NPS server needs to be registered in Active Directory.
1. On the NPS server, open Server Manager.
2. In Server Manager, click Tools, and then click Network Policy Server.
3. In the Network Policy Server console, right-click NPS (Local), and then click Register server in Active
Directory.
4. Click OK two times.
5. Leave the console open for the next procedure.
Create and configure RADIUS client
The Remote Desktop Gateway needs to be configured as a RADIUS client to the NPS server.
1. On the NPS server where the NPS extension is installed, in the NPS (Local) console, right-click RADIUS
Clients and click New.
2. In the New RADIUS Client dialog box, provide a friendly name, such as Gateway, and the IP address or
DNS name of the Remote Desktop Gateway server.
3. In the Shared secret and the Confirm shared secret fields, enter the same secret that you used before.
4. Click OK to close the New RADIUS Client dialog box.
Configure Network Policy
Recall that the NPS server with the Azure MFA extension is the designated central policy store for the Connection
Authorization Policy (CAP ). Therefore, you need to implement a CAP on the NPS server to authorize valid
connections requests.
1. On the NPS Server, open the NPS (Local) console, expand Policies, and click Network Policies.
2. Right-click Connections to other access servers, and click Duplicate Policy.
3. Right-click Copy of Connections to other access servers, and click Properties.

4. In the Copy of Connections to other access servers dialog box, in Policy name, enter a suitable name,
such as RDG_CAP. Check Policy enabled, and select Grant access. Optionally, in Type of network
access server, select Remote Desktop Gateway, or you can leave it as Unspecified.
5. Click the Constraints tab, and check Allow clients to connect without negotiating an authentication
method.
6. Optionally, click the Conditions tab and add conditions that must be met for the connection to be
authorized, for example, membership in a specific Windows group.
7. Click OK. When prompted to view the corresponding Help topic, click No.
8. Ensure that your new policy is at the top of the list, that the policy is enabled, and that it grants access.
Verify configuration
To verify the configuration, you need to sign in to the Remote Desktop Gateway with a suitable RDP client. Be sure
to use an account that is allowed by your Connection Authorization Policies and is enabled for Azure MFA.
As show in the image below, you can use the Remote Desktop Web Access page.
Upon successfully entering your credentials for primary authentication, the Remote Desktop Connect dialog box
shows a status of Initiating remote connection, as shown below.
If you successfully authenticate with the secondary authentication method you previously configured in Azure
MFA, you are connected to the resource. However, if the secondary authentication is not successful, you are denied
access to the resource.
In the example below, the Authenticator app on a Windows phone is used to provide the secondary authentication.
Once you have successfully authenticated using the secondary authentication method, you are logged into the
Remote Desktop Gateway as normal. However, because you are required to use a secondary authentication
method using a mobile app on a trusted device, the sign in process is more secure than it would be otherwise.
View Event Viewer logs for successful logon events
To view the successful sign-in events in the Windows Event Viewer logs, you can issue the following Windows
PowerShell command to query the Windows Terminal Services and Windows Security logs.
To query successful sign-in events in the Gateway operational logs (Event Viewer\Applications and Services
Logs\Microsoft\Windows\TerminalServices-Gateway\Operational), use the following PowerShell commands:
Get-WinEvent -Logname Microsoft-Windows-TerminalServices-Gateway/Operational | where {$_.ID -eq '300'} | FL
This command displays Windows events that show the user met resource authorization policy requirements
(RD RAP ) and was granted access.
Get-WinEvent -Logname Microsoft-Windows-TerminalServices-Gateway/Operational | where {$_.ID -eq '200'} | FL
This command displays the events that show when user met connection authorization policy requirements.
You can also view this log and filter on event IDs, 300 and 200. To query successful logon events in the Security
event viewer logs, use the following command:
Get-WinEvent -Logname Security | where {$_.ID -eq '6272'} | FL
This command can be run on either the central NPS or the RD Gateway Server.
You can also view the Security log or the Network Policy and Access Services custom view, as shown below:
On the server where you installed the NPS extension for Azure MFA, you can find Event Viewer application logs
specific to the extension at Application and Services Logs\Microsoft\AzureMfa.
Troubleshoot Guide
If the configuration is not working as expected, the first place to start to troubleshoot is to verify that the user is
configured to use Azure MFA. Have the user connect to the Azure portal. If users are prompted for secondary
verification and can successfully authenticate, you can eliminate an incorrect configuration of Azure MFA.
If Azure MFA is working for the user(s), you should review the relevant Event logs. These include the Security
Event, Gateway operational, and Azure MFA logs that are discussed in the previous section.
Below is an example output of Security log showing a failed logon event (Event ID 6273).
Below is a related event from the AzureMFA logs:
To perform advanced troubleshoot options, consult the NPS database format log files where the NPS service is
installed. These log files are created in %SystemRoot%\System32\Logs folder as comma-delimited text files.
For a description of these log files, see Interpret NPS Database Format Log Files. The entries in these log files can
be difficult to interpret without importing them into a spreadsheet or a database. You can find several IAS parsers
online to assist you in interpreting the log files.
The image below shows the output of one such downloadable shareware application.
Finally, for additional troubleshoot options, you can use a protocol analyzer, such Microsoft Message Analyzer.
The image below from Microsoft Message Analyzer shows network traffic filtered on RADIUS protocol that
contains the user name CONTOSO\AliceC.
Next steps
How to get Azure Multi-Factor Authentication
Remote Desktop Gateway and Azure Multi-Factor Authentication Server using RADIUS
Integrate your on-premises directories with Azure Active Directory
Integrate your VPN infrastructure with Azure MFA by
using the Network Policy Server extension for Azure
The Network Policy Server (NPS ) extension for Azure allows organizations to safeguard Remote Authentication
Dial-In User Service (RADIUS ) client authentication using cloud-based Azure Multi-Factor Authentication (MFA),
which provides two-step verification.
This article provides instructions for integrating NPS infrastructure with MFA by using the NPS extension for
Azure. This process enables secure two-step verification for users who attempt to connect to your network by
using a VPN.
Network Policy and Access Services gives organizations the ability to:
Assign a central location for the management and control of network requests to specify:
Who can connect
What times of day connections are allowed
The duration of connections
The level of security that clients must use to connect
Rather than specify policies on each VPN or Remote Desktop Gateway server, do so after they're in a
central location. The RADIUS protocol is used to provide centralized Authentication, Authorization,
and Accounting (AAA).
Establish and enforce Network Access Protection (NAP ) client health policies that determine whether
devices are granted unrestricted or restricted access to network resources.
Provide a way to enforce authentication and authorization for access to 802.1x-capable wireless access
points and Ethernet switches. For more information, see Network Policy Server.
To enhance security and provide a high level of compliance, organizations can integrate NPS with Azure Multi-
Factor Authentication to ensure that users use two-step verification to connect to the virtual port on the VPN
server. For users to be granted access, they must provide their username and password combination and other
information that they control. This information must be trusted and not easily duplicated. It can include a cell
phone number, a landline number, or an application on a mobile device.
Prior to the availability of the NPS extension for Azure, customers who wanted to implement two-step verification
for integrated NPS and MFA environments had to configure and maintain a separate MFA server in an on-
premises environment. This type of authentication is offered by Remote Desktop Gateway and Azure Multi-Factor
Authentication Server using RADIUS.
With the NPS extension for Azure, organizations can secure RADIUS client authentication by deploying either an
on-premises based MFA solution or a cloud-based MFA solution.
Authentication flow
When users connect to a virtual port on a VPN server, they must first authenticate by using a variety of protocols.
The protocols allow the use of a combination of user name and password and certificate-based authentication
methods.
In addition to authenticating and verifying their identity, users must have the appropriate dial-in permissions. In
simple implementations, dial-in permissions that allow access are set directly on the Active Directory user objects.
In simple implementations, each VPN server grants or denies access based on policies that are defined on each
local VPN server.
In larger and more scalable implementations, the policies that grant or deny VPN access are centralized on
RADIUS servers. In these cases, the VPN server acts as an access server (RADIUS client) that forwards
connection requests and account messages to a RADIUS server. To connect to the virtual port on the VPN server,
users must be authenticated and meet the conditions that are defined centrally on RADIUS servers.
When the NPS extension for Azure is integrated with the NPS, a successful authentication flow results, as follows:
1. The VPN server receives an authentication request from a VPN user that includes the username and password
for connecting to a resource, such as a Remote Desktop session.
2. Acting as a RADIUS client, the VPN server converts the request to a RADIUS Access-Request message and
sends it (with an encrypted password) to the RADIUS server where the NPS extension is installed.
3. The username and password combination is verified in Active Directory. If either the username or password is
incorrect, the RADIUS Server sends an Access-Reject message.
4. If all conditions, as specified in the NPS Connection Request and Network Policies, are met (for example, time
of day or group membership restrictions), the NPS extension triggers a request for secondary authentication
with Azure Multi-Factor Authentication.
5. Azure Multi-Factor Authentication communicates with Azure Active Directory, retrieves the user’s details, and
performs the secondary authentication by using the method that's configured by the user (cell phone call, text
message, or mobile app).
6. When the MFA challenge is successful, Azure Multi-Factor Authentication communicates the result to the NPS
extension.
7. After the connection attempt is both authenticated and authorized, the NPS where the extension is installed
sends a RADIUS Access-Accept message to the VPN server (RADIUS client).
8. The user is granted access to the virtual port on the VPN server and establishes an encrypted VPN tunnel.
Prerequisites
This section details the prerequisites that must be completed before you can integrate MFA with the VPN. Before
you begin, you must have the following prerequisites in place:
VPN infrastructure
Network Policy and Access Services role
Azure Multi-Factor Authentication license
Libraries
Azure Active Directory (Azure AD ) synced with on-premises Active Directory
VPN infrastructure
This article assumes that you have a working VPN infrastructure that uses Microsoft Windows Server 2016 and
that your VPN server is currently not configured to forward connection requests to a RADIUS server. In the
article, you configure the VPN infrastructure to use a central RADIUS server.
If you do not have a working VPN infrastructure in place, you can quickly create one by following the guidance in
numerous VPN setup tutorials that you can find on the Microsoft and third-party sites.
The Network Policy and Access Services role
Network Policy and Access Services provides the RADIUS server and client functionality. This article assumes that
you have installed the Network Policy and Access Services role on a member server or domain controller in your
environment. In this guide, you configure RADIUS for a VPN configuration. Install the Network Policy and Access
Services role on a server other than your VPN server.
For information about installing the Network Policy and Access Services role service Windows Server 2012 or
later, see Install a NAP Health Policy Server. NAP is deprecated in Windows Server 2016. For a description of best
practices for NPS, including the recommendation to install NPS on a domain controller, see Best practices for
NPS.
Azure MFA License
A license is required for Azure Multi-Factor Authentication, and it is available through an Azure AD Premium,
Enterprise Mobility + Security, or a Multi-Factor Authentication stand-alone license. Consumption-based licenses
for Azure MFA such as per user or per authentication licenses are not compatible with the NPS extension. For
more information, see How to get Azure Multi-Factor Authentication. For testing purposes, you can use a trial
subscription.
The NPS extension requires Windows Server 2008 R2 SP1 or later, with the Network Policy and Access Services
role installed. All the steps in this guide were performed with Windows Server 2016.
Libraries
The following libraries are installed automatically with the NPS extension:
Visual C++ Redistributable Packages for Visual Studio 2013 (X64)
Microsoft Azure Active Directory Module for Windows PowerShell version 1.1.166.0
If the Microsoft Azure Active Directory PowerShell Module is not already present, it is installed with a
configuration script that you run as part of the setup process. There is no need to install the module ahead of time
if it is not already installed.
Azure Active Directory synced with on-premises Active Directory
To use the NPS extension, on-premises users must be synced with Azure Active Directory and enabled for MFA.
This guide assumes that on-premises users are synced with Azure Active Directory via Azure AD Connect.
Instructions for enabling users for MFA are provided below.
For information about Azure AD Connect, see Integrate your on-premises directories with Azure Active Directory.
To install the NPS extension, you need to know the GUID of the Azure Active Directory. Instructions for finding the
GUID of the Azure Active Directory are provided in the next section.
Configure RADIUS for VPN connections

If you have installed the NPS role on a member server, you need to configure it to authenticate and authorize the
VPN client that requests VPN connections.
This section assumes that you have installed the Network Policy and Access Services role but have not configured
it for use in your infrastructure.
NOTE
If you already have a working VPN server that uses a centralized RADIUS server for authentication, you can skip this section.
Register Server in Active Directory

To function properly in this scenario, the NPS server must be registered in Active Directory.
1. Open Server Manager.
2. In Server Manager, select Tools, and then select Network Policy Server.
3. In the Network Policy Server console, right-click NPS (Local), and then select Register server in Active
Directory. Select OK two times.
4. Leave the console open for the next procedure.

Use wizard to configure the RADIUS server
You can use a standard (wizard-based) or advanced configuration option to configure the RADIUS server. This
section assumes that you're using the wizard-based standard configuration option.
1. In the Network Policy Server console, select NPS (Local).
2. Under Standard Configuration, select RADIUS Server for Dial-Up or VPN Connections, and then
select Configure VPN or Dial-Up.
3. In the Select Dial-up or Virtual Private Network Connections Type window, select Virtual Private
Network Connections, and then select Next.
4. In the Specify Dial-Up or VPN Server window, select Add.

5. In the New RADIUS client window, provide a friendly name, enter the resolvable name or IP address of
the VPN server, and then enter a shared secret password. Make the shared secret password long and
complex. Record it, because you'll need it in the next section.
6. Select OK, and then select Next.
7. In the Configure Authentication Methods window, accept the default selection (Microsoft Encrypted
Authentication version 2 [MS -CHAPv2]) or choose another option, and select Next.
NOTE
If you configure Extensible Authentication Protocol (EAP), you must use either Microsoft Challenge-Handshake
Authentication Protocol (CHAPv2) or Protected Extensible Authentication Protocol (PEAP). No other EAP is
supported.
8. In the Specify User Groups window, select Add, and then select an appropriate group. If no group exists,
leave the selection blank to grant access to all users.
9. Select Next.
10. In the Specify IP Filters window, select Next.
11. In the Specify Encryption Settings window, accept the default settings, and then select Next.
12. In the Specify a Realm Name window, leave the realm name blank, accept the default setting, and then
select Next.
13. In the Completing New Dial-up or Virtual Private Network Connections and RADIUS clients
window, select Finish.
Verify the RADIUS configuration
This section details the configuration you created by using the wizard.
1. On the Network Policy Server, in the NPS (local) console, expand RADIUS Clients, and then select
RADIUS Clients.
2. In the details pane, right-click the RADIUS client that you created, and then select Properties. The
properties of your RADIUS client (the VPN server) should be like those shown here:
3. Select Cancel.
4. On the Network Policy Server, in the NPS (local) console, expand Policies, and then select Connection
Request Policies. The VPN Connections policy is displayed as shown in the following image:
5. Under Policies, select Network Policies. You should see a Virtual Private Network (VPN ) Connections
policy that resembles the policy shown in the following image:
Configure your VPN server to use RADIUS authentication
In this section, you configure your VPN server to use RADIUS authentication. The instructions assume that you
have a working configuration of a VPN server but have not configured it to use RADIUS authentication. After you
configure the VPN server, confirm that your configuration is working as expected.
NOTE
If you already have a working VPN server configuration that uses RADIUS authentication, you can skip this section.
Configure authentication provider

1. On the VPN server, open Server Manager.
2. In Server Manager, select Tools, and then select Routing and Remote Access.
3. In the Routing and Remote Access window, right-click <server name> (local), and then select
Properties.
4. In the <server name> (local) Properties window, select the Security tab.
5. On the Security tab, under Authentication provider, select RADIUS Authentication, and then select
Configure.
6. In the RADIUS Authentication window, select Add.
7. In the Add RADIUS Server window, do the following:
a. In the Server name box, enter the name or IP address of the RADIUS server that you configured in the
previous section.
b. For the Shared secret, select Change, and then enter the shared secret password that you created and
recorded earlier.
c. In the Time-out (seconds) box, enter a value of 30.
The timeout value is necessary to allow enough time to complete the second authentication factor.
8. Select OK.
Test VPN connectivity
In this section, you confirm that the VPN client is authenticated and authorized by the RADIUS server when you
attempt to connect to the VPN virtual port. The instructions assume that you are using Windows 10 as a VPN
client.
NOTE
If you already configured a VPN client to connect to the VPN server and have saved the settings, you can skip the steps
related to configuring and saving a VPN connection object.
1. On your VPN client computer, select the Start button, and then select the Settings button.
2. In the Windows Settings window, select Network & Internet.
3. Select VPN.
4. Select Add a VPN connection.
5. In the Add a VPN connection window, in the VPN provider box, select Windows (built-in), complete
the remaining fields, as appropriate, and then select Save.
6. Go to Control Panel, and then select Network and Sharing Center.

7. Select Change adapter settings.
8. Right-click the VPN network connection, and then select Properties.
9. In the VPN properties window, select the Security tab.
10. On the Security tab, ensure that only Microsoft CHAP Version 2 (MS -CHAP v2) is selected, and then
select OK.
11. Right-click the VPN connection, and then select Connect.

12. In the Settings window, select Connect.
A successful connection appears in the Security log, on the RADIUS server, as Event ID 6272, as shown
here:
Troubleshooting RADIUS
Assume that your VPN configuration was working before you configured the VPN server to use a centralized
RADIUS server for authentication and authorization. If the configuration was working, it is likely that the issue is
caused by a misconfiguration of the RADIUS server or the use of an invalid username or password. For example,
if you use the alternate UPN suffix in the username, the sign-in attempt might fail. Use the same account name for
best results.
To troubleshoot these issues, an ideal place to start is to examine the Security event logs on the RADIUS server. To
save time searching for events, you can use the role-based Network Policy and Access Server custom view in
Event Viewer, as shown here. "Event ID 6273" indicates events where the NPS denied access to a user.
Configure Multi-Factor Authentication
For assistance configuring users for Multi-Factor Authentication see the articles Planning a cloud-based Azure
Multi-Factor Authentication deployment and Set up my account for two-step verification
Install and configure the NPS extension

This section provides instructions for configuring VPN to use MFA for client authentication with the VPN server.
After you install and configure the NPS extension, all RADIUS -based client authentication that is processed by this
server is required to use MFA. If all your VPN users are not enrolled in Azure Multi-Factor Authentication, you can
do either of the following:
Set up another RADIUS server to authenticate users who are not configured to use MFA.
Create a registry entry that allows challenged users to provide a second authentication factor if they are
enrolled in Azure Multi-Factor Authentication.
Create a new string value named REQUIRE_USER_MATCH in HKLM\SOFTWARE\Microsoft\AzureMfa, and set
the value to True or False.
If the value is set to True or is blank, all authentication requests are subject to an MFA challenge. If the value is set
to False, MFA challenges are issued only to users who are enrolled in Azure Multi-Factor Authentication. Use the
False setting only in testing or in production environments during an onboarding period.
Obtain the Azure Active Directory GUID ID
As part of the configuration of the NPS extension, you must supply administrator credentials and the ID of your
Azure AD tenant. Obtain the ID by doing the following:
1. Sign in to the Azure portal as the global administrator of the Azure tenant.
2. In the left pane, select the Azure Active Directory button.
3. Select Properties.
4. To copy your Azure AD ID, select the Copy button.
The NPS extension must be installed on a server that has the Network Policy and Access Services role installed
and that functions as the RADIUS server in your design. Do not install the NPS extension on your VPN server.
1. Download the NPS extension from Microsoft Download Center.
2. Copy the setup executable file (NpsExtnForAzureMfaInstaller.exe) to the NPS server.
3. On the NPS server, double-click NpsExtnForAzureMfaInstaller.exe and, if you are prompted, select Run.
4. In the NPS Extension For Azure MFA Setup window, review the software license terms, select the I
agree to the license terms and conditions check box, and then select Install.
5. In the NPS Extension For Azure MFA Setup window, select Close.
Configure certificates for use with the NPS extension by using a PowerShell script
To ensure secure communications and assurance, configure certificates for use by the NPS extension. The NPS
components include a Windows PowerShell script that configures a self-signed certificate for use with NPS.
The script performs the following actions:
Creates a self-signed certificate.
Associates the public key of the certificate to the service principal on Azure AD.
Stores the certificate in the local machine store.
Grants the network user access to the certificate’s private key.
Restarts the NPS service.
If you want to use your own certificates, you must associate the public key of your certificate with the service
principal on Azure AD, and so on.
To use the script, provide the extension with your Azure Active Directory administrative credentials and the Azure
Active Directory tenant ID that you copied earlier. Run the script on each NPS server where you install the NPS
extension.
1. Run Windows PowerShell as an administrator.
2. At the PowerShell command prompt, enter cd "c:\Program Files\Microsoft\AzureMfa\Config", and
then select Enter.
3. At the next command prompt, enter .\AzureMfaNpsExtnConfigSetup.ps1, and then select Enter. The
script checks to see whether the Azure AD PowerShell module is installed. If it is not installed, the script
installs the module for you.
After the script verifies the installation of the PowerShell module, it displays the Azure Active Directory
PowerShell module sign-in window.
4. Enter your Azure AD administrator credentials and password, and then select Sign in.
5. At the command prompt, paste the tenant ID that you copied earlier, and then select Enter.
The script creates a self-signed certificate and performs other configuration changes. The output is like that
in the following image:
6. Reboot the server.
Verify the configuration
To verify the configuration, you must establish a new VPN connection with the VPN server. After you've
successfully entered your credentials for primary authentication, the VPN connection waits for the secondary
authentication to succeed before the connection is established, as shown below.
If you successfully authenticate with the secondary verification method that you previously configured in Azure
MFA, you are connected to the resource. However, if the secondary authentication is unsuccessful, you are denied
access to the resource.
In the following example, the Microsoft Authenticator app on a Windows Phone provides the secondary
authentication:
After you've successfully authenticated by using the secondary method, you are granted access to the virtual port
on the VPN server. Because you were required to use a secondary authentication method by using a mobile app
on a trusted device, the sign-in process is more secure than if it were using only a username and password
combination.
View Event Viewer logs for successful sign-in events
To view successful sign-in events in the Windows Event Viewer logs query the Windows Security log, on the NPS
server, by entering the following PowerShell command:
`Get-WinEvent -Logname Security | where {$_.ID -eq '6272'} | FL`
You can also view the security log or the Network Policy and Access Services custom view, as shown here:
On the server where you installed the NPS extension for Azure Multi-Factor Authentication, you can find Event
Viewer application logs that are specific to the extension at Application and Services Logs\Microsoft\AzureMfa.
`Get-WinEvent -Logname Security | where {$_.ID -eq '6272'} | FL`
Troubleshooting guide
If the configuration is not working as expected, begin troubleshooting by verifying that the user is configured to
use MFA. Have the user connect to the Azure portal. If the user is prompted for secondary authentication and can
successfully authenticate, you can eliminate an incorrect configuration of MFA as an issue.
If MFA is working for the user, review the relevant Event Viewer logs. The logs include the security event, Gateway
operational, and Azure Multi-Factor Authentication logs that are discussed in the previous section.
An example of a security log that displays a failed sign-in event (event ID 6273) is shown here:
A related event from the Azure Multi-Factor Authentication log is shown here:
To do advanced troubleshooting, consult the NPS database format log files where the NPS service is installed. The
log files are created in the %SystemRoot%\System32\Logs folder as comma-delimited text files. For a description
of the log files, see Interpret NPS Database Format Log Files.
The entries in these log files are difficult to interpret unless you export them to a spreadsheet or a database. You
can find many Internet Authentication Service (IAS ) parsing tools online to assist you in interpreting the log files.
The output of one such downloadable shareware application is shown here:
To do additional troubleshooting, you can use a protocol analyzer such as Wireshark or Microsoft Message
Analyzer. The following image from Wireshark shows the RADIUS messages between the VPN server and the
NPS.
For more information, see Integrate your existing NPS infrastructure with Azure Multi-Factor Authentication.
Next steps
Get Azure Multi-Factor Authentication
Remote Desktop Gateway and Azure Multi-Factor Authentication Server using RADIUS
Integrate your on-premises directories with Azure Active Directory
Enable combined security information registration
(preview)
Before enabling the new experience, review the article Combined security information registration (preview ) to
ensure you understand the functionality and effects of this feature.
Combined security information registration for Azure Multi-Factor Authentication and Azure Active Directory (Azure AD) self-
service password reset is a public preview feature of Azure AD. For more information about previews, see Supplemental Terms of
Use for Microsoft Azure Previews.
Enable combined registration

Complete these steps to enable combined registration:
1. Sign in to the Azure portal as a user administrator or global administrator.
2. Go to Azure Active Directory > User settings > Manage settings for access panel preview
features.
3. Under Users can use preview features for registering and managing security info - refresh, choose
to enable for a Selected group of users or for All users.
IMPORTANT
Starting in March 2019, the phone call options won't be available to Multi-Factor Authentication and SSPR users in free/trial
Azure AD tenants. SMS messages are not affected by this change. The phone call options will still be available to users in
paid Azure AD tenants.
NOTE
After you enable combined registration, users who register or confirm their phone number or mobile app through the new
experience can use them for Multi-Factor Authentication and SSPR, if those methods are enabled in the Multi-Factor
Authentication and SSPR policies. If you then disable this experience, users who go to the previous SSPR registration page at
https://aka.ms/ssprsetup will be required to perform multi-factor authentication before they can access the page.
If you have configured the Site to Zone Assignment List in Internet Explorer, the following sites have to be in the
same zone:
https://mysignins.microsoft.com
https://account.activedirectory.windowsazure.com
Conditional Access policies for combined registration

Securing when and how users register for Azure Multi-Factor Authentication and self-service password reset is
now possible with user actions in Conditional Access policy. This preview feature is available to organizations who
have enabled the combined registration preview. This functionality may be enabled in organizations where they
want users to register for Azure Multi-Factor Authentication and SSPR from a central location such as a trusted
network location during HR onboarding. For more information about creating trusted locations in Conditional
Access, see the article What is the location condition in Azure Active Directory Conditional Access?
Create a policy to require registration from a trusted location
The following policy applies to all selected users, who attempt to register using the combined registration
experience, and blocks access unless they are connecting from a location marked as trusted network.
1. In the Azure portal, browse to Azure Active Directory > Conditional Access
2. Select New policy
3. In Name, Enter a Name for this policy. For example, Combined Security Info Registration on Trusted
Networks
4. Under Assignments, click Users and groups, and select the users and groups you want this policy to
apply to
WARNING
Users must be enabled for the combined registration preview.
5. Under Cloud apps or actions, select User actions, check Register security information (preview)
6. Under Conditions > Locations
a. Configure Yes
b. Include Any location
c. Exclude All trusted locations
d. Click Done on the Locations blade
e. Click Done on the Conditions blade
7. Under Access controls > Grant
a. Click Block access
b. Then click Select
8. Set Enable policy to On
9. Then click Create
Next steps
Available methods for Multi-Factor Authentication and SSPR
Configure self-service password reset
Troubleshooting combined security info registration
What is the location condition in Azure Active Directory Conditional Access?
Troubleshooting combined security information
registration (preview)
The information in this article is meant to guide admins who are troubleshooting issues reported by users of the
combined registration experience.
Combined security information registration for Azure Multi-Factor Authentication and Azure Active Directory (Azure AD) self-
service password reset is a public preview feature of Azure AD. For more information about previews, see Supplemental Terms of
Use for Microsoft Azure Previews.
Audit logs
The events logged for combined registration are in the Authentication Methods category in the Azure AD audit
logs.
The following table lists all audit events generated by combined registration:
ACTIVITY STATUS REASON DESCRIPTION
User registered all required Success User registered all required This event occurs when a
security info security info. user has successfully
completed registration.
User registered all required Failure User canceled security info This event occurs when a
security info registration. user cancels registration
from interrupt mode.
User registered security info Success User registered method. This event occurs when a
user registers an individual
method. Method can be
Authenticator app, Phone,
Email, Security questions,
App password, Alternate
phone, and so on.
User reviewed security info Success User successfully reviewed This event occurs when a
security info. user selects Looks good on
the security info review
page.
User reviewed security info Failure User failed to review security This event occurs when a
info. user selects Looks good on
the security info review page
but something fails on the
backend.
User deleted security info Success User deleted method. This event occurs when a
user deletes an individual
phone, and so on.
User deleted security info Failure User failed to delete method. This event occurs when a
user tries to delete a method
but the attempt fails for
some reason. Method can be
phone, and so on.
User changed default Success User changed the default This event occurs when a
security info security info for method. user changes the default
Authenticator app
notification, A code from my
authenticator app or token,
Call +X XXXXXXXXXX, Text a
code to +X XXXXXXXXX, and
so on.
User changed default Failure User failed to change the This event occurs when a
security info default security info for user tries to change the
method. default method but the
attempt fails for some
reason. Method can be
Authenticator app
notification, A code from my
authenticator app or token,
Call +X XXXXXXXXXX, Text a
code to +X XXXXXXXXX, and
so on.
Troubleshooting interrupt mode

SYMPTOM TROUBLESHOOTING STEPS
I’m not seeing the methods I expected to see. 1. Check if the user has an Azure AD admin role. If yes, view
the SSPR admin policy differences.
2. Determine whether the user is being interrupted because of
Multi-Factor Authentication registration enforcement or SSPR
registration enforcement. See the flowchart under "Combined
registration modes" to determine which methods should be
shown.
3. Determine how recently the Multi-Factor Authentication or
SSPR policy was changed. If the change was recent, it might
take some time for the updated policy to propagate.
Troubleshooting manage mode

SYMPTOM TROUBLESHOOTING STEPS
I don’t have the option to add a particular method. 1. Determine whether the method is enabled for Multi-Factor
Authentication or for SSPR.
2. If the method is enabled, save the policies again and wait 1-
2 hours before testing again.
3. If the method is enabled, ensure that the user hasn’t
already set up the maximum number of that method that
they're allowed to set up.
Disable combined registration

When a user registers a phone number and/or mobile app in the new combined experience, our service stamps a
set of flags (StrongAuthenticationMethods) for those methods on that user. This functionality allows the user to
perform Multi-Factor Authentication with those methods whenever Multi-Factor Authentication is required.
If an admin enables the preview, users register through the new experience, and then the admin disables the
preview, users might unknowingly be registered for Multi-Factor Authentication also.
If a user who has completed combined registration goes to the current self-service password reset (SSPR )
registration page at https://aka.ms/ssprsetup, the user will be prompted to perform Multi-Factor Authentication
before they can access that page. This step is expected from a technical standpoint, but it's new for users who were
previously registered for SSPR only. Though this extra step does improve the user’s security posture by providing
another level of security, admins might want to roll back their users so that they're no longer able to perform
Multi-Factor Authentication.
How to roll back users
If you, as an admin, want to reset a user's Multi-Factor Authentication settings, you can use the PowerShell script
provided in the next section. The script will clear the StrongAuthenticationMethods property for a user’s mobile
app and/or phone number. If you run this script for your users, they'll need to re-register for Multi-Factor
Authentication if they need it. We recommend testing rollback with one or two users before rolling back all affected
users.
The steps that follow will help you roll back a user or group of users.
Prerequisites
1. Install the appropriate Azure AD PowerShell modules. In a PowerShell window, run these commands to
install the modules:
Install-Module -Name MSOnline

2. Save the list of affected user object IDs to your computer as a text file with one ID per line. Make note of the
location of the file.
3. Save the following script to your computer and make note of the location of the script:
<#
//********************************************************
//* *
//* Copyright (C) Microsoft. All rights reserved. *
//* *
//********************************************************
#>
param($path)
# Define Remediation Fn
function RemediateUser {
param
(
$ObjectId
)
$user = Get-MsolUser -ObjectId $ObjectId
Write-Host "Checking if user is eligible for rollback: UPN: " $user.UserPrincipalName " ObjectId:
" $user.ObjectId -ForegroundColor Yellow
$hasMfaRelyingParty = $false
foreach($p in $user.StrongAuthenticationRequirements)
{
if ($p.RelyingParty -eq "*")
{
$hasMfaRelyingParty = $true
Write-Host "User was enabled for per-user MFA." -ForegroundColor Yellow
}
}
if ($user.StrongAuthenticationMethods.Count -gt 0 -and -not $hasMfaRelyingParty)

{
Write-Host $user.UserPrincipalName " is eligible for rollback" -ForegroundColor Yellow
Write-Host "Rolling back user ..." -ForegroundColor Yellow
Reset-MsolStrongAuthenticationMethodByUpn -UserPrincipalName $user.UserPrincipalName
Write-Host "Successfully rolled back user " $user.UserPrincipalName -ForegroundColor Green
}
else
{
Write-Host $user.UserPrincipalName " is not eligible for rollback. No action required."
}
Write-Host ""
Start-Sleep -Milliseconds 750
}
# Connect
Connect-MsolService
foreach($line in Get-Content $path)

{
RemediateUser -ObjectId $line
}
Rollback
In a PowerShell window, run the following command, providing the script and user file locations. Enter global
administrator credentials when prompted. The script will output the outcome of each user update operation.
<script location> -path <user file location>
Disable the preview experience

To disable the preview experience for your users, complete these steps:
1. Sign in to the Azure portal as a user administrator.
2. Go to Azure Active Directory > User settings > Manage settings for access panel preview features.
3. Under Users can use preview features for registering and managing security info, set the selector to
None, and then select Save.
Users will no longer be prompted to register by using the preview experience.
Next steps
Learn more about the public preview of combined registration for self-service password reset and Azure Multi-
Factor Authentication
Configuring the custom banned password list
Many organizations find their users create passwords using common local words such as a school, sports team, or
famous person, leaving them easy to guess. Microsoft's custom banned password list allows organizations to add
strings to evaluate and block, in addition to the global banned password list, when users and administrators
attempt to change or reset a password.
Add to the custom list

Configuring the custom banned password list requires an Azure Active Directory Premium P1 or P2 license. For
more detailed information about Azure Active Directory licensing, see the Azure Active Directory pricing page.
1. Sign in to the Azure portal and browse to Azure Active Directory, Authentication methods, then Password
protection.
2. Set the option Enforce custom list, to Yes.
3. Add strings to the Custom banned password list, one string per line
The custom banned password list can contain up to 1000 terms.
The custom banned password list is case-insensitive.
The custom banned password list considers common character substitution.
Example: "o" and "0" or "a" and "@"
The minimum string length is four characters and the maximum is 16 characters.
4. When you have added all strings, click Save.
NOTE
It may take several hours for updates to the custom banned password list to be applied.
NOTE
The custom banned password list is limited to having a maximum of 1000 terms. It is not designed for blocking extremely
large lists of passwords. In order to fully leverage the benefits of the custom banned password list, Microsoft recommends
that you first review and understand the intended design and usage of the custom banned password list (see Custom
banned password list), and also the password evaluation algorithm (see How are passwords evaluated).
How it works
Each time a user or administrator resets or changes an Azure AD password, it flows through the banned password
lists to confirm that it is not on a list. This check is included in any passwords set or changed using Azure AD.
What do users see

When a user attempts to reset a password to something that would be banned, they see one of the following error
messages:
Unfortunately, your password contains a word, phrase, or pattern that makes your password easily guessable.
Please try again with a different password.
Unfortunately, you can't use that password because it contains words or characters that have been blocked by
your administrator. Please try again with a different password.
Next steps
Conceptual overview of the banned password lists
Conceptual overview of Azure AD password protection
Enable on-premises integration with the banned password lists
Now that you understand how to enforce Azure AD password protection for Windows Server Active Directory,
the next step is to plan and execute your deployment.
Deployment strategy
We recommend that you start deployments in audit mode. Audit mode is the default initial setting, where
passwords can continue to be set. Passwords that would be blocked are recorded in the event log. After you
deploy the proxy servers and DC Agents in audit mode, you should monitor the impact that the password policy
will have on users and the environment when the policy is enforced.
During the audit stage, many organizations find out that:
They need to improve existing operational processes to use more secure passwords.
Users often use unsecure passwords.
They need to inform users about the upcoming change in security enforcement, possible impact on them, and
how to choose more secure passwords.
It is also possible for stronger password validation to affect your existing Active Directory domain controller
deployment automation. We recommend that at least one DC promotion and one DC demotion happen during
the audit period evaluation in order to help uncover such issues in advance. For more information, see:
Ntdsutil.exe is unable to set a weak Directory Services Repair Mode password
Domain controller replica promotion fails because of a weak Directory Services Repair Mode password
Domain controller demotion fails due to a weak local Administrator password
After the feature has been running in audit mode for a reasonable period, you can switch the configuration from
Audit to Enforce to require more secure passwords. Focused monitoring during this time is a good idea.
Deployment requirements
Licensing requirements for Azure AD password protection can be found in the article Eliminate bad
passwords in your organization.
All domain controllers that get the DC Agent service for Azure AD password protection installed must run
Windows Server 2012 or later. This requirement does not imply that the Active Directory domain or forest
must also be at Windows Server 2012 domain or forest functional level. As mentioned in Design Principles,
there is no minimum DFL or FFL required for either the DC agent or proxy software to run.
All machines that get the DC agent service installed must have .NET 4.5 installed.
All machines that get the proxy service for Azure AD password protection installed must run Windows
Server 2012 R2 or later.
NOTE
Proxy service deployment is a mandatory requirement for deploying Azure AD password protection even though
the Domain controller may have outbound direct internet connectivity.
All machines where the Azure AD Password Protection Proxy service will be installed must have .NET 4.7
installed. .NET 4.7 should already be installed on a fully updated Windows Server. If this is not the case,
download and run the installer found at The .NET Framework 4.7 offline installer for Windows.
All machines, including domain controllers, that get Azure AD password protection components installed
must have the Universal C Runtime installed. You can get the runtime by making sure you have all updates
from Windows Update. Or you can get it in an OS -specific update package. For more information, see
Update for Universal C Runtime in Windows.
Network connectivity must exist between at least one domain controller in each domain and at least one
server that hosts the proxy service for password protection. This connectivity must allow the domain
controller to access RPC endpoint mapper port 135 and the RPC server port on the proxy service. By
default, the RPC server port is a dynamic RPC port, but it can be configured to use a static port.
All machines that host the proxy service must have network access to the following endpoints:
ENDPOINT PURPOSE
https://login.microsoftonline.com Authentication requests
https://enterpriseregistration.windows.net Azure AD password protection functionality
All machines that host the proxy service for password protection must be configured to allow outbound
TLS 1.2 HTTP traffic.
A Global Administrator account to register the proxy service for password protection and forest with Azure
AD.
An account that has Active Directory domain administrator privileges in the forest root domain to register
the Windows Server Active Directory forest with Azure AD.
Any Active Directory domain that runs the DC Agent service software must use Distributed File System
Replication (DFSR ) for sysvol replication.
The Key Distribution Service must be enabled on all domain controllers in the domain that run Windows
Server 2012. By default, this service is enabled via manual trigger start.
Single-forest deployment
The following diagram shows how the basic components of Azure AD password protection work together in an
on-premises Active Directory environment.
It's a good idea to review how the software works before you deploy it. See Conceptual overview of Azure AD
password protection.
Download the software
There are two required installers for Azure AD password protection. They're available from the Microsoft
Download Center.
Install and configure the proxy service for password protection
1. Choose one or more servers to host the proxy service for password protection.
Each such service can only provide password policies for a single forest. The host machine must be
joined to a domain in that forest. Root and child domains are both supported. You need network
connectivity between at least one DC in each domain of the forest and the password protection
machine.
You can run the proxy service on a domain controller for testing. But that domain controller then
requires internet connectivity, which can be a security concern. We recommend this configuration for
testing only.
We recommend at least two proxy servers for redundancy. See High availability.
2. Install the Azure AD Password Protection Proxy service using the AzureADPasswordProtectionProxySetup.exe
software installer.
The software installation does not require a reboot. The software installation may be automated
using standard MSI procedures, for example:
AzureADPasswordProtectionProxySetup.exe /quiet
NOTE
The Windows Firewall service must be running before you install the
AzureADPasswordProtectionProxySetup.msi package to avoid an installation error. If Windows Firewall is
configured to not run, the workaround is to temporarily enable and run the Firewall service during the
installation. The proxy software has no specific dependency on Windows Firewall after installation. If you're
using a third-party firewall, it must still be configured to satisfy the deployment requirements. These include
allowing inbound access to port 135 and the proxy RPC server port. See Deployment requirements.
3. Open a PowerShell window as an administrator.

The password protection proxy software includes a new PowerShell module,
AzureADPasswordProtection. The following steps run various cmdlets from this PowerShell module.
Import the new module as follows:
Import-Module AzureADPasswordProtection
To check that the service is running, use the following PowerShell command:
Get-Service AzureADPasswordProtectionProxy | fl .
The result should show a Status of "Running."
4. Register the proxy.
After step 3 is completed, the proxy service is running on the machine. But the service doesn't yet
have the necessary credentials to communicate with Azure AD. Registration with Azure AD is
required:
Register-AzureADPasswordProtectionProxy
This cmdlet requires global administrator credentials for your Azure tenant. You also need on-
premises Active Directory domain administrator privileges in the forest root domain. After this
command succeeds once for a proxy service, additional invocations of it will succeed but are
unnecessary.
The Register-AzureADPasswordProtectionProxy cmdlet supports the following three authentication
modes.
Interactive authentication mode:
Register-AzureADPasswordProtectionProxy -AccountUpn
'yourglobaladmin@yourtenant.onmicrosoft.com'
NOTE
This mode doesn't work on Server Core operating systems. Instead, use one of the following
authentication modes. Also, this mode might fail if Internet Explorer Enhanced Security Configuration
is enabled. The workaround is to disable that Configuration, register the proxy, and then re-enable it.
Device-code authentication mode:

Register-AzureADPasswordProtectionProxy -AccountUpn
'yourglobaladmin@yourtenant.onmicrosoft.com' -AuthenticateUsingDeviceCode
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter
the code XYZABC123 to authenticate.
You then complete authentication by following the displayed instructions on a different

device.
Silent (password-based) authentication mode:
$globalAdminCredentials = Get-Credential
Register-AzureADPasswordProtectionProxy -AzureCredential $globalAdminCredentials
NOTE
This mode fails if Azure Multi-Factor Authentication is required for your account. In that case, use
one of the previous two authentication modes, or instead use a different account that does not
require MFA.
You may also see MFA required if Azure Device Registration (which is used under the covers by Azure
AD Password Protection) has been configured to globally require MFA. To workaround this you may
use a different account that supports MFA with one of the previous two authentication modes, or
you may also temporarily relax the Azure Device Registration MFA requirement. To do this, go to the
Azure management portal, then go to Azure Active Directory, then Devices, then Device Settings,
then set "Require Multi-Factor Auth to join devices" to No. Be sure to reconfigure this setting back to
Yes once registration is complete.
We recommend that MFA requirements be bypassed for test purposes only.
You don't currently have to specify the -ForestCredential parameter, which is reserved for
future functionality.
Registration of the proxy service for password protection is necessary only once in the lifetime of the
service. After that, the proxy service will automatically perform any other necessary maintenance.
TIP
There might be a noticeable delay before completion the first time that this cmdlet is run for a specific Azure tenant.
Unless a failure is reported, don't worry about this delay.
5. Register the forest.

You must initialize the on-premises Active Directory forest with the necessary credentials to
communicate with Azure by using the Register-AzureADPasswordProtectionForest PowerShell cmdlet.
The cmdlet requires global administrator credentials for your Azure tenant. It also requires on-
premises Active Directory Enterprise Administrator privileges. This step is run once per forest.
The Register-AzureADPasswordProtectionForest cmdlet supports the following three authentication
modes.
Interactive authentication mode:
Register-AzureADPasswordProtectionForest -AccountUpn
'yourglobaladmin@yourtenant.onmicrosoft.com'
NOTE
This mode won't work on Server Core operating systems. Instead use one of the following two
authentication modes. Also, this mode might fail if Internet Explorer Enhanced Security Configuration
is enabled. The workaround is to disable that Configuration, register the forest, and then re-enable it.
Device-code authentication mode:
Register-AzureADPasswordProtectionForest -AccountUpn
'yourglobaladmin@yourtenant.onmicrosoft.com' -AuthenticateUsingDeviceCode
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter
the code XYZABC123 to authenticate.
You then complete authentication by following the displayed instructions on a different

device.
Silent (password-based) authentication mode:
$globalAdminCredentials = Get-Credential
Register-AzureADPasswordProtectionForest -AzureCredential $globalAdminCredentials
NOTE
This mode fails if Azure Multi-Factor Authentication is required for your account. In that case, use
one of the previous two authentication modes, or instead use a different account that does not
require MFA.
You may also see MFA required if Azure Device Registration (which is used under the covers by Azure
AD Password Protection) has been configured to globally require MFA. To workaround this you may
use a different account that supports MFA with one of the previous two authentication modes, or
you may also temporarily relax the Azure Device Registration MFA requirement. To do this, go to the
Azure management portal, then go to Azure Active Directory, then Devices, then Device Settings,
then set "Require Multi-Factor Auth to join devices" to No. Be sure to reconfigure this setting back to
Yes once registration is complete.
We recommend that MFA requirements be bypassed for test purposes only.
These examples only succeed if the currently signed-in user is also an Active Directory
domain administrator for the root domain. If this isn't the case, you can supply alternative
domain credentials via the -ForestCredential parameter.
NOTE
If multiple proxy servers are installed in your environment, it doesn't matter which proxy server you use to register
the forest.
TIP
There might be a noticeable delay before completion the first time that this cmdlet is run for a specific Azure tenant.
Unless a failure is reported, don't worry about this delay.
Registration of the Active Directory forest is necessary only once in the lifetime of the forest. After that, the
Domain Controller Agents in the forest will automatically perform any other necessary maintenance. After
Register-AzureADPasswordProtectionForest runs successfully for a forest, additional invocations of the
cmdlet succeed but are unnecessary.
For Register-AzureADPasswordProtectionForest to succeed, at least one domain controller running Windows
Server 2012 or later must be available in the proxy server's domain. But the DC Agent software doesn't
have to be installed on any domain controllers before this step.
6. Configure the proxy service for password protection to communicate through an HTTP proxy.
If your environment requires the use of a specific HTTP proxy to communicate with Azure, use this method:
Create a AzureADPasswordProtectionProxy.exe.config file in the %ProgramFiles%\Azure AD Password
Protection Proxy\Service folder. Include the following content:
<configuration>
<system.net>
<defaultProxy enabled="true">
<proxy bypassonlocal="true"
proxyaddress="http://yourhttpproxy.com:8080" />
</defaultProxy>
</system.net>
</configuration>
If your HTTP proxy requires authentication, add the useDefaultCredentials tag:
<configuration>
<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy bypassonlocal="true"
proxyaddress="http://yourhttpproxy.com:8080" />
</defaultProxy>
</system.net>
</configuration>
In both cases, replace http://yourhttpproxy.com:8080 with the address and port of your specific HTTP
proxy server.
If your HTTP proxy is configured to use an authorization policy, you must grant access to the Active
Directory computer account of the machine that hosts the proxy service for password protection.
We recommend that you stop and restart the proxy service after you create or update the
AzureADPasswordProtectionProxy.exe.config file.
The proxy service doesn't support the use of specific credentials for connecting to an HTTP proxy.
7. Optional: Configure the proxy service for password protection to listen on a specific port.
The DC Agent software for password protection on the domain controllers uses RPC over TCP to
communicate with the proxy service. By default, the proxy service listens on any available dynamic RPC
endpoint. But you can configure the service to listen on a specific TCP port, if this is necessary because
of networking topology or firewall requirements in your environment.
To configure the service to run under a static port, use the
Set-AzureADPasswordProtectionProxyConfiguration cmdlet.
Set-AzureADPasswordProtectionProxyConfiguration –StaticPort <portnumber>

WARNING
You must stop and restart the service for these changes to take effect.
To configure the service to run under a dynamic port, use the same procedure but set
StaticPort back to zero:
Set-AzureADPasswordProtectionProxyConfiguration –StaticPort 0
WARNING
You must stop and restart the service for these changes to take effect.
NOTE
The proxy service for password protection requires a manual restart after any change in port configuration. But you
don't have to restart the DC Agent service software on domain controllers after you make these configuration
changes.
To query for the current configuration of the service, use the

Get-AzureADPasswordProtectionProxyConfiguration cmdlet:
Get-AzureADPasswordProtectionProxyConfiguration | fl
ServiceName : AzureADPasswordProtectionProxy
DisplayName : Azure AD password protection Proxy
StaticPort : 0
Install the DC Agent service

Install the DC Agent service for password protection by using the AzureADPasswordProtectionDCAgentSetup.msi
package.
The software installation, or un-installation, requires a restart. This is because password filter DLLs are only
loaded or unloaded by a restart.
You can install the DC Agent service on a machine that's not yet a domain controller. In this case, the service will
start and run but remain inactive until the machine is promoted to be a domain controller.
You can automate the software installation by using standard MSI procedures. For example:
msiexec.exe /i AzureADPasswordProtectionDCAgentSetup.msi /quiet /qn /norestart
You may omit the /norestart flag if you prefer to have the installer automatically reboot the machine.
The installation is complete after the DC Agent software is installed on a domain controller, and that computer is
rebooted. No other configuration is required or possible.
Upgrading the Proxy agent

When a newer version of the Azure AD Password Protection Proxy software is available, the upgrade is
accomplished by running the latest version of the AzureADPasswordProtectionProxySetup.exe software installer. The
latest version of the software is available on the Microsoft Download Center.
It is not required to uninstall the current version of the Proxy software - the installer will perform an in-place
upgrade. No reboot should be required when upgrading the Proxy software. The software upgrade may be
automated using standard MSI procedures, for example: AzureADPasswordProtectionProxySetup.exe /quiet .
The Proxy agent supports automatic upgrade. Automatic upgrade uses the Microsoft Azure AD Connect Agent
Updater service which is installed side-by-side with the Proxy service. Automatic upgrade is on by default, and
may be enabled or disabled using the Set-AzureADPasswordProtectionProxyConfiguration cmdlet. The current
setting can be queried using the Get-AzureADPasswordProtectionProxyConfiguration cmdlet. Microsoft
recommends that the automatic upgrade be left enabled.
The Get-AzureADPasswordProtectionProxy cmdlet may be used to query the software version of all currently
installed Proxy agents in a forest.
Upgrading the DC agent

When a newer version of the Azure AD Password Protection DC Agent software is available, the upgrade is
accomplished by running the latest version of the AzureADPasswordProtectionDCAgentSetup.msi software package.
The latest version of the software is available on the Microsoft Download Center.
It is not required to uninstall the current version of the DC agent software - the installer will perform an in-place
upgrade. A reboot is always required when upgrading the DC agent software - this is caused by core Windows
behavior.
The software upgrade may be automated using standard MSI procedures, for example:
msiexec.exe /i AzureADPasswordProtectionDCAgentSetup.msi /quiet /qn /norestart .
You may omit the /norestart flag if you prefer to have the installer automatically reboot the machine.
The Get-AzureADPasswordProtectionDCAgent cmdlet may be used to query the software version of all currently
installed DC agents in a forest.
Multiple forest deployments

There are no additional requirements to deploy Azure AD password protection across multiple forests. Each forest
is independently configured as described in the "Single-forest deployment" section. Each password protection
proxy can only support domain controllers from the forest that it's joined to. The password protection software in
any forest is unaware of password protection software that's deployed in other forests, regardless of Active
Directory trust configurations.
Read-only domain controllers

Password changes/sets are not processed and persisted on read-only domain controllers (RODCs). They are
forwarded to writable domain controllers. So, you don't have to install the DC Agent software on RODCs.
High availability
The main availability concern for password protection is the availability of proxy servers when the domain
controllers in a forest try to download new policies or other data from Azure. Each DC Agent uses a simple round-
robin-style algorithm when deciding which proxy server to call. The Agent skips proxy servers that aren't
responding. For most fully connected Active Directory deployments that have healthy replication of both directory
and sysvol folder state, two proxy servers is enough to ensure availability. This results in timely download of new
policies and other data. But you can deploy additional proxy servers.
The design of the DC Agent software mitigates the usual problems that are associated with high availability. The
DC Agent maintains a local cache of the most recently downloaded password policy. Even if all registered proxy
servers become unavailable, the DC Agents continue to enforce their cached password policy. A reasonable
update frequency for password policies in a large deployment is usually days, not hours or less. So, brief outages
of the proxy servers don't significantly impact Azure AD password protection.
Next steps
Now that you've installed the services that you need for Azure AD password protection on your on-premises
servers, perform post-install configuration and gather reporting information to complete your deployment.
Conceptual overview of Azure AD password protection
Azure AD Password Protection operational
procedures
After you have completed the installation of Azure AD Password Protection on-premises, there are a couple items
that must be configured in the Azure portal.
Configure the custom banned password list

Follow the guidance in the article Configuring the custom banned password list for steps to customize the banned
password list for your organization.
Enable Password Protection

1. Sign in to the Azure portal and browse to Azure Active Directory, Authentication methods, then
Password Protection.
2. Set Enable Password Protection on Windows Server Active Directory to Yes
3. As mentioned in the Deployment guide, it is recommended to initially set the Mode to Audit
After you are comfortable with the feature, you can switch the Mode to Enforced
4. Click Save
Audit Mode
Audit mode is intended as a way to run the software in a “what if” mode. Each DC agent service evaluates an
incoming password according to the currently active policy. If the current policy is configured to be in Audit mode,
“bad” passwords result in event log messages but are accepted. This is the only difference between Audit and
Enforce mode; all other operations run the same.
NOTE
Microsoft recommends that initial deployment and testing always start out in Audit mode. Events in the event log should
then be monitored to try to anticipate whether any existing operational processes would be disturbed once Enforce mode is
enabled.
Enforce Mode
Enforce mode is intended as the final configuration. As in Audit mode above, each DC agent service evaluates
incoming passwords according to the currently active policy. If Enforce mode is enabled though, a password that is
considered unsecure according to the policy is rejected.
When a password is rejected in Enforce mode by the Azure AD Password Protection DC Agent, the visible impact
seen by an end user is identical to what they would see if their password was rejected by traditional on-premises
password complexity enforcement. For example, a user might see the following traditional error message at the
Windows logon\change password screen:
Unable to update the password. The value provided for the new password does not meet the length, complexity, or
history requirements of the domain.
This message is only one example of several possible outcomes. The specific error message can vary depending on
the actual software or scenario that is attempting to set an unsecure password.
Affected end users may need to work with their IT staff to understand the new requirements and be more able to
choose secure passwords.
Enable Mode
This setting should normally be left in its default enabled (Yes) state. Configuring this setting to disabled (No) will
cause all deployed Azure AD Password Protection DC agents to go into a quiescent mode where all passwords are
accepted as-is, and no validation activities will be executed whatsoever (for example, not even audit events will be
emitted).
Next steps
Monitoring for Azure AD Password Protection
Azure AD Password Protection monitoring and
logging
After the deployment of Azure AD Password Protection, monitoring and reporting are essential tasks. This article
goes into detail to help you understand various monitoring techniques, including where each service logs
information and how to report on the use of Azure AD Password Protection.
Monitoring and reporting are done either by event log messages or by running PowerShell cmdlets. The DC agent
and proxy services both log event log messages. All PowerShell cmdlets described below are only available on the
proxy server (see the AzureADPasswordProtection PowerShell module). The DC agent software does not install a
PowerShell module.
DC agent event logging

On each domain controller, the DC agent service software writes the results of each individual password validation
operation (and other status) to a local event log:
\Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Admin
\Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Operational
\Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Trace
The DC agent Admin log is the primary source of information for how the software is behaving.
Note that the Trace log is off by default.
Events logged by the various DC agent components fall within the following ranges:
COMPONENT EVENT ID RANGE
DC Agent password filter dll 10000-19999
DC agent service hosting process 20000-29999
DC agent service policy validation logic 30000-39999
DC agent Admin event log

Password validation outcome events
On each domain controller, the DC agent service software writes the results of each individual password validation
to the DC agent admin event log.
For a successful password validation operation, there is generally one event logged from the DC agent password
filter dll. For a failing password validation operation, there are generally two events logged, one from the DC agent
service, and one from the DC Agent password filter dll.
Discrete events to capture these situations are logged, based around the following factors:
Whether a given password is being set or changed.
Whether validation of a given password passed or failed.
Whether validation failed due to the Microsoft global policy, the organizational policy, or a combination.
Whether audit only mode is currently on or off for the current password policy.
The key password-validation-related events are as follows:
PASSWORD CHANGE PASSWORD SET
Pass 10014 10015
Fail (due to customer password policy) 10016, 30002 10017, 30003
Fail (due to Microsoft password policy) 10016, 30004 10017, 30005
Fail (due to combined Microsoft and 10016, 30026 10017, 30027

customer password policies)
Audit-only Pass (would have failed 10024, 30008 10025, 30007

customer password policy)

Microsoft password policy)

combined Microsoft and customer
password policies)
The cases in the table above that refer to "combined policies" are referring to situations where a user's password
was found to contain at least one token from both the Microsoft banned password list and the customer banned
password list.
When a pair of events is logged together, both events are explicitly associated by having the same CorrelationId.
Password validation summary reporting via PowerShell
The Get-AzureADPasswordProtectionSummaryReport cmdlet may be used to produce a summary view of password
validation activity. An example output of this cmdlet is as follows:
Get-AzureADPasswordProtectionSummaryReport -DomainController bplrootdc2

DomainController : bplrootdc2
PasswordChangesValidated : 6677
PasswordSetsValidated : 9
PasswordChangesRejected : 10868
PasswordSetsRejected : 34
PasswordChangeAuditOnlyFailures : 213
PasswordSetAuditOnlyFailures : 3
PasswordChangeErrors : 0
PasswordSetErrors : 1
The scope of the cmdlet’s reporting may be influenced using one of the –Forest, -Domain, or –DomainController
parameters. Not specifying a parameter implies –Forest.
The Get-AzureADPasswordProtectionSummaryReport cmdlet works by querying the DC agent admin event log, and
then counting the total number of events that correspond to each displayed outcome category. The following table
contains the mappings between each outcome and its corresponding event ID:
GET-AZUREADPASSWORDPROTECTIONSUMMARYREPORT
PROPERTY CORRESPONDING EVENT ID
PasswordChangesValidated 10014
PasswordSetsValidated 10015
PasswordChangesRejected 10016
PasswordSetsRejected 10017
PasswordChangeAuditOnlyFailures 10024
PasswordSetAuditOnlyFailures 10025
PasswordChangeErrors 10012
PasswordSetErrors 10013
Note that the Get-AzureADPasswordProtectionSummaryReport cmdlet is shipped in PowerShell script form and if
needed may be referenced directly at the following location:
%ProgramFiles%\WindowsPowerShell\Modules\AzureADPasswordProtection\Get-
AzureADPasswordProtectionSummaryReport.ps1
NOTE
This cmdlet works by opening a PowerShell session to each domain controller. In order to succeed, PowerShell remote session
support must be enabled on each domain controller, and the client must have sufficient privileges. For more information on
PowerShell remote session requirements, run 'Get-Help about_Remote_Troubleshooting' in a PowerShell window.
NOTE
This cmdlet works by remotely querying each DC agent service’s Admin event log. If the event logs contain large numbers of
events, the cmdlet may take a long time to complete. In addition, bulk network queries of large data sets may impact domain
controller performance. Therefore, this cmdlet should be used carefully in production environments.
Sample event log message for Event ID 10014 (successful password change )
The changed password for the specified user was validated as compliant with the current Azure password policy.
UserName: BPL_02885102771
FullName:
Sample event log message for Event ID 10017 and 30003 (failed password set)
10017:
The reset password for the specified user was rejected because it did not comply with the current Azure
password policy. Please see the correlated event log message for more details.
FullName:
30003:
The reset password for the specified user was rejected because it matched at least one of the tokens present
in the per-tenant banned password list of the current Azure password policy.
FullName:
Sample event log message for Event ID 30001 (password accepted due to no policy available )
The password for the specified user was accepted because an Azure password policy is not available yet
UserName: SomeUser
FullName: Some User
This condition may be caused by one or more of the following reasons:%n
1. The forest has not yet been registered with Azure.
Resolution steps: an administrator must register the forest using the Register-
AzureADPasswordProtectionForest cmdlet.
2. An Azure AD password protection Proxy is not yet available on at least one machine in the current forest.
Resolution steps: an administrator must install and register a proxy using the Register-
AzureADPasswordProtectionProxy cmdlet.
3. This DC does not have network connectivity to any Azure AD password protection Proxy instances.
Resolution steps: ensure network connectivity exists to at least one Azure AD password protection Proxy
instance.
4. This DC does not have connectivity to other domain controllers in the domain.
Resolution steps: ensure network connectivity exists to the domain.
Sample event log message for Event ID 30006 (new policy being enforced)
The service is now enforcing the following Azure password policy.
Enabled: 1
AuditOnly: 1
Global policy date: 2018-05-15T00:00:00.000000000Z
Tenant policy date: 2018-06-10T20:15:24.432457600Z
Enforce tenant policy: 1
Sample event log message for Event ID 30019 (Azure AD Password Protection is disabled)
The most recently obtained Azure password policy was configured to be disabled. All passwords submitted for
validation from this point on will automatically be considered compliant with no processing performed.
No further events will be logged until the policy is changed.%n
DC Agent Operational log

The DC agent service will also log operational-related events to the following log:
\Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Operational
DC Agent Trace log

The DC agent service can also log verbose debug-level trace events to the following log:
\Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Trace
Trace logging is disabled by default.
WARNING
When enabled, the Trace log receives a high volume of events and may impact domain controller performance. Therefore,
this enhanced log should only be enabled when a problem requires deeper investigation, and then only for a minimal
amount of time.
DC Agent text logging

The DC agent service can be configured to write to a text log by setting the following registry value:
HKLM\System\CurrentControlSet\Services\AzureADPasswordProtectionDCAgent\Parameters!EnableTextLogging = 1
(REG_DWORD value)
Text logging is disabled by default. A restart of the DC agent service is required for changes to this value to take
effect. When enabled the DC agent service will write to a log file located under:
%ProgramFiles%\Azure AD Password Protection DC Agent\Logs
TIP
The text log receives the same debug-level entries that can be logged to the Trace log, but is generally in an easier format to
review and analyze.
WARNING
When enabled, this log receives a high volume of events and may impact domain controller performance. Therefore, this
enhanced log should only be enabled when a problem requires deeper investigation, and then only for a minimal amount of
time.
DC agent performance monitoring

The DC agent service software installs a performance counter object named Azure AD Password Protection.
The following perf counters are currently available:
PERF COUNTER NAME DESCRIPTION
Passwords processed This counter displays the total number of passwords

processed (accepted or rejected) since last restart.
Passwords accepted This counter displays the total number of passwords that were
accepted since last restart.
Passwords rejected This counter displays the total number of passwords that were
rejected since last restart.
Password filter requests in progress This counter displays the number of password filter requests
currently in progress.
PERF COUNTER NAME DESCRIPTION
Peak password filter requests This counter displays the peak number of concurrent
password filter requests since the last restart.
Password filter request errors This counter displays the total number of password filter
requests that failed due to an error since last restart. Errors
can occur when the Azure AD Password Protection DC agent
service is not running.
Password filter requests/sec This counter displays the rate at which passwords are being
processed.
Password filter request processing time This counter displays the average time required to process a
password filter request.
Peak password filter request processing time This counter displays the peak password filter request
processing time since the last restart.
Passwords accepted due to audit mode This counter displays the total number of passwords that
would normally have been rejected, but were accepted
because the password policy was configured to be in audit-
mode (since last restart).
DC Agent discovery
The Get-AzureADPasswordProtectionDCAgent cmdlet may be used to display basic information about the various DC
agents running in a domain or forest. This information is retrieved from the serviceConnectionPoint object(s)
registered by the running DC agent service(s).
An example output of this cmdlet is as follows:
Get-AzureADPasswordProtectionDCAgent
ServerFQDN : bplChildDC2.bplchild.bplRootDomain.com
Domain : bplchild.bplRootDomain.com
Forest : bplRootDomain.com
PasswordPolicyDateUTC : 2/16/2018 8:35:01 AM
HeartbeatUTC : 2/16/2018 8:35:02 AM
The various properties are updated by each DC agent service on an approximate hourly basis. The data is still
subject to Active Directory replication latency.
The scope of the cmdlet’s query may be influenced using either the –Forest or –Domain parameters.
If the HeartbeatUTC value gets stale, this may be a symptom that the Azure AD Password Protection DC Agent on
that domain controller is not running, or has been uninstalled, or the machine was demoted and is no longer a
domain controller.
If the PasswordPolicyDateUTC value gets stale, this may be a symptom that the Azure AD Password Protection DC
Agent on that machine is not working properly.
DC agent newer version available

The DC agent service will log a 30034 warning event to the Operational log upon detecting that a newer version
of the DC agent software is available, for example:
An update for Azure AD Password Protection DC Agent is available.
If autoupgrade is enabled, this message may be ignored.
If autoupgrade is disabled, refer to the following link for the latest version available:
https://aka.ms/AzureADPasswordProtectionAgentSoftwareVersions
Current version: 1.2.116.0
The event above does not specify the version of the newer software. You should go to the link in the event
message for that information.
NOTE
Despite the references to "autoupgrade" in the above event message, the DC agent software does not currently support this
feature.
Proxy service event logging

The Proxy service emits a minimal set of events to the following event logs:
\Applications and Services Logs\Microsoft\AzureADPasswordProtection\ProxyService\Admin
\Applications and Services Logs\Microsoft\AzureADPasswordProtection\ProxyService\Operational
\Applications and Services Logs\Microsoft\AzureADPasswordProtection\ProxyService\Trace
Note that the Trace log is off by default.
WARNING
When enabled, the Trace log receives a high volume of events and this may impact performance of the proxy host. Therefore,
this log should only be enabled when a problem requires deeper investigation, and then only for a minimal amount of time.
Events are logged by the various Proxy components using the following ranges:
COMPONENT EVENT ID RANGE
Proxy service hosting process 10000-19999
Proxy service core business logic 20000-29999
PowerShell cmdlets 30000-39999
Proxy service text logging

The Proxy service can be configured to write to a text log by setting the following registry value:
HKLM\System\CurrentControlSet\Services\AzureADPasswordProtectionProxy\Parameters!EnableTextLogging =
1 (REG_DWORD value)
Text logging is disabled by default. A restart of the Proxy service is required for changes to this value to take effect.
When enabled the Proxy service will write to a log file located under:
%ProgramFiles%\Azure AD Password Protection Proxy\Logs
TIP
The text log receives the same debug-level entries that can be logged to the Trace log, but is generally in an easier format to
review and analyze.
WARNING
When enabled, this log receives a high volume of events and may impact the machine's performance. Therefore, this
enhanced log should only be enabled when a problem requires deeper investigation, and then only for a minimal amount of
time.
PowerShell cmdlet logging

PowerShell cmdlets that result in a state change (for example, Register-AzureADPasswordProtectionProxy) will
normally log an outcome event to the Operational log.
In addition, most of the Azure AD Password Protection PowerShell cmdlets will write to a text log located under:
%ProgramFiles%\Azure AD Password Protection Proxy\Logs
If a cmdlet error occurs and the cause and\or solution is not readily apparent, these text logs may also be
consulted.
Proxy discovery
The Get-AzureADPasswordProtectionProxy cmdlet may be used to display basic information about the various Azure
AD Password Protection Proxy services running in a domain or forest. This information is retrieved from the
serviceConnectionPoint object(s) registered by the running Proxy service(s).
An example output of this cmdlet is as follows:
Get-AzureADPasswordProtectionProxy
ServerFQDN : bplProxy.bplchild2.bplRootDomain.com
Domain : bplchild2.bplRootDomain.com
Forest : bplRootDomain.com
HeartbeatUTC : 12/25/2018 6:35:02 AM
The various properties are updated by each Proxy service on an approximate hourly basis. The data is still subject
to Active Directory replication latency.
The scope of the cmdlet’s query may be influenced using either the –Forest or –Domain parameters.
If the HeartbeatUTC value gets stale, this may be a symptom that the Azure AD Password Protection Proxy on that
machine is not running or has been uninstalled.
Proxy agent newer version available

The Proxy service will log a 20002 warning event to the Operational log upon detecting that a newer version of
the proxy software is available, for example:
An update for Azure AD Password Protection Proxy is available.
If autoupgrade is enabled, this message may be ignored.
If autoupgrade is disabled, refer to the following link for the latest version available:
https://aka.ms/AzureADPasswordProtectionAgentSoftwareVersions
Current version: 1.2.116.0

.
The event above does not specify the version of the newer software. You should go to the link in the event
message for that information.
This event will be emitted even if the Proxy agent is configured with autoupgrade enabled.
Next steps
Troubleshooting for Azure AD Password Protection
For more information on the global and custom banned password lists, see the article Ban bad passwords
Azure AD Password Protection troubleshooting
After the deployment of Azure AD Password Protection, troubleshooting may be required. This article goes into
detail to help you understand some common troubleshooting steps.
The DC agent cannot locate a proxy in the directory

The main symptom of this problem is 30017 events in the DC agent Admin event log.
The usual cause of this issue is that a proxy has not yet been registered. If a proxy has been registered, there may
be some delay due to AD replication latency until a particular DC agent is able to see that proxy.
The DC agent is not able to communicate with a proxy

The main symptom of this problem is 30018 events in the DC agent Admin event log. This problem may have
several possible causes:
1. The DC agent is located in an isolated portion of the network that does not allow network connectivity to
the registered proxy(s). This problem may be benign as long as other DC agents can communicate with the
proxy(s) in order to download password policies from Azure. Once downloaded, those policies will then be
obtained by the isolated DC via replication of the policy files in the sysvol share.
2. The proxy host machine is blocking access to the RPC endpoint mapper endpoint (port 135)
The Azure AD Password Protection Proxy installer automatically creates a Windows Firewall inbound rule
that allows access to port 135. If this rule is later deleted or disabled, DC agents will be unable to
communicate with the Proxy service. If the builtin Windows Firewall has been disabled in lieu of another
firewall product, you must configure that firewall to allow access to port 135.
3. The proxy host machine is blocking access to the RPC endpoint (dynamic or static) listened on by the Proxy
service
The Azure AD Password Protection Proxy installer automatically creates a Windows Firewall inbound rule
that allows access to any inbound ports listened to by the Azure AD Password Protection Proxy service. If
this rule is later deleted or disabled, DC agents will be unable to communicate with the Proxy service. If the
builtin Windows Firewall has been disabled in lieu of another firewall product, you must configure that
firewall to allow access to any inbound ports listened to by the Azure AD Password Protection Proxy
service. This configuration may be made more specific if the Proxy service has been configured to listen on
a specific static RPC port (using the Set-AzureADPasswordProtectionProxyConfiguration cmdlet).
Proxy service is unable to communicate with Azure

1. Ensure the proxy machine has connectivity to the endpoints listed in the deployment requirements.
2. Ensure that the forest and all proxy servers are registered against the same Azure tenant.
You can check this requirement by running the Get-AzureADPasswordProtectionProxy and
Get-AzureADPasswordProtectionDCAgent PowerShell cmdlets, then compare the AzureTenant property of each
returned item. For correct operation, the reported tenant name must be the same across all DC agents and
proxy servers.
If an Azure tenant registration mismatch condition does exist, this problem can be fixed by running the
Register-AzureADPasswordProtectionProxy and/or Register-AzureADPasswordProtectionForest PowerShell
cmdlets as needed, making sure to use credentials from the same Azure tenant for all registrations.
DC agent is unable to encrypt or decrypt password policy files

This problem can manifest with a variety of symptoms but usually has a common root cause.
Azure AD Password Protection has a critical dependency on the encryption and decryption functionality supplied
by the Microsoft Key Distribution Service, which is available on domain controllers running Windows Server 2012
and later. The KDS service must be enabled and functional on all Windows Server 2012 and later domain
controllers in a domain.
By default the KDS service's service start mode is configured as Manual (Trigger Start). This configuration means
that the first time a client tries to use the service, it is started on-demand. This default service start mode is
acceptable for Azure AD Password Protection to work.
If the KDS service start mode has been configured to Disabled, this configuration must be fixed before Azure AD
Password Protection will work properly.
A simple test for this issue is to manually start the KDS service, either via the Service management MMC console,
or using other management tools (for example, run "net start kdssvc" from a command prompt console). The KDS
service is expected to start successfully and stay running.
The most common root cause for the KDS service being unable to start is that the Active Directory domain
controller object is located outside of the default Domain Controllers OU. This configuration is not supported by
the KDS service and is not a limitation imposed by Azure AD Password Protection. The fix for this condition is to
move the domain controller object to a location under the default Domain Controllers OU.
Weak passwords are being accepted but should not be

This problem may have several causes.
1. Your DC agent(s) are running a public preview software version that has expired. See Public preview DC
agent software has expired.
2. Your DC agent(s) cannot download a policy or is unable to decrypt existing policies. Check for possible
causes in the above topics.
3. The password policy Enforce mode is still set to Audit. If this configuration is in effect, reconfigure it to
Enforce using the Azure AD Password Protection portal. See Enable Password protection.
4. The password policy has been disabled. If this configuration is in effect, reconfigure it to enabled using the
Azure AD Password Protection portal. See Enable Password protection.
5. You have not installed the DC agent software on all domain controllers in the domain. In this situation, it is
difficult to ensure that remote Windows clients target a particular domain controller during a password
change operation. If you have think you have successfully targeted a particular DC where the DC agent
software is installed, you can verify by double-checking the DC agent admin event log: regardless of
outcome, there will be at least one event to document the outcome of the password validation. If there is no
event present for the user whose password is changed, then the password change was likely processed by a
different domain controller.
As an alternative test, try setting\changing passwords while logged in directly to a DC where the DC agent
software is installed. This technique is not recommended for production Active Directory domains.
While incremental deployment of the DC agent software is supported subject to these limitations, Microsoft
strongly recommends that the DC agent software is installed on all domain controllers in a domain as soon
as possible.
6. The password validation algorithm may actually be working as expected. See How are passwords evaluated.
Ntdsutil.exe fails to set a weak DSRM password

Active Directory will always validate a new Directory Services Repair Mode password to make sure it meets the
domain's password complexity requirements; this validation also calls into password filter dlls like Azure AD
Password Protection. If the new DSRM password is rejected, the following error message results:
C:\>ntdsutil.exe
ntdsutil: set dsrm password
Reset DSRM Administrator Password: reset password on server null
Please type password for DS Restore Mode Administrator Account: ********
Please confirm new password: ********
Setting password failed.
WIN32 Error Code: 0xa91
Error Message: Password doesn't meet the requirements of the filter dll's
When Azure AD Password Protection logs the password validation event log event(s) for an Active Directory
DSRM password, it is expected that the event log messages will not include a user name. This behavior occurs
because the DSRM account is a local account that is not part of the actual Active Directory domain.
Domain controller replica promotion fails because of a weak DSRM

password
During the DC promotion process, the new Directory Services Repair Mode password will be submitted to an
existing DC in the domain for validation. If the new DSRM password is rejected, the following error message
results:
Install-ADDSDomainController : Verification of prerequisites for Domain Controller promotion failed. The

Directory Services Restore Mode password does not meet a requirement of the password filter(s). Supply a
suitable password.
Just like in the above issue, any Azure AD Password Protection password validation outcome event will have
empty user names for this scenario.
Domain controller demotion fails due to a weak local Administrator

password
It is supported to demote a domain controller that is still running the DC agent software. Administrators should be
aware however that the DC agent software continues to enforce the current password policy during the demotion
procedure. The new local Administrator account password (specified as part of the demotion operation) is
validated like any other password. Microsoft recommends that secure passwords be chosen for local Administrator
accounts as part of a DC demotion procedure.
Once the demotion has succeeded, and the domain controller has been rebooted and is again running as a normal
member server, the DC agent software reverts to running in a passive mode. It may then be uninstalled at any
time.
Booting into Directory Services Repair Mode

If the domain controller is booted into Directory Services Repair Mode, the DC agent password filter dll detects
this condition and will cause all password validation or enforcement activities to be disabled, regardless of the
currently active policy configuration. The DC agent password filter dll will log a 10023 warning event to the Admin
event log, for example:
The password filter dll is loaded but the machine appears to be a domain controller that has been booted into
Directory Services Repair Mode. All password change and set requests will be automatically approved. No
further messages will be logged until after the next reboot.
Public preview DC agent software has expired

During the Azure AD Password Protection public preview period, the DC agent software was hard-coded to stop
processing password validation requests on the following dates:
Version 1.2.65.0 will stop processing password validation requests on September 1 2019.
Version 1.2.25.0 and prior stopped processing password validation requests on July 1 2019.
As the deadline approaches, all time-limited DC agent versions will emit a 10021 event in the DC agent Admin
event log at boot time that looks like this:
The password filter dll has successfully loaded and initialized.
The allowable trial period is nearing expiration. Once the trial period has expired, the password filter dll
will no longer process passwords. Please contact Microsoft for an newer supported version of the software.
Expiration date: 9/01/2019 0:00:00 AM
This message will not be repeated until the next reboot.
Once the deadline has passed, all time-limited DC agent versions will emit a 10022 event in the DC agent Admin
event log at boot time that looks like this:
The password filter dll is loaded but the allowable trial period has expired. All password change and set
requests will be automatically approved. Please contact Microsoft for a newer supported version of the
software.
No further messages will be logged until after the next reboot.
Since the deadline is only checked on initial boot, you may not see these events until long after the calendar
deadline has passed. Once the deadline has been recognized, no negative effects on either the domain controller or
the larger environment will occur other than all passwords will be automatically approved.
IMPORTANT
Microsoft recommends that expired public preview DC agents be immediately upgraded to the latest version.
An easy way to discover DC agents in your environment that need to be upgrade is by running the
Get-AzureADPasswordProtectionDCAgent cmdlet, for example:
PS C:\> Get-AzureADPasswordProtectionDCAgent
ServerFQDN : bpl1.bpl.com
SoftwareVersion : 1.2.125.0
Domain : bpl.com
Forest : bpl.com
PasswordPolicyDateUTC : 8/1/2019 9:18:05 PM
HeartbeatUTC : 8/1/2019 10:00:00 PM
AzureTenant : bpltest.onmicrosoft.com
For this topic, the SoftwareVersion field is obviously the key property to look at. You can also use PowerShell
filtering to filter out DC agents that are already at or above the required baseline version, for example:
PS C:\> $LatestAzureADPasswordProtectionVersion = "1.2.125.0"

PS C:\> Get-AzureADPasswordProtectionDCAgent | Where-Object {$_.SoftwareVersion -lt
$LatestAzureADPasswordProtectionVersion}
The Azure AD Password Protection Proxy software is not time-limited in any version. Microsoft still recommends
that both DC and proxy agents be upgraded to the latest versions as they are released. The
Get-AzureADPasswordProtectionProxy cmdlet may be used to find Proxy agents that require upgrades, similar to the
example above for DC agents.
Please refer to Upgrading the DC agent and Upgrading the Proxy agent for more details on specific upgrade
procedures.
Emergency remediation
If a situation occurs where the DC agent service is causing problems, the DC agent service may be immediately
shut down. The DC agent password filter dll still attempts to call the non-running service and will log warning
events (10012, 10013), but all incoming passwords are accepted during that time. The DC agent service may then
also be configured via the Windows Service Control Manager with a startup type of “Disabled” as needed.
Another remediation measure would be to set the Enable mode to No in the Azure AD Password Protection portal.
Once the updated policy has been downloaded, each DC agent service will go into a quiescent mode where all
passwords are accepted as-is. For more information, see Enforce mode.
Removal
If it is decided to uninstall the Azure AD password protection software and cleanup all related state from the
domain(s) and forest, this task can be accomplished using the following steps:
IMPORTANT
It is important to perform these steps in order. If any instance of the Proxy service is left running it will periodically re-create
its serviceConnectionPoint object. If any instance of the DC agent service is left running it will periodically re-create its
serviceConnectionPoint object and the sysvol state.
1. Uninstall the Proxy software from all machines. This step does not require a reboot.
2. Uninstall the DC Agent software from all domain controllers. This step requires a reboot.
3. Manually remove all Proxy service connection points in each domain naming context. The location of these
objects may be discovered with the following Active Directory PowerShell command:
$scp = "serviceConnectionPoint"
$keywords = "{ebefb703-6113-413d-9167-9f8dd4d24468}*"
Get-ADObject -SearchScope Subtree -Filter { objectClass -eq $scp -and keywords -like $keywords }
Do not omit the asterisk (“*”) at the end of the $keywords variable value.
The resulting object(s) found via the Get-ADObject command can then be piped to Remove-ADObject , or
deleted manually.
4. Manually remove all DC agent connection points in each domain naming context. There may be one these
objects per domain controller in the forest, depending on how widely the software was deployed. The
location of that object may be discovered with the following Active Directory PowerShell command:
$scp = "serviceConnectionPoint"
$keywords = "{2bac71e6-a293-4d5b-ba3b-50b995237946}*"
Get-ADObject -SearchScope Subtree -Filter { objectClass -eq $scp -and keywords -like $keywords }
The resulting object(s) found via the Get-ADObject command can then be piped to Remove-ADObject , or
deleted manually.
Do not omit the asterisk (“*”) at the end of the $keywords variable value.
5. Manually remove the forest-level configuration state. The forest configuration state is maintained in a
container in the Active Directory configuration naming context. It can be discovered and deleted as follows:
$passwordProtectionConfigContainer = "CN=Azure AD Password Protection,CN=Services," + (Get-

ADRootDSE).configurationNamingContext
Remove-ADObject -Recursive $passwordProtectionConfigContainer
6. Manually remove all sysvol related state by manually deleting the following folder and all of its contents:
\\<domain>\sysvol\<domain fqdn>\AzureADPasswordProtection
If necessary, this path may also be accessed locally on a given domain controller; the default location would
be something like the following path:
%windir%\sysvol\domain\Policies\AzureADPasswordProtection
This path is different if the sysvol share has been configured in a non-default location.
Next steps
Frequently asked questions for Azure AD Password Protection
For more information on the global and custom banned password lists, see the article Ban bad passwords
Azure AD Password Protection on-premises -
Frequently asked questions
This section provides answers to many commonly asked questions about Azure AD Password Protection.
General questions
Q: What guidance should users be given on how to select a secure password?
Microsoft's current guidance on this topic can be found at the following link:
Microsoft Password Guidance
Q: Is on-premises Azure AD Password Protection supported in non-public clouds?
No - on-premises Azure AD Password Protection is only supported in the public cloud. No date has been
announced for non-public cloud availability.
The Azure AD portal does allow modification of the on-premises-specific "Password protection for Windows
Server Active Directory" configuration even in non-public clouds; such changes will be persisted but otherwise will
never take effect. Registration of on-premises proxy agents or forests is unsupported when non-public cloud
credentials are used, and any such registration attempts will always fail.
Q: How can I apply Azure AD Password Protection benefits to a subset of my on-premises users?
Not supported. Once deployed and enabled, Azure AD Password Protection doesn't discriminate - all users receive
equal security benefits.
Q: What is the difference between a password change and a password set (or reset)?
A password change is when a user chooses a new password after proving they have knowledge of the old
password. For example, a password change is what happens when a user logs into Windows and is then prompted
to choose a new password.
A password set (sometimes called a password reset) is when an administrator replaces the password on an
account with a new password, for example by using the Active Directory Users and Computers management tool.
This operation requires a high level of privilege (usually Domain Admin), and the person performing the operation
usually does not have knowledge of the old password. Help-desk scenarios often perform password sets, for
instance when assisting a user who has forgotten their password. You will also see password set events when a
brand new user account is being created for the first time with a password.
The password validation policy behaves the same regardless of whether a password change or set is being done.
The Azure AD Password Protection DC Agent service does log different events to inform you whether a password
change or set operation was done. See Azure AD Password Protection monitoring and logging.
Q: Why are duplicated password rejection events logged when attempting to set a weak password using
the Active Directory Users and Computers management snap-in?
The Active Directory Users and Computers management snap-in will first try to set the new password using the
Kerberos protocol. Upon failure, the snap-in will make a second attempt to set the password using a legacy (SAM
RPC ) protocol (the specific protocols used are not important). If the new password is considered weak by Azure
AD Password Protection, this snap-in behavior will result in two sets of password reset rejection events being
logged.
Q: Why are Azure AD Password Protection password validation events being logged with an empty user
name?
Active Directory supports the ability to test a password to see if it passes the domain's current password
complexity requirements, for example using the NetValidatePasswordPolicy api. When a password is validated in
this way, the testing also includes validation by password-filter-dll based products such as Azure AD Password
Protection - but the user names passed to a given password filter dll will be empty. In this scenario, Azure AD
Password Protection will still validate the password using the currently in-effect password policy and will issue an
event log message to capture the outcome, however the event log message will have empty user name fields.
Q: Is it supported to install Azure AD Password Protection side by side with other password-filter-based
products?
Yes. Support for multiple registered password filter dlls is a core Windows feature and not specific to Azure AD
Password Protection. All registered password filter dlls must agree before a password is accepted.
Q: How can I deploy and configure Azure AD Password Protection in my Active Directory environment
without using Azure?
Not supported. Azure AD Password Protection is an Azure feature that supports being extended into an on-
premises Active Directory environment.
Q: How can I modify the contents of the policy at the Active Directory level?
Not supported. The policy can only be administered using the Azure AD portal. Also see previous question.
Q: Why is DFSR required for sysvol replication?
FRS (the predecessor technology to DFSR ) has many known problems and is entirely unsupported in newer
versions of Windows Server Active Directory. Zero testing of Azure AD Password Protection will be done on FRS -
configured domains.
For more information, please see the following articles:
The Case for Migrating sysvol replication to DFSR
The End is Nigh for FRS
Q: How much disk space does the feature require on the domain sysvol share?
The precise space usage varies since it depends on factors such as the number and length of the banned tokens in
the Microsoft global banned list and the per-tenant custom list, plus encryption overhead. The contents of these
lists are likely to grow in the future. With that in mind, a reasonable expectation is that the feature will need at least
five (5) megabytes of space on the domain sysvol share.
Q: Why is a reboot required to install or upgrade the DC agent software?
This requirement is caused by core Windows behavior.
Q: Is there any way to configure a DC agent to use a specific proxy server?
No. Since the proxy server is stateless, it's not important which specific proxy server is used.
Q: Is it okay to deploy the Azure AD Password Protection Proxy service side by side with other services
such as Azure AD Connect?
Yes. The Azure AD Password Protection Proxy service and Azure AD Connect should never conflict directly with
each other.
Q: In what order should the DC agents and proxies be installed and registered?
Any ordering of Proxy agent installation, DC agent installation, forest registration, and Proxy registration is
supported.
Q: Should I be concerned about the performance hit on my domain controllers from deploying this
feature?
The Azure AD Password Protection DC Agent service shouldn't significantly impact domain controller
performance in an existing healthy Active Directory deployment.
For most Active Directory deployments password change operations are a small proportion of the overall
workload on any given domain controller. As an example, imagine an Active Directory domain with 10000 user
accounts and a MaxPasswordAge policy set to 30 days. On average, this domain will see 10000/30=~333
password change operations each day, which is a minor number of operations for even a single domain controller.
Consider a potential worst case scenario: suppose those ~333 password changes on a single DC were done over a
single hour. For example, this scenario may occur when many employees all come to work on a Monday morning.
Even in that case, we're still looking at ~333/60 minutes = six password changes per minute, which again is not a
significant load.
However if your current domain controllers are already running at performance-limited levels (for example, maxed
out with respect to CPU, disk space, disk I/O, etc.), it is advisable to add additional domain controllers or expand
available disk space, before deploying this feature. Also see question above about sysvol disk space usage above.
Q: I want to test Azure AD Password Protection on just a few DCs in my domain. Is it possible to force
user password changes to use those specific DCs?
No. The Windows client OS controls which domain controller is used when a user changes their password. The
domain controller is selected based on factors such as Active Directory site and subnet assignments, environment-
specific network configuration, etc. Azure AD Password Protection does not control these factors and cannot
influence which domain controller is selected to change a user's password.
One way to partially reach this goal would be to deploy Azure AD Password Protection on all of the domain
controllers in a given Active Directory site. This approach will provide reasonable coverage for the Windows clients
that are assigned to that site, and therefore also for the users that are logging into those clients and changing their
passwords.
Q: If I install the Azure AD Password Protection DC Agent service on just the Primary Domain
Controller (PDC ), will all other domain controllers in the domain also be protected?
No. When a user's password is changed on a given non-PDC domain controller, the clear-text password is never
sent to the PDC (this idea is a common mis-perception). Once a new password is accepted on a given DC, that DC
uses that password to create the various authentication-protocol-specific hashes of that password and then
persists those hashes in the directory. The clear-text password is not persisted. The updated hashes are then
replicated to the PDC. User passwords may in some cases be changed directly on the PDC, again depending on
various factors such as network topology and Active Directory site design. (See the previous question.)
In summary, deployment of the Azure AD Password Protection DC Agent service on the PDC is required to reach
100% security coverage of the feature across the domain. Deploying the feature on the PDC only does not provide
Azure AD Password Protection security benefits for any other DCs in the domain.
Q: Why is custom smart lockout not working even after the agents are installed in my on-premises
Active Directory environment?
Custom smart lockout is only supported in Azure AD. Changes to the custom smart lockout settings in the Azure
AD portal have no effect on the on-premises Active Directory environment, even with the agents installed.
Q: Is a System Center Operations Manager management pack available for Azure AD Password
Protection?
No.
Q: Why is Azure AD still rejecting weak passwords even though I've configured the policy to be in Audit
mode?
Audit mode is only supported in the on-premises Active Directory environment. Azure AD is implicitly always in
"enforce" mode when it evaluates passwords.
Additional content
The following links are not part of the core Azure AD Password Protection documentation but may be a useful
source of additional information on the feature.
Azure AD Password Protection is now generally available!
Email Phishing Protection Guide – Part 15: Implement the Microsoft Azure AD Password Protection Service (for
On-Premises too!)
Azure AD Password Protection and Smart Lockout are now in Public Preview!
Microsoft Premier\Unified support training available

If you're interested in learning more about Azure AD Password Protection and deploying it in your environment,
you can take advantage of a Microsoft proactive service available to those customers with a Premier or Unified
support contract. The service is called Azure Active Directory: Password Protection. Contact your Technical
Account Manager for more information.
Next steps
If you have an on-premises Azure AD Password Protection question that isn't answered here, submit a Feedback
item below - thank you!
Azure AD Password Protection agent version history
1.2.125.0
Release date: 3/22/2019
Fix minor typo errors in event log messages
Update EULA agreement to final General Availability version
NOTE
Build 1.2.125.0 is the General Availability build. Thank you again to everyone has provided feedback on the product!
1.2.116.0
The Get-AzureADPasswordProtectionProxy and Get-AzureADPasswordProtectionDCAgent cmdlets now
report software version and the current Azure tenant with the following limitations:
Software version and Azure tenant data are only available for DC agents and proxies running version
1.2.116.0 or later.
Azure tenant data may not be reported until a re-registration (or renewal) of the proxy or forest has
occurred.
The Proxy service now requires that .NET 4.7 is installed.
.NET 4.7 should already be installed on a fully updated Windows Server. If this is not the case, download
and run the installer found at The .NET Framework 4.7 offline installer for Windows.
On Server Core systems it may be necessary to pass the /q flag to the .NET 4.7 installer to get it to
succeed.
The Proxy service now supports automatic upgrade. Automatic upgrade uses the Microsoft Azure AD Connect
Agent Updater service which is installed side-by-side with the Proxy service. Automatic upgrade is on by
default.
Automatic upgrade can be enabled or disabled using the Set-AzureADPasswordProtectionProxyConfiguration
cmdlet. The current setting can be queried using the Get-AzureADPasswordProtectionProxyConfiguration
cmdlet.
The service binary for the DC agent service has been renamed to AzureADPasswordProtectionDCAgent.exe.
The service binary for the Proxy service has been renamed to AzureADPasswordProtectionProxy.exe. Firewall
rules may need to be modified accordingly if a third-party firewall is in-use.
NOTE: if an http proxy config file was being used in a previous Proxy install, it will need to be renamed
(from proxyservice.exe.config to AzureADPasswordProtectionProxy.exe.config) after this upgrade.
All time-limited functionality checks have been removed from the DC agent.
Minor bugs fixes and logging improvements.
1.2.65.0
Changes:
DC agent and proxy service are now supported on Server Core. Mininimum OS requirements are
unchanged from before: Windows Server 2012 for DC agents, and Windows Server 2012 R2 for proxies.
The Register-AzureADPasswordProtectionProxy and Register-AzureADPasswordProtectionForest cmdlets
now support device-code-based Azure authentication modes.
The Get-AzureADPasswordProtectionDCAgent cmdlet will ignore mangled and/or invalid service
connection points. This fixes the bug where domain controllers would sometimes show up multiple times in
the output.
The Get-AzureADPasswordProtectionSummaryReport cmdlet will ignore mangled and/or invalid service
connection points. This fixes the bug where domain controllers would sometimes show up multiple times in
the output.
The Proxy powershell module is now registered from %ProgramFiles%\WindowsPowerShell\Modules. The
machine's PSModulePath environment variable is no longer modified.
A new Get-AzureADPasswordProtectionProxy cmdlet has been added to aid in discovering registered
proxies in a forest or domain.
The DC agent uses a new folder in the sysvol share for replicating password policies and other files.
Old folder location:
\\<domain>\sysvol\<domain fqdn>\Policies\{4A9AB66B-4365-4C2A-996C-58ED9927332D}
New folder location:

\\<domain>\sysvol\<domain fqdn>\AzureADPasswordProtection
(This change was made to avoid false-positive "orphaned GPO" warnings.)
NOTE
No migration or sharing of data will be done between the old folder and the new folder. Older DC agent versions will
continue to use the old location until upgraded to this version or later. Once all DC agents are running version
1.2.65.0 or later, the old sysvol folder may be manually deleted.
The DC agent and proxy service will now detect and delete mangled copies of their respective service
connection points.
Each DC agent will periodically delete mangled and stale service connection points in its domain, for both
DC agent and proxy service connection points. Both DC agent and proxy service connection points are
considered stale if its heartbeat timestamp is older than seven days.
The DC agent will now renew the forest certificate as needed.
The Proxy service will now renew the proxy certificate as needed.
Updates to password validation algorithm: the global banned password list and customer-specific banned
password list (if configured) are combined prior to password validations. A given password may now be
rejected (fail or audit-only) if it contains tokens from both the global and customer-specific list. The event log
documentation has been updated to reflect this; please see Monitor Azure AD Password Protection.
Performance and robustness fixes
Improved logging
WARNING
Time-limited functionality: the DC agent service in this release (1.2.65.0) will stop processing password validation requests as
of September 1st 2019. DC agent services in prior releases (see list below) will stop processing as of July 1st 2019. The DC
agent service in all versions will log 10021 events to the Admin event log in the two months leading up these deadlines. All
time-limit restrictions will be removed in the upcoming GA release. The Proxy agent service is not time-limited in any version
but should still be upgraded to the latest version in order to take advantage of all subsequent bug fixes and other
improvements.
1.2.25.0
Fixes:
DC agent and proxy service should no longer fail due to certificate trust failures.
DC agent and proxy service have additional fixes for FIPS -compliant machines.
Proxy service will now work properly in a TLS 1.2-only networking environment.
Minor performance and robustness fixes
Improved logging
Changes:
The minimum required OS level for the Proxy service is now Windows Server 2012 R2. The minimum required
OS level for the DC agent service remains at Windows Server 2012.
The Proxy service now requires .NET version 4.6.2.
The password validation algorithm uses an expanded character normalization table. This may result in
passwords being rejected that were accepted in prior versions.
1.2.10.0
Fixes:
Register-AzureADPasswordProtectionProxy and Register-AzureADPasswordProtectionForest now support
multi-factor authentication
Register-AzureADPasswordProtectionProxy requires a WS2012 or later domain controller in the domain to
avoid encryption errors.
DC agent service is more reliable about requesting a new password policy from Azure on startup.
DC agent service will request a new password policy from Azure every hour if necessary, but will now do so on
a randomly selected start time.
DC agent service will no longer cause an indefinite delay in new DC advertisement when installed on a server
prior to its promotion as a replica.
DC agent service will now honor the “Enable password protection on Windows Server Active Directory”
configuration setting
Both DC agent and proxy installers will now support in-place upgrade when upgrading to future versions.
WARNING
In-place upgrade from version 1.1.10.3 is not supported and will result in an installation error. To upgrade to version 1.2.10
or later, you must first completely uninstall the DC agent and proxy service software, then install the new version from
scratch. Re-registration of the Azure AD password protection Proxy service is required. It is not required to re-register the
forest.
NOTE
In-place upgrades of the DC agent software will require a reboot.
DC agent and proxy service now support running on a server configured to only use FIPS -compliant
algorithms.
Minor performance and robustness fixes
Improved logging
1.1.10.3
Initial public preview release
Next steps
Deploy Azure AD Password Protection
Azure Active Directory smart lockout
Smart lockout assists in locking out bad actors who are trying to guess your users’ passwords or use brute-force
methods to get in. It can recognize sign-ins coming from valid users and treat them differently than ones of
attackers and other unknown sources. Smart lockout locks out the attackers, while letting your users continue to
access their accounts and be productive.
By default, smart lockout locks the account from sign-in attempts for one minute after 10 failed attempts. The
account locks again after each subsequent failed sign-in attempt, for one minute at first and longer in subsequent
attempts.
Smart lockout tracks the last three bad password hashes to avoid incrementing the lockout counter for the same
password. If someone enters the same bad password multiple times, this behavior will not cause the account to
lockout.
NOTE
Hash tracking functionality is not available for customers with pass-through authentication enabled as authentication
happens on-premises not in the cloud.
Federated deployments using AD FS 2016 and AF FS 2019 can enable similar benefits using AD FS Extranet
Lockout and Extranet Smart Lockout.
Smart lockout is always on for all Azure AD customers with these default settings that offer the right mix of
security and usability. Customization of the smart lockout settings, with values specific to your organization,
requires paid Azure AD licenses for your users.
Using smart lockout does not guarantee that a genuine user will never be locked out. When smart lockout locks a
user account, we try our best to not lockout the genuine user. The lockout service attempts to ensure that bad
actors can’t gain access to a genuine user account.
Each Azure Active Directory data center tracks lockout independently. A user will have (threshold_limit *
datacenter_count) number of attempts, if the user hits each data center.
Smart Lockout uses familiar location vs unfamiliar location to differentiate between a bad actor and the
genuine user. Unfamiliar and familiar locations will both have separate lockout counters.
Smart lockout can be integrated with hybrid deployments, using password hash sync or pass-through
authentication to protect on-premises Active Directory accounts from being locked out by attackers. By setting
smart lockout policies in Azure AD appropriately, attacks can be filtered out before they reach on-premises Active
Directory.
When using pass-through authentication, you need to make sure that:
The Azure AD lockout threshold is less than the Active Directory account lockout threshold. Set the values so
that the Active Directory account lockout threshold is at least two or three times longer than the Azure AD
lockout threshold.
The Azure AD lockout duration must be set longer than the Active Directory reset account lockout counter after
duration. Be aware that the Azure AD duration is set in seconds, while the AD duration is set in minutes.
For example, if you want your Azure AD counter to be higher than AD, then Azure AD would be 120 seconds (2
minutes) while your on prem AD is set to 1 minute (60 seconds).
IMPORTANT
Currently an administrator can't unlock the users' cloud accounts if they have been locked out by the Smart Lockout
capability. The administrator must wait for the lockout duration to expire.
Verify on-premises account lockout policy

Use the following instructions to verify your on-premises Active Directory account lockout policy:
1. Open the Group Policy Management tool.
2. Edit the group policy that includes your organization's account lockout policy, for example, the Default
Domain Policy.
3. Browse to Computer Configuration > Policies > Windows Settings > Security Settings > Account
Policies > Account Lockout Policy.
4. Verify your Account lockout threshold and Reset account lockout counter after values.
Manage Azure AD smart lockout values

Based on your organizational requirements, smart lockout values may need to be customized. Customization of
the smart lockout settings, with values specific to your organization, requires paid Azure AD licenses for your
users.
To check or modify the smart lockout values for your organization, use the following steps:
1. Sign in to the Azure portal, and click on Azure Active Directory, then Authentication Methods.
2. Set the Lockout threshold, based on how many failed sign-ins are allowed on an account before its first
lockout. The default is 10.
3. Set the Lockout duration in seconds, to the length in seconds of each lockout. The default is 60 seconds (one
minute).
NOTE
If the first sign-in after a lockout also fails, the account locks out again. If an account locks repeatedly, the lockout duration
increases.
How to determine if the Smart lockout feature is working or not

When the smart lockout threshold is triggered, you will get the following message while the account is locked:
Your account is temporarily locked to prevent unauthorized use. Try again later, and if you still have
trouble, contact your admin.
Next steps
Find out how to ban bad passwords in your organization using Azure AD.
Configure self-service password reset to allow users to unlock their own accounts.
Enable passwordless security key sign in for Azure AD
(preview)
Requirements
Combined registration preview with users enabled for SSPR
FIDO2 security key preview requires compatible FIDO2 security keys
WebAuthN requires Microsoft Edge on Windows 10 version 1809 or higher
FIDO2 based Windows sign in requires Azure AD joined Windows 10 version 1809 or higher
Prepare devices for preview

Devices that you will be piloting with must be running Windows 10 version 1809 or higher. The best experience is
on Windows 10 version 1903 or higher.
Enable security keys for Windows sign in

Organizations may choose to use one or more of the following methods to enable the use of security keys for
Windows sign in.
Enable credential provider via Intune
2. Browse to Microsoft Intune > Device enrollment > Windows enrollment > Windows Hello for
Business > Properties.
3. Under Settings set Use security keys for sign-in to Enabled.
Configuration of security keys for sign in, is not dependent on configuring Windows Hello for Business.
Enable targeted Intune deployment
To target specific device groups to enable the credential provider, use the following custom settings via Intune.
2. Browse to Microsoft Intune > Device configuration > Profiles > Create profile.
3. Configure the new profile with the following settings
a. Name: Security Keys for Windows Sign-In
b. Description: Enables FIDO Security Keys to be used during Windows Sign In
c. Platform: Windows 10 and later
d. Platform type: Custom
e. Custom OMA-URI Settings:
a. Name: Turn on FIDO Security Keys for Windows Sign-In
b. OMA-URI: ./Device/Vendor/MSFT/PassportForWork/SecurityKey/UseSecurityKeyForSignin
c. Data Type: Integer
d. Value: 1
4. This policy can be assigned to specific users, devices, or groups. More information can be found in the article
Assign user and device profiles in Microsoft Intune.
Enable credential provider via provisioning package
For devices not managed by Intune, a provisioning package can be installed to enable the functionality. The
Windows Configuration Designer app can be installed from the Microsoft Store.
1. Launch the Windows Configuration Designer.
2. Select File > New project.
3. Give your project a name and take note of the path where your project is created.
4. Select Next.
5. Leave Provisioning package selected as the Selected project workflow and select Next.
6. Select All Windows desktop editions under Choose which settings to view and configure and select
Next.
7. Select Finish.
8. In your newly created project, browse to Runtime settings > WindowsHelloForBusiness > SecurityKeys >
UseSecurityKeyForSignIn.
9. Set UseSecurityKeyForSignIn to Enabled.
10. Select Export > Provisioning package
11. Leave the defaults in the Build window under Describe the provisioning package and select Next.
12. Leave the defaults in the Build window under Select security details for the provisioning package and
select Next.
13. Take note of or change the path in the Build windows under Select where to save the provisioning
package and select Next.
14. Select Build on the Build the provisioning package page.
15. Save the two files created (ppkg and cat) to a location where you can apply them to machines later.
16. Follow the guidance in the article Apply a provisioning package, to apply the provisioning package you created.
Obtain FIDO2 security keys

See the section FIDO2 Security Keys, in the article What is passwordless? for more information about supported
keys and manufacturers.
NOTE
If you purchase and plan to use NFC based security keys you will need a supported NFC reader.
Enable passwordless authentication method
Enable the combined registration experience
Registration features for passwordless authentication methods rely on the combined registration preview. Follow
the steps in the article Enable combined security information registration (preview ), to enable the combined
registration preview.
Enable new passwordless authentication method
1. Sign in to the Azure portal
2. Browse to Azure Active Directory > Security > Authentication methods > Authentication method
policy (Preview)
3. Under each Method, choose the following options
a. Enable - Yes or No
b. Target - All users or Select users
4. Save each method
WARNING
The FIDO2 “Key restriction policies” do not work yet. This functionality will be available before general availability, please do
not change these policies from default.
NOTE
You don’t need to opt in to both of the passwordless methods (if you want to preview only one passwordless method, you
can enable only that method). We encourage you try out both methods since they both have their own benefits.
User registration and management of FIDO2 security keys

1. Browse to https://myprofile.microsoft.com
2. Sign in if not already
3. Click Security Info
a. If the user already has at least one Azure Multi-Factor Authentication method registered, they can
immediately register a FIDO2 security key.
b. If they don’t have at least one Azure Multi-Factor Authentication method registered, they must add one.
4. Add a FIDO2 Security key by clicking Add method and choosing Security key
5. Choose USB device or NFC device
6. Have your key ready and choose Next
7. A box will appear and ask you to create/enter a PIN for your security key, then perform the required gesture for
your key either biometric or touch.
8. You will be returned to the combined registration experience and asked to provide a meaningful name for your
token so you can identify which one if you have multiple. Click Next.
9. Click Done to complete the process
Manage security key biometric, PIN, or reset security key
Windows 10 version 1809
Companion software from the security key vendor is required
Windows 10 version 1903 or higher
Users can open Windows Settings on their device > Accounts > Security Key
Users can change their PIN, update biometrics, or reset their security key
User registration and management of Microsoft Authenticator app
To configure the Microsoft Authenticator app for phone sign in, follow the guidance in the article Sign in to your
accounts using the Microsoft Authenticator app.
Sign in with passwordless credential

Sign in at the lock screen
In the example below a user Bala Sandhu has already provisioned their FIDO2 security key. Bala can choose the
security key credential provider from the Windows 10 lock screen and insert the security key to sign into Windows.
Sign in on the web

In the example below a user has already provisioned their FIDO2 security key. The user can choose to sign in on
the web with their FIDO2 security key inside of the Microsoft Edge browser on Windows 10 version 1809 or
higher.
Known issues
Security key provisioning
Administrator provisioning and de-provisioning of security keys is not available in the public preview.
Hybrid Azure AD join
Users relying on WIA SSO that use managed credentials like FIDO2 security keys or passwordless sign in with
Microsoft Authenticator app need to Hybrid Join on Windows 10 to get the benefits of SSO. However, security
keys only work for Azure Active Directory Joined machines for now. We recommend you only try out FIDO2
security keys for the Windows lock screen on pure Azure Active Directory Joined machines. This limitation doesn’t
apply for the web.
UPN changes
We are working on supporting a feature that allows UPN change on hybrid AADJ and AADJ devices. If a user’s
UPN changes, you can no longer modify FIDO2 security keys to account for that. So the only approach is to reset
the device and the user has to re-register.
Next steps
Learn about device registration
Learn about Azure Multi-Factor Authentication
Enable passwordless sign-in with the Microsoft
Authenticator app (preview)
The Microsoft Authenticator app can be used to sign in to any Azure AD account without using a password.
Similar to the technology of Windows Hello for Business, the Microsoft Authenticator uses key-based
authentication to enable a user credential that is tied to a device and uses a biometric or PIN. This authentication
method can be used on any device platform, including mobile, and with any app or website that integrates with
Microsoft authentication libraries.
Instead of seeing a prompt for a password after entering a username, a person who has enabled phone sign-in
from the Microsoft Authenticator app will see a message telling them to tap a number in their app. In the app, the
user must match the number, choose Approve, then provide their PIN or biometric, then the authentication will
complete.
NOTE
This capability has been in the Microsoft Authenticator app since March of 2017, so there is a possibility that when the policy
is enabled for a directory, users may encounter this flow immediately, and see an error message if they have not been
enabled by policy. Be aware and prepare your users for this change.
Prerequisites
Azure Multi-Factor Authentication, with push notifications allowed as a verification method
Latest version of Microsoft Authenticator installed on devices running iOS 8.0 or greater, or Android 6.0 or
greater.
NOTE
If you enabled the previous Microsoft Authenticator app passwordless sign-in preview using Azure AD PowerShell, it was
enabled for your entire directory. If you enable using this new method, it will supercede the PowerShell policy. We
recommend enabling for all users in your tenant via the new Authentication Methods, otherwise users not in the new policy
will no longer be able to log in passwordlessly.
Enable passwordless authentication methods

Enable the combined registration experience
Registration features for passwordless authentication methods rely on the combined registration preview. Follow
the steps in the article Enable combined security information registration (preview ), to enable the combined
registration preview.
Enable passwordless phone sign-in authentication methods
1. Sign in to the Azure portal
2. Browse to Azure Active Directory > Authentication methods > Authentication method policy
(Preview)
3. Under Passwordless phone sign-in, choose the following options
a. Enable - Yes or No
b. Target - All users or Select users
4. Save to set the new policy
User registration and management of Microsoft Authenticator app

1. Browse to https://aka.ms/mysecurityinfo
2. Sign in if not already
3. Add an authenticator app by clicking Add method, choosing Authenticator app, and clicking Add
4. Follow the instructions to install and configure the Microsoft Authenticator app on your device
5. Click Done to complete Authenticator MFA app setup flow.
6. In Microsoft Authenticator, choose Enable phone sign-in from the account drop-down menu
7. Follow the instructions in the app to finish registering for passwordless phone sign-in.
Organizations can point their users to the article Sign in with your phone, not your password for further assistance
setting up in the Microsoft Authenticator app and enabling phone sign-in.
Sign in with passwordless credential

For public preview, there is no way to enforce users to create or use this new credential. A user will only encounter
passwordless sign-in once an admin has enabled their tenant and the user has updated their Microsoft
Authenticator app to enable phone sign-in.
After typing your username on the web and selecting Next, users are presented with a number and are prompted
in their Microsoft Authenticator app to select the appropriate number to authenticate instead of using their
password.
Known Issues
User is not enabled by policy but still has passwordless phone sign-in method in Microsoft Authenticator
It is possible that a user has at some point created a passwordless phone sign-in credential in their current
Microsoft Authenticator app, or on an earlier device. Once an admin enables the authentication method policy for
passwordless phone sign-in, any user with a credential registered, will start to experience the new sign-in prompt,
regardless of whether they have been enabled to use the policy or not. If the user has not been allowed to use the
credential by policy, they will see an error after completing the authentication flow.
The admin can choose to enable the user to use passwordless phone sign-in, or the user must remove the method.
If the user no longer has the registered device, they can go to https://aka.ms/mysecurityinfo and remove it. If they
are still using the Authenticator for MFA, they can choose Disable phone sign-in from within the Microsoft
Authenticator.
AD FS integration
When a user has enabled the Microsoft Authenticator passwordless credential, authentication for that user will
always default to sending a notification for approval. This logic prevents users in a hybrid tenant from being
directed to ADFS for sign-in verification without the user taking an additional step to click “Use your password
instead.” This process will also bypass any on-premises Conditional Access policies, and Pass-through
authentication flows.
If a user has an unanswered passwordless phone sign-in verification pending and attempts to sign in again, the
user may be taken to ADFS to enter a password instead.
Azure MFA server
End users who are enabled for MFA through an organization’s on-premises Azure MFA server can still create and
use a single passwordless phone sign in credential. If the user attempts to upgrade multiple installations (5+) of
the Microsoft Authenticator with the credential, this change may result in an error.
Device registration
One of the prerequisites to create this new, strong credential, is that the device must also registered within the
Azure AD tenant to an individual user. Due to current device registration restrictions, a device can only be
registered in a single tenant. This limit means that only one work or school account in the Microsoft Authenticator
app can be enabled for phone sign-in.
NOTE
Device registration is not the same as device management or "MDM." It only associates a device ID and a user ID together in
the Azure AD directory.
Next steps
What is passwordless?
Learn about device registration
Learn about Azure Multi-Factor Authentication
Get started with certificate-based authentication in
Azure Active Directory
Certificate-based authentication enables you to be authenticated by Azure Active Directory with a client certificate
on a Windows, Android, or iOS device when connecting your Exchange online account to:
Microsoft mobile applications such as Microsoft Outlook and Microsoft Word
Exchange ActiveSync (EAS ) clients
Configuring this feature eliminates the need to enter a username and password combination into certain mail and
Microsoft Office applications on your mobile device.
This topic:
Provides you with the steps to configure and utilize certificate-based authentication for users of tenants in
Office 365 Enterprise, Business, Education, and US Government plans. This feature is available in preview in
Office 365 China, US Government Defense, and US Government Federal plans.
Assumes that you already have a public key infrastructure (PKI) and AD FS configured.
Requirements
To configure certificate-based authentication, the following statements must be true:
Certificate-based authentication (CBA) is only supported for Federated environments for browser applications
or native clients using modern authentication (ADAL ). The one exception is Exchange Active Sync (EAS ) for
Exchange Online (EXO ), which can be used for federated and managed accounts.
The root certificate authority and any intermediate certificate authorities must be configured in Azure Active
Directory.
Each certificate authority must have a certificate revocation list (CRL ) that can be referenced via an internet-
facing URL.
You must have at least one certificate authority configured in Azure Active Directory. You can find related steps
in the Configure the certificate authorities section.
For Exchange ActiveSync clients, the client certificate must have the user’s routable email address in Exchange
online in either the Principal Name or the RFC822 Name value of the Subject Alternative Name field. Azure
Active Directory maps the RFC822 value to the Proxy Address attribute in the directory.
Your client device must have access to at least one certificate authority that issues client certificates.
A client certificate for client authentication must have been issued to your client.
Step 1: Select your device platform

As a first step, for the device platform you care about, you need to review the following:
The Office mobile applications support
The specific implementation requirements
The related information exists for the following device platforms:
Android
iOS
Step 2: Configure the certificate authorities
To configure your certificate authorities in Azure Active Directory, for each certificate authority, upload the
following:
The public portion of the certificate, in .cer format
The internet-facing URLs where the Certificate Revocation Lists (CRLs) reside
The schema for a certificate authority looks as follows:
class TrustedCAsForPasswordlessAuth
{
CertificateAuthorityInformation[] certificateAuthorities;
}
class CertificateAuthorityInformation
{
CertAuthorityType authorityType;
X509Certificate trustedCertificate;
string crlDistributionPoint;
string deltaCrlDistributionPoint;
string trustedIssuer;
string trustedIssuerSKI;
}
enum CertAuthorityType
{
RootAuthority = 0,
IntermediateAuthority = 1
}
For the configuration, you can use the Azure Active Directory PowerShell Version 2:
1. Start Windows PowerShell with administrator privileges.
2. Install the Azure AD module version 2.0.0.33 or higher.
Install-Module -Name AzureAD –RequiredVersion 2.0.0.33
As a first configuration step, you need to establish a connection with your tenant. As soon as a connection to your
tenant exists, you can review, add, delete, and modify the trusted certificate authorities that are defined in your
directory.
Connect
To establish a connection with your tenant, use the Connect-AzureAD cmdlet:
Connect-AzureAD
Retrieve
To retrieve the trusted certificate authorities that are defined in your directory, use the Get-
AzureADTrustedCertificateAuthority cmdlet.
Get-AzureADTrustedCertificateAuthority
Add
To create a trusted certificate authority, use the New -AzureADTrustedCertificateAuthority cmdlet and set the
crlDistributionPoint attribute to a correct value:
$cert=Get-Content -Encoding byte "[LOCATION OF THE CER FILE]"

$new_ca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation
$new_ca.AuthorityType=0
$new_ca.TrustedCertificate=$cert
$new_ca.crlDistributionPoint="<CRL Distribution URL>"
New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_ca
Remove
To remove a trusted certificate authority, use the Remove-AzureADTrustedCertificateAuthority cmdlet:
$c=Get-AzureADTrustedCertificateAuthority
Remove-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[2]
Modify
To modify a trusted certificate authority, use the Set-AzureADTrustedCertificateAuthority cmdlet:
$c=Get-AzureADTrustedCertificateAuthority
$c[0].AuthorityType=1
Set-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[0]
Step 3: Configure revocation

To revoke a client certificate, Azure Active Directory fetches the certificate revocation list (CRL ) from the URLs
uploaded as part of certificate authority information and caches it. The last publish timestamp (Effective Date
property) in the CRL is used to ensure the CRL is still valid. The CRL is periodically referenced to revoke access to
certificates that are a part of the list.
If a more instant revocation is required (for example, if a user loses a device), the authorization token of the user
can be invalidated. To invalidate the authorization token, set the StsRefreshTokenValidFrom field for this
particular user using Windows PowerShell. You must update the StsRefreshTokenValidFrom field for each user
you want to revoke access for.
To ensure that the revocation persists, you must set the Effective Date of the CRL to a date after the value set by
StsRefreshTokenValidFrom and ensure the certificate in question is in the CRL.
The following steps outline the process for updating and invalidating the authorization token by setting the
StsRefreshTokenValidFrom field.
To configure revocation:
1. Connect with admin credentials to the MSOL service:
$msolcred = get-credential
connect-msolservice -credential $msolcred
2. Retrieve the current StsRefreshTokensValidFrom value for a user:
$user = Get-MsolUser -UserPrincipalName test@yourdomain.com`

$user.StsRefreshTokensValidFrom
3. Configure a new StsRefreshTokensValidFrom value for the user equal to the current timestamp:
Set-MsolUser -UserPrincipalName test@yourdomain.com -StsRefreshTokensValidFrom ("03/05/2016")
The date you set must be in the future. If the date is not in the future, the StsRefreshTokensValidFrom property is
not set. If the date is in the future, StsRefreshTokensValidFrom is set to the current time (not the date indicated
by Set-MsolUser command).
Step 4: Test your configuration

Testing your certificate
As a first configuration test, you should try to sign in to Outlook Web Access or SharePoint Online using your on-
device browser.
If your sign-in is successful, then you know that:
The user certificate has been provisioned to your test device
AD FS is configured correctly
Testing Office mobile applications
To test certificate-based authentication on your mobile Office application:
1. On your test device, install an Office mobile application (for example, OneDrive).
2. Launch the application.
3. Enter your username, and then select the user certificate you want to use.
You should be successfully signed in.
Testing Exchange ActiveSync client applications
To access Exchange ActiveSync (EAS ) via certificate-based authentication, an EAS profile containing the client
certificate must be available to the application.
The EAS profile must contain the following information:
The user certificate to be used for authentication
The EAS endpoint (for example, outlook.office365.com)
An EAS profile can be configured and placed on the device through the utilization of Mobile device management
(MDM ) such as Intune or by manually placing the certificate in the EAS profile on the device.
Testing EAS client applications on Android
To test certificate authentication:
1. Configure an EAS profile in the application that satisfies the requirements in the prior section.
2. Open the application, and verify that mail is synchronizing.
Next steps
Additional information about certificate-based authentication on Android devices.
Additional information about certificate-based authentication on iOS devices.
Azure Active Directory certificate-based
authentication on Android
Android devices can use certificate-based authentication (CBA) to authenticate to Azure Active Directory using a
client certificate on their device when connecting to:
Office mobile applications such as Microsoft Outlook and Microsoft Word
This topic provides you with the requirements and the supported scenarios for configuring CBA on an
iOS (Android) device for users of tenants in Office 365 Enterprise, Business, Education, US Government, China,
and Germany plans.
This feature is available in preview in Office 365 US Government Defense and Federal plans.
Microsoft mobile applications support

APPS SUPPORT
Azure Information Protection app
Intune Company Portal
Microsoft Teams
OneNote
OneDrive
Outlook
Power BI
Skype for Business
Word / Excel / PowerPoint
Yammer
Implementation requirements
The device OS version must be Android 5.0 (Lollipop) and above.
A federation server must be configured.
For Azure Active Directory to revoke a client certificate, the ADFS token must have the following claims:
http://schemas.microsoft.com/ws/2008/06/identity/claims/<serialnumber> (The serial number of the client
certificate)
http://schemas.microsoft.com/2012/12/certificatecontext/field/<issuer> (The string for the issuer of the client
certificate)
Azure Active Directory adds these claims to the refresh token if they are available in the ADFS token (or any other
SAML token). When the refresh token needs to be validated, this information is used to check the revocation.
As a best practice, you should update your organization's ADFS error pages with the following information:
The requirement for installing the Microsoft Authenticator on Android.
Instructions on how to get a user certificate.
For more information, see Customizing the AD FS Sign-in Pages.
Some Office apps (with modern authentication enabled) send ‘prompt=login’ to Azure AD in their request. By
default, Azure AD translates ‘prompt=login’ in the request to ADFS as ‘wauth=usernamepassworduri’ (asks ADFS
to do U/P Auth) and ‘wfresh=0’ (asks ADFS to ignore SSO state and do a fresh authentication). If you want to
enable certificate-based authentication for these apps, you need to modify the default Azure AD behavior. Set the
‘PromptLoginBehavior’ in your federated domain settings to ‘Disabled‘. You can use the
MSOLDomainFederationSettings cmdlet to perform this task:
Set-MSOLDomainFederationSettings -domainname <domain> -PromptLoginBehavior Disabled
Exchange ActiveSync clients support

Certain Exchange ActiveSync applications on Android 5.0 (Lollipop) or later are supported. To determine if your
email application does support this feature, contact your application developer.
Next steps
If you want to configure certificate-based authentication in your environment, see Get started with certificate-
based authentication on Android for instructions.
Azure Active Directory certificate-based
authentication on iOS
iOS devices can use certificate-based authentication (CBA) to authenticate to Azure Active Directory using a client
certificate on their device when connecting to:
Office mobile applications such as Microsoft Outlook and Microsoft Word
This topic provides you with the requirements and the supported scenarios for configuring CBA on an
iOS (Android) device for users of tenants in Office 365 Enterprise, Business, Education, US Government, China,
and Germany plans.
This feature is available in preview in Office 365 US Government Defense and Federal plans.
Microsoft mobile applications support

APPS SUPPORT
Azure Information Protection app
Intune Company Portal
Microsoft Teams
OneNote
OneDrive
Outlook
Power BI
Skype for Business
Word / Excel / PowerPoint
Yammer
Requirements
The device OS version must be iOS 9 and above
A federation server must be configured.
Microsoft Authenticator is required for Office applications on iOS.
For Azure Active Directory to revoke a client certificate, the ADFS token must have the following claims:
http://schemas.microsoft.com/ws/2008/06/identity/claims/<serialnumber> (The serial number of the client
certificate)
http://schemas.microsoft.com/2012/12/certificatecontext/field/<issuer> (The string for the issuer of the client
certificate)
Azure Active Directory adds these claims to the refresh token if they are available in the ADFS token (or any other
SAML token). When the refresh token needs to be validated, this information is used to check the revocation.
As a best practice, you should update your organization's ADFS error pages with the following information:
The requirement for installing the Microsoft Authenticator on iOS
Instructions on how to get a user certificate.
For more information, see Customizing the AD FS Sign-in Pages.
Some Office apps (with modern authentication enabled) send ‘prompt=login’ to Azure AD in their request. By
default, Azure AD translates ‘prompt=login’ in the request to ADFS as ‘wauth=usernamepassworduri’ (asks ADFS
to do U/P Auth) and ‘wfresh=0’ (asks ADFS to ignore SSO state and do a fresh authentication). If you want to
enable certificate-based authentication for these apps, you need to modify the default Azure AD behavior. Just set
the ‘PromptLoginBehavior’ in your federated domain settings to ‘Disabled‘. You can use the
MSOLDomainFederationSettings cmdlet to perform this task:
Set-MSOLDomainFederationSettings -domainname <domain> -PromptLoginBehavior Disabled
Exchange ActiveSync clients support

On iOS 9 or later, the native iOS mail client is supported. For all other Exchange ActiveSync applications, to
determine if this feature is supported, contact your application developer.
Next steps
If you want to configure certificate-based authentication in your environment, see Get started with certificate-
based authentication on Android for instructions.
Authentication methods usage & insights (preview)
Usage & insights enables you to understand how authentication methods for features like Azure Multi-Factor
Authentication and self-service password reset are working in your organization. This reporting capability
provides your organization with the means to understand what methods are being registered and how they are
being used.
Permissions and licenses

The following roles can access usage and insights:
Global Administrator
Security Reader
Security Administrator
Reports Reader
No additional licensing is required to access usage and insights. Azure Multi-Factor Authentication and self-
service password reset (SSPR ) licensing information can be found on the Azure Active Directory pricing site.
How it works
To access authentication method usage and insights:
1. Browse to the Azure portal.
2. Browse to Azure Active Directory > Password reset > Usage & insights.
3. From the Registration or Usage overviews, you can choose to open the pre-filtered reports to filter based on
your needs.
To access usage & insights directly, go to
https://portal.azure.com/#blade/Microsoft_AAD_IAM/AuthMethodsOverviewBlade. This link will bring you to the
registration overview.
The Users registered, Users enabled, and Users capable tiles show the following registration data for your users:
Registered: A user is considered registered if they (or an admin) have registered enough authentication
methods to meet your organization's SSPR or Multi-Factor Authentication policy.
Enabled: A user is considered enabled if they are in scope for the SSPR policy. If SSPR is enabled for a group,
then the user is considered enabled if they are in that group. If SSPR is enabled for all users, then all users in
the tenant (excluding guests) are considered enabled.
Capable: A user is considered capable if they are both registered and enabled. This status means that they can
perform SSPR at any time if needed.
Clicking on any of these tiles or the insights shown in them will bring you to a pre-filtered list of registration
details.
The Registrations chart on the Registration tab shows the number of successful and failed authentication
method registrations by authentication method. The Resets chart on the Usage tab shows the number of
successful and failed authentications during the password reset flow by authentication method.
Clicking on either of the charts will bring you to a pre-filtered list of registration or reset events.
Using the control in the upper, right-hand corner, you can change the date range for the audit data shown in the
Registrations and Resets charts to 24 hours, 7 days, or 30 days.
Registration data from the
Registration details
Clicking on the Users registered, Users enabled, or Users capable tiles or insights will bring you to the
registration details.
The registration details report shows the following information for each user:
Name
User name
Registration status (All, Registered, Not registered)
Enabled status (All, Enabled, Not enabled)
Capable status (All, Capable, Not capable)
Methods (App notification, App code, Phone call, SMS, Email, Security questions)
Using the controls at the top of the list, you can search for a user and filter the list of users based on the columns
shown.
Reset details
Clicking on the Registrations or Resets charts will bring you to the reset details.
The reset details report shows registration and reset events from the last 30 days including:
Name
User name
Feature (All, Registration, Reset)
Authentication method (App notification, App code, Phone call, Office call, SMS, Email, Security questions)
Status (All, Success, Failure)
Using the controls at the top of the list, you can search for a user and filter the list of users based on the columns
shown.
Limitations
The data shown in these reports will be delayed by up to 60 minutes. A “Last refreshed" field exists in the Azure
portal to identify how recent your data is.
Usage and insights data is not a replacement for the Azure Multi-Factor Authentication activity reports or
information contained in the Azure AD sign-ins report.
Next steps
Working with the authentication methods usage report API
Choosing authentication methods for your organization
Combined registration experience
Reporting options for Azure AD password
management
After deployment, many organizations want to know how or if self-service password reset (SSPR ) is really being
used. The reporting feature that Azure Active Directory (Azure AD ) provides helps you answer questions by using
prebuilt reports. If you're appropriately licensed, you can also create custom queries.
The following questions can be answered by the reports that exist in the Azure portal:
NOTE
You must be a global administrator, and you must opt-in for this data to be gathered on behalf of your organization. To
opt in, you must visit the Reporting tab or the audit logs at least once. Until then, data is not collected for your
organization.
How many people have registered for password reset?

Who has registered for password reset?
What data are people registering?
How many people reset their passwords in the last seven days?
What are the most common methods that users or admins use to reset their passwords?
What are common problems users or admins face when attempting to use password reset?
What admins are resetting their own passwords frequently?
Is there any suspicious activity going on with password reset?
Power BI content pack
If you're a Power BI user, there is a content pack for Azure AD that includes easy-to-use reporting for SSPR. For
more information on how to use and deploy the content pack, see How to use the Azure Active Directory Power
BI content pack. With the content pack, you can create your own dashboards and share them with others in your
organization.
How to view password management reports in the Azure portal

In the Azure portal experience, we have improved the way that you can view password reset and password reset
registration activity. Use the following the steps to find the password reset and password reset registration events:
1. Browse to the Azure portal.
2. Select All services in the left pane.
3. Search for Azure Active Directory in the list of services and select it.
4. Select Users from the Manage section.
5. Select Audit Logs from the Users blade. This shows you all of the audit events that occurred against all the
users in your directory. You can filter this view to see all the password-related events.
6. From the Filter menu at the top of the pane, select the Service drop-down list, and change it to the Self-
service Password Management service type.
7. Optionally, further filter the list by choosing the specific Activity you're interested in.
Converged registration (preview)
If you are participating in the public preview of converged registration, information regarding user activity in the
audit logs will be found under the service Authentication Methods.
Description of the report columns in the Azure portal

The following list explains each of the report columns in the Azure portal in detail:
User: The user who attempted a password reset registration operation.
Role: The role of the user in the directory.
Date and Time: The date and time of the attempt.
Data Registered: The authentication data that the user provided during password reset registration.
Description of the report values in the Azure portal

The following table describes the different values that are you can set for each column in the Azure portal:
COLUMN PERMITTED VALUES AND THEIR MEANINGS

COLUMN PERMITTED VALUES AND THEIR MEANINGS
Data registered Alternate email: The user used an alternate email or

authentication email to authenticate.
Office phone: The user used an office phone to
authenticate.
Mobile phone: The user used a mobile phone or
authentication phone to authenticate.
Security questions: The user used security questions to
authenticate.
Any combination of the previous methods, for
example, alternate email + mobile phone: Occurs
when a two-gate policy is specified and shows which two
methods the user used to authentication their password
reset request.
Self-Service Password Management activity types

The following activity types appear in the Self-Service Password Management audit event category:
Blocked from self-service password reset: Indicates that a user tried to reset a password, use a specific gate, or
validate a phone number more than five total times in 24 hours.
Change password (self-service): Indicates that a user performed a voluntary, or forced (due to expiry)
password change.
Reset password (by admin): Indicates that an administrator performed a password reset on behalf of a user
from the Azure portal.
Reset password (self-service): Indicates that a user successfully reset their password from the Azure AD
password reset portal.
Self-service password reset flow activity progress: Indicates each specific step a user proceeds through, such
as passing a specific password reset authentication gate, as part of the password reset process.
Unlock user account (self-service)): Indicates that a user successfully unlocked their Active Directory account
without resetting their password from the Azure AD password reset portal by using the Active Directory
feature of account unlock without reset.
User registered for self-service password reset: Indicates that a user has registered all the required
information to be able to reset their password in accordance with the currently specified tenant password reset
policy.
Activity type: Blocked from self-service password reset
The following list explains this activity in detail:
Activity description: Indicates that a user tried to reset a password, use a specific gate, or validate a phone
number more than five total times in 24 hours.
Activity actor: The user who was throttled from performing additional reset operations. The user can be an
end user or an administrator.
Activity target: The user who was throttled from performing additional reset operations. The user can be an
Activity status:
Success: Indicates that a user was throttled from performing any additional resets, attempting any
additional authentication methods, or validating any additional phone numbers for the next 24 hours.
Activity status failure reason: Not applicable.
Activity type: Change password (self-service )
Activity description: Indicates that a user performed a voluntary, or forced (due to expiry) password change.
Activity actor: The user who changed their password. The user can be an end user or an administrator.
Activity target: The user who changed their password. The user can be an end user or an administrator.
Activity statuses:
Success: Indicates that a user successfully changed their password.
Failure: Indicates that a user failed to change their password. You can select the row to see the Activity
status reason category to learn more about why the failure occurred.
Activity status failure reason:
FuzzyPolicyViolationInvalidPassword: The user selected a password that was automatically banned
because the Microsoft Banned Password Detection capabilities found it to be too common or especially
weak.
Activity type: Reset password (by admin)
Activity description: Indicates that an administrator performed a password reset on behalf of a user from
the Azure portal.
Activity actor: The administrator who performed the password reset on behalf of another end user or
administrator. Must be a password administrator, user administrator, or helpdesk administrator.
Activity target: The user whose password was reset. The user can be an end user or a different administrator.
Activity statuses:
Success: Indicates that an admin successfully reset a user's password.
Failure: Indicates that an admin failed to change a user's password. You can select the row to see the
Activity status reason category to learn more about why the failure occurred.
Activity type: Reset password (self-service )
Activity description: Indicates that a user successfully reset their password from the Azure AD password
reset portal.
Activity actor: The user who reset their password. The user can be an end user or an administrator.
Activity target: The user who reset their password. The user can be an end user or an administrator.
Activity statuses:
Success: Indicates that a user successfully reset their own password.
Failure: Indicates that a user failed to reset their own password. You can select the row to see the
Activity status failure reason:
FuzzyPolicyViolationInvalidPassword: The admin selected a password that was automatically banned
because the Microsoft Banned Password Detection capabilities found it to be too common or especially
weak.
Activity type: Self serve password reset flow activity progress
Activity description: Indicates each specific step a user proceeds through (such as passing a specific
password reset authentication gate) as part of the password reset process.
Activity actor: The user who performed part of the password reset flow. The user can be an end user or an
administrator.
Activity target: The user who performed part of the password reset flow. The user can be an end user or an
administrator.
Activity statuses:
Success: Indicates that a user successfully completed a specific step of the password reset flow.
Failure: Indicates that a specific step of the password reset flow failed. You can select the row to see the
Activity status reasons: See the following table for all the permissible reset activity status reasons.
Activity type: Unlock a user account (self-service )
Activity description: Indicates that a user successfully unlocked their Active Directory account without
resetting their password from the Azure AD password reset portal by using the Active Directory feature of
account unlock without reset.
Activity actor: The user who unlocked their account without resetting their password. The user can be an end
user or an administrator.
Activity target: The user who unlocked their account without resetting their password. The user can be an
Allowed activity statuses:
Success: Indicates that a user successfully unlocked their own account.
Failure: Indicates that a user failed to unlock their account. You can select the row to see the Activity
status reason category to learn more about why the failure occurred.
Activity type: User registered for self-service password reset
Activity description: Indicates that a user has registered all the required information to be able to reset their
password in accordance with the currently specified tenant password reset policy.
Activity actor: The user who registered for password reset. The user can be an end user or an administrator.
Activity target: The user who registered for password reset. The user can be an end user or an administrator.
Allowed activity statuses:
Success: Indicates that a user successfully registered for password reset in accordance with the
current policy.
Failure: Indicates that a user failed to register for password reset. You can select the row to see the
NOTE
Failure doesn't mean a user is unable to reset their own password. It means that they didn't finish the
registration process. If there is unverified data on their account that's correct, such as a phone number that's
not validated, even though they have not verified this phone number, they can still use it to reset their
password.
Next steps
Reset or change your password.
Register for self-service password reset.
Reports in Azure Multi-Factor Authentication
Azure Multi-Factor Authentication provides several reports that can be used by you and your organization
accessible through the Azure portal. The following table lists the available reports:
REPORT LOCATION DESCRIPTION
Blocked User History Azure AD > MFA Server > Shows the history of requests to block
Block/unblock users or unblock users.
Usage and fraud alerts Azure AD > Sign-ins Provides information on overall usage,
user summary, and user details; as well
as a history of fraud alerts submitted
during the date range specified.
Usage for on-premises components Azure AD > MFA Server > Activity Provides information on overall usage
Report for MFA through the NPS extension,
ADFS, and MFA server.
Bypassed User History Azure AD > MFA Server > One-time Provides a history of requests to bypass
bypass Multi-Factor Authentication for a user.
Server status Azure AD > MFA Server > Server status Displays the status of Multi-Factor
Authentication Servers associated with
your account.
View MFA reports

2. On the left, select Azure Active Directory > MFA Server.
3. Select the report that you wish to view.
Azure AD sign-ins report
With the sign-ins activity report in the Azure portal, you can get the information you need to determine how
your environment is doing.
The sign-ins report can provide you with information about the usage of managed applications and user sign-in
activities, which includes information about multi-factor authentication (MFA) usage. The MFA data gives you
insights into how MFA is working in your organization. It enables you to answer questions like:
Was the sign-in challenged with MFA?
How did the user complete MFA?
Why was the user unable to complete MFA?
How many users are challenged for MFA?
How many users are unable to complete the MFA challenge?
What are the common MFA issues end users are running into?
This data is available through the Azure portal and the reporting API.
Sign-ins report structure
The sign-in activity reports for MFA give you access to the following information:
MFA required: Whether MFA is required for the sign-in or not. MFA can be required due to per-user MFA,
Conditional Access, or other reasons. Possible values are Yes or No.
MFA Result: More information on whether MFA was satisfied or denied:
If MFA was satisfied, this column provides more information about how MFA was satisfied.
completed in the cloud
has expired due to the policies configured on tenant
registration prompted
satisfied by claim in the token
satisfied by claim provided by external provider
satisfied by strong authentication
skipped as flow exercised was Windows broker logon flow
skipped due to app password
skipped due to location
skipped due to registered device
skipped due to remembered device
successfully completed
Redirected to external provider for multi-factor authentication
If MFA was denied, this column would provide the reason for denial.
Azure Multi-Factor Authentication denied;
authentication in-progress
duplicate authentication attempt
entered incorrect code too many times
invalid authentication
invalid mobile app verification code
misconfiguration
phone call went to voicemail
phone number has an invalid format
service error
unable to reach the user’s phone
unable to send the mobile app notification to the device
unable to send the mobile app notification
user declined the authentication
user did not respond to mobile app notification
user does not have any verification methods registered
user entered incorrect code
user entered incorrect PIN
user hung up the phone call without succeeding the authentication
user is blocked
user never entered the verification code
user not found
verification code already used once
MFA authentication method: The authentication method the user used to complete MFA. Possible values
include:
Text message
Mobile app notification
Phone call (Authentication phone)
Mobile app verification code
Phone call (Office phone)
Phone call (Alternate authentication phone)
MFA authentication detail: Scrubbed version of the phone number, for example: +X XXXXXXXX64.
Conditional Access Find information about Conditional Access policies that affected the sign-in attempt
including:
Policy name
Grant controls
Session controls
Result
PowerShell reporting on users registered for MFA

First, ensure that you have the MSOnline V1 PowerShell module installed.
Identify users who have registered for MFA using the PowerShell that follows.
Get-MsolUser -All | where {$_.StrongAuthenticationMethods -ne $null} | Select-Object -Property
UserPrincipalName
Identify users who have not registered for MFA using the PowerShell that follows.
Get-MsolUser -All | where {$_.StrongAuthenticationMethods.Count -eq 0} | Select-Object -Property
UserPrincipalName
Possible results in activity reports

The following table may be used to troubleshoot multi-factor authentication using the downloaded version of the
multi-factor authentication activity report. They will not appear directly in the Azure portal.
CALL RESULT DESCRIPTION BROAD DESCRIPTION
SUCCESS_WITH_PIN PIN Entered The user entered a PIN. If

authentication succeeded then they
entered the correct PIN. If
authentication is denied, then they
entered an incorrect PIN or the user is
set to Standard mode.
SUCCESS_NO_PIN Only # Entered If the user is set to PIN mode and the
authentication is denied, this means the
user did not enter their PIN and only
entered #. If the user is set to Standard
mode and the authentication succeeds
this means the user only entered #
which is the correct thing to do in
Standard mode.
SUCCESS_WITH_PIN_BUT_TIMEOUT # Not Pressed After Entry The user did not send any DTMF digits
since # was not entered. Other digits
entered are not sent unless # is entered
indicating the completion of the entry.
SUCCESS_NO_PIN_BUT_TIMEOUT No Phone Input - Timed Out The call was answered, but there was no
response. This typically indicates the
call was picked up by voicemail.
SUCCESS_PIN_EXPIRED PIN Expired and Not Changed The user's PIN is expired and they were
prompted to change it, but the PIN
change was not successfully completed.
SUCCESS_USED_CACHE Used Cache Authentication succeeded without a

Multi-Factor Authentication call since a
previous successful authentication for
the same username occurred within the
configured cache timeframe.
SUCCESS_BYPASSED_AUTH Bypassed Auth Authentication succeeded using a One-

Time Bypass initiated for the user. See
the Bypassed User History Report for
more details on the bypass.
SUCCESS_USED_IP_BASED_CACHE Used IP-based Cache Authentication succeeded without a

the same username, authentication
type, application name, and IP occurred
within the configured cache timeframe.
SUCCESS_USED_APP_BASED_CACHE Used App-based Cache Authentication succeeded without a

the same username, authentication
type, and application name within the
configured cache timeframe.
SUCCESS_INVALID_INPUT Invalid Phone Input The response sent from the phone is
not valid. This could be from a fax
machine or modem or the user may
have entered * as part of their PIN.
SUCCESS_USER_BLOCKED User is Blocked The user's phone number is blocked. A

blocked number can be initiated by the
user during an authentication call or by
an administrator using the Azure portal.
NOTE: A blocked number is also a
byproduct of a Fraud Alert.
SUCCESS_SMS_AUTHENTICATED Text Message Authenticated For two-way test message, the user
correctly replied with their one-time
passcode (OTP) or OTP + PIN.
SUCCESS_SMS_SENT Text Message Sent For Text Message, the text message
containing the one-time passcode
(OTP) was successfully sent. The user
will enter the OTP or OTP + PIN in the
application to complete the
authentication.
SUCCESS_PHONE_APP_AUTHENTICATE Mobile App Authenticated The user successfully authenticated via

D the mobile app.
SUCCESS_OATH_CODE_PENDING OATH Code Pending The user was prompted for their OATH
code but didn't respond.
SUCCESS_OATH_CODE_VERIFIED OATH Code Verified The user entered a valid OATH code
when prompted.
SUCCESS_FALLBACK_OATH_CODE_VERI Fallback OATH Code Verified The user was denied authentication
FIED using their primary Multi-Factor
Authentication method and then
provided a valid OATH code for fallback.
SUCCESS_FALLBACK_SECURITY_QUESTI Fallback Security Questions Answered The user was denied authentication
ONS_ANSWERED using their primary Multi-Factor
Authentication method and then
answered their security questions
correctly for fallback.
FAILED_PHONE_BUSY Auth Already In Progress Multi-Factor Authentication is already

processing an authentication for this
user. This is often caused by RADIUS
clients that send multiple authentication
requests during the same sign-on.
CONFIG_ISSUE Phone Unreachable Call was attempted, but either could

not be placed or was not answered.
This includes busy signal, fast busy
signal (disconnected), tri-tones (number
no longer in service), timed out while
ringing, etc.
FAILED_INVALID_PHONENUMBER Invalid Phone Number Format The phone number has an invalid
format. Phone numbers must be
numeric and must be 10 digits for
country code +1 (United States &
Canada).
FAILED_USER_HUNGUP_ON_US User Hung Up the Phone The user answered the phone, but then
hung up without pressing any buttons.
FAILED_INVALID_EXTENSION Invalid Extension The extension contains invalid

characters. Only digits, commas, *, and
# are allowed. An @ prefix may also be
used.
FAILED_FRAUD_CODE_ENTERED Fraud Code Entered The user elected to report fraud during
the call resulting in a denied
authentication and a blocked phone
number.
FAILED_SERVER_ERROR Unable to Place Call The Multi-Factor Authentication service

was unable to place the call.
FAILED_SMS_NOT_SENT Text Message Could Not Be Sent The text message could not be sent.
The authentication is denied.
FAILED_SMS_OTP_INCORRECT Text Message OTP Incorrect The user entered an incorrect one-time
passcode (OTP) from the text message
they received. The authentication is
denied.
FAILED_SMS_OTP_PIN_INCORRECT Text Message OTP + PIN Incorrect The user entered an incorrect one-time
passcode (OTP) and/or an incorrect user
PIN. The authentication is denied.
FAILED_SMS_MAX_OTP_RETRY_REACHE Exceeded Maximum Text Message OTP The user has exceeded the maximum
D Attempts number of one-time passcode (OTP)
attempts.
FAILED_PHONE_APP_DENIED Mobile App Denied The user denied the authentication in

the mobile app by pressing the Deny
button.
FAILED_PHONE_APP_INVALID_PIN Mobile App Invalid PIN The user entered an invalid PIN when
authenticating in the mobile app.
FAILED_PHONE_APP_PIN_NOT_CHANG Mobile App PIN Not Changed The user did not successfully complete a
ED required PIN change in the mobile app.
FAILED_FRAUD_REPORTED Fraud Reported The user reported fraud in the mobile

app.
FAILED_PHONE_APP_NO_RESPONSE Mobile App No Response The user did not respond to the mobile
app authentication request.
FAILED_PHONE_APP_ALL_DEVICES_BL Mobile App All Devices Blocked The mobile app devices for this user are
OCKED no longer responding to notifications
and have been blocked.
FAILED_PHONE_APP_NOTIFICATION_F Mobile App Notification Failed A failure occurred when attempting to

AILED send a notification to the mobile app on
the user's device.
FAILED_PHONE_APP_INVALID_RESULT Mobile App Invalid Result The mobile app returned an invalid
result.
FAILED_OATH_CODE_INCORRECT OATH Code Incorrect The user entered an incorrect OATH

code. The authentication is denied.
FAILED_OATH_CODE_PIN_INCORRECT OATH Code + PIN Incorrect The user entered an incorrect OATH
code and/or an incorrect user PIN. The
authentication is denied.
FAILED_OATH_CODE_DUPLICATE Duplicate OATH Code The user entered an OATH code that
was previously used. The authentication
is denied.
FAILED_OATH_CODE_OLD OATH Code Out of Date The user entered an OATH code that
precedes an OATH code that was
previously used. The authentication is
denied.
FAILED_OATH_TOKEN_TIMEOUT OATH Code Result Timeout The user took too long to enter the
OATH code and the Multi-Factor
Authentication attempt had already
timed out.
FAILED_SECURITY_QUESTIONS_TIMEO Security Questions Result Timeout The user took too long to enter answer
UT to security questions and the Multi-
Factor Authentication attempt had
already timed out.
FAILED_AUTH_RESULT_TIMEOUT Auth Result Timeout The user took too long to complete the
Multi-Factor Authentication attempt.
FAILED_AUTHENTICATION_THROTTLED Authentication Throttled The Multi-Factor Authentication

attempt was throttled by the service.
Next steps
For Users
Where to deploy
Azure Multi-Factor Authentication user data
collection
This document explains how to find user information collected by Azure Multi-Factor Authentication Server (MFA
Server) and Azure MFA (Cloud-based) in the event you would like to remove it.
NOTE
If you’re interested in viewing or deleting personal data, please review Microsoft's guidance in the Windows Data Subject
Requests for the GDPR site. If you’re looking for general information about GDPR, see the GDPR section of the Service Trust
portal.
Information collected
MFA Server, the NPS Extension, and the Windows Server 2016 Azure MFA AD FS Adapter collect and store the
following information for 90 days.
Authentication Attempts (used for reporting and troubleshooting):
Timestamp
Username
First Name
Last Name
Email Address
User Group
Authentication Method (Phone Call, Text Message, Mobile App, OATH Token)
Phone Call Mode (Standard, PIN )
Text Message Direction (One-Way, Two-Way)
Text Message Mode (OTP, OTP + PIN )
Mobile App Mode (Standard, PIN )
OATH Token Mode (Standard, PIN )
Authentication Type
Application Name
Primary Call Country Code
Primary Call Phone Number
Primary Call Extension
Primary Call Authenticated
Primary Call Result
Backup Call Country Code
Backup Call Phone Number
Backup Call Extension
Backup Call Authenticated
Backup Call Result
Overall Authenticated
Overall Result
Results
Authenticated
Result
Initiating IP Address
Devices
Device Token
Device Type
Mobile App Version
OS Version
Result
Used Check for Notification
Activations (attempts to activate an account in the Microsoft Authenticator mobile app):
Username
Account Name
Timestamp
Get Activation Code Result
Activate Success
Activate Error
Activation Status Result
Device Name
Device Type
App Version
OATH Token Enabled
Blocks (used to determine blocked state and for reporting):
Block Timestamp
Block By Username
Username
Country Code
Phone Number
Phone Number Formatted
Extension
Clean Extension
Blocked
Block Reason
Completion Timestamp
Completion Reason
Account Lockout
Fraud Alert
Fraud Alert Not Blocked
Language
Bypasses (used for reporting):
Bypass Timestamp
Bypass Seconds
Bypass By Username
Username
Country Code
Phone Number
Phone Number Formatted
Extension
Clean Extension
Bypass Reason
Completion Timestamp
Completion Reason
Bypass Used
Changes (used to sync user changes to MFA Server or AAD ):
Change Timestamp
Username
New Country Code
New Phone Number
New Extension
New Backup Country Code
New Backup Phone Number
New Backup Extension
New PIN
PIN Change Required
Old Device Token
New Device Token
Gather data from MFA Server

For MFA Server version 8.0 or higher the following process allows administrators to export all data for users:
Log in to your MFA Server, navigate to the Users tab, select the user in question, and click the Edit button. Take
screenshots (Alt-PrtScn) of each tab to provide the user their current MFA settings.
From the command line of the MFA Server, run the following command changing the path according to your
installation C:\Program Files\Multi-Factor Authentication Server\MultiFactorAuthGdpr.exe export <username> to
produce a JSON formatted file.
Administrators can also use the Web Service SDK GetUserGdpr operation as an option to export all MFA cloud
service information collected for a given user or incorporate into a larger reporting solution.
Search C:\Program Files\Multi-Factor Authentication Server\Logs\MultiFactorAuthSvc.log and any backups for
“<username>” (include the quotes in the search) to find all instances of the user record being added or changed.
These records can be limited (but not eliminated) by unchecking “Log user changes” in the MFA Server
UX, Logging section, Log Files tab.
If syslog is configured, and “Log user changes” is checked in the MFA Server UX, Logging section,
Syslog tab, then the log entries can be gathered from syslog instead.
Other occurrences of the username in MultiFactorAuthSvc.log and other MFA Server log files pertaining to
authentication attempts are considered operational and duplicative to the information provided using
MultiFactorAuthGdpr.exe export or Web Service SDK GetUserGdpr.
Delete data from MFA Server

From the command line of the MFA Server, run the following command changing the path according to your
installation C:\Program Files\Multi-Factor Authentication Server\MultiFactorAuthGdpr.exe delete <username> to
delete all MFA cloud service information collected for this user.
Data included in the export is deleted in real time, but it may take up to 30 days for operational or duplicative
data to be fully removed.
Administrators can also use the Web Service SDK DeleteUserGdpr operation as an option to delete all MFA
cloud service information collected for a given user or incorporate into a larger reporting solution.
Gather data from NPS Extension

Use the Microsoft Privacy Portal to make a request for Export.
MFA information is included in the export, which may take hours or days to complete.
Occurrences of the username in the AzureMfa/AuthN/AuthNOptCh, AzureMfa/AuthZ/AuthZAdminCh, and
AzureMfa/AuthZ/AuthZOptCh event logs are considered operational and duplicative to the information
provided in the export.
Delete data from NPS Extension

Use the Microsoft Privacy Portal to make a request for Account Close to delete all MFA cloud service information
collected for this user.
It may take up to 30 days for data to be fully removed.
Gather data from Windows Server 2016 Azure MFA AD FS Adapter

Occurrences of the username in the AD FS Tracing/Debug event logs (if enabled) are considered operational
and duplicative to the information provided in the export.
Delete data from Windows Server 2016 Azure MFA AD FS Adapter

Gather data for Azure MFA

Delete Data for Azure MFA

Next steps
MFA Server reporting
Getting started with the Azure Multi-Factor
Authentication Server
This page covers a new installation of the server and setting it up with on-premises Active Directory. If you already
have the MFA server installed and are looking to upgrade, see Upgrade to the latest Azure Multi-Factor
Authentication Server. If you're looking for information on installing just the web service, see Deploying the Azure
Multi-Factor Authentication Server Mobile App Web Service.
IMPORTANT
As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who would like to require
multi-factor authentication from their users should use cloud-based Azure Multi-Factor Authentication. Existing customers
who have activated MFA Server prior to July 1 will be able to download the latest version, future updates and generate
activation credentials as usual.
Plan your deployment

WARNING
Starting in March of 2019 MFA Server downloads will only be available to paid tenants. Free/trial tenants will no longer be
able to download or generate and use activation credentials.
Before you download the Azure Multi-Factor Authentication Server, think about what your load and high
availability requirements are. Use this information to decide how and where to deploy.
A good guideline for the amount of memory you need is the number of users you expect to authenticate on a
regular basis.
USERS RAM
1-10,000 4 GB
10,001-50,000 8 GB
50,001-100,000 12 GB
100,000-200,001 16 GB
200,001+ 32 GB
Do you need to set up multiple servers for high availability or load balancing? There are a number of ways to set
up this configuration with Azure MFA Server. When you install your first Azure MFA Server, it becomes the
master. Any additional servers become subordinate, and automatically synchronize users and configuration with
the master. Then, you can configure one primary server and have the rest act as backup, or you can set up load
balancing among all the servers.
When a master Azure MFA Server goes offline, the subordinate servers can still process two-step verification
requests. However, you can't add new users and existing users can't update their settings until the master is back
online or a subordinate gets promoted.
Prepare your environment
Make sure the server that you're using for Azure Multi-Factor Authentication meets the following requirements:
AZURE MULTI-FACTOR AUTHENTICATION SERVER REQUIREMENTS DESCRIPTION
Hardware 200 MB of hard disk space

x32 or x64 capable processor
1 GB or greater RAM
Software Windows Server 2016

Windows Server 2012 R2
Windows Server 2012
Windows Server 2008, SP1, SP2
Windows Server 2003, SP1, SP2
Windows 10
Windows 8.1, all editions
Windows 8, all editions
Windows 7, all editions
Windows Vista, all editions, SP1, SP2
Microsoft .NET 4.0 Framework
IIS 7.0 or greater if installing the user portal or web service
SDK
Permissions Domain Administrator or Enterprise Administrator account to

register with Active Directory
Azure MFA Server Components

There are three web components that make up Azure MFA Server:
Web Service SDK - Enables communication with the other components and is installed on the Azure MFA
application server
User Portal - An IIS web site that allows users to enroll in Azure Multi-Factor Authentication (MFA) and
maintain their accounts.
Mobile App Web Service - Enables using a mobile app like the Microsoft Authenticator app for two-step
verification.
All three components can be installed on the same server if the server is internet-facing. If breaking up the
components, the Web Service SDK is installed on the Azure MFA application server and the User Portal and
Mobile App Web Service are installed on an internet-facing server.
Azure Multi-Factor Authentication Server firewall requirements
Each MFA server must be able to communicate on port 443 outbound to the following addresses:
https://pfd.phonefactor.net
https://pfd2.phonefactor.net
https://css.phonefactor.net
If outbound firewalls are restricted on port 443, open the following IP address ranges:
IP SUBNET NETMASK IP RANGE
134.170.116.0/25 255.255.255.128 134.170.116.1 – 134.170.116.126
134.170.165.0/25 255.255.255.128 134.170.165.1 – 134.170.165.126
70.37.154.128/25 255.255.255.128 70.37.154.129 – 70.37.154.254
If you aren't using the Event Confirmation feature, and your users aren't using mobile apps to verify from devices
on the corporate network, you only need the following ranges:
IP SUBNET NETMASK IP RANGE
134.170.116.72/29 255.255.255.248 134.170.116.72 – 134.170.116.79
134.170.165.72/29 255.255.255.248 134.170.165.72 – 134.170.165.79
70.37.154.200/29 255.255.255.248 70.37.154.201 – 70.37.154.206
Download the MFA Server

WARNING
Starting in March of 2019 MFA Server downloads will only be available to paid tenants. Free/trial tenants will no longer be
able to download or generate and use activation credentials.
Follow these steps to download the Azure Multi-Factor Authentication Server from the Azure portal:
2. Select Azure Active Directory > MFA Server.
3. Select Server settings.
4. Select Download and follow the instructions on the download page to save the installer.
5. Keep this page open as we will refer to it after running the installer.
Install and configure the MFA Server

Now that you have downloaded the server you can install and configure it. Be sure that the server you are
installing it on meets requirements listed in the planning section.
1. Double-click the executable.
2. On the Select Installation Folder screen, make sure that the folder is correct and click Next.
3. Once the installation is complete, click Finish. The configuration wizard launches.
4. On the configuration wizard welcome screen, check Skip using the Authentication Configuration
Wizard and click Next. The wizard closes and the server starts.
5. Back on the page that you downloaded the server from, click the Generate Activation Credentials
button. Copy this information into the Azure MFA Server in the boxes provided and click Activate.
Send users an email

To ease rollout, allow MFA Server to communicate with your users. MFA Server can send an email to inform them
that they have been enrolled for two-step verification.
The email you send should be determined by how you configure your users for two-step verification. For example,
if you are able to import phone numbers from the company directory, the email should include the default phone
numbers so that users know what to expect. If you do not import phone numbers, or your users are going to use
the mobile app, send them an email that directs them to complete their account enrollment. Include a hyperlink to
the Azure Multi-Factor Authentication User Portal in the email.
The content of the email also varies depending on the method of verification that has been set for the user (phone
call, SMS, or mobile app). For example, if the user is required to use a PIN when they authenticate, the email tells
them what their initial PIN has been set to. Users are required to change their PIN during their first verification.
Configure email and email templates
Click the email icon on the left to set up the settings for sending these emails. This page is where you can enter the
SMTP information of your mail server and send email by checking the Send emails to users check box.
On the Email Content tab, you can see the email templates that are available to choose from. Depending on how
you have configured your users to perform two-step verification, choose the template that best suits you.
Import users from Active Directory

Now that the server is installed you want to add users. You can choose to create them manually, import users from
Active Directory, or configure automated synchronization with Active Directory.
Manual import from Active Directory
1. In the Azure MFA Server, on the left, select Users.
2. At the bottom, select Import from Active Directory.
3. Now you can either search for individual users or search the AD directory for OUs with users in them. In
this case, we specify the users OU.
4. Highlight all the users on the right and click Import. You should receive a pop-up telling you that you were
successful. Close the import window.
Automated synchronization with Active Directory

1. In the Azure MFA Server, on the left, select Directory Integration.
2. Navigate to the Synchronization tab.
3. At the bottom, choose Add
4. In the Add Synchronization Item box that appears choose the Domain, OU or security group, Settings,
Method Defaults, and Language Defaults for this synchronization task and click Add.
5. Check the box labeled Enable synchronization with Active Directory and choose a Synchronization
interval between one minute and 24 hours.
How the Azure Multi-Factor Authentication Server handles user data

When you use the Multi-Factor Authentication (MFA) Server on-premises, a user’s data is stored in the on-
premises servers. No persistent user data is stored in the cloud. When the user performs a two-step verification,
the MFA Server sends data to the Azure MFA cloud service to perform the verification. When these authentication
requests are sent to the cloud service, the following fields are sent in the request and logs so that they are
available in the customer's authentication/usage reports. Some of the fields are optional so they can be enabled or
disabled within the Multi-Factor Authentication Server. The communication from the MFA Server to the MFA
cloud service uses SSL/TLS over port 443 outbound. These fields are:
Unique ID - either username or internal MFA server ID
First and last name (optional)
Email address (optional)
Phone number - when doing a voice call or SMS authentication
Device token - when doing mobile app authentication
Authentication mode
Authentication result
MFA Server name
MFA Server IP
Client IP – if available
In addition to the fields above, the verification result (success/denial) and reason for any denials is also stored with
the authentication data and available through the authentication/usage reports.
IMPORTANT
Starting in March of 2019 the phone call options will not be available to MFA Server users in free/trial Azure AD tenants.
Back up and restore Azure MFA Server

Making sure that you have a good backup is an important step to take with any system.
To back up Azure MFA Server, ensure that you have a copy of the C:\Program Files\Multi-Factor
Authentication Server\Data folder including the PhoneFactor.pfdata file.
In case a restore is needed complete the following steps:
1. Reinstall Azure MFA Server on a new server.
2. Activate the new Azure MFA Server.
3. Stop the MultiFactorAuth service.
4. Overwrite the PhoneFactor.pfdata with the backed-up copy.
5. Start the MultiFactorAuth service.
The new server is now up and running with the original backed-up configuration and user data.
Managing the TLS/SSL Protocols and Cipher Suites

Once you have upgraded to or installed MFA Server version 8.x or higher, it is recommended that older and
weaker cipher suites be disabled or removed unless required by your organization. Information on how to
complete this task can be found in the article Managing SSL/TLS Protocols and Cipher Suites for AD FS
Next steps
Set up and configure the User Portal for user self-service.
Set up and configure the Azure MFA Server with Active Directory Federation Service, RADIUS Authentication,
or LDAP Authentication.
Set up and configure Remote Desktop Gateway and Azure Multi-Factor Authentication Server using RADIUS.
Deploy the Azure Multi-Factor Authentication Server Mobile App Web Service.
Advanced scenarios with Azure Multi-Factor Authentication and third-party VPNs.
User portal for the Azure Multi-Factor Authentication
Server
The user portal is an IIS web site that allows users to enroll in Azure Multi-Factor Authentication (MFA) and
maintain their accounts. A user may change their phone number, change their PIN, or choose to bypass two-step
verification during their next sign-on.
Users sign in to the user portal with their normal username and password, then either complete a two-step
verification call or answer security questions to complete their authentication. If user enrollment is allowed, users
configure their phone number and PIN the first time they sign in to the user portal.
User portal Administrators may be set up and granted permission to add new users and update existing users.
Depending on your environment, you may want to deploy the user portal on the same server as Azure Multi-
Factor Authentication Server or on another internet-facing server.
IMPORTANT
NOTE
The user portal is only available with Multi-Factor Authentication Server. If you use Multi-Factor Authentication in the cloud,
refer your users to the Set-up your account for two-step verification or Manage your settings for two-step verification.
Install the web service SDK

In either scenario, if the Azure Multi-Factor Authentication Web Service SDK is not already installed on the Azure
Multi-Factor Authentication (MFA) Server, complete the steps that follow.
1. Open the Multi-Factor Authentication Server console.
2. Go to the Web Service SDK and select Install Web Service SDK.
3. Complete the install using the defaults unless you need to change them for some reason.
4. Bind an SSL Certificate to the site in IIS.
If you have questions about configuring an SSL Certificate on an IIS server, see the article How to Set Up SSL on
IIS.
The Web Service SDK must be secured with an SSL certificate. A self-signed certificate is okay for this purpose.
Import the certificate into the “Trusted Root Certification Authorities” store of the Local Computer account on the
User Portal web server so that it trusts that certificate when initiating the SSL connection.
Deploy the user portal on the same server as the Azure Multi-Factor
The following pre-requisites are required to install the user portal on the same server as the Azure Multi-Factor
Authentication Server:
IIS, including ASP.NET, and IIS 6 meta base compatibility (for IIS 7 or higher)
An account with admin rights for the computer and Domain if applicable. The account needs permissions to
create Active Directory security groups.
Secure the user portal with an SSL certificate.
Secure the Azure Multi-Factor Authentication Web Service SDK with an SSL certificate.
To deploy the user portal, follow these steps:
1. Open the Azure Multi-Factor Authentication Server console, click the User Portal icon in the left menu,
then click Install User Portal.
2. Complete the install using the defaults unless you need to change them for some reason.
3. Bind an SSL Certificate to the site in IIS
NOTE
This SSL Certificate is usually a publicly signed SSL Certificate.
4. Open a web browser from any computer and navigate to the URL where the user portal was installed
(Example: https://mfa.contoso.com/MultiFactorAuth). Ensure that no certificate warnings or errors are
displayed.
IIS.
Deploy the user portal on a separate server

If the server where Azure Multi-Factor Authentication Server is running is not internet-facing, you should install
the user portal on a separate, internet-facing server.
If your organization uses the Microsoft Authenticator app as one of the verification methods, and want to deploy
the user portal on its own server, complete the following requirements:
Use v6.0 or higher of the Azure Multi-Factor Authentication Server.
Install the user portal on an internet-facing web server running Microsoft internet Information Services (IIS )
6.x or higher.
When using IIS 6.x, ensure ASP.NET v2.0.50727 is installed, registered, and set to Allowed.
When using IIS 7.x or higher, IIS, including Basic Authentication, ASP.NET, and IIS 6 meta base compatibility.
Secure the user portal with an SSL certificate.
Secure the Azure Multi-Factor Authentication Web Service SDK with an SSL certificate.
Ensure that the user portal can connect to the Azure Multi-Factor Authentication Web Service SDK over SSL.
Ensure that the user portal can authenticate to the Azure Multi-Factor Authentication Web Service SDK using
the credentials of a service account in the "PhoneFactor Admins" security group. This service account and
group should exist in Active Directory if the Azure Multi-Factor Authentication Server is running on a domain-
joined server. This service account and group exist locally on the Azure Multi-Factor Authentication Server if it
is not joined to a domain.
Installing the user portal on a server other than the Azure Multi-Factor Authentication Server requires the
following steps:
1. On the MFA Server, browse to the installation path (Example: C:\Program Files\Multi-Factor
Authentication Server), and copy the file MultiFactorAuthenticationUserPortalSetup64 to a location
accessible to the internet-facing server where you will install it.
2. On the internet-facing web server, run the MultiFactorAuthenticationUserPortalSetup64 install file as an
administrator, change the Site if desired and change the Virtual directory to a short name if you would like.
3. Bind an SSL Certificate to the site in IIS.
NOTE
This SSL Certificate is usually a publicly signed SSL Certificate.
4. Browse to C:\inetpub\wwwroot\MultiFactorAuth
5. Edit the Web.Config file in Notepad
Find the key "USE_WEB_SERVICE_SDK" and change value="false" to value="true"
Find the key "WEB_SERVICE_SDK_AUTHENTICATION_USERNAME" and change value="" to
value="DOMAIN\User" where DOMAIN\User is a Service Account that is a part of "PhoneFactor
Admins" Group.
Find the key "WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD" and change value="" to
value="Password" where Password is the password for the Service Account entered in the previous
line.
Find the value https://www.contoso.com/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx and
change this placeholder URL to the Web Service SDK URL we installed in step 2.
Save the Web.Config file and close Notepad.
6. Open a web browser from any computer and navigate to the URL where the user portal was installed
(Example: https://mfa.contoso.com/MultiFactorAuth). Ensure that no certificate warnings or errors are
displayed.
IIS.
Configure user portal settings in the Azure Multi-Factor Authentication

Server
Now that the user portal is installed, you need to configure the Azure Multi-Factor Authentication Server to work
with the portal.
1. In the Azure Multi-Factor Authentication Server console, click the User Portal icon. On the Settings tab, enter
the URL to the user portal in the User Portal URL textbox. If email functionality has been enabled, this URL is
included in the emails that are sent to users when they are imported into the Azure Multi-Factor Authentication
Server.
2. Choose the settings that you want to use in the User Portal. For example, if users are allowed to choose their
authentication methods, ensure that Allow users to select method is checked, along with the methods they
can choose from.
3. Define who should be Administrators on the Administrators tab. You can create granular administrative
permissions using the checkboxes and dropdowns in the Add/Edit boxes.
Optional configuration:
Security Questions - Define approved security questions for your environment and the language they appear
in.
Passed Sessions - Configure user portal integration with a form-based website using MFA.
Trusted IPs - Allow users to skip MFA when authenticating from a list of trusted IPs or ranges.
Azure Multi-Factor Authentication server provides several options for the user portal. The following table provides
a list of these options and an explanation of what they are used for.
USER PORTAL SETTINGS DESCRIPTION
User Portal URL Enter the URL of where the portal is being hosted.
Primary authentication Specify the type of authentication to use when signing in to

the portal. Either Windows, Radius, or LDAP authentication.
Allow users to log in Allow users to enter a username and password on the sign-in
page for the User portal. If this option is not selected, the
boxes are grayed out.
USER PORTAL SETTINGS DESCRIPTION
Allow user enrollment Allow a user to enroll in Multi-Factor Authentication by taking

them to a setup screen that prompts them for additional
information such as telephone number. Prompt for backup
phone allows users to specify a secondary phone number.
Prompt for third-party OATH token allows users to specify a
third-party OATH token.
Allow users to initiate One-Time Bypass Allow users to initiate a one-time bypass. If a user sets this
option up, it will take effect the next time the user signs in.
Prompt for bypass seconds provides the user with a box so
they can change the default of 300 seconds. Otherwise, the
one-time bypass is only good for 300 seconds.
Allow users to select method Allow users to specify their primary contact method. This
method can be phone call, text message, mobile app, or OATH
token.
Allow users to select language Allow users to change the language that is used for the phone
call, text message, mobile app, or OATH token.
Allow users to activate mobile app Allow users to generate an activation code to complete the
mobile app activation process that is used with the server. You
can also set the number of devices they can activate the app
on, between 1 and 10.
Use security questions for fallback Allow security questions in case two-step verification fails. You
can specify the number of security questions that must be
successfully answered.
Allow users to associate third-party OATH token Allow users to specify a third-party OATH token.
Use OATH token for fallback Allow for the use of an OATH token in case two-step
verification is not successful. You can also specify the session
timeout in minutes.
Enable logging Enable logging on the user portal. The log files are located at:
C:\Program Files\Multi-Factor Authentication Server\Logs.
IMPORTANT
Starting in March of 2019 the phone call options will not be available to MFA Server users in free/trial Azure AD tenants.
These settings become visible to the user in the portal once they are enabled and they are signed in to the user
portal.
Self-service user enrollment
If you want your users to sign in and enroll, you must select the Allow users to log in and Allow user
enrollment options under the Settings tab. Remember that the settings you select affect the user sign-in
experience.
For example, when a user signs in to the user portal for the first time, they are then taken to the Azure Multi-Factor
Authentication User Setup page. Depending on how you have configured Azure Multi-Factor Authentication, the
user may be able to select their authentication method.
If they select the Voice Call verification method or have been pre-configured to use that method, the page prompts
the user to enter their primary phone number and extension if applicable. They may also be allowed to enter a
backup phone number.
If the user is required to use a PIN when they authenticate, the page prompts them to create a PIN. After entering
their phone number(s) and PIN (if applicable), the user clicks the Call Me Now to Authenticate button. Azure
Multi-Factor Authentication performs a phone call verification to the user’s primary phone number. The user must
answer the phone call and enter their PIN (if applicable) and press # to move on to the next step of the self-
enrollment process.
If the user selects the Text Message verification method or has been pre-configured to use that method, the page
prompts the user for their mobile phone number. If the user is required to use a PIN when they authenticate, the
page also prompts them to enter a PIN. After entering their phone number and PIN (if applicable), the user clicks
the Text Me Now to Authenticate button. Azure Multi-Factor Authentication performs an SMS verification to
the user’s mobile phone. The user receives the text message with a one-time-passcode (OTP ), then replies to the
message with that OTP plus their PIN (if applicable).
If the user selects the Mobile App verification method, the page prompts the user to install the Microsoft
Authenticator app on their device and generate an activation code. After installing the app, the user clicks the
Generate Activation Code button.
NOTE
To use the Microsoft Authenticator app, the user must enable push notifications for their device.
The page then displays an activation code and a URL along with a barcode picture. If the user is required to use a
PIN when they authenticate, the page additionally prompts them to enter a PIN. The user enters the activation
code and URL into the Microsoft Authenticator app or uses the barcode scanner to scan the barcode picture and
clicks the Activate button.
After the activation is complete, the user clicks the Authenticate Me Now button. Azure Multi-Factor
Authentication performs a verification to the user’s mobile app. The user must enter their PIN (if applicable) and
press the Authenticate button in their mobile app to move on to the next step of the self-enrollment process.
If the administrators have configured the Azure Multi-Factor Authentication Server to collect security questions
and answers, the user is then taken to the Security Questions page. The user must select four security questions
and provide answers to their selected questions.
The user self-enrollment is now complete and the user is signed in to the user portal. Users can sign back in to the
user portal at any time in the future to change their phone numbers, PINs, authentication methods, and security
questions if changing their methods is allowed by their administrators.
Next steps
Deploy the Azure Multi-Factor Authentication Server Mobile App Web Service
Enable mobile app authentication with Azure Multi-
Factor Authentication Server
The Microsoft Authenticator app offers an additional out-of-band verification option. Instead of placing an
automated phone call or SMS to the user during login, Azure Multi-Factor Authentication pushes a notification to
the Microsoft Authenticator app on the user’s smartphone or tablet. The user simply taps Verify (or enters a PIN
and taps “Authenticate”) in the app to complete their sign-in.
Using a mobile app for two-step verification is preferred when phone reception is unreliable. If you use the app as
an OATH token generator, it doesn't require any network or internet connection.
IMPORTANT
IMPORTANT
If you have installed Azure Multi-Factor Authentication Server v8.x or higher, most of the steps below are not required.
Mobile app authentication can be set up by following the steps under Configure the mobile app.
Requirements
To use the Microsoft Authenticator app, you must be running Azure Multi-Factor Authentication Server v8.x or
higher
Configure the mobile app settings in the Azure Multi-Factor

1. In the Multi-Factor Authentication Server console, click the User Portal icon. If users are allowed to control
their authentication methods, check Mobile App on the Settings tab, under Allow users to select method.
Without this feature enabled, end users are required to contact your Help Desk to complete activation for the
Mobile App.
2. Check the Allow users to activate Mobile App box.
3. Check the Allow User Enrollment box.
4. Click the Mobile App icon.
5. Populate the Account name field with the company or organization name to display in the mobile application
for this account.
Next steps
Advanced scenarios with Azure Multi-Factor Authentication and third-party VPNs.
Configure Azure Multi-Factor Authentication Server
for high availability
To achieve high-availability with your Azure Server MFA deployment, you need to deploy multiple MFA servers.
This section provides information on a load-balanced design to achieve your high availability targets in you Azure
MFS Server deployment.
IMPORTANT
MFA Server overview

The Azure MFA Server service architecture comprises several components as shown in the following diagram:
An MFA Server is a Windows Server that has the Azure Multi-Factor Authentication software installed. The MFA
Server instance must be activated by the MFA Service in Azure to function. More than one MFA Server can be
installed on-premises.
The first MFA Server that is installed is the master MFA Server upon activation by the Azure MFA Service by
default. The master MFA server has a writeable copy of the PhoneFactor.pfdata database. Subsequent installations
of instances of MFA Server are known as subordinates. The MFA subordinates have a replicated read-only copy of
the PhoneFactor.pfdata database. MFA servers replicate information using Remote Procedure Call (RPC ). All MFA
Severs must collectively either be domain joined or standalone to replicate information.
Both MFA master and subordinate MFA Servers communicate with the MFA Service when two-factor
authentication is required. For example, when a user attempts to gain access to an application that requires two-
factor authentication, the user will first be authenticated by an identity provider, such as Active Directory (AD ).
After successful authentication with AD, the MFA Server will communicate with the MFA Service. The MFA Server
waits for notification from the MFA Service to allow or deny the user access to the application.
If the MFA master server goes offline, authentications can still be processed, but operations that require changes to
the MFA database cannot be processed. (Examples include: the addition of users, self-service PIN changes,
changing user information, or access to the user portal)
Deployment
Consider the following important points for load balancing Azure MFA Server and its related components.
Using RADIUS standard to achieve high availability. If you are using Azure MFA Servers as RADIUS
servers, you can potentially configure one MFA Server as a primary RADIUS authentication target and
other Azure MFA Servers as secondary authentication targets. However, this method to achieve high
availability may not be practical because you must wait for a time-out period to occur when authentication
fails on the primary authentication target before you can be authenticated against the secondary
authentication target. It is more efficient to load balance the RADIUS traffic between the RADIUS client and
the RADIUS Servers (in this case, the Azure MFA Servers acting as RADIUS servers) so that you can
configure the RADIUS clients with a single URL that they can point to.
Need to manually promote MFA subordinates. If the master Azure MFA server goes offline, the
secondary Azure MFA Servers continue to process MFA requests. However, until a master MFA server is
available, admins can not add users or modify MFA settings, and users can not make changes using the user
portal. Promoting an MFA subordinate to the master role is always a manual process.
Separability of components. The Azure MFA Server comprises several components that can be installed
on the same Windows Server instance or on different instances. These components include the User Portal,
Mobile App Web Service, and the ADFS adapter (agent). This separability makes it possible to use the Web
Application Proxy to publish the User Portal and Mobile App Web Server from the perimeter network. Such
a configuration adds to the overall security of your design, as shown in the following diagram. The MFA
User Portal and Mobile App Web Server may also be deployed in HA load-balanced configurations.
One-time password (OTP ) over SMS (aka one-way SMS ) requires the use of sticky sessions if
traffic is load-balanced. One-way SMS is an authentication option that causes the MFA Server to send the
users a text message containing an OTP. The user enters the OTP in a prompt window to complete the MFA
challenge. If you load balance Azure MFA Servers, the same server that served the initial authentication
request must be the server that receives the OTP message from the user; if another MFA Server receives the
OTP reply, the authentication challenge fails. For more information, see One Time Password over SMS
Added to Azure MFA Server.
Load-Balanced deployments of the User Portal and Mobile App Web Service require sticky
sessions. If you are load-balancing the MFA User Portal and the Mobile App Web Service, each session
needs to stay on the same server.
High-availability deployment
The following diagram shows a complete HA load-balanced implementation of Azure MFA and its components,
along with ADFS for reference.
Note the following items for the correspondingly numbered area of the preceding diagram.
1. The two Azure MFA Servers (MFA1 and MFA2) are load balanced (mfaapp.contoso.com) and are configured
to use a static port (4443) to replicate the PhoneFactor.pfdata database. The Web Service SDK is installed on
each of the MFA Server to enable communication over TCP port 443 with the ADFS servers. The MFA
servers are deployed in a stateless load-balanced configuration. However, if you wanted to use OTP over
SMS, you must use stateful load balancing.
NOTE
Because RPC uses dynamic ports, it is not recommended to open firewalls up to the range of dynamic ports that RPC
can potentially use. If you have a firewall between your MFA application servers, you should configure the MFA
Server to communicate on a static port for the replication traffic between subordinate and master servers and open
that port on your firewall. You can force the static port by creating a DWORD registry value at
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Positive Networks\PhoneFactor called Pfsvc_ncan_ip_tcp_port
and setting the value to an available static port. Connections are always initiated by the subordinate MFA Servers to
the master, the static port is only required on the master, but since you can promote a subordinate to be the master
at any time, you should set the static port on all MFA Servers.
2. The two User Portal/MFA Mobile App servers (MFA-UP -MAS1 and MFA-UP -MAS2) are load balanced in a
stateful configuration (mfa.contoso.com). Recall that sticky sessions are a requirement for load balancing
the MFA User Portal and Mobile App Service.
3. The ADFS Server farm is load balanced and published to the Internet through load-balanced ADFS proxies
in the perimeter network. Each ADFS Server uses the ADFS agent to communicate with the Azure MFA
Servers using a single load-balanced URL (mfaapp.contoso.com) over TCP port 443.
Next steps
Install and configure Azure MFA Server
Upgrade to the latest Azure Multi-Factor
This article walks you through the process of upgrading Azure Multi-Factor Authentication (MFA) Server v6.0 or
higher. If you need to upgrade an old version of the PhoneFactor Agent, refer to Upgrade the PhoneFactor Agent
to Azure Multi-Factor Authentication Server.
If you're upgrading from v6.x or older to v7.x or newer, all components change from .NET 2.0 to .NET 4.5. All
components also require Microsoft Visual C++ 2015 Redistributable Update 1 or higher. The MFA Server installer
installs both the x86 and x64 versions of these components if they aren't already installed. If the User Portal and
Mobile App Web Service run on separate servers, you need to install those packages before upgrading those
components. You can search for the latest Microsoft Visual C++ 2015 Redistributable update on the Microsoft
Download Center.
IMPORTANT
Upgrade steps at a glance:

Upgrade Azure MFA Servers (Subordinates then Master)
Upgrade the User Portal instances
Upgrade the AD FS Adapter instances
Upgrade Azure MFA Server

1. Use the instructions in Download the Azure Multi-Factor Authentication Server to get the latest version of
the Azure MFA Server installer.
2. Make a backup of the MFA Server data file located at C:\Program Files\Multi-Factor Authentication
Server\Data\PhoneFactor.pfdata (assuming the default install location) on your master MFA Server.
3. If you run multiple servers for high availability, change the client systems that authenticate to the MFA
Server so that they stop sending traffic to the servers that are upgrading. If you use a load balancer, remove
a subordinate MFA Server from the load balancer, do the upgrade, and then add the server back into the
farm.
4. Run the new installer on each MFA Server. Upgrade subordinate servers first because they can read the old
data file being replicated by the master.
NOTE
When upgrading a server it should be removed from any loadbalancing or traffic sharing with other MFA Servers.
You do not need to uninstall your current MFA Server before running the installer. The installer performs an in-place
upgrade. The installation path is picked up from the registry from the previous installation, so it installs in the same
location (for example, C:\Program Files\Multi-Factor Authentication Server).
5. If you're prompted to install a Microsoft Visual C++ 2015 Redistributable update package, accept the
prompt. Both the x86 and x64 versions of the package are installed.
6. If you use the Web Service SDK, you are prompted to install the new Web Service SDK. When you install
the new Web Service SDK, make sure that the virtual directory name matches the previously installed
virtual directory (for example, MultiFactorAuthWebServiceSdk).
7. Repeat the steps on all subordinate servers. Promote one of the subordinates to be the new master, then
upgrade the old master server.
Upgrade the User Portal

Complete the upgrade of your MFA Servers before moving to this section.
1. Make a backup of the web.config file that is in the virtual directory of the User Portal installation location
(for example, C:\inetpub\wwwroot\MultiFactorAuth). If any changes were made to the default theme, make
a backup of the App_Themes\Default folder as well. It is better to create a copy of the Default folder and
create a new theme than to change the Default theme.
2. If the User Portal runs on the same server as the other MFA Server components, the MFA Server
installation prompts you to update the User Portal. Accept the prompt and install the User Portal update.
Check that the virtual directory name matches the previously installed virtual directory (for example,
MultiFactorAuth).
3. If the User Portal is on its own server, copy the MultiFactorAuthenticationUserPortalSetup64.msi file from
the install location of one of the MFA Servers and put it onto the User Portal web server. Run the installer.
If an error occurs stating, "Microsoft Visual C++ 2015 Redistributable Update 1 or higher is required,"
download and install the latest update package from the Microsoft Download Center. Install both the x86
and x64 versions.
4. After the updated User Portal software is installed, compare the web.config backup you made in step 1 with
the new web.config file. If no new attributes exist in the new web.config, copy your backup web.config into
the virtual directory to overwrite the new one. Another option is to copy/paste the appSettings values and
the Web Service SDK URL from the backup file into the new web.config.
If you have the User Portal on multiple servers, repeat the installation on all of them.
Upgrade the Mobile App Web Service

NOTE
When upgrading from a version of Azure MFA Server older than 8.0 to 8.0+ that the mobile app web service can be
uninstalled after the upgrade
Upgrade the AD FS Adapters

Complete the upgrade of your MFA Servers and User Portal before moving to this section.
If MFA runs on different servers than AD FS
These instructions only apply if you run Multi-Factor Authentication Server separately from your AD FS servers. If
both services run on the same servers, skip this section and go to the installation steps.
1. Save a copy of the MultiFactorAuthenticationAdfsAdapter.config file that was registered in AD FS, or export
the configuration using the following PowerShell command:
Export-AdfsAuthenticationProviderConfigurationData -Name [adapter name] -FilePath [path to config file] .
The adapter name is either "WindowsAzureMultiFactorAuthentication" or "AzureMfaServerAuthentication"
depending on the version previously installed.
2. Copy the following files from the MFA Server installation location to the AD FS servers:
MultiFactorAuthenticationAdfsAdapterSetup64.msi
Register-MultiFactorAuthenticationAdfsAdapter.ps1
Unregister-MultiFactorAuthenticationAdfsAdapter.ps1
MultiFactorAuthenticationAdfsAdapter.config
3. Edit the Register-MultiFactorAuthenticationAdfsAdapter.ps1 script by adding
-ConfigurationFilePath [path] to the end of the Register-AdfsAuthenticationProvider command. Replace
[path] with the full path to the MultiFactorAuthenticationAdfsAdapter.config file or the configuration file
exported in the previous step.
Check the attributes in the new MultiFactorAuthenticationAdfsAdapter.config to see if they match the old
config file. If any attributes were added or removed in the new version, copy the attribute values from the
old configuration file to the new one or modify the old configuration file to match.
Install new AD FS adapters
IMPORTANT
Your users will not be required to perform two-step verification during steps 3-8 of this section. If you have AD FS configured
in multiple clusters, you can remove, upgrade, and restore each cluster in the farm independently of the other clusters to
avoid downtime.
1. Remove some AD FS servers from the farm. Update these servers while the others are still running.
2. Install the new AD FS adapter on each server removed from the AD FS farm. If the MFA Server is installed
on each AD FS server, you can update through the MFA Server admin UX. Otherwise, update by running
MultiFactorAuthenticationAdfsAdapterSetup64.msi.
If an error occurs stating, "Microsoft Visual C++ 2015 Redistributable Update 1 or higher is required,"
download and install the latest update package from the Microsoft Download Center. Install both the x86
and x64 versions.
3. Go to AD FS > Authentication Policies > Edit Global MultiFactor Authentication Policy. Uncheck
WindowsAzureMultiFactorAuthentication or AzureMFAServerAuthentication (depending on the
current version installed).
Once this step is complete, two-step verification through MFA Server is not available in this AD FS cluster
until you complete step 8.
4. Unregister the older version of the AD FS adapter by running the Unregister-
MultiFactorAuthenticationAdfsAdapter.ps1 PowerShell script. Ensure that the -Name parameter (either
“WindowsAzureMultiFactorAuthentication” or "AzureMFAServerAuthentication") matches the name that
was displayed in step 3. This applies to all servers in the same AD FS cluster since there is a central
configuration.
5. Register the new AD FS adapter by running the Register-MultiFactorAuthenticationAdfsAdapter.ps1
PowerShell script. This applies to all servers in the same AD FS cluster since there is a central configuration.
6. Restart the AD FS service on each server removed from the AD FS farm.
7. Add the updated servers back to the AD FS farm and remove the other servers from the farm.
8. Go to AD FS > Authentication Policies > Edit Global MultiFactor Authentication Policy. Check
AzureMfaServerAuthentication.
9. Repeat step 2 to update the servers now removed from the AD FS farm and restart the AD FS service on
those servers.
10. Add those servers back into the AD FS farm.
Next steps
Get examples of Advanced scenarios with Azure Multi-Factor Authentication and third-party VPNs
Synchronize MFA Server with Windows Server Active Directory
Configure Windows Authentication for your applications
Upgrade the PhoneFactor Agent to Azure Multi-
To upgrade the PhoneFactor Agent v5.x or older to Azure Multi-Factor Authentication Server, uninstall the
PhoneFactor Agent and affiliated components first. Then the Multi-Factor Authentication Server and its affiliated
components can be installed.
IMPORTANT
Uninstall the PhoneFactor Agent

1. First, back up the PhoneFactor data file. The default installation location is C:\Program
Files\PhoneFactor\Data\Phonefactor.pfdata.
2. If the User Portal is installed:
a. Navigate to the install folder and back up the web.config file. The default installation location is
C:\inetpub\wwwroot\PhoneFactor.
b. If you have added custom themes to the portal, back up your custom folder below the
C:\inetpub\wwwroot\PhoneFactor\App_Themes directory.
c. Uninstall the User Portal either through the PhoneFactor Agent (only available if installed on the
same server as the PhoneFactor Agent) or through Windows Programs and Features.
3. If the Mobile App Web Service is installed:
a. Go to the install folder and back up the web.config file. The default installation location is
C:\inetpub\wwwroot\PhoneFactorPhoneAppWebService.
b. Uninstall the Mobile App Web Service through Windows Programs and Features.
4. If the Web Service SDK is installed, uninstall it either through the PhoneFactor Agent or through Windows
Programs and Features.
5. Uninstall the PhoneFactor Agent through Windows Programs and Features.
Install the Multi-Factor Authentication Server

The installation path is picked up from the registry from the previous PhoneFactor Agent installation, so it should
install in the same location (for example, C:\Program Files\PhoneFactor). New installations have a different default
install path (for example, C:\Program Files\Multi-Factor Authentication Server). The data file left by the previous
PhoneFactor Agent should be upgraded during installation, so your users and settings should still be there after
installing the new Multi-Factor Authentication Server.
1. If prompted, activate the Multi-Factor Authentication Server and ensure it is assigned to the correct
replication group.
2. If the Web Service SDK was previously installed, install the new Web Service SDK through the Multi-Factor
Authentication Server User Interface.
The default virtual directory name is now MultiFactorAuthWebServiceSdk instead of
PhoneFactorWebServiceSdk. If you want to use the previous name, you must change the name of the
virtual directory during installation. Otherwise, if you allow the install to use the new default name, you
have to change the URL in any applications that reference the Web Service SDK (like the User Portal and
Mobile App Web Service) to point at the correct location.
3. If the User Portal was previously installed on the PhoneFactor Agent Server, install the new Multi-Factor
Authentication User Portal through the Multi-Factor Authentication Server User Interface.
The default virtual directory name is now MultiFactorAuth instead of PhoneFactor. If you want to use the
previous name, you must change the name of the virtual directory during installation. Otherwise, if you
allow the install to use the new default name, you should click the User Portal icon in the Multi-Factor
Authentication Server and update the User Portal URL on the Settings tab.
4. If the User Portal and/or Mobile App Web Service was previously installed on a different server from the
PhoneFactor Agent:
a. Go to the install location (for example, C:\Program Files\PhoneFactor) and copy one or more
installers to the other server. There are 32-bit and 64-bit installers for both the User Portal and
Mobile App Web Service. They are called MultiFactorAuthenticationUserPortalSetupXX.msi and
MultiFactorAuthenticationMobileAppWebServiceSetupXX.msi.
b. To install the User Portal on the web server, open a command prompt as an administrator and run
MultiFactorAuthenticationUserPortalSetupXX.msi.
The default virtual directory name is now MultiFactorAuth instead of PhoneFactor. If you want to
use the previous name, you must change the name of the virtual directory during installation.
Otherwise, if you allow the install to use the new default name, you should click the User Portal icon
in the Multi-Factor Authentication Server and update the User Portal URL on the Settings tab.
Existing users need to be informed of the new URL.
c. Go to the User Portal install location (for example, C:\inetpub\wwwroot\MultiFactorAuth) and edit
the web.config file. Copy the values in the appSettings and applicationSettings sections from your
original web.config file that was backed up before the upgrade into the new web.config file. If the new
default virtual directory name was kept when installing the Web Service SDK, change the URL in the
applicationSettings section to point to the correct location. If any other defaults were changed in the
previous web.config file, apply those same changes to the new web.config file.
NOTE
When upgrading from a version of Azure MFA Server older than 8.0 to 8.0+ that the mobile app web service can be
uninstalled after the upgrade
Next steps
Install the users portal for the Azure Multi-Factor Authentication Server.
Configure Windows Authentication for your applications.
Windows Authentication and Azure Multi-Factor
Use the Windows Authentication section of the Azure Multi-Factor Authentication Server to enable and configure
Windows authentication for applications. Before you set up Windows Authentication, keep the following list in
mind:
After setup, reboot the Azure Multi-Factor Authentication for Terminal Services to take effect.
If ‘Require Azure Multi-Factor Authentication user match’ is checked and you are not in the user list, you will
not be able to log into the machine after reboot.
Trusted IPs is dependent on whether the application can provide the client IP with the authentication. Currently
only Terminal Services is supported.
IMPORTANT
NOTE
This feature is not supported to secure Terminal Services on Windows Server 2012 R2.
To secure an application with Windows Authentication, use the

following procedure
1. In the Azure Multi-Factor Authentication Server click the Windows Authentication icon.
2. Check the Enable Windows Authentication checkbox. By default, this box is unchecked.
3. The Applications tab allows the administrator to configure one or more applications for Windows
Authentication.
4. Select a server or application – specify whether the server/application is enabled. Click OK.
5. Click Add…
6. The Trusted IPs tab allows you to skip Azure Multi-Factor Authentication for Windows sessions originating
from specific IPs. For example, if employees use the application from the office and from home, you may
decide you don't want their phones ringing for Azure Multi-Factor Authentication while at the office. For this,
you would specify the office subnet as Trusted IPs entry.
7. Click Add…
8. Select Single IP if you would like to skip a single IP address.
9. Select IP Range if you would like to skip an entire IP range. Example 10.63.193.1-10.63.193.100.
10. Select Subnet if you would like to specify a range of IPs using subnet notation. Enter the subnet's starting IP
and pick the appropriate netmask from the drop-down list.
11. Click OK.
Next steps
Configure third-party VPN appliances for Azure MFA Server
Augment your existing authentication infrastructure with the NPS extension for Azure MFA
for IIS web apps
Use the IIS Authentication section of the Azure Multi-Factor Authentication (MFA) Server to enable and configure
IIS authentication for integration with Microsoft IIS web applications. The Azure MFA Server installs a plug-in that
can filter requests being made to the IIS web server to add Azure Multi-Factor Authentication. The IIS plug-in
provides support for Form-Based Authentication and Integrated Windows HTTP Authentication. Trusted IPs can
also be configured to exempt internal IP addresses from two-factor authentication.
IMPORTANT
Using Form-Based IIS Authentication with Azure Multi-Factor

To secure an IIS web application that uses form-based authentication, install the Azure Multi-Factor Authentication
Server on the IIS web server and configure the Server per the following procedure:
1. In the Azure Multi-Factor Authentication Server, click the IIS Authentication icon in the left menu.
2. Click the Form -Based tab.
3. Click Add.
4. To detect username, password and domain variables automatically, enter the Login URL (like
https://localhost/contoso/auth/login.aspx ) within the Auto-Configure Form -Based Website dialog box and
click OK.
5. Check the Require Multi-Factor Authentication user match box if all users have been or will be
imported into the Server and subject to multi-factor authentication. If a significant number of users have
not yet been imported into the Server and/or will be exempt from multi-factor authentication, leave the box
unchecked.
6. If the page variables cannot be detected automatically, click Specify Manually in the Auto-Configure
Form-Based Website dialog box.
7. In the Add Form-Based Website dialog box, enter the URL to the login page in the Submit URL field and
enter an Application name (optional). The Application name appears in Azure Multi-Factor Authentication
reports and may be displayed within SMS or Mobile App authentication messages.
8. Select the correct Request format. This is set to POST or GET for most web applications.
9. Enter the Username variable, Password variable, and Domain variable (if it appears on the login page). To
find the names of the input boxes, navigate to the login page in a web browser, right-click on the page, and
select View Source.
10. Check the Require Azure Multi-Factor Authentication user match box if all users have been or will be
imported into the Server and subject to multi-factor authentication. If a significant number of users have
not yet been imported into the Server and/or will be exempt from multi-factor authentication, leave the box
unchecked.
11. Click Advanced to review advanced settings, including:
Select a custom denial page file
Cache successful authentications to the website for a period of time using cookies
Select whether to authenticate the primary credentials against a Windows Domain, LDAP directory. or
RADIUS server.
12. Click OK to return to the Add Form-Based Website dialog box.
13. Click OK.
14. Once the URL and page variables have been detected or entered, the website data displays in the Form-
Based panel.
Using Integrated Windows Authentication with Azure Multi-Factor

To secure an IIS web application that uses Integrated Windows HTTP authentication, install the Azure MFA Server
on the IIS web server, then configure the Server with the following steps:
2. Click the HTTP tab.
3. Click Add.
4. In the Add Base URL dialogue box, enter the URL for the website where HTTP authentication is performed (like
http://localhost/owa) and provide an Application name (optional). The Application name appears in Azure
Multi-Factor Authentication reports and may be displayed within SMS or Mobile App authentication messages.
5. Adjust the Idle timeout and Maximum session times if the default is not sufficient.
6. Check the Require Multi-Factor Authentication user match box if all users have been or will be imported
into the Server and subject to multi-factor authentication. If a significant number of users have not yet been
imported into the Server and/or will be exempt from multi-factor authentication, leave the box unchecked.
7. Check the Cookie cache box if desired.
8. Click OK.
Enable IIS Plug-ins for Azure Multi-Factor Authentication Server

After configuring the Form-Based or HTTP authentication URLs and settings, select the locations where the Azure
Multi-Factor Authentication IIS plug-ins should be loaded and enabled in IIS. Use the following procedure:
1. If running on IIS 6, click the ISAPI tab. Select the website that the web application is running under (e.g.
Default Web Site) to enable the Azure Multi-Factor Authentication ISAPI filter plug-in for that site.
2. If running on IIS 7 or higher, click the Native Module tab. Select the server, websites, or applications to enable
the IIS plug-in at the desired levels.
3. Click the Enable IIS authentication box at the top of the screen. Azure Multi-Factor Authentication is now
securing the selected IIS application. Ensure that users have been imported into the Server.
Trusted IPs
The Trusted IPs allows users to bypass Azure Multi-Factor Authentication for website requests originating from
specific IP addresses or subnets. For example, you may want to exempt users from Azure Multi-Factor
Authentication while logging in from the office. For this, you would specify the office subnet as a Trusted IPs entry.
To configure Trusted IPs, use the following procedure:
1. In the IIS Authentication section, click the Trusted IPs tab.
2. Click Add.
3. When the Add Trusted IPs dialog box appears, select the Single IP, IP range, or Subnet radio button.
4. Enter the IP address, range of IP addresses or subnet that should be allowed. If entering a subnet, select the
appropriate Netmask and click OK.
LDAP authentication and Azure Multi-Factor
By default, the Azure Multi-Factor Authentication Server is configured to import or synchronize users from Active
Directory. However, it can be configured to bind to different LDAP directories, such as an ADAM directory, or
specific Active Directory domain controller. When connected to a directory via LDAP, the Azure Multi-Factor
Authentication Server can act as an LDAP proxy to perform authentications. It also allows for the use of LDAP
bind as a RADIUS target, for pre-authentication of users with IIS Authentication, or for primary authentication in
the Azure MFA user portal.
To use Azure Multi-Factor Authentication as an LDAP proxy, insert the Azure Multi-Factor Authentication Server
between the LDAP client (for example, VPN appliance, application) and the LDAP directory server. The Azure
Multi-Factor Authentication Server must be configured to communicate with both the client servers and the LDAP
directory. In this configuration, the Azure Multi-Factor Authentication Server accepts LDAP requests from client
servers and applications and forwards them to the target LDAP directory server to validate the primary
credentials. If the LDAP directory validates the primary credentials, Azure Multi-Factor Authentication performs a
second identity verification and sends a response back to the LDAP client. The entire authentication succeeds only
if both the LDAP server authentication and the second-step verification succeed.
IMPORTANT
Configure LDAP authentication

To configure LDAP authentication, install the Azure Multi-Factor Authentication Server on a Windows server. Use
the following procedure:
Add an LDAP client
1. In the Azure Multi-Factor Authentication Server, select the LDAP Authentication icon in the left menu.
2. Check the Enable LDAP Authentication checkbox.
3. On the Clients tab, change the TCP port and SSL port if the Azure Multi-Factor Authentication LDAP
service should bind to non-standard ports to listen for LDAP requests.
4. If you plan to use LDAPS from the client to the Azure Multi-Factor Authentication Server, an SSL certificate
must be installed on the same server as MFA Server. Click Browse next to the SSL certificate box, and
select a certificate to use for the secure connection.
5. Click Add.
6. In the Add LDAP Client dialog box, enter the IP address of the appliance, server, or application that
authenticates to the Server and an Application name (optional). The Application name appears in Azure
Multi-Factor Authentication reports and may be displayed within SMS or Mobile App authentication
messages.
imported into the Server and subject to two-step verification. If a significant number of users have not yet
been imported into the Server and/or are exempt from two-step verification, leave the box unchecked. See
the MFA Server help file for additional information on this feature.
Repeat these steps to add additional LDAP clients.
Configure the LDAP directory connection
When the Azure Multi-Factor Authentication is configured to receive LDAP authentications, it must proxy those
authentications to the LDAP directory. Therefore, the Target tab only displays a single, grayed out option to use an
LDAP target.
NOTE
Directory integration is not guaranteed to work with directories other than Active Directory Domain Services.
1. To configure the LDAP directory connection, click the Directory Integration icon.
2. On the Settings tab, select the Use specific LDAP configuration radio button.
3. Select Edit…
4. In the Edit LDAP Configuration dialog box, populate the fields with the information required to connect to
the LDAP directory. Descriptions of the fields are included in the Azure Multi-Factor Authentication Server
help file.
5. Test the LDAP connection by clicking the Test button.

6. If the LDAP connection test was successful, click the OK button.
7. Click the Filters tab. The Server is pre-configured to load containers, security groups, and users from Active
Directory. If binding to a different LDAP directory, you probably need to edit the filters displayed. Click the
Help link for more information on filters.
8. Click the Attributes tab. The Server is pre-configured to map attributes from Active Directory.
9. If you're binding to a different LDAP directory or to change the pre-configured attribute mappings, click
Edit…
10. In the Edit Attributes dialog box, modify the LDAP attribute mappings for your directory. Attribute names
can be typed in or selected by clicking the … button next to each field. Click the Help link for more
information on attributes.
11. Click the OK button.
12. Click the Company Settings icon and select the Username Resolution tab.
13. If you're connecting to Active Directory from a domain-joined server, leave the Use Windows security
identifiers (SIDs) for matching usernames radio button selected. Otherwise, select the Use LDAP
unique identifier attribute for matching usernames radio button.
When the Use LDAP unique identifier attribute for matching usernames radio button is selected, the Azure
Multi-Factor Authentication Server attempts to resolve each username to a unique identifier in the LDAP
directory. An LDAP search is performed on the Username attributes defined in the Directory Integration ->
Attributes tab. When a user authenticates, the username is resolved to the unique identifier in the LDAP directory.
The unique identifier is used for matching the user in the Azure Multi-Factor Authentication data file. This allows
for case-insensitive comparisons, and long and short username formats.
After you complete these steps, the MFA Server listens on the configured ports for LDAP access requests from the
configured clients, and acts as a proxy for those requests to the LDAP directory for authentication.
Configure LDAP client

To configure the LDAP client, use the guidelines:
Configure your appliance, server, or application to authenticate via LDAP to the Azure Multi-Factor
Authentication Server as though it were your LDAP directory. Use the same settings that you would normally
use to connect directly to your LDAP directory, except for the server name or IP address, which will be that of
the Azure Multi-Factor Authentication Server.
Configure the LDAP timeout to 30-60 seconds so that there is time to validate the user’s credentials with the
LDAP directory, perform the second-step verification, receive their response, and respond to the LDAP access
request.
If using LDAPS, the appliance or server making the LDAP queries must trust the SSL certificate installed on
the Azure Multi-Factor Authentication Server.
Integrate RADIUS authentication with Azure Multi-
RADIUS is a standard protocol to accept authentication requests and to process those requests. The Azure Multi-
Factor Authentication Server can act as a RADIUS server. Insert it between your RADIUS client (VPN appliance)
and your authentication target to add two-step verification. Your authentication target could be Active Directory,
an LDAP directory, or another RADIUS server. For Azure Multi-Factor Authentication (MFA) to function, you must
configure the Azure MFA Server so that it can communicate with both the client servers and the authentication
target. The Azure MFA Server accepts requests from a RADIUS client, validates credentials against the
authentication target, adds Azure Multi-Factor Authentication, and sends a response back to the RADIUS client.
The authentication request only succeeds if both the primary authentication and the Azure Multi-Factor
Authentication succeed.
IMPORTANT
NOTE
The MFA Server only supports PAP (password authentication protocol) and MSCHAPv2 (Microsoft's Challenge-Handshake
Authentication Protocol) RADIUS protocols when acting as a RADIUS server. Other protocols, like EAP (extensible
authentication protocol), can be used when the MFA server acts as a RADIUS proxy to another RADIUS server that supports
that protocol.
In this configuration, one-way SMS and OATH tokens don't work since the MFA Server can't initiate a successful RADIUS
Challenge response using alternative protocols.
Add a RADIUS client
To configure RADIUS authentication, install the Azure Multi-Factor Authentication Server on a Windows server. If
you have an Active Directory environment, the server should be joined to the domain inside the network. Use the
following procedure to configure the Azure Multi-Factor Authentication Server:
1. In the Azure Multi-Factor Authentication Server, click the RADIUS Authentication icon in the left menu.
2. Check the Enable RADIUS authentication checkbox.
3. On the Clients tab, change the Authentication and Accounting ports if the Azure MFA RADIUS service
needs to listen for RADIUS requests on non-standard ports.
4. Click Add.
5. Enter the IP address of the appliance/server that will authenticate to the Azure Multi-Factor Authentication
Server, an application name (optional), and a shared secret.
The application name appears in reports and may be displayed within SMS or mobile app authentication
messages.
The shared secret needs to be the same on both the Azure Multi-Factor Authentication Server and
appliance/server.
6. Check the Require Multi-Factor Authentication user match box if all users have been imported into the
Server and subject to multi-factor authentication. If a significant number of users have not yet been
imported into the Server or are exempt from two-step verification, leave the box unchecked.
7. Check the Enable fallback OATH token box if you want to use OATH passcodes from mobile verification
apps as a backup method.
8. Click OK.
Repeat steps 4 through 8 to add as many additional RADIUS clients as you need.
Configure your RADIUS client
1. Click the Target tab.
If the Azure MFA Server is installed on a domain-joined server in an Active Directory environment,
select Windows domain.
If users should be authenticated against an LDAP directory, select LDAP bind. Select the Directory
Integration icon and edit the LDAP configuration on the Settings tab so that the Server can bind to your
directory. Instructions for configuring LDAP can be found in the LDAP Proxy configuration guide.
If users should be authenticated against another RADIUS server, select RADIUS server(s).
2. Click Add to configure the server to which the Azure MFA Server will proxy the RADIUS requests.
3. In the Add RADIUS Server dialog box, enter the IP address of the RADIUS server and a shared secret.
The shared secret needs to be the same on both the Azure Multi-Factor Authentication Server and RADIUS
server. Change the Authentication port and Accounting port if different ports are used by the RADIUS
server.
4. Click OK.
5. Add the Azure MFA Server as a RADIUS client in the other RADIUS server so that it can process access
requests sent to it from the Azure MFA Server. Use the same shared secret configured in the Azure Multi-
Factor Authentication Server.
Repeat these steps to add more RADIUS servers. Configure the order in which the Azure MFA Server should call
them with the Move Up and Move Down buttons.
You've successfully configured the Azure Multi-Factor Authentication Server. The Server is now listening on the
configured ports for RADIUS access requests from the configured clients.
RADIUS Client configuration

To configure the RADIUS client, use the guidelines:
Configure your appliance/server to authenticate via RADIUS to the Azure Multi-Factor Authentication Server’s
IP address, which acts as the RADIUS server.
Use the same shared secret that was configured earlier.
Configure the RADIUS timeout to 30-60 seconds so that there is time to validate the user’s credentials,
perform two-step verification, receive their response, and then respond to the RADIUS access request.
Next steps
Learn how to integrate with RADIUS authentication if you have Azure Multi-Factor Authentication in the cloud.
Directory integration between Azure MFA Server and
Active Directory
Use the Directory Integration section of the Azure MFA Server to integrate with Active Directory or another LDAP
directory. You can configure attributes to match the directory schema and set up automatic user synchronization.
IMPORTANT
Settings
By default, the Azure Multi-Factor Authentication (MFA) Server is configured to import or synchronize users from
Active Directory. The Directory Integration tab allows you to override the default behavior and to bind to a
different LDAP directory, an ADAM directory, or specific Active Directory domain controller. It also provides for
the use of LDAP Authentication to proxy LDAP or for LDAP Bind as a RADIUS target, pre-authentication for IIS
Authentication, or primary authentication for User Portal. The following table describes the individual settings.
NOTE
Directory integration is not guaranteed to work with directories other than Active Directory Domain Services.
FEATURE DESCRIPTION
Use Active Directory Select the Use Active Directory option to use Active Directory
for importing and synchronization. This is the default setting.
Note: For Active Directory integration to work properly,join
the computer to a domain and sign in with a domain account.
Include trusted domains Check Include Trusted Domains to have the agent attempt
to connect to domains trusted by the current domain,
another domain in the forest, or domains involved in a forest
trust. When not importing or synchronizing users from any of
the trusted domains, uncheck the checkbox to improve
performance. The default is checked.
Use specific LDAP configuration Select the Use LDAP option to use the LDAP settings specified
for importing and synchronization. Note: When Use LDAP is
selected, the user interface changes references from Active
Directory to LDAP.
Edit button The Edit button allows the current LDAP configuration
settings to modified.
Use attribute scope queries Indicates whether attribute scope queries should be used.
Attribute scope queries allow for efficient directory searches
qualifying records based on the entries in another record's
attribute. The Azure Multi-Factor Authentication Server uses
attribute scope queries to efficiently query the users that are a
member of a security group.
Note: There are some cases where attribute scope queries are
supported, but shouldn't be used. For example, Active
Directory can have issues with attribute scope queries when a
security group contains members from more than one
domain. In this case, unselect the checkbox.
The following table describes the LDAP configuration settings.
FEATURE DESCRIPTION
Server Enter the hostname or IP address of the server running the

LDAP directory. A backup server may also be specified
separated by a semi-colon.
Note: When Bind Type is SSL, a fully qualified hostname is
required.
Base DN Enter the distinguished name of the base directory object

from which all directory queries start. For example,
dc=abc,dc=com.
FEATURE DESCRIPTION
Bind type - Queries Select the appropriate bind type for use when binding to
search the LDAP directory. This is used for imports,
synchronization, and username resolution.
Anonymous - An anonymous bind is performed. Bind DN and

Bind Password are not used. This only works if the LDAP
directory allows anonymous binding and permissions allow
the querying of the appropriate records and attributes.
Simple - Bind DN and Bind Password are passed as plain text

to bind to the LDAP directory. This is for testing purposes, to
verify that the server can be reached and that the bind
account has the appropriate access. After the appropriate cert
has been installed, use SSL instead.
SSL - Bind DN and Bind Password are encrypted using SSL to

bind to the LDAP directory. Install a cert locally that the LDAP
directory trusts.
Windows - Bind Username and Bind Password are used to

securely connect to an Active Directory domain controller or
ADAM directory. If Bind Username is left blank, the logged-on
user's account is used to bind.
Bind type - Authentications Select the appropriate bind type for use when performing
LDAP bind authentication. See the bind type descriptions
under Bind type - Queries. For example, this allows for
Anonymous bind to be used for queries while SSL bind is used
to secure LDAP bind authentications.
Bind DN or Bind username Enter the distinguished name of the user record for the
account to use when binding to the LDAP directory.
The bind distinguished name is only used when Bind Type is

Simple or SSL.
Enter the username of the Windows account to use when

binding to the LDAP directory when Bind Type is Windows. If
left blank, the logged-on user's account is used to bind.
Bind Password Enter the bind password for the Bind DN or username being
used to bind to the LDAP directory. To configure the
password for the Multi-Factor Auth Server AdSync Service,
enable synchronization and ensure that the service is running
on the local machine. The password is saved in the Windows
Stored Usernames and Passwords under the account the
Multi-Factor Auth Server AdSync Service is running as. The
password is also saved under the account the Multi-Factor
Auth Server user interface is running as and under the
account the Multi-Factor Auth Server Service is running as.
Since the password is only stored in the local server's

Windows Stored Usernames and Passwords, repeat this step
on each Multi-Factor Auth Server that needs access to the
password.
FEATURE DESCRIPTION
Query size limit Specify the size limit for the maximum number of users that a
directory search returns. This limit should match the
configuration on the LDAP directory. For large searches where
paging is not supported, import and synchronization
attempts to retrieve users in batches. If the size limit specified
here is larger than the limit configured on the LDAP directory,
some users may be missed.
Test button Click Test to test binding to the LDAP server.
You don't need to select the Use LDAP option to test binding.
This allows the binding to be tested before you use the LDAP
configuration.
Filters
Filters allow you to set criteria to qualify records when performing a directory search. By setting the filter, you can
scope the objects you want to synchronize.
Azure Multi-Factor Authentication has the following three filter options:

Container filter - Specify the filter criteria used to qualify container records when performing a directory
search. For Active Directory and ADAM, (|(objectClass=organizationalUnit)(objectClass=container)) is
commonly used. For other LDAP directories, use filter criteria that qualifies each type of container object,
depending on the directory schema.
Note: If left blank, ((objectClass=organizationalUnit)(objectClass=container)) is used by default.
Security group filter - Specify the filter criteria used to qualify security group records when performing a
directory search. For Active Directory and ADAM, (&(objectCategory=group)
(groupType:1.2.840.113556.1.4.804:=-2147483648)) is commonly used. For other LDAP directories, use filter
criteria that qualifies each type of security group object, depending on the directory schema.
Note: If left blank, (&(objectCategory=group)(groupType:1.2.840.113556.1.4.804:=-2147483648)) is used by
default.
User filter - Specify the filter criteria used to qualify user records when performing a directory search. For
Active Directory and ADAM, (&(objectClass=user)(objectCategory=person)) is commonly used. For other
LDAP directories, use (objectClass=inetOrgPerson) or something similar, depending on the directory schema.
Note: If left blank, (&(objectCategory=person)(objectClass=user)) is used by default.
Attributes
You can customize attributes as necessary for a specific directory. This allows you to add custom attributes and
fine-tune the synchronization to only the attributes that you need. Use the name of the attribute as defined in the
directory schema for the value of each attribute field. The following table provides additional information about
each feature.
Attributes may be entered manually and are not required to match an attribute in the attribute list.
FEATURE DESCRIPTION
Unique identifier Enter the attribute name of the attribute that serves as the
unique identifier of container, security group, and user
records. In Active Directory, this is usually objectGUID. Other
LDAP implementations may use entryUUID or something
similar. The default is objectGUID.
FEATURE DESCRIPTION
Unique identifier type Select the type of the unique identifier attribute. In Active
Directory, the objectGUID attribute is of type GUID. Other
LDAP implementations may use type ASCII Byte Array or
String. The default is GUID.
It is important to set this type correctly since Synchronization

Items are referenced by their Unique Identifier. The Unique
Identifier Type is used to directly find the object in the
directory. Setting this type to String when the directory
actually stores the value as a byte array of ASCII characters
prevents synchronization from functioning properly.
Distinguished name Enter the attribute name of the attribute that contains the
distinguished name for each record. In Active Directory, this is
usually distinguishedName. Other LDAP implementations may
use entryDN or something similar. The default is
distinguishedName.
If an attribute containing just the distinguished name doesn't

exist, the ads path attribute may be used. The
"LDAP://<server>/" portion of the path is automatically
stripped off, leaving just the distinguished name of the object.
Container name Enter the attribute name of the attribute that contains the
name in a container record. The value of this attribute is
displayed in the Container Hierarchy when importing from
Active Directory or adding synchronization items. The default
is name.
If different containers use different attributes for their names,

use semi-colons to separate multiple container name
attributes. The first container name attribute found on a
container object is used to display its name.
Security group name Enter the attribute name of the attribute that contains the
name in a security group record. The value of this attribute is
displayed in the Security Group list when importing from
Active Directory or adding synchronization items. The default
is name.
Username Enter the attribute name of the attribute that contains the
username in a user record. The value of this attribute is used
as the Multi-Factor Auth Server username. A second attribute
may be specified as a backup to the first. The second attribute
is only used if the first attribute does not contain a value for
the user. The defaults are userPrincipalName and
sAMAccountName.
First name Enter the attribute name of the attribute that contains the
first name in a user record. The default is givenName.
Last name Enter the attribute name of the attribute that contains the last
name in a user record. The default is sn.
Email address Enter the attribute name of the attribute that contains the
email address in a user record. Email address is used to send
welcome and update emails to the user. The default is mail.
FEATURE DESCRIPTION
User group Enter the attribute name of the attribute that contains the
user group in a user record. User group can be used to filter
users in the agent and on reports in the Multi-Factor Auth
Server Management Portal.
Description Enter the attribute name of the attribute that contains the
description in a user record. Description is only used for
searching. The default is description.
Phone call language Enter the attribute name of the attribute that contains the
short name of the language to use for voice calls for the user.
Text message language Enter the attribute name of the attribute that contains the
short name of the language to use for SMS text messages for
the user.
Mobile app language Enter the attribute name of the attribute that contains the
short name of the language to use for phone app text
messages for the user.
OATH token language Enter the attribute name of the attribute that contains the
short name of the language to use for OATH token text
messages for the user.
Business phone Enter the attribute name of the attribute that contains the
business phone number in a user record. The default is
telephoneNumber.
Home phone Enter the attribute name of the attribute that contains the
home phone number in a user record. The default is
homePhone.
Pager Enter the attribute name of the attribute that contains the
pager number in a user record. The default is pager.
Mobile phone Enter the attribute name of the attribute that contains the
mobile phone number in a user record. The default is mobile.
Fax Enter the attribute name of the attribute that contains the fax
number in a user record. The default is
facsimileTelephoneNumber.
IP phone Enter the attribute name of the attribute that contains the IP
phone number in a user record. The default is ipPhone.
Custom Enter the attribute name of the attribute that contains a

custom phone number in a user record. The default is blank.
FEATURE DESCRIPTION
Extension Enter the attribute name of the attribute that contains the
phone number extension in a user record. The value of the
extension field is used as the extension to the primary phone
number only. The default is blank.
If the Extension attribute is not specified, extensions can be

included as part of the phone attribute. In this case, precede
the extension with an 'x' so that it gets parsed correctly. For
example, 555-123-4567 x890 would result in 555-123-4567
as the phone number and 890 as the extension.
Restore Defaults button Click Restore Defaults to return all attributes back to their
default value. The defaults should work properly with the
normal Active Directory or ADAM schema.
To edit attributes, click Edit on the Attributes tab. This brings up a window where you can edit the attributes. Select
the ... next to any attribute to open a window where you can choose which attributes to display.
Synchronization
Synchronization keeps the Azure MFA user database synchronized with the users in Active Directory or another
Lightweight Directory Access Protocol (LDAP ) directory. The process is similar to importing users manually from
Active Directory, but periodically polls for Active Directory user and security group changes to process. It also
disables or removes users that were removed from a container, security group, or Active Directory.
The Multi-Factor Auth ADSync service is a Windows service that performs the periodic polling of Active Directory.
This is not to be confused with Azure AD Sync or Azure AD Connect. the Multi-Factor Auth ADSync, although
built on a similar code base, is specific to the Azure Multi-Factor Authentication Server. It is installed in a Stopped
state and is started by the Multi-Factor Auth Server service when configured to run. If you have a multi-server
Multi-Factor Auth Server configuration, the Multi-Factor Auth ADSync may only be run on a single server.
The Multi-Factor Auth ADSync service uses the DirSync LDAP server extension provided by Microsoft to
efficiently poll for changes. This DirSync control caller must have the "directory get changes" right and DS -
Replication-Get-Changes extended control access right. By default, these rights are assigned to the Administrator
and LocalSystem accounts on domain controllers. The Multi-Factor Auth AdSync service is configured to run as
LocalSystem by default. Therefore it is simplest to run the service on a domain controller. If you configure the
service to always perform a full synchronization, it can run as an account with lesser permissions. This is less
efficient, but requires fewer account privileges.
If the LDAP directory supports and is configured for DirSync, then polling for user and security group changes will
work the same as it does with Active Directory. If the LDAP directory does not support the DirSync control, then a
full synchronization is performed during each cycle.
The following table contains additional information on each of the Synchronization tab settings.
FEATURE DESCRIPTION
Enable synchronization with Active Directory When checked, the Multi-Factor Auth Server service
periodically polls Active Directory for changes.
Note: At least one Synchronization Item must be added and a

Synchronize Now must be performed before the Multi-Factor
Auth Server service will start processing changes.
Synchronize every Specify the time interval the Multi-Factor Auth Server service
will wait between polling and processing changes.
Note: The interval specified is the time between the beginning

of each cycle. If the time processing changes exceed the
interval, the service will poll again immediately.
FEATURE DESCRIPTION
Remove users no longer in Active Directory When checked, the Multi-Factor Auth Server service will
process Active Directory deleted user tombstones and remove
the related Multi-Factor Auth Server user.
Always perform a full synchronization When checked, the Multi-Factor Auth Server service will
always perform a full synchronization. When unchecked, the
Multi-Factor Auth Server service will perform an incremental
synchronization by only querying users that have changed.
The default is unchecked.
When unchecked, Azure MFA Server performs incremental

synchronization only when the directory supports the DirSync
control and the account binding to the directory has
permissions to perform DirSync incremental queries. If the
account does not have the appropriate permissions or
multiple domains are involved in the synchronization, Azure
MFA Server performs a full synchronization.
Require administrator approval when more than X users will Synchronization items can be configured to disable or remove
be disabled or removed users who are no longer a member of the item's container or
security group. As a safeguard, administrator approval can be
required when the number of users to disable or remove
exceeds a threshold. When checked, approval is required for
specified threshold. The default is 5 and the range is 1 to 999.
Approval is facilitated by first sending an email notification to

administrators. The email notification gives instructions for
reviewing and approving the disabling and removal of users.
When the Multi-Factor Auth Server user interface is launched,
it will prompt for approval.
The Synchronize Now button allows you to run a full synchronization for the synchronization items specified. A
full synchronization is required whenever synchronization items are added, modified, removed, or reordered. It is
also required before the Multi-Factor Auth AdSync service is operational since it sets the starting point from which
the service will poll for incremental changes. If changes have been made to synchronization items but a full
synchronization hasn't been performed, you will be prompted to Synchronize Now.
The Remove button allows the administrator to delete one or more synchronization items from the Multi-Factor
Auth Server synchronization item list.
WARNING
Once a synchronization item record has been removed, it cannot be recovered. You will need to add the synchronization
item record again if you deleted it by mistake.
The synchronization item or synchronization items have been removed from Multi-Factor Auth Server. The Multi-
Factor Auth Server service will no longer process the synchronization items.
The Move Up and Move Down buttons allow the administrator to change the order of the synchronization items.
The order is important since the same user may be a member of more than one synchronization item (e.g. a
container and a security group). The settings applied to the user during synchronization will come from the first
synchronization item in the list to which the user is associated. Therefore, the synchronization items should be put
in priority order.
TIP
A full synchronization should be performed after removing synchronization items. A full synchronization should be
performed after ordering synchronization items. Click Synchronize Now to perform a full synchronization.
Multi-Factor Authentication servers

Additional Multi-Factor Authentication servers may be set up to serve as a backup RADIUS proxy, LDAP proxy, or
for IIS Authentication. The Synchronization configuration is shared among all the agents. However, only one of
these agents may have the Multi-Factor Authentication server service running. This tab allows you to select the
Multi-Factor Authentication server that should be enabled for synchronization.
to work with AD FS 2.0
This article is for organizations that are federated with Azure Active Directory, and want to secure resources that
are on-premises or in the cloud. Protect your resources by using the Azure Multi-Factor Authentication Server and
configuring it to work with AD FS so that two-step verification is triggered for high-value end points.
This documentation covers using the Azure Multi-Factor Authentication Server with AD FS 2.0. For information
about AD FS, see Securing cloud and on-premises resources using Azure Multi-Factor Authentication Server with
Windows Server 2012 R2 AD FS.
IMPORTANT
Secure AD FS 2.0 with a proxy

To secure AD FS 2.0 with a proxy, install the Azure Multi-Factor Authentication Server on the AD FS proxy server.
Configure IIS authentication
2. Click the Form -Based tab.
3. Click Add.
4. To detect username, password, and domain variables automatically, enter the login URL (like
https://sso.contoso.com/adfs/ls) within the Auto-Configure Form-Based Website dialog box and click OK.
been imported into the Server and/or will be exempt from two-step verification, leave the box unchecked.
6. If the page variables cannot be detected automatically, click the Specify Manually… button in the Auto-
Configure Form-Based Website dialog box.
7. In the Add Form-Based Website dialog box, enter the URL to the AD FS login page in the Submit URL field
(like https://sso.contoso.com/adfs/ls) and enter an Application name (optional). The Application name
appears in Azure Multi-Factor Authentication reports and may be displayed within SMS or Mobile App
authentication messages.
8. Set the Request format to POST or GET.
9. Enter the Username variable (ctl00$ContentPlaceHolder1$UsernameTextBox) and Password variable
(ctl00$ContentPlaceHolder1$PasswordTextBox). If your form-based login page displays a domain textbox,
enter the Domain variable as well. To find the names of the input boxes on the login page, go to the login
page in a web browser, right-click on the page and select View Source.
11. Click Advanced… to review advanced settings. Settings that you can configure include:
Select a custom denial page file
Cache successful authentications to the website using cookies
Select how to authenticate the primary credentials
12. Since the AD FS proxy server is not likely to be joined to the domain, you can use LDAP to connect to your
domain controller for user import and pre-authentication. In the Advanced Form-Based Website dialog box,
click the Primary Authentication tab and select LDAP Bind for the Pre-authentication Authentication
type.
13. When complete, click OK to return to the Add Form-Based Website dialog box.
14. Click OK to close the dialog box.
15. Once the URL and page variables have been detected or entered, the website data displays in the Form-
Based panel.
16. Click the Native Module tab and select the server, the website that the AD FS proxy is running under (like
“Default Web Site”), or the AD FS proxy application (like “ls” under “adfs”) to enable the IIS plug-in at the
desired level.
17. Click the Enable IIS authentication box at the top of the screen.
The IIS authentication is now enabled.
Configure directory integration
You enabled IIS authentication, but to perform the pre-authentication to your Active Directory (AD ) via LDAP you
must configure the LDAP connection to the domain controller.
1. Click the Directory Integration icon.
2. On the Settings tab, select the Use specific LDAP configuration radio button.
3. Click Edit.
4. In the Edit LDAP Configuration dialog box, populate the fields with the information required to connect to
the AD domain controller. Descriptions of the fields are included in the Azure Multi-Factor Authentication
Server help file.
5. Test the LDAP connection by clicking the Test button.
6. If the LDAP connection test was successful, click OK.

Configure company settings
1. Next, click the Company Settings icon and select the Username Resolution tab.
2. Select the Use LDAP unique identifier attribute for matching usernames radio button.
3. If users enter their username in “domain\username” format, the Server needs to be able to strip the domain off
the username when it creates the LDAP query. That can be done through a registry setting.
4. Open the registry editor and go to HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Positive
Networks/PhoneFactor on a 64-bit server. If on a 32-bit server, take the “Wow6432Node” out of the path.
Create a DWORD registry key called “UsernameCxz_stripPrefixDomain” and set the value to 1. Azure Multi-
Factor Authentication is now securing the AD FS proxy.
Ensure that users have been imported from Active Directory into the Server. See the Trusted IPs section if you
would like to allow internal IP addresses so that two-step verification is not required when signing in to the
website from those locations.
AD FS 2.0 Direct without a proxy

You can secure AD FS when the AD FS proxy is not used. Install the Azure Multi-Factor Authentication Server on
the AD FS server and configure the Server per the following steps:
1. Within the Azure Multi-Factor Authentication Server, click the IIS Authentication icon in the left menu.
2. Click the HTTP tab.
3. Click Add.
4. In the Add Base URL dialogue box, enter the URL for the AD FS website where HTTP authentication is
performed (like https://sso.domain.com/adfs/ls/auth/integrated) into the Base URL field. Then, enter an
Application name (optional). The Application name appears in Azure Multi-Factor Authentication reports
and may be displayed within SMS or Mobile App authentication messages.
5. If desired, adjust the Idle timeout and Maximum session times.
7. Check the cookie cache box if desired.
8. Click OK.
9. Click the Native Module tab and select the server, the website (like “Default Web Site”), or the AD FS
application (like “ls” under “adfs”) to enable the IIS plug-in at the desired level.
10. Click the Enable IIS authentication box at the top of the screen.
Azure Multi-Factor Authentication is now securing AD FS.
Ensure that users have been imported from Active Directory into the Server. See the Trusted IPs section if you
would like to allow internal IP addresses so that two-step verification is not required when signing in to the
website from those locations.
Trusted IPs
Trusted IPs allow users to bypass Azure Multi-Factor Authentication for website requests originating from specific
IP addresses or subnets. For example, you may want to exempt users from two-step verification when they sign in
from the office. For this, you would specify the office subnet as a Trusted IPs entry.
To configure trusted IPs
1. In the IIS Authentication section, click the Trusted IPs tab.
2. Click the Add… button.
3. When the Add Trusted IPs dialog box appears, select one of the Single IP, IP range, or Subnet radio buttons.
4. Enter the IP address, range of IP addresses, or subnet that should be allowed. If entering a subnet, select the
appropriate Netmask and click the OK button.
to work with AD FS in Windows Server
If you use Active Directory Federation Services (AD FS ) and want to secure cloud or on-premises resources, you
can configure Azure Multi-Factor Authentication Server to work with AD FS. This configuration triggers two-step
verification for high-value endpoints.
In this article, we discuss using Azure Multi-Factor Authentication Server with AD FS in Windows Server 2012 R2
or Windows Server 2016. For more information, read about how to secure cloud and on-premises resources by
using Azure Multi-Factor Authentication Server with AD FS 2.0.
IMPORTANT
Secure Windows Server AD FS with Azure Multi-Factor Authentication

Server
When you install Azure Multi-Factor Authentication Server, you have the following options:
Install Azure Multi-Factor Authentication Server locally on the same server as AD FS
Install the Azure Multi-Factor Authentication adapter locally on the AD FS server, and then install Multi-Factor
Authentication Server on a different computer
Before you begin, be aware of the following information:
You don't have to install Azure Multi-Factor Authentication Server on your AD FS server. However, you must
install the Multi-Factor Authentication adapter for AD FS on a Windows Server 2012 R2 or Windows Server
2016 that is running AD FS. You can install the server on a different computer if you install the AD FS adapter
separately on your AD FS federation server. See the following procedures to learn how to install the adapter
separately.
If your organization is using text message or mobile app verification methods, the strings defined in Company
Settings contain a placeholder, <$application_name$>. In MFA Server v7.1, you can provide an application
name that replaces this placeholder. In v7.0 or older, this placeholder is not automatically replaced when you
use the AD FS adapter. For those older versions, remove the placeholder from the appropriate strings when
you secure AD FS.
The account that you use to sign in must have user rights to create security groups in your Active Directory
service.
The Multi-Factor Authentication AD FS adapter installation wizard creates a security group called PhoneFactor
Admins in your instance of Active Directory. It then adds the AD FS service account of your federation service
to this group. Verify that the PhoneFactor Admins group was created on your domain controller, and that the
AD FS service account is a member of this group. If necessary, manually add the AD FS service account to the
PhoneFactor Admins group on your domain controller.
For information about installing the Web Service SDK with the user portal, see deploying the user portal for
Azure Multi-Factor Authentication Server.
Install Azure Multi-Factor Authentication Server locally on the AD FS server
1. Download and install Azure Multi-Factor Authentication Server on your AD FS server. For installation
information, read about getting started with Azure Multi-Factor Authentication Server.
2. In the Azure Multi-Factor Authentication Server management console, click the AD FS icon. Select the
options Allow user enrollment and Allow users to select method.
3. Select any additional options you'd like to specify for your organization.
4. Click Install AD FS Adapter.
5. If the Active Directory window is displayed, that means two things. Your computer is joined to a domain,
and the Active Directory configuration for securing communication between the AD FS adapter and the
Multi-Factor Authentication service is incomplete. Click Next to automatically complete this configuration,
or select the Skip automatic Active Directory configuration and configure settings manually check
box. Click Next.
6. If the Local Group windows is displayed, that means two things. Your computer is not joined to a domain,
and the local group configuration for securing communication between the AD FS adapter and the Multi-
Factor Authentication service is incomplete. Click Next to automatically complete this configuration, or
select the Skip automatic Local Group configuration and configure settings manually check box.
Click Next.
7. In the installation wizard, click Next. Azure Multi-Factor Authentication Server creates the PhoneFactor
Admins group and adds the AD FS service account to the PhoneFactor Admins group.
8. On the Launch Installer page, click Next.
9. In the Multi-Factor Authentication AD FS adapter installer, click Next.
10. Click Close when the installation is finished.
11. When the adapter has been installed, you must register it with AD FS. Open Windows PowerShell and run
the following command:
C:\Program Files\Multi-Factor Authentication Server\Register-MultiFactorAuthenticationAdfsAdapter.ps1
12. To use your newly registered adapter, edit the global authentication policy in AD FS. In the AD FS
management console, go to the Authentication Policies node. In the Multi-factor Authentication
section, click the Edit link next to the Global Settings section. In the Edit Global Authentication Policy
window, select Multi-Factor Authentication as an additional authentication method, and then click OK.
The adapter is registered as WindowsAzureMultiFactorAuthentication. Restart the AD FS service for the
registration to take effect.
At this point, Multi-Factor Authentication Server is set up to be an additional authentication provider to use with
AD FS.
Install a standalone instance of the AD FS adapter by using the Web

Service SDK
1. Install the Web Service SDK on the server that is running Multi-Factor Authentication Server.
2. Copy the following files from the \Program Files\Multi-Factor Authentication Server directory to the server on
which you plan to install the AD FS adapter:
MultiFactorAuthenticationAdfsAdapterSetup64.msi
Register-MultiFactorAuthenticationAdfsAdapter.ps1
Unregister-MultiFactorAuthenticationAdfsAdapter.ps1
MultiFactorAuthenticationAdfsAdapter.config
3. Run the MultiFactorAuthenticationAdfsAdapterSetup64.msi installation file.
4. In the Multi-Factor Authentication AD FS adapter installer, click Next to start the installation.
5. Click Close when the installation is finished.
Edit the MultiFactorAuthenticationAdfsAdapter.config file

Follow these steps to edit the MultiFactorAuthenticationAdfsAdapter.config file:
1. Set the UseWebServiceSdk node to true.
2. Set the value for WebServiceSdkUrl to the URL of the Multi-Factor Authentication Web Service SDK. For
example: https://contoso.com/<certificatename>/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx, Where
<certificatename> is the name of your certificate.
3. Edit the Register-MultiFactorAuthenticationAdfsAdapter.ps1 script by adding
-ConfigurationFilePath <path> to the end of the Register-AdfsAuthenticationProvider command, where
<path> is the full path to the MultiFactorAuthenticationAdfsAdapter.config file.
Configure the Web Service SDK with a username and password
There are two options for configuring the Web Service SDK. The first is with a username and password, the
second is with a client certificate. Follow these steps for the first option, or skip ahead for the second.
1. Set the value for WebServiceSdkUsername to an account that is a member of the PhoneFactor Admins
security group. Use the <domain>\<user name> format.
2. Set the value for WebServiceSdkPassword to the appropriate account password.
Configure the Web Service SDK with a client certificate
If you don't want to use a username and password, follow these steps to configure the Web Service SDK with a
client certificate.
1. Obtain a client certificate from a certificate authority for the server that is running the Web Service SDK. Learn
how to obtain client certificates.
2. Import the client certificate to the local computer personal certificate store on the server that is running the
Web Service SDK. Make sure that the certificate authority's public certificate is in Trusted Root Certificates
certificate store.
3. Export the public and private keys of the client certificate to a .pfx file.
4. Export the public key in Base64 format to a .cer file.
5. In Server Manager, verify that the Web Server (IIS )\Web Server\Security\IIS Client Certificate Mapping
Authentication feature is installed. If it is not installed, select Add Roles and Features to add this feature.
6. In IIS Manager, double-click Configuration Editor in the website that contains the Web Service SDK virtual
directory. It is important to select the website, not the virtual directory.
7. Go to the system.webServer/security/authentication/iisClientCertificateMappingAuthentication
section.
8. Set enabled to true.
9. Set oneToOneCertificateMappingsEnabled to true.
10. Click the ... button next to oneToOneMappings, and then click the Add link.
11. Open the Base64 .cer file you exported earlier. Remove -----BEGIN CERTIFICATE -----, -----END CERTIFICATE -
----, and any line breaks. Copy the resulting string.
12. Set certificate to the string copied in the preceding step.
13. Set enabled to true.
14. Set userName to an account that is a member of the PhoneFactor Admins security group. Use the <domain>\
<user name> format.
15. Set the password to the appropriate account password, and then close Configuration Editor.
16. Click the Apply link.
17. In the Web Service SDK virtual directory, double-click Authentication.
18. Verify that ASP.NET Impersonation and Basic Authentication are set to Enabled, and that all other items are
set to Disabled.
19. In the Web Service SDK virtual directory, double-click SSL Settings.
20. Set Client Certificates to Accept, and then click Apply.
21. Copy the .pfx file you exported earlier to the server that is running the AD FS adapter.
22. Import the .pfx file to the local computer personal certificate store.
23. Right-click and select Manage Private Keys, and then grant read access to the account you used to sign in to
the AD FS service.
24. Open the client certificate and copy the thumbprint from the Details tab.
25. In the MultiFactorAuthenticationAdfsAdapter.config file, set WebServiceSdkCertificateThumbprint to the
string copied in the previous step.
Finally, to register the adapter, run the \Program Files\Multi-Factor Authentication Server\Register-
MultiFactorAuthenticationAdfsAdapter.ps1 script in PowerShell. The adapter is registered as
WindowsAzureMultiFactorAuthentication. Restart the AD FS service for the registration to take effect.
Secure Azure AD resources using AD FS

To secure your cloud resource, set up a claims rule so that Active Directory Federation Services emits the
multipleauthn claim when a user performs two-step verification successfully. This claim is passed on to Azure AD.
Follow this procedure to walk through the steps:
3. Right-click on Microsoft Office 365 Identity Platform and select Edit Claim Rules…

6. Give your rule a name.

7. Select Authentication Methods References as the Incoming claim type.
8. Select Pass through all claim values.
9. Click Finish. Close the AD FS Management console.
Troubleshooting logs
To help with troubleshooting issues with the MFA Server AD FS Adapter use the steps that follow to enable
additional logging.
1. In the MFA Server interface, open the AD FS section, and check the Enable logging checkbox.
2. On each AD FS server, use regedit.exe to create string value registry key
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Positive Networks\PhoneFactor\InstallPath with value
C:\Program Files\Multi-Factor Authentication Server\ (or other directory of your choice). Note, the trailing
backslash is important.
3. Create C:\Program Files\Multi-Factor Authentication Server\Logs directory (or other directory as referenced in
Step 2).
4. Grant Modify access on the Logs directory to the AD FS service account.
5. Restart the AD FS service.
6. Verify that MultiFactorAuthAdfsAdapter.log file was created in the Logs directory.
Related topics
For troubleshooting help, see the Azure Multi-Factor Authentication FAQs
Remote Desktop Gateway and Azure Multi-Factor
Authentication Server using RADIUS
Often, Remote Desktop (RD ) Gateway uses the local Network Policy Services (NPS ) to authenticate users. This
article describes how to route RADIUS requests out from the Remote Desktop Gateway (through the local NPS )
to the Multi-Factor Authentication Server. The combination of Azure MFA and RD Gateway means that your
users can access their work environments from anywhere while performing strong authentication.
Since Windows Authentication for terminal services is not supported for Server 2012 R2, use RD Gateway and
RADIUS to integrate with MFA Server.
Install the Azure Multi-Factor Authentication Server on a separate server, which proxies the RADIUS request
back to the NPS on the Remote Desktop Gateway Server. After NPS validates the username and password, it
returns a response to the Multi-Factor Authentication Server. Then, the MFA Server performs the second factor
of authentication and returns a result to the gateway.
IMPORTANT
As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who would like to
require multi-factor authentication from their users should use cloud-based Azure Multi-Factor Authentication. Existing
customers who have activated MFA Server prior to July 1 will be able to download the latest version, future updates and
generate activation credentials as usual.
Prerequisites
A domain-joined Azure MFA Server. If you don't have one installed already, follow the steps in Getting started
with the Azure Multi-Factor Authentication Server.
An existing configured NPS Server.
A Remote Desktop Gateway that authenticates with Network Policy Services.
NOTE
This article should be used with MFA Server deployments only, not Azure MFA (Cloud-based).
Configure the Remote Desktop Gateway

Configure the RD Gateway to send RADIUS authentication to an Azure Multi-Factor Authentication Server.
1. In RD Gateway Manager, right-click the server name and select Properties.
2. Go to the RD CAP Store tab and select Central server running NPS.
3. Add one or more Azure Multi-Factor Authentication Servers as RADIUS servers by entering the name or IP
address of each server.
4. Create a shared secret for each server.
Configure NPS
The RD Gateway uses NPS to send the RADIUS request to Azure Multi-Factor Authentication. To configure NPS,
first you change the timeout settings to prevent the RD Gateway from timing out before the two-step verification
has completed. Then, you update NPS to receive RADIUS authentications from your MFA Server. Use the
following procedure to configure NPS:
Modify the timeout policy
1. In NPS, open the RADIUS Clients and Server menu in the left column and select Remote RADIUS Server
Groups.
2. Select the TS GATEWAY SERVER GROUP.
3. Go to the Load Balancing tab.
4. Change both the Number of seconds without response before request is considered dropped and the
Number of seconds between requests when server is identified as unavailable to between 30 and 60
seconds. (If you find that the server still times out during authentication, you can come back here and increase
the number of seconds.)
5. Go to the Authentication/Account tab and check that the RADIUS ports specified match the ports that the
Multi-Factor Authentication Server is listening on.
Prepare NPS to receive authentications from the MFA Server
1. Right-click RADIUS Clients under RADIUS Clients and Servers in the left column and select New.
2. Add the Azure Multi-Factor Authentication Server as a RADIUS client. Choose a Friendly name and specify a
shared secret.
3. Open the Policies menu in the left column and select Connection Request Policies. You should see a policy
called TS GATEWAY AUTHORIZATION POLICY that was created when RD Gateway was configured. This
policy forwards RADIUS requests to the Multi-Factor Authentication Server.
4. Right-click TS GATEWAY AUTHORIZATION POLICY and select Duplicate Policy.
5. Open the new policy and go to the Conditions tab.
6. Add a condition that matches the Client Friendly Name with the Friendly name set in step 2 for the Azure
Multi-Factor Authentication Server RADIUS client.
7. Go to the Settings tab and select Authentication.
8. Change the Authentication Provider to Authenticate requests on this server. This policy ensures that when
NPS receives a RADIUS request from the Azure MFA Server, the authentication occurs locally instead of
sending a RADIUS request back to the Azure Multi-Factor Authentication Server, which would result in a loop
condition.
9. To prevent a loop condition, make sure that the new policy is ordered ABOVE the original policy in the
Connection Request Policies pane.

The Azure Multi-Factor Authentication Server is configured as a RADIUS proxy between RD Gateway and NPS.
It should be installed on a domain-joined server that is separate from the RD Gateway server. Use the following
procedure to configure the Azure Multi-Factor Authentication Server.
1. Open the Azure Multi-Factor Authentication Server and select the RADIUS Authentication icon.
2. Check the Enable RADIUS authentication checkbox.
3. On the Clients tab, ensure the ports match what is configured in NPS then select Add.
4. Add the RD Gateway server IP address, application name (optional), and a shared secret. The shared secret
needs to be the same on both the Azure Multi-Factor Authentication Server and RD Gateway.
5. Go to the Target tab and select the RADIUS server(s) radio button.
6. Select Add and enter the IP address, shared secret, and ports of the NPS server. Unless using a central NPS,
the RADIUS client and RADIUS target are the same. The shared secret must match the one setup in the
RADIUS client section of the NPS server.
Next steps
Integrate Azure MFA and IIS web apps
Get answers in the Azure Multi-Factor Authentication FAQ
Advanced scenarios with Azure MFA Server and
third-party VPN solutions
Azure Multi-Factor Authentication Server (Azure MFA Server) can be used to seamlessly connect with various
third-party VPN solutions. This article focuses on Cisco® ASA VPN appliance, Citrix NetScaler SSL VPN
appliance, and the Juniper Networks Secure Access/Pulse Secure Connect Secure SSL VPN appliance. We
created configuration guides to address these three common appliances. Azure MFA Server can also integrate
with most other systems that use RADIUS, LDAP, IIS, or claims-based authentication to AD FS. You can find
more details in Azure MFA Server configurations.
IMPORTANT
As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who would like to
require multi-factor authentication from their users should use cloud-based Azure Multi-Factor Authentication. Existing
customers who have activated MFA Server prior to July 1 will be able to download the latest version, future updates and
generate activation credentials as usual.
Cisco ASA VPN appliance and Azure MFA Server

Azure MFA Server integrates with your Cisco® ASA VPN appliance to provide additional security for Cisco
AnyConnect® VPN logins and portal access. You can use either the LDAP or RADIUS protocol. Select one of the
following to download the detailed step-by-step configuration guides.
CONFIGURATION GUIDE DESCRIPTION
Cisco ASA with Anyconnect VPN and Azure MFA Integrate your Cisco ASA VPN appliance with Azure MFA
Configuration for LDAP using LDAP
Cisco ASA with Anyconnect VPN and Azure MFA Integrate your Cisco ASA VPN appliance with Azure MFA
Configuration for RADIUS using RADIUS
Citrix NetScaler SSL VPN and Azure MFA Server

Azure MFA Server integrates with your Citrix NetScaler SSL VPN appliance to provide additional security for
Citrix NetScaler SSL VPN logins and portal access. You can use either the LDAP or RADIUS protocol. Select one
of the following to download the detailed step-by-step configuration guides.
Citrix NetScaler SSL VPN and Azure MFA Configuration for Integrate your Citrix NetScaler SSL VPN with Azure MFA
LDAP appliance using LDAP
Citrix NetScaler SSL VPN and Azure MFA Configuration for Integrate your Citrix NetScaler SSL VPN appliance with Azure
RADIUS MFA using RADIUS
Juniper/Pulse Secure SSL VPN appliance and Azure MFA Server

Azure MFA Server integrates with your Juniper/Pulse Secure SSL VPN appliance to provide additional security
for Juniper/Pulse Secure SSL VPN logins and portal access. You can use either the LDAP or RADIUS protocol.
Select one of the following to download the detailed step-by-step configuration guides.
Juniper/Pulse Secure SSL VPN and Azure MFA Configuration Integrate your Juniper/Pulse Secure SSL VPN with Azure MFA
for LDAP appliance using LDAP
Juniper/Pulse Secure SSL VPN and Azure MFA Configuration Integrate your Juniper/Pulse Secure SSL VPN appliance with
for RADIUS Azure MFA using RADIUS
Next steps
Augment your existing authentication infrastructure with the NPS extension for Azure Multi-Factor
Authentication
Resolve error messages from the NPS extension for
If you encounter errors with the NPS extension for Azure Multi-Factor Authentication, use this article to reach a
resolution faster. NPS extension logs are found in Event Viewer under Custom Views > Server Roles > Network
Policy and Access Services on the server where the NPS Extension is installed.
Troubleshooting steps for common errors

ERROR CODE TROUBLESHOOTING STEPS
CONTACT_SUPPORT Contact support, and mention the list of steps for collecting
logs. Provide as much information as you can about what
happened before the error, including tenant id, and user
principal name (UPN).
CLIENT_CERT_INSTALL_ERROR There may be an issue with how the client certificate was
installed or associated with your tenant. Follow the
instructions in Troubleshooting the MFA NPS extension to
investigate client cert problems.
ESTS_TOKEN_ERROR Follow the instructions in Troubleshooting the MFA NPS

extension to investigate client cert and ADAL token problems.
HTTPS_COMMUNICATION_ERROR The NPS server is unable to receive responses from Azure

MFA. Verify that your firewalls are open bidirectionally for
traffic to and from https://adnotifications.windowsazure.com
HTTP_CONNECT_ERROR On the server that runs the NPS extension, verify that you can
reach https://adnotifications.windowsazure.com and
https://login.microsoftonline.com/. If those sites don't load,
troubleshoot connectivity on that server.
NPS Extension for Azure MFA: This error usually reflects an authentication failure in AD or
NPS Extension for Azure MFA only performs Secondary Auth that the NPS server is unable to receive responses from Azure
for Radius requests in AccessAccept State. Request received for AD. Verify that your firewalls are open bidirectionally for traffic
User username with response state AccessReject, ignoring to and from https://adnotifications.windowsazure.com and
request. https://login.microsoftonline.com using ports 80 and 443. It is
also important to check that on the DIAL-IN tab of Network
Access Permissions, the setting is set to "control access
through NPS Network Policy". This error can also trigger if the
user is not assigned a license.
REGISTRY_CONFIG_ERROR A key is missing in the registry for the application, which may
be because the PowerShell script wasn't run after installation.
The error message should include the missing key. Make sure
you have the key under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureMfa.
REQUEST_FORMAT_ERROR This error usually reflects an installation issue. The NPS

Radius Request missing mandatory Radius userName\Identifier extension must be installed in NPS servers that can receive
attribute.Verify that NPS is receiving RADIUS requests RADIUS requests. NPS servers that are installed as
dependencies for services like RDG and RRAS don't receive
radius requests. NPS Extension does not work when installed
over such installations and errors out since it cannot read the
details from the authentication request.
REQUEST_MISSING_CODE Make sure that the password encryption protocol between the
NPS and NAS servers supports the secondary authentication
method that you're using. PAP supports all the authentication
methods of Azure MFA in the cloud: phone call, one-way text
message, mobile app notification, and mobile app verification
code. CHAPV2 and EAP support phone call and mobile app
notification.
USERNAME_CANONICALIZATION_ERROR Verify that the user is present in your on-premises Active

Directory instance, and that the NPS Service has permissions
to access the directory. If you are using cross-forest trusts,
contact support for further help.
Alternate login ID errors

ERROR CODE ERROR MESSAGE TROUBLESHOOTING STEPS
ALTERNATE_LOGIN_ID_ERROR Error: userObjectSid lookup failed Verify that the user exists in your on-
premises Active Directory instance. If
you are using cross-forest trusts,
ALTERNATE_LOGIN_ID_ERROR Error: Alternate LoginId lookup failed Verify that

LDAP_ALTERNATE_LOGINID_ATTRIBUTE
is set to a valid active directory
attribute.
If LDAP_FORCE_GLOBAL_CATALOG is
set to True, or LDAP_LOOKUP_FORESTS
is configured with a non-empty value,
verify that you have configured a Global
Catalog and that the AlternateLoginId
attribute is added to it.
If LDAP_LOOKUP_FORESTS is
configured with a non-empty value,
verify that the value is correct. If there is
more than one forest name, the names
must be separated with semi-colons,
not spaces.
If these steps don't fix the problem,

contact support for more help.
ALTERNATE_LOGIN_ID_ERROR Error: Alternate LoginId value is empty Verify that the AlternateLoginId
attribute is configured for the user.
Errors your users may encounter

AccessDenied Caller tenant does not have access Check whether the tenant domain and
permissions to do authentication for the the domain of the user principal name
user (UPN) are the same. For example, make
sure that user@contoso.com is trying to
authenticate to the Contoso tenant. The
UPN represents a valid user for the
tenant in Azure.
AuthenticationMethodNotConfigure The specified authentication method Have the user add or verify their
d was not configured for the user verification methods according to the
instructions in Manage your settings for
two-step verification.
AuthenticationMethodNotSupported Specified authentication method is not Collect all your logs that include this
supported. error, and contact support. When you
contact support, provide the username
and the secondary verification method
that triggered the error.
BecAccessDenied MSODS Bec call returned access denied, The user is present in Active Directory
probably the username is not defined in on-premises but is not synced into
the tenant Azure AD by AD Connect. Or, the user
is missing for the tenant. Add the user
to Azure AD and have them add their
verification methods according to the
two-step verification.
InvalidFormat or The phone number is in an Have the user correct their verification
StrongAuthenticationServiceInvalidP unrecognizable format phone numbers.
arameter
InvalidSession The specified session is invalid or may The session has taken more than three
have expired minutes to complete. Verify that the
user is entering the verification code, or
responding to the app notification,
within three minutes of initiating the
authentication request. If that doesn't fix
the problem, check that there are no
network latencies between client, NAS
Server, NPS Server, and the Azure MFA
endpoint.
NoDefaultAuthenticationMethodIsCo No default authentication method was Have the user add or verify their
nfigured configured for the user verification methods according to the
two-step verification. Verify that the
user has chosen a default authentication
method, and configured that method
for their account.
OathCodePinIncorrect Wrong code and pin entered. This error is not expected in the NPS
extension. If your user encounters this,
contact support for troubleshooting
help.
ProofDataNotFound Proof data was not configured for the Have the user try a different verification
specified authentication method. method, or add a new verification
methods according to the instructions
in Manage your settings for two-step
verification. If the user continues to see
this error after you confirmed that their
verification method is set up correctly,
contact support.
SMSAuthFailedWrongCodePinEntere Wrong code and pin entered. This error is not expected in the NPS
d (OneWaySMS) extension. If your user encounters this,
help.
TenantIsBlocked Tenant is blocked Contact support with Directory ID from

the Azure AD properties page in the
Azure portal.
UserNotFound The specified user was not found The tenant is no longer visible as active
in Azure AD. Check that your
subscription is active and you have the
required first party apps. Also make
sure the tenant in the certificate subject
is as expected and the cert is still valid
and registered under the service
principal.
Messages your users may encounter that aren't errors

Sometimes, your users may get messages from Multi-Factor Authentication because their authentication request
failed. These aren't errors in the product of configuration, but are intentional warnings explaining why an
authentication request was denied.
ERROR CODE ERROR MESSAGE RECOMMENDED STEPS
OathCodeIncorrect Wrong code entered\OATH Code The user entered the wrong code. Have
Incorrect them try again by requesting a new
code or signing in again.
SMSAuthFailedMaxAllowedCodeRet Maximum allowed code retry reached The user failed the verification challenge
ryReached too many times. Depending on your
settings, they may need to be
unblocked by an admin now.
SMSAuthFailedWrongCodeEntered Wrong code entered/Text Message OTP The user entered the wrong code. Have
Errors that require support

If you encounter one of these errors, we recommend that you contact support for diagnostic help. There's no
standard set of steps that can address these errors. When you do contact support, be sure to include as much
information as possible about the steps that led to an error, and your tenant information.
ERROR CODE ERROR MESSAGE
InvalidParameter Request must not be null
InvalidParameter ObjectId must not be null or empty for ReplicationScope:{0}
InvalidParameter The length of CompanyName {0}\ is longer than the maximum

allowed length {1}
InvalidParameter UserPrincipalName must not be null or empty
InvalidParameter The provided TenantId is not in correct format
InvalidParameter SessionId must not be null or empty
InvalidParameter Could not resolve any ProofData from request or Msods. The
ProofData is unKnown
InternalError
OathCodePinIncorrect
VersionNotSupported
MFAPinNotSetup
Next steps
Troubleshoot user accounts
If your users are Having trouble with two-step verification, help them self-diagnose problems.
Contact Microsoft support
If you need additional help, contact a support professional through Azure Multi-Factor Authentication Server
support. When contacting us, it's helpful if you can include as much information about your issue as possible.
Information you can supply includes the page where you saw the error, the specific error code, the specific session
ID, the ID of the user who saw the error, and debug logs.
To collect debug logs for support diagnostics, use the following steps on the NPS server:
1. Open Registry Editor and browse to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureMfa set
VERBOSE_LOG to TRUE
2. Open an Administrator command prompt and run these commands:
Mkdir c:\NPS
Cd NPS
netsh trace start Scenario=NetConnection capture=yes tracefile=c:\NPS\nettrace.etl
logman create trace "NPSExtension" -ow -o c:\NPS\NPSExtension.etl -p {7237ED00-E119-430B-AB0F-
C63360C8EE81} 0xffffffffffffffff 0xff -nb 16 16 -bs 1024 -mode Circular -f bincirc -max 4096 -ets
logman update trace "NPSExtension" -p {EC2E6D3A-C958-4C76-8EA4-0262520886FF} 0xffffffffffffffff 0xff -
ets
3. Reproduce the issue

4. Stop the tracing with these commands:
logman stop "NPSExtension" -ets
netsh trace stop
wevtutil epl AuthNOptCh C:\NPS\%computername%_AuthNOptCh.evtx
wevtutil epl AuthZOptCh C:\NPS\%computername%_AuthZOptCh.evtx
wevtutil epl AuthZAdminCh C:\NPS\%computername%_AuthZAdminCh.evtx
Start .

VERBOSE_LOG to FALSE
6. Zip the contents of the C:\NPS folder and attach the zipped file to the support case.
Troubleshoot self-service password reset
Are you having a problem with Azure Active Directory (Azure AD ) self-service password reset (SSPR )? The
information that follows can help you to get things working again.
Troubleshoot self-service password reset errors that a user might see

ERROR DETAILS TECHNICAL DETAILS
TenantSSPRFlagDisabled = 9 We’re sorry, you can't reset your SSPR_0009: We've detected that
password at this time because your password reset has not been enabled
administrator has disabled password by your administrator. Please contact
reset for your organization. There is no your admin and ask them to enable
further action you can take to resolve password reset for your organization.
this situation. Please contact your
admin and ask them to enable this
feature. To learn more, see Help, I
forgot my Azure AD password.
WritebackNotEnabled = 10 We’re sorry, you can't reset your SSPR_0010: We've detected that
password at this time because your password writeback has not been
administrator has not enabled a enabled. Please contact your admin
necessary service for your organization. and ask them to enable password
There is no further action you can take writeback.
to resolve this situation. Please contact
your admin and ask them to check
your organization’s configuration. To
learn more about this necessary
service, see Configuring password
writeback.
SsprNotEnabledInUserPolicy = 11 We’re sorry, you can't reset your SSPR_0011: Your organization has not
password at this time because your defined a password reset policy. Please
administrator has not configured contact your admin and ask them to
password reset for your organization. define a password reset policy.
There is no further action you can take
to resolve this situation. Contact your
admin and ask them to configure
password reset. To learn more about
password reset configuration, see
Quick start: Azure AD self-service
password reset.
UserNotLicensed = 12 We’re sorry, you can't reset your SSPR_0012: Your organization does not
password at this time because required have the required licenses necessary to
licenses are missing from your perform password reset. Please contact
organization. There is no further action your admin and ask them to review the
you can take to resolve this situation. license assignments.
Please contact your admin and ask
them to check your license assignment.
To learn more about licensing, see
Licensing requirements for Azure AD
self-service password reset.
ERROR DETAILS TECHNICAL DETAILS
UserNotMemberOfScopedAccessGroup We’re sorry, you can't reset your SSPR_0013: You are not a member of a
= 13 password at this time because your group enabled for password reset.
administrator has not configured your Contact your admin and request to be
account to use password reset. There is added to the group.
no further action you can take to
resolve this situation. Please contact
your admin and ask them to configure
your account for password reset. To
learn more about account
configuration for password reset, see
Roll out password reset for users.
UserNotProperlyConfigured = 14 We’re sorry, you can't reset your SSPR_0014: Additional security info is
password at this time because needed to reset your password. To
necessary information is missing from proceed, contact your admin and ask
your account. There is no further action them to reset your password. After you
you can take to resolve this situation. have access to your account, you can
Please contact you admin and ask register additional security info at
them to reset your password for you. https://aka.ms/ssprsetup. Your admin
After you have access to your account can add additional security info to your
again, you need to register the account by following the steps in Set
necessary information. To register and read authentication data for
information, follow the steps in the password reset.
article.
OnPremisesAdminActionRequired = 29 We’re sorry, we can't reset your SSPR_0029: We are unable to reset
password at this time because of a your password due to an error in your
problem with your organization’s on-premises configuration. Please
password reset configuration. There is contact your admin and ask them to
no further action you can take to investigate.
resolve this situation. Please contact
your admin and ask them to
investigate. To learn more about the
potential problem, see Troubleshoot
password writeback.
OnPremisesConnectivityError = 30 We’re sorry, we can't reset your SSPR_0030: We can't reset your
password at this time because of password due to a poor connection
connectivity issues to your with your on-premises environment.
organization. There is no action to take Contact your admin and ask them to
right now, but the problem might be investigate.
resolved if you try again later. If the
problem persists, please contact your
admin and ask them to investigate. To
learn more about connectivity issues,
see Troubleshoot password writeback
connectivity.
Troubleshoot the password reset configuration in the Azure portal

ERROR SOLUTION
ERROR SOLUTION
I don't see the Password reset section under Azure AD in This can happen if you don't have an Azure AD license
the Azure portal. assigned to the administrator performing the operation.
Assign a license to the administrator account in question. You

can follow the steps in the Assign, verify, and resolve
problems with licenses article.
I don't see a particular configuration option. Many elements of the UI are hidden until they are needed.
Try enabling all the options you want to see.
I don't see the On-premises integration tab. This option only becomes visible if you have downloaded
Azure AD Connect and have configured password writeback.
For more information, see Getting started with Azure AD
Connect by using the express settings.
Troubleshoot password reset reporting

ERROR SOLUTION
I don’t see any password management activity types in the This can happen if you don't have an Azure AD license
Self-Service Password Management audit event category. assigned to the administrator performing the operation.
You can resolve this problem by assigning a license to the

administrator account in question. Follow the steps in the
Assign, verify, and resolve problems with licenses article.
User registrations show multiple times. Currently, when a user registers, we log each individual piece
of data that's registered as a separate event.
If you want to aggregate this data and have greater flexibility

in how you can view it, you can download the report and
open the data as a pivot table in Excel.
Troubleshoot the password reset registration portal

ERROR SOLUTION
The directory is not enabled for password reset. Your Switch the Self-service password reset enabled flag to
administrator has not enabled you to use this feature. Selected or All and then select Save.
The user does not have an Azure AD license assigned. Your This can happen if you don't have an Azure AD license
administrator has not enabled you to use this feature. assigned to the administrator performing the operation.
You can resolve this problem by assigning a license to the

There is an error processing the request. This can be caused by many issues, but generally this error is
caused by either a service outage or a configuration issue. If
you see this error and it affects your business, contact
Microsoft support for additional assistance.
Troubleshoot the password reset portal

ERROR SOLUTION
The directory is not enabled for password reset. Switch the Self-service password reset enabled flag to
Selected or All and then select Save.
The user does not have an Azure AD license assigned. This can happen if you don't have an Azure AD license
assigned to the administrator performing the operation.
You can resolve this problem if you assign a license to the

The directory is enabled for password reset, but the user has Before proceeding, ensure that user has properly formed
missing or malformed authentication information. contact data on file in the directory. For more information,
see Data used by Azure AD self-service password reset.
The directory is enabled for password reset, but the user has Before proceeding, ensure that the user has at least two
only one piece of contact data on file when the policy is set to properly configured contact methods. An example is having
require two verification methods. both a mobile phone number and an office phone number.
The directory is enabled for password reset and the user is This can be the result of a temporary service error or if there
properly configured, but the user is unable to be contacted. is incorrect contact data that we can't properly detect.
If the user waits 10 seconds, "try again" and "contact your

administrator” links appear. If the user selects "try again," it
retries the call. If the user selects “contact your administrator,”
it sends a form email to their administrators requesting a
password reset to be performed for that user account.
The user never receives the password reset SMS or phone This can be the result of a malformed phone number in the
call. directory. Make sure the phone number is in the format
“+ccc xxxyyyzzzzXeeee”.
Password reset does not support extensions, even if you

specify one in the directory. The extensions are stripped
before the call is dispatched. Use a number without an
extension or integrate the extension into the phone number
in your private branch exchange (PBX).
The user never receives the password reset email. The most common cause for this problem is that the
message is rejected by a spam filter. Check your spam, junk,
or deleted items folder for the email.
Also ensure that you're checking the correct email account for
the message.
I have set a password reset policy, but when an admin Microsoft manages and controls the administrator password
account uses password reset, that policy isn't applied. reset policy to ensure the highest level of security.
ERROR SOLUTION
The user is prevented from attempting a password reset too We implement an automatic throttling mechanism to block
many times in a day. users from attempting to reset their passwords too many
times in a short period of time. Throttling occurs when:
The user attempts to validate a phone number five
times in one hour.
The user attempts to use the security questions gate
five times in one hour.
The user attempts to reset a password for the same
user account five times in one hour.
To fix this problem, instruct the user to wait 24 hours after
the last attempt. The user can then reset their password.
The user sees an error when validating their phone number. This error occurs when the phone number entered does not
match the phone number on file. Make sure the user is
entering the complete phone number, including the area and
country code, when they attempt to use a phone-based
method for password reset.
There is an error processing the request. This can be caused by many issues, but generally this error is
caused by either a service outage or a configuration issue. If
you see this error and it affects your business, contact
Microsoft support for additional assistance.
On-premises policy violation The password does not meet the on-premises Active
Directory password policy.
Password does not comply fuzzy policy The password that was used appears in the banned password
list and may not be used.
Troubleshoot password writeback

ERROR SOLUTION
The password reset service does not start on-premises. Error When password writeback is enabled, the sync engine calls
6800 appears in the Azure AD Connect machine’s application the writeback library to perform the configuration
event log. (onboarding) by communicating to the cloud onboarding
service. Any errors encountered during onboarding or while
After onboarding, federated, pass-through authentication, or starting the Windows Communication Foundation (WCF)
password-hash-synchronized users can't reset their endpoint for password writeback results in errors in the event
passwords. log, on your Azure AD Connect machine.
During restart of the Azure AD Sync (ADSync) service, if

writeback was configured, the WCF endpoint starts up. But, if
the startup of the endpoint fails, we will log event 6800 and
let the sync service start up. The presence of this event
means that the password writeback endpoint did not start
up. Event log details for this event 6800, along with event log
entries generate by the PasswordResetService component,
indicate why you can't start up the endpoint. Review these
event log errors and try to restart the Azure AD Connect if
password writeback still isn’t working. If the problem persists,
try to disable and then re-enable password writeback.
ERROR SOLUTION
When a user attempts to reset a password or unlock an Find the Active Directory account for Azure AD Connect and
account with password writeback enabled, the operation fails. reset the password so that it contains no more than 256
characters. Then open the Synchronization Service from
In addition, you see an event in the Azure AD Connect event the Start menu. Browse to Connectors and find the Active
log that contains: “Synchronization Engine returned an error Directory Connector. Select it and then select Properties.
hr=800700CE, message=The filename or extension is too Browse to the Credentials page and enter the new
long” after the unlock operation occurs. password. Select OK to close the page.
At the last step of the Azure AD Connect installation process, This error occurs in the following two cases:
you see an error indicating that password writeback couldn't You have specified an incorrect password for the
be configured. global administrator account specified at the
beginning of the Azure AD Connect installation
The Azure AD Connect application event log contains error process.
32009 with the text “Error getting auth token.” You have attempted to use a federated user for the
global administrator account specified at the
beginning of the Azure AD Connect installation
process.
To fix this problem, ensure that you're not using a federated
account for the global administrator you specified at the
beginning of the installation process. Also ensure that the
password specified is correct.
The Azure AD Connect machine event log contains error Your on-premises environment isn't able to connect to the
32002 that is thrown by running PasswordResetService. Azure Service Bus endpoint in the cloud. This error is normally
caused by a firewall rule blocking an outbound connection to
The error reads: “Error Connecting to ServiceBus. The token a particular port or web address. See Connectivity
provider was unable to provide a security token.” prerequisites for more info. After you have updated these
rules, reboot the Azure AD Connect machine and password
writeback should start working again.
After working for some time, federated, pass-through In some rare cases, the password writeback service can fail to
authentication, or password-hash-synchronized users can't restart when Azure AD Connect has restarted. In these cases,
reset their passwords. first, check whether password writeback appears to be
enabled on-premises. You can check by using either the
Azure AD Connect wizard or PowerShell (See the previous
HowTos section). If the feature appears to be enabled, try
enabling or disabling the feature again either through the UI
or PowerShell. If this doesn’t work, try a complete uninstall
and reinstall of Azure AD Connect.
Federated, pass-through authentication, or password-hash- If you see these errors in your event log, confirm that the
synchronized users who attempt to reset their passwords see Active Directory Management Agent (ADMA) account that
an error after attempting to submit their password. The error was specified in the wizard at the time of configuration has
indicates that there was a service problem. the necessary permissions for password writeback.
In addition to this problem, during password reset After this permission is given, it can take up to one hour for
operations, you might see an error that the management the permissions to trickle down via the sdprop background
agent was denied access in your on-premises event logs. task on the domain controller (DC).
For password reset to work, the permission needs to be

stamped on the security descriptor of the user object whose
password is being reset. Until this permission shows up on
the user object, password reset continues to fail with an
access denied message.
ERROR SOLUTION
Federated, pass-through authentication, or password-hash- This error usually indicates that the sync engine is unable to
synchronized users who attempt to reset their passwords, see find either the user object in the Azure AD connector space
an error after they submit their password. The error indicates or the linked metaverse (MV) or Azure AD connector space
that there was a service problem. object.
In addition to this problem, during password reset To troubleshoot this problem, make sure that the user is
operations, you might see an error in your event logs from indeed synchronized from on-premises to Azure AD via the
the Azure AD Connect service indicating an “Object could not current instance of Azure AD Connect and inspect the state
be found” error. of the objects in the connector spaces and MV. Confirm that
the Active Directory Certificate Services (AD CS) object is
connected to the MV object via the
“Microsoft.InfromADUserAccountEnabled.xxx” rule.
Federated, pass-through authentication, or password-hash- This indicates that the sync engine detected that the MV
synchronized users who attempt to reset their passwords see object is connected to more than one AD CS object via
an error after they submit their password. The error indicates “Microsoft.InfromADUserAccountEnabled.xxx”. This means
that there was a service problem. that the user has an enabled account in more than one
forest. This scenario isn't supported for password writeback.
In addition to this problem, during password reset
operations, you might see an error in your event logs from
the Azure AD Connect service that indicates that there is a
“Multiple matches found” error.
Password operations fail with a configuration error. The This error occurs if the Azure AD Connect configuration is
application event log contains Azure AD Connect error 6329 changed to add a new Active Directory forest (or to remove
with the text "0x8023061f (The operation failed because and readd an existing forest) after the password writeback
password synchronization is not enabled on this feature has already been enabled. Password operations for
Management Agent)". users in these recently added forests fail. To fix the problem,
disable and then re-enable the password writeback feature
after the forest configuration changes have been completed.
Password writeback event-log error codes

A best practice when you troubleshoot problems with password writeback is to inspect the application event log,
on your Azure AD Connect machine. This event log contains events from two sources of interest for password
writeback. The PasswordResetService source describes operations and problems related to the operation of
password writeback. The ADSync source describes operations and problems related to setting passwords in your
Active Directory environment.
If the source of the event is ADSync
CODE NAME OR MESSAGE DESCRIPTION
6329 BAIL: MMS(4924) 0x80230619: “A This event occurs when the password
restriction prevents the password from writeback service attempts to set a
being changed to the current one password on your local directory that
specified.” does not meet the password age,
history, complexity, or filtering
requirements of the domain.
If you have a minimum password age

and have recently changed the
password within that window of time,
you're not able to change the password
again until it reaches the specified age
in your domain. For testing purposes,
the minimum age should be set to 0.
If you have password history

requirements enabled, then you must
select a password that has not been
used in the last N times, where N is the
password history setting. If you do
select a password that has been used
in the last N times, then you see a
failure in this case. For testing
purposes, the password history should
be set to 0.
If you have password complexity

requirements, all of them are enforced
when the user attempts to change or
reset a password.
If you have password filters enabled

and a user selects a password that
does not meet the filtering criteria,
then the reset or change operation
fails.
6329 MMS(3040): admaexport.cpp(2837): This problem occurs if

The server does not contain the LDAP LDAP_SERVER_POLICY_HINTS_OID
password policy control. control (1.2.840.113556.1.4.2066) isn't
enabled on the DCs. To use the
password writeback feature, you must
enable the control. To do so, the DCs
must be on Windows Server 2008R2 or
later.
HR 8023042 Synchronization Engine returned an This error occurs when the same user
error hr=80230402, message=An ID is enabled in multiple domains. An
attempt to get an object failed because example is if you're syncing account
there are duplicated entries with the and resource forests and have the
same anchor. same user ID present and enabled in
each forest.
This error can also occur if you use a

non-unique anchor attribute, like an
alias or UPN, and two users share that
same anchor attribute.
To resolve this problem, ensure that

you don't have any duplicated users
within your domains and that you use
a unique anchor attribute for each user.
If the source of the event is PasswordResetService

31001 PasswordResetStart This event indicates that the on-

premises service detected a password
reset request for a federated, pass-
through authentication, or password-
hash-synchronized user that originates
from the cloud. This event is the first
event in every password-reset
writeback operation.
31002 PasswordResetSuccess This event indicates that a user selected

a new password during a password-
reset operation. We determined that
this password meets corporate
password requirements. The password
has been successfully written back to
the local Active Directory environment.
31003 PasswordResetFail This event indicates that a user selected

a password and the password arrived
successfully to the on-premises
environment. But when we attempted
to set the password in the local Active
Directory environment, a failure
occurred. This failure can happen for
several reasons:
The user’s password does not
meet the age, history,
complexity, or filter
requirements for the domain. To
resolve this problem, create a
new password.
The ADMA service account
does not have the appropriate
permissions to set the new
password on the user account
in question.
The user’s account is in a
protected group, such as
domain or enterprise admin
group, which disallows
password set operations.
31004 OnboardingEventStart This event occurs if you enable

password writeback with Azure AD
Connect and we have started
onboarding your organization to the
password writeback web service.
31005 OnboardingEventSuccess This event indicates that the

onboarding process was successful and
that the password writeback capability
is ready to use.
31006 ChangePasswordStart This event indicates that the on-

premises service detected a password
change request for a federated, pass-
through authentication, or password-
hash-synchronized user that originates
from the cloud. This event is the first
event in every password-change
writeback operation.
31007 ChangePasswordSuccess This event indicates that a user selected

a new password during a password
change operation, we determined that
the password meets corporate
password requirements, and that the
password has been successfully written
back to the local Active Directory
environment.
31008 ChangePasswordFail This event indicates that a user selected

a password and that the password
arrived successfully to the on-premises
environment, but when we attempted
several reasons:
requirements for the domain. To
resolve this problem, create a
new password.
in question.
domain or enterprise admins,
which disallows password set
operations.
31009 ResetUserPasswordByAdminStart The on-premises service detected a

password reset request for a federated,
pass-through authentication, or
password-hash-synchronized user
originating from the administrator on
behalf of a user. This event is the first
event in every password-reset
writeback operation that is initiated by
an administrator.
31010 ResetUserPasswordByAdminSuccess The admin selected a new password

during an admin-initiated password-
reset operation. We determined that
this password meets corporate
password requirements. The password
has been successfully written back to
the local Active Directory environment.
31011 ResetUserPasswordByAdminFail The admin selected a password on

behalf of a user. The password arrived
successfully to the on-premises
environment. But when we attempted
several reasons:
requirements for the domain.
Try a new password to resolve
this problem.
in question.
domain or enterprise admins,
which disallows password set
operations.
31012 OffboardingEventStart This event occurs if you disable

password writeback with Azure AD
Connect and indicates that we started
offboarding your organization to the
password writeback web service.
31013 OffboardingEventSuccess This event indicates that the

offboarding process was successful and
that password writeback capability has
been successfully disabled.
31014 OffboardingEventFail This event indicates that the

offboarding process was not successful.
This might be due to a permissions
error on the cloud or on-premises
administrator account specified during
configuration. The error can also occur
if you're attempting to use a federated
cloud global administrator when
disabling password writeback. To fix
this problem, check your administrative
permissions and ensure that you're not
using a federated account while
configuring the password writeback
capability.
31015 WriteBackServiceStarted This event indicates that the password

writeback service has started
successfully. It is ready to accept
password management requests from
the cloud.
31016 WriteBackServiceStopped This event indicates that the password

writeback service has stopped. Any
password management requests from
the cloud will not be successful.
31017 AuthTokenSuccess This event indicates that we

successfully retrieved an authorization
token for the global admin specified
during Azure AD Connect setup to
start the offboarding or onboarding
process.
31018 KeyPairCreationSuccess This event indicates that we

successfully created the password
encryption key. This key is used to
encrypt passwords from the cloud to
be sent to your on-premises
environment.
32000 UnknownError This event indicates an unknown error

occurred during a password
management operation. Look at the
exception text in the event for more
details. If you're having problems, try
disabling and then re-enabling
password writeback. If this does not
help, include a copy of your event log
along with the tracking ID specified
insider to your support engineer.
32001 ServiceError This event indicates there was an error

connecting to the cloud password reset
service. This error generally occurs
when the on-premises service was
unable to connect to the password-
reset web service.
32002 ServiceBusError This event indicates there was an error

connecting to your tenant’s Service Bus
instance. This can happen if you're
blocking outbound connections in your
on-premises environment. Check your
firewall to ensure that you allow
connections over TCP 443 and to
https://ssprsbprodncu-
sb.accesscontrol.windows.net/, and
then try again. If you're still having
problems, try disabling and then re-
enabling password writeback.
32003 InPutValidationError This event indicates that the input

passed to our web service API was
invalid. Try the operation again.
32004 DecryptionError This event indicates that there was an

error decrypting the password that
arrived from the cloud. This might be
due to a decryption key mismatch
between the cloud service and your
on-premises environment. To resolve
this problem, disable and then re-
enable password writeback in your on-
premises environment.
32005 ConfigurationError During onboarding, we save tenant-

specific information in a configuration
file in your on-premises environment.
This event indicates that there was an
error saving this file or that when the
service was started, there was an error
reading the file. To fix this problem, try
password writeback to force a rewrite
of the configuration file.
32007 OnBoardingConfigUpdateError During onboarding, we send data from

the cloud to the on-premises
password-reset service. That data is
then written to an in-memory file
before it is sent to the sync service to
be stored securely on disk. This event
indicates that there is a problem with
writing or updating that data in
memory. To fix this problem, try
password writeback to force a rewrite
of this configuration file.
32008 ValidationError This event indicates we received an

invalid response from the password-
reset web service. To fix this problem,
try disabling and then re-enabling
password writeback.
32009 AuthTokenError This event indicates that we couldn't

get an authorization token for the
global administrator account specified
during Azure AD Connect setup. This
error can be caused by a bad username
or password specified for the global
admin account. This error can also
occur if the global admin account
specified is federated. To fix this
problem, rerun the configuration with
the correct username and password
and ensure that the administrator is a
managed (cloud-only or password-
synchronized) account.
32010 CryptoError This event indicates there was an error

generating the password encryption
key or decrypting a password that
arrives from the cloud service. This
error likely indicates a problem with
your environment. Look at the details
of your event log to learn more about
how to resolve this problem. You can
also try disabling and then re-enabling
the password writeback service.
32011 OnBoardingServiceError This event indicates that the on-

premises service couldn't properly
communicate with the password-reset
web service to initiate the onboarding
process. This can happen as a result of
a firewall rule or if there is a problem
getting an authentication token for
your tenant. To fix this problem, ensure
that you're not blocking outbound
connections over TCP 443 and TCP
9350-9354 or to
sb.accesscontrol.windows.net/. Also
ensure that the Azure AD admin
account you're using to onboard isn't
federated.
32013 OffBoardingError This event indicates that the on-

premises service couldn't properly
communicate with the password-reset
web service to initiate the offboarding
process. This can happen as a result of
a firewall rule or if there is a problem
getting an authorization token for your
tenant. To fix this problem, ensure that
you're not blocking outbound
connections over 443 or to
sb.accesscontrol.windows.net/, and that
the Azure Active Directory admin
account you're using to offboard isn't
federated.
32014 ServiceBusWarning This event indicates that we had to

retry to connect to your tenant’s
Service Bus instance. Under normal
conditions, this should not be a
concern, but if you see this event many
times, consider checking your network
connection to Service Bus, especially if
it’s a high-latency or low-bandwidth
connection.
32015 ReportServiceHealthError In order to monitor the health of your

password writeback service, we send
heartbeat data to our password-reset
web service every five minutes. This
event indicates that there was an error
when sending this health information
back to the cloud web service. This
health information does not include an
object identifiable information (OII) or
personally identifiable information (PII)
data, and is purely a heartbeat and
basic service statistics so that we can
provide service status information in
the cloud.
33001 ADUnKnownError This event indicates that there was an

unknown error returned by Active
Directory. Check the Azure AD Connect
server event log for events from the
ADSync source for more information.
33002 ADUserNotFoundError This event indicates that the user who

is trying to reset or change a password
was not found in the on-premises
directory. This error can occur when the
user has been deleted on-premises but
not in the cloud. This error can also
occur if there is a problem with sync.
Check your sync logs and the last few
sync run details for more information.
33003 ADMutliMatchError When a password reset or change

request originates from the cloud, we
use the cloud anchor specified during
the setup process of Azure AD Connect
to determine how to link that request
back to a user in your on-premises
environment. This event indicates that
we found two users in your on-
premises directory with the same cloud
anchor attribute. Check your sync logs
and the last few sync run details for
more information.
33004 ADPermissionsError This event indicates that the Active

Directory Management Agent (ADMA)
service account does not have the
appropriate permissions on the
account in question to set a new
password. Ensure that the ADMA
account in the user’s forest has reset
and change password permissions on
all objects in the forest. For more
information on how to set the
permissions, see Step 4: Set up the
appropriate Active Directory
permissions.
33005 ADUserAccountDisabled This event indicates that we attempted

to reset or change a password for an
account that was disabled on-premises.
Enable the account and try the
operation again.
33006 ADUserAccountLockedOut This event indicates that we attempted

to reset or change a password for an
account that was locked out on-
premises. Lockouts can occur when a
user has tried a change or reset
password operation too many times in
a short period. Unlock the account and
try the operation again.
33007 ADUserIncorrectPassword This event indicates that the user

specified an incorrect current password
when performing a password change
operation. Specify the correct current
password and try again.
33008 ADPasswordPolicyError This event occurs when the password

writeback service attempts to set a
password on your local directory that
does not meet the password age,
history, complexity, or filtering
requirements of the domain.
If you have a minimum password age

and have recently changed the
password within that window of time,
you're not able to change the password
again until it reaches the specified age
in your domain. For testing purposes,
the minimum age should be set to 0.
If you have password history

requirements enabled, then you must
select a password that has not been
used in the last N times, where N is the
password history setting. If you do
select a password that has been used
in the last N times, then you see a
failure in this case. For testing
purposes, the password history should
be set to 0.
If you have password complexity

requirements, all of them are enforced
when the user attempts to change or
reset a password.
If you have password filters enabled

and a user selects a password that
does not meet the filtering criteria,
then the reset or change operation
fails.
33009 ADConfigurationError This event indicates there was a

problem writing a password back to
your on-premises directory because of
a configuration issue with Active
Directory. Check the Azure AD Connect
machine’s application event log for
messages from the ADSync service for
more information on which error
occurred.
Troubleshoot password writeback connectivity

If you're experiencing service interruptions with the password writeback component of Azure AD Connect, here
are some quick steps you can take to resolve this problem:
Confirm network connectivity
Restart the Azure AD Connect Sync service
Disable and re-enable the password writeback feature
Install the latest Azure AD Connect release
Troubleshoot password writeback
In general, to recover your service in the most rapid manner, we recommend that you execute these steps in the
order discussed previously.
Confirm network connectivity
The most common point of failure is that firewall and or proxy ports and idle timeouts are incorrectly configured.
For Azure AD Connect version 1.1.443.0 and above, you need outbound HTTPS access to the following:
*.passwordreset.microsoftonline.com
*.servicebus.windows.net
For more granularity, reference the updated list of Microsoft Azure Datacenter IP Ranges updated every
Wednesday and put into effect the next Monday.
For more information, review the connectivity prerequisites in the Prerequisites for Azure AD Connect article.
Restart the Azure AD Connect Sync service
To resolve connectivity problems or other transient problems with the service, restart the Azure AD Connect Sync
service:
1. As an administrator, select Start on the server running Azure AD Connect.
2. Enter services.msc in the search field and select Enter.
3. Look for the Microsoft Azure AD Sync entry.
4. Right-click the service entry, select Restart, and then wait for the operation to finish.
These steps re-establish your connection with the cloud service and resolve any interruptions you might be
experiencing. If restarting the ADSync service does not resolve your problem, we recommend that you try to
disable and then re-enable the password writeback feature.
Disable and re -enable the password writeback feature
To resolve connectivity issues, disable and then re-enable the password writeback feature:
1. As an administrator, open the Azure AD Connect Configuration wizard.
2. In Connect to Azure AD, enter your Azure AD global admin credentials.
3. In Connect to AD DS, enter your AD Domain Services admin credentials.
4. In Uniquely identifying your users, select the Next button.
5. In Optional features, clear the Password writeback check box.
6. Select Next through the remaining dialog pages without changing anything until you get to the Ready to
configure page.
7. Ensure that the Ready to configure page shows the Password writeback option as disabled and then
select the green Configure button to commit your changes.
8. In Finished, clear the Synchronize now option, and then select Finish to close the wizard.
9. Reopen the Azure AD Connect Configuration wizard.
10. Repeat steps 2-8, except ensure you select the Password writeback option on the Optional features page to
re-enable the service.
These steps re-establish your connection with our cloud service and resolve any interruptions you might be
experiencing.
If disabling and then re-enabling the password writeback feature does not resolve your problem, we recommend
that you reinstall Azure AD Connect.
Install the latest Azure AD Connect release
Reinstalling Azure AD Connect can resolve configuration and connectivity issues between our cloud services and
your local Active Directory environment.
We recommend that you perform this step only after you attempt the first two steps previously described.
WARNING
If you have customized the out-of-the-box sync rules, back them up before proceeding with upgrade and then manually
redeploy them after you're finished.
1. Download the latest version of Azure AD Connect from the Microsoft Download Center.
2. Because you have already installed Azure AD Connect, you need to perform an in-place upgrade to update
your Azure AD Connect installation to the latest version.
3. Execute the downloaded package and follow the on-screen instructions to update your Azure AD Connect
machine.
The previous steps should re-establish your connection with our cloud service and resolve any interruptions you
might be experiencing.
If installing the latest version of the Azure AD Connect server does not resolve your problem, we recommend
that you try disabling and then re-enabling password writeback as a final step after you install the latest release.
Verify that Azure AD Connect has the required permission for

password writeback
Azure AD Connect requires Active Directory Reset password permission to perform password writeback. To find
out if Azure AD Connect has the required permission for a given on-premises Active Directory user account, you
can use the Windows Effective Permission feature:
1. Sign in to the Azure AD Connect server and start the Synchronization Service Manager by selecting
Start > Synchronization Service.
2. Under the Connectors tab, select the on-premises Active Directory Domain Services connector, and
then select Properties.
3. In the pop-up window, select Connect to Active Directory Forest and make note of the User name
property. This property is the AD DS account used by Azure AD Connect to perform directory
synchronization. For Azure AD Connect to perform password writeback, the AD DS account must have
reset password permission.
4. Sign in to an on-premises domain controller and start the Active Directory Users and Computers
application.
5. Select View and make sure the Advanced Features option is enabled.
6. Look for the Active Directory user account you want to verify. Right-click the account name and select
Properties.
7. In the pop-up window, go to the Security tab and select Advanced.
8. In the Advanced Security Settings for Administrator pop-up window, go to the Effective Access tab.
9. Select Select a user, select the AD DS account used by Azure AD Connect (see step 3), and then select
View effective access.
10. Scroll down and look for Reset password. If the entry has a check mark, the AD DS account has
permission to reset the password of the selected Active Directory user account.
Azure AD forums
If you have a general question about Azure AD and self-service password reset, you can ask the community for
assistance on the Azure AD forums. Members of the community include engineers, product managers, MVPs,
and fellow IT professionals.

If you can't find the answer to a problem, our support teams are always available to assist you further.
To properly assist you, we ask that you provide as much detail as possible when opening a case. These details
include:
General description of the error: What is the error? What was the behavior that was noticed? How can
we reproduce the error? Provide as much detail as possible.
Page: What page were you on when you noticed the error? Include the URL if you're able to and a
screenshot of the page.
Support code: What was the support code that was generated when the user saw the error?
To find this code, reproduce the error, then select the Support code link at the bottom of the screen
and send the support engineer the GUID that results.
If you're on a page without a support code at the bottom, select F12 and search for the SID and CID
and send those two results to the support engineer.
Date, time, and time zone: Include the precise date and time with the time zone that the error occurred.
User ID: Who was the user who saw the error? An example is user@contoso.com.
Is this a federated user?
Is this a pass-through authentication user?
Is this a password-hash-synchronized user?
Is this a cloud-only user?
Licensing: Does the user have an Azure AD license assigned?
Application event log: If you're using password writeback and the error is in your on-premises
infrastructure, include a zipped copy of your application event log from the Azure AD Connect server.
Next steps
The following articles provide additional information about password reset through Azure AD:
Password management frequently asked questions
The following are some frequently asked questions (FAQ ) for all things related to password reset.
If you have a general question about Azure Active Directory (Azure AD ) and self-service password reset (SSPR )
that's not answered here, you can ask the community for assistance on the Azure AD forum. Members of the
community include engineers, product managers, MVPs, and fellow IT professionals.
This FAQ is split into the following sections:
Questions about password reset registration
Questions about password reset
Questions about password change
Questions about password management reports
Questions about password writeback
Password reset registration

Q: Can my users register their own password reset data?
A: Yes. As long as password reset is enabled and they are licensed, users can go to the password reset
registration portal (https://aka.ms/ssprsetup) to register their authentication information. Users can
also register through the Access Panel (https://myapps.microsoft.com). To register through the Access
Panel, they need to select their profile picture, select Profile, and then select the Register for
password reset option.
Q: If I enable password reset for a group and then decide to enable it for everyone are my users
required re-register?
A: No. Users who have populated authentication data are not required to re-register.
Q: Can I define password reset data on behalf of my users?
A: Yes, you can do so with Azure AD Connect, PowerShell, the Azure portal, or the Microsoft 365
admin center. For more information, see Data used by Azure AD self-service password reset.
Q: Can I synchronize data for security questions from on-premises?
A: No, this is not possible today.
Q: Can my users register data in such a way that other users can't see this data?
A: Yes. When users register data by using the password reset registration portal, the data is saved into
private authentication fields that are visible only to global administrators and the user.
Q: Do my users have to be registered before they can use password reset?
A: No. If you define enough authentication information on their behalf, users don't have to register.
Password reset works as long as you have properly formatted the data stored in the appropriate fields
in the directory.
Q: Can I synchronize or set the authentication phone, authentication email, or alternate

authentication phone fields on behalf of my users?
A: The fields that are able to be set by a Global Administrator are defined in the article SSPR Data
requirements.
Q: How does the registration portal determine which options to show my users?
A: The password reset registration portal shows only the options that you have enabled for your users.
These options are found under the User Password Reset Policy section of your directory’s
Configure tab. For example, if you don't enable security questions, then users are not able to register
for that option.
Q: When is a user considered registered?
A: A user is considered registered for SSPR when they have registered at least the Number of
methods required to reset a password that you have set in the Azure portal.
Password reset
Q: Do you prevent users from multiple attempts to reset a password in a short period of time?
A: Yes, there are security features built into password reset to protect it from misuse.
Users can try only five password reset attempts within a 24 hour period before they're locked out for
24 hours.
Users can try to validate a phone number, send a SMS, or validate security questions and answers only
five times within an hour before they're locked out for 24 hours.
Users can send an email a maximum of 10 times within a 10 minute period before they're locked out
for 24 hours.
The counters are reset once a user resets their password.
Q: How long should I wait to receive an email, SMS, or phone call from password reset?
A: Emails, SMS messages, and phone calls should arrive in under a minute. The normal case is 5 to 20
seconds. If you don't receive the notification in this time frame:
Check your junk folder.
Check that the number or email being contacted is the one you expect.
Check that the authentication data in the directory is correctly formatted, for example, +1
4255551234 or user@contoso.com.
Q: What languages are supported by password reset?
A: The password reset UI, SMS messages, and voice calls are localized in the same languages that are
supported in Office 365.
Q: What parts of the password reset experience get branded when I set the organizational
branding items in my directory’s configure tab?
A: The password reset portal shows your organization's logo and allows you to configure the "Contact
your administrator" link to point to a custom email or URL. Any email that's sent by password reset
includes your organization’s logo, colors, and name in the body of the email, and is customized from
the settings for that particular name.
Q: How can I educate my users about where to go to reset their passwords?
A: Try some of the suggestions in our SSPR deployment article.
Q: Can I use this page from a mobile device?
A: Yes, this page works on mobile devices.
Q: Do you support unlocking local Active Directory accounts when users reset their passwords?
A: Yes. When a user resets their password, if password writeback has been deployed through Azure
AD Connect, that user’s account is automatically unlocked when they reset their password.
Q: How can I integrate password reset directly into my user’s desktop sign-in experience?
A: If you're an Azure AD Premium customer, you can install Microsoft Identity Manager at no
additional cost and deploy the on-premises password reset solution.
Q: Can I set different security questions for different locales?
A: No, this is not possible today.
Q: How many questions can I configure for the security questions authentication option?
A: You can configure up to 20 custom security questions in the Azure portal.
Q: How long can security questions be?
A: Security questions can be 3 to 200 characters long.
Q: How long can the answers to security questions be?
A: Answers can be 3 to 40 characters long.
Q: Are duplicate answers to security questions rejected?
A: Yes, we reject duplicate answers to security questions.
Q: Can a user register the same security question more than once?
A: No. After a user registers a particular question, they can't register for that question a second time.
Q: Is it possible to set a minimum limit of security questions for registration and reset?
A: Yes, one limit can be set for registration and another for reset. Three to five security questions can
be required for registration, and three to five questions can be required for reset.
Q: I configured my policy to require users to use security questions for reset, but the Azure
administrators seem to be configured differently.
A: This is the expected behavior. Microsoft enforces a strong default two-gate password reset policy
for any Azure administrator role. This prevents administrators from using security questions. You can
find more information about this policy in the Password policies and restrictions in Azure Active
Directory article.
Q: If a user has registered more than the maximum number of questions required to reset, how
are the security questions selected during reset?
A: N number of security questions are selected at random out of the total number of questions a user
has registered for, where N is the amount that is set for the Number of questions required to reset
option. For example, if a user has registered five security questions, but only three are required to reset
a password, three of the five questions are randomly selected and are presented at reset. To prevent
question hammering, if the user gets the answers to the questions wrong the selection process starts
over.
Q: How long are the email and SMS one-time passcodes valid?
A: The session lifetime for password reset is 15 minutes. From the start of the password reset
operation, the user has 15 minutes to reset their password. The email and SMS one-time passcode are
invalid after this time period expires.
Q: Can I block users from resetting their password?
A: Yes, if you use a group to enable SSPR, you can remove an individual user from the group that
allows users to reset their password. If the user is a Global Administrator they will retain the ability to
reset their password and this cannot be disabled.
Password change
Q: Where should my users go to change their passwords?
A: Users can change their passwords anywhere they see their profile picture or icon, like in the upper-
right corner of their Office 365 portal or Access Panel experiences. Users can change their passwords
from the Access Panel Profile page. Users can also be asked to change their passwords automatically
at the Azure AD sign-in page if their passwords have expired. Finally, users can browse to the Azure
AD password change portal directly if they want to change their passwords.
Q: Can my users be notified in the Office portal when their on-premises password expires?
A: Yes, this is possible today if you use Active Directory Federation Services (AD FS ). If you use AD FS,
follow the instructions in the Sending password policy claims with AD FS article. If you use password
hash synchronization, this is not possible today. We don't sync password policies from on-premises
directories, so it's not possible for us to post expiration notifications to cloud experiences. In either
case, it's also possible to notify users whose passwords are about to expire through PowerShell.
Q: Can I block users from changing their password?

A: For cloud-only users, password changes can't be blocked. For on-premises users, you can set the
User cannot change password option to selected. The selected users can't change their password.
Password management reports

Q: How long does it take for data to show up on the password management reports?
A: Data should appear on the password management reports in 5 to 10 minutes. In some instances, it
might take up to an hour to appear.
Q: How can I filter the password management reports?
A: To filter the password management reports, select the small magnifying glass to the extreme right
of the column labels, near the top of the report. If you want to do richer filtering, you can download the
report to Excel and create a pivot table.
Q: What is the maximum number of events that are stored in the password management
reports?
A: Up to 75,000 password reset or password reset registration events are stored in the password
management reports, spanning back as far as 30 days. We are working to expand this number to
include more events.
Q: How far back do the password management reports go?
A: The password management reports show operations that occurred within the last 30 days. For now,
if you need to archive this data, you can download the reports periodically and save them in a separate
location.
Q: Is there a maximum number of rows that can appear on the password management reports?
A: Yes. A maximum of 75,000 rows can appear on either of the password management reports,
whether they are shown in the UI or are downloaded.
Q: Is there an API to access the password reset or registration reporting data?
A: Yes. To learn how you can access the password reset reporting data stream, see Learn how to access
password reset reporting events programmatically.
Password writeback
Q: How does password writeback work behind the scenes?
A: See the article How password writeback works for an explanation of what happens when you
enable password writeback and how data flows through the system back into your on-premises
environment.
Q: How long does password writeback take to work? Is there a synchronization delay like there is
with password hash sync?
A: Password writeback is instant. It is a synchronous pipeline that works fundamentally differently

than password hash synchronization. Password writeback allows users to get real-time feedback about
the success of their password reset or change operation. The average time for a successful writeback
of a password is under 500 ms.
Q: If my on-premises account is disabled, how is my cloud account and access affected?
A: If your on-premises ID is disabled, your cloud ID and access will also be disabled at the next sync
interval through Azure AD Connect. By default, this sync is every 30 minutes.
Q: If my on-premises account is constrained by an on-premises Active Directory password

policy, does SSPR obey this policy when I change my password?
A: Yes, SSPR relies on and abides by the on-premises Active Directory password policy. This policy
includes the typical Active Directory domain password policy, as well as any defined, fine-grained
password policies that are targeted to a user.
Q: What types of accounts does password writeback work for?
A: Password writeback works for user accounts that are synchronized from on-premises Active
Directory to Azure AD, including federated, password hash synchronized, and Pass-Through
Autentication Users.
Q: Does password writeback enforce my domain’s password policies?
A: Yes. Password writeback enforces password age, history, complexity, filters, and any other restriction
you might put in place on passwords in your local domain.
Q: Is password writeback secure? How can I be sure I won’t get hacked?
A: Yes, password writeback is secure. To read more about the multiple layers of security implemented
by the password writeback service, check out the Password writeback security section in the Password
writeback overview article.
Next steps
Frequently asked questions about Azure Multi-Factor
Authentication
This FAQ answers common questions about Azure Multi-Factor Authentication and using the Multi-Factor
Authentication service. It's broken down into questions about the service in general, billing models, user
experiences, and troubleshooting.
General
Q: How does Azure Multi-Factor Authentication Server handle user data?
With Multi-Factor Authentication Server, user data is stored only on the on-premises servers. No persistent user
data is stored in the cloud. When the user performs two-step verification, Multi-Factor Authentication Server
sends data to the Azure Multi-Factor Authentication cloud service for authentication. Communication between
Multi-Factor Authentication Server and the Multi-Factor Authentication cloud service uses Secure Sockets Layer
(SSL ) or Transport Layer Security (TLS ) over port 443 outbound.
When authentication requests are sent to the cloud service, data is collected for authentication and usage reports.
Data fields included in two-step verification logs are as follows:
Unique ID (either user name or on-premises Multi-Factor Authentication Server ID )
First and Last Name (optional)
Email Address (optional)
Phone Number (when using a voice call or SMS authentication)
Device Token (when using mobile app authentication)
Authentication Mode
Authentication Result
Multi-Factor Authentication Server Name
Multi-Factor Authentication Server IP
Client IP (if available)
The optional fields can be configured in Multi-Factor Authentication Server.
The verification result (success or denial), and the reason if it was denied, is stored with the authentication data.
This data is available in authentication and usage reports.
Q: What SMS short codes are used for sending SMS messages to my users?
In the United States Microsoft uses the following SMS short codes:
97671
69829
51789
99399
In Canada Microsoft uses the following SMS short codes:
759731
673801
Microsoft does not guarantee consistent SMS or Voice-based Multi-Factor Authentication prompt delivery by the
same number. In the interest of our users, Microsoft may add or remove Short codes at any time as we make
route adjustments to improve SMS deliverability. Microsoft does not support short codes for countries/regions
besides the United States and Canada.
Billing
Most billing questions can be answered by referring to either the Multi-Factor Authentication Pricing page or the
documentation about How to get Azure Multi-Factor Authentication.
Q: Is my organization charged for sending the phone calls and text messages that are used for
authentication?
No, you are not charged for individual phone calls placed or text messages sent to users through Azure Multi-
Factor Authentication. If you use a per-authentication MFA provider, you are billed for each authentication but not
for the method used.
Your users might be charged for the phone calls or text messages they receive, according to their personal phone
service.
Q: Does the per-user billing model charge me for all enabled users, or just the ones that performed two-
step verification?
Billing is based on the number of users configured to use Multi-Factor Authentication, regardless of whether they
performed two-step verification that month.
Q: How does Multi-Factor Authentication billing work?
When you create a per-user or per-authentication MFA provider, your organization's Azure subscription is billed
monthly based on usage. This billing model is similar to how Azure bills for usage of virtual machines and
websites.
When you purchase a subscription for Azure Multi-Factor Authentication, your organization only pays the annual
license fee for each user. MFA licenses and Office 365, Azure AD Premium, or Enterprise Mobility + Security
bundles are billed this way.
Learn more about your options in How to get Azure Multi-Factor Authentication.
Q: Is there a free version of Azure Multi-Factor Authentication?
Multi-Factor Authentication for Azure Administrators offers a subset of Azure MFA features at no cost for access
to Microsoft online services, including the Azure portal and Microsoft 365 admin center. This offer only applies to
global administrators in Azure Active Directory instances that don't have the full version of Azure MFA through an
MFA license, a bundle, or a standalone consumption-based provider. If your admins use the free version, and then
you purchase a full version of Azure MFA, then all global administrators are elevated to the paid version
automatically.
Multi-Factor Authentication for Office 365 users offers a subset of Azure MFA features at no cost for access to
Office 365 services, including Exchange Online and SharePoint Online. This offer applies to users who have an
Office 365 license assigned, when the corresponding instance of Azure Active Directory doesn't have the full
version of Azure MFA through an MFA license, a bundle, or a standalone consumption-based provider.
Q: Can my organization switch between per-user and per-authentication consumption billing models at
any time?
If your organization purchases MFA as a standalone service with consumption-based billing, you choose a billing
model when you create an MFA provider. You cannot change the billing model after an MFA provider is created.
AD tenant, user settings and configuration options are not transferred. Also, existing Azure MFA Servers need to
be reactivated using activation credentials generated through the new MFA Provider. Reactivating the MFA
Servers to link them to the new MFA Provider doesn't impact phone call and text message authentication, but
mobile app notifications will stop working for all users until they reactivate the mobile app.
Learn more about MFA providers in Getting started with an Azure Multi-Factor Auth Provider.
Q: Can my organization switch between consumption-based billing and subscriptions (a license-based
model) at any time?
If your directory has a per-user Azure Multi-Factor Authentication provider, you can add MFA licenses. Users with
licenses aren't be counted in the per-user consumption-based billing. Users without licenses can still be enabled
for MFA through the MFA provider. If you purchase and assign licenses for all your users configured to use Multi-
Factor Authentication, you can delete the Azure Multi-Factor Authentication provider. You can always create
another per-user MFA provider if you have more users than licenses in the future.
If your directory has a per-authentication Azure Multi-Factor Authentication provider, you are always billed for
each authentication, as long as the MFA provider is linked to your subscription. You can assign MFA licenses to
users, but you'll still be billed for every two-step verification request, whether it comes from someone with an
MFA license assigned or not.
Q: Does my organization have to use and synchronize identities to use Azure Multi-Factor
Authentication?
If your organization uses a consumption-based billing model, Azure Active Directory is optional, but not required.
If your MFA provider is not linked to an Azure AD tenant, you can only deploy Azure Multi-Factor Authentication
Server on-premises.
Azure Active Directory is required for the license model because licenses are added to the Azure AD tenant when
you purchase and assign them to users in the directory.
Manage and support user accounts

Q: What should I tell my users to do if they don’t receive a response on their phone?
Have your users attempt up to 5 times in 5 minutes to get a phone call or SMS for authentication. Microsoft uses
multiple providers for delivering calls and SMS messages. If this doesn't work please open a support case with
Microsoft to further troubleshoot.
If the steps above do not work hopefully all your users configured more than one verification method. Tell them to
try signing in again, but select a different verification method on the sign-in page.
You can point your users to the End-user troubleshooting guide.
Q: What should I do if one of my users can't get in to their account?
You can reset the user's account by making them to go through the registration process again. Learn more about
managing user and device settings with Azure Multi-Factor Authentication in the cloud.
Q: What should I do if one of my users loses a phone that is using app passwords?
To prevent unauthorized access, delete all the user's app passwords. After the user has a replacement device, they
can recreate the passwords. Learn more about managing user and device settings with Azure Multi-Factor
Authentication in the cloud.
Q: What if a user can't sign in to non-browser apps?
If your organization still uses legacy clients, and you allowed the use of app passwords, then your users can't sign
in to these legacy clients with their username and password. Instead, they need to set up app passwords. Your
users must clear (delete) their sign-in information, restart the app, and then sign in with their username and app
password instead of their regular password.
If your organization doesn't have legacy clients, you should not allow your users to create app passwords.
NOTE
Modern authentication for Office 2013 clients
App passwords are only necessary for apps that don't support modern authentication. Office 2013 clients support modern
authentication protocols, but need to be configured. Now modern authentication is available to any customer running the
March 2015 or later update for Office 2013. For more information, see the blog post Updated Office 365 modern
authentication.
Q: My users say that sometimes they don't receive the text message, or they reply to two-way text
messages but the verification times out.
Delivery of text messages and receipt of replies in two-way SMS are not guaranteed because there are
uncontrollable factors that might affect the reliability of the service. These factors include the destination
country/region, the mobile phone carrier, and the signal strength.
If your users often have problems with reliably receiving text messages, tell them to use the mobile app or phone
call method instead. The mobile app can receive notifications both over cellular and Wi-Fi connections. In addition,
the mobile app can generate verification codes even when the device has no signal at all. The Microsoft
Authenticator app is available for Android, IOS, and Windows Phone.
If you must use text messages, we recommend using one-way SMS rather than two-way SMS when possible.
One-way SMS is more reliable and it prevents users from incurring global SMS charges from replying to a text
message that was sent from another country/region.
Q: Can I change the amount of time my users have to enter the verification code from a text message
before the system times out?
In some cases, yes.
For one-way SMS with Azure MFA Server v7.0 or higher, you can configure the timeout setting by setting a
registry key. After the MFA cloud service sends the text message, the verification code (or one-time passcode) is
returned to the MFA Server. The MFA Server stores the code in memory for 300 seconds by default. If the user
doesn't enter the code before the 300 seconds have passed, their authentication is denied. Use these steps to
change the default timeout setting:
1. Go to HKLM\Software\Wow6432Node\Positive Networks\PhoneFactor.
2. Create a DWORD registry key called pfsvc_pendingSmsTimeoutSeconds and set the time in seconds that
you want the Azure MFA Server to store one-time passcodes.
TIP
If you have multiple MFA Servers, only the one that processed the original authentication request knows the verification
code that was sent to the user. When the user enters the code, the authentication request to validate it must be sent to the
same server. If the code validation is sent to a different server, the authentication is denied.
For two-way SMS with Azure MFA Server, you can configure the timeout setting in the MFA Management Portal.
If users don't respond to the SMS within the defined timeout period, their authentication is denied.
For one-way SMS with Azure MFA in the cloud (including the AD FS adapter or the Network Policy Server
extension), you cannot configure the timeout setting. Azure AD stores the verification code for 180 seconds.
Q: Can I use hardware tokens with Azure Multi-Factor Authentication Server?
If you are using Azure Multi-Factor Authentication Server, you can import third-party Open Authentication
(OATH) time-based, one-time password (TOTP ) tokens, and then use them for two-step verification.
You can use ActiveIdentity tokens that are OATH TOTP tokens if you put the secret key in a CSV file and import to
Azure Multi-Factor Authentication Server. You can use OATH tokens with Active Directory Federation Services
(ADFS ), Internet Information Server (IIS ) forms-based authentication, and Remote Authentication Dial-In User
Service (RADIUS ) as long as the client system can accept the user input.
You can import third-party OATH TOTP tokens with the following formats:
Portable Symmetric Key Container (PSKC )
CSV if the file contains a serial number, a secret key in Base 32 format, and a time interval
Q: Can I use Azure Multi-Factor Authentication Server to secure Terminal Services?
Yes, but if you are using Windows Server 2012 R2 or later you can only secure Terminal Services by using Remote
Desktop Gateway (RD Gateway).
Security changes in Windows Server 2012 R2 changed how Azure Multi-Factor Authentication Server connects to
the Local Security Authority (LSA) security package in Windows Server 2012 and earlier versions. For versions of
Terminal Services in Windows Server 2012 or earlier, you can secure an application with Windows Authentication.
If you are using Windows Server 2012 R2, you need RD Gateway.
Q: I configured Caller ID in MFA Server, but my users still receive Multi-Factor Authentication calls
from an anonymous caller.
When Multi-Factor Authentication calls are placed through the public telephone network, sometimes they are
routed through a carrier that doesn't support caller ID. Because of this, caller ID is not guaranteed, even though
the Multi-Factor Authentication system always sends it.
Q: Why are my users being prompted to register their security information? There are several reasons that
users could be prompted to register their security information:
The user has been enabled for MFA by their administrator in Azure AD, but doesn't have security information
registered for their account yet.
The user has been enabled for self-service password reset in Azure AD. The security information will help
them reset their password in the future if they ever forget it.
The user accessed an application that has a Conditional Access policy to require MFA and hasn’t previously
registered for MFA.
The user is registering a device with Azure AD (including Azure AD Join), and your organization requires MFA
for device registration, but the user has not previously registered for MFA.
The user is generating Windows Hello for Business in Windows 10 (which requires MFA) and hasn’t
previously registered for MFA.
The organization has created and enabled an MFA Registration policy that has been applied to the user.
The user previously registered for MFA, but chose a verification method that an administrator has since
disabled. The user must therefore go through MFA registration again to select a new default verification
method.
Errors
Q: What should users do if they see an “Authentication request is not for an activated account” error
message when using mobile app notifications?
Tell them to follow this procedure to remove their account from the mobile app, then add it again:
1. Go to your Azure portal profile and sign in with your organizational account.
2. Select Additional Security Verification.
3. Remove the existing account from the mobile app.
4. Click Configure, and then follow the instructions to reconfigure the mobile app.
Q: What should users do if they see a 0x800434D4L error message when signing in to a non-browser
application?
The 0x800434D4L error occurs when you try to sign in to a non-browser application, installed on a local
computer, that doesn't work with accounts that require two-step verification.
A workaround for this error is to have separate user accounts for admin-related and non-admin operations. Later,
you can link mailboxes between your admin account and non-admin account so that you can sign in to Outlook by
using your non-admin account. For more details about this solution, learn how to give an administrator the ability
to open and view the contents of a user's mailbox.
Next steps
If your question isn't answered here, please leave it in the comments at the bottom of the page. Or, here are some
additional options for getting help:
Search the Microsoft Support Knowledge Base for solutions to common technical issues.
Search for and browse technical questions and answers from the community, or ask your own question in the
Azure Active Directory forums.
If you're a legacy PhoneFactor customer and you have questions or need help resetting a password, use the
password reset link to open a support case.
Contact a support professional through Azure Multi-Factor Authentication Server (PhoneFactor) support.
When contacting us, it's helpful if you can include as much information about your issue as possible.
Information you can supply includes the page where you saw the error, the specific error code, the specific
session ID, and the ID of the user who saw the error.
Resolve error messages from the NPS extension for
If you encounter errors with the NPS extension for Azure Multi-Factor Authentication, use this article to reach a
resolution faster. NPS extension logs are found in Event Viewer under Custom Views > Server Roles >
Network Policy and Access Services on the server where the NPS Extension is installed.
Troubleshooting steps for common errors

CONTACT_SUPPORT Contact support, and mention the list of steps for collecting
logs. Provide as much information as you can about what
happened before the error, including tenant id, and user
principal name (UPN).
CLIENT_CERT_INSTALL_ERROR There may be an issue with how the client certificate was
installed or associated with your tenant. Follow the
instructions in Troubleshooting the MFA NPS extension to
investigate client cert problems.
ESTS_TOKEN_ERROR Follow the instructions in Troubleshooting the MFA NPS

extension to investigate client cert and ADAL token problems.
HTTPS_COMMUNICATION_ERROR The NPS server is unable to receive responses from Azure

MFA. Verify that your firewalls are open bidirectionally for
traffic to and from https://adnotifications.windowsazure.com
HTTP_CONNECT_ERROR On the server that runs the NPS extension, verify that you
can reach https://adnotifications.windowsazure.com and
https://login.microsoftonline.com/. If those sites don't load,
troubleshoot connectivity on that server.
NPS Extension for Azure MFA: This error usually reflects an authentication failure in AD or
NPS Extension for Azure MFA only performs Secondary Auth that the NPS server is unable to receive responses from Azure
for Radius requests in AccessAccept State. Request received AD. Verify that your firewalls are open bidirectionally for traffic
for User username with response state AccessReject, ignoring to and from https://adnotifications.windowsazure.com and
request. https://login.microsoftonline.com using ports 80 and 443. It is
also important to check that on the DIAL-IN tab of Network
Access Permissions, the setting is set to "control access
through NPS Network Policy". This error can also trigger if the
user is not assigned a license.
REGISTRY_CONFIG_ERROR A key is missing in the registry for the application, which may
be because the PowerShell script wasn't run after installation.
The error message should include the missing key. Make sure
you have the key under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureMfa.
REQUEST_FORMAT_ERROR This error usually reflects an installation issue. The NPS

Radius Request missing mandatory Radius extension must be installed in NPS servers that can receive
userName\Identifier attribute.Verify that NPS is receiving RADIUS requests. NPS servers that are installed as
RADIUS requests dependencies for services like RDG and RRAS don't receive
radius requests. NPS Extension does not work when installed
over such installations and errors out since it cannot read the
details from the authentication request.
REQUEST_MISSING_CODE Make sure that the password encryption protocol between

the NPS and NAS servers supports the secondary
authentication method that you're using. PAP supports all
the authentication methods of Azure MFA in the cloud:
phone call, one-way text message, mobile app notification,
and mobile app verification code. CHAPV2 and EAP support
phone call and mobile app notification.
USERNAME_CANONICALIZATION_ERROR Verify that the user is present in your on-premises Active

Directory instance, and that the NPS Service has permissions
to access the directory. If you are using cross-forest trusts,
Alternate login ID errors

ALTERNATE_LOGIN_ID_ERROR Error: userObjectSid lookup failed Verify that the user exists in your on-
premises Active Directory instance. If
you are using cross-forest trusts,
ALTERNATE_LOGIN_ID_ERROR Error: Alternate LoginId lookup failed Verify that

LDAP_ALTERNATE_LOGINID_ATTRIBUT
E is set to a valid active directory
attribute.
If LDAP_FORCE_GLOBAL_CATALOG is
set to True, or
LDAP_LOOKUP_FORESTS is configured
with a non-empty value, verify that you
have configured a Global Catalog and
that the AlternateLoginId attribute is
added to it.
If LDAP_LOOKUP_FORESTS is
configured with a non-empty value,
verify that the value is correct. If there
is more than one forest name, the
names must be separated with semi-
colons, not spaces.
If these steps don't fix the problem,

contact support for more help.
ALTERNATE_LOGIN_ID_ERROR Error: Alternate LoginId value is empty Verify that the AlternateLoginId
attribute is configured for the user.
Errors your users may encounter

AccessDenied Caller tenant does not have access Check whether the tenant domain and
permissions to do authentication for the domain of the user principal name
the user (UPN) are the same. For example, make
sure that user@contoso.com is trying
to authenticate to the Contoso tenant.
The UPN represents a valid user for the
tenant in Azure.
AuthenticationMethodNotConfigure The specified authentication method Have the user add or verify their
d was not configured for the user verification methods according to the
instructions in Manage your settings
for two-step verification.
AuthenticationMethodNotSupporte Specified authentication method is not Collect all your logs that include this
d supported. error, and contact support. When you
contact support, provide the username
and the secondary verification method
that triggered the error.
BecAccessDenied MSODS Bec call returned access denied, The user is present in Active Directory
probably the username is not defined on-premises but is not synced into
in the tenant Azure AD by AD Connect. Or, the user
is missing for the tenant. Add the user
to Azure AD and have them add their
verification methods according to the
for two-step verification.
InvalidFormat or The phone number is in an Have the user correct their verification
StrongAuthenticationServiceInvalid unrecognizable format phone numbers.
Parameter
InvalidSession The specified session is invalid or may The session has taken more than three
have expired minutes to complete. Verify that the
user is entering the verification code, or
responding to the app notification,
within three minutes of initiating the
authentication request. If that doesn't
fix the problem, check that there are no
network latencies between client, NAS
Server, NPS Server, and the Azure MFA
endpoint.
NoDefaultAuthenticationMethodIsC No default authentication method was Have the user add or verify their
onfigured configured for the user verification methods according to the
for two-step verification. Verify that the
user has chosen a default
authentication method, and configured
that method for their account.
OathCodePinIncorrect Wrong code and pin entered. This error is not expected in the NPS
extension. If your user encounters this,
help.
ProofDataNotFound Proof data was not configured for the Have the user try a different verification
specified authentication method. method, or add a new verification
methods according to the instructions
in Manage your settings for two-step
verification. If the user continues to see
this error after you confirmed that their
verification method is set up correctly,
contact support.
SMSAuthFailedWrongCodePinEnter Wrong code and pin entered. This error is not expected in the NPS
ed (OneWaySMS) extension. If your user encounters this,
help.
TenantIsBlocked Tenant is blocked Contact support with Directory ID from

the Azure AD properties page in the
Azure portal.
UserNotFound The specified user was not found The tenant is no longer visible as active
in Azure AD. Check that your
subscription is active and you have the
required first party apps. Also make
sure the tenant in the certificate subject
is as expected and the cert is still valid
and registered under the service
principal.
Messages your users may encounter that aren't errors

Sometimes, your users may get messages from Multi-Factor Authentication because their authentication request
failed. These aren't errors in the product of configuration, but are intentional warnings explaining why an
authentication request was denied.
ERROR CODE ERROR MESSAGE RECOMMENDED STEPS
OathCodeIncorrect Wrong code entered\OATH Code The user entered the wrong code. Have
SMSAuthFailedMaxAllowedCodeRet Maximum allowed code retry reached The user failed the verification challenge
ryReached too many times. Depending on your
settings, they may need to be
unblocked by an admin now.
SMSAuthFailedWrongCodeEntered Wrong code entered/Text Message OTP The user entered the wrong code. Have
Errors that require support

If you encounter one of these errors, we recommend that you contact support for diagnostic help. There's no
standard set of steps that can address these errors. When you do contact support, be sure to include as much
information as possible about the steps that led to an error, and your tenant information.
ERROR CODE ERROR MESSAGE
InvalidParameter Request must not be null
InvalidParameter ObjectId must not be null or empty for ReplicationScope:{0}
InvalidParameter The length of CompanyName {0}\ is longer than the

maximum allowed length {1}
InvalidParameter UserPrincipalName must not be null or empty
InvalidParameter The provided TenantId is not in correct format
InvalidParameter SessionId must not be null or empty
InvalidParameter Could not resolve any ProofData from request or Msods. The
ProofData is unKnown
InternalError
OathCodePinIncorrect
VersionNotSupported
MFAPinNotSetup
Next steps
Troubleshoot user accounts
If your users are Having trouble with two-step verification, help them self-diagnose problems.
If you need additional help, contact a support professional through Azure Multi-Factor Authentication Server
support. When contacting us, it's helpful if you can include as much information about your issue as possible.
Information you can supply includes the page where you saw the error, the specific error code, the specific session
ID, the ID of the user who saw the error, and debug logs.
To collect debug logs for support diagnostics, use the following steps on the NPS server:
VERBOSE_LOG to TRUE
2. Open an Administrator command prompt and run these commands:
Mkdir c:\NPS
Cd NPS
netsh trace start Scenario=NetConnection capture=yes tracefile=c:\NPS\nettrace.etl
logman create trace "NPSExtension" -ow -o c:\NPS\NPSExtension.etl -p {7237ED00-E119-430B-AB0F-
C63360C8EE81} 0xffffffffffffffff 0xff -nb 16 16 -bs 1024 -mode Circular -f bincirc -max 4096 -ets
logman update trace "NPSExtension" -p {EC2E6D3A-C958-4C76-8EA4-0262520886FF} 0xffffffffffffffff 0xff -
ets
3. Reproduce the issue

4. Stop the tracing with these commands:
logman stop "NPSExtension" -ets
netsh trace stop
wevtutil epl AuthNOptCh C:\NPS\%computername%_AuthNOptCh.evtx
wevtutil epl AuthZOptCh C:\NPS\%computername%_AuthZOptCh.evtx
wevtutil epl AuthZAdminCh C:\NPS\%computername%_AuthZAdminCh.evtx
Start .

VERBOSE_LOG to FALSE
6. Zip the contents of the C:\NPS folder and attach the zipped file to the support case.
2 minutes to read
Azure AD service limits and restrictions
This article contains the usage constraints and other service limits for the Azure Active Directory (Azure AD )
service. If you’re looking for the full set of Microsoft Azure service limits, see Azure Subscription and Service
Limits, Quotas, and Constraints.
Here are the usage constraints and other service limits for the Azure Active Directory (Azure AD ) service.
CATEGORY LIMITS
Directories A single user can belong to a maximum of 500 Azure AD

directories as a member or a guest.
A single user can create a maximum of 20 directories.
Domains You can add no more than 900 managed domain names. If
you set up all of your domains for federation with on-premises
Active Directory, you can add no more than 450 domain
names in each directory.
Objects A maximum of 50,000 objects can be created in a

single directory by users of the Free edition of Azure
Active Directory by default. If you have at least one
verified domain, the default directory service quota in
Azure AD is extended to 300,000 objects.
A non-admin user can create no more than 250
objects. Both active objects and deleted objects that
are available to restore count toward this quota. Only
deleted objects that were deleted fewer than 30 days
ago are available to restore. Deleted objects that are
no longer available to restore count toward this quota
at a value of one-quarter for 30 days. Perhaps assign
an administrator role to non-admin users who are
likely to repeatedly exceed this quota in the course of
their regular duties.
Schema extensions String-type extensions can have a maximum of 256

characters.
Binary-type extensions are limited to 256 bytes.
Only 100 extension values, across all types and all
applications, can be written to any single object.
Only User, Group, TenantDetail, Device, Application,
and ServicePrincipal entities can be extended with
string-type or binary-type single-valued attributes.
Schema extensions are available only in the Graph API
version 1.21 preview. The application must be granted
write access to register an extension.
Applications A maximum of 100 users can be owners of a single

application.
CATEGORY LIMITS
Groups A maximum of 100 users can be owners of a single

group.
Any number of objects can be members of a single
group.
A user can be a member of any number of groups.
The number of members in a group that you can
synchronize from your on-premises Active Directory to
Azure Active Directory by using Azure AD Connect is
limited to 50,000 members.
Application Proxy A maximum of 500 transactions per second per App

Proxy application
A maximum of 750 transactions per second for the
tenant
A transaction is defined as a single http request and response

for a unique resource. When throttled, clients will receive a
429 response (too many requests).
Access Panel There's no limit to the number of applications that can

be seen in the Access Panel per user. This applies to
users assigned licenses for Azure AD Premium or the
Enterprise Mobility Suite.
A maximum of 10 app tiles can be seen in the Access
Panel for each user. This limit applies to users who are
assigned licenses for Free or Azure AD Basic editions of
Azure Active Directory. Examples of app tiles include
Box, Salesforce, or Dropbox. This limit doesn't apply to
administrator accounts.
Reports A maximum of 1,000 rows can be viewed or downloaded in

any report. Any additional data is truncated.
Administrative units An object can be a member of no more than 30 administrative

units.
Admin roles and permissions A group cannot be added as an owner.

A group cannot be assigned to a role.
Users’ ability to read other users’ directory information
cannot be restricted outside of the tenant-wide switch
to disable all non-admin users’ access to all directory
information (not recommended). More information on
default permissions here.
It may take up to 15 minutes or signing out/signing in
before admin role membership additions and
revocations take effect.
Next steps
Sign up for Azure as an organization
How Azure subscriptions are associated with Azure AD
What's new in Azure Active Directory?
Get notified about when to revisit this page for updates by copying and pasting this URL:
https://docs.microsoft.com/api/search/rss?search=%22release+notes+for+azure+AD%22&locale=en-us into your
feed reader.
Azure AD receives improvements on an ongoing basis. To stay up-to-date with the most recent developments, this
article provides you with information about:
The latest releases
Known issues
Bug fixes
Deprecated functionality
Plans for changes
This page is updated monthly, so revisit it regularly. If you're looking for items that are older than six months, you
can find them in the Archive for What's new in Azure Active Directory.
July 2019
Plan for change: Application Proxy service update to support only TLS 1.2
Type: Plan for change
Service category: App Proxy
Product capability: Access Control
To help provide you with our strongest encryption, we're going to begin limiting Application Proxy service access
to only TLS 1.2 protocols. This limitation will initially be rolled out to customers who are already using TLS 1.2
protocols, so you won't see the impact. Complete deprecation of the TLS 1.0 and TLS 1.1 protocols will be
complete on August 31, 2019. Customers still using TLS 1.0 and TLS 1.1 will receive advanced notice to prepare
for this change.
To maintain the connection to the Application Proxy service throughout this change, we recommend that you make
sure your client-server and browser-server combinations are updated to use TLS 1.2. We also recommend that you
make sure to include any client systems used by your employees to access apps published through the Application
Proxy service.
For more information, see Add an on-premises application for remote access through Application Proxy in Azure
Active Directory.
Plan for change: Design updates are coming for the Application Gallery
Service category: Enterprise Apps
Product capability: SSO
New user interface changes are coming to the design of the Add from the gallery area of the Add an
application blade. These changes will help you more easily find your apps that support automatic provisioning,
OpenID Connect, Security Assertion Markup Language (SAML ), and Password single sign-on (SSO ).
Plan for change: Removal of the MFA server IP address from the Office 365 IP address
Service category: MFA
Product capability: Identity Security & Protection
We're removing the MFA server IP address from the Office 365 IP Address and URL Web service. If you currently
rely on these pages to update your firewall settings, you must make sure you're also including the list of IP
addresses documented in the Azure Multi-Factor Authentication Server firewall requirements section of the
Getting started with the Azure Multi-Factor Authentication Server article.
App-only tokens now require the client app to exist in the resource tenant
Type: Fixed
Service category: Authentications (Logins)
Product capability: User Authentication
On July 26, 2019, we changed how we provide app-only tokens through the client credentials grant. Previously,
apps could get tokens to call other apps, regardless of whether the client app was in the tenant. We've updated this
behavior so single-tenant resources, sometimes called Web APIs, can only be called by client apps that exist in the
resource tenant.
If your app isn't located in the resource tenant, you'll get an error message that says,
The service principal named <app_name> was not found in the tenant named <tenant_name>. This can happen if the
application has not been installed by the administrator of the tenant.
To fix this problem, you must create the client app service principal in the tenant, using either the admin consent
endpoint or through PowerShell, which ensures your tenant has given the app permission to operate within the
tenant.
For more information, see What's new for authentication?.
NOTE
Existing consent between the client and the API continues to not be required. Apps should still be doing their own
authorization checks.
New passwordless sign-in to Azure AD using FIDO2 security keys

Type: New feature
Azure AD customers can now set policies to manage FIDO2 security keys for their organization's users and groups.
End-users can also self-register their security keys, use the keys to sign in to their Microsoft accounts on web sites
while on FIDO -capable devices, as well as sign in to their Azure AD -joined Windows 10 devices.
For more information, see Enable passwordless sign in for Azure AD (preview ) for administrator-related
information, and Set up security info to use a security key (Preview ) for end-user-related information.
New Federated Apps available in Azure AD App gallery - July 2019

Type: New feature
Product capability: 3rd Party Integration
In July 2019, we've added these 18 new apps with Federation support to the app gallery:
Ungerboeck Software, Bright Pattern Omnichannel Contact Center, Clever Nelly, AcquireIO, Looop, productboard,
MS Azure SSO Access for Ethidex Compliance Office™, Hype, Abstract, Ascentis, Flipsnack, Wandera, TwineSocial,
Kallidus, HyperAnna, PharmID WasteWitness, i2B Connect, JFrog Artifactory
For more information about the apps, see SaaS application integration with Azure Active Directory. For more
information about listing your application in the Azure AD app gallery, see List your application in the Azure Active
Directory application gallery.
Automate user account provisioning for these newly supported SaaS apps
Type: New feature
Product capability: Monitoring & Reporting
You can now automate creating, updating, and deleting user accounts for these newly integrated apps:
Dialpad
Federated Directory
Figma
Leapsome
Peakon
Smartsheet
For more information about how to better secure your organization by using automated user account provisioning,
see Automate user provisioning to SaaS applications with Azure AD
New Azure AD Domain Services service tag for Network Security Group
Type: New feature
Service category: Azure AD Domain Services
Product capability: Azure AD Domain Services
If you're tired of managing long lists of IP addresses and ranges, you can use the new
AzureActiveDirectoryDomainServices network service tag in your Azure network security group to help secure
inbound traffic to your Azure AD Domain Services virtual network subnet.
For more information about this new service tag, see Network Security Groups for Azure AD Domain Services.
New Security Audits for Azure AD Domain Services (Public Preview)

Type: New feature
We're pleased to announce the release of Azure AD Domain Service Security Auditing to public preview. Security
auditing helps provide you with critical insight into your authentication services by streaming security audit events
to targeted resources, including Azure Storage, Azure Log Analytics workspaces, and Azure Event Hub, using the
Azure AD Domain Service portal.
For more information, see Enable Security Audits for Azure AD Domain Services (Preview ).
New Authentication methods usage & insights (Public Preview)

Type: New feature
Service category: Self Service Password Reset
The new Authentication methods usage & insights reports can help you to understand how features like Azure
Multi-Factor Authentication and self-service password reset are being registered and used in your organization,
including the number of registered users for each feature, how often self-service password reset is used to reset
passwords, and by which method the reset happens.
For more information, see Authentication methods usage & insights (preview ).
New security reports are available for all Azure AD administrators (Public Preview)
Type: New feature
Service category: Identity Protection
All Azure AD administrators can now select the banner at the top of existing security reports, such as the Users
flagged for risk report, to start using the new security experience as shown in the Risky users and the Risky
sign-ins reports. Over time, all of the security reports will move from the older versions to the new versions, with
the new reports providing you the following additional capabilities:
Advanced filtering and sorting
Bulk actions, such as dismissing user risk
Confirmation of compromised or safe entities
Risk state, covering: At risk, Dismissed, Remediated, and Confirmed compromised
For more information, see Risky users report and Risky sign-ins report.
New Security Audits for Azure AD Domain Services (Public Preview)

Type: New feature
We're pleased to announce the release of Azure AD Domain Service Security Auditing to public preview. Security
auditing helps provide you with critical insight into your authentication services by streaming security audit events
to targeted resources, including Azure Storage, Azure Log Analytics workspaces, and Azure Event Hub, using the
Azure AD Domain Service portal.
For more information, see Enable Security Audits for Azure AD Domain Services (Preview ).
New B2B direct federation using SAML/WS -Fed (Public Preview)

Type: New feature
Service category: B2B
Product capability: B2B/B2C
Direct federation helps to make it easier for you to work with partners whose IT-managed identity solution is not
Azure AD, by working with identity systems that support the SAML or WS -Fed standards. After you set up a direct
federation relationship with a partner, any new guest user you invite from that domain can collaborate with you
using their existing organizational account, making the user experience for your guests more seamless.
For more information, see Direct federation with AD FS and third-party providers for guest users (preview ) .
Type: New feature
Dialpad
Federated Directory
Figma
Leapsome
Peakon
Smartsheet
see Automate user provisioning to SaaS applications with Azure AD.
New check for duplicate group names in the Azure AD portal

Type: New feature
Service category: Group Management
Product capability: Collaboration
Now, when you create or update a group name from the Azure AD portal, we'll perform a check to see if you are
duplicating an existing group name in your resource. If we determine that the name is already in use by another
group, you'll be asked to modify your name.
For more information, see Manage groups in the Azure AD portal.
Azure AD now supports static query parameters in reply (redirect) URIs

Type: New feature
Azure AD apps can now register and use reply (redirect) URIs with static query parameters (for example,
https://contoso.com/oauth2?idp=microsoft ) for OAuth 2.0 requests. The static query parameter is subject to string
matching for reply URIs, just like any other part of the reply URI. If there's no registered string that matches the
URL -decoded redirect-uri, the request is rejected. If the reply URI is found, the entire string is used to redirect the
user, including the static query parameter.
Dynamic reply URIs are still forbidden because they represent a security risk and can't be used to retain state
information across an authentication request. For this purpose, use the state parameter.
Currently, the app registration screens of the Azure portal still block query parameters. However, you can manually
edit the app manifest to add and test query parameters in your app. For more information, see What's new for
authentication?.
Activity logs (MS Graph APIs) for Azure AD are now available through PowerShell Cmdlets
Type: New feature
Service category: Reporting
We're excited to announce that Azure AD activity logs (Audit and Sign-ins reports) are now available through the
Azure AD PowerShell module. Previously, you could create your own scripts using MS Graph API endpoints, and
now we've extended that capability to PowerShell cmdlets.
For more information about how to use these cmdlets, see Azure AD PowerShell cmdlets for reporting.
Updated filter controls for Audit and Sign-in logs in Azure AD
Type: Changed feature
We've updated the Audit and Sign-in log reports so you can now apply various filters without having to add them
as columns on the report screens. Additionally, you can now decide how many filters you want to show on the
screen. These updates all work together to make your reports easier to read and more scoped to your needs.
For more information about these updates, see Filter audit logs and Filter sign-in activities.
June 2019
New riskDetections API for Microsoft Graph (Public preview)
Type: New feature
We're pleased to announce the new riskDetections API for Microsoft Graph is now in public preview. You can use
this new API to view a list of your organization's Identity Protection-related user and sign-in risk detections. You
can also use this API to more efficiently query your risk detections, including details about the detection type,
status, level, and more.
For more information, see the Risk detection API reference documentation.
New Federated Apps available in Azure AD app gallery - June 2019

Type: New feature
In June 2019, we've added these 22 new apps with Federation support to the app gallery:
Azure AD SAML Toolkit, Otsuka Shokai (大塚商会), ANAQUA, Azure VPN Client, ExpenseIn, Helper Helper,
Costpoint, GlobalOne, Mercedes-Benz In-Car Office, Skore, Oracle Cloud Infrastructure Console, CyberArk SAML
Authentication, Scrible Edu, PandaDoc, Perceptyx, Proptimise OS, Vtiger CRM (SAML ), Oracle Access Manager for
Oracle Retail Merchandising, Oracle Access Manager for Oracle E -Business Suite, Oracle IDCS for E -Business
Suite, Oracle IDCS for PeopleSoft, Oracle IDCS for JD Edwards
Type: New feature
Zoom
Envoy
Proxyclick
4me
see Automate user provisioning to SaaS applications with Azure AD
View the real-time progress of the Azure AD provisioning service

Service category: App Provisioning
Product capability: Identity Lifecycle Management
We've updated the Azure AD provisioning experience to include a new progress bar that shows you how far you
are in the user provisioning process. This updated experience also provides information about the number of users
provisioned during the current cycle, as well as how many users have been provisioned to date.
For more information, see Check the status of user provisioning.
Company branding now appears on sign out and error screens

We've updated Azure AD so that your company branding now appears on the sign out and error screens, as well as
the sign-in page. You don't have to do anything to turn on this feature, Azure AD simply uses the assets you've
already set up in the Company branding area of the Azure portal.
For more information about setting up your company branding, see Add branding to your organization's Azure
Active Directory pages.
Azure Multi-Factor Authentication (MFA ) Server is no longer available for new deployments
Type: Deprecated
Service category: MFA
As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who want to
require multi-factor authentication in their organization must now use cloud-based Azure Multi-Factor
Authentication. Customers who activated MFA Server prior to July 1 won't see a change. You'll still be able to
download the latest version, get future updates, and generate activation credentials.
For more information, see Getting started with the Azure Multi-Factor Authentication Server. For more
information about cloud-based Azure Multi-Factor Authentication, see Planning a cloud-based Azure Multi-Factor
Authentication deployment.
May 2019
Service change: Future support for only TLS 1.2 protocols on the Application Proxy service
To help provide best-in-class encryption for our customers, we're limiting access to only TLS 1.2 protocols on the
Application Proxy service. This change is gradually being rolled out to customers who are already only using TLS
1.2 protocols, so you shouldn't see any changes.
Deprecation of TLS 1.0 and TLS 1.1 happens on August 31, 2019, but we'll provide additional advanced notice, so
you'll have time to prepare for this change. To prepare for this change make sure your client-server and browser-
server combinations, including any clients your users use to access apps published through Application Proxy, are
updated to use the TLS 1.2 protocol to maintain the connection to the Application Proxy service. For more
information, see Add an on-premises application for remote access through Application Proxy in Azure Active
Directory.
Use the usage and insights report to view your app-related sign-in data
Type: New feature
You can now use the usage and insights report, located in the Enterprise applications area of the Azure portal, to
get an application-centric view of your sign-in data, including info about:
Top used apps for your organization
Apps with the most failed sign-ins
Top sign-in errors for each app
For more information about this feature, see Usage and insights report in the Azure Active Directory portal
Automate your user provisioning to cloud apps using Azure AD

Type: New feature
Follow these new tutorials to use the Azure AD Provisioning Service to automate the creation, deletion, and
updating of user accounts for the following cloud-based apps:
Comeet
DynamicSignal
KeeperSecurity
You can also follow this new Dropbox tutorial, which provides info about how to provision group objects.
For more information about how to better secure your organization through automated user account provisioning,
Identity secure score is now available in Azure AD (General availability)

Type: New feature
Service category: N/A
You can now monitor and improve your identity security posture by using the identity secure score feature in Azure
AD. The identity secure score feature uses a single dashboard to help you:
Objectively measure your identity security posture, based on a score between 1 and 223.
Plan for your identity security improvements
Review the success of your security improvements
For more information about the identity security score feature, see What is the identity secure score in Azure Active
Directory?.
New App registrations experience is now available (General availability)

Type: New feature
Product capability: Developer Experience
The new App registrations experience is now in general availability. This new experience includes all the key
features you’re familiar with from the Azure portal and the Application Registration portal and improves upon
them through:
Better app management. Instead of seeing your apps across different portals, you can now see all your
apps in one location.
Simplified app registration. From the improved navigation experience to the revamped permission
selection experience, it’s now easier to register and manage your apps.
More detailed information. You can find more details about your app, including quickstart guides and
more.
For more information, see Microsoft identity platform and the App registrations experience is now generally
available! blog announcement.
New capabilities available in the Risky Users API for Identity Protection
Type: New feature
We're pleased to announce that you can now use the Risky Users API to retrieve users' risk history, dismiss risky
users, and to confirm users as compromised. This change helps you to more efficiently update the risk status of
your users and understand their risk history.
For more information, see the Risky Users API reference documentation.
New Federated Apps available in Azure AD app gallery - May 2019

Type: New feature
In May 2019, we've added these 21 new apps with Federation support to the app gallery:
Freedcamp, Real Links, Kianda, Simple Sign, Braze, Displayr, Templafy, Marketo Sales Engage, ACLP, OutSystems,
Meta4 Global HR, Quantum Workplace, Cobalt, webMethods API Cloud, RedFlag, Whatfix, Control, JOBHUB,
NEOGOV, Foodee, MyVR
Improved groups creation and management experiences in the Azure AD portal

Type: New feature
We've made improvements to the groups-related experiences in the Azure AD portal. These improvements allow
administrators to better manage groups lists, members lists, and to provide additional creation options.
Improvements include:
Basic filtering by membership type and group type.
Addition of new columns, such as Source and Email address.
Ability to multi-select groups, members, and owner lists for easy deletion.
Ability to choose an email address and add owners during group creation.
For more information, see Create a basic group and add members using Azure Active Directory.
Configure a naming policy for Office 365 groups in Azure AD portal (General availability)
Administrators can now configure a naming policy for Office 365 groups, using the Azure AD portal. This change
helps to enforce consistent naming conventions for Office 365 groups created or edited by users in your
organization.
You can configure naming policy for Office 365 groups in two different ways:
Define prefixes or suffixes, which are automatically added to a group name.
Upload a customized set of blocked words for your organization, which are not allowed in group names (for
example, “CEO, Payroll, HR”).
For more information, see Enforce a Naming Policy for Office 365 groups.
Microsoft Graph API endpoints are now available for Azure AD activity logs (General availability)
We're happy to announce general availability of Microsoft Graph API endpoints support for Azure AD activity logs.
With this release, you can now use Version 1.0 of both the Azure AD audit logs, as well as the sign-in logs APIs.
For more information, see Azure AD audit log API overview.
Administrators can now use Conditional Access for the combined registration process (Public preview)
Type: New feature
Service category: Conditional Access
Administrators can now create Conditional Access policies for use by the combined registration page. This includes
applying policies to allow registration if:
Users are on a trusted network.
Users are a low sign-in risk.
Users are on a managed device.
Users agree to the organization’s terms of use (TOU ).
For more information about Conditional Access and password reset, you can see the Conditional Access for the
Azure AD combined MFA and password reset registration experience blog post. For more information about
Conditional Access policies for the combined registration process, see Conditional Access policies for combined
registration. For more information about the Azure AD terms of use feature, see Azure Active Directory terms of
use feature.
April 2019
New Azure AD threat intelligence detection is now available in refreshed Azure AD Identity Protection
Type: New feature
Service category: Azure AD Identity Protection
Azure AD threat intelligence detection is now available in the refreshed Azure AD Identity Protection. This new
functionality helps to indicate user activity that’s unusual for a specific user or that’s consistent with known attack
patterns based on Microsoft’s internal and external threat intelligence.
For more information about the refreshed version of Azure AD Identity Protection, see the Four major Azure AD
Identity Protection enhancements are now in public preview blog and the What is Azure Active Directory Identity
Protection (refreshed)? article. For more information about Azure AD threat intelligence detection, see the Azure
Active Directory Identity Protection risk events article.
Azure AD entitlement management is now available (Public preview)

Type: New feature
Service category: Identity Governance
Product capability: Identity Governance
Azure AD entitlement management, now in public preview, helps customers to delegate management of access
packages, which defines how employees and business partners can request access, who must approve, and how
long they have access. Access packages can manage membership in Azure AD and Office 365 groups, role
assignments in enterprise applications, and role assignments for SharePoint Online sites. Read more about
entitlement management at the overview of Azure AD entitlement management. To learn more about the breadth
of Azure AD Identity Governance features, including Privileged Identity Management, access reviews and terms of
use, see What is Azure AD Identity Governance?.
Configure a naming policy for Office 365 groups in Azure AD portal (Public preview)
Type: New feature
Administrators can now configure a naming policy for Office 365 groups, using the Azure AD portal. This change
helps to enforce consistent naming conventions for Office 365 groups created or edited by users in your
organization.
You can configure naming policy for Office 365 groups in two different ways:
Define prefixes or suffixes, which are automatically added to a group name.
Upload a customized set of blocked words for your organization, which are not allowed in group names (for
example, “CEO, Payroll, HR”).
For more information, see Enforce a Naming Policy for Office 365 groups.
Azure AD Activity logs are now available in Azure Monitor (General availability)
Type: New feature
To help address your feedback about visualizations with the Azure AD Activity logs, we're introducing a new
Insights feature in Log Analytics. This feature helps you gain insights about your Azure AD resources by using our
interactive templates, called Workbooks. These pre-built Workbooks can provide details for apps or users, and
include:
Sign-ins. Provides details for apps and users, including sign-in location, the in-use operating system or
browser client and version, and the number of successful or failed sign-ins.
Legacy authentication and Conditional Access. Provides details for apps and users using legacy
authentication, including Multi-Factor Authentication usage triggered by Conditional Access policies, apps
using Conditional Access policies, and so on.
Sign-in failure analysis. Helps you to determine if your sign-in errors are occurring due to a user action,
policy issues, or your infrastructure.
Custom reports. You can create new, or edit existing Workbooks to help customize the Insights feature for
your organization.
For more information, see How to use Azure Monitor workbooks for Azure Active Directory reports.
New Federated Apps available in Azure AD app gallery - April 2019

Type: New feature
In April 2019, we've added these 21 new apps with Federation support to the app gallery:
SAP Fiori, HRworks Single Sign-On, Percolate, MobiControl, Citrix NetScaler, Shibumi, Benchling, MileIQ,
PageDNA, EduBrite LMS, RStudio Connect, AMMS, Mitel Connect, Alibaba Cloud (Role-based SSO ), Certent
Equity Management, Sectigo Certificate Manager, GreenOrbit, Workgrid, monday.com, SurveyMonkey Enterprise,
Indiggo
New access reviews frequency option and multiple role selection

Type: New feature
Service category: Access Reviews
Product capability: Identity Governance
New updates in Azure AD access reviews allow you to:
Change the frequency of your access reviews to semi-annually, in addition to the previously existing
options of weekly, monthly, quarterly, and annually.
Select multiple Azure AD and Azure resource roles when creating a single access review. In this situation, all
roles are set up with the same settings and all reviewers are notified at the same time.
For more information about how to create an access review, see Create an access review of groups or applications
in Azure AD access reviews.
Azure AD Connect email alert system(s) are transitioning, sending new email sender information for some
customers
Service category: AD Sync
Product capability: Platform
Azure AD Connect is in the process of transitioning our email alert system(s), potentially showing some customers
a new email sender. To address this, you must add azure-noreply@microsoft.com to your organization's allow list or
you won't be able to continue receiving important alerts from your Office 365, Azure, or your Sync services.
UPN suffix changes are now successful between Federated domains in Azure AD Connect
Type: Fixed
Service category: AD Sync
Product capability: Platform
You can now successfully change a user's UPN suffix from one Federated domain to another Federated domain in
Azure AD Connect. This fix means you should no longer experience the FederatedDomainChangeError error
message during the synchronization cycle or receive a notification email stating, "Unable to update this object in
Azure Active Directory, because the attribute [FederatedUser.UserPrincipalName], is not valid. Update the value in
your local directory services".
For more information, see Troubleshooting Errors during synchronization.
Increased security using the app protection-based Conditional Access policy in Azure AD (Public preview)
Type: New feature
App protection-based Conditional Access is now available by using the Require app protection policy. This new
policy helps to increase your organization's security by helping to prevent:
Users gaining access to apps without a Microsoft Intune license.
Users being unable to get a Microsoft Intune app protection policy.
Users gaining access to apps without a configured Microsoft Intune app protection policy.
For more information, see How to Require app protection policy for cloud app access with Conditional Access.
New support for Azure AD single sign-on and Conditional Access in Microsoft Edge (Public preview)
Type: New feature
We've enhanced our Azure AD support for Microsoft Edge, including providing new support for Azure AD single
sign-on and Conditional Access. If you've previously used Microsoft Intune Managed Browser, you can now use
Microsoft Edge instead.
For more information about setting up and managing your devices and apps using Conditional Access, see Require
managed devices for cloud app access with Conditional Access and Require approved client apps for cloud app
access with Conditional Access. For more information about how to manage access using Microsoft Edge with
Microsoft Intune policies, see Manage Internet access using a Microsoft Intune policy-protected browser.
March 2019
Identity Experience Framework and custom policy support in Azure Active Directory B2C is now available (GA )
Type: New feature
Service category: B2C - Consumer Identity Management
You can now create custom policies in Azure AD B2C, including the following tasks, which are supported at-scale
and under our Azure SLA:
Create and upload custom authentication user journeys by using custom policies.
Describe user journeys step-by-step as exchanges between claims providers.
Define conditional branching in user journeys.
Transform and map claims for use in real-time decisions and communications.
Use REST API-enabled services in your custom authentication user journeys. For example, with email
providers, CRMs, and proprietary authorization systems.
Federate with identity providers who are compliant with the OpenIDConnect protocol. For example, with
multi-tenant Azure AD, social account providers, or two-factor verification providers.
For more information about creating custom policies, see Developer notes for custom policies in Azure Active
Directory B2C and read Alex Simon’s blog post, including case studies.
New Federated Apps available in Azure AD app gallery - March 2019

Type: New feature
In March 2019, we've added these 14 new apps with Federation support to the app gallery:
ISEC7 Mobile Exchange Delegate, MediusFlow, ePlatform, Fulcrum, ExcelityGlobal, Explanation-Based Auditing
System, Lean, Powerschool Performance Matters, Cinode, Iris Intranet, Empactis, SmartDraw, Confirmit Horizons,
TAS
New Zscaler and Atlassian provisioning connectors in the Azure AD gallery - March 2019
Type: New feature
Service category: App Provisioning
Automate creating, updating, and deleting user accounts for the following apps:
Zscaler, Zscaler Beta, Zscaler One, Zscaler Two, Zscaler Three, Zscaler ZSCloud, Atlassian Cloud
For more information about how to better secure your organization through automated user account provisioning,
Restore and manage your deleted Office 365 groups in the Azure AD portal
Type: New feature
You can now view and manage your deleted Office 365 groups from the Azure AD portal. This change helps you to
see which groups are available to restore, along with letting you permanently delete any groups that aren’t needed
by your organization.
For more information, see Restore expired or deleted groups.
Single sign-on is now available for Azure AD SAML -secured on-premises apps through Application Proxy
(public preview)
Type: New feature
You can now provide a single sign-on (SSO ) experience for on-premises, SAML -authenticated apps, along with
remote access to these apps through Application Proxy. For more information about how to set up SAML SSO
with your on-premises apps, see SAML single sign-on for on-premises applications with Application Proxy
(Preview ).
Client apps in request loops will be interrupted to improve reliability and user experience
Type: New feature
Client apps can incorrectly issue hundreds of the same login requests over a short period of time. These requests,
whether they're successful or not, all contribute to a poor user experience and heightened workloads for the IDP,
increasing latency for all users and reducing the availability of the IDP.
This update sends an invalid_grant error:
AADSTS50196: The server terminated an operation because it encountered a loop while processing a request to
client apps that issue duplicate requests multiple times over a short period of time, beyond the scope of normal
operation. Client apps that encounter this issue should show an interactive prompt, requiring the user to sign in
again. For more information about this change and about how to fix your app if it encounters this error, see What's
new for authentication?.
New Audit Logs user experience now available

We've created a new Azure AD Audit logs page to help improve both readability and how you search for your
information. To see the new Audit logs page, select Audit logs in the Activity section of Azure AD.
For more information about the new Audit logs page, see Audit activity reports in the Azure Active Directory
portal.
New warnings and guidance to help prevent accidental administrator lockout from misconfigured Conditional
Access policies
To help prevent administrators from accidentally locking themselves out of their own tenants through
misconfigured Conditional Access policies, we've created new warnings and updated guidance in the Azure portal.
For more information about the new guidance, see What are service dependencies in Azure Active Directory
Conditional Access.
Improved end-user terms of use experiences on mobile devices

Service category: Terms of use
Product capability: Governance
We've updated our existing terms of use experiences to help improve how you review and consent to terms of use
on a mobile device. You can now zoom in and out, go back, download the information, and select hyperlinks. For
more information about the updated terms of use, see Azure Active Directory terms of use feature.
New Azure AD Activity logs download experience available

You can now download large amounts of activity logs directly from the Azure portal. This update lets you:
Download up to 250,000 rows.
Get notified after the download completes.
Customize your file name.
Determine your output format, either JSON or CSV.
For more information about this feature, see Quickstart: Download an audit report using the Azure portal
Breaking change: Updates to condition evaluation by Exchange ActiveSync (EAS )

We’re in the process of updating how Exchange ActiveSync (EAS ) evaluates the following conditions:
User location, based on country, region, or IP address
Sign-in risk
Device platform
If you’ve previously used these conditions in your Conditional Access policies, be aware that the condition behavior
might change. For example, if you previously used the user location condition in a policy, you might find the policy
now being skipped based on the location of your user.
February 2019
Configurable Azure AD SAML token encryption (Public preview)
Type: New feature
Product capability: SSO
You can now configure any supported SAML app to receive encrypted SAML tokens. When configured and used
with an app, Azure AD encrypts the emitted SAML assertions using a public key obtained from a certificate stored
in Azure AD.
For more information about configuring your SAML token encryption, see Configure Azure AD SAML token
encryption.
Create an access review for groups or apps using Azure AD Access Reviews
Type: New feature
Service category: Access Reviews
Product capability: Governance
You can now include multiple groups or apps in a single Azure AD access review for group membership or app
assignment. Access reviews with multiple groups or apps are set up using the same settings and all included
reviewers are notified at the same time.
For more information about how create an access review using Azure AD Access Reviews, see Create an access
review of groups or applications in Azure AD Access Reviews
New Federated Apps available in Azure AD app gallery - February 2019

Type: New feature
In February 2019, we've added these 27 new apps with Federation support to the app gallery:
Euromonitor Passport, MindTickle, FAT FINGER, AirStack, Oracle Fusion ERP, IDrive, Skyward Qmlativ, Brightidea,
AlertOps, Soloinsight-CloudGate SSO, Permission Click, Brandfolder, StoregateSmartFile, Pexip, Stormboard,
Seismic, Share A Dream, Bugsnag, webMethods Integration Cloud, Knowledge Anywhere LMS, OU Campus,
Periscope Data, Netop Portal, smartvid.io, PureCloud by Genesys, ClickUp Productivity Platform
Enhanced combined MFA/SSPR registration

Service category: Self Service Password Reset
In response to customer feedback, we’ve enhanced the combined MFA/SSPR registration preview experience,
helping your users to more quickly register their security info for both MFA and SSPR.
To turn on the enhanced experience for your users' today, follow these steps:
1. As a global administrator or user administrator, sign in to the Azure portal and go to Azure Active
Directory > User settings > Manage settings for access panel preview features.
2. In the Users who can use the preview features for registering and managing security info – refresh
option, choose to turn on the features for a Selected group of users or for All users.
Over the next few weeks, we’ll be removing the ability to turn on the old combined MFA/SSPR registration
preview experience for tenants that don’t already have it turned on.
To see if the control will be removed for your tenant, follow these steps:
1. As a global administrator or user administrator, sign in to the Azure portal and go to Azure Active
Directory > User settings > Manage settings for access panel preview features.
2. If the Users who can use the preview features for registering and managing security info option is
set to None, the option will be removed from your tenant.
Regardless of whether you previously turned on the old combined MFA/SSPR registration preview experience for
users or not, the old experience will be turned off at a future date. Because of that, we strongly suggest that you
move to the new, enhanced experience as soon as possible.
For more information about the enhanced registration experience, see the Cool enhancements to the Azure AD
combined MFA and password reset registration experience.
Updated policy management experience for user flows

We've updated the policy creation and management process for user flows (previously known as, built-in policies)
easier. This new experience is now the default for all of your Azure AD tenants.
You can provide additional feedback and suggestions by using the smile or frown icons in the Send us feedback
area at the top of the portal screen.
For more information about the new policy management experience, see the Azure AD B2C now has JavaScript
customization and many more new features blog.
Choose specific page element versions provided by Azure AD B2C
Type: New feature
You can now choose a specific version of the page elements provided by Azure AD B2C. By selecting a specific
version, you can test your updates before they appear on a page and you can get predictable behavior. Additionally,
you can now opt in to enforce specific page versions to allow JavaScript customizations. To turn on this feature, go
to the Properties page in your user flows.
For more information about choosing specific versions of page elements, see the Azure AD B2C now has
JavaScript customization and many more new features blog.
Configurable end-user password requirements for B2C (GA )

Type: New feature
You can now set up your organization's password complexity for your end users, instead of having to use your
native Azure AD password policy. From the Properties blade of your user flows (previously known as your built-in
policies), you can choose a password complexity of Simple or Strong, or you can create a Custom set of
requirements.
For more information about password complexity requirement configuration, see Configure complexity
requirements for passwords in Azure Active Directory B2C.
New default templates for custom branded authentication experiences

Type: New feature
You can use our new default templates, located on the Page layouts blade of your user flows (previously known as
built-in policies), to create a custom branded authentication experience for your users.
For more information about using the templates, see Azure AD B2C now has JavaScript customization and many
more new features.

Cloud MS - AZURE Multi Authentication

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Cloud MS - AZURE Multi Authentication

Загружено:

Авторское право:

Доступные форматы

Contents

Self-service password reset

Enable self-service password reset

Test self-service password reset

Enable Azure Multi-Factor Authentication

Test Azure Multi-Factor Authentication

Enable self-service password reset

Test SSPR as a user

Enable password writeback option in Azure AD Connect

Enable password writeback option in SSPR

Enable risk-based policies for SSPR and MFA

Enable risk-based password changes

AUTHENTICATION METHOD USAGE

Password MFA and SSPR

Security questions SSPR Only

Email address SSPR Only

Microsoft Authenticator app MFA and public preview for SSPR

OATH Hardware token Public preview for MFA and SSPR

SMS MFA and SSPR

Voice call MFA and SSPR

App passwords MFA only in certain cases

Microsoft Authenticator app

Notification through mobile app

Verification code from mobile app

OATH hardware tokens (public preview)

upn,serial number,secret key,time interval,manufacturer,model

Troubleshooting phone options

SOMETHING YOU HAVE SOMETHING YOU ARE OR KNOW

Passwordless Phone or security key Biometric or PIN

Microsoft Authenticator App

WHY IS THIS FEATURE OR EX TENSION

1 Resident key This feature enables the security key to

2 Client pin This feature enables you to protect your

3 hmac-secret This extension ensures you can sign in

What scenarios work with the preview?

Methods available in combined registration

REGISTER CHANGE DELETE

Microsoft Authenticator Yes (maximum of 5) No Yes

Other authenticator app Yes (maximum of 5) No Yes

Hardware token No No Yes

Phone Yes Yes Yes

Alternate phone Yes Yes Yes

Email Yes Yes Yes

Security questions Yes No Yes

App passwords Yes No Yes

Combined registration modes

Key usage scenarios

How does the password reset portal work?

NUMBER OF METHODS REQUIRED TO

Mobile app features available Code Code or Notification

Change authentication methods

NUMBER OF METHODS REGISTERED NUMBER OF METHODS REQUIRED RESULT

1 or more 1 Able to reset or unlock

1 2 Unable to reset or unlock

2 or more 2 Able to reset or unlock

Password reset for B2B users

Customize the "Contact your administrator" link

Customize the AD FS sign-in page for SSPR

Set-ADFSGlobalWebContent -SigninPageDescriptionText "<p><A href='https://passwordreset.microsoftonline.com'

Administrator reset policy differences

UserPrincipalName policies that apply to all user accounts

PROPERTY USERPRINCIPALNAME REQUIREMENTS

Characters allowed A–Z