Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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
On-premises integration
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.
Multi-Factor Authentication
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
3/22/2019 • 2 minutes to read • Edit Online
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.
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
6/13/2019 • 2 minutes to read • Edit Online
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.
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
4/9/2019 • 3 minutes to read • Edit Online
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.
Enable self-service password reset
Test SSPR as a user
Prerequisites
A Global Administrator account
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 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
7/12/2019 • 2 minutes to read • Edit Online
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.
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
6/13/2019 • 2 minutes to read • Edit Online
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.
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?
6/17/2019 • 11 minutes to read • Edit Online
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.
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.
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.
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.
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 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.
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.
To work properly, phone numbers must be in the format +CountryCode PhoneNumber, for example, +1
4255551234.
The office phone attribute is managed by your administrator.
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.
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.
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?
8/6/2019 • 3 minutes to read • Edit Online
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.
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.
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:
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.
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)
7/2/2019 • 6 minutes to read • Edit Online
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.
Office phone No No No
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.
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.
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
3/22/2019 • 11 minutes to read • Edit Online
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
Authentication methods
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
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.
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.
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.
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.
On-premises integration
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.
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
7/30/2019 • 3 minutes to read • Edit Online
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.
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 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
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
Password policies and restrictions in Azure Active
Directory
5/16/2019 • 6 minutes to read • Edit Online
This article describes the password policies and complexity requirements associated with user accounts in your
Azure Active Directory (Azure AD ) tenant.
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
PROPERTY REQUIREMENTS
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.
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:
To see the Password never expires setting for all users, run the following cmdlet:
To set the passwords of all users in the organization so that they expire, use the following cmdlet:
To set the passwords of all the users in an organization to never expire, run the following cmdlet:
Next steps
The following articles provide additional information about 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 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
Licensing requirements for Azure AD self-service
password reset
8/8/2019 • 2 minutes to read • Edit Online
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.
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
Next steps
How do I complete a successful rollout of SSPR?
Reset or change your password
Register for self-service password reset
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
What is password writeback?
7/26/2019 • 9 minutes to read • Edit Online
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
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.
WARNING
Standalone Office 365 licensing plans don't support "Self-Service Password Reset/Change/Unlock with on-premises
writeback" and require that you have one of the preceding plans for this functionality to work.
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.
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
8/8/2019 • 2 minutes to read • Edit Online
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.
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
6/4/2019 • 5 minutes to read • Edit Online
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.
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.
MULTI-FACTOR MULTI-FACTOR
AUTHENTICATION FOR OFFICE AUTHENTICATION FOR AZURE AZURE MULTI-FACTOR
FEATURE 365 AD ADMINISTRATORS AUTHENTICATION
PIN mode ●
Fraud alert ●
MFA Reports ●
One-Time Bypass ●
Trusted IPs ●
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
7/21/2019 • 2 minutes to read • Edit Online
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.
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
3/22/2019 • 6 minutes to read • Edit Online
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.
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.
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
8/5/2019 • 13 minutes to read • Edit Online
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.
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 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?
In some instances, yes.
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.
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
7/12/2019 • 9 minutes to read • Edit Online
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.
NOTE
Cyber-criminals also use similar strategies in their attacks. Therefore Microsoft does not publish the contents of this list
publicly.
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.
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.
'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
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.
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
4/26/2019 • 5 minutes to read • Edit Online
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.
Download
The two required agent installers for Azure AD password protection are available from the Microsoft Download
Center.
Next steps
Deploy Azure AD password protection
Create a resilient access control management strategy
with Azure Active Directory
8/4/2019 • 16 minutes to read • Edit Online
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?
Microsoft recommendations
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:
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.
Microsoft recommendations
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
8/8/2019 • 11 minutes to read • Edit Online
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.
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
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
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.
Auditing backup
Reporting 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.
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
3/22/2019 • 4 minutes to read • Edit Online
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.
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.
Fields populated
If you use the default settings in Azure AD Connect, the following mappings are made:
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.
Connect-MsolService
Connect-MsolService
Connect-MsolService
Get-MsolUser -UserPrincipalName user@domain.com | select -Expand StrongAuthenticationUserDetails | select
PhoneNumber
Get-MsolUser -UserPrincipalName user@domain.com | select -Expand StrongAuthenticationUserDetails | select
Email
Get-Module AzureADPreview
Install-Module AzureADPreview
Connect-AzureAD
Connect-AzureAD
Next steps
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 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
How-to: Configure password writeback
3/21/2019 • 3 minutes to read • Edit Online
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
Enterprise Mobility + Security E3 or A3
Enterprise Mobility + Security E5 or A5
Microsoft 365 E3 or A3
Microsoft 365 E5 or A5
Microsoft 365 F1
Microsoft 365 Business
WARNING
Standalone Office 365 licensing plans don't support "Self-Service Password Reset/Change/Unlock with on-premises
writeback" and require that you have one of the preceding plans for this functionality to work.
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
7/17/2019 • 5 minutes to read • Edit Online
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.
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.
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}
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
8/8/2019 • 15 minutes to read • Edit Online
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
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.
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.
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.
4. Click on Save.
5. Close the service settings tab.
# 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 {
if ($KeepMethods) {
# Restore the MFA methods which got cleared when disabling MFA
Set-MsolUser -ObjectId $User.ObjectId `
-StrongAuthenticationMethods $User.StrongAuthenticationMethods
}
}
}
[CmdletBinding()]
param(
[Parameter(ValueFromPipelineByPropertyName=$True)]
$ObjectId,
[Parameter(ValueFromPipelineByPropertyName=$True)]
$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
}
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.
Value set to True / not set Not enrolled MFA challenge is unsuccessful
SETTINGS USER MFA STATUS EFFECTS
<MfaPerformed>true</MfaPerformed>
<MfaMethod>MFA</MfaMethod>
TIP
Government cloud users can enroll at https://aka.ms/GovtMFASetup
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.
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
8/7/2019 • 5 minutes to read • Edit Online
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.
NOTE
More information about licenses and pricing can be found on the Azure AD and Multi-Factor Authentication pricing pages.
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.
TIP
Enabled users are automatically switched to Enforced when they register for Azure MFA. Do not manually change the
user state to Enforced.
TIP
Don't forget to connect first using Connect-MsolService
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
}
# 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 {
if ($KeepMethods) {
# Restore the MFA methods which got cleared when disabling MFA
Set-MsolUser -ObjectId $User.ObjectId `
-StrongAuthenticationMethods $User.StrongAuthenticationMethods
}
}
}
[CmdletBinding()]
param(
[Parameter(ValueFromPipelineByPropertyName=$True)]
$ObjectId,
[Parameter(ValueFromPipelineByPropertyName=$True)]
$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
}
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
7/26/2019 • 3 minutes to read • Edit Online
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
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.
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
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
Configure Azure Multi-Factor Authentication settings
7/26/2019 • 21 minutes to read • Edit Online
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
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
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
FEATURE DESCRIPTION
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.
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
1. Sign in to the Azure portal as an administrator.
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.
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.
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.
Retry (Standard) Thank you for using the Microsoft's sign-in verification
system. Please press the pound key to finish your verification.
Greeting (Standard) Thank you for using the Microsoft's sign-in verification
system. Please press the pound key to finish your 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.
Please enter your PIN followed by 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.
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
system. Please press the pound key to finish your verification.
Activation retry (Standard) Thank you for using the Microsoft's sign-in verification
system. Please press the pound key to finish your verification.
Activation 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.
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
1. Sign in to the Azure portal as an administrator.
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
1. Sign in to the Azure portal.
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
1. Sign in to the Azure portal as an administrator.
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.
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.
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.
NOTE
We recommend that you create one app password per device, rather than one app password per application.
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:
1. Sign in to the Azure portal.
2. On the left, select Azure Active Directory > Users and groups > All users.
3. Select Multi-Factor Authentication.
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.
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
1. Sign in to the Azure portal.
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
1. Sign in to the Azure portal.
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
1. Sign in to the Azure portal.
2. On the left, select Azure Active Directory > Users.
3. Select Multi-Factor Authentication.
4. Under Multi-Factor Authentication, select service settings.
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.
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.
Next steps
Modify Azure AD sign-in page branding
Getting started with Azure Multi-Factor
Authentication and Active Directory Federation
Services
3/22/2019 • 2 minutes to read • Edit Online
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
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.
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.
5. On the Add Transform Claim Rule Wizard, select Pass Through or Filter an Incoming Claim from the
drop-down and click Next.
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.
9. On Issuance Transform Rules, click Add Rule.
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);
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://login.microsoftonline.com
https://provisioningapi.microsoftonline.com
https://aadcdn.msauth.net
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.
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.
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 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 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.
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
5/21/2019 • 2 minutes to read • Edit Online
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:
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.
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:
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
7/9/2019 • 2 minutes to read • Edit Online
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.
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
4/29/2019 • 18 minutes to read • Edit Online
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.
Windows Server software
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.
Azure Active Directory GUID ID
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.
IMPORTANT
Be sure you do not install the NPS extension on your Remote Desktop Gateway server.
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.
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.
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.
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.
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
8/5/2019 • 18 minutes to read • Edit Online
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
Windows Server software
Libraries
Azure Active Directory (Azure AD ) synced with on-premises Active Directory
Azure Active Directory GUID ID
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.
Windows Server software
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.
Azure Active Directory GUID ID
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.
NOTE
If you already have a working VPN server that uses a centralized RADIUS server for authentication, you can skip this section.
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.
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.
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.
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)
6/13/2019 • 2 minutes to read • Edit Online
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.
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://login.microsoftonline.com
https://mysignins.microsoft.com
https://account.activedirectory.windowsazure.com
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
Configure Azure Multi-Factor Authentication
Troubleshooting combined security info registration
What is the location condition in Azure Active Directory Conditional Access?
Troubleshooting combined security information
registration (preview)
4/10/2019 • 5 minutes to read • Edit Online
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:
User registered all required Success User registered all required This event occurs when a
security info security info. user has successfully
completed registration.
ACTIVITY STATUS REASON DESCRIPTION
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
method. Method can be
Authenticator app, Phone,
Email, Security questions,
App password, Alternate
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
Authenticator app, Phone,
Email, Security questions,
App password, Alternate
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
method. 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.
ACTIVITY STATUS REASON DESCRIPTION
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.
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.
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.
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
)
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
}
}
Write-Host ""
Start-Sleep -Milliseconds 750
}
# Connect
Import-Module MSOnline
Connect-MsolService
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>
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
7/10/2019 • 2 minutes to read • Edit Online
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.
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.
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
Deploy Azure AD password protection
8/7/2019 • 15 minutes to read • Edit Online
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
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.
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.
$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.
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.
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.
$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>
<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.
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.
Get-AzureADPasswordProtectionProxyConfiguration | fl
ServiceName : AzureADPasswordProtectionProxy
DisplayName : Azure AD password protection Proxy
StaticPort : 0
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.
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.
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
3/21/2019 • 2 minutes to read • Edit Online
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.
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
8/7/2019 • 12 minutes to read • Edit Online
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.
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:
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:
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.
UserName: BPL_03283841185
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.
UserName: BPL_03283841185
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
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.
Sample event log message for Event ID 30006 (new policy being enforced)
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.
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.
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.
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.
If autoupgrade is disabled, refer to the following link for the latest version available:
https://aka.ms/AzureADPasswordProtectionAgentSoftwareVersions
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.
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:
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.
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.
If autoupgrade is disabled, refer to the following link for the latest version available:
https://aka.ms/AzureADPasswordProtectionAgentSoftwareVersions
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
8/4/2019 • 12 minutes to read • Edit Online
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.
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.
Just like in the above issue, any Azure AD Password Protection password validation outcome event will have
empty user names for this scenario.
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.
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.
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:
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:
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
8/8/2019 • 9 minutes to read • Edit Online
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!
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!
Deploy Azure AD password protection
Azure AD Password Protection agent version history
7/9/2019 • 5 minutes to read • Edit Online
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
Release date: 3/13/2019
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
Release date: 2/1/2019
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}
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
Release date: 11/01/2018
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
Release date: 8/17/2018
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
Release date: 6/15/2018
Initial public preview release
Next steps
Deploy Azure AD Password Protection
Azure Active Directory smart lockout
8/8/2019 • 4 minutes to read • Edit Online
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.
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)
8/6/2019 • 5 minutes to read • Edit Online
Requirements
Azure Multi-Factor Authentication
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
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.
Next steps
Learn about device registration
Learn about Azure Multi-Factor Authentication
Enable passwordless sign-in with the Microsoft
Authenticator app (preview)
8/6/2019 • 4 minutes to read • Edit Online
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.
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
3/21/2019 • 5 minutes to read • Edit Online
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.
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.
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:
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]
$msolcred = get-credential
connect-msolservice -credential $msolcred
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).
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
3/22/2019 • 2 minutes to read • Edit Online
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
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 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 Teams
OneNote
OneDrive
Outlook
Power BI
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
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
3/22/2019 • 2 minutes to read • Edit Online
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
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 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 Teams
OneNote
OneDrive
Outlook
Power BI
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
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)
7/3/2019 • 3 minutes to read • Edit Online
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.
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
7/2/2019 • 9 minutes to read • Edit Online
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.
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
SSPR and MFA usage and insights reporting
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?
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
Reports in Azure Multi-Factor Authentication
7/2/2019 • 9 minutes to read • Edit Online
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:
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.
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_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_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_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_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_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_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_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.
CALL RESULT DESCRIPTION BROAD DESCRIPTION
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_INVALID_RESULT Mobile App Invalid Result The mobile app returned an invalid
result.
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.
Next steps
SSPR and MFA usage and insights reporting
For Users
Where to deploy
Azure Multi-Factor Authentication user data
collection
3/25/2019 • 4 minutes to read • Edit Online
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
Next steps
MFA Server reporting
Getting started with the Azure Multi-Factor
Authentication Server
6/12/2019 • 9 minutes to read • Edit Online
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.
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:
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:
Follow these steps to download the Azure Multi-Factor Authentication Server from the Azure portal:
1. Sign in to the Azure portal as an administrator.
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.
IMPORTANT
Starting in March of 2019 the phone call options will not be available to MFA Server 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.
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
6/12/2019 • 11 minutes to read • Edit Online
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
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.
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.
Deploy the user portal on the same server as the Azure Multi-Factor
Authentication Server
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.
If you have questions about configuring an SSL Certificate on an IIS server, see the article How to Set Up SSL on
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.
If you have questions about configuring an SSL Certificate on an IIS server, see the article How to Set Up SSL on
IIS.
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 URL Enter the URL of where the portal is being hosted.
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 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.
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.
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
6/12/2019 • 2 minutes to read • Edit Online
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
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.
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
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
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.
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
Authentication Server
6/12/2019 • 6 minutes to read • Edit Online
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
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.
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.
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-
Factor Authentication Server
6/12/2019 • 4 minutes to read • Edit Online
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
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.
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
Authentication Server
6/12/2019 • 2 minutes to read • Edit Online
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
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.
NOTE
This feature is not supported to secure Terminal Services on Windows Server 2012 R2.
Next steps
Configure third-party VPN appliances for Azure MFA Server
Augment your existing authentication infrastructure with the NPS extension for Azure MFA
Configure Azure Multi-Factor Authentication Server
for IIS web apps
6/12/2019 • 4 minutes to read • Edit Online
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
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.
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
Authentication Server
7/2/2019 • 5 minutes to read • Edit Online
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
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.
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.
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
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.
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.
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
7/2/2019 • 16 minutes to read • Edit Online
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Synchronize every Specify the time interval the Multi-Factor Auth Server service
will wait between polling and processing changes.
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.
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.
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.
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
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.
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.
Configure Azure Multi-Factor Authentication Server
to work with AD FS in Windows Server
6/12/2019 • 8 minutes to read • Edit Online
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
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.
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.
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
6/12/2019 • 4 minutes to read • Edit Online
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 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.
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 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 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 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
Configure Azure Multi-Factor Authentication settings
Resolve error messages from the NPS extension for
Azure Multi-Factor Authentication
7/2/2019 • 8 minutes to read • Edit Online
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.
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.
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.
ERROR CODE TROUBLESHOOTING STEPS
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.
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,
contact support for further help.
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.
ALTERNATE_LOGIN_ID_ERROR Error: Alternate LoginId value is empty Verify that the AlternateLoginId
attribute is configured for the user.
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
instructions in Manage your settings for
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
instructions in Manage your settings 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,
contact support for troubleshooting
help.
ERROR CODE ERROR MESSAGE TROUBLESHOOTING STEPS
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,
contact support for troubleshooting
help.
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.
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
Incorrect them try again by requesting a new
code or signing in again.
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
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.
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.
Register for self-service 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.
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.
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.
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.
User registrations show multiple times. Currently, when a user registers, we log each individual piece
of data that's registered as a separate event.
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.
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.
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.
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.
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”.
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.
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.
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).
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.
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.
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.
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.
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'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:
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 have a question that was not covered somewhere else
Password management frequently asked questions
6/25/2019 • 11 minutes to read • Edit Online
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
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.
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 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.
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.
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.
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.
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: 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: How many questions can I configure for the security questions authentication option?
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.
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.
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.
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.
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.
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: 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.
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.
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.
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.
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
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?
Frequently asked questions about Azure Multi-Factor
Authentication
8/5/2019 • 13 minutes to read • Edit Online
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.
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 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?
In some instances, yes.
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.
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
Azure Multi-Factor Authentication
7/2/2019 • 8 minutes to read • Edit Online
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.
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.
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.
ERROR CODE 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,
contact support for further help.
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.
ALTERNATE_LOGIN_ID_ERROR Error: Alternate LoginId value is empty Verify that the AlternateLoginId
attribute is configured for the user.
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
instructions in Manage your settings
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
instructions in Manage your settings
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,
contact support for troubleshooting
help.
ERROR CODE ERROR MESSAGE TROUBLESHOOTING STEPS
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,
contact support for troubleshooting
help.
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.
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
Incorrect them try again by requesting a new
code or signing in again.
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
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
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.
Next steps
Sign up for Azure as an organization
How Azure subscriptions are associated with Azure AD
What's new in Azure Active Directory?
8/6/2019 • 35 minutes to read • Edit Online
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
Type: Plan for change
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
Type: Plan for change
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.
Automate user account provisioning for these newly supported SaaS apps
Type: New feature
Service category: Enterprise Apps
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 reports are available for all Azure AD administrators (Public Preview)
Type: New feature
Service category: Identity Protection
Product capability: Identity Security & 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.
Automate user account provisioning for these newly supported SaaS apps
Type: New feature
Service category: Enterprise Apps
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.
Activity logs (MS Graph APIs) for Azure AD are now available through PowerShell Cmdlets
Type: New feature
Service category: Reporting
Product capability: Monitoring & 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
Service category: Reporting
Product capability: Monitoring & Reporting
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
Service category: Identity Protection
Product capability: Identity Security & Protection
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.
Automate user account provisioning for these newly supported SaaS apps
Type: New feature
Service category: Enterprise Apps
Product capability: Monitoring & Reporting
You can now automate creating, updating, and deleting user accounts for these newly integrated apps:
Zoom
Envoy
Proxyclick
4me
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
Azure Multi-Factor Authentication (MFA ) Server is no longer available for new deployments
Type: Deprecated
Service category: MFA
Product capability: Identity Security & Protection
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
Type: Plan for change
Service category: App Proxy
Product capability: Access Control
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
Service category: Enterprise Apps
Product capability: Monitoring & Reporting
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
New capabilities available in the Risky Users API for Identity Protection
Type: New feature
Service category: Identity Protection
Product capability: Identity Security & Protection
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.
Configure a naming policy for Office 365 groups in Azure AD portal (General availability)
Type: Changed feature
Service category: Group Management
Product capability: Collaboration
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)
Type: Changed feature
Service category: Reporting
Product capability: Monitoring & Reporting
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
Product capability: Identity Security & Protection
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
Product capability: Identity Security & 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.
Configure a naming policy for Office 365 groups in Azure AD portal (Public preview)
Type: New feature
Service category: Group Management
Product capability: Collaboration
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
Service category: Reporting
Product capability: Monitoring & Reporting
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.
Azure AD Connect email alert system(s) are transitioning, sending new email sender information for some
customers
Type: Changed feature
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
Service category: Conditional Access
Product capability: Identity Security & Protection
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
Service category: Conditional Access
Product capability: Identity Security & Protection
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
Product capability: B2B/B2C
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 Zscaler and Atlassian provisioning connectors in the Azure AD gallery - March 2019
Type: New feature
Service category: App Provisioning
Product capability: 3rd Party Integration
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,
see Automate user provisioning to SaaS applications with Azure AD.
Restore and manage your deleted Office 365 groups in the Azure AD portal
Type: New feature
Service category: Group Management
Product capability: Collaboration
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
Service category: App Proxy
Product capability: Access Control
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
Service category: Authentications (Logins)
Product capability: User Authentication
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 warnings and guidance to help prevent accidental administrator lockout from misconfigured Conditional
Access policies
Type: Changed feature
Service category: Conditional Access
Product capability: Identity Security & Protection
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.
February 2019
Configurable Azure AD SAML token encryption (Public preview)
Type: New feature
Service category: Enterprise Apps
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