+ Title: Enable accidental deletions prevention in the Microsoft Entra provisioning service

+description: Enable accidental deletions prevention in the Microsoft Entra provisioning service for applications and cross-tenant synchronization.

+# Enable accidental deletions prevention in the Microsoft Entra provisioning service

+The Microsoft Entra provisioning service includes a feature to help avoid accidental deletions. This feature ensures that users aren't disabled or deleted in an application unexpectedly.

+The Microsoft Entra provisioning service includes a feature to help avoid accidental deletions. This feature ensures that users aren't disabled or deleted in the target tenant unexpectedly.

+description: How to troubleshoot common issues faced when you don't see users appearing in a Microsoft Entra Gallery Application you have configured for user provisioning with Microsoft Entra ID

+After automatic provisioning has been configured for an application (including verifying that the app credentials provided to Microsoft Entra ID to connect to the app are valid), then users and/or groups are provisioned to the app. Provisioning is determined by the following things:

+- Which users and groups have been **assigned** to the application. Note that provisioning nested groups are not supported. For more information on assignment, see [Assign a user or group to an enterprise app in Microsoft Entra ID](../manage-apps/assign-user-or-group-access-portal.md).

+- Whether or not **attribute mappings** are enabled, and configured to sync valid attributes from Microsoft Entra ID to the app. For more information on attribute mappings, see [Customizing User Provisioning Attribute Mappings for SaaS Applications in Microsoft Entra ID](customize-application-attributes.md).

+If you observe that users are not being provisioned, consult the [Provisioning logs (preview)](../reports-monitoring/concept-provisioning-logs.md?context=azure/active-directory/manage-apps/context/manage-apps-context) in Microsoft Entra ID. Search for log entries for a specific user.

+The provisioning logs record all the operations performed by the provisioning service, including querying Microsoft Entra ID for assigned users that are in scope for provisioning, querying the target app for the existence of those users, comparing the user objects between the system. Then add, update, or disable the user account in the target system based on the comparison.

+>An initial cycle can take anywhere from 20 minutes to several hours, depending on the size of the Microsoft Entra directory and the number of users in scope for provisioning. Subsequent syncs after the initial cycle are faster, as the provisioning service stores watermarks that represent the state of both systems after the initial cycle. The initial cycle improves performance of subsequent syncs.

+- **The user is ΓÇ£not effectively entitledΓÇ¥.** If you see this specific error message, it is because there is a problem with the user assignment record stored in Microsoft Entra ID. To fix this issue, unassign the user (or group) from the app, and reassign it again. For more information on assignment, see [Assign user or group access](../manage-apps/assign-user-or-group-access-portal.md).

+- **A required attribute is missing or not populated for a user.** An important thing to consider when setting up provisioning is to review and configure the attribute mappings and workflows that define which user (or group) properties flow from Microsoft Entra ID to the application. This configuration includes setting the ΓÇ£matching propertyΓÇ¥ that is used to uniquely identify and match users/groups between the two systems. For more information on this important process, see [Customizing User Provisioning Attribute Mappings for SaaS Applications in Microsoft Entra ID](customize-application-attributes.md).

+- **Attribute mappings for groups:** Provisioning of the group name and group details, in addition to the members, if supported for some applications. You can enable or disable this functionality by enabling or disabling the **Mapping** for group objects shown in the **Provisioning** tab. If provisioning groups is enabled, be sure to review the attribute mappings to ensure an appropriate field is being used for the ΓÇ£matching IDΓÇ¥. The matching ID can be the display name or email alias. The group and its members are not provisioned if the matching property is empty or not populated for a group in Microsoft Entra ID.

+[Microsoft Entra Connect Sync: Understanding Declarative Provisioning](../hybrid/connect/concept-azure-ad-connect-sync-declarative-provisioning.md)

+description: How to solve common protocol compatibility issues faced when adding a non-gallery application that supports SCIM 2.0 to Microsoft Entra ID

+# Known issues and resolutions with SCIM 2.0 protocol compliance of the Microsoft Entra User Provisioning service

+Microsoft Entra ID can automatically provision users and groups to any application or system that is fronted by a web service with the interface defined in the [System for Cross-Domain Identity Management (SCIM) 2.0 protocol specification](https://tools.ietf.org/html/draft-ietf-scim-api-19).

+Microsoft Entra ID's support for the SCIM 2.0 protocol is described in [Using System for Cross-Domain Identity Management (SCIM) to automatically provision users and groups from Microsoft Entra ID to applications](use-scim-to-provision-users-and-groups.md), which lists the specific parts of the protocol that it implements in order to automatically provision users and groups from Microsoft Entra ID to applications that support SCIM 2.0.

+This article describes current and past issues with the Microsoft Entra user provisioning service's adherence to the SCIM 2.0 protocol, and how to work around these issues.

+| Microsoft Entra ID requires "/scim" to be in the root of the application's SCIM endpoint URL | Yes | December 18, 2018 | downgrade to customappSSO |

+1. In a new web browser window, go to https://developer.microsoft.com/graph/graph-explorer and sign in as the administrator for the Microsoft Entra tenant where your app is added.

+1. In a new web browser window, go to https://developer.microsoft.com/graph/graph-explorer and sign in as the administrator for the Microsoft Entra tenant where your app is added.

+ Title: Problem configuring user provisioning to a Microsoft Entra Gallery app

+description: How to troubleshoot common issues faced when configuring user provisioning to an application already listed in the Microsoft Entra Application Gallery

+# Problem configuring user provisioning to a Microsoft Entra Gallery application

+You should always start by finding the setup tutorial specific to setting up provisioning for your application. Then follow those steps to configure both the app and Microsoft Entra ID to create the provisioning connection. A list of app tutorials can be found at [List of Tutorials on How to Integrate SaaS Apps with Microsoft Entra ID](../saas-apps/tutorial-list.md).

+- **Provisioning logs (preview)** ΓÇô The [provisioning logs](../reports-monitoring/concept-provisioning-logs.md?context=azure/active-directory/manage-apps/context/manage-apps-context) record all the operations performed by the provisioning service, including querying Microsoft Entra ID for assigned users that are in scope for provisioning. Query the target app for the existence of those users, comparing the user objects between the system. Then add, update, or disable the user account in the target system based on the comparison. You can access the provisioning logs in the Microsoft Entra admin center by selecting **Identity** > **Applications** > **Enterprise applications** > **Provisioning logs** in the **Activity** section.

+>An initial cycle can take anywhere from 20 minutes to several hours, depending on the size of the Microsoft Entra directory and the number of users in scope for provisioning. Subsequent syncs after the initial cycle be faster, as the provisioning service stores watermarks that represent the state of both systems after the initial cycle, improving performance of subsequent syncs.

+In order for provisioning to work, Microsoft Entra ID requires valid credentials that allow it to connect to a user management API provided by that app. If these credentials donΓÇÖt work, or you donΓÇÖt know what they are, review the tutorial for setting up this app, described previously.

+- **The user is ΓÇ£not effectively entitledΓÇ¥.** If you see this specific error message, it is because there is a problem with the user assignment record stored in Microsoft Entra ID. To fix this issue, un-assign the user (or group) from the app, and re-assign it again. For more information, see [Assign a user or group to an enterprise app](../manage-apps/assign-user-or-group-access-portal.md).

+- **A required attribute is missing or not populated for a user.** An important thing to consider when setting up provisioning be to review and configure the attribute mappings and workflows that define which user (or group) properties flow from Microsoft Entra ID to the application. This includes setting the ΓÇ£matching propertyΓÇ¥ that be used to uniquely identify and match users/groups between the two systems. For more information on this important process, see [Customizing user provisioning attribute-mappings](../app-provisioning/customize-application-attributes.md).

+ * **Attribute mappings for groups:** Provisioning of the group name and group details, in addition to the members, if supported for some applications. You can enable or disable this functionality by enabling or disabling the **Mapping** for group objects shown in the **Provisioning** tab. If provisioning groups is enabled, be sure to review the attribute mappings to ensure an appropriate field is being used for the ΓÇ£matching IDΓÇ¥. This can be the display name or email alias), as the group and its members not be provisioned if the matching property is empty or not populated for a group in Microsoft Entra ID.

+[Automate User Provisioning and Deprovisioning to SaaS Applications with Microsoft Entra ID](user-provisioning.md)

+1. Select the "Sign-In with Microsoft" button and sign in using Microsoft Entra Global Administrator or App Admin credentials.

+Applications in the Microsoft Entra application gallery each have an [application template](/graph/api/applicationtemplate-list?tabs=http&view=graph-rest-beta&preserve-view=true) that describes the metadata for that application. Using this template, you can create an instance of the application and service principal in your tenant for management. Retrieve the identifier of the application template for **AWS Single-Account Access** and from the response, record the value of the **id** property to use later in this tutorial.

+Configuring provisioning requires establishing a trust between Microsoft Entra ID and the application. Authorize access to the third-party application. The following example is for an application that requires a client secret and a secret token. Each application has its own requirements. Review the [API documentation](/graph/api/synchronization-synchronizationjob-validatecredentials?tabs=http&view=graph-rest-beta&preserve-view=true) to see the available options.

+- [Integrating a custom SCIM app with Microsoft Entra ID](./use-scim-to-provision-users-and-groups.md)

+ Title: Understand how Provisioning integrates with Azure Monitor logs in Microsoft Entra ID.

+description: Understand how Provisioning integrates with Azure Monitor logs in Microsoft Entra ID.

+- [Install and use the log analytics views for Microsoft Entra ID](../../azure-monitor/visualize/workbooks-view-designer-conversion-overview.md)

+ Title: Quarantine status in Microsoft Entra Application Provisioning

+The Microsoft Entra provisioning service monitors the health of your configuration. It also places unhealthy apps in a "quarantine" state. If most, or all, of the calls made against the target system consistently fail then the provisioning job is marked as in quarantine. An example of a failure is an error received because of invalid admin credentials.

+|**SCIM Compliance issue:** An HTTP/404 Not Found response was returned rather than the expected HTTP/200 OK response. In this case, the Microsoft Entra provisioning service has made a request to the target application and received an unexpected response.|Check the admin credentials section. See if the application requires specifying the tenant URL and that the URL is correct. If you don't see an issue, contact the application developer to ensure that their service is SCIM-compliant. https://tools.ietf.org/html/rfc7644#section-3.4.2 |

+- Check the application's provisioning settings to make sure you've [entered valid Admin Credentials](../app-provisioning/configure-automatic-user-provisioning-portal.md#configuring-automatic-user-account-provisioning). Microsoft Entra ID must establish a trust with the target application. Ensure that you have entered valid credentials and your account has the necessary permissions.

+- Review the [provisioning logs](../reports-monitoring/concept-provisioning-logs.md) to further investigate what errors are causing quarantine and address the error. Go to **Microsoft Entra ID** > **Enterprise Apps** > **Provisioning logs (preview)** in the **Activity** section.

+ Title: Find out when a specific user is able to access an app in Microsoft Entra Application Provisioning

+description: How to find out when a critically important user is able to access an application you have configured for user provisioning with Microsoft Entra ID.

+The Microsoft Entra provisioning service runs an initial provisioning cycle against the source system and target system, followed by periodic incremental cycles. When you configure provisioning for an app, you can check the current status of the provisioning service and see when a user is able to access an app.

+ On the **Provisioning** page for an app, you can view the status of the Microsoft Entra provisioning service. The **Current Status** section at the bottom of the page shows whether a provisioning cycle has started provisioning user accounts. You can watch the progress of the cycle, see how many users and groups have been provisioned, and see how many roles are created.

+- A **View Audit Logs** link, which opens the Microsoft Entra provisioning logs. To learn more about operations run by the user provisioning service, including provisioning status for individual users, see [Use provisioning logs](#use-provisioning-logs-to-check-a-users-provisioning-status) later in the article.

+To see the provisioning status for a selected user, consult the [Provisioning logs (preview)](../reports-monitoring/concept-provisioning-logs.md?context=azure/active-directory/manage-apps/context/manage-apps-context) in Microsoft Entra ID. All operations run by the user provisioning service are recorded in the Microsoft Entra provisioning logs. The logs include read and write operations made to the source and target systems. Associated user data related to read and write operations is also logged.

+* Querying Microsoft Entra ID for assigned users that are in scope for provisioning

+When you're using automatic user provisioning with an application, there are some things to keep in mind. First, Microsoft Entra ID automatically provisions and updates user accounts in an app based on things like [user and group assignment](../manage-apps/assign-user-or-group-access-portal.md). The sync happens at a regularly scheduled time interval, typically every 40 minutes.

+- For **initial cycle**, the job time depends on many factors, including the number of users and groups in scope for provisioning, and the total number of users and group in the source system. The first sync between Microsoft Entra ID and an app happen as fast as 20 minutes or take as long as several hours. The time depends on the size of the Microsoft Entra directory and the number of users in scope for provisioning. A comprehensive list of factors that affect initial cycle performance are summarized later in this section.

+The following table summarizes synchronization times for common provisioning scenarios. In these scenarios, the source system is Microsoft Entra ID and the target system is a SaaS application. The sync times are derived from a statistical analysis of sync jobs for the SaaS applications ServiceNow, Workplace, Salesforce, and G Suite.

+| Sync all users and groups in Microsoft Entra ID | < 1,000 | < 30 minutes |

+| Sync all users and groups in Microsoft Entra ID | 1,000 - 10,000 | < 30 - 120 minutes |

+| Sync all users and groups in Microsoft Entra ID | 10,000 - 100,000 | 713 - 1,425 minutes |

+| Sync all users in Microsoft Entra ID| < 1,000 | < 30 minutes |

+| Sync all users in Microsoft Entra ID | 1,000 - 10,000 | 43 - 86 minutes |

+- The total number of users, groups, and group members present in the source system (Microsoft Entra ID).

+- If performance becomes an issue, and you're attempting to provision most users and groups in your tenant, then use scoping filters. Scoping filters allow you to fine tune the data that the provisioning service extracts from Microsoft Entra ID by filtering out users based on specific attribute values. For more information on scoping filters, see [Attribute-based application provisioning with scoping filters](define-conditional-rules-for-provisioning-user-accounts.md).

+[Automate user provisioning and deprovisioning to SaaS applications with Microsoft Entra ID](user-provisioning.md)

+ Title: Report automatic user account provisioning from Microsoft Entra ID to Software as a Service (SaaS) applications

+Microsoft Entra ID includes a [user account provisioning service](user-provisioning.md). The service helps automate the provisioning deprovisioning of user accounts in SaaS apps and other systems. The automation helps with end-to-end identity lifecycle management. Microsoft Entra ID supports preintegrated user provisioning connectors for many applications and systems. To learn more about user provisioning tutorials, see [Provisioning Tutorials](../saas-apps/tutorial-list.md).

+* **Source System** - The repository of users that the Microsoft Entra provisioning service synchronizes from. Microsoft Entra ID is the source system for most preintegrated provisioning connectors, however there are some exceptions (example: Workday Inbound Synchronization).

+* **Target System** - The repository of users where the Microsoft Entra provisioning service synchronizes. The repository is typically a SaaS application, such as Salesforce, ServiceNow, G Suite, and Dropbox for Business. In some cases the repository can be an on-premises system such as Active Directory, such as Workday Inbound Synchronization to Active Directory.

+All activities performed by the provisioning service are recorded in the Microsoft Entra [provisioning logs](../reports-monitoring/concept-provisioning-logs.md?context=azure/active-directory/manage-apps/context/manage-apps-context). You can access the provisioning logs in the Microsoft Entra admin center. You can search the provisioning data based on the name of the user or the identifier in either the source system or the target system. For details, see [Provisioning logs](../reports-monitoring/concept-provisioning-logs.md?context=azure/active-directory/manage-apps/context/manage-apps-context).

+- [What is application access and single sign-on with Microsoft Entra ID?](../manage-apps/what-is-single-sign-on.md)

+ Title: User provisioning management for enterprise apps in Microsoft Entra ID

+description: Learn how to manage user account provisioning for enterprise apps using the Microsoft Entra ID.

+This article describes the general steps for managing automatic user account provisioning and deprovisioning for applications that support it. *User account provisioning* is the act of creating, updating, and/or disabling user account records in an applicationΓÇÖs local user profile store. Most cloud and SaaS applications store the role and permissions in the user's own local user profile store. The presence of such a user record in the user's local store is *required* for single sign-on and access to work. To learn more about automatic user account provisioning, see [Automate User Provisioning and Deprovisioning to SaaS Applications with Microsoft Entra ID](user-provisioning.md).

+> Microsoft Entra ID has a gallery that contains thousands of pre-integrated applications that are enabled for automatic provisioning with Microsoft Entra ID. You should start by finding the provisioning setup tutorial specific to your application in the [List of tutorials on how to integrate SaaS apps with Microsoft Entra ID](../saas-apps/tutorial-list.md). You'll likely find step-by-step guidance for configuring both the app and Microsoft Entra ID to create the provisioning connection.

+* **Automatic** - This option is shown if Microsoft Entra ID supports automatic API-based provisioning or deprovisioning of user accounts to this application. Select this mode to display an interface that helps administrators:

+ * Configure Microsoft Entra ID to connect to the application's user management API

+ * Create account mappings and workflows that define how user account data should flow between Microsoft Entra ID and the app

+ * Manage the Microsoft Entra provisioning service

+* **Manual** - This option is shown if Microsoft Entra ID doesn't support automatic provisioning of user accounts to this application. In this case, user account records stored in the application must be managed using an external process, based on the user management and provisioning capabilities provided by that application (which can include SAML Just-In-Time provisioning).

+Expand **Admin Credentials** to enter the credentials required for Microsoft Entra ID to connect to the application's user management API. The input required varies depending on the application. To learn about the credential types and requirements for specific applications, see the [configuration tutorial for that specific application](user-provisioning.md).

+Select **Test Connection** to test the credentials by having Microsoft Entra ID attempt to connect to the app's provisioning app using the supplied credentials.

+Expand **Mappings** to view and edit the user attributes that flow between Microsoft Entra ID and the target application when user accounts are provisioned or updated.

+There's a preconfigured set of mappings between Microsoft Entra user objects and each SaaS appΓÇÖs user objects. Some apps also manage group objects. Select a mapping in the table to open the mapping editor, where you can view and customize them.

+* Enabling and disabling mappings for specific objects, such as the Microsoft Entra user object to the SaaS app's user object.

+* Editing the attributes that flow from the Microsoft Entra user object to the app's user object. For more information on attribute mapping, see [Understanding attribute mapping types](customize-application-attributes.md#understanding-attribute-mapping-types).

+* Filtering the provisioning actions that Microsoft Entra ID runs on the targeted application. Instead of having Microsoft Entra ID fully synchronize objects, you can limit the actions run.

+ For example, only select **Update** and Microsoft Entra-only updates existing user accounts in an application but doesn't create new ones. Only select **Create** and Azure only creates new user accounts but doesn't update existing ones. This feature lets admins create different mappings for account creation and update workflows.

+If provisioning is being enabled for the first time for an application, turn on the service by changing the **Provisioning Status** to **On**. This change causes the Microsoft Entra provisioning service to run an initial cycle. It reads the users assigned in the **Users and groups** section, queries the target application for them, and then runs the provisioning actions defined in the Microsoft Entra ID **Mappings** section. During this process, the provisioning service stores cached data about what user accounts it's managing. The service stores cached data so nonmanaged accounts inside the target applications that were never in scope for assignment aren't affected in deprovisioning operations. After the initial cycle, the provisioning service automatically synchronizes user and group objects on a forty-minute interval.

+ Title: Tutorial - Customize Microsoft Entra attribute mappings in Application Provisioning

+description: Learn about attribute mappings for Software as a Service (SaaS) apps in Microsoft Entra Application Provisioning. Learn what attributes are and how you can modify them to address your business needs.

+# Tutorial - Customize user provisioning attribute-mappings for SaaS applications in Microsoft Entra ID

+Microsoft Entra ID provides support for user provisioning to third-party SaaS applications such as Salesforce, G Suite and others. If you enable user provisioning for a third-party SaaS application, the Microsoft Entra admin center controls its attribute values through attribute-mappings.

+- [Quickstart Series on App Management in Microsoft Entra ID](../manage-apps/view-applications-portal.md)

+There's a preconfigured set of attributes and attribute-mappings between Microsoft Entra user objects and each SaaS app's user objects. Some apps manage other types of objects along with Users, such as Groups.

+1. Expand **Mappings** to view and edit the user attributes that flow between Microsoft Entra ID and the target application. If the target application supports it, this section lets you optionally configure provisioning of groups and user accounts.

+ In this screenshot, you can see that the **Username** attribute of a managed object in Salesforce is populated with the **userPrincipalName** value of the linked Microsoft Entra Object.

+1. Select an existing **Attribute Mapping** to open the **Edit Attribute** screen. Here you can edit the user attributes that flow between Microsoft Entra ID and the target application.

+- **Direct** ΓÇô the target attribute is populated with the value of an attribute of the linked object in Microsoft Entra ID.

+- **Expression** - the target attribute is populated based on the result of a script-like expression. For more information about expressions, see [Writing Expressions for Attribute-Mappings in Microsoft Entra ID](../app-provisioning/functions-for-customizing-application-data.md).

+Along with these four basic types, custom attribute-mappings support the concept of an optional **default** value assignment. The default value assignment ensures that a target attribute is populated with a value if there's not a value in Microsoft Entra ID or on the target object. The most common configuration is to leave this blank.

+- **Source attribute** - The user attribute from the source system (example: Microsoft Entra ID).

+- **Default value if null (optional)** - The value that is passed to the target system if the source attribute is null. This value is only provisioned when a user is created. The "default value when null" isn't provisioned when updating an existing user. For example, add a default value for job title, when creating a user, with the expression: `Switch(IsPresent([jobTitle]), "DefaultValue", "True", [jobTitle])`. For more information about expressions, see [Reference for writing expressions for attribute mappings in Microsoft Entra ID](../app-provisioning/functions-for-customizing-application-data.md).

+- **Match objects using this attribute** ΓÇô Whether this mapping should be used to uniquely identify users between the source and target systems. It's typically set on the userPrincipalName or mail attribute in Microsoft Entra ID, which is typically mapped to a username field in a target application.

+The Microsoft Entra provisioning service can be deployed in both "green field" scenarios (where users don't exist in the target system) and "brownfield" scenarios (where users already exist in the target system). To support both scenarios, the provisioning service uses the concept of matching attributes. Matching attributes allow you to determine how to uniquely identify a user in the source and match the user in the target. As part of planning your deployment, identify the attribute that can be used to uniquely identify a user in the source and target systems. Things to note:

+The user attributes supported for a given application are preconfigured. Most application's user management APIs don't support schema discovery. So, the Microsoft Entra provisioning service isn't able to dynamically generate the list of supported attributes by making calls to the application.

+However, some applications support custom attributes, and the Microsoft Entra provisioning service can read and write to custom attributes. To enter their definitions into the Microsoft Entra admin center, select the **Show advanced options** check box at the bottom of the **Attribute Mapping** screen, and then select **Edit attribute list for** your app.

+- Workday to Active Directory / Workday to Microsoft Entra ID

+- SuccessFactors to Active Directory / SuccessFactors to Microsoft Entra ID

+- Microsoft Entra ID ([Azure AD Graph API default attributes](/previous-versions/azure/ad/graph/api/entity-and-complex-type-reference#user-entity) and custom directory extensions are supported). For more information about creating extensions, see [Syncing extension attributes for Microsoft Entra Application Provisioning](./user-provisioning-sync-attributes-for-mapping.md) and [Known issues for provisioning in Microsoft Entra ID](./known-issues.md).

+- Microsoft Entra ID supports writeback to Workday or SuccessFactors for XPATH and JSONPath metadata. Microsoft Entra ID doesn't support new Workday or SuccessFactors attributes not included in the default schema.

+> When a directory extension attribute in Microsoft Entra ID doesn't show up automatically in your attribute mapping drop-down, you can manually add it to the "Microsoft Entra attribute list". When manually adding Microsoft Entra directory extension attributes to your provisioning app, note that directory extension attribute names are case-sensitive. For example: If you have a directory extension attribute named `extension_53c9e2c0exxxxxxxxxxxxxxxx_acmeCostCenter`, make sure you enter it in the same format as defined in the directory. Provisioning multi-valued directory extension attributes is not supported.

+These instructions are only applicable to SCIM-enabled applications. Applications such as ServiceNow and Salesforce aren't integrated with Microsoft Entra ID using SCIM, and therefore they don't require this specific namespace when adding a custom attribute.

+Custom attributes can't be referential attributes, multi-value or complex-typed attributes. Custom multi-value and complex-typed extension attributes are currently supported only for applications in the gallery. The custom extension schema header is omitted in the example because it isn't sent in requests from the Microsoft Entra SCIM client.

+- Mapping an appRoleAssignment in Microsoft Entra ID to a role in your application requires that you transform the attribute using an [expression](../app-provisioning/functions-for-customizing-application-data.md). The appRoleAssignment attribute **shouldn't be mapped directly** to a role attribute without using an expression to parse the role details.

+ - The AppRoleAssignmentsComplex only supports the PATCH add function. For multi-role SCIM applications, roles deleted in Microsoft Entra ID will therefore not be deleted from the application. We're working to support additional PATCH functions and address the limitation.

+Certain attributes such as phoneNumbers and emails are multi-value attributes where you may need to specify different types of phone numbers or emails. Use the expression for multi-value attributes. It allows you to specify the attribute type and map that to the corresponding Microsoft Entra user attribute for the value.

+Should you need to start over and reset your existing mappings back to their default state, you can select the **Restore default mappings** check box and save the configuration. Doing so sets all mappings and scoping filters as if the application was added to your Microsoft Entra tenant from the application gallery.

+- Microsoft Entra ID provides an efficient implementation of a synchronization process. In an initialized environment, only objects requiring updates are processed during a synchronization cycle.

+- The attribute `IsSoftDeleted` is often part of the default mappings for an application. `IsSoftdeleted` can be true in one of four scenarios: 1) The user is out of scope due to being unassigned from the application. 2) The user is out of scope due to not meeting a scoping filter. 3) The user has been soft deleted in Microsoft Entra ID. 4) The property `AccountEnabled` is set to false on the user. It's not recommended to remove the `IsSoftDeleted` attribute from your attribute mappings.

+- The Microsoft Entra provisioning service doesn't support provisioning null values.

+- [Using SCIM to enable automatic provisioning of users and groups from Microsoft Entra ID to applications](use-scim-to-provision-users-and-groups.md)

+ Title: Scoping users or groups to be provisioned with scoping filters in Microsoft Entra ID

+description: Learn how to use scoping filters to define attribute-based rules that determine which users or groups are provisioned in Microsoft Entra ID.

+Learn how to use scoping filters in the Microsoft Entra provisioning service to define attribute based rules. The rules are used to determine which users or groups are provisioned.

+You use scoping filters to prevent objects in applications that support automated user provisioning from being provisioned if an object doesn't satisfy your business requirements. A scoping filter allows you to include or exclude any users who have an attribute that matches a specific value. For example, when provisioning users from Microsoft Entra ID to a SaaS application used by a sales team, you can specify that only users with a "Department" attribute of "Sales" should be in scope for provisioning.

+* **Outbound provisioning from Microsoft Entra ID to SaaS applications**. When Microsoft Entra ID is the source system, [user and group assignments](../manage-apps/assign-user-or-group-access-portal.md) are the most common method for determining which users are in scope for provisioning. These assignments also are used for enabling single sign-on and provide a single method to manage access and provisioning. Scoping filters can be used optionally, in addition to assignments or instead of them, to filter users based on attribute values.

+* **Inbound provisioning from HCM applications to Microsoft Entra ID and Active Directory**. When an [HCM application such as Workday](../saas-apps/workday-tutorial.md) is the source system, scoping filters are the primary method for determining which users should be provisioned from the HCM application to Active Directory or Microsoft Entra ID.

+By default, Microsoft Entra provisioning connectors don't have any attribute-based scoping filters configured.

+When Microsoft Entra ID is the source system, [user and group assignments](../manage-apps/assign-user-or-group-access-portal.md) are the most common method for determining which users are in scope for provisioning. Reducing the number of users in scope improves performance and synchronizing assigned users and groups instead of synchronizing all users and groups is recommended.

+Scoping filters can be used optionally, in addition to scoping by assignment. A scoping filter allows the Microsoft Entra provisioning service to include or exclude any users who have an attribute that matches a specific value. For example, when provisioning users from a sales team, you can specify that only users with a "Department" attribute of "Sales" should be in scope for provisioning.

+Each user or group processed by the Microsoft Entra provisioning service is always evaluated individually against each scoping filter.

+Scoping filters are configured as part of the attribute mappings for each Microsoft Entra user provisioning connector. The following procedure assumes that you already set up automatic provisioning for [one of the supported applications](../saas-apps/tutorial-list.md) and are adding a scoping filter to it.

+5. In the **Mappings** section, select the mapping that you want to configure a scoping filter for: for example, "Synchronize Microsoft Entra Users to ServiceNow".

+5. In the **Mappings** section, select the mapping that you want to configure a scoping filter for: for example, "Provision Microsoft Entra Users".

+* [Use SCIM to enable automatic provisioning of users and groups from Microsoft Entra ID to applications](../app-provisioning/use-scim-to-provision-users-and-groups.md)

+ Title: Export Application Provisioning configuration and roll back to a known good state for disaster recovery in Microsoft Entra ID

+description: Learn how to export your Application Provisioning configuration and roll back to a known good state for disaster recovery in Microsoft Entra ID.

+You can use the Microsoft Graph API and the Microsoft Graph Explorer to export your User Provisioning attribute mappings and schema to a JSON file and import it back into Microsoft Entra ID. You can also use the steps captured here to create a backup of your provisioning configuration.

+1. Click on the "Sign-In with Microsoft" button and sign-in using Microsoft Entra Global Administrator or App Admin credentials.

+ Title: Understand how expression builder works with Application Provisioning in Microsoft Entra ID

+description: Understand how expression builder works with Application Provisioning in Microsoft Entra ID.

+ Title: Reference for writing expressions for attribute mappings in Microsoft Entra Application Provisioning

+description: Learn how to use expression mappings to transform attribute values into an acceptable format during automated provisioning of SaaS app objects in Microsoft Entra ID. Includes a reference list of functions.

+# Reference for writing expressions for attribute mappings in Microsoft Entra ID

+Used to provision multiple roles for a user. For detailed usage, see [Tutorial - Customize user provisioning attribute-mappings for SaaS applications in Microsoft Entra ID](customize-application-attributes.md#provisioning-a-role-to-a-scim-app).

+Example: You need to take a comma-delimited list of strings, and split them into an array that can be plugged into a multi-value attribute like Salesforce's PermissionSets attribute. In this example, a list of permission sets has been populated in extensionAttribute5 in Microsoft Entra ID.

+Example: Define the time zone of the user based on the state code stored in Microsoft Entra ID.

+* [Using SCIM to enable automatic provisioning of users and groups from Microsoft Entra ID to applications](../app-provisioning/use-scim-to-provision-users-and-groups.md)

+ Title: Understand how Application Provisioning in Microsoft Entra ID

+description: Understand how Application Provisioning works in Microsoft Entra ID.

+# How Application Provisioning works in Microsoft Entra ID

+Automatic provisioning refers to creating user identities and roles in the cloud applications that users need to access. In addition to creating user identities, automatic provisioning includes the maintenance and removal of user identities as status or roles change. Before you start a deployment, you can review this article to learn how Microsoft Entra provisioning works and get configuration recommendations.

+The **Microsoft Entra provisioning service** provisions users to SaaS apps and other systems by connecting to a System for Cross-Domain Identity Management (SCIM) 2.0 user management API endpoint provided by the application vendor. This SCIM endpoint allows Microsoft Entra ID to programmatically create, update, and remove users. For selected applications, the provisioning service can also create, update, and remove extra identity-related objects, such as groups and roles. The channel used for provisioning between Microsoft Entra ID and the application is encrypted using HTTPS TLS 1.2 encryption.

+

+*Figure 1: The Microsoft Entra provisioning service*

+*Figure 2: "Outbound" user provisioning workflow from Microsoft Entra ID to popular SaaS applications*

+*Figure 3: "Inbound" user provisioning workflow from popular Human Capital Management (HCM) applications to Microsoft Entra ID and Windows Server Active Directory*

+The Microsoft Entra provisioning service uses the [SCIM 2.0 protocol](https://techcommunity.microsoft.com/t5/Identity-Standards-Blog/bg-p/IdentityStandards) for automatic provisioning. The service connects to the SCIM endpoint for the application, and uses SCIM user object schema and REST APIs to automate the provisioning and deprovisioning of users and groups. A SCIM-based provisioning connector is provided for most applications in the Microsoft Entra gallery. Developers use the SCIM 2.0 user management API in Microsoft Entra ID to build endpoints for their apps that integrate with the provisioning service. For details, see [Build a SCIM endpoint and configure user provisioning](../app-provisioning/use-scim-to-provision-users-and-groups.md).

+To request an automatic Microsoft Entra provisioning connector for an app that doesn't currently have one, see [Microsoft Entra Application Request](../manage-apps/v2-howto-app-gallery-listing.md).

+Credentials are required for Microsoft Entra ID to connect to the application's user management API. While you're configuring automatic user provisioning for an application, you need to enter valid credentials. For gallery applications, you can find credential types and requirements for the application by referring to the app tutorial. For non-gallery applications, you can refer to the [SCIM](./use-scim-to-provision-users-and-groups.md#authorization-to-provisioning-connectors-in-the-application-gallery) documentation to understand the credential types and requirements. In the Microsoft Entra admin center, you're able to test the credentials by having Microsoft Entra ID attempt to connect to the app's provisioning app using the supplied credentials.

+When you enable user provisioning for a third-party SaaS application, the Microsoft Entra admin center controls its attribute values through attribute mappings. Mappings determine the user attributes that flow between Microsoft Entra ID and the target application when user accounts are provisioned or updated.

+There's a preconfigured set of attributes and attribute mappings between Microsoft Entra user objects and each SaaS appΓÇÖs user objects. Some apps manage other types of objects along with Users, such as Groups.

+When setting up provisioning, it's important to review and configure the attribute mappings and workflows that define which user (or group) properties flow from Microsoft Entra ID to the application. Review and configure the matching property (**Match objects using this attribute**) that is used to uniquely identify and match users/groups between the two systems.

+For outbound provisioning from Microsoft Entra ID to a SaaS application, relying on [user or group assignments](../manage-apps/assign-user-or-group-access-portal.md) is the most common way to determine which users are in scope for provisioning. Because user assignments are also used for enabling single sign-on, the same method can be used for managing both access and provisioning. Assignment-based scoping doesn't apply to inbound provisioning scenarios such as Workday and Successfactors.

+* **Groups.** With a Microsoft Entra ID P1 or P2 license plan, you can use groups to assign access to a SaaS application. Then, when the provisioning scope is set to **Sync only assigned users and groups**, the Microsoft Entra provisioning service provisions or deprovisions users based on whether they're members of a group that's assigned to the application. The group object itself isn't provisioned unless the application supports group objects. Ensure that groups assigned to your application have the property "SecurityEnabled" set to "True".

+* **Dynamic groups.** The Microsoft Entra user provisioning service can read and provision users in [dynamic groups](../enterprise-users/groups-create-rule.md). Keep these caveats and recommendations in mind:

+ * Dynamic groups can impact the performance of end-to-end provisioning from Microsoft Entra ID to SaaS applications.

+* **Nested groups.** The Microsoft Entra user provisioning service can't read or provision users in nested groups. The service can only read and provision users that are immediate members of an explicitly assigned group. This limitation of "group-based assignments to applications" also affects single sign-on (see [Using a group to manage access to SaaS applications](../enterprise-users/groups-saasapps.md)). Instead, directly assign or otherwise [scope in](define-conditional-rules-for-provisioning-user-accounts.md) the groups that contain the users who need to be provisioned.

+You can use scoping filters to define attribute-based rules that determine which users are provisioned to an application. This method is commonly used for inbound provisioning from HCM applications to Microsoft Entra ID and Active Directory. Scoping filters are configured as part of the attribute mappings for each Microsoft Entra user provisioning connector. For details about configuring attribute-based scoping filters, see [Attribute-based application provisioning with scoping filters](define-conditional-rules-for-provisioning-user-accounts.md).

+It's possible to use the Microsoft Entra user provisioning service to provision B2B (guest) users in Microsoft Entra ID to SaaS applications. However, for B2B users to sign in to the SaaS application using Microsoft Entra ID, you must manually configure the SaaS application to use Microsoft Entra ID as a Security Assertion Markup Language (SAML) identity provider.

+When Microsoft Entra ID is the source system, the provisioning service uses the [delta query to track changes in Microsoft Graph data](/graph/delta-query-overview) to monitor users and groups. The provisioning service runs an initial cycle against the source system and target system, followed by periodic incremental cycles.

+9. If a user that was previously in scope for provisioning is hard-deleted in the source system, the service deletes the user in the target system. In Microsoft Entra ID, users are hard-deleted 30 days after they're soft-deleted.

+All operations run by the user provisioning service are recorded in the Microsoft Entra [Provisioning logs (preview)](../reports-monitoring/concept-provisioning-logs.md?context=azure/active-directory/manage-apps/context/manage-apps-context). The logs include all read and write operations made to the source and target systems, and the user data that was read or written during each operation. For information on how to read the provisioning logs in the Microsoft Entra admin center, see the [provisioning reporting guide](./check-status-user-account-provisioning.md).

+The Microsoft Entra provisioning service keeps source and target systems in sync by deprovisioning accounts when user access is removed.

+* A user is soft-deleted in Microsoft Entra ID (sent to the recycle bin / AccountEnabled property set to false). Thirty days after a user is deleted in Microsoft Entra ID, they're permanently deleted from the tenant. At this point, the provisioning service sends a DELETE request to permanently delete the user in the application. At any time during the 30-day window, you can [manually delete a user permanently](../fundamentals/users-restore.md), which sends a delete request to the application.

+* A user is permanently deleted / removed from the recycle bin in Microsoft Entra ID.

+By default, the Microsoft Entra provisioning service soft-deletes or disables users that go out of scope. If you want to override this default behavior, you can set a flag to [skip out-of-scope deletions.](skip-out-of-scope-deletions.md)

+The table describes how you can configure deprovisioning actions with the Microsoft Entra provisioning service. These rules are written with the non-gallery / custom application in mind, but generally apply to applications in the gallery. However, the behavior for gallery applications can differ as they've been optimized to meet the needs of the application. For example, if the target application doesn't support soft-deleting then the Microsoft Entra provisioning service might send a hard-delete request to delete users rather than send a soft-delete.

+|Scenario|How to configure in Microsoft Entra ID|

+|A user is unassigned from an app, soft-deleted in Microsoft Entra ID, or blocked from sign-in. You don't want anything to be done.|Remove `isSoftDeleted` from the attribute mappings and / or set the [skip out of scope deletions](skip-out-of-scope-deletions.md) property to true.|

+|A user is unassigned from an app, soft-deleted in Microsoft Entra ID, or blocked from sign-in. You want to set a specific attribute to `true` or `false`.|Map `isSoftDeleted` to the attribute that you would like to set to false.|

+|A user is disabled in Microsoft Entra ID, unassigned from an app, soft-deleted in Microsoft Entra ID, or blocked from sign-in. You want to send a DELETE request to the target application.|This is currently supported for a limited set of gallery applications where the functionality is required. It's not configurable by customers.|

+|A user is deleted in Microsoft Entra ID. You don't want anything done in the target application.|Ensure that "Delete" isn't selected as one of the target object actions in the [attribute configuration experience](skip-out-of-scope-deletions.md).|

+|A user is deleted in Microsoft Entra ID. You want to set the value of an attribute in the target application.|Not supported.|

+|A user is deleted in Microsoft Entra ID. You want to delete the user in the target application|Ensure that Delete is selected as one of the target object actions in the [attribute configuration experience](skip-out-of-scope-deletions.md).|

+* Provisioning a user that is disabled in Microsoft Entra ID isn't supported. They must be active in Microsoft Entra ID before they're provisioned.

+* When a user goes from soft-deleted to active, the Microsoft Entra provisioning service activates the user in the target app, but doesn't automatically restore the group memberships. The target application should maintain the group memberships for the user in inactive state. If the target application doesn't support maintaining the inactive state, you can restart provisioning to update the group memberships.

+| * Workday to on-premises Active Directory user provisioning <br> * Workday to Microsoft Entra user provisioning |

+| * Workday to on-premises Active Directory user provisioning <br> * Workday to Microsoft Entra user provisioning |

+| You have just configured the Workday inbound provisioning app and successfully connected to the Workday tenant URL. You have an integration system configured in Workday and you have configured XPATHs that point to attributes in the Workday Integration System. However, the Microsoft Entra provisioning app isn't fetching values associated with these integration system attributes or calculated fields. |

+* [Learn more about Microsoft Entra ID and Workday integration scenarios and web service calls](workday-integration-reference.md)

+* Workday to Microsoft Entra user provisioning

+* SAP SuccessFactors to Microsoft Entra user provisioning

+The Microsoft Entra provisioning service automatically updates manager information so that the user-manager relationship in Microsoft Entra ID is always in sync with your HR data. It uses a process called *manager reference resolution* to accurately update the *manager* attribute. Before going into the process details, it is important to understand how manager information is stored in Microsoft Entra ID and on-premises Active Directory.

+* In **Microsoft Entra ID**, the *manager* attribute is a DirectoryObject navigation property in Microsoft Entra ID. When you view the user record in the Microsoft Entra admin center, it shows the *displayName* of the manager record in Microsoft Entra ID.

+| Microsoft Entra ID | objectId | manager (which points to the manager's Microsoft Entra ID record) |

+* [Learn more about Microsoft Entra ID and Workday integration scenarios and web service calls](workday-integration-reference.md)

+* Workday to Microsoft Entra user provisioning

+* SAP SuccessFactors to Microsoft Entra user provisioning

+ * Option 2: Use the function [IgnoreFlowIfNullOrEmpty](functions-for-customizing-application-data.md#ignoreflowifnullorempty) to drop empty or null attributes in the payload sent to on-premises Active Directory / Microsoft Entra ID.

+* [Learn more about Microsoft Entra ID and Workday integration scenarios and web service calls](workday-integration-reference.md)

+* Workday to Microsoft Entra user provisioning

+* SAP SuccessFactors to Microsoft Entra user provisioning

+| **Issue** | You have successfully configured the inbound provisioning app. You are getting null or empty value from the HR app. You expect the provisioning service to clear the corresponding target attribute value in on-premises Active Directory / Microsoft Entra ID. But the operation fails with the error message: `InvalidAttributeSyntax-LdapErr: The syntax is invalid. The parameter is incorrect. Error in attribute conversion operation, data 0, v3839` |

+ * Option 2: Use the function [IgnoreFlowIfNullOrEmpty](functions-for-customizing-application-data.md#ignoreflowifnullorempty) to drop empty or null attributes in the payload sent to on-premises Active Directory / Microsoft Entra ID.

+* Workday to Microsoft Entra user provisioning

+| **Cause** | During incremental sync, the provisioning app queries Workday transaction log for changes to the primary Worker entity and only changes tracked by Workday's transaction log are processed. <br> If changes to a Workday attribute in your setup is not tracked by Workday's transaction log, then Microsoft Entra ID will not be able to fetch that change. For example: the *LocalReference* Workday attribute is part of the default attribute mapping and it has XPATH `wd:Worker/wd:Worker_Data/wd:Employment_Data/wd:Position_Data/wd:Business_Site_Summary_Data/wd:Local_Reference/wd:ID[@wd:type='Locale_ID']/text()`. Note that this attribute is part of the entity *Business_Site_Summary_Data*. A change in the value of this attribute in Workday will not show up in the Workday transaction log. Thus during incremental sync, the new value of this attribute will show up only if an attribute associated with the primary Worker entity also changes during the sync interval. |

+* Workday to Microsoft Entra user provisioning

+* SAP SuccessFactors to Microsoft Entra user provisioning

+| **Issue** | Let's say you are using *extensionAttribute3* in Microsoft Entra ID to store the employee ID and you have mapped it to Workday *WorkerID* or SuccessFactors *personIdExternal* attribute for user matching. With this configuration, the matching step in provisioning process fails. This issue impacts both user creation and updates. |

+| **Cause** | The Microsoft Entra ID *OnPremisesExtensionAttributes* (`extensionAttributes1-15`) cannot be used as a matching attribute because the `$filter` parameter of **Azure AD Graph API** does not [support filtering by extensionAttributes](/previous-versions/azure/ad/graph/howto/azure-ad-graph-api-supported-queries-filters-and-paging-options#filter). |

+| **Resolution** | Don't use Microsoft Entra ID *OnPremisesExtensionAttributes* (`extensionAttributes1-15`) in the matching attribute pair. Use employeeID. |

+* [Learn more about Microsoft Entra ID and Workday integration scenarios and web service calls](workday-integration-reference.md)

+| **Issue** | You have successfully configured the Writeback app. You are getting null or empty value from Microsoft Entra ID. You expect the provisioning service to clear the corresponding email or phone number value in the HR app. But the operation fails. |

+ Let's say the attribute `telephoneNumber` mapped to SAP SuccessFactors attribute `businessPhoneNumber` may be null or empty in Microsoft Entra ID.

+* [Learn more about Microsoft Entra ID and Workday integration scenarios and web service calls](workday-integration-reference.md)

+This document provides a conceptual overview of the Microsoft Entra API-driven inbound user provisioning.

+Today enterprises have a variety of authoritative systems of record. To establish end-to-end identity lifecycle, strengthen security posture and stay compliant with regulations, identity data in Microsoft Entra ID must be kept in sync with workforce data managed in these systems of record. The *system of record* could be an HR app, a payroll app, a spreadsheet or SQL tables in a database hosted either on-premises or in the cloud.

+With API-driven inbound provisioning, the Microsoft Entra provisioning service now supports integration with *any* system of record. Customers and partners can use *any* automation tool of their choice to retrieve workforce data from the system of record and ingest it into Microsoft Entra ID. The IT admin has full control on how the data is processed and transformed with attribute mappings. Once the workforce data is available in Microsoft Entra ID, the IT admin can configure appropriate joiner-mover-leaver business processes using [Lifecycle Workflows](../governance/what-are-lifecycle-workflows.md).

+<a name='scenario-2-enable-isvs-to-build-direct-integration-with-azure-ad'></a>

+### Scenario 2: Enable ISVs to build direct integration with Microsoft Entra ID

+With API-driven inbound provisioning, HR ISVs can ship native synchronization experiences so that changes in the HR system automatically flow into Microsoft Entra ID and connected on-premises Active Directory domains. For example, an HR app or student information systems app can send data to Microsoft Entra ID as soon as a transaction is complete or as end-of-day bulk update.

+Partners can build custom HR connectors to meet different integration requirements around data flow from systems of record to Microsoft Entra ID.

+In all the above scenarios, the integration is greatly simplified as Microsoft Entra provisioning service takes over the responsibility of performing identity profile comparison, restricting the data sync to scoping logic configured by the IT admin and executing rule-based attribute flow and transformation managed in the Microsoft Entra admin center.

+1. The API developer/partner/system integrator builds an API client to send authoritative identity data to Microsoft Entra ID.

+1. The Microsoft Entra provisioning service processes the data received, applies the attribute mapping rules and completes user provisioning.

+1. Depending on the provisioning app configured, the user is provisioned either into on-premises Active Directory (for hybrid users) or Microsoft Entra ID (for cloud-only users).

+- Each API endpoint is associated with a specific provisioning app in Microsoft Entra ID. You can integrate multiple data sources by creating a provisioning app for each data source.

+- [Automate user provisioning and deprovisioning to SaaS applications with Microsoft Entra ID](user-provisioning.md)

+* API-driven inbound user provisioning to Microsoft Entra ID

+* [Application Administrator](../roles/permissions-reference.md#application-administrator) (if you're configuring inbound user provisioning to Microsoft Entra ID) OR

+2. Browse to **Microsoft Entra ID** > **Applications** > **Enterprise applications**.

+ [](media/inbound-provisioning-api-configure-app/provisioning-entra-admin-center.png#lightbox)

+ * **API-driven Inbound User Provisioning to On-Premises AD**: Select this app if you're provisioning hybrid identities (identities that need both on-premises AD and Microsoft Entra account) from your system of record. Once these accounts are provisioned in on-premises AD, they are automatically synchronized to your Microsoft Entra tenant using Microsoft Entra Connect or Cloud Sync.

+ * **API-driven Inbound User Provisioning to Microsoft Entra ID**: Select this app if you're provisioning cloud-only identities (identities that don't require on-premises AD accounts and only need Microsoft Entra account) from your system of record.

+* [Configure API-driven inbound provisioning to Microsoft Entra ID](#configure-api-driven-inbound-provisioning-to-azure-ad)

+1. Click on the information banner about the Microsoft Entra provisioning Agent.

+1. Click **Accept terms & download** to download the Microsoft Entra provisioning Agent.

+1. Refer to the steps documented here to [install and configure the provisioning agent.](https://go.microsoft.com/fwlink/?linkid=2241216). This step registers your on-premises Active Directory domains with your Microsoft Entra tenant.

+1. Click on **Test connection** to ensure that Microsoft Entra ID can connect to the provisioning agent.

+<a name='configure-api-driven-inbound-provisioning-to-azure-ad'></a>

+## Configure API-driven inbound provisioning to Microsoft Entra ID

+- [Automate user provisioning and deprovisioning to SaaS applications with Microsoft Entra ID](user-provisioning.md)

+1. Browse to **Microsoft Entra ID -> Applications -> Enterprise applications**.

+You have configured API-driven provisioning app. You're provisioning app is successfully consuming the attributes that are part of the standard SCIM Core User and Enterprise User schema and provisioning users in Microsoft Entra ID. You now want to send two custom attributes `HireDate` and `JobCode` from your HR system to the inbound provisioning API endpoint. You'd like to map these two custom attributes to Microsoft Entra attributes `employeeHireDate` and `jobTitle`.

+1. Edit the attribute mapping to an expression that will include the `urn:ietf:params:scim:schemas:extension:contoso:1.0:User:JobCode` as part of the `jobTitle` Microsoft Entra attribute.

+ With this expression mapping, if the `title` is "Tour Lead" and `JobCode`is "TL-1001", then the Microsoft Entra attribute `jobTitle` will be set to "Tour Lead (TL-1001)".

+1. You can also verify the change in the Microsoft Entra user profile. The value for `Employee hire date` reflects your tenant time zone. <br>

+ - When identity data is sent to the MS Graph Users API endpoint, it's immediately processed, and a Create/Update/Delete operation takes place on the Microsoft Entra user profile.

+ - Request data sent to the provisioning /bulkUpload API is processed *asynchronously* by the Microsoft Entra provisioning service. The provisioning job applies scoping rules, attribute mapping and transformation configured by the IT admin. This initiates a ```Create/Update/Delete``` operation on the Microsoft Entra user profile or the on-premises AD user profile.

+- **IT admin retains control**: With API-driven inbound provisioning, the IT admin has more control on how the incoming identity data is processed and mapped to Microsoft Entra attributes. They can define scoping rules to exclude certain types of identity data (for example, contractor data) and use transformation functions to derive new values before setting the attribute values on the user profile.

+The primary goal of MS Graph inbound provisioning /bulkUpload API is to enable customers to send *any* identity data (for example, costCenter, pay grade, badgeId) from *any* identity data source (for example, CSV/SQL/HR) for eventual processing by Microsoft Entra provisioning service. The Microsoft Entra provisioning service consumes the bulk payload data received at this endpoint, applies attribute mapping rules configured by the IT admin and determines whether the data payload leads to (Create, Update, Enable, Disable) operation in the target identity store (Microsoft Entra ID / on-premises AD).

+The /bulkUpload API is available only for apps of the type: "API-driven inbound provisioning to Microsoft Entra ID" and "API-driven inbound provisioning to on-premises Active Directory". You can retrieve the unique API endpoint for each provisioning app from the Provisioning blade home page. In **Statistics to date** > **View technical information**,copy the **Provisioning API Endpoint** URL.

+1. The job retrieves the attribute mapping for the provisioning job and makes note of the matching attribute pair (by default ```externalId``` API attribute is used to match with ```employeeId``` in Microsoft Entra ID).

+1. The job checks the value matching identifier in the request (by default the attribute `externalId`) and uses it to check if there's a user in Microsoft Entra ID with matching `employeeId` value.

+To make sure that the right users get created in Microsoft Entra ID, define the right matching attribute pair in your mapping which uniquely identifies users in your source and Microsoft Entra ID.

+By default, the API endpoint supports processing any attribute that is part of the SCIM Core User and Enterprise User schema. If you'd like to send more attributes, you can extend the provisioning app schema, map the new attributes to Microsoft Entra attributes and update the bulk request to send those attributes.

+1. The provisioning job retrieves the attribute mapping for the provisioning job and makes note of the matching attribute pair (by default ```externalId``` API attribute is used to match with ```employeeId``` in Microsoft Entra ID). You can change this default attribute matching pair.

+1. The job checks the value matching identifier in the SCIM request (by default: API attribute ```externalId```) and uses it to check if there's a user in Microsoft Entra ID with matching ```employeeId``` value.

+To make sure that the right users get updated in Microsoft Entra ID, make sure you define the right matching attribute pair in your mapping which uniquely identifies users in your source and Microsoft Entra ID.

+To process terminations, identify an attribute in your source that will be used to set the ```accountEnabled``` flag in Microsoft Entra ID. If you are provisioning to on-premises Active Directory, then map that source attribute to the `accountDisabled` attribute.

+<a name='can-we-soft-delete-a-user-in-azure-ad-using-bulkupload-provisioning-api'></a>

+## Can we soft-delete a user in Microsoft Entra ID using /bulkUpload provisioning API?

+* If the target directory for the operation is Microsoft Entra ID, then the matched user is soft-deleted. The user can be seen on the Microsoft Azure portal **Deleted users** page for the next 30 days and can be restored during that time.

+The current API only supports inbound data. Here are some options to consider for implementing writeback of attributes like email / username / phone generated by Microsoft Entra ID, that you can flow back to the HR system:

+- **Option 2 ΓÇô Use Microsoft Entra ECMA connector for the writeback scenario**

+Depending on how your API client authenticates with Microsoft Entra ID, you can select between two configuration options:

+* [Configure a service principal](#configure-a-service-principal): Follow these instructions if your API client plans to use a service principal of an [Microsoft Entra registered app](../develop/howto-create-service-principal-portal.md) and authenticate using OAuth client credentials grant flow.

+* [Configure a managed identity](#configure-a-managed-identity): Follow these instructions if your API client plans to use a Microsoft Entra [managed identity](../managed-identities-azure-resources/overview.md).

+This configuration registers an app in Microsoft Entra ID that represents the external API client and grants it permission to invoke the inbound provisioning API. The service principal client id and client secret can be used in the OAuth client credentials grant flow.

+1. Browse to **Microsoft Entra ID** -> **Applications** -> **App registrations**.

+1. To confirm that the permission was applied, find the managed identity service principal under **Enterprise Applications** in Microsoft Entra ID. Remove the **Application type** filter to see all service principals.

+> This provisioning API is primarily meant for use within an application or service. Tenant admins can either configure a service principal or managed identity to grant permission to perform the upload. There is no separate user-assignable Microsoft Entra built-in directory role for this API. Outside of applications that have acquired `SynchronizationData-User.Upload` permission with admin consent, only admin users with Global Administrator role can invoke the API. This tutorial shows how you can test the API with a global administrator role in your test setup.

+1. Browse to **Microsoft Entra ID -> Applications -> Enterprise applications**.

+This expression fixes the issue by appending a default domain to the UPN value accepted by Microsoft Entra ID.

+This tutorial describes how to use Azure Logic Apps workflow to implement Microsoft Entra ID [API-driven inbound provisioning](inbound-provisioning-api-concepts.md). Using the steps in this tutorial, you can convert a CSV file containing HR data into a bulk request payload and send it to the Microsoft Entra provisioning [/bulkUpload](/graph/api/synchronization-synchronizationjob-post-bulkupload) API endpoint. The article also provides guidance on how the same integration pattern can be used with any system of record.

+* You want to use Microsoft Entra provisioning service to apply your IT managed provisioning rules to automatically create/update/enable/disable accounts in the target directory (on-premises Active Directory or Microsoft Entra ID).

+After reading the source data, apply your pre-processing rules and convert the output from your system of record into a bulk request that can be sent to the Microsoft Entra provisioning [bulkUpload](/graph/api/synchronization-synchronizationjob-post-bulkupload) API endpoint.

+> If you'd like to share your API-driven inbound provisioning + Logic Apps integration workflow with the community, create a [Logic app template](/azure/logic-apps/logic-apps-create-azure-resource-manager-templates), document steps on how to use it and submit a pull request for inclusion in the GitHub repository [`entra-id-inbound-provisioning`](https://github.com/AzureAD/entra-id-inbound-provisioning).

+The Logic Apps deployment template published in the [Microsoft Entra inbound provisioning GitHub repository](https://github.com/AzureAD/entra-id-inbound-provisioning/tree/main/LogicApps/CSV2SCIMBulkUpload) automates several tasks. It also has logic for handling large CSV files and chunking the bulk request to send 50 records in each request. Here's how you can test it and customize it per your integration requirements.

+1. From the **Workspaces** menu, select **Create Workspace** to create a new Workspace called **Microsoft Entra provisioning API**.

+ - [Microsoft Entra Inbound Provisioning.postman_collection.json](https://github.com/AzureAD/entra-id-inbound-provisioning/blob/main/Postman/Entra%20ID%20Inbound%20Provisioning.postman_collection.json) (Request collection)

+ - [Test-API2AAD.postman_environment.json](https://github.com/AzureAD/entra-id-inbound-provisioning/blob/main/Postman/Test-API2AAD.postman_environment.json) (Environment collection for API-driven provisioning to Microsoft Entra ID)-

+1. Next, open the collection **Microsoft Entra Inbound Provisioning**.

+1. Browse to **Microsoft Entra ID -> Applications -> Enterprise applications**.

+1. Open the workspace **Microsoft Entra provisioning API** in your Postman desktop app.

+2. The collection **Microsoft Entra Inbound Provisioning** contains three sample requests that enable you to query the provisioning logs.

+This tutorial describes how to use a PowerShell script to implement Microsoft Entra ID [API-driven inbound provisioning](inbound-provisioning-api-concepts.md). Using the steps in this tutorial, you can convert a CSV file containing HR data into a bulk request payload and send it to the Microsoft Entra provisioning [/bulkUpload](/graph/api/synchronization-synchronizationjob-post-bulkupload) API endpoint. The article also provides guidance on how the same integration pattern can be used with any system of record.

+* You want to use Microsoft Entra provisioning service to apply your IT managed provisioning rules to automatically create/update/enable/disable accounts in the target directory (on-premises Active Directory or Microsoft Entra ID).

+After reading the source data, apply your pre-processing rules and convert the output from your system of record into a bulk request that can be sent to the Microsoft Entra provisioning [bulkUpload](/graph/api/synchronization-synchronizationjob-post-bulkupload) API endpoint.

+> If you'd like to share your PowerShell integration script with the community, publish it on [PowerShell Gallery](https://www.powershellgallery.com/) and notify us on the GitHub repository [`entra-id-inbound-provisioning`](https://github.com/AzureAD/entra-id-inbound-provisioning), so we can add a reference it.

+The PowerShell sample script published in the [Microsoft Entra inbound provisioning GitHub repository](https://github.com/AzureAD/entra-id-inbound-provisioning/tree/main/PowerShell/CSV2SCIM) automates several tasks. It has logic for handling large CSV files and chunking the bulk request to send 50 records in each request. Here's how you can test it and customize it per your integration requirements.

+|3 | Use a certificate for authentication to Microsoft Entra ID. | [Create a service principal that can access](inbound-provisioning-api-grant-access.md) the inbound provisioning API. Refer to steps in the section [Configure client certificate for service principal authentication](#configure-client-certificate-for-service-principal-authentication) to learn how to use client certificate for authentication. | If you'd like to use managed identity instead of a service principal for authentication, then review the use of `Connect-MgGraph` in the sample script and update it to use [managed identities](/powershell/microsoftgraph/authentication-commands#using-managed-identity). |

+1. Access the GitHub repository [`entra-id-inbound-provisioning`](https://github.com/AzureAD/entra-id-inbound-provisioning).

+After sending the bulk request, you can query the logs of the latest sync cycles processed by Microsoft Entra ID. You can retrieve the sync statistics and processing details with the PowerShell script and save it for analysis.

+| ClientId |The Client ID of a Microsoft Entra registered app to use for OAuth authentication flow. This app must have valid certificate credentials. | Mandatory: Only when performing certificate-based authentication. |

+You can set the registry option to [skip GMSA configuration](https://go.microsoft.com/fwlink/?linkid=2239993) and reconfigure the Microsoft Entra Connect provisioning agent to use a manually created service account with the right permissions.

+ Title: Enable automatic user provisioning for multi-tenant applications in Microsoft Entra ID

+description: A guide for independent software vendors for enabling automated provisioning in Microsoft Entra ID

+# Enable automatic user provisioning for your multi-tenant application in Microsoft Entra ID

+* Increase the visibility of your application in the [Microsoft Entra app gallery](https://azuremarketplace.microsoft.com/marketplace/apps).

+Microsoft Entra ID provides several integration paths to enable automatic user provisioning for your application.

+* The [Microsoft Entra provisioning service](../app-provisioning/user-provisioning.md) manages the provisioning and deprovisioning of users from Microsoft Entra ID to your application (outbound provisioning) and from your application to Microsoft Entra ID (inbound provisioning). The service connects to the System for Cross-Domain Identity Management (SCIM) user management API endpoints provided by your application.

+* When using the [Microsoft Graph](/graph/), your application manages inbound and outbound provisioning of users and groups from Microsoft Entra ID to your application by querying the Microsoft Graph API.

+| Capabilities enabled or enhanced by Automatic Provisioning| Microsoft Entra provisioning service (SCIM 2.0)| Microsoft Graph API (OData v4.0)| SAML JIT |

+| User and group management in Microsoft Entra ID| √| √| User only |

+^* ΓÇô Microsoft Entra Connect setup is required to sync users from AD to Microsoft Entra ID.

+<a name='azure-ad-provisioning-service-scim'></a>

+## Microsoft Entra provisioning service (SCIM)

+The Microsoft Entra provisioning service uses [SCIM](https://aka.ms/SCIMOverview), an industry standard for provisioning supported by many identity providers (IdPs) as well as applications (e.g. Slack, G Suite, Dropbox). We recommend you use the Microsoft Entra provisioning service if you want to support IdPs in addition to Microsoft Entra ID, as any SCIM-compliant IdP can connect to your SCIM endpoint. Building a simple /User endpoint, you can enable provisioning without having to maintain your own sync engine.

+For more information on how the Microsoft Entra provisioning service users SCIM, see:

+* [Using System for Cross-Domain Identity Management (SCIM) to automatically provision users and groups from Microsoft Entra ID to applications](../app-provisioning/use-scim-to-provision-users-and-groups.md)

+* [Understand the Microsoft Entra SCIM implementation](../app-provisioning/use-scim-to-provision-users-and-groups.md)

+More than 15 million organizations, and 90% of fortune 500 companies use Microsoft Entra ID while subscribing to Microsoft cloud services like Microsoft 365, Microsoft Azure, or Enterprise Mobility Suite. You can use Microsoft Graph to integrate your app with administrative workflows, such as employee onboarding (and termination), profile maintenance, and more.

+SAML JIT uses the claims information in the SAML token to create and update user information in the application. Customers can configure these required claims in the Microsoft Entra application as needed. Sometimes the JIT provisioning needs to be enabled from the application side so that customer can use this feature. SAML JIT is useful for creating and updating users, but it can't delete or deactivate the users in the application.

+ Title: Known issues for provisioning in Microsoft Entra ID

+description: Learn about known issues when you work with automated application provisioning or cross-tenant synchronization in Microsoft Entra ID.

+# Known issues for provisioning in Microsoft Entra ID

+This article discusses known issues to be aware of when you work with app provisioning or cross-tenant synchronization. To provide feedback about the application provisioning service on UserVoice, see [Microsoft Entra application provision UserVoice](https://aka.ms/appprovisioningfeaturerequest). We watch UserVoice closely so that we can improve the service.

+An external user from the source (home) tenant can't be provisioned into another tenant. Internal guest users from the source tenant can't be provisioned into another tenant. Only internal member users from the source tenant can be provisioned into the target tenant. For more information, see [Properties of a Microsoft Entra B2B collaboration user](../external-identities/user-properties.md).

+<a name='usage-of-azure-ad-b2b-collaboration-for-cross-tenant-access'></a>

+### Usage of Microsoft Entra B2B collaboration for cross-tenant access

+- B2B users with UserType Member aren't currently supported in Power BI. For more information, see [Distribute Power BI content to external guest users using Microsoft Entra B2B](/power-bi/guidance/whitepaper-azure-b2b-power-bi)

+- Converting a guest account into a Microsoft Entra member account or converting a Microsoft Entra member account into a guest isn't supported by Teams. For more information, see [Guest access in Microsoft Teams](/microsoftteams/guest-access).

+Microsoft Entra ID currently can't provision null attributes. If an attribute is null on the user object, it will be skipped.

+<a name='changes-not-moving-from-target-app-to-azure-ad'></a>

+#### Changes not moving from target app to Microsoft Entra ID

+The app provisioning service isn't aware of changes made in external apps. So, no action is taken to roll back. The app provisioning service relies on changes made in Microsoft Entra ID.

+The following information is a current list of known limitations with the Microsoft Entra ECMA Connector Host and on-premises application provisioning.

+<a name='active-directory-domain-services-user-or-group-writeback-from-azure-ad-by-using-the-on-premises-provisioning-preview'></a>

+#### Active Directory Domain Services (user or group writeback from Microsoft Entra ID by using the on-premises provisioning preview)

+ - When a user is managed by Microsoft Entra Connect, the source of authority is on-premises Active Directory Domain Services. So, user attributes can't be changed in Microsoft Entra ID. This preview doesn't change the source of authority for users managed by Microsoft Entra Connect.

+ - Attempting to use Microsoft Entra Connect and the on-premises provisioning to provision groups or users into Active Directory Domain Services can lead to creation of a loop, where Microsoft Entra Connect can overwrite a change that was made by the provisioning service in the cloud. Microsoft is working on a dedicated capability for group or user writeback. Upvote the UserVoice feedback on [this website](https://feedback.azure.com/d365community/forum/22920db1-ad25-ec11-b6e6-000d3a4f0789/) to track the status of the preview. Alternatively, you can use [Microsoft Identity Manager](/microsoft-identity-manager/microsoft-identity-manager-2016) for user or group writeback from Microsoft Entra ID to Active Directory.

+<a name='azure-ad'></a>

+#### Microsoft Entra ID

+ By using on-premises provisioning, you can take a user already in Microsoft Entra ID and provision them into a third-party application. *You can't bring a user into the directory from a third-party application.* Customers will need to rely on our native HR integrations, Microsoft Entra Connect, Microsoft Identity Manager, or Microsoft Graph, to bring users into the directory.

+ - On-premises applications are sometimes not federated with Microsoft Entra ID and require local passwords. The on-premises provisioning preview doesn't support password synchronization. Provisioning initial one-time passwords is supported. Ensure that you're using the [Redact](./functions-for-customizing-application-data.md#redact) function to redact the passwords from the logs. In the SQL and LDAP connectors, the passwords aren't exported on the initial call to the application, but rather a second call with set password.

+ The Microsoft Entra ECMA Connector Host currently requires either an SSL certificate to be trusted by Azure or the provisioning agent to be used. The certificate subject must match the host name the Microsoft Entra ECMA Connector Host is installed on.

+ The Microsoft Entra ECMA Connector Host currently doesn't support anchor attribute changes (renames) or target systems, which require multiple attributes to form an anchor.

+ Title: 'Microsoft Entra on-premises application provisioning architecture'

+# Microsoft Entra on-premises application identity provisioning architecture

+- The provisioning agent provides connectivity between Microsoft Entra ID and your on-premises environment.

+- The ECMA host converts provisioning requests from Microsoft Entra ID to requests made to your target application. It serves as a gateway between Microsoft Entra ID and your application. You can use it to import existing ECMA2 connectors used with Microsoft Identity Manager. The ECMA host isn't required if you've built a SCIM application or SCIM gateway.

+- The Microsoft Entra provisioning service serves as the synchronization engine.

+|Endpoints|Responsible for communication and data-transfer with the Microsoft Entra provisioning service|

+1. The Microsoft Entra provisioning service queries the ECMA Connector Host to see if the user exists. It uses the **matching attribute** as the filter. This attribute is defined in the Azure portal under Enterprise applications -> On-premises provisioning -> provisioning -> attribute matching. It is denoted by the 1 for matching precedence.

+2. ECMA Connector Host receives the GET request and queries its internal cache to see if the user exists and has based imported. This is done using the matching attribute(s) above. If you define multiple matching attributes, the Microsoft Entra provisioning service will send a GET request for each attribute and the ECMA host will check its cache for a match until it finds one.

+3. If the user does not exist, Microsoft Entra ID will make a POST request to create the user. The ECMA Connector Host will respond back to Microsoft Entra ID with the HTTP 201 and provide an ID for the user. This ID is derived from the anchor value defined in the object types page. This anchor will be used by Microsoft Entra ID to query the ECMA Connector Host for future and subsequent requests.

+4. If a change happens to the user in Microsoft Entra ID, then Microsoft Entra ID will make a GET request to retrieve the user using the anchor from the previous step, rather than the matching attribute in step 1. This allows, for example, the UPN to change without breaking the link between the user in Microsoft Entra ID and in the app.

+- Using the same agent for the on-premises provisioning feature along with Workday / SuccessFactors / Microsoft Entra Connect Cloud Sync is currently unsupported. We are actively working to support on-premises provisioning on the same agent as the other provisioning scenarios.

+ 3. Look for the version that corresponds to the entry for **Microsoft Entra Connect Provisioning Agent**.

+<a name='can-i-install-the-provisioning-agent-on-the-same-server-running-azure-ad-connect-or-microsoft-identity-manager'></a>

+### Can I install the provisioning agent on the same server running Microsoft Entra Connect or Microsoft Identity Manager?

+Yes. You can install the provisioning agent on the same server that runs Microsoft Entra Connect or Microsoft Identity Manager, but they aren't required.

+<a name='how-do-i-ensure-the-provisioning-agent-can-communicate-with-the-azure-ad-tenant-and-no-firewalls-are-blocking-ports-required-by-the-agent'></a>

+### How do I ensure the provisioning agent can communicate with the Microsoft Entra tenant and no firewalls are blocking ports required by the agent?

+ - Microsoft Entra Connect Provisioning Agent

+ - Microsoft Entra Connect Agent Updater

+ - Microsoft Entra Connect Provisioning Agent Package

+This article lists the versions and features of Microsoft Entra Connect Provisioning Agent that have been released. The Microsoft Entra ID team regularly updates the Provisioning Agent with new features and functionality. Please ensure that you do not use the same agent for on-premises provisioning and Cloud Sync / HR-driven provisioning.

+ Title: Microsoft Entra provisioning to applications using custom connectors

+description: This document describes how to configure Microsoft Entra ID to provision users with external systems that offer REST and SOAP APIs.

+Microsoft Entra ID supports preintegrated connectors for applications that support the following protocols and standards:

+For connectivity to applications that don't support the aforementioned protocols and standards, customers and [partners](https://social.technet.microsoft.com/wiki/contents/articles/1589.fim-2010-mim-2016-management-agents-from-partners.aspx) have built custom [ECMA 2.0](/previous-versions/windows/desktop/forefront-2010/hh859557(v=vs.100)) connectors for Microsoft Identity Manager (MIM) 2016. You can now use those ECMA 2.0 connectors with the lightweight Microsoft Entra provisioning agent, without needing MIM sync deployed.

+The following table includes capabilities of the ECMA framework that are either partially supported or not supported by the Microsoft Entra provisioning agent. For a list of known limitations for the Microsoft Entra provisioning service and on-premises application provisioning, see [here](known-issues.md#on-premises-application-provisioning).

+After you configure the provisioning agent and ECMA host, it's time to test connectivity from the Microsoft Entra provisioning service to the provisioning agent, the ECMA host, and the application. To perform this end-to-end test, select **Test connection** in the application in the Azure portal. Be sure to wait 10 to 20 minutes after assigning an initial agent or changing the agent before testing the connection. If after this time the test connection fails, try the following troubleshooting steps:

+ 2. Under **Services**, make sure the **Microsoft Entra Connect Provisioning Agent**, and **Microsoft ECMA2Host** services are present and their status is *Running*.

+ 1. Restart the provisioning agent by going to the taskbar on your VM by searching for the Microsoft Entra Connect provisioning agent. Right-click **Stop**, and then select **Start**.

+Requests made by Microsoft Entra ID to the provisioning agent and connector host use the SCIM protocol. Requests made from the host to apps use the protocol the app supports. The requests from the host to the agent to Microsoft Entra ID rely on SCIM. You can learn more about the SCIM implementation in [Tutorial: Develop and plan provisioning for a SCIM endpoint in Microsoft Entra ID](use-scim-to-provision-users-and-groups.md).

+The Microsoft Entra provisioning service generally makes a get-user call to check for a [dummy user](use-scim-to-provision-users-and-groups.md#request-3) in three situations: at the beginning of each provisioning cycle, before performing on-demand provisioning and when **test connection** is selected. This check ensures the target endpoint is available and returning SCIM-compliant responses to the Microsoft Entra provisioning service.

+"Service 'Microsoft Entra Connect Provisioning Agent' failed to start. Check that you have sufficient privileges to start the system services."

+ 3. Under **Services**, double-click **Microsoft Entra Connect Provisioning Agent**.

+ 1. Install the AADCloudSyncTools PowerShell module as described in [AADCloudSyncTools PowerShell Module for Microsoft Entra Connect cloud sync](../hybrid/cloud-sync/reference-powershell.md#install-the-aadcloudsynctools-powershell-module).

+By using Microsoft Entra ID, you can monitor the provisioning service in the cloud and collect logs on-premises. The provisioning service emits logs for each user that was evaluated as part of the synchronization process. Those logs can be consumed through the [Azure portal UI, APIs, and log analytics](../reports-monitoring/concept-provisioning-logs.md). The ECMA host also generates logs on-premises. It shows each provisioning request that was received and the response that was sent to Microsoft Entra ID.

+ Title: Microsoft Entra provisioning to LDAP directories

+description: This document describes how to configure Microsoft Entra ID to provision users into an LDAP directory.

+# Configuring Microsoft Entra ID to provision users into LDAP directories

+The following documentation provides configuration and tutorial information demonstrating how to provision users from Microsoft Entra ID into an LDAP directory.

+ Title: Preparing for Microsoft Entra provisioning to Active Directory Lightweight Directory Services

+description: This document describes how to configure Microsoft Entra ID to provision users into Active Directory Lightweight Directory Services as an example of an LDAP directory.

+# Prepare Active Directory Lightweight Directory Services for provisioning from Microsoft Entra ID

+The following documentation provides tutorial information demonstrating how to prepare an Active Directory Lightweight Directory Services (AD LDS) installation. This can be used as an example LDAP directory for troubleshooting or to demonstrate [how to provision users from Microsoft Entra ID into an LDAP directory](on-premises-ldap-connector-configure.md).

+Next, continue in the guidance to [provision users from Microsoft Entra ID into an LDAP directory](on-premises-ldap-connector-configure.md) to download and configure the provisioning agent.

+ Title: 'Export a Microsoft Identity Manager connector for use with the Microsoft Entra ECMA Connector Host'

+description: Describes how to create and export a connector from MIM Sync to be used with the Microsoft Entra ECMA Connector Host.

+# Export a Microsoft Identity Manager connector for use with the Microsoft Entra ECMA Connector Host

+You can import into the Microsoft Entra ECMA Connector Host a configuration for a specific connector from a Forefront Identity Manager Synchronization Service or Microsoft Identity Manager Synchronization Service (MIM Sync) installation. The MIM Sync installation is only used for configuration, not for the ongoing synchronization from Microsoft Entra ID.

+ 1. Prepare a Windows Server 2016 server, which is distinct from the server that will be used for running the Microsoft Entra ECMA Connector Host. This host server should either have a SQL Server 2016 database colocated or have network connectivity to a SQL Server 2016 database. One way to set up this server is by deploying an Azure virtual machine with the image **SQL Server 2016 SP1 Standard on Windows Server 2016**. This server doesn't need internet connectivity other than remote desktop access for setup purposes.

+ 1. Sign in to the Windows server as the account that the Microsoft Entra ECMA Connector Host runs as.

+- [Configuring Microsoft Entra ID to provision users into SQL based applications](on-premises-sql-connector-configure.md) with the Generic SQL connector

+- [Configuring Microsoft Entra ID to provision users into LDAP directories](on-premises-ldap-connector-configure.md) with the Generic LDAP connector

+ Title: Microsoft Entra provisioning to applications via PowerShell

+description: This document describes how to configure Microsoft Entra ID to provision users with external systems that offer Windows PowerShell based APIs.

+The following documentation provides configuration and tutorial information demonstrating how the generic PowerShell connector and the ECMA Connector Host can be used to integrate Microsoft Entra ID with external systems that offer Windows PowerShell based APIs.

+ - A Microsoft Entra tenant with Microsoft Entra ID P1 or Premium P2 (or EMS E3 or E5). [!INCLUDE [active-directory-p1-license.md](../../../includes/active-directory-p1-license.md)]

+ - The Microsoft Entra users, to be provisioned, must already be populated with any attributes required by the schema.

+<a name='download-install-and-configure-the-azure-ad-connect-provisioning-agent-package'></a>

+## Download, install, and configure the Microsoft Entra Connect Provisioning Agent Package

+ 1. In the Azure portal, select **Microsoft Entra ID**.

+ 2. On the left, select **Microsoft Entra Connect**.

+ >Please use different provisioning agents for on-premises application provisioning and Microsoft Entra Connect Cloud Sync / HR-driven provisioning. All three scenarios should not be managed on the same agent.

+ 8. The provisioning agent uses the operating system's web browser to display a popup window for you to authenticate to Microsoft Entra ID, and potentially also your organization's identity provider. If you are using Internet Explorer as the browser on Windows Server, then you may need to add Microsoft web sites to your browser's trusted site list to allow JavaScript to run correctly.

+ 9. Provide credentials for a Microsoft Entra administrator when you're prompted to authorize. The user is required to have the Hybrid Identity Administrator or Global Administrator role.

+ <a name='configure-the-azure-ad-ecma-connector-host-certificate'></a>

+## Configure the Microsoft Entra ECMA Connector Host certificate

+ 4. Generate a secret token used for authenticating Microsoft Entra ID to the connector. It should be 12 characters minimum and unique for each application. If you do not already have a secret generator, you can use a PowerShell command such as the following to generate an example random string.

+On the Deprovisioning page, you can specify if you wish to have Microsoft Entra ID remove users from the directory when they go out of scope of the application. If so, under Disable flow, select Delete, and under Delete flow, select Delete. If Set attribute value is chosen, the attributes selected on the previous page won't be available to select on the Deprovisioning page.

+ 1. On the server running the Microsoft Entra ECMA Connector Host, select **Start**.

+ 4. On the server running the Microsoft Entra ECMA Connector Host, launch PowerShell.

+ 10. However, if the target system already contains one or more users but the script displayed `False`, then this status indicates the connector could not read from the target system. If you attempt to provision, then Microsoft Entra ID may not correctly match users in that source directory with users in Microsoft Entra ID. Wait several minutes for the connector host to finish reading objects from the existing target system, and then rerun the script. If the output continues to be `False`, then check the configuration of your connector and the permissions in the target system are allowing the connector to read existing users.

+<a name='test-the-connection-from-azure-ad-to-the-connector-host'></a>

+## Test the connection from Microsoft Entra ID to the connector host

+ >If you just assigned the agent to the application, please wait 10 minutes for the registration to complete. The connectivity test won't work until the registration completes. Forcing the agent registration to complete by restarting the provisioning agent on your server can speed up the registration process. Go to your server, search for **services** in the Windows search bar, identify the **Microsoft Entra Connect Provisioning Agent** service, right-click the service, and restart.

+ >If you just assigned the agent to the application, please wait 10 minutes for the registration to complete. The connectivity test won't work until the registration completes. Forcing the agent registration to complete by restarting the provisioning agent on your server can speed up the registration process. Go to your server, search for **services** in the Windows search bar, identify the **Microsoft Entra Connect Provisioning Agent Service**, right-click the service, and restart.

+Now you need to map attributes between the representation of the user in Microsoft Entra ID and the representation of a user in the on-premises InputFile.txt.

+You'll use the Azure portal to configure the mapping between the Microsoft Entra user's attributes and the attributes that you previously selected in the ECMA Host configuration wizard.

+ 1. In the Microsoft Entra portal, under **Enterprise applications**, select the **On-premises ECMA app** application, and then the **Provisioning** page.

+ 3. Expand **Mappings** and select **Provision Microsoft Entra Users**. If this is the first time you've configured the attribute mappings for this application, there will be only one mapping present, for a placeholder.

+ 4. To confirm that the schema is available in Microsoft Entra ID, select the **Show advanced options** checkbox and select **Edit attribute list for ScimOnPremises**. Ensure that all the attributes selected in the configuration wizard are listed. If not, then wait several minutes for the schema to refresh, and then reload the page. Once you see the attributes listed, then cancel from this page to return to the mappings list.

+Now that you have the Microsoft Entra ECMA Connector Host talking with Microsoft Entra ID, and the attribute mapping configured, you can move on to configuring who's in scope for provisioning.

+If there are existing users in the InputFile.txt, then you should create application role assignments for those existing users. To learn more about how to create application role assignments in bulk, see [governing an application's existing users in Microsoft Entra ID](../governance/identity-governance-applications-existing-users.md).

+Otherwise, if there are no current users of the application, then select a test user from Microsoft Entra who will be provisioned to the application.

+ Title: Microsoft Entra provisioning into SAP ERP Central Component (SAP ECC, formerly SAP R/3) with NetWeaver AS ABAP 7.0 or later.

+description: This document describes how to configure Microsoft Entra ID to provision users into SAP ERP Central Component (SAP ECC, formerly SAP R/3) with NetWeaver AS ABAP 7.0 or later.

+# Configuring Microsoft Entra ID to provision users into SAP ECC with NetWeaver AS ABAP 7.0 or later

+The following documentation provides configuration and tutorial information demonstrating how to provision users from Microsoft Entra ID into SAP ERP Central Component (SAP ECC, formerly SAP R/3) with NetWeaver 7.0 or later. If you are using other versions such as SAP R/3, you can still use the guides provided in the [download center](https://www.microsoft.com/download/details.aspx?id=51495) as a reference to build your own template and configure provisioning.

+ Title: Microsoft Entra on-premises app provisioning to SCIM-enabled apps

+description: This article describes how to use the Microsoft Entra provisioning service to provision users into an on-premises app that's SCIM enabled.

+# Microsoft Entra on-premises application provisioning to SCIM-enabled apps

+The Microsoft Entra provisioning service supports a [SCIM 2.0](https://techcommunity.microsoft.com/t5/security-compliance-and-identity/provisioning-with-scim-getting-started/ba-p/880010) client that can be used to automatically provision users into cloud or on-premises applications. This article outlines how you can use the Microsoft Entra provisioning service to provision users into an on-premises application that's SCIM enabled. If you want to provision users into non-SCIM on-premises applications that use SQL as a data store, see the [Microsoft Entra ECMA Connector Host Generic SQL Connector tutorial](tutorial-ecma-sql-connector.md). If you want to provision users into cloud apps such as DropBox and Atlassian, review the app-specific [tutorials](../../active-directory/saas-apps/tutorial-list.md).

+- A Microsoft Entra tenant with Microsoft Entra ID P1 or Premium P2 (or EMS E3 or E5). [!INCLUDE [active-directory-p1-license.md](../../../includes/active-directory-p1-license.md)]

+<a name='download-install-and-configure-the-azure-ad-connect-provisioning-agent-package'></a>

+## Download, install, and configure the Microsoft Entra Connect Provisioning Agent Package

+ 1. In the Azure portal, select **Microsoft Entra ID**.

+ 2. On the left, select **Microsoft Entra Connect**.

+ >Please use different provisioning agents for on-premises application provisioning and Microsoft Entra Connect Cloud Sync / HR-driven provisioning. All three scenarios should not be managed on the same agent.

+ 1. The provisioning agent will use the operating system's web browser to display a popup window for you to authenticate to Microsoft Entra ID, and potentially also your organization's identity provider. If you are using Internet Explorer as the browser on Windows Server, then you may need to add Microsoft web sites to your browser's trusted site list to allow JavaScript to run correctly.

+ 1. Provide credentials for a Microsoft Entra administrator when you're prompted to authorize. The user is required to have the Hybrid Identity Administrator or Global Administrator role.

+ 5. Now either wait 10 minutes or restart the **Microsoft Entra Connect Provisioning Agent** before proceeding to the next step & testing the connection.

+* Ensure your [SCIM](https://techcommunity.microsoft.com/t5/security-compliance-and-identity/provisioning-with-scim-getting-started/ba-p/880010) implementation meets the [Microsoft Entra SCIM requirements](use-scim-to-provision-users-and-groups.md).

+ Microsoft Entra ID offers open-source [reference code](https://github.com/AzureAD/SCIMReferenceCode/wiki) that developers can use to bootstrap their SCIM implementation. The code is as is.

+ Title: Microsoft Entra provisioning to applications via web services connector

+description: This document describes how to configure Microsoft Entra ID to provision users with external systems that offer web services based APIs.

+The following documentation provides information about the generic web services connector. Microsoft Entra ID Governance supports provisioning accounts into various applications such as SAP ECC, Oracle eBusiness Suite, and line of business applications that expose REST or SOAP APIs. Customers that have previously deployed MIM to connect to these applications can easily switch to using the lightweight Microsoft Entra provisioning agent, while reusing the same web services connector built for MIM.

+> - Keep user attributes synchronized between Microsoft Entra ID and your application.

+The Microsoft Entra provisioning service allows you to provision users and groups into both [SaaS](user-provisioning.md) and [on-premises](on-premises-scim-provisioning.md) applications. There are four integration paths:

+**Option 1 - Microsoft Entra Application Gallery:**

+Popular third party applications, such as Dropbox, Snowflake, and Workplace by Facebook, are made available for customers through the Microsoft Entra application gallery. New applications can easily be onboarded to the gallery using the [application network portal](../manage-apps/v2-howto-app-gallery-listing.md).

+If your line-of-business application supports the [SCIM](https://aka.ms/scimoverview) standard, it can easily be integrated with the [Microsoft Entra SCIM client](use-scim-to-provision-users-and-groups.md).

+Many new applications use Microsoft Graph to retrieve users, groups and other resources from Microsoft Entra ID. You can learn more about what scenarios to use [SCIM and Graph](scim-graph-scenarios.md) in.

+In cases where an application doesn't support SCIM, partners have built gateways between the Microsoft Entra SCIM client and target applications. **This document serves as a place for partners to attest to integrations that are compatible with Microsoft Entra ID, and for customers to discover these partner-driven integrations.** These gateways are built, maintained, and owned by the third-party vendor.

+ [](media/partner-driven-integrations/partner-driven-connectors-1.png#lightbox)

+The Microsoft Entra platform integrates with IDMWORKS IdentityForge (IDF) Gateway for user lifecycle management for Mainframe systems (RACF, Top Secret, ACF2), Midrange system (AS400), Healthcare applications (EPIC/Cerner), Linux/Unix servers, Databases, and dozens of on-premises and cloud applications. IdentityForge provides a central, standardized integration engine and modern identity store that serves as a trusted source for all lifecycle management.

+The IDF Gateway for Microsoft Entra ID provides lifecycle management for import sources and provisioning target systems that are not covered by the Microsoft Entra connector portfolio like Mainframe systems (RACF, Top Secret, ACF2) or Healthcare applications (EPIC/Cerner). The IDF Gateway powers Microsoft Entra identity lifecycle management (LCM) to continuously synchronize user account information from Mainframe/Healthcare sources and to automate the account provisioning lifecycle use cases like create, read (import), update, deactivate, delete user accounts and perform group management.

+1. Review the Microsoft Entra SCIM [documentation](use-scim-to-provision-users-and-groups.md) to understand the Microsoft Entra SCIM implementation.

+1. Test compatibility between the Microsoft Entra SCIM client and your SCIM gateway.

+* To avoid duplication, only include applications that don't already have out of the box provisioning connectors in the [Microsoft Entra application gallery](../saas-apps/tutorial-list.md).

+For independent software vendors: The Microsoft Entra Application Gallery Terms & Conditions, excluding Sections 2ΓÇô4, apply to this Partner-Driven Integrations Catalog (the ΓÇ£Integrations CatalogΓÇ¥). References to the ΓÇ£GalleryΓÇ¥ shall be read as the ΓÇ£Integrations CatalogΓÇ¥ and references to an ΓÇ£AppΓÇ¥ shall be read as ΓÇ£IntegrationΓÇ¥.

+ Title: Plan an automatic user provisioning deployment for Microsoft Entra ID

+description: Guidance for planning and executing automatic user provisioning in Microsoft Entra ID

+# Plan an automatic user provisioning deployment in Microsoft Entra ID

+Microsoft Entra automatic user provisioning simplifies this process by securely automating the creation, maintenance, and removal of user identities in SaaS applications based on business rules. This automation allows you to effectively scale your identity management systems on both cloud-only and hybrid environments as you expand their dependency on cloud-based solutions.

+See [Automate user provisioning and deprovisioning to SaaS applications with Microsoft Entra ID](../app-provisioning/user-provisioning.md) to better understand the functionality.

+* **Address compliance and governance**. Microsoft Entra ID supports native audit logs for every user provisioning request. Requests are executed in both the source and target systems. Audit logs let you track who has access to applications from a single screen.

+Microsoft Entra ID provides self-service integration of any application using templates provided in the application gallery menu. For a full list of license requirements, see [Microsoft Entra pricing page](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing).

+You need the appropriate licenses for the application(s) you want to automatically provision. Discuss with the application owners whether the users assigned to the application have the proper licenses for their application roles. If Microsoft Entra ID manages automatic provisioning based on roles, the roles assigned in Microsoft Entra ID must align to application licenses. Incorrect licenses owned in the application may lead to errors during the provisioning/updating of a user.

+* Source system - The repository of users that the Microsoft Entra ID provisions from. Microsoft Entra ID is the source system for most preintegrated provisioning connectors. However, there are some exceptions for cloud applications such as SAP, Workday, and AWS. For example, see [User provisioning from Workday to AD](../saas-apps/workday-inbound-tutorial.md).

+* Target system - The repository of users that the Microsoft Entra ID provisions to. The Target system is typically a SaaS application such as ServiceNow, Zscaler, and Slack. The target system can also be an on-premises system such as AD.

+| On-demand webinars| [Manage your Enterprise Applications with Microsoft Entra ID](https://info.microsoft.com/CO-AZUREPLAT-WBNR-FY18-03Mar-06-ManageYourEnterpriseApplicationsOption1-MCW0004438_02OnDemandRegistration-ForminBody.html)<br>ΓÇÄLearn how Microsoft Entra ID can help you achieve SSO to your enterprise SaaS applications and best practices for controlling access. |

+| Videos| [What is user provisioning in Active Azure Directory?](https://youtu.be/_ZjARPpI6NI) <br> [How to deploy user provisioning in Active Azure Directory?](https://youtu.be/pKzyts6kfrw) <br> [Integrating Salesforce with Microsoft Entra ID: How to automate User Provisioning](https://youtu.be/MAy8s5WSe3A)

+| Online courses| SkillUp Online: [Managing Identities](https://skillup.online/courses/course-v1:Microsoft+AZ-100.5+2018_T3/) <br> Learn how to integrate Microsoft Entra ID with many SaaS applications and to secure user access to those applications. |

+| Books| [Modern Authentication with Microsoft Entra ID for Web Applications (Developer Reference) 1st Edition](https://www.amazon.com/Authentication-Directory-Applications-Developer-Reference/dp/0735696942/ref=sr_1_fkmr0_1?keywords=Azure+multifactor+authentication&qid=1550168894&s=gateway&sr=8-1-fkmr0). <br> ΓÇÄThis is an authoritative, deep-dive guide to building Active Directory authentication solutions for these new environments. |

+| Tutorials| See the [list of tutorials on how to integrate SaaS apps with Microsoft Entra ID](../saas-apps/tutorial-list.md). |

+The Microsoft Entra provisioning service provisions users to SaaS apps and other systems by connecting to user management API endpoints provided by each application vendor. These user management API endpoints allow Microsoft Entra ID to programmatically create, update, and remove users.

+In this example, users and or groups are created in an HR database connected to an on-premises directory. The Microsoft Entra provisioning service manages automatic user provisioning to the target SaaS applications.

+1. **Microsoft Entra Connect agent** runs scheduled synchronizations of identities (users and groups) from the local AD to Microsoft Entra ID.

+1. **Microsoft Entra provisioning service** begins an [initial cycle](../app-provisioning/user-provisioning.md) against the source system and target system.

+1. **Microsoft Entra provisioning service** queries the source system for any users and groups changed since the initial cycle, and pushes changes in [incremental cycles](../app-provisioning/user-provisioning.md).

+In this example, user creation occurs in Microsoft Entra ID and the Microsoft Entra provisioning service manages automatic user provisioning to the target (SaaS) applications.

+

+1. Users/groups are created in Microsoft Entra ID.

+1. **Microsoft Entra provisioning service** begins an [initial cycle](../app-provisioning/user-provisioning.md) against the source system and target system.

+1. **Microsoft Entra provisioning service** queries the source system for any users and groups updated since the initial cycle, and performs any [incremental cycles](../app-provisioning/user-provisioning.md).

+In this example, the users and or groups are created in a cloud HR application like such as Workday and SuccessFactors. The Microsoft Entra provisioning service and Microsoft Entra Connect provisioning agent provisions the user data from the cloud HR app tenant into AD. Once the accounts are updated in AD, it's synced with Microsoft Entra ID through Microsoft Entra Connect, and the email addresses and username attributes can be written back to the cloud HR app tenant.

+2. **Microsoft Entra provisioning service** runs the scheduled cycles from the cloud HR app tenant and identifies changes that need to be processed for sync with AD.

+3. **Microsoft Entra provisioning service** invokes the Microsoft Entra Connect provisioning agent with a request payload containing AD account create/update/enable/disable operations.

+4. **Microsoft Entra Connect provisioning agent** uses a service account to manage AD account data.

+5. **Microsoft Entra Connect** runs delta sync to pull updates in AD.

+6. **AD** updates are synced with Microsoft Entra ID.

+7. **Microsoft Entra provisioning service** writebacks email attribute and username from Microsoft Entra ID to the cloud HR app tenant.

+The actual steps required to enable and configure automatic provisioning vary depending on the application. If the application you wish to automatically provision is listed in the [Microsoft Entra SaaS app gallery](../saas-apps/tutorial-list.md), then you should select the [app-specific integration tutorial](../saas-apps/tutorial-list.md) to configure its preintegrated user provisioning connector.

+1. Use the [BYOA SCIM](../app-provisioning/use-scim-to-provision-users-and-groups.md) generic user provisioning support for the app. Using SCIM is a requirement for Microsoft Entra ID to provision users to the app without a preintegrated provisioning connector.

+For more information, see [What applications and systems can I use with Microsoft Entra automatic user provisioning?](../app-provisioning/user-provisioning.md)

+Each application may have unique user or group attributes that must be mapped to the attributes in your Microsoft Entra ID. Application may have only a subset of CRUD operations available.

+To implement automatic user provisioning, you need to define the user and group attributes that are needed for the application. There's a preconfigured set of attributes and [attribute-mappings](../app-provisioning/configure-automatic-user-provisioning-portal.md) between Microsoft Entra user objects, and each SaaS applicationΓÇÖs user objects. Not all SaaS apps enable group attributes.

+Microsoft Entra ID supports by direct attribute-to-attribute mapping, providing constant values, or [writing expressions for attribute mappings](../app-provisioning/functions-for-customizing-application-data.md). This flexibility gives you fine control over what is populated in the targeted system's attribute. You can use [Microsoft Graph API](../app-provisioning/export-import-provisioning-configuration.md) and Graph Explorer to export your user provisioning attribute mappings and schema to a JSON file and import it back into Microsoft Entra ID.

+For more information, see [Customizing User Provisioning Attribute-Mappings for SaaS Applications in Microsoft Entra ID](../app-provisioning/customize-application-attributes.md).

+* Confirm schema consistency between source and target systems. Common issues include attributes such as UPN or mail not matching. For example, UPN in Microsoft Entra ID set as *john_smith@contoso.com* and in the app, it's *jsmith@contoso.com*. For more information, see The [User and group schema reference](../app-provisioning/use-scim-to-provision-users-and-groups.md).

+| User information updates in Microsoft Entra ID by any method. | Updated user attributes reflect in the target system after an incremental cycle. |

+It's common for a security review to be required as part of a deployment. If you require a security review, see the many Microsoft Entra ID [whitepapers](https://www.microsoft.com/download/details.aspx?id=36391) that provides an overview for identity as a service.

+1. Use provisioning audit logs to determine the last known good state of the users and/or groups affected. Also review the source systems (Microsoft Entra ID or AD).

+When the Microsoft Entra provisioning service runs for the first time, the initial cycle against the source system and target systems creates a snapshot of all user objects for each target system.

+When you enable automatic provisioning for an application, the initial cycle takes anywhere from 20 minutes to several hours. The duration depends on the size of the Microsoft Entra directory and the number of users in scope for provisioning.

+The Microsoft Entra user provisioning service can also be configured and managed using the [Microsoft Graph API](/graph/api/resources/synchronization-overview).

+After a successful [initial cycle](../app-provisioning/user-provisioning.md), the Microsoft Entra provisioning service will run incremental updates indefinitely, at intervals specific to each application, until one of the following events occurs:

+To review these events, and all other activities performed by the provisioning service, refer to Microsoft Entra [provisioning logs](../reports-monitoring/concept-provisioning-logs.md?context=azure/active-directory/manage-apps/context/manage-apps-context).

+Microsoft Entra ID can provide more insights into your organizationΓÇÖs user provisioning usage and operational health through audit logs and reports. To learn more about user insights, see [Check the status of user provisioning](application-provisioning-when-will-provisioning-finish-specific-user.md).

+Admins should check the provisioning summary report to monitor the operational health of the provisioning job. All activities performed by the provisioning service are recorded in the Microsoft Entra audit logs. See [Tutorial: Reporting on automatic user account provisioning](../app-provisioning/check-status-user-account-provisioning.md).

+We recommend that you assume ownership of and consume these reports on a cadence that meets your organizationΓÇÖs requirements. Microsoft Entra ID retains most audit data for 30 days.

+* [Problem configuring user provisioning to a Microsoft Entra Gallery application](../app-provisioning/application-provisioning-config-problem.md)

+* [Sync an attribute from your on-premises Active Directory to Microsoft Entra ID for provisioning to an application](../app-provisioning/user-provisioning-sync-attributes-for-mapping.md)

+* [Problem saving administrator credentials while configuring user provisioning to a Microsoft Entra Gallery application](./user-provisioning.md)

+* [No users are being provisioned to a Microsoft Entra Gallery application](../app-provisioning/application-provisioning-config-problem-no-users-provisioned.md)

+* [Wrong set of users are being provisioned to a Microsoft Entra Gallery application](../manage-apps/add-application-portal-assign-users.md)

+* [Microsoft Entra Connect Provisioning Agent: Version release history](provisioning-agent-release-version-history.md)

+* [Keep up to date on what's new with Microsoft Entra ID](https://azure.microsoft.com/updates/?product=active-directory)

+* [Microsoft Q&A Microsoft Entra forum](/answers/topics/azure-active-directory.html)

+* [Writing expressions for attribute mappings in Microsoft Entra ID](../app-provisioning/functions-for-customizing-application-data.md)

+ Title: Plan cloud HR application to Microsoft Entra user provisioning

+description: This article describes the deployment process of integrating cloud HR systems, such as Workday and SuccessFactors, with Microsoft Entra ID. Integrating Microsoft Entra ID with your cloud HR system results in a complete identity lifecycle management system.

+# Plan cloud HR application to Microsoft Entra user provisioning

+To manage the identity lifecycles of employees, vendors, or contingent workers, [Microsoft Entra user provisioning service](../app-provisioning/user-provisioning.md) offers integration with cloud-based human resources (HR) applications. Examples of applications include Workday or SuccessFactors.

+Microsoft Entra ID uses this integration to enable the following cloud HR application (app) workflows:

+- **Provision cloud-only users to Microsoft Entra ID:** In scenarios where Active Directory isn't used, provision users directly from the cloud HR app to Microsoft Entra ID.

+- **Write back to the cloud HR app:** Write the email addresses and username attributes from Microsoft Entra back to the cloud HR app.

+> This deployment plan shows you how to deploy your cloud HR app workflows with Microsoft Entra user provisioning. For information on how to deploy automatic user provisioning to software as a service (SaaS) apps, see [Plan an automatic user provisioning deployment](./plan-auto-user-provisioning.md).

+The Microsoft Entra user provisioning service enables automation of the following HR-based identity lifecycle management scenarios:

+- **New employee hiring:** Adding an employee to the cloud HR app automatically creates a user in Active Directory and Microsoft Entra ID. Adding a user account includes the option to write back the email address and username attributes to the cloud HR app.

+- **Employee attribute and profile updates:** When an employee record such as name, title, or manager is updated in the cloud HR app, their user account is automatically updated in Active Directory and Microsoft Entra ID.

+- **Employee terminations:** When an employee is terminated in the cloud HR app, their user account is automatically disabled in Active Directory and Microsoft Entra ID.

+- **Employee rehires:** When an employee is rehired in the cloud HR app, their old account can be automatically reactivated or reprovisioned to Active Directory and Microsoft Entra ID.

+The cloud HR app integration with Microsoft Entra user provisioning is ideally suited for organizations that:

+- Require direct user provisioning from the cloud HR app to Active Directory or Microsoft Entra ID.

+- **Source system**: The repository of users that Microsoft Entra ID provisions from. An example is a cloud HR app such as Workday or SuccessFactors.

+- **Target system**: The repository of users that the Microsoft Entra ID provisions to. Examples are Active Directory, Microsoft Entra ID, Microsoft 365, or other SaaS apps.

+- **Address compliance and governance:** Microsoft Entra ID supports native audit logs for user provisioning requests performed by apps of both source and target systems. With auditing, you can track who has access to the apps from a single screen.

+To configure the cloud HR app to Microsoft Entra user provisioning integration, you require a valid [Microsoft Entra ID P1 or P2 license](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing) and a license for the cloud HR app, such as Workday or SuccessFactors.

+You also need a valid Microsoft Entra ID P1 or higher subscription license for every user that is sourced from the cloud HR app and provisioned to either Active Directory or Microsoft Entra ID. Any improper number of licenses owned in the cloud HR app might lead to errors during user provisioning.

+- Microsoft Entra ID [hybrid identity administrator](../roles/permissions-reference.md#hybrid-identity-administrator) to configure the Microsoft Entra Connect provisioning agent.

+- Microsoft Entra ID [application administrator](../roles/permissions-reference.md#application-administrator) role to configure the provisioning app in the Azure portal

+- For user provisioning to Active Directory, a server running Windows Server 2016 or greater is required to host the Microsoft Entra Connect provisioning agent. This server should be a tier 0 server based on the Active Directory administrative tier model.

+- [Microsoft Entra Connect](../hybrid/connect/whatis-azure-ad-connect.md) for synchronizing users between Active Directory and Microsoft Entra ID.

+| Tutorials | [List of tutorials on how to integrate SaaS apps with Microsoft Entra ID](../saas-apps/tutorial-list.md) |

+| | [Provisioning from Workday to Microsoft Entra ID](../saas-apps/workday-inbound-tutorial.md#frequently-asked-questions-faq) |

+- **Authoritative HR data flow from cloud HR app to Active Directory.** In this flow, the HR event (Joiners-Movers-Leavers process) is initiated in the cloud HR app tenant. The Microsoft Entra provisioning service and Microsoft Entra Connect provisioning agent provision the user data from the cloud HR app tenant into Active Directory. Depending on the event, it might lead to create, update, enable, and disable operations in Active Directory.

+- **Sync with Microsoft Entra ID and write back email and username from on-premises Active Directory to cloud HR app.** After the accounts are updated in Active Directory, it's synced with Microsoft Entra ID through Microsoft Entra Connect. The email addresses and username attributes can be written back to the cloud HR app tenant.

+2. **Microsoft Entra provisioning service** runs the scheduled cycles from the cloud HR app tenant and identifies changes to process for sync with Active Directory.

+3. **Microsoft Entra provisioning service** invokes the Microsoft Entra Connect provisioning agent with a request payload that contains Active Directory account create, update, enable, and disable operations.

+4. **Microsoft Entra Connect provisioning agent** uses a service account to manage Active Directory account data.

+5. **Microsoft Entra Connect** runs delta [sync](../hybrid/connect/how-to-connect-sync-whatis.md) to pull updates in Active Directory.

+6. **Active Directory** updates are synced with Microsoft Entra ID.

+7. **Microsoft Entra provisioning service** write backs email attribute and username from Microsoft Entra ID to the cloud HR app tenant.

+To facilitate Microsoft Entra provisioning workflows between the cloud HR app and Active Directory, you can add multiple provisioning connector apps from the Microsoft Entra app gallery:

+- **Cloud HR app to Active Directory user provisioning**: This provisioning connector app facilitates user account provisioning from the cloud HR app to a single Active Directory domain. If you have multiple domains, you can add one instance of this app from the Microsoft Entra app gallery for each Active Directory domain you need to provision to.

+- **Cloud HR app to Microsoft Entra user provisioning**: Microsoft Entra Connect is the tool used to synchronize Active Directory on premises users to Microsoft Entra ID. The Cloud HR app to Microsoft Entra user provisioning is a connector you use to provision cloud-only users from the cloud HR app to a single Microsoft Entra tenant.

+- **Cloud HR app write-back**: This provisioning connector app facilitates the write-back of the user's email addresses from Microsoft Entra ID to the cloud HR app.

+For example, the following image lists the Workday connector apps that are available in the Microsoft Entra app gallery.

+<a name='design-the-azure-ad-connect-provisioning-agent-deployment-topology'></a>

+## Design the Microsoft Entra Connect provisioning agent deployment topology

+- Microsoft Entra Connect provisioning agent

+The Microsoft Entra Connect provisioning agent deployment topology depends on the number of cloud HR app tenants and Active Directory child domains that you plan to integrate. If you have multiple Active Directory domains, it depends on whether the Active Directory domains are contiguous or [disjoint](/windows-server/identity/ad-ds/plan/disjoint-namespace).

+|Number of Microsoft Entra Connect provisioning agents to deploy.|Two (for high availability and failover).

+|Server host for Microsoft Entra Connect provisioning agent.|Windows Server 2016 with line of sight to geolocated Active Directory domain controllers. </br>Can coexist with Microsoft Entra Connect service.|

+|Number of Microsoft Entra Connect provisioning agents to deploy on-premises|Two per disjoint Active Directory forest.|

+|Server host for Microsoft Entra Connect provisioning agent.|Windows Server 2016 with line of sight to geolocated Active Directory domain controllers. </br>Can coexist with Microsoft Entra Connect service.|

+<a name='azure-ad-connect-provisioning-agent-requirements'></a>

+### Microsoft Entra Connect provisioning agent requirements

+The cloud HR app to Active Directory user provisioning solution requires the deployment of one or more Microsoft Entra Connect provisioning agents. These agents must be deployed on servers that run Windows Server 2016 or greater. The servers must have a minimum of 4-GB RAM and .NET 4.7.1+ runtime. Ensure that the host server has network access to the target Active Directory domain.

+To prepare the on-premises environment, the Microsoft Entra Connect provisioning agent configuration wizard registers the agent with your Microsoft Entra tenant, [opens ports](../app-proxy/application-proxy-add-on-premises-application.md#open-ports), [allows access to URLs](../app-proxy/application-proxy-add-on-premises-application.md#allow-access-to-urls), and supports [outbound HTTPS proxy configuration](../saas-apps/workday-inbound-tutorial.md#how-do-i-configure-the-provisioning-agent-to-use-a-proxy-server-for-outbound-http-communication).

+For high availability, you can deploy more than one Microsoft Entra Connect provisioning agent. Register the agent to handle the same set of on-premises Active Directory domains.

+* Use the [provisioning agent configuration wizard](../hybrid/cloud-sync/how-to-install.md#install-the-agent) to register your AD domain with your Microsoft Entra tenant.

+* Use the [provisioning agent configuration wizard](../hybrid/cloud-sync/how-to-install.md#install-the-agent) to register all child AD domains with your Microsoft Entra tenant.

+* Use the [provisioning agent configuration wizard](../hybrid/cloud-sync/how-to-install.md#install-the-agent) to register the parent AD domain and all child AD domains with your Microsoft Entra tenant.

+* Use the [provisioning agent configuration wizard](../hybrid/cloud-sync/how-to-install.md#install-the-agent) to register the parent AD domain and all child AD domains with your Microsoft Entra tenant.

+When you enable provisioning from the cloud HR app to Active Directory or Microsoft Entra ID, the Azure portal controls the attribute values through attribute mapping.

+Use [scoping filters](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md) to define the attribute-based rules that determine which users should be provisioned from the cloud HR app to Active Directory or Microsoft Entra ID.

+- Do you plan to use the cloud HR app to Microsoft Entra user provisioning to manage both employees and contingent workers?

+- Do you plan to roll out the cloud HR app to Microsoft Entra user provisioning only for a subset of the cloud HR app users? An example might be employees only.

+With provisioning, you get the ability to match existing accounts between the source and target system. When you integrate the cloud HR app with the Microsoft Entra provisioning service, you can [configure attribute mapping](../app-provisioning/configure-automatic-user-provisioning-portal.md#mappings) to determine what user data should flow from the cloud HR app to Active Directory or Microsoft Entra ID.

+Depending on your requirements, Microsoft Entra ID supports direct attribute-to-attribute mapping by providing constant values or [writing expressions for attribute mappings](../app-provisioning/functions-for-customizing-application-data.md). This flexibility gives you ultimate control of what's populated in the targeted app attribute. You can use the [Microsoft Graph API](../app-provisioning/export-import-provisioning-configuration.md) and Graph Explorer to export your user provisioning attribute mappings and schema to a JSON file and import it back into Microsoft Entra ID.

+Depending on your requirements, you might customize the mapping logic by using [Microsoft Entra expressions](../app-provisioning/functions-for-customizing-application-data.md) so that the Active Directory account is enabled or disabled based on a combination of data points.

+The Microsoft Entra ID function [SelectUniqueValues](../app-provisioning/functions-for-customizing-application-data.md#selectuniquevalue) evaluates each rule and then checks the value generated for uniqueness in the target system. For an example, see [Generate unique value for the userPrincipalName (UPN) attribute](../app-provisioning/functions-for-customizing-application-data.md#generate-unique-value-for-userprincipalname-upn-attribute).

+When you initiate the Joiners process, you need to set and deliver a temporary password of new user accounts. With cloud HR to Microsoft Entra user provisioning, you can roll out the Microsoft Entra ID [self-service password reset](../authentication/tutorial-enable-sspr.md) (SSPR) capability for the user on day one.

+SSPR is a simple means for IT administrators to enable users to reset their passwords or unlock their accounts. You can provision the **Mobile Number** attribute from the cloud HR app to Active Directory and sync it with Microsoft Entra ID. After the **Mobile Number** attribute is in Microsoft Entra ID, you can enable SSPR for the user's account. Then on day one, the new user can use the registered and verified mobile number for authentication. Refer to the [SSPR documentation](../authentication/howto-sspr-authenticationdata.md) for details on how to prepopulate authentication contact information.

+When the Microsoft Entra provisioning service runs for the first time, it performs an [initial cycle](../app-provisioning/how-provisioning-works.md#initial-cycle) against the cloud HR app to create a snapshot of all user objects in the cloud HR app. The time taken for initial cycles is directly dependent on how many users are present in the source system. The initial cycle for some cloud HR app tenants with over 100,000 users can take a long time.

+After you configure the cloud HR app to Microsoft Entra user provisioning, run test cases to verify whether this solution meets your organization's requirements.

+|New employee is hired in the cloud HR app.| - The user account is provisioned in Active Directory.</br>- The user can log into Active Directory-domain apps and perform the desired actions.</br>- If Microsoft Entra Connect Sync is configured, the user account also gets created in Microsoft Entra ID.

+It's common for a security review to be required as part of the deployment of a new service. If a security review is required or hasn't been conducted, see the many Microsoft Entra ID [white papers](https://www.microsoft.com/download/details.aspx?id=36391) that provide an overview of the identity as a service.

+2. The last known good state of the users or groups affected can be determined through the provisioning audit logs or by reviewing the target systems (Microsoft Entra ID or Active Directory).

+**Workday**: To import worker profiles from Workday into Active Directory and Microsoft Entra ID, see [Tutorial: Configure Workday for automatic user provisioning](../saas-apps/workday-inbound-tutorial.md#planning-your-deployment). Optionally, you can write back the email address, username and phone number to Workday.

+**SAP SuccessFactors**: To import worker profiles from SuccessFactors into Active Directory and Microsoft Entra ID, see [Tutorial: Configure SAP SuccessFactors for automatic user provisioning](../saas-apps/sap-successfactors-inbound-provisioning-tutorial.md). Optionally, you can write back the email address and username to SuccessFactors.

+Microsoft Entra ID can provide more insights into your organization's user provisioning usage and operational health through audit logs and reports.

+After a successful [initial cycle](../app-provisioning/how-provisioning-works.md#initial-cycle), the Microsoft Entra provisioning service continues to run back-to-back incremental updates indefinitely, at intervals defined in the tutorials specific to each app, until one of the following events occurs:

+All activities performed by the provisioning service are recorded in the Microsoft Entra audit logs. You can route Microsoft Entra audit logs to Azure Monitor logs for further analysis. With Azure Monitor logs (also known as Log Analytics workspace), you can query data to find events, analyze trends, and perform correlation across various data sources. Watch this [video](https://youtu.be/MP5IaCTwkQg) to learn the benefits of using Azure Monitor logs for Microsoft Entra ID logs in practical user scenarios.

+Install the [log analytics views for Microsoft Entra activity logs](../../azure-monitor/visualize/workbooks-view-designer-conversion-overview.md) to get access to [prebuilt reports](https://github.com/AzureAD/Deployment-Plans/tree/master/Log%20Analytics%20Views) around provisioning events in your environment.

+For more information, see how to [analyze the Microsoft Entra activity logs with your Azure Monitor logs](../reports-monitoring/howto-analyze-activity-logs-log-analytics.md).

+The Microsoft Entra Connect provisioning agent installed on the Windows server creates logs in the Windows event log that might contain personal data depending on your cloud HR app to Active Directory attribute mappings. To comply with user privacy obligations, set up a Windows scheduled task to clear the event log and ensure that no data is kept beyond 48 hours.

+Microsoft Entra provisioning service doesn't generate reports, perform analytics, or provide insights beyond 30 days because the service doesn't store, process, or keep any data beyond 30 days.

+- [Problem configuring user provisioning to a Microsoft Entra Gallery application](application-provisioning-config-problem.md)

+- [Sync an attribute from your on-premises Active Directory to Microsoft Entra ID for provisioning to an application](user-provisioning-sync-attributes-for-mapping.md)

+- [Problem saving administrator credentials while configuring user provisioning to a Microsoft Entra Gallery application](./user-provisioning.md)

+- [No users are being provisioned to a Microsoft Entra Gallery application](application-provisioning-config-problem-no-users-provisioned.md)

+- [Wrong set of users are being provisioned to a Microsoft Entra Gallery application](../manage-apps/add-application-portal-assign-users.md)

+- [Microsoft Entra Connect Provisioning Agent: Version release history](provisioning-agent-release-version-history.md)

+ Title: Provision a user or group on demand using the Microsoft Entra provisioning service

+description: Learn how to provision users on demand in Microsoft Entra ID.

+# On-demand provisioning in Microsoft Entra ID

+2. Go to **Microsoft Entra ID** > **Enterprise applications** > **All applications**.

+2. Go to **Microsoft Entra ID** > **Cross-tenant Synchronization** > **Configurations**

+* For System for Cross-domain Identity Management (SCIM) applications, you can use a tool like Postman. Such tools help you ensure that the application responds to authorization requests in the way that the Microsoft Entra provisioning service expects. Have a look at an [example request](./use-scim-to-provision-users-and-groups.md#request-3).

+The **View details** section shows the properties of the user that were imported from the source system (for example, Microsoft Entra ID).

+* **Active in source system** indicates that the user has the property `IsActive` set to **true** in Microsoft Entra ID.

+* **Assigned to application** indicates that the user is assigned to the application in Microsoft Entra ID.

+* On-demand provisioning supports disabling users that have been unassigned from the application. However, it doesn't support disabling or deleting users that have been disabled or deleted from Microsoft Entra ID. Those users don't appear when you search for a user.

+* The on-demand provisioning request API can only accept a single group with up to 5 members at a time.

+Azure AD user provisioning can help address these challenges. To learn more about how customers have been using Azure AD user provisioning, read the [ASOS case study](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/asos-better-protects-its-data-with-azure-ad-automated-user/ba-p/827846). The following video provides an overview of user provisioning in Azure AD.

+ Title: Integrate with Microsoft Entra application proxy on an NDES server

+description: Guidance on deploying a Microsoft Entra application proxy to protect your NDES server.

+# Integrate with Microsoft Entra application proxy on a Network Device Enrollment Service (NDES) server

+Microsoft Entra application proxy lets you publish applications inside your network. These applications are ones such as SharePoint sites, Microsoft Outlook Web App, and other web applications. It also provides secure access to users outside your network via Azure.

+If you're new to Microsoft Entra application proxy and want to learn more, see [Remote access to on-premises applications through Microsoft Entra application proxy](application-proxy.md).

+Microsoft Entra application proxy is built on Azure. It gives you a massive amount of network bandwidth and server infrastructure for better protection against distributed denial-of-service (DDOS) attacks and superb availability. Furthermore, there's no need to open external firewall ports to your on-premises network and no DMZ server is required. All traffic is originated inbound. For a complete list of outbound ports, see [Tutorial: Add an on-premises application for remote access through Application Proxy in Microsoft Entra ID](./application-proxy-add-on-premises-application.md#prepare-your-on-premises-environment).

+> Microsoft Entra application proxy is a feature that is available only if you are using the Premium or Basic editions of Microsoft Entra ID. For more information, see [Microsoft Entra pricing](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing).

+> The Microsoft Entra application proxy connector only installs on Windows Server 2012 R2 or later. This is also a requirement of the NDES server.

+1. Copy the Microsoft Entra application proxy connector setup file to your NDES server.

+1. During the install, you're prompted to register the connector with the Application Proxy in your Microsoft Entra directory.

+ * Provide the credentials for a global or application administrator in your Microsoft Entra directory. The Microsoft Entra global or application administrator credentials may be different from your Azure credentials in the portal.

+ > For example, if the Microsoft Entra domain is *contoso.com*, the global/application administrator should be `admin@contoso.com` or another valid alias on that domain.

+1. At the end of the setup, a note is shown for environments with an outbound proxy. To configure the Microsoft Entra application proxy connector to work through the outbound proxy, run the provided script, such as `C:\Program Files\Microsoft AAD App Proxy connector\ConfigureOutBoundProxy.ps1`.

+ 

+ > To provide high availability for applications authenticating through the Microsoft Entra application proxy, you can install connectors on multiple VMs. Repeat the same steps listed in the previous section to install the connector on other servers joined to the Microsoft Entra DS managed domain.

+1. Test whether you can access your NDES server via the Microsoft Entra application proxy by pasting the link you copied in step 15 into a browser. You should see a default IIS welcome page.

+With the Microsoft Entra application proxy integrated with NDES, publish applications for users to access. For more information, see [publish applications using Microsoft Entra application proxy](./application-proxy-add-on-premises-application.md).

+ Title: Tutorial - Add an on-premises app - Application Proxy in Microsoft Entra ID

+description: Microsoft Entra ID has an Application Proxy service that enables users to access on-premises applications by signing in with their Microsoft Entra account. This tutorial shows you how to prepare your environment for use with Application Proxy. Then, it uses the Microsoft Entra admin center to add an on-premises application to your Microsoft Entra tenant.

+# Tutorial: Add an on-premises application for remote access through Application Proxy in Microsoft Entra ID

+Microsoft Entra ID has an Application Proxy service that enables users to access on-premises applications by signing in with their Microsoft Entra account. To learn more about Application Proxy, see [What is App Proxy?](what-is-application-proxy.md). This tutorial prepares your environment for use with Application Proxy. Once your environment is ready, use the Microsoft Entra admin center to add an on-premises application to your tenant.

+- [Quickstart Series on App Management in Microsoft Entra ID](../manage-apps/view-applications-portal.md)

+Connectors are a key part of Application Proxy. To learn more about connectors, see [Understand Microsoft Entra application proxy connectors](application-proxy-connectors.md).

+> * Adds an on-premises application to your Microsoft Entra tenant

+> * Verifies a test user can sign on to the application by using a Microsoft Entra account

+To add an on-premises application to Microsoft Entra ID, you need:

+* A [Microsoft Entra ID P1 or P2 subscription](https://azure.microsoft.com/pricing/details/active-directory)

+* User identities must be synchronized from an on-premises directory or created directly within your Microsoft Entra tenants. Identity synchronization allows Microsoft Entra ID to preauthenticate users before granting them access to App Proxy published applications and to have the necessary user identifier information to perform single sign-on (SSO).

+1. Physically locate the connector server close to the application servers to optimize performance between the connector and the application. For more information, see [Optimize traffic flow with Microsoft Entra application proxy](application-proxy-network-topology.md).

+> If you've deployed Microsoft Entra Password Protection Proxy, do not install Microsoft Entra application proxy and Microsoft Entra Password Protection Proxy together on the same machine. Microsoft Entra application proxy and Microsoft Entra Password Protection Proxy install different versions of the Microsoft Entra Connect Agent Updater service. These different versions are incompatible when installed together on the same machine.

+Start by enabling communication to Azure data centers to prepare your environment for Microsoft Entra application proxy. If there's a firewall in the path, make sure it's open. An open firewall allows the connector to make HTTPS (TCP) requests to the Application Proxy.

+> Avoid all forms of inline inspection and termination on outbound TLS communications between Microsoft Entra application proxy connectors and Microsoft Entra application proxy Cloud services.

+<a name='dns-name-resolution-for-azure-ad-application-proxy-endpoints'></a>

+### DNS name resolution for Microsoft Entra application proxy endpoints

+Public DNS records for Microsoft Entra application proxy endpoints are chained CNAME records pointing to an A record. Setting up the records this way ensures fault tolerance and flexibility. ItΓÇÖs guaranteed that the Microsoft Entra application proxy Connector always accesses host names with the domain suffixes `*.msappproxy.net` or `*.servicebus.windows.net`. However, during the name resolution the CNAME records might contain DNS records with different host names and suffixes. Due to the difference, you must ensure that the device (depending on your setup - connector server, firewall, outbound proxy) can resolve all the records in the chain and allows connection to the resolved IP addresses. Since the DNS records in the chain might be changed from time to time, we can't provide you with any list DNS records.

+To use Application Proxy, install a connector on each Windows server you're using with the Application Proxy service. The connector is an agent that manages the outbound connection from the on-premises application servers to Application Proxy in Microsoft Entra ID. You can install a connector on servers that also have other authentication agents installed such as Microsoft Entra Connect.

+1. Follow the instructions in the wizard to install the service. When you're prompted to register the connector with the Application Proxy for your Microsoft Entra tenant, provide your application administrator credentials.

+If you have installed connectors in different regions, you can optimize traffic by selecting the closest Application Proxy cloud service region to use with each connector group, see [Optimize traffic flow with Microsoft Entra application proxy](application-proxy-network-topology.md)

+For information about connectors, capacity planning, and how they stay up-to-date, see [Understand Microsoft Entra application proxy connectors](application-proxy-connectors.md).

+ 

+ - **Microsoft Entra application proxy Connector** enables connectivity.

+ - **Microsoft Entra application proxy Connector Updater** is an automated update service. The updater checks for new versions of the connector and updates the connector as needed.

+<a name='add-an-on-premises-app-to-azure-ad'></a>

+## Add an on-premises app to Microsoft Entra ID

+Now that you've prepared your environment and installed a connector, you're ready to add on-premises applications to Microsoft Entra ID.

+ | **External URL** | The address for users to access the app from outside your network. If you don't want to use the default Application Proxy domain, read about [custom domains in Microsoft Entra application proxy](./application-proxy-configure-custom-domain.md). |

+ | **Pre Authentication** | How Application Proxy verifies users before giving them access to your application.<br><br>**Microsoft Entra ID** - Application Proxy redirects users to sign in with Microsoft Entra ID, which authenticates their permissions for the directory and application. We recommend keeping this option as the default so that you can take advantage of Microsoft Entra security features like Conditional Access and Multi-Factor Authentication. **Microsoft Entra ID** is required for monitoring the application with Microsoft Defender for Cloud Apps.<br><br>**Passthrough** - Users don't have to authenticate against Microsoft Entra ID to access the application. You can still set up authentication requirements on the backend. |

+ | **Use Persistent Cookie**| Keep the option unselected. Only use this setting for applications that can't share cookies between processes. For more information about cookie settings, see [Cookie settings for accessing on-premises applications in Microsoft Entra ID](./application-proxy-configure-cookie-settings.md).

+ | **Translate URLs in Application Body** | Keep the option unselected unless you have hardcoded HTML links to other on-premises applications and don't use custom domains. For more information, see [Link translation with Application Proxy](./application-proxy-configure-hard-coded-link-translation.md).<br><br>Select if you plan to monitor this application with Microsoft Defender for Cloud Apps. For more information, see [Configure real-time application access monitoring with Microsoft Defender for Cloud Apps and Microsoft Entra ID](./application-proxy-integrate-with-microsoft-cloud-application-security.md). |

+In this tutorial, you prepared your on-premises environment to work with Application Proxy, and then installed and registered the Application Proxy connector. Next, you added an application to your Microsoft Entra tenant. You verified that a user can sign on to the application by using a Microsoft Entra account.

+> * Added an on-premises application to your Microsoft Entra tenant

+> * Verified a test user can sign on to the application by using a Microsoft Entra account

+description: How to add Web Application Firewall protection for apps published with Microsoft Entra application proxy.

+When using Microsoft Entra application proxy to expose applications deployed on-premises, on sealed Azure Virtual Networks, or in other public clouds, you can integrate a Web Application Firewall (WAF) in the data flow in order to protect your application from malicious attacks.

+This article guides you through the steps to securely expose a web application on the Internet, by integrating the Microsoft Entra application proxy with Azure WAF on Application Gateway. In this guide we'll be using the Microsoft Entra admin center. The reference architecture for this deployment is represented below.

+ <a name='configure-your-application-to-be-remotely-accessed-through-application-proxy-in-azure-ad'></a>

+### Configure your application to be remotely accessed through Application Proxy in Microsoft Entra ID.

+For a detailed guide on how to add your application to Application Proxy in Microsoft Entra ID, see [Tutorial: Add an on-premises application for remote access through Application Proxy in Microsoft Entra ID][appproxy-add-app]. For more information about performance considerations concerning the Application Proxy connectors, see [Optimize traffic flow with Microsoft Entra application proxy][appproxy-optimize].

+In this example, the same URL was configured as the internal and external URL. Remote clients will access the application over the Internet on port 443, through the Application Proxy, whereas clients connected to the corporate network will access the application privately through the Application Gateway directly, also on port 443. For a detailed step on how to configure custom domains in Application Proxy, see [Configure custom domains with Microsoft Entra application proxy][appproxy-custom-domain].

+After [adding a user for testing](./application-proxy-add-on-premises-application.md#add-a-user-for-testing), you can test the application by accessing https://www.fabrikam.one. The user will be prompted to authenticate in Microsoft Entra ID, and upon successful authentication, will access the application.

+[waf-logs]: ../../application-gateway/application-gateway-diagnostics.md#firewall-log

+description: How to optimize performance for global connectivity scenarios using Azure Front Door (for Geo-Acceleration) with Microsoft Entra application proxy.

+This article explains how to configure Microsoft Entra application proxy to work with Azure Front Door (AFD) to achieve reduce latency and better performance.

+This article guides you through the steps to securely expose a web application on the Internet, by integrating the Microsoft Entra application proxy with Azure Front Door. In this guide we'll be using the Microsoft Entra admin center. The reference architecture for this deployment is represented below.

+- For licensing information, Application Proxy is available through a Microsoft Entra ID P1 or P2 subscription. Refer here for a full listing of licensing options and features: [Microsoft Entra pricing](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing)

+ - Set the External URL to the domain address you want the users to access the app from. For this you must configure a custom domain for our application here, for example, contoso.org. Reference: [Custom domains in Microsoft Entra application proxy][appproxy-custom-domain]

+The methods available for achieving SSO to published applications can vary from one application to another. One option that Microsoft Entra application proxy offers by default is Kerberos constrained delegation (KCD). You can configure a connector, for your users, to run constrained Kerberos authentication to back-end applications.

+- Deployment of Microsoft Entra application proxy per [Get started with Application Proxy](application-proxy-add-on-premises-application.md) and general access to non-KCD applications work as expected.

+- The server and application hosts reside in a single Microsoft Entra domain. For detailed information on cross-domain and forest scenarios, see the [KCD white paper](https://aka.ms/KCDPaper).

+Microsoft Entra application proxy can be deployed into many types of infrastructures or environments. The architectures vary from organization to organization. The most common causes of KCD-related issues aren't the environments. Simple misconfigurations or general mistakes cause most issues.

+1. Verify that there's only one instance of the SPN in existence in Microsoft Entra ID. Issue `setspn -x` from a command prompt on any domain member host.

+ *Microsoft Entra application proxy Connector cannot authenticate the user because the backend server responds to Kerberos authentication attempts with an HTTP 401 error.*

+ - Check the IIS application. Make sure that the configured application pool and the SPN are configured to use the same account in Microsoft Entra ID. Navigate in IIS as shown in the following illustration:

+ - Check the SPN defined against the applicationΓÇÖs settings in the portal. Make sure that the same SPN configured against the target Microsoft Entra account is used by the applicationΓÇÖs app pool.

+ This additional check puts you on track to use your published application. You can spin up additional connectors that are also configured to delegate. For more information, read the more in-depth technical walk-through, [Troubleshooting the Microsoft Entra application proxy](https://aka.ms/proxytshootpaper).

+ Title: How to configure a Microsoft Entra application proxy application

+description: Learn how to create and configure a Microsoft Entra application proxy application in a few simple steps

+This article helps you to understand how to configure an Application Proxy application within Microsoft Entra ID to expose your on-premises applications to the cloud.

+To learn about the initial configurations and creation of an Application Proxy application through the Admin Portal, follow the [Publish applications using Microsoft Entra application proxy](application-proxy-add-on-premises-application.md).

+For information on uploading certificates and using custom domains, see [Working with custom domains in Microsoft Entra application proxy](application-proxy-configure-custom-domain.md).

+If you are following the steps in the [Publish applications using Microsoft Entra application proxy](application-proxy-add-on-premises-application.md) documentation and are getting an error creating the application, see the error details for information and suggestions for how to fix the application. Most error messages include a suggested fix. To avoid common errors, verify:

+Custom Domains allow you to specify the domain of your external URLs. To use custom domains, you need to upload the certificate for that domain. For information on using custom domains and certificates, see [Working with custom domains in Microsoft Entra application proxy](application-proxy-configure-custom-domain.md).

+[Publish applications using Microsoft Entra application proxy](application-proxy-add-on-premises-application.md)

+ Title: Problem creating a Microsoft Entra application proxy application

+To learn more about creating an Application Proxy application through the Admin Portal, see [Publish applications using Microsoft Entra application proxy](application-proxy-add-on-premises-application.md).

+Single sign-on (SSO) allows your users to access an application without authenticating multiple times. It allows the single authentication to occur in the cloud, against Microsoft Entra ID, and allows the service or Connector to impersonate the user to complete any additional authentication challenges from the application.

+To configure SSO, first make sure that your application is configured for Pre-Authentication through Microsoft Entra ID.

+- **Password-based sign-on:** Password-based sign-on can be used for any application that uses username and password fields to sign on. Configuration steps are in [Configure password Single sign-on for a Microsoft Entra gallery application](../manage-apps/configure-password-single-sign-on-non-gallery-applications.md).

+- **SAML single sign-on:** With SAML single sign-on, Microsoft Entra authenticates to the application by using the user's Microsoft Entra account. Microsoft Entra ID communicates the sign-on information to the application through a connection protocol. With SAML-based single sign-on, you can map users to specific application roles based on rules you define in your SAML claims. For information about setting up SAML single sign-on, see [SAML for single sign-on with Application Proxy](application-proxy-configure-single-sign-on-on-premises-apps.md).

+ Title: Complex applications for Microsoft Entra application proxy

+description: Provides an understanding of complex application in Microsoft Entra application proxy, and how to configure one.

+# Understanding Microsoft Entra application proxy Complex application scenario (Preview)

+When applications are made up of multiple individual web application using different domain suffixes or different ports or paths in the URL, the individual web application instances must be published in separate Microsoft Entra application proxy apps and the following problems might arise:

+1. Pre-authentication- The client must separately acquire an access token or cookie for each Microsoft Entra application proxy app. This might lead to additional redirects to login.microsoftonline.com and CORS issues.

+2. CORS issues- Cross-origin resource sharing calls (OPTIONS request) might be triggered to validate if the caller web app is allowed to access the URL of the targeted web app. These will be blocked by the Microsoft Entra application proxy Cloud service, since these requests cannot contain authentication information.

+With [Microsoft Entra application proxy](application-proxy.md), you can address this issue by using complex application publishing that is made up of multiple URLs across various domains.

+> Two application segment per complex distributed application are supported for [Microsoft Entra ID P1 or P2 subscription](https://azure.microsoft.com/pricing/details/active-directory). License requirement for more than two application segments per complex application to be announced soon.

+For more detailed instructions for Application Proxy, see [Tutorial: Add an on-premises application for remote access through Application Proxy in Microsoft Entra ID](../app-proxy/application-proxy-add-on-premises-application.md).

+- [Tutorial: Add an on-premises application for remote access through Application Proxy in Microsoft Entra ID](../app-proxy/application-proxy-add-on-premises-application.md)

+- [Plan a Microsoft Entra application proxy deployment](application-proxy-deployment-plan.md)

+- [Remote access to on-premises applications through Microsoft Entra application proxy](application-proxy.md)

+- [Understand and solve Microsoft Entra application proxy CORS issues](application-proxy-understand-cors-issues.md)

+ Title: Work with existing on-premises proxy servers and Microsoft Entra ID

+description: Covers how to work with existing on-premises proxy servers with Microsoft Entra ID.

+This article explains how to configure Microsoft Entra application proxy connectors to work with outbound proxy servers. It is intended for customers with network environments that have existing proxies.

+* Configure connectors to use an outbound proxy to access Microsoft Entra application proxy.

+For more information about how connectors work, see [Understand Microsoft Entra application proxy connectors](application-proxy-connectors.md).

+To disable outbound proxy usage for the connector, edit the C:\Program Files\Microsoft Azure AD App Proxy Connector\ApplicationProxyConnectorService.exe.config file and add the *system.net* section shown in this code sample:

+To ensure that the Connector Updater service also bypasses the proxy, make a similar change to the ApplicationProxyConnectorUpdaterService.exe.config file. This file is located at C:\Program Files\Microsoft Azure AD App Proxy Connector Updater.

+ 

+To do so, edit the C:\Program Files\Microsoft Azure AD App Proxy Connector\ApplicationProxyConnectorService.exe.config file, and add the *system.net* section shown in this code sample. Change *proxyserver:8080* to reflect your local proxy server name or IP address, and the port that it's listening on. The value must have the prefix http:// even if you are using an IP address.

+Next, configure the Connector Updater service to use the proxy by making a similar change to the C:\Program Files\Microsoft Azure AD App Proxy Connector Updater\ApplicationProxyConnectorUpdaterService.exe.config file.

+`UseDefaultProxyForBackendRequests = 1` to the Connector configuration registry key located in "HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft Azure AD App Proxy Connector".

+1. From services.msc, stop the Microsoft Entra application proxy Connector service.

+ 

+1. Start the Microsoft Entra application proxy Connector service.

+* [Understand Microsoft Entra application proxy connectors](application-proxy-connectors.md)

+* If you have problems with connector connectivity issues, ask your question in the [Microsoft Q&A question page for Microsoft Entra ID](/answers/topics/azure-active-directory.html) or create a ticket with our support team.

+description: Microsoft Entra ID has access and session cookies for accessing on-premises applications through Application Proxy. In this article, you'll find out how to use and configure the cookie settings.

+# Cookie settings for accessing on-premises applications in Microsoft Entra ID

+Microsoft Entra ID has access and session cookies for accessing on-premises applications through Application Proxy. Find out how to use the Application Proxy cookie settings.

+ Title: Custom domains in Microsoft Entra application proxy

+description: Configure and manage custom domains in Microsoft Entra application proxy.

+# Configure custom domains with Microsoft Entra application proxy

+When you publish an application through Microsoft Entra application proxy, you create an external URL for your users. This URL gets the default domain *yourtenant.msappproxy.net*. For example, if you publish an app named *Expenses* in your tenant named *Contoso*, the external URL is *https:\//expenses-contoso.msappproxy.net*. If you want to use your own domain name instead of *msappproxy.net*, you can configure a custom domain for your application.

+- Links between apps work even outside the corporate network. Without a custom domain, if your app has hard-coded internal links to targets outside the Application Proxy, and the links aren't externally resolvable, they will break. When your internal and external URLs are the same, you avoid this problem. If you're not able to use custom domains, see [Redirect hardcoded links for apps published with Microsoft Entra application proxy](./application-proxy-configure-hard-coded-link-translation.md) for other ways to address this issue.

+To configure an on-premises app to use a custom domain, you need a verified Microsoft Entra custom domain, a PFX certificate for the custom domain, and an on-premises app to configure.

+1. After you register the domain, on the domain's page in Microsoft Entra ID, select **Verify**. Once the domain status is **Verified**, you can use the domain across all your Microsoft Entra configurations, including Application Proxy.

+For more detailed instructions for Application Proxy, see [Tutorial: Add an on-premises application for remote access through Application Proxy in Microsoft Entra ID](application-proxy-add-on-premises-application.md).

+* [Enable single sign-on](application-proxy-configure-single-sign-on-with-kcd.md) to your published apps with Microsoft Entra authentication.

+ Title: Custom home page for published apps - Microsoft Entra application proxy

+description: Covers the basics about Microsoft Entra application proxy connectors

+# Set a custom home page for published apps by using Microsoft Entra application proxy

+This article discusses how to configure an app to direct a user to a custom home page. When you publish an app with Application Proxy, you set an internal URL, but sometimes that's not the page a user should see first. Set a custom home page so that a user gets the right page when they access the app. A user will see the custom home page that you set, regardless of whether they access the app from the Microsoft Entra My Apps or the Microsoft 365 app launcher.

+1. In the same PowerShell window, import the Microsoft Entra module.

+1. Sign in to the Microsoft Entra module as the tenant administrator.

+Create the home page URL, and update your app with that value. Continue using the same PowerShell window, or if you're using a new PowerShell window, sign in to the Microsoft Entra module again using `Connect-AzureAD`. Then follow these steps:

+- [Enable remote access to SharePoint with Microsoft Entra application proxy](./application-proxy-integrate-with-sharepoint-server.md)

+- [Tutorial: Add an on-premises application for remote access through Application Proxy in Microsoft Entra ID](application-proxy-add-on-premises-application.md)

+ Title: Claims-aware apps - Microsoft Entra application proxy

+3. If you chose **Microsoft Entra ID** as your **Preauthentication Method**, select **Microsoft Entra single sign-on disabled** as your **Internal Authentication Method**. If you chose **Passthrough** as your **Preauthentication Method**, you don't need to change anything.

+* [Enable native client apps to interact with proxy applications](application-proxy-configure-native-client-application.md)

+ Title: Translate links and URLs Microsoft Entra application proxy

+description: Learn how to redirect hard-coded links for apps published with Microsoft Entra application proxy.

+# Redirect hard-coded links for apps published with Microsoft Entra application proxy

+Microsoft Entra application proxy makes your on-premises apps available to users who are remote or on their own devices. Some apps, however, were developed with local links embedded in the HTML. These links don't work correctly when the app is used remotely. When you have several on-premises applications point to each other, your users expect the links to keep working when they're not at the office.

+> The last option is only for tenants that, for whatever reason, can't use custom domains to have the same internal and external URLs for their apps. Before you enable this feature, see if [custom domains in Microsoft Entra application proxy](application-proxy-configure-custom-domain.md) can work for you.

+[Use custom domains with Microsoft Entra application proxy](application-proxy-configure-custom-domain.md) to have the same internal and external URL

+description: Covers how to enable native client apps to communicate with Microsoft Entra application proxy Connector to provide secure remote access to your on-premises apps.

+You can use Microsoft Entra application proxy to publish web apps, but it also can be used to publish native client applications that are configured with the Microsoft Authentication Library (MSAL). Native client applications differ from web apps because they're installed on a device, while web apps are accessed through a browser.

+To support native client applications, Application Proxy accepts Microsoft Entra ID-issued tokens that are sent in the header. The Application Proxy service does the authentication for the users. This solution doesn't use application tokens for authentication.

+

+You now need to register your application in Microsoft Entra ID, as follows:

+For more detailed information about creating a new application registration, see [Integrating applications with Microsoft Entra ID](../develop/quickstart-register-app.md).

+| \<Tenant ID> | **Microsoft Entra ID** > **Properties** > **Directory ID** |

+For more information about the native application flow, see [mobile](../develop/authentication-flows-app-scenarios.md#mobile-app-that-calls-a-web-api-on-behalf-of-an-interactive-user) and [desktop](../develop/authentication-flows-app-scenarios.md#desktop-app-that-calls-a-web-api-on-behalf-of-a-signed-in-user) apps in Microsoft Entra ID.

+Learn about setting up [Single sign-on to applications in Microsoft Entra ID](../manage-apps/plan-sso-deployment.md#choosing-a-single-sign-on-method).

+ Title: SAML single sign-on for on-premises apps with Microsoft Entra application proxy

+You can provide single sign-on (SSO) to on-premises applications that are secured with SAML authentication and provide remote access to these applications through Application Proxy. With SAML single sign-on, Microsoft Entra authenticates to the application by using the user's Microsoft Entra account. Microsoft Entra ID communicates the sign-on information to the application through a connection protocol. You can also map users to specific application roles based on rules you define in your SAML claims. By enabling Application Proxy in addition to SAML SSO, your users will have external access to the application and a seamless SSO experience.

+The applications must be able to consume SAML tokens issued by **Microsoft Entra ID**.

+This configuration doesn't apply to applications using an on-premises identity provider. For these scenarios, we recommend reviewing [Resources for migrating applications to Microsoft Entra ID](../manage-apps/migration-resources.md).

+SAML SSO with Application Proxy also works with the SAML token encryption feature. For more info, see [Configure Microsoft Entra SAML token encryption](../manage-apps/howto-saml-token-encryption.md).

+ 

+ 

+1. In the Microsoft Entra admin center, select **Microsoft Entra ID > Enterprise applications** and select **New application**.

+Before you can provide SSO for on-premises applications, you need to enable Application Proxy and install a connector. See the tutorial [Add an on-premises application for remote access through Application Proxy in Microsoft Entra ID](application-proxy-add-on-premises-application.md) to learn how to prepare your on-premises environment, install and register a connector, and test the connector. Then follow these steps to publish your new application with Application Proxy. For other settings not mentioned below, refer to the [Add an on-premises app to Microsoft Entra ID](application-proxy-add-on-premises-application.md#add-an-on-premises-app-to-azure-ad) section in the tutorial.

+ > As a best practice, use custom domains whenever possible for an optimized user experience. Learn more about [Working with custom domains in Microsoft Entra application proxy](application-proxy-configure-custom-domain.md).

+2. Select **Microsoft Entra ID** as the **Pre Authentication** method for your application.

+- [How does Microsoft Entra application proxy provide single sign-on?](../manage-apps/what-is-single-sign-on.md)

+ Title: Single sign-on to apps with Microsoft Entra application proxy

+description: Turn on single sign-on for your published on-premises applications with Microsoft Entra application proxy in the Microsoft Entra admin center.

+Microsoft Entra application proxy helps you improve productivity by publishing on-premises applications so that remote employees can securely access them, too. In the Microsoft Entra admin center, you can also set up single sign-on (SSO) to these apps. Your users only need to authenticate with Microsoft Entra ID, and they can access your enterprise application without having to sign in again.

+Application Proxy supports several [single sign-on modes](../manage-apps/plan-sso-deployment.md#choosing-a-single-sign-on-method). Password-based sign-on is intended for applications that use a username/password combination for authentication. When you configure password-based sign-on for your application, your users have to sign in to the on-premises application once. After that, Microsoft Entra ID stores the sign-in information and automatically provides it to the application when your users access it remotely.

+You should already have published and tested your app with Application Proxy. If not, follow the steps in [Publish applications using Microsoft Entra application proxy](application-proxy-add-on-premises-application.md) then come back here.

+1. Change the **Pre Authentication type** to **Passthrough** and select **Save**. Later you can switch back to **Microsoft Entra ID** type again!

+1. Change the **Pre Authentication type** to **Microsoft Entra ID** and select **Save**.

+1. Select **Microsoft Entra ID** > **App registrations** > **All applications**.

+- Learn about [Security considerations for accessing apps remotely with Microsoft Entra application proxy](application-proxy-security.md)

+ Title: Header-based single sign-on for on-premises apps with Microsoft Entra application proxy

+# Header-based single sign-on for on-premises apps with Microsoft Entra application proxy

+Microsoft Entra application proxy natively supports single sign-on access to applications that use headers for authentication. You can configure header values required by your application in Microsoft Entra ID. The header values will be sent down to the application via Application Proxy. Some benefits to using native support for header-based authentication with Application Proxy include:

+* **Wide list of attributes and transformations available** - All header values available are based on standard claims that are issued by Microsoft Entra ID. All attributes and transformations available for [configuring claims for SAML or OIDC applications](../develop/saml-claims-customization.md#attributes) are also available to be used as header values.

+|Federated SSO |In pre-authenticated mode, all applications are protected with Microsoft Entra authentication and enable users to have single sign-on. |

+|Header-based integration |Application Proxy does the SSO integration with Microsoft Entra ID and then passes identity or other application data as HTTP headers to the application. |

+|Application authorization |Common policies can be specified based on the application being accessed, the userΓÇÖs group membership and other policies. In Microsoft Entra ID, policies are implemented using [Conditional Access](../conditional-access/overview.md). Application authorization policies only apply to the initial authentication request. |

+> This article features connecting header-based authentication applications to Microsoft Entra ID using Application Proxy and is the recommended pattern. As an alternative, there is also an integration pattern that uses PingAccess with Microsoft Entra ID to enable header-based authentication. For more details, see [Header-based authentication for single sign-on with Application Proxy and PingAccess](application-proxy-ping-access-publishing-guide.md).

+2. When a user accesses the app, Application Proxy ensures the user is authenticated by Microsoft Entra ID

+2. Select **Microsoft Entra ID** as the **pre-authentication method**.

+Before you get started with single sign-on for header-based applications, you should have already installed an Application Proxy connector and the connector can access the target applications. If not, follow the steps in [Tutorial: Microsoft Entra application proxy](application-proxy-add-on-premises-application.md) then come back here.

+3. In Basic Configuration, **Microsoft Entra ID**, will be selected as the default.

+ Title: Kerberos-based single sign-on (SSO) in Microsoft Entra ID with Application Proxy

+description: Covers how to provide single sign-on using Microsoft Entra application proxy.

+

+2. Application Proxy redirects the request to Microsoft Entra authentication services to preauthenticate. At this point, Microsoft Entra ID applies any applicable authentication and authorization policies, such as multifactor authentication. If the user is validated, Microsoft Entra ID creates a token and sends it to the user.

+1. Publish your application according to the instructions described in [Publish applications with Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md). Make sure to select **Microsoft Entra ID** as the **Preauthentication Method**.

+The Kerberos delegation flow in Microsoft Entra application proxy starts when Microsoft Entra authenticates the user in the cloud. Once the request arrives on-premises, the Microsoft Entra application proxy connector issues a Kerberos ticket on behalf of the user by interacting with the local Active Directory. This process is referred to as Kerberos Constrained Delegation (KCD).

+There are several mechanisms that define how to send the Kerberos ticket in such requests. Most non-Windows servers expect to receive it in form of SPNEGO token. This mechanism is supported on Microsoft Entra application proxy, but is disabled by default. A connector can be configured for SPNEGO or standard Kerberos token, but not both.

+1. Configure Microsoft Entra Connect settings so the main identity is the email address (mail). This is done as part of the customize process, by changing the **User Principal Name** field in the sync settings. These settings also determine how users log in to Office365, Windows10 devices, and other applications that use Microsoft Entra ID as their identity store.

+ Title: No working connector group found for a Microsoft Entra application proxy app

+description: Address problems you might encounter when there is no working Connector in a Connector Group for your application with the Microsoft Entra application proxy

+This article helps to resolve the common issues faced when there is not a connector detected for an Application Proxy application integrated with Microsoft Entra ID.

+For details on each of these options, see the corresponding section below. The instructions assume that you are starting from the Connector management page. If you are looking at the error message above, you can go to this page by clicking on the warning message. You can also get to the page by going to **Microsoft Entra ID**, clicking on **Enterprise Applications**, then **Application Proxy.**

+[Understand Microsoft Entra application proxy connectors](application-proxy-connectors.md)

+description: Covers how to create and manage groups of connectors in Microsoft Entra application proxy.

+Customers utilize Microsoft Entra application proxy for more scenarios and applications. So we've made App Proxy even more flexible by enabling more topologies. You can create Application Proxy connector groups so that you can assign specific connectors to serve specific applications. This capability gives you more control and ways to optimize your Application Proxy deployment.

+

+With Microsoft Entra application proxy connector groups, you can enable a common service to secure the access to all applications without creating additional dependency on your corporate network:

+

+In this case, specific connectors can be deployed per forest, and set to serve applications that were published to serve only the users of that specific forest. Each connector group represents a different forest. While the tenant and most of the experience is unified for all forests, users can be assigned to their forest applications using Microsoft Entra groups.

+* If your DR site is built in active-active mode where it is exactly like the main site and has the same networking and AD settings, you can create the connectors on the DR site in the same connector group as the main site. This enables Microsoft Entra ID to detect failovers for you.

+There are many different ways to implement a model in which a single service provider deploys and maintains Microsoft Entra ID related services for multiple companies. Connector groups help the admin segregate the connectors and applications into different groups. One way, which is suitable for small companies, is to have a single Microsoft Entra tenant while the different companies have their own domain name and networks. This is also true for M&A scenarios and situations where a single IT division serves several companies for regulatory or business reasons.

+

+

+[Understand Microsoft Entra application proxy connectors](application-proxy-connectors.md)

+ Title: Problem installing the Microsoft Entra application proxy Agent Connector

+description: How to troubleshoot issues you might face when installing the Application Proxy Agent Connector for Microsoft Entra ID.

+Microsoft Entra application proxy Connector is an internal domain component that uses outbound connections to establish the connectivity from the cloud available endpoint to the internal domain.

+1. **Connectivity** ΓÇô to complete a successful installation, the new connector needs to register and establish future trust properties. This is done by connecting to the Microsoft Entra application proxy cloud service.

+To learn more about the Register-AppProxyConnector command, please see [Create an unattended installation script for the Microsoft Entra application proxy connector](./application-proxy-register-connector-powershell.md)

+Connect to `https://login.microsoftonline.com` and use the same credentials. Make sure the login is successful. You can check the user role by going to **Microsoft Entra ID** -&gt; **Users and Groups** -&gt; **All Users**.

+[Understand Microsoft Entra application proxy connectors](application-proxy-connectors.md)

+ Title: Understand Microsoft Entra application proxy connectors

+description: Learn about the Microsoft Entra application proxy connectors.

+# Understand Microsoft Entra application proxy connectors

+Connectors are what make Microsoft Entra application proxy possible. They're simple, easy to deploy and maintain, and super powerful. This article discusses what connectors are, how they work, and some suggestions for how to optimize your deployment.

+Connectors are lightweight agents that sit on-premises and facilitate the outbound connection to the Application Proxy service. Connectors must be installed on a Windows Server that has access to the backend application. You can organize connectors into connector groups, with each group handling traffic to specific applications. For more information on Application proxy and a diagrammatic representation of application proxy architecture see [Using Microsoft Entra application proxy to publish on-premises apps for remote users](what-is-application-proxy.md#application-proxy-connectors)

+

+Microsoft Entra ID provides automatic updates for all the connectors that you deploy. As long as the Application Proxy Connector Updater service is running, your connectors [update with the latest major connector release](application-proxy-faq.yml#why-is-my-connector-still-using-an-older-version-and-not-auto-upgraded-to-latest-version-) automatically. If you donΓÇÖt see the Connector Updater service on your server, you need to [reinstall your connector](application-proxy-add-on-premises-application.md) to get any updates.

+For more information about optimizing your network, see [Network topology considerations when using Microsoft Entra application proxy](application-proxy-network-topology.md).

+After the first successful certificate renewal the Microsoft Entra application proxy Connector service (Network Service) has no permission to remove the old certificate from the local machine store. If the certificate has expired or it won't be used by the service anymore, you can delete it safely.

+ 

+- [How to silently install the Microsoft Entra application proxy Connector](./application-proxy-register-connector-powershell.md)

+description: Debug issues with Microsoft Entra application proxy applications.

+This article helps you troubleshoot issues with Microsoft Entra application proxy applications. If you're using the Application Proxy service for remote access to an on-premises web application, but you're having trouble connecting to the application, use this flowchart to debug application issues.

+|6 | Publish all resources, check browser developer tools, and fix links | Make sure the publishing path includes all the necessary images, scripts, and style sheets for your application. For details, see [Add an on-premises app to Microsoft Entra ID](application-proxy-add-on-premises-application.md#add-an-on-premises-app-to-azure-ad). <br></br>Use the browser's developer tools (F12 tools in Internet Explorer or Microsoft Edge) and check for publishing issues as described in [Application page does not display correctly](application-proxy-page-appearance-broken-problem.md). <br></br>Review options for resolving broken links in [Links on the page don't work](application-proxy-page-links-broken-problem.md). |

+* [How to silently install the Microsoft Entra application proxy Connector](application-proxy-register-connector-powershell.md)

+description: Debug issues with Microsoft Entra application proxy connectors.

+This article helps you troubleshoot issues with Microsoft Entra application proxy connectors. If you're using the Application Proxy service for remote access to an on-premises web application, but you're having trouble connecting to the application, use this flowchart to debug connector issues.

+|9 | Lengthen the time-out value on the back end | In the **Additional Settings** for your application, change the **Backend Application Timeout** setting to **Long**. See [Add an on-premises app to Microsoft Entra ID](application-proxy-add-on-premises-application.md#add-an-on-premises-app-to-azure-ad). |

+* [How to silently install the Microsoft Entra application proxy Connector](application-proxy-register-connector-powershell.md)

+ Title: Plan a Microsoft Entra application proxy Deployment

+# Plan a Microsoft Entra application proxy deployment

+Microsoft Entra application proxy is a secure and cost-effective remote access solution for on-premises applications. It provides an immediate transition path for ΓÇ£Cloud FirstΓÇ¥ organizations to manage access to legacy on-premises applications that arenΓÇÖt yet capable of using modern protocols. For additional introductory information, see [What is Application Proxy](./application-proxy.md).

+This article includes the resources you need to plan, operate, and manage Microsoft Entra application proxy.

+* See [Understand Microsoft Entra application proxy Connectors](application-proxy-connectors.md) for a more detailed overview.

+* **Network access settings**: Microsoft Entra application proxy connectors [connect to Azure via HTTPS (TCP Port 443) and HTTP (TCP Port 80)](application-proxy-add-on-premises-application.md).

+<a name='important-considerations-before-configuring-azure-ad-application-proxy'></a>

+### Important considerations before configuring Microsoft Entra application proxy

+The following core requirements must be met in order to configure and implement Microsoft Entra application proxy.

+* **Azure onboarding**: Before deploying application proxy, user identities must be synchronized from an on-premises directory or created directly within your Microsoft Entra tenants. Identity synchronization allows Microsoft Entra ID to pre-authenticate users before granting them access to App Proxy published applications and to have the necessary user identifier information to perform single sign-on (SSO).

+* **Conditional Access requirements**: We do not recommend using Application Proxy for intranet access because this adds latency that will impact users. We recommend using Application Proxy with pre-authentication and Conditional Access policies for remote access from the internet. An approach to provide Conditional Access for intranet use is to modernize applications so they can directly authenticate with Microsoft Entra ID. Refer to [Resources for migrating applications to Microsoft Entra ID](../manage-apps/migration-resources.md) for more information.

+* **Service limits**: To protect against overconsumption of resources by individual tenants there are throttling limits set per application and tenant. To see these limits refer to [Microsoft Entra service limits and restrictions](../enterprise-users/directory-service-limits-restrictions.md). These throttling limits are based on a benchmark far above typical usage volume and provides ample buffer for a majority of deployments.

+* **Public certificate**: If you are using custom domain names, you must procure a TLS/SSL certificate. Depending on your organizational requirements, getting a certificate can take some time and we recommend beginning the process as early as possible. Azure Application Proxy supports standard, [wildcard](application-proxy-wildcard.md), or SAN-based certificates. For more details see [Configure custom domains with Microsoft Entra application proxy](application-proxy-configure-custom-domain.md).

+ * **Connector installation** requires local admin rights to the Windows server that it's being installed on. It also requires a minimum of an *Application Administrator* role to authenticate and register the connector instance to your Microsoft Entra tenant.

+* **Licensing**: Application Proxy is available through a Microsoft Entra ID P1 or P2 subscription. Refer to the [Microsoft Entra pricing page](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing) for a full list of licensing options and features.

+* Remote users with domain-joined or Microsoft Entra joined devices can access published applications securely with seamless single sign-on (SSO).

+Several options exist for managing access to App Proxy published resources, so choose the most appropriate for your given scenario and scalability needs. Common approaches include: using on-premises groups that are being synced via Microsoft Entra Connect, creating Dynamic Groups in Microsoft Entra ID based on user attributes, using self-service groups that are managed by a resource owner, or a combination of all of these. See the linked resources for the benefits of each.

+Guest users can also be [invited to access internal applications published via Application Proxy through Microsoft Entra B2B](../external-identities/add-users-information-worker.md).

+Leaving this option set to No allows users to access the on-premises application via Microsoft Entra application proxy without permissions, so use with caution.

+3. In the **Pre-Authentication** field, use the dropdown list to select **Microsoft Entra ID**, and select **Save**.

+With pre-authentication enabled, Microsoft Entra ID will challenge users first for authentication and if single sign-on is configured then the back-end application will also verify the user before access to the application is granted. Changing the pre-authentication mode from Passthrough to Microsoft Entra ID also configures the external URL with HTTPS, so any application initially configured for HTTP will now be secured with HTTPS.

+SSO provides the best possible user experience and security because users only need to sign in once when accessing Microsoft Entra ID. Once a user has pre-authenticated, SSO is performed by the Application Proxy connector authenticating to the on-premises application, on behalf of the user. The backend application processes the login as if it were the user themselves.

+Choosing the **Passthrough** option allows users to access the published application without ever having to authenticate to Microsoft Entra ID.

+Performing SSO is only possible if Microsoft Entra ID can identify the user requesting access to a resource, so your application must be configured to pre-authenticate users with Microsoft Entra ID upon access for SSO to function, otherwise the SSO options will be disabled.

+Read [Single sign-on to applications in Microsoft Entra ID](../manage-apps/what-is-single-sign-on.md) to help you choose the most appropriate SSO method when configuring your applications.

+Microsoft Entra application proxy can also support applications that have been developed to use the [Microsoft Authentication Library (MSAL)](../develop/v2-overview.md). It supports native client apps by consuming Microsoft Entra ID issued tokens received in the header information of client request to perform pre-authentication on behalf of the users.

+The following capabilities can be used to support Microsoft Entra application proxy:

+* Microsoft Entra My Apps: With your Application Proxy service deployed, and applications securely published, offer your users a simple hub to discover and access all their applications. Increase productivity with self-service capabilities, such as the ability to request access to new apps and groups or manage access to these resources on behalf of others, through [My Apps](https://aka.ms/AccessPanelDPDownload).

+Microsoft advocates the principle of granting the least possible privilege to perform needed tasks with Microsoft Entra ID. [Review the different Azure roles that are available](../roles/permissions-reference.md) and choose the right one to address the needs of each persona. Some roles may need to be applied temporarily and removed after the deployment is completed.

+| Business role| Business tasks| Microsoft Entra roles |

+| Identity admin| Read Microsoft Entra sign-in reports and audit logs to debug App Proxy related issues.| Security reader |

+However, users still need to carry out day to day privileged operations, so enforcing just-in-time (JIT) based [Privileged Identity Management](../privileged-identity-management/pim-configure.md) policies to provide on-demand privileged access to Azure resources and Microsoft Entra ID is our recommended approach towards effectively managing administrative access and auditing.

+Microsoft Entra ID provides additional insights into your organizationΓÇÖs application usage and operational health through [audit logs and reports](../reports-monitoring/concept-provisioning-logs.md?context=azure/active-directory/manage-apps/context/manage-apps-context). Application Proxy also makes it very easy to monitor connectors from the Microsoft Entra admin center and Windows Event Logs.

+The connectors and the service take care of all the high availability tasks. You can monitor the status of your connectors from the Application Proxy page in the Microsoft Entra admin center. For more information about connector maintenance see [Understand Microsoft Entra application proxy Connectors](./application-proxy-connectors.md#maintenance).

+

+Connectors have both admin and session logs. The admin logs include key events and their errors. The session logs include all the transactions and their processing details. Logs and counters are located in Windows Event Logs for more information see [Understand Microsoft Entra application proxy Connectors](./application-proxy-connectors.md#under-the-hood). Follow this [tutorial to configure event log data sources in Azure Monitor](../../azure-monitor/agents/data-sources-windows-events.md).

+ Title: High availability and load balancing - Microsoft Entra application proxy

+Another key area where high availability is a factor is the connection between connectors and the back-end servers. When an application is published through Microsoft Entra application proxy, traffic from the users to the applications flows through three hops:

+1. The user connects to the Microsoft Entra application proxy service public endpoint on Azure. The connection is established between the originating client IP address (public) of the client and the IP address of the Application Proxy endpoint.

+In some situations (like auditing, load balancing etc.), sharing the originating IP address of the external client with the on-premises environment is a requirement. To address the requirement, Microsoft Entra application proxy connector adds the X-Forwarded-For header field with the originating client IP address (public) to the HTTP request. The appropriate network device (load balancer, firewall) or the web server or back-end application can then read and use the information.

+- [Learn how Microsoft Entra architecture supports high availability](../architecture/architecture.md)

+ Title: Securely integrate Azure Logic Apps with on-premises APIs using Microsoft Entra application proxy

+description: Microsoft Entra application proxy lets cloud-native logic apps securely access on-premises APIs to bridge your workload.

+# Securely integrate Azure Logic Apps with on-premises APIs using Microsoft Entra application proxy

+This article describes the steps necessary to utilize the Microsoft Entra application proxy solution to provide secure access to a Logic App, while protecting the internal application from unwanted actors. The process and end result is similar to [Access on-premises APIs with Microsoft Entra application proxy](./application-proxy-secure-api-access.md) with special attention paid to utilizing the API from within a Logic App.

+The following diagram shows how you can use Microsoft Entra application proxy to securely publish APIs for use with Logic Apps (or other Azure Cloud services) without opening any incoming ports:

+The Microsoft Entra application proxy and associated connector facilitate secure authorization and integration to your on-premises services without additional configuration to your network security infrastructure.

+- Azure Application Proxy connector deployed and an application configured as detailed in [Add an on-premises app - Application Proxy in Microsoft Entra ID](./application-proxy-add-on-premises-application.md)

+ 

+ 

+ 

+ 

+ 

+ 2. *URI*: Fill in with the *public* FQDN of your application registered in Microsoft Entra ID, along with the additional URI required for API access (e.g. *sampleapp1.msappproxy.net/api/1/status*)

+ 3. *Audience*: Enter the *public* FQDN of your application registered in Microsoft Entra ID (e.g. *sampleapp1.msappproxy.net*)

+- APIs that require authentication/authorization require special handling when using this method. Since Microsoft Entra ID OAuth is being used for access, the requests sent already contain an *Authorization* field that cannot also be utilized by the internal API (unless SSO is configured). As a workaround, some applications offer authentication or authorization that uses methods other than an *Authorization* header. For example, GitLab allows for a header titled *PRIVATE-TOKEN*, and Atlassian JIRA allows for requesting a Cookie that can be used in later requests

+- [Access on-premises APIs with Microsoft Entra application proxy](./application-proxy-secure-api-access.md)

+- [Common scenarios, examples, tutorials, and walkthroughs for Azure Logic Apps](../../logic-apps/logic-apps-examples-and-scenarios.md)

+description: Configure an on-premises application in Microsoft Entra ID to work with Microsoft Defender for Cloud Apps. Use the Defender for Cloud Apps Conditional Access App Control to monitor and control sessions in real-time based on Conditional Access policies. You can apply these policies to on-premises applications that use Application Proxy in Microsoft Entra ID.

+# Configure real-time application access monitoring with Microsoft Defender for Cloud Apps and Microsoft Entra ID

+Configure an on-premises application in Microsoft Entra ID to use Microsoft Defender for Cloud Apps for real-time monitoring. Defender for Cloud Apps uses Conditional Access App Control to monitor and control sessions in real-time based on Conditional Access policies. You can apply these policies to on-premises applications that use Application Proxy in Microsoft Entra ID.

+- Microsoft Entra ID P1 and Defender for Cloud Apps Standalone.

+- Configure Microsoft Entra ID to use Application Proxy, including preparing your environment and installing the Application Proxy connector. For a tutorial, see [Add an on-premises applications for remote access through Application Proxy in Microsoft Entra ID](../app-proxy/application-proxy-add-on-premises-application.md).

+<a name='add-on-premises-application-to-azure-ad'></a>

+## Add on-premises application to Microsoft Entra ID

+Add an on-premises application to Microsoft Entra ID. For a quickstart, see [Add an on-premises app to Microsoft Entra ID](../app-proxy/application-proxy-add-on-premises-application.md#add-an-on-premises-app-to-azure-ad). When adding the application, be sure to set the following two settings in the **Add your on-premises application** blade:

+- **Pre Authentication**: Enter **Microsoft Entra ID**.

+After adding your application to Microsoft Entra ID, use the steps in [Test the application](../app-proxy/application-proxy-add-on-premises-application.md#test-the-application) to add a user for testing, and test the sign-on.

+To configure your application with the Conditional Access Application Control, follow the instructions in [Deploy Conditional Access Application Control for Microsoft Entra apps](/cloud-app-security/proxy-deployment-aad).

+To test the deployment of Microsoft Entra applications with Conditional Access Application Control, follow the instructions in [Test the deployment for Microsoft Entra apps](/cloud-app-security/proxy-deployment-aad).

+ Title: Enable remote access to Power BI with Microsoft Entra application proxy

+description: Covers the basics about how to integrate an on-premises Power BI with Microsoft Entra application proxy.

+# Enable remote access to Power BI Mobile with Microsoft Entra application proxy

+This article discusses how to use Microsoft Entra application proxy to enable the Power BI mobile app to connect to Power BI Report Server (PBIRS) and SQL Server Reporting Services (SSRS) 2016 and later. Through this integration, users who are away from the corporate network can access their Power BI reports from the Power BI mobile app and be protected by Microsoft Entra authentication. This protection includes [security benefits](application-proxy-security.md#security-benefits) such as Conditional Access and multi-factor authentication.

+- Enabling Application Proxy requires installing a connector on a Windows server and completing the [prerequisites](../app-proxy/application-proxy-add-on-premises-application.md#prepare-your-on-premises-environment) so that the connector can communicate with Microsoft Entra services.

+Configure KCD so that the Microsoft Entra application proxy service can delegate user identities to the Reporting Services application pool account. Configure KCD by enabling the Application Proxy connector to retrieve Kerberos tickets for your users who have been authenticated in Microsoft Entra ID. Then that server passes the context to the target application, or Reporting Services in this case.

+<a name='step-2-publish-report-services-through-azure-ad-application-proxy'></a>

+## Step 2: Publish Report Services through Microsoft Entra application proxy

+Now you're ready to configure Microsoft Entra application proxy.

+1. Publish Report Services through Application Proxy with the following settings. For step-by-step instructions on how to publish an application through Application Proxy, see [Publishing applications using Microsoft Entra application proxy](../app-proxy/application-proxy-add-on-premises-application.md#add-an-on-premises-app-to-azure-ad).

+ - **External URL**: Enter the public URL the Power BI mobile app will connect to. For example, it may look like `https://reports.contoso.com` if a custom domain is used. To use a custom domain, upload a certificate for the domain, and point a DNS record to the default msappproxy.net domain for your application. For detailed steps, see [Working with custom domains in Microsoft Entra application proxy](application-proxy-configure-custom-domain.md).

+ - **Pre-authentication Method**: Microsoft Entra ID

+1. On the Microsoft Entra ID **Overview** page, select **App registrations**.

+2. Select **Connect**. You'll be directed to the Microsoft Entra sign-in page.

+Using Microsoft Entra application proxy to enable the Power BI mobile app to connect to on premises Power BI Report Server is not supported with Conditional Access policies that require the Microsoft Power BI app as an approved client app.

+ Title: Publish Remote Desktop with Microsoft Entra application proxy

+# Publish Remote Desktop with Microsoft Entra application proxy

+Remote Desktop Service and Microsoft Entra application proxy work together to improve the productivity of workers who are away from the corporate network.

+- Current Remote Desktop Services customers who want to reduce the attack surface of their deployment by using Microsoft Entra application proxy. This scenario gives a set of two-step verification and Conditional Access controls to RDS.

+A standard RDS deployment includes various Remote Desktop role services running on Windows Server. Looking at the [Remote Desktop Services architecture](/windows-server/remote/remote-desktop-services/Desktop-hosting-logical-architecture), there are multiple deployment options. Unlike other RDS deployment options, the [RDS deployment with Microsoft Entra application proxy](/windows-server/remote/remote-desktop-services/Desktop-hosting-logical-architecture) (shown in the following diagram) has a permanent outbound connection from the server running the connector service. Other deployments leave open inbound connections through a load balancer.

+- RD Gateway comes into the picture once a user launches the RDP connection. The RD Gateway handles encrypted RDP traffic coming over the internet and translates it to the on-premises server that the user is connecting to. In this scenario, the traffic the RD Gateway is receiving comes from the Microsoft Entra application proxy.

+- You should already have [deployed RDS](/windows-server/remote/remote-desktop-services/rds-in-azure), and [enabled Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md). Ensure you have satisfied the pre-requisites to enable Application Proxy, such as installing the connector, opening required ports and URLs, and enabling TLS 1.2 on the server. To learn which ports need to be opened, and other details, see [Tutorial: Add an on-premises application for remote access through Application Proxy in Microsoft Entra ID](application-proxy-add-on-premises-application.md).

+- For the Microsoft Entra pre-authentication flow, users can only connect to resources published to them in the **RemoteApp and Desktops** pane. Users can't connect to a desktop using the **Connect to a remote PC** pane.

+- If you are using Windows Server 2019, you may need to disable HTTP2 protocol. For more information, see [Tutorial: Add an on-premises application for remote access through Application Proxy in Microsoft Entra ID](../app-proxy/application-proxy-add-on-premises-application.md).

+After setting up RDS and Microsoft Entra application proxy for your environment, follow the steps to combine the two solutions. These steps walk through publishing the two web-facing RDS endpoints (RD Web and RD Gateway) as applications, and then directing traffic on your RDS to go through Application Proxy.

+ - Preauthentication method: Microsoft Entra ID

+3. Leave the single sign-on method for the application as **Microsoft Entra single sign-on disabled**.

+ >Your users are asked to authenticate once to Microsoft Entra ID and once to RD Web, but they have single sign-on to RD Gateway.

+Connect to the RDS deployment as an administrator and change the RD Gateway server name for the deployment. This configuration ensures that connections go through the Microsoft Entra application proxy service.

+Now that you've configured Remote Desktop, Microsoft Entra application proxy has taken over as the internet-facing component of RDS. You can remove the other public internet-facing endpoints on your RD Web and RD Gateway machines.

+2. You are asked to authenticate to Microsoft Entra ID. Use an account that you assigned to the application.

+The pre-authentication flow offers more security benefits than the passthrough flow. With pre-authentication you can use Microsoft Entra authentication features like single sign-on, Conditional Access, and two-step verification for your on-premises resources. You also ensure that only authenticated traffic reaches your network.

+- [Enable remote access to SharePoint with Microsoft Entra application proxy](application-proxy-integrate-with-sharepoint-server.md)

+- [Security considerations for accessing apps remotely by using Microsoft Entra application proxy](application-proxy-security.md)

+ Title: Publish an on-premises SharePoint farm with Microsoft Entra application proxy

+description: Covers the basics about how to integrate an on-premises SharePoint farm with Microsoft Entra application proxy for SAML.

+# Integrate Microsoft Entra application proxy with SharePoint (SAML)

+This step-by-step guide explains how to secure the access to the [Microsoft Entra integrated on-premises SharePoint (SAML)](../saas-apps/sharepoint-on-premises-tutorial.md) using Microsoft Entra application proxy, where users in your organization (Microsoft Entra ID, B2B) connect to SharePoint through the Internet.

+> If you're new to Microsoft Entra application proxy and want to learn more, see [Remote access to on-premises applications through Microsoft Entra application proxy](./application-proxy.md).

+- Microsoft Entra application proxy ensures that authenticated traffic can reach your internal network and SharePoint.

+- You can control the access by user assignment on the Microsoft Entra application proxy level and you can increase the security with Microsoft Entra features like Conditional Access and Multi-Factor Authentication (MFA).

+ - A SharePoint 2013 farm or newer. The SharePoint farm must be [integrated with Microsoft Entra ID](../saas-apps/sharepoint-on-premises-tutorial.md).

+ - A Microsoft Entra tenant with a plan that includes Application Proxy. Learn more about [Microsoft Entra ID plans and pricing](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing).

+ - A [custom, verified domain](../fundamentals/add-custom-domain.md) in the Microsoft Entra tenant. The verified domain must match the SharePoint URL suffix.

+ - On-premises Active Directory users must be synchronized with Microsoft Entra Connect, and must be configure to [sign in to Azure](../hybrid/connect/plan-connect-user-signin.md).

+<a name='step-1-integrate-sharepoint-on-premises-with-azure-ad'></a>

+## Step 1: Integrate SharePoint on-premises with Microsoft Entra ID

+1. Configure the SharePoint on-premises app. For more information, see [Tutorial: Microsoft Entra single sign-on integration with SharePoint on-premises](../saas-apps/sharepoint-on-premises-tutorial.md).

+In this step, you create an application in your Microsoft Entra tenant that uses Application Proxy. You set the external URL and specify the internal URL, both of which are used later in SharePoint.

+ 1. Create a new Microsoft Entra application proxy application with custom domain. For step-by-step instructions, see [Custom domains in Microsoft Entra application proxy](./application-proxy-configure-custom-domain.md).

+ - Pre-Authentication: Microsoft Entra ID

+ Title: Enable remote access to SharePoint - Microsoft Entra application proxy

+description: Covers the basics about how to integrate on-premises SharePoint Server with Microsoft Entra application proxy.

+# Enable remote access to SharePoint with Microsoft Entra application proxy

+This step-by-step guide explains how to integrate an on-premises SharePoint farm with Microsoft Entra application proxy.

+- A Microsoft Entra tenant with a plan that includes Application Proxy. Learn more about [Microsoft Entra ID plans and pricing](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing).

+- A [custom, verified domain](../fundamentals/add-custom-domain.md) in the Microsoft Entra tenant.

+- On-premises Active Directory synchronized with Microsoft Entra Connect, through which users can [sign in to Azure](../hybrid/connect/plan-connect-user-signin.md).

+- An external URL, visible to end-users and determined in Microsoft Entra ID. This URL can use a custom domain. Learn more about [working with custom domains in Microsoft Entra application proxy](application-proxy-configure-custom-domain.md).

+<a name='step-1-configure-an-application-in-azure-ad-that-uses-application-proxy'></a>

+## Step 1: Configure an application in Microsoft Entra ID that uses Application Proxy

+In this step, you create an application in your Microsoft Entra tenant that uses Application Proxy. You set the external URL and specify the internal URL, both of which are used later in SharePoint.

+1. Create the app as described with the following settings. For step-by-step instructions, see [Publishing applications using Microsoft Entra application proxy](../app-proxy/application-proxy-add-on-premises-application.md#add-an-on-premises-app-to-azure-ad).

+ * **Pre-Authentication**: Microsoft Entra ID

+The SharePoint web application must be configured with Kerberos and the appropriate alternate access mappings to work correctly with Microsoft Entra application proxy. There are two possible options:

+1. Expand the server in the tree view, expand **Sites**, select the **SharePoint - Microsoft Entra ID Proxy** site, and select **Bindings**.

+You can now access the SharePoint site externally through Microsoft Entra application proxy.

+Users will initially authenticate in Microsoft Entra ID and then to SharePoint by using Kerberos through the Microsoft Entra ID Proxy connector. To allow the connector to obtain a Kerberos token on behalf of the Microsoft Entra user, you must configure Kerberos Constrained Delegation (KCD) with protocol transition. To learn more about KCD, see [Kerberos Constrained Delegation overview](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj553400(v=ws.11)).

+Configure the KCD so that the Microsoft Entra application proxy service can delegate user identities to the SharePoint application pool account. Configure KCD by enabling the Application Proxy connector to retrieve Kerberos tickets for your users who have been authenticated in Microsoft Entra ID. Then, that server passes the context to the target application (SharePoint in this case).

+1. Find the computer running the Microsoft Entra ID Proxy connector. In this example, it's the computer that's running SharePoint Server.

+* [Working with custom domains in Microsoft Entra application proxy](application-proxy-configure-custom-domain.md)

+* [Understand Microsoft Entra application proxy connectors](application-proxy-connectors.md)

+ Title: Microsoft Entra application proxy and Tableau

+description: Learn how to use Microsoft Entra application proxy to provide remote access for your Tableau deployment.

+# Microsoft Entra application proxy and Tableau

+Microsoft Entra application proxy and Tableau have partnered to ensure you are easily able to use Application Proxy to provide remote access for your Tableau deployment. This article explains how to configure this scenario.

+- Detailed instructions of steps 1-8, see [Publish applications using Microsoft Entra application proxy](../app-proxy/application-proxy-add-on-premises-application.md).

+ - **Pre-authentication method**: Microsoft Entra ID (recommended but not required).

+For more information about Microsoft Entra application proxy, see [How to provide secure remote access to on-premises applications](application-proxy.md).

+ Title: Access Microsoft Entra application proxy apps in Teams

+description: Use Microsoft Entra application proxy to access your on-premises application through Microsoft Teams.

+# Access your on-premises applications through Microsoft Teams with Microsoft Entra application proxy

+Microsoft Entra application proxy gives you single sign-on to on-premises applications no matter where you are. Microsoft Teams streamlines your collaborative efforts in one place. Integrating the two together means that your users can be productive with their teammates in any situation.

+Your users can add cloud apps to their Teams channels [using tabs](https://support.office.com/article/Video-Using-Tabs-7350a03e-017a-4a00-a6ae-1c9fe8c497b3?ui=en-US&rs=en-US&ad=US), but what about the SharePoint sites or planning tool that are hosted on-premises? Application Proxy is the solution. They can add apps published through Application Proxy to their channels using the same external URLs they always use to access their apps remotely. And because Application Proxy authenticates through Microsoft Entra ID, your users get a single sign-on experience.

+If you already have your apps published but don't remember their external URLs, look them up in the [Microsoft Entra admin center](https://portal.azure.com). Sign in, then navigate to **Microsoft Entra ID** > **Enterprise applications** > **All applications** > select your app > **Application proxy**.

+This article explains how to configure Microsoft Entra application proxy to work with Traffic Manager. With the Application Proxy geo-routing feature, you can optimize which region of the Application Proxy service your connector groups use. You can now combine this functionality with a Traffic Manager solution of your choice. This combination enables a fully dynamic geo-aware solution based on your user location. It unlocks the rich rule set of your preferred Traffic Manager to prioritize how traffic is routed to your apps protected by Application Proxy. With this combination, users can use a single URL to access the instance of the app closest to them.

+ Title: Network topology considerations for Microsoft Entra application proxy

+description: Covers network topology considerations when using Microsoft Entra application proxy.

+# Optimize traffic flow with Microsoft Entra application proxy

+This article explains how to optimize traffic flow and network topology considerations when using Microsoft Entra application proxy for publishing and accessing your applications remotely.

+When an application is published through Microsoft Entra application proxy, traffic from the users to the applications flows through three connections:

+1. The user connects to the Microsoft Entra application proxy service public endpoint on Azure

+When you sign up for a Microsoft Entra tenant, the region of your tenant is determined by the country/region you specify. When you enable Application Proxy, the **default** Application Proxy cloud service instances for your tenant are chosen in the same region as your Microsoft Entra tenant, or the closest region to it.

+For example, if your Microsoft Entra tenant's country or region is the United Kingdom, all your Application Proxy connectors at **default** will be assigned to use service instances in European data centers. When your users access published applications, their traffic goes through the Application Proxy cloud service instances in this location.

+Organizations typically include server endpoints in their perimeter network. With Microsoft Entra application proxy, however, traffic flows through the proxy service in the cloud while the connectors reside on your corporate network. No perimeter network is required.

+Latency is not compromised because traffic is flowing over a dedicated connection. You also get improved Application Proxy service-to-connector latency because the connector is installed in an Azure datacenter close to your Microsoft Entra tenant location.

+Increasingly, organizations are moving their networks into hosted environments. This enables them to place their apps in a hosted environment that is also part of their corporate network, and still be within the domain. In this case, the patterns discussed in the preceding sections can be applied to the new application location. If you're considering this option, see [Microsoft Entra Domain Services](../../active-directory-domain-services/overview.md).

+In this section, we walk through a few common scenarios. Assume that the Microsoft Entra tenant (and therefore proxy service endpoint) is located in the United States (US). The considerations discussed in these use cases also apply to other regions around the globe.

+description: Guidance when the page isnΓÇÖt displaying correctly in an Application Proxy Application you have integrated with Microsoft Entra ID

+This article helps you troubleshoot issues with Microsoft Entra application proxy applications when you navigate to the page, but something on the page doesn't look correct.

+[Publish applications using Microsoft Entra application proxy](../app-proxy/application-proxy-add-on-premises-application.md)

+ Title: Links on the page don't work for a Microsoft Entra application proxy application

+description: How to troubleshoot issues with broken links on Application Proxy applications you have integrated with Microsoft Entra ID

+This article helps you troubleshoot why links on your Microsoft Entra application proxy application don't work correctly.

+ If you change the internal URL but donΓÇÖt want to change the landing page for users, change the Home page URL to the previously published internal URL. This can be done by going to ΓÇ£Microsoft Entra IDΓÇ¥ -&gt; App Registrations -&gt; select the application -&gt; Branding. In the branding section, you see the field ΓÇ£Home Page URLΓÇ¥, which you can adjust to be the desired landing page. If you are still using the legacy App registrations experience the properties tab would show the "Home Page URL" details.

+ > In order to make the above changes you require rights to modify application objects in Azure AD.The user needs to be assigned [Application Administrator](../roles/delegate-app-roles.md#assign-built-in-application-admin-roles) role which grants application modificaion rights in Microsoft Entra ID to the user.

+3. If neither of these options are feasible, there are multiple options for enabling inline link translation. These options include using the Intune Managed Browser, My Apps extension, or using the link translation setting on your application. To learn more about each of these options and how to enable them, see [Redirect hardcoded links for apps published with Microsoft Entra application proxy](application-proxy-configure-hard-coded-link-translation.md).

+ Title: A Microsoft Entra application proxy application takes too long to load

+description: Troubleshoot page load performance issues with Microsoft Entra application proxy

+This article helps you to understand why a Microsoft Entra application proxy application may take a long time to load. It also explains what you can do to resolve this issue.

+ Title: Header-based authentication with PingAccess for Microsoft Entra application proxy

+Microsoft Entra application proxy has partnered with PingAccess so that your Microsoft Entra customers can access more of your applications. PingAccess provides another option beyond integrated [header-based single sign-on](application-proxy-configure-single-sign-on-with-headers.md).

+<a name='whats-pingaccess-for-azure-ad'></a>

+## What's PingAccess for Microsoft Entra ID?

+With PingAccess for Microsoft Entra ID, you can give users access and single sign-on (SSO) to applications that use headers for authentication. Application Proxy treats these applications like any other, using Microsoft Entra ID to authenticate access and then passing traffic through the connector service. PingAccess sits in front of the applications and translates the access token from Microsoft Entra ID into a header. The application then receives the authentication in the format it can read.

+Since this scenario comes from a partnership between Microsoft Entra ID and PingAccess, you need licenses for both services. However, Microsoft Entra ID P1 or P2 subscriptions include a basic PingAccess license that covers up to 20 applications. If you need to publish more than 20 header-based applications, you can purchase an additional license from PingAccess.

+For more information, see [Microsoft Entra editions](../fundamentals/whatis.md).

+This article is for people to publish an application with this scenario for the first time. Besides detailing the publishing steps, it guides you in getting started with both Application Proxy and PingAccess. If you've already configured both services but want a refresher on the publishing steps, skip to the [Add your application to Microsoft Entra ID with Application Proxy](#add-your-application-to-azure-ad-with-application-proxy) section.

+> Since this scenario is a partnership between Microsoft Entra ID and PingAccess, some of the instructions exist on the Ping Identity site.

+If you've enabled Application Proxy and installed a connector already, you can skip this section and go to [Add your application to Microsoft Entra ID with Application Proxy](#add-your-application-to-azure-ad-with-application-proxy).

+The Application Proxy connector is a Windows Server service that directs the traffic from your remote employees to your published applications. For more detailed installation instructions, see [Tutorial: Add an on-premises application for remote access through Application Proxy in Microsoft Entra ID](../app-proxy/application-proxy-add-on-premises-application.md).

+<a name='add-your-application-to-azure-ad-with-application-proxy'></a>

+### Add your application to Microsoft Entra ID with Application Proxy

+- Adding your on-premises application to Microsoft Entra ID

+ > For a more detailed walkthrough of this step, see [Add an on-premises app to Microsoft Entra ID](../app-proxy/application-proxy-add-on-premises-application.md#add-an-on-premises-app-to-azure-ad).

+ 1. **Pre-authentication method**: Choose **Microsoft Entra ID**.

+In addition to the external URL, an authorize endpoint of Microsoft Entra ID on the external URL should be added to the Redirect URIs list.

+| Name of Microsoft Entra ID field | Name of PingAccess field | Data format |

+You can configure optional claims for your application by modifying the application manifest. For more info, see the [Understanding the Microsoft Entra application manifest article](../develop/reference-app-manifest.md)

+[Claims Mapping Policy (preview)](../develop/reference-claims-mapping-policy-type.md#claims-mapping-policy-properties) for attributes which do not exist in Microsoft Entra ID. Claims mapping allows you to migrate old on-prem apps to the cloud by adding additional custom claims that are backed by your ADFS or user objects

+Now that you've completed all the Microsoft Entra setup steps, you can move on to configuring PingAccess.

+The detailed steps for the PingAccess part of this scenario continue in the Ping Identity documentation. Follow the instructions in [Configuring PingAccess for Microsoft Entra ID](https://docs.pingidentity.com/access/sources/dita/topic?category=pingaccess&Releasestatus_ce=Current&resourceid=pa_configuring_apps_for_azure) on the Ping Identity web site and download the [latest version of PingAccess](https://www.pingidentity.com/en/lp/azure-download.html).

+Those steps help you install PingAccess and set up a PingAccess account (if you don't already have one). Then, to create a Microsoft Entra ID OpenID Connect (OIDC) connection, you set up a token provider with the **Directory (tenant) ID** value that you copied from the Microsoft Entra admin center. Next, to create a web session on PingAccess, you use the **Application (client) ID** and `PingAccess key` values. After that, you can set up identity mapping and create a virtual host, site, and application.

+- [Configuring PingAccess to use Microsoft Entra ID as the token provider](https://docs.pingidentity.com/access/sources/dita/topic?category=pingaccess&Releasestatus_ce=Current&resourceid=pa_configure_pa_to_use_azure_ad_as_the_token_provider)

+- [Single sign-on to applications in Microsoft Entra ID](../manage-apps/what-is-single-sign-on.md)

+ Title: PowerShell samples for Microsoft Entra application proxy

+description: Use these PowerShell samples for Microsoft Entra application proxy to get information about Application Proxy apps and connectors in your directory, assign users and groups to apps, and get certificate information.

+# Microsoft Entra application proxy PowerShell examples

+The following table includes links to PowerShell script examples for Microsoft Entra application proxy. These samples require either the [Microsoft Entra V2 PowerShell for Graph module](/powershell/azure/active-directory/install-adv2) or the [Microsoft Entra V2 PowerShell for Graph module preview version](/powershell/azure/active-directory/install-adv2?view=azureadps-2.0-preview&preserve-view=true), unless otherwise noted.

+| [Get all Application Proxy apps with a token lifetime policy](scripts/powershell-get-all-app-proxy-apps-with-policy.md) | Lists all Application Proxy apps in your directory with a token lifetime policy and its details. This sample requires the [Microsoft Entra V2 PowerShell for Graph module preview version](/powershell/azure/active-directory/install-adv2?view=azureadps-2.0-preview&preserve-view=true). |

+| [Get all Microsoft Entra ID Proxy application apps published with no certificate uploaded](scripts/powershell-get-all-custom-domain-no-cert.md) | Lists all Application Proxy apps that are using custom domains but don't have a valid TLS/SSL certificate uploaded. |

+| [Get all Microsoft Entra ID Proxy application apps published with the identical certificate](scripts/powershell-get-custom-domain-identical-cert.md) | Lists all the Microsoft Entra ID Proxy application apps published with the identical certificate. |

+| [Get all Microsoft Entra ID Proxy application apps published with the identical certificate and replace it](scripts/powershell-get-custom-domain-replace-cert.md) | For Microsoft Entra ID Proxy application apps that are published with an identical certificate, allows you to replace the certificate in bulk. |

+ Title: Microsoft Entra application proxy and Qlik Sense

+description: Integrate Microsoft Entra application proxy with Qlik Sense.

+# Microsoft Entra application proxy and Qlik Sense

+Microsoft Entra application proxy and Qlik Sense have partnered together to ensure you are easily able to use Application Proxy to provide remote access for your Qlik Sense deployment.

+Follow these steps to publish your app. For a more detailed walkthrough of steps 1-8, see [Publish applications using Microsoft Entra application proxy](../app-proxy/application-proxy-add-on-premises-application.md).

+ - **Pre-authentication method**: Microsoft Entra ID (Recommended but not required)

+- [Microsoft Entra ID with integrated Windows authentication using a Kerberos Constrained Delegation with Qlik Sense](https://community.qlik.com/docs/DOC-20183)

+- [Qlik Sense integration with Microsoft Entra application proxy](https://community.qlik.com/t5/Technology-Partners-Ecosystem/Azure-AD-Application-Proxy/ta-p/1528396)

+ Title: Silent install Microsoft Entra application proxy connector

+description: Covers how to perform an unattended installation of Microsoft Entra application proxy Connector to provide secure remote access to your on-premises apps.

+# Create an unattended installation script for the Microsoft Entra application proxy connector

+This topic helps you create a Windows PowerShell script that enables unattended installation and registration for your Microsoft Entra application proxy connector.

+For the [Application Proxy connector](application-proxy-connectors.md) to work, it has to be registered with your Microsoft Entra directory using an application administrator and password. Ordinarily this information is entered during Connector installation in a pop-up dialog box, but you can use PowerShell to automate this process instead.

+There are two steps for an unattended installation. First, install the connector. Second, register the connector with Microsoft Entra ID.

+<a name='register-the-connector-with-azure-ad'></a>

+## Register the connector with Microsoft Entra ID

+2. Go to **C:\Program Files\Microsoft Azure AD App Proxy Connector** and run the following script using the `$cred` object that you created:

+ Title: 'Microsoft Entra application proxy: Version release history'

+description: This article lists all releases of Microsoft Entra application proxy and describes new features and fixed issues.

+# Microsoft Entra application proxy: Version release history

+This article lists the versions and features of Microsoft Entra application proxy that have been released. The Microsoft Entra ID team regularly updates Application Proxy with new features and functionality. Application Proxy connectors are [updated automatically when a new major version is released](application-proxy-faq.yml#why-is-my-connector-still-using-an-older-version-and-not-auto-upgraded-to-latest-version-).

+| Understand Microsoft Entra application proxy connectors | Find out more about [connector management](application-proxy-connectors.md) and how connectors [auto-upgrade](application-proxy-connectors.md#automatic-updates). |

+| Microsoft Entra application proxy Connector Download | [Download the latest connector](https://download.msappproxy.net/subscription/d3c8b69d-6bf7-42be-a529-3fe9c2e70c90/connector/download). |

+- Silent registration of connector with credentials. See [Create an unattended installation script for the Microsoft Entra application proxy connector](application-proxy-register-connector-powershell.md) for more details.

+- Support for using the Remote Desktop Services web client with Application Proxy. See [Publish Remote Desktop with Microsoft Entra application proxy](application-proxy-integrate-with-remote-desktop-services.md) for more details.

+- Support for optimized routing between connector groups and Application Proxy cloud services based on region. See [Optimize traffic flow with Microsoft Entra application proxy](application-proxy-network-topology.md) for more details.

+- Learn more about [Remote access to on-premises applications through Microsoft Entra application proxy](application-proxy.md).

+ Title: Remove personal data - Microsoft Entra application proxy

+description: Remove personal data from connectors installed on devices for Microsoft Entra application proxy.

+# Remove personal data for Microsoft Entra application proxy

+Microsoft Entra application proxy requires that you install connectors on your devices, which means that there might be personal data on your devices. This article provides steps for how to delete that personal data to improve privacy.

+1. Restart the Microsoft Entra application proxy Connector service to generate a new log file. The new log file enables you to delete or modify the old log files.

+For an overview of Application Proxy, see [How to provide secure remote access to on-premises applications](application-proxy.md).

+ Title: Access on-premises APIs with Microsoft Entra application proxy

+description: Microsoft Entra application proxy lets native apps securely access APIs and business logic you host on-premises or on cloud VMs.

+# Secure access to on-premises APIs with Microsoft Entra application proxy

+You may have business logic APIs running on-premises, or hosted on virtual machines in the cloud. Your native Android, iOS, Mac, or Windows apps need to interact with the API endpoints to use data or provide user interaction. Microsoft Entra application proxy and the [Microsoft Authentication Library (MSAL)](../develop/reference-v2-libraries.md) let your native apps securely access your on-premises APIs. Microsoft Entra application proxy is a faster and more secure solution than opening firewall ports and controlling authentication and authorization at the app layer.

+This article walks you through setting up a Microsoft Entra application proxy solution for hosting a web API service that native apps can access.

+The following diagram shows how you can use Microsoft Entra application proxy to securely publish APIs without opening any incoming ports:

+

+The Microsoft Entra application proxy forms the backbone of the solution, working as a public endpoint for API access, and providing authentication and authorization. You can access your APIs from a vast array of platforms by using the [Microsoft Authentication Library (MSAL)](../develop/reference-v2-libraries.md) libraries.

+Since Microsoft Entra application proxy authentication and authorization are built on top of Microsoft Entra ID, you can use Microsoft Entra Conditional Access to ensure only trusted devices can access APIs published through Application Proxy. Use Microsoft Entra join or Microsoft Entra hybrid joined for desktops, and Intune Managed for devices. You can also take advantage of Microsoft Entra ID P1 or P2 features like Microsoft Entra multifactor authentication, and the machine learning-backed security of [Azure Identity Protection](../identity-protection/overview-identity-protection.md).

+To publish an API outside of your intranet through Application Proxy, you follow the same pattern as for publishing web apps. For more information, see [Tutorial: Add an on-premises application for remote access through Application Proxy in Microsoft Entra ID](application-proxy-add-on-premises-application.md).

+1. On the **Browse Microsoft Entra Gallery** page, locate section **On-premises applications** and select **Add an on-premises application**. The **Add your own on-premises application** page appears.

+ 1. Make sure **Pre-Authentication** is set to **Microsoft Entra ID**.

+You've published your web API through Microsoft Entra application proxy. Now, add users who can access the app.

+Native apps are programs developed to use on a particular platform or device. Before your native app can connect and access an API, you must register it in Microsoft Entra ID. The following steps show how to register a native app and give it access to the web API you published through Application Proxy.

+You've now registered the AppProxyNativeAppSample app in Microsoft Entra ID. To give your native app access to the SecretAPI web API:

+To configure the native app to connect to Microsoft Entra ID and call the API App Proxy, update the placeholder values in the *App.config* file of the NativeClient sample app with values from Microsoft Entra ID:

+- [Tutorial: Add an on-premises application for remote access through Application Proxy in Microsoft Entra ID](application-proxy-add-on-premises-application.md)

+ Title: Security considerations for Microsoft Entra application proxy

+description: Covers security considerations for using Microsoft Entra application proxy

+# Security considerations for accessing apps remotely with Microsoft Entra application proxy

+This article explains the components that work to keep your users and applications safe when you use Microsoft Entra application proxy.

+The following diagram shows how Microsoft Entra ID enables secure remote access to your on-premises applications.

+ 

+Microsoft Entra application proxy offers many security benefits including authenticated access, Conditional Access, traffic termination, all outbound access, cloud scale analytics and machine learning, and remote access as a service. It is important to note that even with all of the added security provided by Application Proxy, the systems being accessed must continually be updated with the latest patches.

+If you choose to use Microsoft Entra preauthentication, then only authenticated connections can access your network.

+Microsoft Entra application proxy relies on the Microsoft Entra security token service (STS) for all authentication. Preauthentication, by its very nature, blocks a significant number of anonymous attacks, because only authenticated identities can access the back-end application.

+You can also use Conditional Access to configure Multi-Factor Authentication policies, adding another layer of security to your user authentications. Additionally, your applications can also be routed to Microsoft Defender for Cloud Apps via Microsoft Entra Conditional Access to provide real-time monitoring and controls, via [access](/cloud-app-security/access-policy-aad) and [session](/cloud-app-security/session-policy-aad) policies

+Because Microsoft Entra application proxy is a reverse-proxy, all traffic to back-end applications is terminated at the service. The session can get reestablished only with the back-end server, which means that your back-end servers are not exposed to direct HTTP traffic. This configuration means that you are better protected from targeted attacks.

+Application Proxy connectors only use outbound connections to the Microsoft Entra application proxy service, which means that there is no need to open firewall ports for incoming connections. Traditional proxies required a perimeter network (also known as *DMZ*, *demilitarized zone*, or *screened subnet*) and allowed access to unauthenticated connections at the network edge. This scenario required investments in web application firewall products to analyze traffic and protect the environment. With Application Proxy, you don't need a perimeter network because all connections are outbound and take place over a secure channel.

+For more information about connectors, see [Understand Microsoft Entra application proxy connectors](application-proxy-connectors.md).

+Because it's part of Microsoft Entra ID, Application Proxy can leverage [Microsoft Entra ID Protection](../identity-protection/overview-identity-protection.md), with data from the Microsoft Security Response Center and Digital Crimes Unit. Together we proactively identify compromised accounts and offer protection from high-risk sign-ins. We take into account numerous factors to determine which sign-in attempts are high risk. These factors include flagging infected devices, anonymizing networks, and atypical or unlikely locations.

+Unpatched software still accounts for a large number of attacks. Microsoft Entra application proxy is an Internet-scale service that Microsoft owns, so you always get the latest security patches and upgrades.

+To improve the security of applications published by Microsoft Entra application proxy, we block web crawler robots from indexing and archiving your applications. Each time a web crawler robot tries to retrieve the robot's settings for a published app, Application Proxy replies with a robots.txt file that includes `User-agent: * Disallow: /`.

+Microsoft Entra application proxy consists of two parts:

+* [The on-premises connector](application-proxy-connectors.md): An on-premises component, the connector listens for requests from the Microsoft Entra application proxy service and handles connections to the internal applications.

+1. The connector registration to the service happens as part of the installation of the connector. Users are prompted to enter their Microsoft Entra admin credentials. The token acquired from this authentication is then presented to the Microsoft Entra application proxy service.

+If you configured the app to preauthenticate with Microsoft Entra ID, users are redirected to the Microsoft Entra STS to authenticate, and the following steps take place:

+2. After all checks have passed, the Microsoft Entra STS issues a signed token for the application and redirects the user back to the Application Proxy service.

+3. Application Proxy verifies that the token was issued to the correct application. It performs other checks also, such as ensuring that the token was signed by Microsoft Entra ID, and that it is still within the valid window.

+4. Application Proxy sets an encrypted authentication cookie to indicate that authentication to the application has occurred. The cookie includes an expiration timestamp that's based on the token from Microsoft Entra ID and other data, such as the user name that the authentication is based on. The cookie is encrypted with a private key known only to the Application Proxy service.

+[Network topology considerations when using Microsoft Entra application proxy](application-proxy-network-topology.md)

+[Understand Microsoft Entra application proxy connectors](application-proxy-connectors.md)

+# Microsoft Entra certificate-based authentication with federation on Android

+Android devices can use certificate-based authentication (CBA) to authenticate to Microsoft Entra ID using a client certificate on their device when connecting to:

+For Microsoft Entra ID to revoke a client certificate, the AD FS token must have the following claims:

+Microsoft Entra ID adds these claims to the refresh token if they're available in the AD FS token (or any other SAML token). When the refresh token needs to be validated, this information is used to check the revocation.

+Office apps with modern authentication enabled send '*prompt=login*' to Microsoft Entra ID in their request. By default, Microsoft Entra ID translates '*prompt=login*' in the request to AD FS as '*wauth=usernamepassworduri*' (asks AD FS to do U/P Auth) and '*wfresh=0*' (asks AD FS 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 Microsoft Entra behavior. Set the '*PromptLoginBehavior*' in your federated domain settings to '*Disabled*'.

+# Get started with certificate-based authentication in Microsoft Entra ID with federation

+Certificate-based authentication (CBA) with federation enables you to be authenticated by Microsoft Entra ID with a client certificate on a Windows, Android, or iOS device when connecting your Exchange online account to:

+>As an alternative, organizations can deploy Microsoft Entra CBA without needing federation. For more information, see [Overview of Microsoft Entra certificate-based authentication against Microsoft Entra ID](concept-certificate-based-authentication.md).

+- CBA with federation is only supported for Federated environments for browser applications, native clients using modern authentication, or MSAL libraries. The one exception is Exchange Active Sync (EAS) for Exchange Online (EXO), which can be used for federated and managed accounts. To configure Microsoft Entra CBA without needing federation, see [How to configure Microsoft Entra certificate-based authentication](how-to-certificate-based-authentication.md).

+- The root certificate authority and any intermediate certificate authorities must be configured in Microsoft Entra ID.

+- You must have at least one certificate authority configured in Microsoft Entra ID. You can find related steps in the [Configure the certificate authorities](#step-2-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. Microsoft Entra ID maps the RFC822 value to the Proxy Address attribute in the directory.

+>The maximum size of a CRL for Microsoft Entra ID to successfully download and cache is 20MB, and the time required to download the CRL must not exceed 10 seconds. If Microsoft Entra ID can't download a CRL, certificate based authentications using certificates issued by the corresponding CA will fail. Best practices to ensure CRL files are within size constraints are to keep certificate lifetimes to within reasonable limits and to clean up expired certificates.

+description: Learn about the supported scenarios and the requirements for configuring certificate-based authentication for Microsoft Entra ID in solutions with iOS devices

+# Microsoft Entra certificate-based authentication with federation on iOS

+To improve security, iOS devices can use certificate-based authentication (CBA) to authenticate to Microsoft Entra ID using a client certificate on their device when connecting to the following applications or

+For Microsoft Entra ID to revoke a client certificate, the AD FS token must have the following claims. Microsoft Entra ID adds these claims to the refresh token if they're available in the AD FS token (or any other SAML token). When the refresh token needs to be validated, this information is used to check the revocation:

+Some Office apps with modern authentication enabled send `prompt=login` to Microsoft Entra ID in their request. By default, Microsoft Entra ID translates `prompt=login` in the request to AD FS as `wauth=usernamepassworduri` (asks AD FS to do U/P Auth) and `wfresh=0` (asks AD FS to ignore SSO state and do a fresh authentication). If you want to enable certificate-based authentication for these apps, modify the default Microsoft Entra behavior.

+description: Learn about using the Microsoft Authenticator in Microsoft Entra ID to help secure your sign-ins

+# Customer intent: As an identity administrator, I want to understand how to use the Microsoft Authenticator app in Microsoft Entra ID to improve and secure user sign-in events.

+# Authentication methods in Microsoft Entra ID - Microsoft Authenticator app

+The Microsoft Authenticator app provides an additional level of security to your Microsoft Entra work or school account or your Microsoft account and is available for [Android](https://go.microsoft.com/fwlink/?linkid=866594) and [iOS](https://go.microsoft.com/fwlink/?linkid=866594). With the Microsoft Authenticator app, users can authenticate in a passwordless way during sign-in, or as an additional verification option during self-service password reset (SSPR) or multifactor authentication events.

+<a name='fips-140-compliant-for-azure-ad-authentication'></a>

+## FIPS 140 compliant for Microsoft Entra authentication

+Beginning with version 6.6.8, Microsoft Authenticator for iOS is compliant with [Federal Information Processing Standard (FIPS) 140](https://csrc.nist.gov/publications/detail/fips/140/3/final?azure-portal=true) for all Microsoft Entra authentications using push multi-factor authentications (MFA), passwordless Phone Sign-In (PSI), and time-based one-time passcodes (TOTP).  

+No changes in configurations are required in Microsoft Authenticator or the Microsoft Entra admin center to enable FIPS 140 compliance. Beginning with Microsoft Authenticator for iOS version 6.6.8, Microsoft Entra authentications will be FIPS 140 compliant by default.

+ Title: Protecting authentication methods in Microsoft Entra ID

+description: Learn about authentication features that may be enabled by default in Microsoft Entra ID

+# Protecting authentication methods in Microsoft Entra ID

+Microsoft Entra ID adds and improves security features to better protect customers against increasing attacks. As new attack vectors become known, Microsoft Entra ID may respond by enabling protection by default to help customers stay ahead of emerging security threats.

+- After a security feature is released, customers can use the Microsoft Entra admin center or Graph API to test and roll out the change on their own schedule. To help defend against new attack vectors, Microsoft Entra ID may enable protection of a security feature by default for all tenants on a certain date, and there won't be an option to disable protection. Microsoft schedules default protection far in advance to give customers time to prepare for the change. Customers can't opt out if Microsoft schedules protection by default.

+- Protection can be **Microsoft managed**, which means Microsoft Entra ID can enable or disable protection based upon the current landscape of security threats. Customers can choose whether to allow Microsoft to manage the protection. They can change from **Microsoft managed** to explicitly make the protection **Enabled** or **Disabled** at any time.

+<a name='default-protection-enabled-by-azure-ad'></a>

+## Default protection enabled by Microsoft Entra ID

+In addition to configuring Authentication methods policy settings to be either **Enabled** or **Disabled**, IT admins can configure some settings in the Authentication methods policy to be **Microsoft managed**. A setting that is configured as **Microsoft managed** allows Microsoft Entra ID to enable or disable the setting.

+The option to let Microsoft Entra ID manage the setting is a convenient way for an organization to allow Microsoft to enable or disable a feature by default. Organizations can more easily improve their security posture by trusting Microsoft to manage when a feature should be enabled by default. By configuring a setting as **Microsoft managed** (named *default* in Graph APIs), IT admins can trust Microsoft to enable a security feature they haven't explicitly disabled.

+For example, an admin can enable [location and application name](how-to-mfa-number-match.md) in push notifications to give users more context when they approve MFA requests with Microsoft Authenticator. The additional context can also be explicitly disabled, or set as **Microsoft managed**. Today, the **Microsoft managed** configuration for location and application name is **Disabled**, which effectively disables the option for any environment where an admin chooses to let Microsoft Entra ID manage the setting.

+| [Registration campaign](how-to-mfa-registration-campaign.md) | From Sept 25 to Oct 20, 2023, the Microsoft managed value for the registration campaign will change to Enabled for text message and voice call users across all tenants. |

+As threat vectors change, Microsoft Entra ID may announce default protection for a **Microsoft managed** setting in [release notes](../fundamentals/whats-new.md) and on commonly read forums like [Tech Community](https://techcommunity.microsoft.com/). For example, see our blog post [It's Time to Hang Up on Phone Transports for Authentication](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/it-s-time-to-hang-up-on-phone-transports-for-authentication/ba-p/1751752) for more information about the need to move away from using text message and voice calls, which led to default enablement for the registration campaign to help users to set up Authenticator for modern authentication.

+[Authentication methods in Microsoft Entra ID - Microsoft Authenticator](concept-authentication-authenticator-app.md)

+# Customer intent: As an identity administrator, I want to understand what authentication options are available in Microsoft Entra ID and how I can manage them.

+# Manage authentication methods for Microsoft Entra ID

+Microsoft Entra ID allows the use of a range of authentication methods to support a wide variety of sign-in scenarios. Administrators can specifically configure each method to meet their goals for user experience and security. This topic explains how to manage authentication methods for Microsoft Entra ID, and how configuration options affect user sign-in and password reset scenarios.

+Methods enabled in the Authentication methods policy can typically be used anywhere in Microsoft Entra ID - for both authentication and password reset scenarios. The exception is that some methods are inherently limited to use in authentication, such as FIDO2 and Windows Hello for Business, and others are limited to use in password reset, such as security questions. For more control over which methods are usable in a given authentication scenario, consider using the **Authentication Strengths** feature.

+Two other policies, located in **multifactor authentication** settings and **Password reset** settings, provide a legacy way to manage some authentication methods for all users in the tenant. You can't control who uses an enabled authentication method, or how the method can be used. A [Global Administrator](../roles/permissions-reference.md#global-administrator) is needed to manage these policies.

+>In March 2023, we announced the deprecation of managing authentication methods in the legacy multifactor authentication and self-service password reset (SSPR) policies. Beginning September 30, 2024, authentication methods can't be managed in these legacy MFA and SSPR policies. We recommend customers use the manual migration control to migrate to the Authentication methods policy by the deprecation date.

+To manage the legacy MFA policy, click **Security** > **multifactor authentication** > **Additional cloud-based multifactor authentication settings**.

+Settings aren't synchronized between the policies, which allows administrators to manage each policy independently. Microsoft Entra ID respects the settings in all of the policies so a user who is enabled for an authentication method in _any_ policy can register and use that method. To prevent users from using a method, it must be disabled in all policies.

+- [What authentication and verification methods are available in Microsoft Entra ID?](concept-authentication-methods.md)

+- [How Microsoft Entra multifactor authentication works](concept-mfa-howitworks.md)

+description: Learn about the different authentication methods and features available in Microsoft Entra ID to help improve and secure sign-in events

+# Customer intent: As an identity administrator, I want to understand what authentication options are available in Microsoft Entra ID and how or why I can use them to improve and secure user sign-in events.

+# What authentication and verification methods are available in Microsoft Entra ID?

+Microsoft Entra multifactor authentication adds additional security over only using a password when a user signs in. The user can be prompted for additional forms of authentication, such as to respond to a push notification, enter a code from a software or hardware token, or respond to a text message or phone call.

+To simplify the user on-boarding experience and register for both MFA and self-service password reset (SSPR), we recommend you [enable combined security information registration](howto-registration-mfa-sspr-combined.md). For resiliency, we recommend that you require users to register multiple authentication methods. When one method isn't available for a user during sign-in or SSPR, they can choose to authenticate with another method. For more information, see [Create a resilient access control management strategy in Microsoft Entra ID](concept-resilient-controls.md).

+When you deploy features like Microsoft Entra multifactor authentication in your organization, review the available authentication methods. Choose the methods that meet or exceed your requirements in terms of security, usability, and availability. Where possible, use authentication methods with the highest level of security.

+The following table outlines the security considerations for the available authentication methods. Availability is an indication of the user being able to use the authentication method, not of the service availability in Microsoft Entra ID:

+Some authentication methods can be used as the primary factor when you sign in to an application or device, such as using a FIDO2 security key or a password. Other authentication methods are only available as a secondary factor when you use Microsoft Entra multifactor authentication or SSPR.

+> In Microsoft Entra ID, a password is often one of the primary authentication methods. You can't disable the password authentication method. If you use a password as the primary authentication factor, increase the security of sign-in events using Microsoft Entra multifactor authentication.

+* [App passwords](howto-mfa-app-passwords.md) - used for old applications that don't support modern authentication and can be configured for per-user Microsoft Entra multifactor authentication.

+To get started, see the [tutorial for self-service password reset (SSPR)][tutorial-sspr] and [Microsoft Entra multifactor authentication][tutorial-azure-mfa].

+To learn more about SSPR concepts, see [How Microsoft Entra self-service password reset works][concept-sspr].

+To learn more about MFA concepts, see [How Microsoft Entra multifactor authentication works][concept-mfa].

+To review what authentication methods are in use, see [Microsoft Entra multifactor authentication authentication method analysis with PowerShell](/samples/azure-samples/azure-mfa-authentication-method-analysis/azure-mfa-authentication-method-analysis/).

+description: Learn about using OATH tokens in Microsoft Entra ID to help improve and secure sign-in events

+# Customer intent: As an identity administrator, I want to understand how to use OATH tokens in Microsoft Entra ID to improve and secure user sign-in events.

+# Authentication methods in Microsoft Entra ID - OATH tokens

+OATH TOTP (Time-based One Time Password) is an open standard that specifies how one-time password (OTP) codes are generated. OATH TOTP can be implemented using either software or hardware to generate the codes. Microsoft Entra ID doesn't support OATH HOTP, a different code generation standard.

+Software OATH tokens are typically applications such as the Microsoft Authenticator app and other authenticator apps. Microsoft Entra ID generates the secret key, or seed, that's input into the app and used to generate each OTP.

+Microsoft Entra ID supports the use of OATH-TOTP SHA-1 tokens that refresh codes every 30 or 60 seconds. Customers can purchase these tokens from the vendor of their choice. Hardware OATH tokens are available for users with a Microsoft Entra ID P1 or P2 license.

+OATH TOTP hardware tokens typically come with a secret key, or seed, pre-programmed in the token. These keys must be input into Microsoft Entra ID as described in the following steps. Secret keys are limited to 128 characters, which may not be compatible with all tokens. The secret key can only contain the characters *a-z* or *A-Z* and digits *2-7*, and must be encoded in *Base32*.

+Programmable OATH TOTP hardware tokens that can be reseeded can also be set up with Microsoft Entra ID in the software token setup flow.

+ Title: Operator assistance in Microsoft Entra ID

+description: Learn about deprecation of operator assistance feature in Microsoft Entra ID

+On September 30, 2023, we will retire operator assistance in Microsoft Entra multifactor authentication and it will no longer be available. To avoid service disruption, follow the steps in this topic to disable operator assistance before September 30, 2023.

+Operator assistance is a feature within Microsoft Entra ID that allows an operator to manually transfer phone calls instead of automatic transfer. When this setting is enabled, the office phone number is dialed and when answered, the system asks the operator to transfer the call to a given extension.

+To check the status of this feature in your own tenant, sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least an [Authentication Policy Administrator](../roles/permissions-reference.md#authentication-policy-administrator), then click **Protection** > **multifactor authentication** > **Phone call settings**. Check **Operator required to transfer extensions** to see if the setting is **On** or **Off**.

+- You have [registered a direct phone number](https://aka.ms/mfasetup) (contains no extension) or [other method](concept-authentication-methods.md) to be used for multifactor authentication or self-service password reset if enabled.

+- Your admins have registered a direct phone number (contains no extension) on behalf of the user to be used for [multifactor authentication](howto-mfa-userdevicesettings.md#add-authentication-methods-for-a-user) or [self-service password reset](tutorial-enable-sspr.md) if enabled.

+ Title: Microsoft Entra passwordless sign-in

+description: Learn about options for passwordless sign-in to Microsoft Entra ID using FIDO2 security keys or Microsoft Authenticator

+# Passwordless authentication options for Microsoft Entra ID

+Each organization has different needs when it comes to authentication. Microsoft global Azure and Azure Government offer the following three passwordless authentication options that integrate with Microsoft Entra ID:

+The following steps show how the sign-in process works with Microsoft Entra ID:

+1. The Cloud AP provider requests a nonce (a random arbitrary number that can be used just once) from Microsoft Entra ID.

+1. Microsoft Entra ID returns a nonce that's valid for 5 minutes.

+1. The Cloud AP provider signs the nonce using the user's private key and returns the signed nonce to the Microsoft Entra ID.

+1. Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. Microsoft Entra ID validates the signature and then validates the returned signed nonce. When the nonce is validated, Microsoft Entra ID creates a primary refresh token (PRT) with session key that is encrypted to the device's transport key and returns it to the Cloud AP provider.

+Passwordless authentication using the Authenticator app follows the same basic pattern as Windows Hello for Business. It's a little more complicated as the user needs to be identified so that Microsoft Entra ID can find the Authenticator app version being used:

+1. Microsoft Entra ID detects that the user has a strong credential and starts the Strong Credential flow.

+1. The app calls Microsoft Entra ID and receives a proof-of-presence challenge and nonce.

+1. The nonce is signed with the private key and sent back to Microsoft Entra ID.

+1. Microsoft Entra ID performs public/private key validation and returns a token.

+FIDO2 security keys can be used to sign in to their Microsoft Entra ID or Microsoft Entra hybrid joined Windows 10 devices and get single-sign on to their cloud and on-premises resources. Users can also sign in to supported browsers. 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.

+We have a reference document for which [browsers support FIDO2 authentication with Microsoft Entra ID](fido2-compatibility.md), as well as best practices for developers wanting to [support FIDO2 auth in the applications they develop](../develop/support-fido2-authentication.md).

+4. Microsoft Entra ID sends back a nonce.

+7. The primary refresh token (PRT) token request with signed nonce is sent to Microsoft Entra ID.

+8. Microsoft Entra ID verifies the signed nonce using the FIDO2 public key.

+9. Microsoft Entra ID returns PRT to enable access to on-premises resources.

+ - Authenticator app: Works in scenarios where Microsoft Entra authentication is used, including across all browsers, during Windows 10 setup, and with integrated mobile apps on any operating system.

+|**Pre-requisite**| Windows 10, version 1809 or later<br>Microsoft Entra ID| Authenticator app<br>Phone (iOS and Android devices)|Windows 10, version 1903 or later<br>Microsoft Entra ID|

+To get started with passwordless in Microsoft Entra ID, complete one of the following how-tos:

+description: Learn about using phone authentication methods in Microsoft Entra ID to help improve and secure sign-in events

+# Customer intent: As an identity administrator, I want to understand how to use phone authentication methods in Microsoft Entra ID to improve and secure user sign-in events.

+# Authentication methods in Microsoft Entra ID - phone options

+Microsoft recommends users move away from using text messages or voice calls for multifactor authentication. Modern authentication methods like [Microsoft Authenticator](concept-authentication-authenticator-app.md) are a recommended alternative. For more information, see [It's Time to Hang Up on Phone Transports for Authentication](https://aka.ms/hangup). Users can still verify themselves using a mobile phone or office phone as secondary form of authentication used for multifactor authentication or self-service password reset (SSPR).

+>Phone call verification isn't available for Microsoft Entra tenants with trial subscriptions. For example, if you sign up for a trial license Microsoft Enterprise Mobility and Security (EMS), phone call verification isn't available. Phone numbers must be provided in the format *+CountryCode PhoneNumber*, for example, *+1 4251234567*. There must be a space between the country/region code and the phone number.

+For Microsoft Entra multifactor authentication or SSPR, users can choose to receive a text message with a verification code to enter in the sign-in interface, or receive a phone call.

+Microsoft doesn't guarantee consistent text message or voice-based Microsoft Entra multifactor authentication prompt delivery by the same number. In the interest of our users, we may add or remove short codes at any time as we make route adjustments to improve text message deliverability. Microsoft doesn't support short codes for countries/regions besides the United States and Canada.

+With text message verification during SSPR or Microsoft Entra multifactor authentication, a text message is sent to the mobile phone number containing a verification code. To complete the sign-in process, the verification code provided is entered into the sign-in interface.

+With phone call verification during SSPR or Microsoft Entra multifactor authentication, an automated voice call is made to the phone number registered by the user. To complete the sign-in process, the user is prompted to press # on their keypad.

+With office phone call verification during SSPR or Microsoft Entra multifactor authentication, an automated voice call is made to the phone number registered by the user. To complete the sign-in process, the user is prompted to press # on their keypad.

+If you have problems with phone authentication for Microsoft Entra ID, review the following troubleshooting steps:

+ * Have a Microsoft Entra administrator unblock the user in the Microsoft Entra admin center.

+ - There are a few country codes blocked for voice MFA unless your Microsoft Entra administrator has opted in for those country codes. Have your Microsoft Entra administrator opt-in to receive MFA for those country codes.

+To get started, see the [tutorial for self-service password reset (SSPR)][tutorial-sspr] and [Microsoft Entra multifactor authentication][tutorial-azure-mfa].

+To learn more about SSPR concepts, see [How Microsoft Entra self-service password reset works][concept-sspr].

+To learn more about MFA concepts, see [How Microsoft Entra multifactor authentication works][concept-mfa].

+description: Learn about using security questions in Microsoft Entra ID to help improve and secure sign-in events

+# Customer intent: As an identity administrator, I want to understand how to use security questions in Microsoft Entra ID to improve and secure user sign-in events.

+# Authentication methods in Microsoft Entra ID - security questions

+To learn more about SSPR concepts, see [How Microsoft Entra self-service password reset works][concept-sspr].

+ Title: Overview of Microsoft Entra authentication strength

+description: Learn how admins can use Microsoft Entra Conditional Access to distinguish which authentication methods can be used based on relevant security factors.

+Authentication strength is based on the [Authentication methods policy](concept-authentication-methods.md), where administrators can scope authentication methods for specific users and groups to be used across Microsoft Entra ID federated applications. Authentication strength allows further control over the usage of these methods based upon specific scenarios such as sensitive resource access, user risk, location, and more.

+- Microsoft Entra Certificate-Based Authentication (Multi-Factor)

+The authentication strength Conditional Access policy defines which methods can be used. Microsoft Entra ID checks the policy during sign-in to determine the userΓÇÖs access to the resource. For example, an administrator configures a Conditional Access policy with a custom authentication strength that requires FIDO2 Security Key or Password + text message. The user accesses a resource protected by this policy. During sign-in, all settings are checked to determine which methods are allowed, which methods are registered, and which methods are required by the Conditional Access policy. To be used, a method must be allowed, registered by the user (either before or as part of the access request), and satisfy the authentication strength.

+When a user accesses a resource protected by an authentication strength Conditional Access policy, Microsoft Entra ID evaluates if the methods they have previously used satisfy the authentication strength. If a satisfactory method was used, Microsoft Entra ID grants access to the resource. For example, let's say a user signs in with password + text message. They access a resource protected by MFA authentication strength. In this case, the user can access the resource without another authentication prompt.

+For federated domains, MFA may be enforced by Microsoft Entra Conditional Access or by the on-premises federation provider by setting the federatedIdpMfaBehavior. If the federatedIdpMfaBehavior setting is set to enforceMfaByFederatedIdp, the user must authenticate on their federated IdP and can only satisfy the **Federated Multi-Factor** combination of the authentication strength requirement. For more information about the federation settings, see [Plan support for MFA](../hybrid/connect/migrate-from-federation-to-cloud-authentication.md#plan-support-for-mfa).

+When you apply an authentication strength Conditional Access policy to external Microsoft Entra users, the policy works together with MFA trust settings in your cross-tenant access settings to determine where and how the external user must perform MFA. A Microsoft Entra user authenticates in their home Microsoft Entra tenant. Then when they access your resource, Microsoft Entra ID applies the policy and checks to see if you've enabled MFA trust. Note that enabling MFA trust is optional for B2B collaboration but is *required* for [B2B direct connect](../external-identities/b2b-direct-connect-overview.md#multi-factor-authentication-mfa).

+In external user scenarios, the authentication methods that can satisfy authentication strength vary, depending on whether the user is completing MFA in their home tenant or the resource tenant. The following table indicates the allowed methods in each tenant. If a resource tenant has opted to trust claims from external Microsoft Entra organizations, only those claims listed in the ΓÇ£Home tenantΓÇ¥ column below will be accepted by the resource tenant for MFA. If the resource tenant has disabled MFA trust, the external user must complete MFA in the resource tenant using one of the methods listed in the ΓÇ£Resource tenantΓÇ¥ column.

+An authentication strength Conditional Access policy works together with [MFA trust settings](../external-identities/cross-tenant-access-settings-b2b-collaboration.md#to-change-inbound-trust-settings-for-mfa-and-device-claims) in your cross-tenant access settings. First, a Microsoft Entra user authenticates with their own account in their home tenant. Then when this user tries to access your resource, Microsoft Entra ID applies the authentication strength Conditional Access policy and checks to see if you've enabled MFA trust.

+- **If MFA trust is enabled**, Microsoft Entra ID checks the user's authentication session for a claim indicating that MFA has been fulfilled in the user's home tenant. See the preceding table for authentication methods that are acceptable for MFA when completed in an external user's home tenant. If the session contains a claim indicating that MFA policies have already been met in the user's home tenant, and the methods satisfy the authentication strength requirements, the user is allowed access. Otherwise, Microsoft Entra ID presents the user with a challenge to complete MFA in the home tenant using an acceptable authentication method.

+- **If MFA trust is disabled**, Microsoft Entra ID presents the user with a challenge to complete MFA in the resource tenant using an acceptable authentication method. (See the table above for authentication methods that are acceptable for MFA by an external user.)

+Authentication strength is based on the Authentication methods policy. The Authentication methods policy helps to scope and configure authentication methods to be used across Microsoft Entra ID by specific users and groups. Authentication strength allows another restriction of methods for specific scenarios, such as sensitive resource access, user risk, location, and more.

+- **Microsoft Entra ID P1** - Your tenant needs to have Microsoft Entra ID P1 license to use Conditional Access. If needed, you can enable a [free trial](https://www.microsoft.com/security/business/get-started/start-free-trial).

+ Title: Web browser cookies used in Microsoft Entra authentication

+description: Learn about Web browser cookies used in Microsoft Entra authentication.

+# Customer intent: As a Microsoft Entra administrator, I want to understand which weh browser cookies are used for Microsoft Entra ID.

+# Web browser cookies used in Microsoft Entra authentication

+During authentication against Microsoft Entra ID through a web browser, multiple cookies are involved in the process. Some of the cookies are common on all requests. Other cookies are used for specific authentication flows or specific client-side conditions.

+| CCState | Common | Contains session information state to be used between Microsoft Entra ID and the [Microsoft Entra Backup Authentication Service](../conditional-access/resilience-defaults.md). |

+| x-ms-gateway-slice | Common | Microsoft Entra Gateway cookie used for tracking and load balance purposes. |

+| stsservicecookie | Common | Microsoft Entra Gateway cookie also used for tracking purposes. |

+| CcsNtv | Specific | To control when Microsoft Entra Gateway will send requests to [Microsoft Entra Backup Authentication Service](../conditional-access/resilience-defaults.md). Native flows. |

+| CcsWeb | Specific | To control when Microsoft Entra Gateway will send requests to [Microsoft Entra Backup Authentication Service](../conditional-access/resilience-defaults.md). Web flows. |

+| Ccs* | Specific | Cookies with prefix Ccs*, have the same purpose as the ones without prefix, but only apply when [Microsoft Entra Backup Authentication Service](../conditional-access/resilience-defaults.md) is in use. |

+> Cookie definitions and respective names are subject to change at any moment in time according to Microsoft Entra service requirements.

+To learn more about self-service password reset concepts, see [How Microsoft Entra self-service password reset works][concept-sspr].

+To learn more about multifactor authentication concepts, see [How Microsoft Entra multifactor authentication works][concept-mfa].

+ Title: Certificate user IDs for Microsoft Entra certificate-based authentication

+description: Learn about certificate user IDs for Microsoft Entra certificate-based authentication without federation

+Users in Microsoft Entra ID can have a multivalued attribute named **certificateUserIds**. The attribute allows up to four values, and each value can be of 120-character length. It can store any value and doesn't require email ID format. It can store non-routable User Principal Names (UPNs) like _bob@woodgrove_ or _bob@local_.

+>Active Directory Administrators (including accounts with delegated administrative privilege over synched user accounts as well as administrative rights over the Azure >AD Connect Servers) can make changes that impact the certificateUserIds value in Microsoft Entra ID for any synched accounts.

+<a name='update-certificate-user-ids-using-azure-ad-connect'></a>

+## Update certificate user IDs using Microsoft Entra Connect

+To update certificate user IDs for federated users, configure Microsoft Entra Connect to sync userPrincipalName to certificateUserIds.

+1. On the Microsoft Entra Connect server, find and start the **Synchronization Rules Editor**.

+1. Find the rule **Out to Microsoft Entra ID ΓÇô User Identity**, click **Edit**, and click **Yes** to confirm.

+> Make sure you use the latest version of [Microsoft Entra Connect](https://www.microsoft.com/download/details.aspx?id=47594).

+For more information about declarative provisioning expressions, see [Microsoft Entra Connect: Declarative Provisioning Expressions](../hybrid/connect/concept-azure-ad-connect-sync-declarative-provisioning-expressions.md).

+<a name='synchronize-alternativesecurityid-attribute-from-ad-to-azure-ad-cba-certificateuserids'></a>

+## Synchronize alternativeSecurityId attribute from AD to Microsoft Entra CBA CertificateUserIds

+ |Name | Descriptive name of the rule, such as: Out to Microsoft Entra ID - certificateUserIds |

+ |Connected System | Your Microsoft Entra domain |

+- [Overview of Microsoft Entra CBA](concept-certificate-based-authentication.md)

+- [Technical deep dive for Microsoft Entra CBA](concept-certificate-based-authentication-technical-deep-dive.md)

+- [How to configure Microsoft Entra CBA](how-to-certificate-based-authentication.md)

+- [Microsoft Entra CBA on iOS devices](concept-certificate-based-authentication-mobile-ios.md)

+- [Microsoft Entra CBA on Android devices](concept-certificate-based-authentication-mobile-android.md)

+- [Windows smart card logon using Microsoft Entra CBA](concept-certificate-based-authentication-smartcard.md)

+ Title: Limitations with Microsoft Entra certificate-based authentication without federation

+description: Learn supported and unsupported scenarios for Microsoft Entra certificate-based authentication

+# Limitations with Microsoft Entra certificate-based authentication

+This topic covers supported and unsupported scenarios for Microsoft Entra certificate-based authentication.

+- [Overview of Microsoft Entra CBA](concept-certificate-based-authentication.md)

+- [Technical deep dive for Microsoft Entra CBA](concept-certificate-based-authentication-technical-deep-dive.md)

+- [How to configure Microsoft Entra CBA](how-to-certificate-based-authentication.md)

+- [Windows SmartCard logon using Microsoft Entra CBA](concept-certificate-based-authentication-smartcard.md)

+- [Microsoft Entra CBA on mobile devices (Android and iOS)](./concept-certificate-based-authentication-mobile-ios.md)

+ Title: Migrate from federation to Microsoft Entra CBA

+description: Learn how to migrate from Federated server to Microsoft Entra ID

+# Migrate from federation to Microsoft Entra certificate-based authentication (CBA)

+This article explains how to migrate from running federated servers such as Active Directory Federation Services (AD FS) on-premises to cloud authentication using Microsoft Entra certificate-based authentication (CBA).

+[Staged Rollout](../hybrid/connect/how-to-connect-staged-rollout.md) helps customers transition from AD FS to Microsoft Entra ID by testing cloud authentication with selected groups of users before switching the entire tenant.

+1. Search for and select **Microsoft Entra Connect**.

+1. On the Microsoft Entra Connect page, under the Staged Rollout of cloud authentication, click **Enable Staged Rollout for managed user sign-in**.

+> When Staged rollout is enabled for a user, the user is considered a managed user and all authentication will happen at Microsoft Entra ID. For a federated Tenant, if CBA is enabled on Staged Rollout, password authentication only works if PHS is enabled too otherwise password authentication will fail.

+<a name='use-azure-ad-connect-to-update-certificateuserids-attribute'></a>

+## Use Microsoft Entra Connect to update certificateUserIds attribute

+An AD FS admin can use **Synchronization Rules Editor** to create rules to sync the values of attributes from AD FS to Microsoft Entra user objects. For more information, see [Sync rules for certificateUserIds](concept-certificate-based-authentication-certificateuserids.md#update-certificate-user-ids-using-azure-ad-connect).

+Microsoft Entra Connect requires a special role named **Hybrid Identity Administrator**, which grants the necessary permissions. You need this role for permission to write to the new cloud attribute.

+>If a user is using synchronized attributes, such as the onPremisesUserPrincipalName attribute in the user object for username binding, be aware that any user that has administrative access to the Microsoft Entra Connect server can change the synchronized attribute mapping, and change the value of the synchronized attribute. The user does not need to be a cloud admin. The AD FS admin should make sure the administrative access to the Microsoft Entra Connect server should be limited, and privileged accounts should be cloud-only accounts.

+<a name='frequently-asked-questions-about-migrating-from-ad-fs-to-azure-ad'></a>

+## Frequently asked questions about migrating from AD FS to Microsoft Entra ID

+Although it's possible, Microsoft recommends privileged accounts be cloud-only accounts. Using cloud-only accounts for privileged access limits exposure in Microsoft Entra ID from a compromised on-premises environment. For more information, see [Protecting Microsoft 365 from on-premises attacks](../architecture/protect-m365-from-on-premises-attacks.md).

+Microsoft recommends privileged accounts be cloud-only accounts. This practice will limit the exposure in Microsoft Entra ID from a compromised on-premises environment. Maintaining privileged accounts a cloud-only is foundational to this goal.

+- If they're in a federated domain, but a subset of accounts is being moved to Microsoft Entra CBA by Staged Rollout, they're subject to risks related to the federated Idp until the federated domain is fully switched to cloud authentication.

+When a domain is federated in Microsoft Entra ID, a high level of trust is being placed on the Federated IdP. AD FS is one example, but the notion holds true for *any* federated IdP. Many organizations deploy a federated IdP such as AD FS exclusively to accomplish certificate based authentication. Microsoft Entra CBA completely removes the AD FS dependency in this case. With Microsoft Entra CBA, customers can move their application estate to Microsoft Entra ID to modernize their IAM infrastructure and reduce costs with increased security.

+From a security perspective, there's no change to the credential, including the X.509 certificate, CACs, PIVs, and so on, or to the PKI being used. The PKI owners retain complete control of the certificate issuance and revocation lifecycle and policy. The revocation check and the authentication happen at Microsoft Entra ID instead of federated Idp. These checks enable passwordless, phishing-resistant authentication directly to Microsoft Entra ID for all users.

+<a name='how-does-authentication-work-with-federated-ad-fs-and-azure-ad-cloud-authentication-with-windows'></a>

+### How does authentication work with Federated AD FS and Microsoft Entra cloud authentication with Windows?

+Microsoft Entra CBA requires the user or application to supply the Microsoft Entra UPN of the user who signs in.

+In the browser example, the user most often types in their Microsoft Entra UPN. The Microsoft Entra UPN is used for realm and user discovery. The certificate used then must match this user by using one of the configured username bindings in the policy.

+In Windows sign-in, the match depends on if the device is hybrid or Microsoft Entra joined. But in both cases, if username hint is provided, Windows will send the hint as a Microsoft Entra UPN. The certificate used then must match this user by using one of the configured username bindings in the policy.

+- [Overview of Microsoft Entra CBA](concept-certificate-based-authentication.md)

+- [Technical deep dive for Microsoft Entra CBA](concept-certificate-based-authentication-technical-deep-dive.md)

+- [How to configure Microsoft Entra CBA](how-to-certificate-based-authentication.md)

+- [Microsoft Entra CBA on iOS devices](concept-certificate-based-authentication-mobile-ios.md)

+- [Microsoft Entra CBA on Android devices](concept-certificate-based-authentication-mobile-android.md)

+- [Windows smart card logon using Microsoft Entra CBA](concept-certificate-based-authentication-smartcard.md)

+ Title: Microsoft Entra certificate-based authentication on Android devices

+description: Learn about Microsoft Entra certificate-based authentication on Android devices

+# Microsoft Entra certificate-based authentication on Android devices

+Android devices can use a client certificate on their device for certificate-based authentication (CBA) to Microsoft Entra ID. CBA can be used to connect to:

+Microsoft Entra CBA is supported for certificates on-device on native browsers, and on Microsoft first-party applications on Android devices.

+To determine if your email application supports Microsoft Entra CBA, contact your application developer.

+Certificates can be provisioned in external devices like hardware security keys along with a PIN to protect private key access. Microsoft Entra ID supports CBA with YubiKey.

+<a name='azure-ad-cba-on-android-mobile-'></a>

+### Microsoft Entra CBA on Android mobile

+Android needs a middleware application to be able to support smartcard or security keys with certificates. To support YubiKeys with Microsoft Entra CBA, YubiKey Android SDK has been integrated into the Microsoft broker code which can be leveraged through the latest Microsoft Authentication Library (MSAL).

+<a name='azure-ad-cba-on-android-mobile-with-yubikey-'></a>

+### Microsoft Entra CBA on Android mobile with YubiKey

+Because Microsoft Entra CBA with YubiKey on Android mobile is enabled by using the latest MSAL, YubiKey Authenticator app isn't required for Android support.

+<a name='does-azure-ad-cba-support-yubikey-via-nfc-'></a>

+#### Does Microsoft Entra CBA support YubiKey via NFC?

+<a name='azure-ad-cba-with-yubikey-is-failing-what-information-would-help-debug-the-issue-'></a>

+#### Microsoft Entra CBA with YubiKey is failing. What information would help debug the issue?

+- Microsoft Entra CBA with YubiKey on latest Outlook and Teams fail at times. This could be due to a keyboard configuration change when the YubiKey is plugged in. This can be solved by:

+- [Overview of Microsoft Entra CBA](concept-certificate-based-authentication.md)

+- [Technical deep dive for Microsoft Entra CBA](concept-certificate-based-authentication-technical-deep-dive.md)

+- [How to configure Microsoft Entra CBA](how-to-certificate-based-authentication.md)

+- [Microsoft Entra CBA on iOS devices](concept-certificate-based-authentication-mobile-ios.md)

+- [Windows SmartCard logon using Microsoft Entra CBA](concept-certificate-based-authentication-smartcard.md)

+ Title: Microsoft Entra certificate-based authentication on Apple devices

+description: Learn about Microsoft Entra certificate-based authentication on Apple devices that run macOS or iOS

+# Microsoft Entra certificate-based authentication on iOS and macOS

+This topic covers Microsoft Entra certificate-based authentication (CBA) support for macOS and iOS devices.

+<a name='azure-active-directory-certificate-based-authentication-on-macos-devices'></a>

+## Microsoft Entra certificate-based authentication on macOS devices

+Devices that run macOS can use CBA to authenticate against Microsoft Entra ID by using their X.509 client certificate. Microsoft Entra CBA is supported with certificates on-device and external hardware protected security keys. On macOS, Microsoft Entra CBA is supported on all browsers and on Microsoft first-party applications.

+<a name='macos-device-sign-in-with-azure-ad-cba'></a>

+### macOS device sign-in with Microsoft Entra CBA

+Microsoft Entra CBA today isn't supported for device-based sign-in to macOS machines. The certificate used to sign in to the device can be the same certificate used to authenticate to Microsoft Entra ID from a browser or desktop application, but the device sign-in itself isn't supported against Microsoft Entra ID yet. 

+<a name='azure-active-directory-certificate-based-authentication-on-ios-devices'></a>

+## Microsoft Entra certificate-based authentication on iOS devices

+Devices that run iOS can use certificate-based authentication (CBA) to authenticate to Microsoft Entra ID using a client certificate on their device when connecting to:

+Microsoft Entra CBA is supported for certificates on-device on native browsers and on Microsoft first-party applications on iOS devices.

+To determine if your email application supports Microsoft Entra CBA, contact your application developer.

+As for iOS 16/iPadOS 16.1, Apple devices provide native driver support for USB-C or Lightning connected CCID-compliant smart cards. This means Apple devices on iOS 16/iPadOS 16.1 see a USB-C or Lightning connected CCID-compliant device as a smart card without the use of additional drivers or third-party apps. Microsoft Entra CBA works on these USB-A, USB-C, or Lightning connected CCID-compliant smart cards.

+<a name='azure-ad-cba-on-ios-mobile-with-yubikey-'></a>

+### Microsoft Entra CBA on iOS mobile with YubiKey

+<a name='azure-ad-cba-with-yubikey-is-failing-what-information-would-help-debug-the-issue-'></a>

+#### Microsoft Entra CBA with YubiKey is failing. What information would help debug the issue?

+- [Overview of Microsoft Entra CBA](concept-certificate-based-authentication.md)

+- [Technical deep dive for Microsoft Entra CBA](concept-certificate-based-authentication-technical-deep-dive.md)

+- [How to configure Microsoft Entra CBA](how-to-certificate-based-authentication.md)

+- [Microsoft Entra CBA on Android devices](concept-certificate-based-authentication-mobile-android.md)

+- [Windows smart card logon using Microsoft Entra CBA](concept-certificate-based-authentication-smartcard.md)

+ Title: Windows smart card sign-in using Microsoft Entra certificate-based authentication

+description: Learn how to enable Windows smart card sign-in using Microsoft Entra certificate-based authentication

+# Windows smart card sign-in using Microsoft Entra certificate-based authentication

+Microsoft Entra users can authenticate using X.509 certificates on their smart cards directly against Microsoft Entra ID at Windows sign-in. There's no special configuration needed on the Windows client to accept the smart card authentication.

+1. Join the machine to either Microsoft Entra ID or a hybrid environment (hybrid join).

+1. Configure Microsoft Entra CBA in your tenant as described in [Configure Microsoft Entra CBA](how-to-certificate-based-authentication.md).

+Users will get a primary refresh token (PRT) from Microsoft Entra ID after the successful sign-in. Depending on the CBA configuration, the PRT will contain the multifactor claim.

+<a name='expected-behavior-of-windows-sending-user-upn-to-azure-ad-cba'></a>

+## Expected behavior of Windows sending user UPN to Microsoft Entra CBA

+|Sign-in | Microsoft Entra join | Hybrid join |

+|Subsequent sign-in | Pull from certificate | Cached Microsoft Entra UPN |

+<a name='windows-rules-for-sending-upn-for-azure-ad-joined-devices'></a>

+### Windows rules for sending UPN for Microsoft Entra joined devices

+<a name='windows-rules-for-sending-upn-for-hybrid-azure-ad-joined-devices'></a>

+### Windows rules for sending UPN for Microsoft Entra hybrid joined devices

+Hybrid Join sign-in must first successfully sign-in against the Active Directory(AD) domain. The users AD UPN is sent to Microsoft Entra ID. In most cases, the Active Directory UPN value is the same as the Microsoft Entra UPN value and is synchronized with Microsoft Entra Connect.

+Some customers may maintain different and sometimes may have non-routable UPN values in Active Directory (such as user@woodgrove.local) In these cases the value sent by Windows may not match the users Microsoft Entra UPN. To support these scenarios where Microsoft Entra ID can't match the value sent by Windows, a subsequent lookup is performed for a user with a matching value in their **onPremisesUserPrincipalName** attribute. If the sign-in is successful, Windows will cache the users Microsoft Entra UPN and is sent in subsequent sign-ins.

+>Microsoft Entra CBA supports both certificates on-device as well as external storage like security keys on Windows.

+Windows OOBE should allow the user to login using an external smart card reader and authenticate against Microsoft Entra CBA. Windows OOBE by default should have the necessary smart card drivers or the smart card drivers previously added to the Windows image before OOBE setup.

+- Microsoft Entra CBA is supported on Windows devices that are hybrid or Microsoft Entra joined.

+- [Overview of Microsoft Entra CBA](concept-certificate-based-authentication.md)

+- [Technical deep dive for Microsoft Entra CBA](concept-certificate-based-authentication-technical-deep-dive.md)

+- [How to configure Microsoft Entra CBA](how-to-certificate-based-authentication.md)

+- [Microsoft Entra CBA on iOS devices](concept-certificate-based-authentication-mobile-ios.md)

+- [Microsoft Entra CBA on Android devices](concept-certificate-based-authentication-mobile-android.md)

+ Title: Microsoft Entra certificate-based authentication technical deep dive

+description: Learn how Microsoft Entra certificate-based authentication works

+# Microsoft Entra certificate-based authentication technical deep dive

+This article explains how Microsoft Entra certificate-based authentication (CBA) works, and dives into technical details on Microsoft Entra CBA configurations.

+<a name='how-does-azure-ad-certificate-based-authentication-work'></a>

+## How does Microsoft Entra certificate-based authentication work?

+The following image describes what happens when a user tries to sign in to an application in a tenant where Microsoft Entra CBA is enabled.

+1. If the user isn't already signed in, the user is redirected to the Microsoft Entra ID **User Sign-in** page at [https://login.microsoftonline.com/](https://login.microsoftonline.com/).

+1. The user enters their username into the Microsoft Entra sign-in page, and then clicks **Next**. Microsoft Entra ID does home realm discovery using the tenant name and the username is used to look up the user in Microsoft Entra tenant.

+1. Microsoft Entra ID checks whether CBA is enabled for the tenant. If CBA is enabled, the user sees a link to **Use a certificate or smartcard** on the password page. If the user doesn't see the sign-in link, make sure CBA is enabled on the tenant. For more information, see [How do I enable Microsoft Entra CBA?](./certificate-based-authentication-faq.yml#how-can-an-administrator-enable-microsoft-entra-cba-).

+ > If CBA is enabled on the tenant, all users will see the link to **Use a certificate or smart card** on the password page. However, only the users in scope for CBA will be able to authenticate successfully against an application that uses Microsoft Entra ID as their Identity provider (IdP).

+ :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/sign-in-log.png" alt-text="Screenshot of the Sign-ins log in Microsoft Entra ID." lightbox="./media/concept-certificate-based-authentication-technical-deep-dive/sign-in-log.png":::

+1. Microsoft Entra ID will request a client certificate, the user picks the client certificate, and clicks **Ok**.

+1. Microsoft Entra ID verifies the certificate revocation list to make sure the certificate isn't revoked and is valid. Microsoft Entra ID identifies the user by using the [username binding configured](how-to-certificate-based-authentication.md#step-4-configure-username-binding-policy) on the tenant to map the certificate field value to the user attribute value.

+1. If a unique user is found with a Conditional Access policy that requires multifactor authentication, and the [certificate authentication binding rule](how-to-certificate-based-authentication.md#step-3-configure-authentication-binding-policy) satisfies MFA, then Microsoft Entra ID signs the user in immediately. If MFA is required but the certificate satisfies only a single factor, either passwordless sign-in or FIDO2 will be offered as a second factor if they are already registered.

+1. Microsoft Entra ID completes the sign-in process by sending a primary refresh token back to indicate successful sign-in.

+Microsoft Entra CBA is an MFA (multifactor authentication) capable method, that is Microsoft Entra CBA can be either Single (SF) or multifactor (MF) depending on the tenant configuration. Enabling CBA for a user indicates the user is potentially capable of MFA. This means a user may need additional configuration to get MFA and proof up to register other authentication methods when the user is in scope for CBA.

+Microsoft Entra CBA can be used as a second factor to meet MFA requirements with single-factor certificates.

+Users need to have another way to get MFA and register passwordless sign-in or FIDO2 in advance to signing in with Microsoft Entra CBA.

+>A user will be considered MFA capable when a user is in scope for Certificate-based authentication auth method. This means user will not be able to use proof up as part of their authentication to registerd other available methods. Make sure users who do not have a valid certificate are not part of CBA auth method scope. More info on [Microsoft Entra multifactor authentication](../authentication/concept-mfa-howitworks.md)

+1. Select **Protection** > **multifactor authentication** > **Additional cloud-based multifactor authentication settings**.

+An admin can determine whether the certificates are single-factor or multifactor strength. For more information, see the documentation that maps [NIST Authentication Assurance Levels to Microsoft Entra auth Methods](https://aka.ms/AzureADNISTAAL), which builds upon [NIST 800-63B SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Mgmt](https://csrc.nist.gov/publications/detail/sp/800-63b/final).

+<a name='how-azure-ad-resolves-multiple-authentication-policy-binding-rules'></a>

+### How Microsoft Entra ID resolves multiple authentication policy binding rules

+There are four supported methods. In general, mapping types are considered high-affinity if they're based on identifiers that you can't reuse (Such as Subject Key Identifiers or SHA1 Public Key). These identifiers convey a higher assurance that only a single certificate can be used to authenticate the respective user. Therefore, all mapping types based on usernames and email addresses are considered low-affinity. Therefore, Microsoft Entra ID implements two mappings considered low-affinity (based on reusable identifiers), and the other two are considered high-affinity bindings. For more information, see [certificateUserIds](concept-certificate-based-authentication-certificateuserids.md).

+<a name='how-azure-ad-resolves-multiple-username-policy-binding-rules'></a>

+### How Microsoft Entra ID resolves multiple username policy binding rules

+1. If the X.509 certificate field is on the presented certificate, Microsoft Entra ID will match the value in the certificate field to the user object attribute value.

+<a name='securing-azure-ad-configuration-with-multiple-username-bindings'></a>

+## Securing Microsoft Entra configuration with multiple username bindings

+Each of the Microsoft Entra attributes (userPrincipalName, onPremiseUserPrincipalName, certificateUserIds) available to bind certificates to Microsoft Entra user accounts has unique constraint to ensure a certificate only matches a single Microsoft Entra user account. However, Microsoft Entra CBA does support configuring multiple binding methods in the username binding policy. This allows an administrator to accommodate multiple certificate configurations. However the combination of some methods can also potentially permit one certificate to match to multiple Microsoft Entra user accounts.

+>When using multiple bindings, Microsoft Entra CBA authentication is only as secure as your low-affinity binding as Microsoft Entra CBA will validate each of the bindings to authenticate the user. In order to eliminate a scenario where a single certificate matching multiple Microsoft Entra accounts, the tenant administrator should:

+>- If a tenant has multiple binding methods configured and doesn't want to allow one certificate to multiple accounts, the tenant admin must ensure all allowable methods configured in the policy map to the same Microsoft Entra account, i.e all user accounts should have values matching all the bindings.

+For example, if the tenant admin has two username bindings on PrincipalName mapped to Microsoft Entra UPN and SubjectKeyIdentifier (SKI) to certificateUserIds and wants a certificate to only be used for a single Microsoft Entra account, the admin must make sure that account has the UPN that is present in the certificate and implements the SKI mapping in the same account certificateUserId attribute.

+Microsoft Entra User Principal Name = Bob.Smith@Contoso.com <br>

+Having both PrincipalName and SKI values from the user's certificate mapped to the same account ensures that while the tenant policy permits mapping PrincipalName to Microsoft Entra UPN & SKI values in certificateUserIds, that certificate can only match a single Microsoft Entra account. With unique constraint on both UserPrincipalName and certificateUserIds, no other user account can have the same values and can't successfully authenticate with the same certificate.

+Microsoft Entra ID downloads and caches the customers certificate revocation list (CRL) from their certificate authority to check if certificates are revoked during the authentication of the user.

+An admin can configure the CRL distribution point during the setup process of the trusted issuers in the Microsoft Entra tenant. Each trusted issuer should have a CRL that can be referenced by using an internet-facing URL.

+>The maximum size of a CRL for Microsoft Entra ID to successfully download on an interactive sign-in and cache is 20 MB in Azure Global and 45 MB in Azure US Government clouds, and the time required to download the CRL must not exceed 10 seconds. If Microsoft Entra ID can't download a CRL, certificate-based authentications using certificates issued by the corresponding CA will fail. As a best practice to keep CRL files within size limits, keep certificate lifetimes within reasonable limits and to clean up expired certificates. For more information, see [Is there a limit for CRL size?](certificate-based-authentication-faq.yml#is-there-a-limit-for-crl-size-).

+"The Certificate Revocation List (CRL) downloaded from {uri} has exceeded the maximum allowed size ({size} bytes) for CRLs in Microsoft Entra ID. Try again in few minutes. If the issue persists, contact your tenant administrators."

+After the error, Microsoft Entra ID will attempt to download the CRL subject to the service-side limits (45 MB in Azure Global and 150 MB in Azure US Government clouds).

+>If the admin skips the configuration of the CRL, Microsoft Entra ID will not perform any CRL checks during the certificate-based authentication of the user. This can be helpful for initial troubleshooting, but shouldn't be considered for production use.

+As of now, we don't support Online Certificate Status Protocol (OCSP) because of performance and reliability reasons. Instead of downloading the CRL at every connection by the client browser for OCSP, Microsoft Entra ID downloads once at the first sign-in and caches it, thereby improving the performance and reliability of CRL verification. We also index the cache so the search is much faster every time. Customers must publish CRLs for certificate revocation.

+1. Microsoft Entra ID will attempt to download the CRL at the first sign-in event of any user with a certificate of the corresponding trusted issuer or certificate authority.

+1. Microsoft Entra ID will cache and re-use the CRL for any subsequent usage. It will honor the **Next update date** and, if available, **Next CRL Publish date** (used by Windows Server CAs) in the CRL document.

+ - A CRL has been configured for the trusted issuer and Microsoft Entra ID can't download the CRL, due to availability, size, or latency constraints.

+ - Microsoft Entra ID will attempt to download a new CRL from the distribution point if the cached CRL document is expired.

+>Microsoft Entra ID will check the CRL of the issuing CA and other CAs in the PKI trust chain up to the root CA. We have a limit of up to 10 CAs from the leaf client certificate for CRL validation in the PKI chain. The limitation is to make sure a bad actor will not bring down the service by uploading a PKI chain with a huge number of CAs with a bigger CRL size.

+If the tenantΓÇÖs PKI chain has more than 5 CAs and in case of a CA compromise, the administrator should remove the compromised trusted issuer from the Microsoft Entra tenant configuration.

+>Due to the nature of CRL caching and publishing cycles, it is highly recommended in case of a certificate revocation to also revoke all sessions of the affected user in Microsoft Entra ID.

+Sign-in logs provide information about sign-ins and how your resources are used by your users. For more information about sign-in logs, see [Sign-in logs in Microsoft Entra ID](../reports-monitoring/concept-all-sign-ins.md).

+ The first entry requests the X.509 certificate from the user. The status **Interrupted** means that Microsoft Entra ID validated that CBA is enabled in the tenant and a certificate is requested for authentication.

+An external identity can't perform multifactor authentication to the resource tenant with Microsoft Entra CBA. Instead, have the user perform MFA using CBA in the home tenant, and set up cross tenant settings for the resource tenant to trust MFA from the home tenant.

+For more information about how to enable **Trust multifactor authentication from Microsoft Entra tenants**, see [Configure B2B collaboration cross-tenant access](../external-identities/cross-tenant-access-settings-b2b-collaboration.md#to-change-inbound-trust-settings-for-mfa-and-device-claims).

+- On iOS clients, there's a double prompt issue as part of the Microsoft Entra CBA flow where the user needs to click **Use the certificate or smart card** twice. We're aware of the UX experience issue and working on fixing this for a seamless UX experience.

+- [Overview of Microsoft Entra CBA](concept-certificate-based-authentication.md)

+- [How to configure Microsoft Entra CBA](how-to-certificate-based-authentication.md)

+- [Microsoft Entra CBA on iOS devices](concept-certificate-based-authentication-mobile-ios.md)

+- [Microsoft Entra CBA on Android devices](concept-certificate-based-authentication-mobile-android.md)

+- [Windows smart card logon using Microsoft Entra CBA](concept-certificate-based-authentication-smartcard.md)

+- [Troubleshoot Microsoft Entra CBA](./certificate-based-authentication-faq.yml)

+ Title: Overview of Microsoft Entra certificate-based authentication

+description: Learn about Microsoft Entra certificate-based authentication without federation

+# Overview of Microsoft Entra certificate-based authentication

+Microsoft Entra certificate-based authentication (CBA) enables customers to allow or require users to authenticate directly with X.509 certificates against their Microsoft Entra ID for applications and browser sign-in.

+<a name='what-is-azure-ad-cba'></a>

+## What is Microsoft Entra CBA?

+Before cloud-managed support for CBA to Microsoft Entra ID, customers had to implement federated certificate-based authentication, which requires deploying Active Directory Federation Services (AD FS) to be able to authenticate using X.509 certificates against Microsoft Entra ID. With Microsoft Entra certificate-based authentication, customers can authenticate directly against Microsoft Entra ID and eliminate the need for federated AD FS, with simplified customer environments and cost reduction.

+The following images show how Microsoft Entra CBA simplifies the customer environment by eliminating federated AD FS.

+**Microsoft Entra certificate-based authentication**

+<a name='key-benefits-of-using-azure-ad-cba'></a>

+## Key benefits of using Microsoft Entra CBA

+| Great user experience |- Users who need certificate-based authentication can now directly authenticate against Microsoft Entra ID and not have to invest in federated AD FS.<br>- Portal UI enables users to easily configure how to map certificate fields to a user object attribute to look up the user in the tenant ([certificate username bindings](concept-certificate-based-authentication-technical-deep-dive.md#understanding-the-username-binding-policy))<br>- Portal UI to [configure authentication policies](concept-certificate-based-authentication-technical-deep-dive.md#understanding-the-authentication-binding-policy) to help determine which certificates are single-factor versus multifactor. |

+| Easy to deploy and administer |- Microsoft Entra CBA is a free feature, and you don't need any paid editions of Microsoft Entra ID to use it. <br>- No need for complex on-premises deployments or network configuration.<br>- Directly authenticate against Microsoft Entra ID. |

+| Secure |- On-premises passwords don't need to be stored in the cloud in any form.<br>- Protects your user accounts by working seamlessly with Microsoft Entra Conditional Access policies, including Phishing-Resistant [multifactor authentication](concept-mfa-howitworks.md) (MFA requires [licensed edition](concept-mfa-licensing.md)) and blocking legacy authentication.<br>- Strong authentication support where users can define authentication policies through the certificate fields, such as issuer or policy OID (object identifiers), to determine which certificates qualify as single-factor versus multifactor.<br>- The feature works seamlessly with [Conditional Access features](../conditional-access/overview.md) and authentication strength capability to enforce MFA to help secure your users. |

+- Password as an authentication method cannot be disabled and the option to sign in using a password is displayed even with Microsoft Entra CBA method available to the user.

+- While Windows Hello For Business (WHFB) can be used for multi-factor authentication in Microsoft Entra ID, WHFB is not supported for fresh MFA. Customers may choose to enroll certificates for your users using the WHFB key pair. When properly configured, these WHFB certificates can be used for multi-factor authentication in Microsoft Entra ID. WHFB certificates are compatible with Microsoft Entra certificate-based authentication (CBA) in Edge and Chrome browsers; however, at this time WHFB certificates are not compatible with Microsoft Entra CBA in non-browser scenarios (e.g. Office 365 applications). The workaround is to use the "Sign in Windows Hello or security key" option to sign in (when available) as this option does not use certificates for authentication and avoids the issue with Microsoft Entra CBA; however, this option may not be available in some older applications.

+The following scenarios are out of scope for Microsoft Entra CBA:

+- [Technical deep dive for Microsoft Entra CBA](concept-certificate-based-authentication-technical-deep-dive.md)

+- [How to configure Microsoft Entra CBA](how-to-certificate-based-authentication.md)

+- [Microsoft Entra CBA on iOS devices](concept-certificate-based-authentication-mobile-ios.md)

+- [Microsoft Entra CBA on Android devices](concept-certificate-based-authentication-mobile-android.md)

+- [Windows smart card logon using Microsoft Entra CBA](concept-certificate-based-authentication-smartcard.md)

+ Title: Become a Microsoft-Compatible FIDO2 Security Key Vendor for sign-in to Microsoft Entra ID

+FIDO2 security keys offer an alternative. FIDO2 security keys can replace weak credentials with strong hardware-backed public/private-key credentials that can't be reused, replayed, or shared across services. Security keys support shared device scenarios, allowing you to carry your credential with you and safely authenticate to a Microsoft Entra joined Windows 10 device thatΓÇÖs part of your organization.

+4. Microsoft adds your FIDO2 Security Key on Microsoft Entra backend and to our list of approved FIDO2 vendors.

+ Title: Microsoft Entra multifactor authenticationentication Providers

+# When to use a Microsoft Entra multifactor authentication provider

+> 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. Multifactor authentication will continue to be available as a feature in Microsoft Entra ID P1 or P2 licenses.

+Two-step verification is available by default for Global Administrators who have Microsoft Entra ID, and Microsoft 365 users. However, if you wish to take advantage of [advanced features](howto-mfa-mfasettings.md) then you should purchase the full version of Microsoft Entra multifactor authentication.

+A Microsoft Entra multifactor authenticationentication Provider is used to take advantage of features provided by Microsoft Entra multifactor authentication for users who **do not have licenses**.

+There are two types of Auth providers, and the distinction is around how your Azure subscription is charged. The per-authentication option calculates the number of authentications performed against your tenant in a month. This option is best if some accounts authenticate only occasionally. The per-user option calculates the number of accounts that are eligible to perform MFA, which is all accounts in Microsoft Entra ID, and all enabled accounts in MFA Server. This option is best if some users have licenses but you need to extend MFA to more users beyond your licensing limits.

+If your MFA provider isn't linked to a Microsoft Entra tenant, or you link the new MFA provider to a different Microsoft Entra tenant, user settings and configuration options aren't transferred. Also, existing Azure MFA Servers need to be reactivated using activation credentials generated through the MFA Provider.

+Authentication providers can be found in the [Microsoft Entra admin center](https://entra.microsoft.com). Sign in as at least an [Authentication Policy Administrator](../roles/permissions-reference.md#authentication-policy-administrator). Browse to **Protection** > **multifactor authentication** > **Providers**. Click the listed providers to see details and configurations associated with that provider.

+[Configure multifactor authentication settings](howto-mfa-mfasettings.md)

+ Title: Microsoft Entra multifactor authentication data residency

+description: Learn what personal and organizational data Microsoft Entra multifactor authentication stores about you and your users and what data remains within the country/region of origin.

+# Data residency and customer data for Microsoft Entra multifactor authentication

+Microsoft Entra ID stores customer data in a geographical location based on the address an organization provides when subscribing to a Microsoft online service such as Microsoft 365 or Azure. For information on where your customer data is stored, see [Where your data is located](https://www.microsoft.com/trust-center/privacy/data-location) in the Microsoft Trust Center.

+Cloud-based Microsoft Entra multifactor authentication and MFA Server process and store personal data and organizational data. This article outlines what and where data is stored.

+The Microsoft Entra multifactor authentication service has datacenters in the United States, Europe, and Asia Pacific. The following activities originate from the regional datacenters except where noted:

+<a name='personal-data-stored-by-azure-ad-multifactor-authentication'></a>

+## Personal data stored by Microsoft Entra multifactor authentication

+* Multifactor authentication activity reportsΓÇöstore multifactor authentication activity from the multifactor authentication on-premises components: NPS Extension, AD FS adapter and MFA server.

+Microsoft Entra multifactor authentication doesn't log personal data such as usernames, phone numbers, or IP addresses. However, *UserObjectId* identifies authentication attempts to users. Log data is stored for 30 days.

+<a name='data-stored-by-azure-ad-multifactor-authentication'></a>

+### Data stored by Microsoft Entra multifactor authentication

+> In September 2022, Microsoft announced deprecation of Azure multifactor authentication Server. Beginning September 30, 2024, Azure multifactor authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Azure MFA service by using the latest Migration Utility included in the most recent [Azure MFA Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure MFA Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+<a name='organizational-data-stored-by-azure-ad-multifactor-authentication'></a>

+## Organizational data stored by Microsoft Entra multifactor authentication

+Organizational data is tenant-level information that can expose configuration or environment setup. Tenant settings from the multifactor authentication pages might store organizational data such as lockout thresholds or caller ID information for incoming phone authentication requests:

+* Multifactor authentication Server status

+| Cloud MFA | All methods | Any | Microsoft Entra sign-in logs in region | Cloud in-region |

+For more information about what user information is collected by cloud-based Microsoft Entra multifactor authentication and MFA Server, see [Microsoft Entra multifactor authentication user data collection](howto-mfa-reporting-datacollection.md).

+ Title: Microsoft Entra multifactor authentication overview

+description: Learn how Microsoft Entra multifactor authentication helps safeguard access to data and applications while meeting user demand for a simple sign-in process.

+# How it works: Microsoft Entra multifactor authentication

+Multifactor authentication is a process in which users are prompted during the sign-in process for an additional form of identification, such as a code on their cellphone or a fingerprint scan.

+

+Microsoft Entra multifactor authentication works by requiring two or more of the following authentication methods:

+Microsoft Entra multifactor authentication can also further secure password reset. When users register themselves for Microsoft Entra multifactor authentication, they can also register for self-service password reset in one step. Administrators can choose forms of secondary authentication and configure challenges for MFA based on configuration decisions.

+You don't need to change apps and services to use Microsoft Entra multifactor authentication. The verification prompts are part of the Microsoft Entra sign-in, which automatically requests and processes the MFA challenge when needed.

+The following additional forms of verification can be used with Microsoft Entra multifactor authentication:

+<a name='how-to-enable-and-use-azure-ad-multi-factor-authentication'></a>

+## How to enable and use Microsoft Entra multifactor authentication

+You can use [security defaults](../fundamentals/security-defaults.md) in Microsoft Entra tenants to quickly enable Microsoft Authenticator for all users. You can enable Microsoft Entra multifactor authentication to prompt users and groups for additional verification during sign-in.

+To learn about licensing, see [Features and licenses for Microsoft Entra multifactor authentication](concept-mfa-licensing.md).

+To learn more about different authentication and validation methods, see [Authentication methods in Microsoft Entra ID](concept-authentication-methods.md).

+To see MFA in action, enable Microsoft Entra multifactor authentication for a set of test users in the following tutorial:

+> [Enable Microsoft Entra multifactor authentication](./tutorial-enable-azure-mfa.md)

+ Title: Microsoft Entra multifactor authentication versions and consumption plans

+description: Learn about the Microsoft Entra multifactor authentication client and different methods and versions available.

+# Features and licenses for Microsoft Entra multifactor authentication

+To protect user accounts in your organization, multifactor authentication should be used. This feature is especially important for accounts that have privileged access to resources. Basic multifactor authentication features are available to Microsoft 365 and Microsoft Entra users and global administrators for no extra cost. If you want to upgrade the features for your admins or extend multifactor authentication to the rest of your users with more authentication methods and greater control, you can purchase Microsoft Entra multifactor authentication in several ways.

+> This article details the different ways that Microsoft Entra multifactor authentication can be licensed and used. For specific details about pricing and billing, see the [Microsoft Entra pricing page](https://www.microsoft.com/en-us/security/business/identity-access-management/azure-ad-pricing).

+<a name='available-versions-of-azure-ad-multi-factor-authentication'></a>

+## Available versions of Microsoft Entra multifactor authentication

+Microsoft Entra multifactor authentication can be used, and licensed, in a few different ways depending on your organization's needs. All tenants are entitled to basic multifactor authentication features via Security Defaults. You may already be entitled to use advanced Microsoft Entra multifactor authentication depending on the Microsoft Entra ID, EMS, or Microsoft 365 license you currently have. For example, the first 50,000 monthly active users in Microsoft Entra External ID can use MFA and other Premium P1 or P2 features for free. For more information, see [Microsoft Entra External ID pricing](https://azure.microsoft.com/pricing/details/active-directory/external-identities/).

+The following table details the different ways to get Microsoft Entra multifactor authentication and some of the features and use cases for each.

+| [Microsoft 365 Business Premium](https://www.microsoft.com/microsoft-365/business) and [EMS](https://www.microsoft.com/security/business/enterprise-mobility-security) or [Microsoft 365 E3 and E5](https://www.microsoft.com/microsoft-365/enterprise/compare-office-365-plans) | EMS E3, Microsoft 365 E3, and Microsoft 365 Business Premium includes Microsoft Entra ID P1. EMS E5 or Microsoft 365 E5 includes Microsoft Entra ID P2. You can use the same Conditional Access features noted in the following sections to provide multifactor authentication to users. |

+| [Microsoft Entra ID P1](../fundamentals/get-started-premium.md) | You can use [Microsoft Entra Conditional Access](../conditional-access/howto-conditional-access-policy-all-users-mfa.md) to prompt users for multifactor authentication during certain scenarios or events to fit your business requirements. |

+| [Microsoft Entra ID P2](../fundamentals/get-started-premium.md) | Provides the strongest security position and improved user experience. Adds [risk-based Conditional Access](../conditional-access/howto-conditional-access-policy-risk.md) to the Microsoft Entra ID P1 features that adapts to user's patterns and minimizes multifactor authentication prompts. |

+| [All Microsoft 365 plans](https://www.microsoft.com/microsoft-365/compare-microsoft-365-enterprise-plans) | Microsoft Entra multifactor authentication can be enabled for all users using [security defaults](../fundamentals/security-defaults.md). Management of Microsoft Entra multifactor authentication is through the Microsoft 365 portal. For an improved user experience, upgrade to Microsoft Entra ID P1 or P2 and use Conditional Access. For more information, see [secure Microsoft 365 resources with multifactor authentication](/microsoft-365/admin/security-and-compliance/set-up-multi-factor-authentication). |

+| [Office 365 free](https://www.microsoft.com/microsoft-365/enterprise/compare-office-365-plans)<br>[Microsoft Entra ID Free](../verifiable-credentials/how-to-create-a-free-developer-account.md) | You can use [security defaults](../fundamentals/security-defaults.md) to prompt users for multifactor authentication as needed but you don't have granular control of enabled users or scenarios, but it does provide that additional security step.<br /> Even when security defaults aren't used to enable multifactor authentication for everyone, users assigned the *Microsoft Entra Global Administrator* role can be configured to use multifactor authentication. This feature of the free tier makes sure the critical administrator accounts are protected by multifactor authentication. |

+The following table provides a list of the features that are available in the various versions of Microsoft Entra ID for multifactor authentication. Plan out your needs for securing user authentication, then determine which approach meets those requirements. For example, although Microsoft Entra ID Free provides security defaults that provide Microsoft Entra multifactor authentication where only the mobile authenticator app can be used for the authentication prompt. This approach may be a limitation if you can't ensure the mobile authentication app is installed on a user's personal device. See [Microsoft Entra ID Free tier](#azure-ad-free-tier) later in this topic for more details.

+| Feature | Microsoft Entra ID Free - Security defaults (enabled for all users) | Microsoft Entra ID Free - Global Administrators only | Office 365 | Microsoft Entra ID P1 | Microsoft Entra ID P2 |

+| Protect Microsoft Entra tenant admin accounts with MFA | ΓùÅ | ΓùÅ (*Microsoft Entra Global Administrator* accounts only) | ΓùÅ | ΓùÅ | ΓùÅ |

+<a name='compare-multi-factor-authentication-policies'></a>

+## Compare multifactor authentication policies

+<a name='purchase-and-enable-azure-ad-multi-factor-authentication'></a>

+## Purchase and enable Microsoft Entra multifactor authentication

+To use Microsoft Entra multifactor authentication, register for or purchase an eligible Microsoft Entra tier. Microsoft Entra ID comes in four editionsΓÇöFree, Office 365, Premium P1, and Premium P2.

+The Free edition is included with an Azure subscription. See the [section below](#azure-ad-free-tier) for information on how to use security defaults or protect accounts with the *Microsoft Entra Global Administrator* role.

+The Microsoft Entra ID P1 or P2 editions are available through your Microsoft representative, the [Open Volume License Program](https://www.microsoft.com/licensing/licensing-programs/open-license.aspx), and the [Cloud Solution Providers program](https://go.microsoft.com/fwlink/?LinkId=614968&clcid=0x409). Azure and Microsoft 365 subscribers can also buy Microsoft Entra ID P1 and P2 online. [Sign in](https://portal.office.com/Commerce/Catalog.aspx) to purchase.

+After you have purchased the required Microsoft Entra tier, [plan and deploy Microsoft Entra multifactor authentication](howto-mfa-getstarted.md).

+<a name='azure-ad-free-tier'></a>

+### Microsoft Entra ID Free tier

+All users in a Microsoft Entra ID Free tenant can use Microsoft Entra multifactor authentication by using security defaults. The mobile authentication app can be used for Microsoft Entra multifactor authentication when using Microsoft Entra ID Free security defaults.

+* [Learn more about Microsoft Entra security defaults](../fundamentals/security-defaults.md)

+* [Enable security defaults for users in Microsoft Entra ID Free](../fundamentals/security-defaults.md#enabling-security-defaults)

+If you don't want to enable Microsoft Entra multifactor authentication for all users, you can instead choose to only protect user accounts with the *Microsoft Entra Global Administrator* role. This approach provides more authentication prompts for critical administrator accounts. You enable Microsoft Entra multifactor authentication in one of the following ways, depending on the type of account you use:

+* If you use a Microsoft Account, [register for multifactor authentication](https://support.microsoft.com/help/12408/microsoft-account-about-two-step-verification).

+* If you aren't using a Microsoft Account, [turn on multifactor authentication for a user or group in Microsoft Entra ID](howto-mfa-userstates.md).

+* For more information on costs, see [Microsoft Entra pricing](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing).

+ Title: Regions that need to opt in for Microsoft Entra multifactor authentication telephony verification | Microsoft Entra ID

+description: To protect customers, some regions require a support ticket to request to opt in to receive MFA telephony verification Microsoft Entra ID

+* [Authentication methods in Microsoft Entra ID](concept-authentication-authenticator-app.md)

+ Title: Understanding telephony fraud risk for Microsoft Entra multifactor authentication | Microsoft Entra ID

+description: Understanding International Revenue Share Fraud (IRSF) is crucial for implementing preventive measures for Microsoft Entra multifactor authentication telephony verification.

+In today's digital landscape, telecommunication services have seamlessly integrated into our daily lives. But technological progress also brings the risk of fraudulent activities like International Revenue Share Fraud (IRSF), which poses financial consequences and service disruptions. IRSF involves exploiting telecommunication billing systems by unauthorized actors. They divert telephony traffic and generate profits through a technique called *traffic pumping*. Traffic pumping targets multifactor authentication systems, and causes inflated charges, service unreliability, and system errors.

+* [Authentication methods in Microsoft Entra ID](concept-authentication-authenticator-app.md)

+ Title: Combined password policy and check for weak passwords in Microsoft Entra ID

+description: Learn about the combined password policy and check for weak passwords in Microsoft Entra ID

+# Combined password policy and check for weak passwords in Microsoft Entra ID

+Beginning in October 2021, Microsoft Entra validation for compliance with password policies also includes a check for [known weak passwords](concept-password-ban-bad.md) and their variants.

+This topic explains details about the password policy criteria checked by Microsoft Entra ID.

+<a name='azure-ad-password-policies'></a>

+## Microsoft Entra password policies

+A password policy is applied to all user and admin accounts that are created and managed directly in Microsoft Entra ID. You can [ban weak passwords](concept-password-ban-bad.md) and define parameters to [lock out an account](howto-password-smart-lockout.md) after repeated bad password attempts. Other password policy settings can't be modified.

+The Microsoft Entra password policy doesn't apply to user accounts synchronized from an on-premises AD DS environment using Microsoft Entra Connect unless you enable EnforceCloudPasswordPolicyForPasswordSyncedUsers.

+The following Microsoft Entra password policy requirements apply for all passwords that are created, changed, or reset in Microsoft Entra ID. Requirements are applied during user provisioning, password change, and password reset flows. You can't change these settings except as noted.

+| Password isn't banned by [Microsoft Entra Password Protection](concept-password-ban-bad.md) | The password can't be on the global list of banned passwords for Microsoft Entra Password Protection, or on the customizable list of banned passwords specific to your organization. |

+Password expiration policies are unchanged but they're included in this topic for completeness. A *Global Administrator* or *User Administrator* can use the [Microsoft Entra Module for Windows PowerShell](/powershell/module/Azuread/) to set user passwords not to expire.

+> By default, only passwords for user accounts that aren't synchronized through Microsoft Entra Connect can be configured to not expire. For more information about directory synchronization, see [Connect AD with Microsoft Entra ID](../hybrid/connect/how-to-connect-password-hash-synchronization.md#password-expiration-policy).

+The following expiration requirements apply to other providers that use Microsoft Entra ID for identity and directory services, such as Microsoft Intune and Microsoft 365.

+| Password expiry duration (Maximum password age) |Default value: **90** days.<br>The value is configurable by using the `Set-MsolPasswordPolicy` cmdlet from the Microsoft Entra Module for Windows PowerShell. |

+- [Password policies and account restrictions in Microsoft Entra ID](concept-sspr-policy.md)

+- [Eliminate bad passwords using Microsoft Entra Password Protection](concept-password-ban-bad.md)

+ Title: Microsoft Entra Password Protection

+description: Ban weak passwords in on-premises Active Directory Domain Services environments by using Microsoft Entra Password Protection

+# Enforce on-premises Microsoft Entra Password Protection for Active Directory Domain Services

+Microsoft Entra Password Protection detects and blocks known weak passwords and their variants, and can also block additional weak terms that are specific to your organization. On-premises deployment of Microsoft Entra Password Protection uses the same global and custom banned password lists that are stored in Microsoft Entra ID, and does the same checks for on-premises password changes as Microsoft Entra ID does for cloud-based changes. These checks are performed during password changes and password reset events against on-premises Active Directory Domain Services (AD DS) domain controllers.

+Microsoft Entra Password Protection is designed with the following principles in mind:

+* The software isn't dependent on other Microsoft Entra features. For example, Microsoft Entra password hash sync (PHS) isn't related or required for Microsoft Entra Password Protection.

+Microsoft Entra Password Protection supports incremental deployment across DCs in an AD DS domain. It's important to understand what this really means and what the tradeoffs are.

+The Microsoft Entra Password Protection DC agent software can only validate passwords when it's installed on a DC, and only for password changes that are sent to that DC. It's not possible to control which DCs are chosen by Windows client machines for processing user password changes. To guarantee consistent behavior and universal Microsoft Entra Password Protection security enforcement, the DC agent software must be installed on all DCs in a domain.

+Many organizations want to carefully test Microsoft Entra Password Protection on a subset of their DCs prior to a full deployment. To support this scenario, Microsoft Entra Password Protection supports partial deployment. The DC agent software on a given DC actively validates passwords even when other DCs in the domain don't have the DC agent software installed. Partial deployments of this type aren't secure and aren't recommended other than for testing purposes.

+It's important to understand the underlying design and function concepts before you deploy Microsoft Entra Password Protection in an on-premises AD DS environment. The following diagram shows how the components of Microsoft Entra Password Protection work together:

+

+* The Microsoft Entra Password Protection Proxy service runs on any domain-joined machine in the current AD DS forest. The service's primary purpose is to forward password policy download requests from DCs to Microsoft Entra ID and then return the responses from Microsoft Entra ID to the DC.

+* The DC Agent service of Microsoft Entra Password Protection receives password-validation requests from the password filter DLL of the DC Agent. The DC Agent service processes them by using the current (locally available) password policy and returns the result of *pass* or *fail*.

+<a name='how-azure-ad-password-protection-works'></a>

+## How Microsoft Entra Password Protection works

+The on-premises Microsoft Entra Password Protection components work as follows:

+1. Each Microsoft Entra Password Protection Proxy service instance advertises itself to the DCs in the forest by creating a *serviceConnectionPoint* object in Active Directory.

+ Each DC Agent service for Microsoft Entra Password Protection also creates a *serviceConnectionPoint* object in Active Directory. This object is used primarily for reporting and diagnostics.

+1. The DC Agent service is responsible for initiating the download of a new password policy from Microsoft Entra ID. The first step is to locate a Microsoft Entra Password Protection Proxy service by querying the forest for proxy *serviceConnectionPoint* objects.

+1. When an available proxy service is found, the DC Agent sends a password policy download request to the proxy service. The proxy service in turn sends the request to Microsoft Entra ID, then returns the response to the DC Agent service.

+1. After the DC Agent service receives a new password policy from Microsoft Entra ID, the service stores the policy in a dedicated folder at the root of its domain *sysvol* folder share. The DC Agent service also monitors this folder in case newer policies replicate in from other DC Agent services in the domain.

+1. The DC Agent service always requests a new policy at service startup. After the DC Agent service is started, it checks the age of the current locally available policy hourly. If the policy is older than one hour, the DC Agent requests a new policy from Microsoft Entra ID via the proxy service, as described previously. If the current policy isn't older than one hour, the DC Agent continues to use that policy.

+* Whenever a Microsoft Entra Password Protection password policy is downloaded, that policy is specific to a tenant. In other words, password policies are always a combination of the Microsoft global banned-password list and the per-tenant custom banned-password list.

+* Microsoft Entra Password Protection isn't a real-time policy application engine. There can be a delay between when a password policy configuration change is made in Microsoft Entra ID and when that change reaches and is enforced on all DCs.

+* Microsoft Entra Password Protection acts as a supplement to the existing AD DS password policies, not a replacement. This includes any other 3rd-party password filter dlls that may be installed. AD DS always requires that all password validation components agree before accepting a password.

+<a name='forest--tenant-binding-for-azure-ad-password-protection'></a>

+## Forest / tenant binding for Microsoft Entra Password Protection

+Deployment of Microsoft Entra Password Protection in an AD DS forest requires registration of that forest with Microsoft Entra ID. Each proxy service that's deployed must also be registered with Microsoft Entra ID. These forest and proxy registrations are associated with a specific Microsoft Entra tenant, which is identified implicitly by the credentials that are used during registration.

+The AD DS forest and all deployed proxy services within a forest must be registered with the same tenant. It's not supported to have an AD DS forest or any proxy services in that forest being registered to different Microsoft Entra tenants. Symptoms of such a mis-configured deployment include the inability to download password policies.

+> Customers that have multiple Microsoft Entra tenants must therefore choose one distinguished tenant to register each forest for Microsoft Entra Password Protection purposes.

+The two required agent installers for Microsoft Entra Password Protection are available from the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=57071).

+To get started with using on-premises Microsoft Entra Password Protection, complete the following how-to:

+> [Deploy on-premises Microsoft Entra Password Protection](howto-password-ban-bad-on-premises-deploy.md)

+ Title: Password protection in Microsoft Entra ID

+description: Learn how to dynamically ban weak passwords from your environment with Microsoft Entra Password Protection

+# Eliminate bad passwords using Microsoft Entra Password Protection

+A lot of security guidance recommends that you don't use the same password in multiple places, to make it complex, and to avoid simple passwords like *Password123*. You can provide your users with [guidance on how to choose passwords](https://www.microsoft.com/research/publication/password-guidance), but weak or insecure passwords are often still used. Microsoft Entra Password Protection detects and blocks known weak passwords and their variants, and can also block additional weak terms that are specific to your organization.

+With Microsoft Entra Password Protection, default global banned password lists are automatically applied to all users in a Microsoft Entra tenant. To support your own business and security needs, you can define entries in a custom banned password list. When users change or reset their passwords, these banned password lists are checked to enforce the use of strong passwords.

+You should use additional features like [Microsoft Entra multifactor authentication](concept-mfa-howitworks.md), not just rely on strong passwords enforced by Microsoft Entra Password Protection. For more information on using multiple layers of security for your sign-in events, see [Your Pa$$word doesn't matter](https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Your-Pa-word-doesn-t-matter/ba-p/731984).

+> This conceptual article explains to an administrator how Microsoft Entra Password Protection works. If you're an end user already registered for self-service password reset and need to get back into your account, go to [https://aka.ms/sspr](https://aka.ms/sspr).

+The Microsoft Entra ID Protection team constantly analyzes Microsoft Entra security telemetry data looking for commonly used weak or compromised passwords. Specifically, the analysis looks for base terms that often are used as the basis for weak passwords. When weak terms are found, they're added to the *global banned password list*. The contents of the global banned password list aren't based on any external data source, but on the results of Microsoft Entra security telemetry and analysis.

+When a password is changed or reset for any user in a Microsoft Entra tenant, the current version of the global banned password list is used to validate the strength of the password. This validation check results in stronger passwords for all Microsoft Entra customers.

+The global banned password list is automatically applied to all users in a Microsoft Entra tenant. There's nothing to enable or configure, and can't be disabled. This global banned password list is applied to users when they change or reset their own password through Microsoft Entra ID.

+Microsoft Entra Password Protection helps you defend against password spray attacks. Most password spray attacks don't attempt to attack any given individual account more than a few times. This behavior would increase the likelihood of detection, either via account lockout or other means.

+Microsoft Entra Password Protection efficiently blocks all known weak passwords likely to be used in password spray attacks. This protection is based on real-world security telemetry data from Microsoft Entra ID to build the global banned password list.

+Although the global banned list is small in comparison to some third-party bulk lists, it's sourced from real-world security telemetry on actual password spray attacks. This approach improves the overall security and effectiveness, and the password validation algorithm also uses smart fuzzy-matching techniques. As a result, Microsoft Entra Password Protection efficiently detects and blocks millions of the most common weak passwords from being used in your enterprise.

+Many organizations have a hybrid identity model that includes on-premises Active Directory Domain Services (AD DS) environments. To extend the security benefits of Microsoft Entra Password Protection into your AD DS environment, you can install components on your on-premises servers. These agents require password change events in the on-premises AD DS environment to comply with the same password policy as in Microsoft Entra ID.

+For more information, see [Enforce Microsoft Entra Password Protection for AD DS](concept-password-ban-bad-on-premises.md).

+For the next two example scenarios, Contoso is using Microsoft Entra Password Protection and has "contoso" on their custom banned password list. Let's also assume that "blank" is on the global list.

+| Users | Microsoft Entra Password Protection with global banned password list | Microsoft Entra Password Protection with custom banned password list|

+| Cloud-only users | Microsoft Entra ID Free | Microsoft Entra ID P1 or P2 |

+| Users synchronized from on-premises AD DS | Microsoft Entra ID P1 or P2 | Microsoft Entra ID P1 or P2 |

+> On-premises AD DS users that aren't synchronized to Microsoft Entra ID also benefit from Microsoft Entra Password Protection based on existing licensing for synchronized users.

+Additional licensing information, including costs, can be found on the [Microsoft Entra pricing site](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing).

+You can also then [enable on-premises Microsoft Entra Password Protection](howto-password-ban-bad-on-premises-deploy.md).

+ Title: Combined registration for SSPR and Microsoft Entra multifactor authentication

+description: Learn about the combined registration experience for Microsoft Entra ID to let users register for both Microsoft Entra multifactor authentication and self-service password reset

+# Combined security information registration for Microsoft Entra overview

+Before combined registration, users registered authentication methods for Microsoft Entra multifactor authentication and self-service password reset (SSPR) separately. People were confused that similar methods were used for multifactor 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 multifactor authentication and SSPR. We recommend this video on [How to enable and configure SSPR in Microsoft Entra ID](https://www.youtube.com/watch?v=rA8TvhNcCvQ).

+Microsoft Entra ID combined security information registration is available for Azure US Government but not Microsoft Azure operated by 21Vianet.

+> App passwords are available only to users who have been enforced for per-user MFA. App passwords aren't available to users who are enabled for Microsoft Entra multifactor authentication by a Conditional Access policy.

+Third party authenticator apps don't provide push notification. As we continue to add more authentication methods to Microsoft Entra ID, those methods become available in combined registration.

+For both modes, users who have previously registered a method that can be used for Microsoft Entra multifactor authentication need to perform multifactor authentication before they can access their security info. Users must confirm their information before continuing to use their previously registered methods.

+- *multifactor authentication registration enforced through Identity Protection:* Users are asked to register during sign-in. They register multifactor authentication methods and SSPR methods (if the user is enabled for SSPR).

+- *multifactor authentication registration enforced through per-user multifactor authentication:* Users are asked to register during sign-in. They register multifactor authentication methods and SSPR methods (if the user is enabled for SSPR).

+- *multifactor authentication registration enforced through Conditional Access or other policies:* Users are asked to register when they use a resource that requires multifactor authentication. They register multifactor authentication methods and SSPR methods (if the user is enabled for SSPR).

+To secure when and how users register for Microsoft Entra multifactor authentication and self-service password reset, you can use user actions in Conditional Access policy. This functionality may be enabled in organizations that want users to register for Microsoft Entra multifactor authentication and SSPR from a central location, such as a trusted network location during HR onboarding. Learn more on how to configure [common Conditional Access policies for securing security info registration.](../conditional-access/howto-conditional-access-policy-registration.md)

+To get started, see the tutorials to [enable self-service password reset](tutorial-enable-sspr.md) and [enable Microsoft Entra multifactor authentication](tutorial-enable-azure-mfa.md).

+You can also review the [available methods for Microsoft Entra multifactor authentication and SSPR](concept-authentication-methods.md).

+# Create a resilient access control management strategy with Microsoft Entra ID

+Organizations that rely on a single access control, such as multifactor authentication 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.

+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 Microsoft Entra 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](../users-groups-roles/directory-emergency-access.md).

+- 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). The following PowerShell script will help you identify in advance, which additional methods your users should register: [Script for Microsoft Entra multifactor authentication authentication method analysis](/samples/azure-samples/azure-mfa-authentication-method-analysis/azure-mfa-authentication-method-analysis/).

+- Use trusted devices via [Microsoft Entra hybrid join](../devices/overview.md) or [Microsoft Intune](/intune/planning-guide). 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.

+- Use Microsoft Entra ID Protection risk-based policies that prevent access when the user or sign-in is at risk in place of fixed MFA policies.

+- If you are protecting VPN access using Microsoft Entra multifactor authentication NPS extension, consider federating your VPN solution as a [SAML app](../manage-apps/view-applications-portal.md) and determine the app category as recommended below.

+> Risk-based policies require [Microsoft Entra ID P2](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing) licenses.

+ * Grant Control: Grant access, require multifactor authentication, require device to be compliant. For multiple controls: Require one of the selected controls.

+A contingency Conditional Access policy is a **backup policy** that omits Microsoft Entra multifactor authentication, third-party MFA, risk-based or device-based controls. In order to minimize unexpected disruption when a contingency policy is enabled, the policy should remain in report-only mode when not in use. Administrators can monitor the potential impact of their contingency policies using the Conditional Access Insights workbook. When your organization decides to activate your contingency plan, administrators can enable the policy and disable the regular control-based policies.

+* Deploy [Microsoft Entra Self-Service Password Reset (SSPR)](./tutorial-enable-sspr.md) and [Microsoft Entra Password Protection](./howto-password-ban-bad-on-premises-deploy.md) to make sure users donΓÇÖt use common password and terms you choose to ban.

+The following example: **Example A - Contingency Conditional Access policy to restore Access to mission-critical Collaboration Apps**, is a typical corporate contingency. In this scenario, the organization typically requires MFA for all Exchange Online and SharePoint Online access, and the disruption in this case is the MFA provider for the customer has an outage (whether Microsoft Entra multifactor authentication, on-premises MFA provider, or third-party MFA). This policy mitigates this outage by allowing specific targeted users access to these apps from trusted Windows devices only when they are accessing the app from their trusted corporate network. It will also exclude emergency accounts and core administrators from these restrictions. The targeted users will then gain access to Exchange Online and SharePoint Online, while other users will still not have access to the apps due to the outage. This example will require a named network location **CorpNetwork** and a security group **ContingencyAccess** with the target users, a group named **CoreAdmins** with the core administrators, and a group named **EmergencyAccess** with the emergency access accounts. The contingency requires four policies to provide the desired access.

+ * Name: EM001 - ENABLE IN EMERGENCY: MFA Disruption[1/4] - Exchange SharePoint - Require Microsoft Entra hybrid join

+In this next example, **Example B - Contingency Conditional Access policies to allow mobile access to Salesforce**, a business appΓÇÖs access is restored. In this scenario, the customer typically requires their sales employees access to Salesforce (configured for single-sign on with Microsoft Entra ID) from mobile devices to only be allowed from compliant devices. The disruption in this case is that there is an issue with evaluating device compliance and the outage is happening at a sensitive time where the sales team needs access to Salesforce to close deals. These contingency policies will grant critical users access to Salesforce from a mobile device so that they can continue to close deals and not disrupt the business. In this example, **SalesforceContingency** contains all the Sales employees who need to retain access and **SalesAdmins** contains necessary admins of Salesforce.

+If you are protecting VPN access using Microsoft Entra multifactor authentication NPS extension, consider federating your VPN solution as a [SAML app](../manage-apps/view-applications-portal.md) and determine the app category as recommended below.

+If you have deployed Microsoft Entra multifactor authentication NPS extension to protect on-prem resources, such as VPN and Remote Desktop Gateway, with MFA - you should consider in advance if you are ready to disable MFA in a case of emergency.

+ Enable password hash sync using the Microsoft Entra Connect wizard, regardless whether your organization uses federation or pass-through authentication.

+ > Configuring [trusted IPs](./howto-mfa-mfasettings.md) for Microsoft Entra multifactor authentication is only available with [Microsoft Entra ID P1 or P2 licenses](./concept-mfa-licensing.md).

+* [Microsoft Entra authentication Documentation](./howto-mfaserver-iis.md)

+* [Manage emergency-access administrative accounts in Microsoft Entra ID](../roles/security-emergency-access.md)

+* [Configure named locations in Microsoft Entra ID](../conditional-access/location-condition.md)

+* [How to configure Microsoft Entra hybrid joined devices](../devices/hybrid-join-plan.md)

+* [What are conditions in Microsoft Entra Conditional Access?](../conditional-access/concept-conditional-access-conditions.md)

+* [What are access controls in Microsoft Entra Conditional Access?](../conditional-access/controls.md)

+# How it works: Microsoft Entra self-service password reset

+Microsoft Entra self-service password reset (SSPR) gives users the ability to change or reset their password, with no administrator or help desk involvement. If a user's account is locked or they forget their password, they can follow prompts to unblock themselves and get back to work. This ability reduces help desk calls and loss of productivity when a user can't sign in to their device or an application. We recommend this video on [how to enable and configure SSPR in Microsoft Entra ID](https://www.youtube.com/watch?v=rA8TvhNcCvQ).

+After the SSPR portal is displayed in the required language, the user is prompted to enter a user ID and pass a captcha. Microsoft Entra ID now verifies that the user is able to use SSPR by doing the following checks:

+* Checks to see if the user's password is managed on-premises, such as if the Microsoft Entra tenant is using federated, pass-through authentication, or password hash synchronization:

+You can enable the option to require a user to complete the SSPR registration if they use modern authentication or web browser to sign in to any applications using Microsoft Entra ID. This workflow includes the following applications:

+* Custom applications using Microsoft Entra ID

+If this option is set to **Yes**, 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 stored in Microsoft Entra ID. If no primary or alternate email address is defined SSPR will attempt email notification via the users User Principal Name (UPN). No one else is notified of the reset event.

+If this option is set to **Yes**, then all other Azure administrators receive an email to their primary email address stored in Microsoft Entra ID. The email notifies them that another administrator has changed their password by using SSPR.

+If you have a hybrid environment, you can configure Microsoft Entra Connect to write password change events back from Microsoft Entra ID to an on-premises directory.

+Microsoft Entra ID checks your current hybrid connectivity and provides one of the following messages in the Microsoft Entra admin center:

+* Microsoft Entra ID is online and is connected to your on-premises writeback client. However, it looks like the installed version of Microsoft Entra Connect is out-of-date. Consider [Upgrading Microsoft Entra Connect](../hybrid/connect/how-to-upgrade-previous-version.md) 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 Microsoft Entra Connect is out-of-date. [Upgrade Microsoft Entra Connect](../hybrid/connect/how-to-upgrade-previous-version.md) 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 Microsoft Entra Connect](./troubleshoot-sspr-writeback.md) 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 Microsoft Entra Connect](./troubleshoot-sspr-writeback.md) to restore the connection.

+You can enable password writeback using the Microsoft Entra admin center. You can also temporarily disable password writeback without having to reconfigure Microsoft Entra Connect.

+By default, Microsoft Entra ID unlocks accounts when it performs a password reset. To provide flexibility, you can choose to allow users to unlock their on-premises accounts without having to reset their password. Use this setting to separate those two operations.

+SSPR performs the equivalent of an admin-initiated password reset in Active Directory. If you use a third-party password filter to enforce custom password rules, and you require that this password filter is checked during Microsoft Entra self-service password reset, ensure that the third-party password filter solution is configured to apply in the admin password reset scenario. [Microsoft Entra password protection for Active Directory Domain Services](concept-password-ban-bad-on-premises.md) is supported by default.

+* **Users from a partner organization with an existing Microsoft Entra tenant**: If the organization you partner with has an existing Microsoft Entra tenant, we respect whatever password reset policies are enabled on that tenant. For password reset to work, the partner organization just needs to make sure that Microsoft Entra SSPR is enabled. There is no additional charge for Microsoft 365 customers.

+* **B2B users**: Any new B2B users created by using the new [Microsoft Entra B2B capabilities](../external-identities/what-is-b2b.md) can also reset their passwords with the email they registered during the invite process.

+> Microsoft accounts that have been granted guest access to your Microsoft Entra tenant, such as those from Hotmail.com, Outlook.com, or other personal email addresses, aren't able to use Microsoft Entra SSPR. They need to reset their password by using the information found in the [When you can't sign in to your Microsoft account](https://support.microsoft.com/help/12429/microsoft-account-sign-in-cant) article.

+description: Learn about the difference Microsoft Entra self-service password reset licensing requirements

+# Licensing requirements for Microsoft Entra self-service password reset

+To reduce help desk calls and loss of productivity when a user can't sign in to their device or an application, user accounts in Microsoft Entra ID can be enabled for self-service password reset (SSPR). Features that make up SSPR include password change, reset, unlock, and writeback to an on-premises directory. Basic SSPR features are available in Microsoft 365 Business Standard or higher and all Microsoft Entra ID P1 or P2 SKUs at no cost.

+This article details the different ways that self-service password reset can be licensed and used. For specific details about pricing and billing, see the [Microsoft Entra pricing page](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing).

+| Feature | Microsoft Entra ID Free | Microsoft 365 Business Standard | Microsoft 365 Business Premium | Microsoft Entra ID P1 or P2 |

+| **Cloud-only user password change**<br />When a user in Microsoft Entra ID knows their password and wants to change it to something new. | ΓùÅ | ΓùÅ | ΓùÅ | ΓùÅ |

+| **Cloud-only user password reset**<br />When a user in Microsoft Entra ID has forgotten their password and needs to reset it. | | ΓùÅ | ΓùÅ | ΓùÅ |

+| **Hybrid user password change or reset with on-prem writeback**<br />When a user in Microsoft Entra that's synchronized from an on-premises directory using Microsoft Entra Connect wants to change or reset their password and also write the new password back to on-prem. | | | ΓùÅ | ΓùÅ |

+> Standalone Microsoft 365 Basic and Standard licensing plans don't support SSPR with on-premises writeback. The on-premises writeback feature requires Microsoft Entra ID P1, Premium P2, or Microsoft 365 Business Premium.

+* [Microsoft Entra pricing](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing)

+* [Microsoft Entra features and capabilities](https://www.microsoft.com/cloud-platform/azure-active-directory-features)

+description: Learn about the different Microsoft Entra self-service password reset policy options

+# Password policies and account restrictions in Microsoft Entra ID

+In Microsoft Entra ID, there's a password policy that defines settings like the password complexity, length, or age. There's also a policy that defines acceptable characters and length for usernames.

+When self-service password reset (SSPR) is used to change or reset a password in Microsoft Entra ID, the password policy is checked. If the password doesn't meet the policy requirements, the user is prompted to try again. Azure administrators have some restrictions on using SSPR that are different to regular user accounts, and there are minor exceptions for trial and free versions of Microsoft Entra ID.

+Every account that signs in to Microsoft Entra ID must have a unique user principal name (UPN) attribute value associated with their account. In hybrid environments with an on-premises Active Directory Domain Services (AD DS) environment synchronized to Microsoft Entra ID using Microsoft Entra Connect, by default the Microsoft Entra UPN is set to the on-premises UPN.

+The following table outlines the username policies that apply to both on-premises AD DS accounts that are synchronized to Microsoft Entra ID, and for cloud-only user accounts created directly in Microsoft Entra ID:

+<a name='azure-ad-password-policies'></a>

+## Microsoft Entra password policies

+A password policy is applied to all user accounts that are created and managed directly in Microsoft Entra ID. Some of these password policy settings can't be modified, though you can [configure custom banned passwords for Microsoft Entra password protection](tutorial-configure-custom-password-protection.md) or account lockout parameters.

+The Microsoft Entra password policy doesn't apply to user accounts synchronized from an on-premises AD DS environment using Microsoft Entra Connect, unless you enable *EnforceCloudPasswordPolicyForPasswordSyncedUsers*.

+The following Microsoft Entra password policy options are defined. Unless noted, you can't change these settings:

+| Password expiry duration (Maximum password age) |Default value: **90** days. If the tenant was created after 2021, it has no default expiration value. You can check current policy with [Get-MsolPasswordPolicy](/powershell/module/msonline/get-msolpasswordpolicy).<br>The value is configurable by using the `Set-MsolPasswordPolicy` cmdlet from the Microsoft Entra Module for Windows PowerShell.|

+The two-gate policy requires two pieces of authentication data, such as an email address, authenticator app, or a phone number, and it prohibits security questions. Office and mobile voice calls are also prohibited for trial or free versions of Microsoft Entra ID.

+* A custom domain has been configured for your Microsoft Entra tenant, such as *contoso.com*; or

+* Microsoft Entra Connect is synchronizing identities from your on-premises directory

+- A custom domain isn't configured (the tenant is using the default **.onmicrosoft.com*, which isn't recommended for production use) and Microsoft Entra Connect isn't synchronizing identities.

+A *Global Administrator* or *User Administrator* can use the [Microsoft Entra Module for Windows PowerShell](/powershell/module/Azuread/) to set user passwords not to expire.

+This guidance applies to other providers, such as Intune and Microsoft 365, which also rely on Microsoft Entra ID for identity and directory services. Password expiration is the only part of the policy that can be changed.

+> By default only passwords for user accounts that aren't synchronized through Microsoft Entra Connect can be configured to not expire. For more information about directory synchronization, see [Connect AD with Microsoft Entra ID](../hybrid/connect/how-to-connect-password-hash-synchronization.md#password-expiration-policy).

+To get started, [download and install the Azure AD PowerShell module](/powershell/module/Azuread/) and [connect it to your Microsoft Entra tenant](/powershell/module/azuread/connect-azuread#examples).

+1. Open a PowerShell prompt and [connect to your Microsoft Entra tenant](/powershell/module/azuread/connect-azuread#examples) using a *Global Administrator* or *User Administrator* account.

+1. Open a PowerShell prompt and [connect to your Microsoft Entra tenant](/powershell/module/azuread/connect-azuread#examples) using a *Global Administrator* or *User Administrator* account.

+1. Open a PowerShell prompt and [connect to your Microsoft Entra tenant](/powershell/module/azuread/connect-azuread#examples) using a *Global Administrator* or *User Administrator* account.

+To get started with SSPR, see [Tutorial: Enable users to unlock their account or reset passwords using Microsoft Entra self-service password reset](tutorial-enable-sspr.md).

+description: Learn how password change or reset events in Microsoft Entra ID can be written back to an on-premises directory environment

+# How does self-service password reset writeback work in Microsoft Entra ID?

+Microsoft Entra self-service password reset (SSPR) lets users reset their passwords in the cloud, but most companies also have an on-premises Active Directory Domain Services (AD DS) environment for users. Password writeback allows password changes in the cloud to be written back to an on-premises directory in real time by using either [Microsoft Entra Connect](../hybrid/whatis-hybrid-identity.md) or [Microsoft Entra Connect cloud sync](tutorial-enable-cloud-sync-sspr-writeback.md). When users change or reset their passwords using SSPR in the cloud, the updated passwords also written back to the on-premises AD DS environment.

+* **Supports side-by-side domain-level deployment** using [Microsoft Entra Connect](tutorial-enable-sspr-writeback.md) or [cloud sync](tutorial-enable-cloud-sync-sspr-writeback.md) to target different sets of users depending on their needs, including users who are in disconnected domains.

+- [Tutorial: Enable Microsoft Entra Connect cloud sync self-service password reset writeback to an on-premises environment (Preview)](tutorial-enable-cloud-sync-sspr-writeback.md)

+<a name='azure-ad-connect-and-cloud-sync-side-by-side-deployment'></a>

+## Microsoft Entra Connect and cloud sync side-by-side deployment

+You can deploy Microsoft Entra Connect and cloud sync side-by-side in different domains to target different sets of users. This helps existing users continue to writeback password changes while adding the option in cases where users are in disconnected domains because of a company merger or split. Microsoft Entra Connect and cloud sync can be configured in different domains so users from one domain can use Microsoft Entra Connect while users in another domain use cloud sync. Cloud sync can also provide higher availability because it doesn't rely on a single instance of Microsoft Entra Connect. For a feature comparison between the two deployment options, see [Comparison between Microsoft Entra Connect and cloud sync](../hybrid/cloud-sync/what-is-cloud-sync.md#comparison-between-azure-ad-connect-and-cloud-sync).

+When a user account configured for federation, password hash synchronization (or, in the case of a Microsoft Entra Connect deployment, pass-through authentication) attempts to reset or change a password in the cloud, the following actions occur:

+ * The user object must be linked to the corresponding Microsoft Entra connector object.

+ When the call comes in from the cloud, the synchronization engine uses the **cloudAnchor** attribute to look up the Microsoft Entra connector space object. It then follows the link back to the MV object, and then follows the link back to the AD DS object. Because there can be multiple AD DS objects (multi-forest) for the same user, the sync engine relies on the `Microsoft.InfromADUserAccountEnabled.xxx` link to pick the correct one.

+ > If the user's password hash is synchronized to Microsoft Entra ID by using password hash synchronization, there's 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.

+1. **Automatic key rollover every six months**: All keys roll over every six months, or every time password writeback is disabled and then re-enabled on Microsoft Entra Connect, to ensure maximum service security and safety.

+* Two messages are sent when the feature is enabled or disabled through Microsoft Entra Connect.

+> Use of the checkbox "User must change password at next logon" in on-premises AD DS administrative tools like Active Directory Users and Computers or the Active Directory Administrative Center is supported as a preview feature of Microsoft Entra Connect. For more information, see [Implement password hash synchronization with Microsoft Entra Connect Sync](../hybrid/connect/how-to-connect-password-hash-synchronization.md).

+# Customer intent: As an identity administrator, I want to encourage users to use the Microsoft Authenticator app in Microsoft Entra ID to improve and secure user sign-in events.

+| State | advancedConfigState | Possible values are:<br>**enabled** explicitly enables the feature for the selected group.<br>**disabled** explicitly disables the feature for the selected group.<br>**default** allows Microsoft Entra ID to manage whether the feature is enabled or not for the selected group. |

+* [Authentication methods in Microsoft Entra ID](concept-authentication-authenticator-app.md)

+ Title: Microsoft Entra multifactor authentication prompts and session lifetime

+description: Learn about the recommended configuration for reauthentication prompts with Microsoft Entra multifactor authentication and how session lifetime is applied.

+# Optimize reauthentication prompts and understand session lifetime for Microsoft Entra multifactor authentication

+Microsoft Entra ID has multiple settings that determine how often users need to reauthenticate. This reauthentication could be with a first factor such as password, FIDO, or passwordless Microsoft Authenticator, or to perform multifactor authentication. You can configure these reauthentication settings as needed for your own environment and the user experience you want.

+The Microsoft Entra ID default configuration for user sign-in frequency is a rolling window of 90 days. Asking users for credentials often seems like a sensible thing to do, but it can backfire. If users are trained to enter their credentials without thinking, they can unintentionally supply them to a malicious credential prompt.

+* If you have Microsoft Entra ID P1 or P2:

+* If you have Microsoft 365 apps licenses or the free Microsoft Entra tier:

+* For mobile devices scenarios, make sure your users use the Microsoft Authenticator app. This app is used as a broker to other Microsoft Entra ID federated apps, and reduces authentication prompts on the device.

+<a name='azure-ad-session-lifetime-configuration-settings'></a>

+## Microsoft Entra session lifetime configuration settings

+To optimize the frequency of authentication prompts for your users, you can configure Microsoft Entra session lifetime options. Understand the needs of your business and users, and configure settings that provide the best balance for your environment.

+A user might see multiple MFA prompts on a device that doesn't have an identity in Microsoft Entra ID. Multiple prompts result when each application has its own OAuth Refresh Token that isn't shared with other client apps. In this scenario, MFA prompts multiple times as each application requests an OAuth Refresh Token to be validated with MFA.

+In Microsoft Entra ID, the most restrictive policy for session lifetime determines when the user needs to reauthenticate. Consider the following scenario:

+Devices joined to Microsoft Entra ID using Microsoft Entra join or Microsoft Entra hybrid join receive a [Primary Refresh Tokens (PRT)](../devices/concept-primary-refresh-token.md) to use single sign-on (SSO) across applications. This PRT lets a user sign in once on the device and allows IT staff to make sure that standards for security and compliance are met. If a user needs to be asked to sign in more frequently on a joined device for some apps or scenarios, this can be achieved using [Conditional Access Sign-in Frequency](../conditional-access/howto-conditional-access-session-lifetime.md).

+If you have a Microsoft Entra ID P1 or P2 1 license, we recommend using Conditional Access policy for *Persistent browser session*. This policy overwrites the *Stay signed in?* setting and provides an improved user experience. If you don't have a Microsoft Entra ID P1 or P2 1 license, we recommend enabling the stay signed in setting for your users.

+<a name='remember-multi-factor-authentication--'></a>

+### Remember multifactor authentication

+If you use *Remember MFA* and have Microsoft Entra ID P1 or P2 1 licenses, consider migrating these settings to Conditional Access Sign-in Frequency. Otherwise, consider using *Keep me signed in?* instead.

+More information, see [Remember multifactor authentication](howto-mfa-mfasettings.md#remember-multi-factor-authentication).

+This setting allows configuration of lifetime for token issued by Microsoft Entra ID. This policy is replaced by *Authentication session management with Conditional Access*. If you are using *Configurable token lifetimes* today, we recommend starting the migration to the Conditional Access policies.

+1. Browse to **Protection** > then **multifactor authentication**.

+1. In the *multifactor authentication service settings* page, scroll to **remember multifactor authentication settings**. Disable the setting by unchecking the checkbox.

+To review token lifetimes, [use Azure AD PowerShell to query any Microsoft Entra policies](../develop/configure-token-lifetimes.md#get-started). Disable any policies that you have in place.

+If more than one setting is enabled in your tenant, we recommend updating your settings based on the licensing available for you. For example, if you have Microsoft Entra ID P1 or P2 licenses you should only use the Conditional Access policy of *Sign-in Frequency* and *Persistent browser session*. If you have Microsoft 365 apps or Microsoft Entra ID Free licenses, you should use the *Remain signed-in?* configuration.

+| | Microsoft Entra ID Free and Microsoft 365 apps | Microsoft Entra ID P1 or P2 |

+| **SSO** | [Microsoft Entra join](../devices/concept-directory-join.md) or [Microsoft Entra hybrid join](../devices/concept-hybrid-join.md), or [Seamless SSO](../hybrid/connect/how-to-connect-sso.md) for unmanaged devices. | Microsoft Entra join<br />Microsoft Entra hybrid join |

+To get started, complete the tutorial to [Secure user sign-in events with Microsoft Entra multifactor authentication](tutorial-enable-azure-mfa.md) or [Use risk detections for user sign-ins to trigger Microsoft Entra multifactor authentication](tutorial-risk-based-sspr-mfa.md).

+ Title: Microsoft Entra feature availability in Azure Government

+description: Learn which Microsoft Entra features are available in Azure Government.

+# Microsoft Entra feature availability

+This following tables list Microsoft Entra feature availability in Azure Government.

+<a name='azure-active-directory'></a>

+## Microsoft Entra ID

+|**Applications access**|SaaS apps with modern authentication (Microsoft Entra application gallery apps, SAML, and OAUTH 2.0) | &#x2705; |

+|| Directory synchronizationΓÇöMicrosoft Entra Connect (sync and cloud sync) | &#x2705; |

+|| Microsoft Entra Connect Health reporting | &#x2705; |

+|Microsoft Entra threat intelligence | &#10060; |

+|Workday to Microsoft Entra User Provisioning | &#x2705; |

+|SuccessFactors to Microsoft Entra User Provisioning | &#x2705; |

+ Title: Browser support of FIDO2 passwordless authentication | Microsoft Entra ID

+description: Browsers and operating system combinations support FIDO2 passwordless authentication for apps using Microsoft Entra ID

+Microsoft Entra ID allows [FIDO2 security keys](./concept-authentication-passwordless.md#fido2-security-keys) to be used as a passwordless device. The availability of FIDO2 authentication for Microsoft accounts was [announced in 2018](https://techcommunity.microsoft.com/t5/identity-standards-blog/all-about-fido2-ctap2-and-webauthn/ba-p/288910), and it became [generally available](https://techcommunity.microsoft.com/t5/azure-active-directory-identity/passwordless-authentication-is-now-generally-available/ba-p/1994700) in March 2021. The following diagram shows which browsers and operating system combinations support passwordless authentication using FIDO2 authentication keys with Microsoft Entra ID. Microsoft Entra ID currently supports only hardware FIDO2 keys and doesn't support passkeys for any platform.

+This table shows support for authenticating Microsoft Entra ID and Microsoft Accounts (MSA). Microsoft accounts are created by consumers for services such as Xbox, Skype, or Outlook.com.

+¹Security key biometrics or PIN for user verficiation isn't currently supported on Android by Google. Microsoft Entra ID requires user verification for all FIDO2 authentications.

+ Title: Find and address gaps in strong authentication coverage for your administrators in Microsoft Entra ID

+description: Learn how to find and address gaps in strong authentication coverage for your administrators in Microsoft Entra ID

+<a name='detect-current-usage-for-azure-ad-built-in-administrator-roles'></a>

+## Detect current usage for Microsoft Entra Built-in administrator roles

+The [Microsoft Entra ID Secure Score](../fundamentals/identity-secure-score.md) provides a score for **Require MFA for administrative roles** in your tenant. This improvement action tracks the MFA usage of Global administrator, Security administrator, Exchange administrator, and SharePoint administrator.

+- If your administrators are licensed for Microsoft Entra ID P1 or P2, you can [create a Conditional Access policy](tutorial-enable-azure-mfa.md) to enforce MFA for administrators. You can also update this policy to require MFA from users who are in custom roles.

+You can read more about these authentication methods and their security considerations in [Microsoft Entra authentication methods](concept-authentication-methods.md).

+description: Learn about how to centrally manage multifactor authentication and self-service password reset (SSPR) settings in the Authentication methods policy.

+# Customer intent: As an identity administrator, I want to understand what authentication options are available in Microsoft Entra ID and how I can manage them.

+# How to migrate MFA and SSPR policy settings to the Authentication methods policy for Microsoft Entra ID

+You can migrate Microsoft Entra ID [legacy policy settings](concept-authentication-methods-manage.md#legacy-mfa-and-sspr-policies) that separately control multifactor authentication and self-service password reset (SSPR) to unified management with the [Authentication methods policy](./concept-authentication-methods-manage.md).

+For more information about how these policies work together during migration, see [Manage authentication methods for Microsoft Entra ID](concept-authentication-methods-manage.md).

+Start by documenting which methods are available in the legacy MFA policy. Sign in to the [Azure portal](https://portal.azure.com) as a [Global Administrator](../roles/permissions-reference.md#global-administrator). Go to **Microsoft Entra ID** > **Users** > **All users** > **Per-user MFA** > **service settings** to view the settings. These settings are tenant-wide, so there's no need for user or group information.

+To get the authentication methods available in the legacy SSPR policy, go to **Microsoft Entra ID** > **Users** > **Password reset** > **Authentication methods**. The following table lists the available methods in the legacy SSPR policy and corresponding methods in the Authentication method policy.

+The Authentication methods policy has other methods that aren't available in the legacy policies, such as FIDO2 security key, Temporary Access Pass, and Microsoft Entra certificate-based authentication. These methods aren't in scope for migration and you won't need to make any changes to them if you've configured them already.

+When you determine that MFA and SSPR work as expected and you no longer need the legacy MFA and SSPR policies, you can change the migration process to **Migration Complete**. In this mode, Microsoft Entra-only follows the Authentication methods policy. No changes can be made to the legacy policies if **Migration Complete** is set, except for security questions in the SSPR policy. If you need to go back to the legacy policies for some reason, you can move the migration state back to **Migration in Progress** at any time.

+- [Manage authentication methods for Microsoft Entra ID](concept-authentication-methods-manage.md)

+- [What authentication and verification methods are available in Microsoft Entra ID?](concept-authentication-methods.md)

+- [How Microsoft Entra multifactor authentication works](concept-mfa-howitworks.md)

+ Title: App support for SMS-based authentication in Microsoft Entra ID

+description: Learn which apps are supported for users to sign in to Microsoft Entra ID using SMS

+SMS-based authentication is available to Microsoft apps integrated with the Microsoft identity platform (Microsoft Entra ID). The table lists some of the web and mobile apps that support SMS-based authentication. If you would like to add or validate any app, [contact us](https://feedback.azure.com/d365community/forum/22920db1-ad25-ec11-b6e6-000d3a4f0789).

+- Integrate Non-Microsoft web apps with Microsoft Entra ID and use Microsoft Entra authentication. Use Security Assertion Markup Language [SAML](../manage-apps/add-application-portal-setup-sso.md) or OpenID Connect [OIDC](../manage-apps/add-application-portal-setup-oidc-sso.md) to integrate with Microsoft Entra SSO.

+- Integrate Non-Microsoft on-prem apps with Microsoft Entra ID using [Microsoft Entra application proxy](../app-proxy/application-proxy-add-on-premises-application.md)

+- Integrate Non-Microsoft client apps with [Microsoft identity platform](../develop/v2-overview.md) for authentication

+- [Integrate SAAS application with Microsoft Entra ID](../saas-apps/tutorial-list.md)

+- [Add an application to your Microsoft Entra ID](../manage-apps/add-application-portal.md)

+- [Overview of MSAL libraries to acquire token from Microsoft identity platform to authenticate users](../develop/msal-overview.md)

+- [Configure Microsoft Managed Home Screen with Microsoft Entra ID](/mem/intune/apps/app-configuration-managed-home-screen-app)

+Two-way SMS for Microsoft Entra multifactor authentication Server was originally deprecated in 2018, and no longer supported after February 24, 2021, except for organizations that received a support extension until August 2, 2021. Administrators should enable another method for users who still use two-way SMS.

+ Title: How to configure Microsoft Entra certificate-based authentication

+description: Topic that shows how to configure Microsoft Entra certificate-based authentication in Microsoft Entra ID

+# How to configure Microsoft Entra certificate-based authentication

+Microsoft Entra certificate-based authentication (CBA) enables organizations to configure their Microsoft Entra tenants to allow or require users to authenticate with X.509 certificates created by their Enterprise Public Key Infrastructure (PKI) for app and browser sign-in. This feature enables organizations to adopt phishing-resistant modern passwordless authentication by using an x.509 certificate.

+Follow these instructions to configure and use Microsoft Entra CBA for tenants in Office 365 Enterprise and US Government plans. You should already have a [public key infrastructure (PKI)](https://aka.ms/securingpki) configured.

+- Configure at least one certification authority (CA) and any intermediate CAs in Microsoft Entra ID.

+- The user must have access to a user certificate (issued from a trusted Public Key Infrastructure configured on the tenant) intended for client authentication to authenticate against Microsoft Entra ID.

+- Each CA should have a certificate revocation list (CRL) that can be referenced from internet-facing URLs. If the trusted CA doesn't have a CRL configured, Microsoft Entra ID won't perform any CRL checking, revocation of user certificates won't work, and authentication won't be blocked.

+>When evaluating a PKI, it is important to review certificate issuance policies and enforcement. As mentioned, adding certificate authorities (CAs) to Microsoft Entra configuration allows certificates issued by those CAs to authenticate any user in Microsoft Entra ID. For this reason, it is important to consider how and when the CAs are allowed to issue certificates, and how they implement reusable identifiers. Where administrators need to ensure only a specific certificate is able to be used to authenticate a user, admins should exclusively use high-affinity bindings to achieve a higher level of assurance that only a specific certificate is able to authenticate the user. For more information, see [high-affinity bindings](concept-certificate-based-authentication-technical-deep-dive.md#understanding-the-username-binding-policy).

+<a name='steps-to-configure-and-test-azure-ad-cba'></a>

+## Steps to configure and test Microsoft Entra CBA

+Some configuration steps to be done before you enable Microsoft Entra CBA. First, an admin must configure the trusted CAs that issue user certificates. As seen in the following diagram, we use role-based access control to make sure only least-privileged administrators are needed to make changes. Only the [Global Administrator](../roles/permissions-reference.md#global-administrator) role can configure the CA.

+Optionally, you can also configure authentication bindings to map certificates to single-factor or multifactor authentication, and configure username bindings to map the certificate field to an attribute of the user object. [Authentication Policy Administrators](../roles/permissions-reference.md#authentication-policy-administrator) can configure user-related settings. Once all the configurations are complete, enable Microsoft Entra CBA on the tenant.

+>A user is considered capable for **MFA** when the user is in scope for **Certificate-based authentication** in the Authentication methods policy. This policy requirement means a user can't use proof up as part of their authentication to register other available methods. If the users do not have access to certificates they will be locked out and not be able to register other methods for MFA. So the admin needs to enable users who have a valid certificate into the CBA scope. Do not use all users for CBA target and use groups of users who have valid certificates available. For more information, see [Microsoft Entra multifactor authentication](concept-mfa-howitworks.md).

+The authentication binding policy helps determine the strength of authentication to either a single factor or multifactor. An admin can change the default value from single-factor to multifactor and configure custom policy rules by mapping to issuer Subject or policy OID fields in the certificate.

+To enable Microsoft Entra CBA and configure user bindings in the Microsoft Entra admin center, complete the following steps:

+1. The protection level attribute has a default value of **Single-factor authentication**. Select **multifactor authentication** to change the default value to MFA.

+ 1. Click **multifactor authentication**.

+ 1. Click **multifactor authentication**.

+>If a username binding policy uses synchronized attributes, such as onPremisesUserPrincipalName attribute of the user object, be aware that any user with Active Directory Administrators privileges can make changes that impact the onPremisesUserPrincipalName value in Microsoft Entra ID for any synchronized accounts, including users with delegated administrative privilege over synchronized user accounts or administrative rights over the Microsoft Entra Connect Servers.

+ If the specified X.509 certificate field is found on the certificate, but Microsoft Entra doesnΓÇÖt find a user object using that value, the authentication fails. Microsoft Entra ID will fall back and try the next binding in the list.

+- Microsoft Entra ID is configured correctly with trusted CAs.

+<a name='enable-azure-ad-cba-using-microsoft-graph-api'></a>

+## Enable Microsoft Entra CBA using Microsoft Graph API

+- [Overview of Microsoft Entra CBA](concept-certificate-based-authentication.md)

+- [Technical deep dive for Microsoft Entra CBA](concept-certificate-based-authentication-technical-deep-dive.md)

+- [Limitations with Microsoft Entra CBA](concept-certificate-based-authentication-limitations.md)

+- [Windows SmartCard logon using Microsoft Entra CBA](concept-certificate-based-authentication-smartcard.md)

+- [Microsoft Entra CBA on mobile devices (Android and iOS)](./concept-certificate-based-authentication-mobile-ios.md)

+# Customer intent: As an identity administrator, I want to encourage users to use the Microsoft Authenticator app in Microsoft Entra ID to improve and secure user sign-in events.

+| id | String | Object ID of a Microsoft Entra user or group. |

+| State | advancedConfigState | Possible values are:<br>**enabled** explicitly enables the feature for the selected group.<br>**disabled** explicitly disables the feature for the selected group.<br>**default** allows Microsoft Entra ID to manage whether the feature is enabled or not for the selected group. |

+[Authentication methods in Microsoft Entra ID - Microsoft Authenticator app](concept-authentication-authenticator-app.md)

+Microsoft Authenticator Lite is another surface for Microsoft Entra users to complete multifactor authentication by using push notifications or time-based one-time passcodes (TOTP) on their Android or iOS device. With Authenticator Lite, users can satisfy a multifactor authentication requirement from the convenience of a familiar app. Authenticator Lite is currently enabled in [Outlook mobile](https://www.microsoft.com/microsoft-365/outlook-mobile-for-android-and-ios).

+| State | advancedConfigState | Possible values are:<br>**enabled** explicitly enables the feature for the selected group.<br>**disabled** explicitly disables the feature for the selected group.<br>**default** allows Microsoft Entra ID to manage whether the feature is enabled or not for the selected group. |

+[Authentication methods in Microsoft Entra ID](concept-authentication-authenticator-app.md)

+ Title: How number matching works in multifactor authentication push notifications for Microsoft Authenticator

+# Customer intent: As an identity administrator, I want to explain how number matching in MFA push notifications from Authenticator in Microsoft Entra ID works in different use cases.

+# How number matching works in multifactor authentication push notifications for Authenticator - Authentication methods policy

+When a user responds to an MFA push notification using Authenticator, they'll be presented with a number. They need to type that number into the app to complete the approval. For more information about how to set up MFA, see [Tutorial: Secure user sign-in events with Microsoft Entra multifactor authentication](tutorial-enable-azure-mfa.md).

+AD FS adapter requires number matching on supported versions of Windows Server. On earlier versions, users continue to see the **Approve**/**Deny** experience and donΓÇÖt see number matching until you upgrade. The AD FS adapter supports number matching only after you install one of the updates in the following table. For more information about how to set up AD FS adapter, see [Configure Microsoft Entra multifactor authentication Server to work with AD FS in Windows Server](howto-mfaserver-adfs-windows-server.md).

+If your organization uses Remote Desktop Gateway and the user is registered for a TOTP code along with Authenticator push notifications, the user can't meet the Microsoft Entra multifactor authentication challenge and Remote Desktop Gateway sign-in fails. In this case, you can set OVERRIDE_NUMBER_MATCHING_WITH_OTP = FALSE to fall back to **Approve**/**Deny** push notifications with Authenticator.

+[Authentication methods in Microsoft Entra ID](concept-authentication-authenticator-app.md)

+ Title: How to run a registration campaign to set up Microsoft Authenticator

+#Customer intent: As an identity administrator, I want to encourage users to use the Microsoft Authenticator app in Microsoft Entra ID to improve and secure user sign-in events.

+- Your organization must have enabled Microsoft Entra multifactor authentication. Every edition of Microsoft Entra ID includes Microsoft Entra multifactor authentication. No other license is needed for a registration campaign.

+1. User successfully authenticates using Microsoft Entra multifactor authentication.

+1. For **State**, click **Microsoft managed** or **Enabled**. In the following screenshot, the registration campaign is **Microsoft managed**. That setting allows Microsoft to set the default value to be either Enabled or Disabled. For the registration campaign, the Microsoft managed value is Enabled for voice call and text message users with free and trial subscriptions. For more information, see [Protecting authentication methods in Microsoft Entra ID](concept-authentication-default-enablement.md).

+| state | "enabled"<br>"disabled"<br>"default" | Allows you to enable or disable the feature.<br>Default value is used when the configuration hasn't been explicitly set and will use Microsoft Entra ID default value for this setting. Currently maps to disabled.<br>Change states to either enabled or disabled as needed. |

+No. This feature is available only for users using Microsoft Entra multifactor authentication.

+**Will I be able to nudge my users if I am not using Microsoft Entra multifactor authentication?**

+No. The nudge only works for users who are doing MFA using the Microsoft Entra multifactor authentication service.

+ Title: How to use the MFA Server Migration Utility to migrate to Microsoft Entra multifactor authentication

+description: Step-by-step guidance to migrate MFA server settings to Microsoft Entra ID using the MFA Server Migration Utility.

+This topic covers how to migrate MFA settings for Microsoft Entra users from on-premises Azure MFA Server to Microsoft Entra multifactor authentication.

+The MFA Server Migration Utility helps synchronize multifactor authentication data stored in the on-premises Azure MFA Server directly to Microsoft Entra multifactor authentication.

+After the authentication data is migrated to Microsoft Entra ID, users can perform cloud-based MFA seamlessly without having to register again or confirm authentication methods.

+- The MFA Server Migration Utility copies the data from the database file onto the user objects in Microsoft Entra ID. During migration, users can be targeted for Microsoft Entra multifactor authentication for testing purposes using [Staged Rollout](../hybrid/connect/how-to-connect-staged-rollout.md). Staged migration lets you test without making any changes to your domain federation settings. Once migrations are complete, you must finalize your migration by making changes to your domain federation settings.

+- AD FS running Windows Server 2016 or higher is required to provide MFA authentication on any AD FS relying parties, not including Microsoft Entra ID and Office 365.

+|Preparations |[Identify Microsoft Entra multifactor authentication Server dependencies](#identify-azure-ad-mfa-server-dependencies) |

+||[Backup Microsoft Entra multifactor authentication Server datafile](#backup-azure-ad-mfa-server-datafile) |

+ - The migration tool uses Microsoft Entra groups for determining the users for which authentication data should be synced between MFA Server and Microsoft Entra multifactor authentication. After user data has been synced, that user is then ready to use Microsoft Entra multifactor authentication.

+ - Staged Rollout allows you to reroute users to Microsoft Entra multifactor authentication, also using Microsoft Entra groups.

+ While you certainly could use the same groups for both tools, we recommend against it as users could potentially be redirected to Microsoft Entra multifactor authentication before the tool has synched their data. We recommend setting up Microsoft Entra groups for syncing authentication data by the MFA Server Migration Utility, and another set of groups for Staged Rollout to direct targeted users to Microsoft Entra multifactor authentication rather than on-premises.

+**Phase 2** should be repeated as you migrate your user base. By the end of Phase 2, your entire user base should be using Microsoft Entra multifactor authentication for all workloads federated against Microsoft Entra ID.

+During the previous phases, you can remove users from the Staged Rollout folders to take them out of scope of Microsoft Entra multifactor authentication and route them back to your on-premises Azure MFA server for all MFA requests originating from Microsoft Entra ID.

+**Phase 3** requires moving all clients that authenticate to the on-premises MFA Server (VPNs, password managers, and so on) to Microsoft Entra federation via SAML/OAUTH. If modern authentication standards aren't supported, you're required to stand up NPS server(s) with the Microsoft Entra multifactor authentication extension installed. Once dependencies are migrated, users should no longer use the User portal on the MFA Server, but rather should manage their authentication methods in Microsoft Entra ID ([aka.ms/mfasetup](https://aka.ms/mfasetup)). Once users begin managing their authentication data in Microsoft Entra ID, those methods won't be synced back to MFA Server. If you roll back to the on-premises MFA Server after users have made changes to their Authentication Methods in Microsoft Entra ID, those changes will be lost. After user migrations are complete, change the [federatedIdpMfaBehavior](/graph/api/resources/internaldomainfederation?view=graph-rest-1.0#federatedidpmfabehavior-values&preserve-view=true) domain federation setting. The change tells Microsoft Entra ID to no longer perform MFA on-premises and to perform _all_ MFA requests with Microsoft Entra multifactor authentication, regardless of group membership.

+<a name='identify-azure-ad-mfa-server-dependencies'></a>

+### Identify Microsoft Entra multifactor authentication Server dependencies

+We've worked hard to ensure that moving onto our cloud-based Microsoft Entra multifactor authentication solution will maintain and even improve your security posture. There are three broad categories that should be used to group dependencies:

+To help your migration, we've matched widely used MFA Server features with the functional equivalent in Microsoft Entra multifactor authentication for each category.

+|MFA Server|Microsoft Entra multifactor authentication|

+|**Username Resolution tab**|Not applicable; username resolution isn't required for Microsoft Entra multifactor authentication|

+|**Text Message tab**|Not applicable; Microsoft Entra multifactor authentication uses a default message for text messages|

+|OATH Token tab|Not applicable; Microsoft Entra multifactor authentication uses a default message for OATH tokens|

+|Reports|[Microsoft Entra authentication Methods Activity reports](howto-authentication-methods-activity.md)|

+^**The default SMS MFA experience in Microsoft Entra multifactor authentication sends users a code, which they're required to enter in the login window as part of authentication. The requirement to roundtrip the SMS code provides proof-of-presence functionality.

+|MFA Server|Microsoft Entra multifactor authentication|

+|Allow users to initiate a One-Time Bypass|See [Microsoft Entra ID TAP functionality](howto-authentication-temporary-access-pass.md)|

+|- Device limit|Microsoft Entra ID limits users to five cumulative devices (mobile app instances + hardware OATH token + software OATH token) per user|

+|Use security questions for fallback|Microsoft Entra ID allows users to choose a fallback method at authentication time should the chosen authentication method fail|

+|- Questions to answer|Security Questions in Microsoft Entra ID can only be used for SSPR. See more details for [Microsoft Entra Custom Security Questions](concept-authentication-security-questions.md#custom-security-questions)|

+|**Security Questions tab** |Security questions in MFA Server were used to gain access to the User portal. Microsoft Entra multifactor authentication only supports security questions for self-service password reset. See [security questions documentation](concept-authentication-security-questions.md).|

+|**Passed Sessions tab**|All authentication method registration flows are managed by Microsoft Entra ID and don't require configuration|

+|**Trusted IPs**|[Microsoft Entra ID trusted IPs](howto-mfa-mfasettings.md#trusted-ips)|

+Any MFA methods available in MFA Server must be enabled in Microsoft Entra multifactor authentication by using [MFA Service settings](howto-mfa-mfasettings.md#mfa-service-settings).

+Azure MFA Server can provide MFA functionality for third-party solutions that use RADIUS or LDAP by acting as an authentication proxy. To discover RADIUS or LDAP dependencies, click **RADIUS Authentication** and **LDAP Authentication** options in MFA Server. For each of these dependencies, determine if these third parties support modern authentication. If so, consider federation directly with Microsoft Entra ID.

+For RADIUS deployments that can't be upgraded, you'll need to deploy an NPS Server and install the [Microsoft Entra multifactor authentication NPS extension](howto-mfa-nps-extension.md).

+For LDAP deployments that can't be upgraded or moved to RADIUS, [determine if Microsoft Entra Domain Services can be used](../architecture/auth-ldap.md). In most cases, LDAP was deployed to support in-line password changes for end users. Once migrated, end users can manage their passwords by using [self-service password reset in Microsoft Entra ID](tutorial-enable-sspr.md).

+If you enabled the [MFA Server Authentication provider in AD FS 2.0](./howto-mfaserver-adfs-windows-server.md#secure-windows-server-ad-fs-with-azure-multi-factor-authentication-server) on any relying party trusts except for the Office 365 relying party trust, you'll need to upgrade to [AD FS 3.0](/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server) or federate those relying parties directly to Microsoft Entra ID if they support modern authentication methods. Determine the best plan of action for each of the dependencies.

+<a name='backup-azure-ad-mfa-server-datafile'></a>

+### Backup Microsoft Entra multifactor authentication Server datafile

+Make a backup of the MFA Server data file located at %programfiles%\multifactor authentication Server\Data\PhoneFactor.pfdata (default location) on your primary MFA Server. Make sure you have a copy of the installer for your currently installed version in case you need to roll back. If you no longer have a copy, contact Customer Support Services.

+Run the new installer on the Primary MFA Server. Before you upgrade a server, remove it from load balancing or traffic sharing with other MFA Servers. You don't need to uninstall your current MFA Server before running the installer. The installer performs an in-place upgrade using the current installation path (for example, C:\Program Files\multifactor authentication Server). 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. It isn't required to install updates for User portal, Web SDK, or AD FS Adapter.

+After installing the MFA Server update, open an elevated PowerShell command prompt: hover over the PowerShell icon, right-click, and click **Run as Administrator**. Run the .\Configure-MultiFactorAuthMigrationUtility.ps1 script found in your MFA Server installation directory (C:\Program Files\multifactor authentication Server by default).

+This script will require you to provide credentials for an Application Administrator in your Microsoft Entra tenant. The script will then create a new MFA Server Migration Utility application within Microsoft Entra ID, which will be used to write user authentication methods to each Microsoft Entra user object.

+Once complete, navigate to the multifactor authentication Server folder, and open the **MultiFactorAuthMigrationUtilityUI** application. You should see the following screen:

+Migrating user data doesn't remove or alter any data in the multifactor authentication Server database. Likewise, this process won't change where a user performs MFA. This process is a one-way copy of data from the on-premises server to the corresponding user object in Microsoft Entra ID.

+The MFA Server Migration utility targets a single Microsoft Entra group for all migration activities. You can add users directly to this group, or add other groups. You can also add them in stages during the migration.

+To begin the migration process, enter the name or GUID of the Microsoft Entra group you want to migrate. Once complete, press Tab or click outside the window to begin searching for the appropriate group. All users in the group are populated. A large group can take several minutes to finish.

+This window displays the attributes for the selected user in both Microsoft Entra ID and the on-premises MFA Server. You can use this window to view how data was written to a user after migration.

+ - Only migrate if not already set in Microsoft Entra ID

+ - Set to the most secure method available if not already set in Microsoft Entra ID

+- User Match ΓÇô Allows you to specify a different on-premises Active Directory attribute for matching Microsoft Entra UPN instead of the default match to userPrincipalName:

+ - If no match is found, it calls a Windows API to find the Microsoft Entra UPN and get the SID, which it uses to search the MFA Server user list.

+- Automatic synchronization ΓÇô Starts a background service that will continually monitor any authentication method changes to users in the on-premises MFA Server, and write them to Microsoft Entra ID at the specified time interval defined.

+1. To migrate all users in the group, click **Migrate Users** > **All users in Microsoft Entra group** > **OK**.

+For the automatic process, click **Automatic synchronization** in **Settings**, and then select whether you want all users to be synced, or only members of a given Microsoft Entra group.

+|**Mobile App**|Maximum of five devices will be migrated or only four if the user also has a hardware OATH token.<br>If there are multiple devices with the same name, only migrate the most recent one.<br>Devices will be ordered from newest to oldest.<br>If devices already exist in Microsoft Entra ID, match on OATH Token Secret Key and update.<br>- If there's no match on OATH Token Secret Key, match on Device Token<br>-- If found, create a Software OATH Token for the MFA Server device to allow OATH Token method to work. Notifications will still work using the existing Microsoft Entra multifactor authentication device.<br>-- If not found, create a new device.<br>If adding a new device will exceed the five-device limit, the device will be skipped. |

+|**OATH Token**|If devices already exist in Microsoft Entra ID, match on OATH Token Secret Key and update.<br>- If not found, add a new Hardware OATH Token device.<br>If adding a new device will exceed the five-device limit, the OATH token will be skipped.|

+During testing, we recommend doing a manual migration first, and test to ensure a given number of users behave as expected. Once testing is successful, turn on automatic synchronization for the Microsoft Entra group you wish to migrate. As you add users to this group, their information will be automatically synchronized to Microsoft Entra ID. MFA Server Migration Utility targets one Microsoft Entra group, however that group can encompass both users and nested groups of users.

+As mentioned in the confirmation message, it can take several minutes for the migrated data to appear on user objects within Microsoft Entra ID. Users can view their migrated methods by navigating to [aka.ms/mfasetup](https://aka.ms/mfasetup).

+Once you've successfully migrated user data, you can validate the end-user experience using Staged Rollout before making the global tenant change. The following process will allow you to target specific Microsoft Entra group(s) for Staged Rollout for MFA. Staged Rollout tells Microsoft Entra ID to perform MFA by using Microsoft Entra multifactor authentication for users in the targeted groups, rather than sending them on-premises to perform MFA. You can validate and testΓÇöwe recommend using the Microsoft Entra admin center, but if you prefer, you can also use Microsoft Graph.

+1. Target the Microsoft Entra group(s) that contain the users you wish to test

+Ensure users know what to expect when they're moved to Azure MFA, including new authentication flows. You may also wish to instruct users to use the Microsoft Entra ID Combined Registration portal ([aka.ms/mfasetup](https://aka.ms/mfasetup)) to manage their authentication methods rather than the User portal once migrations are complete. Any changes made to authentication methods in Microsoft Entra ID won't propagate back to your on-premises environment. In a situation where you had to roll back to MFA Server, any changes users have made in Microsoft Entra ID won't be available in the MFA Server User portal.

+If you use third-party solutions that depend on Azure MFA Server for authentication (see [Authentication services](#authentication-services)), you'll want users to continue to make changes to their MFA methods in the User portal. These changes will be synced to Microsoft Entra ID automatically. Once you've migrated these third party solutions, you can move users to the Microsoft Entra ID combined registration page.

+Once you've completed user migrations, and moved all of your [Authentication services](#authentication-services) off of MFA Server, it's time to update your domain federation settings. After the update, Microsoft Entra no longer sends MFA request to your on-premises federation server.

+To configure Microsoft Entra ID to ignore MFA requests to your on-premises federation server, install the [Microsoft Graph PowerShell SDK](/powershell/microsoftgraph/installation?view=graph-powershell-&preserve-view=true) and set [federatedIdpMfaBehavior](/graph/api/resources/internaldomainfederation?view=graph-rest-1.0#federatedidpmfabehavior-values&preserve-view=true) to `rejectMfaByFederatedIdp`, as shown in the following example.

+Once you've completed migrating all user data, end users can begin using the Microsoft Entra ID combined registration pages to manage MFA Methods. There are a couple ways to prevent users from using the User portal in MFA Server:

+When you no longer need the Azure MFA server, follow your normal server deprecation practices. No special action is required in Microsoft Entra ID to indicate MFA Server retirement.

+1. Configure Microsoft Entra ID to accept MFA requests to your on-premises federation server. Use Graph PowerShell to set [federatedIdpMfaBehavior](/graph/api/resources/internaldomainfederation?view=graph-rest-1.0#federatedidpmfabehavior-values&preserve-view=true) to `enforceMfaByFederatedIdp`, as shown in the following example.

+- [Overview of how to migrate from MFA Server to Microsoft Entra multifactor authentication](how-to-migrate-mfa-server-to-azure-mfa.md)

+ Title: Migrate from MFA Server to Microsoft Entra multifactor authentication

+description: Step-by-step guidance to migrate from MFA Server on-premises to Microsoft Entra multifactor authentication

+# Migrate from MFA Server to Microsoft Entra multifactor authentication

+Multifactor authentication is important to securing your infrastructure and assets from bad actors. Microsoft Entra multifactor authentication Server (MFA Server) isn't available for new deployments and will be deprecated. Customers who are using MFA Server should move to using cloud-based Microsoft Entra multifactor authentication.

+- You're using federation on Microsoft Entra ID with Active Directory Federation Services (AD FS) or another identity provider federation product.

+| <br> | Goal: Decommission MFA Server ONLY | Goal: Decommission MFA Server and move to Microsoft Entra authentication | Goal: Decommission MFA Server and AD FS |

+|MFA provider | Change MFA provider from MFA Server to Microsoft Entra multifactor authentication. | Change MFA provider from MFA Server to Microsoft Entra multifactor authentication. | Change MFA provider from MFA Server to Microsoft Entra multifactor authentication. |

+|User authentication |Continue to use federation for Microsoft Entra authentication. | Move to Microsoft Entra ID with Password Hash Synchronization (preferred) or Passthrough Authentication **and** Seamless single sign-on (SSO).| Move to Microsoft Entra ID with Password Hash Synchronization (preferred) or Passthrough Authentication **and** SSO. |

+|Application authentication | Continue to use AD FS authentication for your applications. | Continue to use AD FS authentication for your applications. | Move apps to Microsoft Entra ID before migrating to Microsoft Entra multifactor authentication. |

+If you can, move both your multifactor authentication and your user authentication to Azure. For step-by-step guidance, see [Moving to Microsoft Entra multifactor authentication and Microsoft Entra user authentication](how-to-migrate-mfa-server-to-mfa-user-authentication.md).

+If you can't move your user authentication, see the step-by-step guidance for [Moving to Microsoft Entra multifactor authentication with federation](how-to-migrate-mfa-server-to-mfa-with-federation.md).

+- AD FS environment (required if you aren't migrating all your apps to Microsoft Entra prior to migrating MFA Server)

+ - Upgrade to AD FS for Windows Server 2019, Farm behavior level (FBL) 4. This upgrade enables you to select authentication provider based on group membership for a more seamless user transition. While it's possible to migrate while on AD FS for Windows Server 2016 FBL 3, it isn't as seamless for users. During the migration, users are prompted to select an authentication provider (MFA Server or Microsoft Entra multifactor authentication) until the migration is complete.

+ - Enterprise administrator role in Active Directory to configure AD FS farm for Microsoft Entra multifactor authentication

+ - Global administrator role in Microsoft Entra ID to perform configuration of Microsoft Entra ID using Azure AD PowerShell

+Migrating from MFA Server to Microsoft Entra multifactor authentication involves more than just moving the registered MFA phone numbers.

+Microsoft's MFA server can be integrated with many systems, and you must evaluate how these systems are using MFA Server to understand the best ways to integrate with Microsoft Entra multifactor authentication.

+You can use the [MFA Server Migration Utility](how-to-mfa-server-migration-utility.md) to synchronize MFA data stored in the on-premises Azure MFA Server to Microsoft Entra multifactor authentication and use [Staged Rollout](../hybrid/connect/how-to-connect-staged-rollout.md) to reroute users to Azure MFA. Staged Rollout helps you test without making any changes to your domain federation settings.

+Microsoft Entra ID provides support for OATH hardware tokens. You can use the [MFA Server Migration Utility](how-to-mfa-server-migration-utility.md) to synchronize MFA settings between MFA Server and Microsoft Entra multifactor authentication and use [Staged Rollout](../hybrid/connect/how-to-connect-staged-rollout.md) to test user migrations without changing domain federation settings.

+If you only want to migrate OATH hardware tokens, you need to [upload tokens to Microsoft Entra ID by using a CSV file](concept-authentication-oath-tokens.md#oath-hardware-tokens-preview), commonly referred to as a "seed file".

+The seed file contains the secret keys, token serial numbers, and other necessary information needed to upload the tokens into Microsoft Entra ID.

+You can use this information along with the seed file to import the tokens into Microsoft Entra ID and assign the OATH token to the specified user based on the serial number.

+Refer to the help file topic **GetUserInfo** > **userSettings** > **OathTokenSerialNumber** in multifactor authentication Server on your MFA Server.

+The decision to migrate from MFA Server to Microsoft Entra multifactor authentication opens the door for other migrations. Completing more migrations depends upon many factors, including specifically:

+- Your willingness to use Microsoft Entra authentication for users

+- Your willingness to move your applications to Microsoft Entra ID

+- Use Microsoft Entra ID for authentication as it enables more robust security and governance

+- Move applications to Microsoft Entra ID if possible

+To select the best user authentication method for your organization, see [Choose the right authentication method for your Microsoft Entra hybrid identity solution](../hybrid/connect/choose-ad-authn.md).

+As part of enrolling users to use Microsoft Authenticator as a second factor, we recommend you enable passwordless phone sign-in as part of their registration. For more information, including other passwordless methods such as FIDO2 security keys and Windows Hello for Business, visit [Plan a passwordless authentication deployment with Microsoft Entra ID](howto-authentication-passwordless-deployment.md#plan-for-and-deploy-microsoft-authenticator).

+MIM can't be configured to use Microsoft Entra multifactor authentication.

+We recommend you evaluate moving your SSPR service to Microsoft Entra SSPR.

+You can use the opportunity of users registering for Microsoft Entra multifactor authentication to use the combined registration experience to register for Microsoft Entra SSPR.

+<a name='radius-clients-and-azure-ad-multi-factor-authentication'></a>

+### RADIUS clients and Microsoft Entra multifactor authentication

+If you're using RADIUS with MFA Server, we recommend moving client applications to modern protocols such as SAML, OpenID Connect, or OAuth on Microsoft Entra ID.

+If the application can't be updated, then you can deploy Network Policy Server (NPS) with the Microsoft Entra multifactor authentication extension.

+The network policy server (NPS) extension acts as an adapter between RADIUS-based applications and Microsoft Entra multifactor authentication to provide a second factor of authentication. This "adapter" allows you to move your RADIUS clients to Microsoft Entra multifactor authentication and decommission your MFA Server.

+- The NPS extension doesn't use Microsoft Entra Conditional Access policies. If you stay with RADIUS and use the NPS extension, all authentication requests going to NPS will require the user to perform MFA.

+- Users must register for Microsoft Entra multifactor authentication prior to using the NPS extension. Otherwise, the extension fails to authenticate the user, which can generate help desk calls.

+ - We recommend federating your VPN as a SAML app if possible. This federation will allow you to use Conditional Access. For more information, see a [list of VPN vendors that are integrated into the Microsoft Entra ID](../manage-apps/secure-hybrid-access.md#secure-hybrid-access-through-azure-ad-partner-integrations) App gallery.

+- [Microsoft Entra multifactor authentication NPS extension health check script](/samples/azure-samples/azure-mfa-nps-extension-health-check/azure-mfa-nps-extension-health-check/)

+- [Integrating existing NPS infrastructure with Microsoft Entra multifactor authentication](howto-mfa-nps-extension-vpn.md)

+- [Moving to Microsoft Entra multifactor authentication with federation](how-to-migrate-mfa-server-to-mfa-with-federation.md)

+- [Moving to Microsoft Entra multifactor authentication and Microsoft Entra user authentication](how-to-migrate-mfa-server-to-mfa-user-authentication.md)

+ Title: Migrate to Microsoft Entra multifactor authentication and Microsoft Entra user authentication

+description: Guidance to move from MFA Server on-premises to Microsoft Entra multifactor authentication and Microsoft Entra user authentication

+# Migrate to Microsoft Entra multifactor authentication and Microsoft Entra user authentication

+Multifactor authentication helps secure your infrastructure and assets from bad actors. Microsoft multifactor authentication Server (MFA Server) is no longer offered for new deployments. Customers who are using MFA Server should move to Microsoft Entra multifactor authentication (Microsoft Entra multifactor authentication).

+There are several options for migrating from MFA Server to Microsoft Entra ID:

+* Good: Moving only your [MFA service to Microsoft Entra ID](how-to-migrate-mfa-server-to-azure-mfa.md).

+* Better: Moving your MFA service and user authentication to Microsoft Entra ID, covered in this article.

+* Best: Moving all of your applications, your MFA service, and user authentication to Microsoft Entra ID. See the move applications to Microsoft Entra ID section of this article if you plan to move applications, covered in this article.

+To select the appropriate MFA migration option for your organization, see the considerations in [Migrate from MFA Server to Microsoft Entra multifactor authentication](how-to-migrate-mfa-server-to-azure-mfa.md).

+The following diagram shows the process for migrating to Microsoft Entra multifactor authentication and cloud authentication while keeping some of your applications on AD FS.

+This process enables the iterative migration of users from MFA Server to Microsoft Entra multifactor authentication based on group membership.

+>If you're planning on moving any applications to Microsoft Entra ID as a part of this migration, you should do so prior to your MFA migration. If you move all of your apps, you can skip sections of the MFA migration process. See the section on moving applications at the end of this article.

+<a name='process-to-migrate-to-azure-ad-and-user-authentication'></a>

+## Process to migrate to Microsoft Entra ID and user authentication

+

+* **To iteratively move users to Microsoft Entra multifactor authentication with Staged Rollout.**

+ Use a group created in Microsoft Entra ID, also known as a cloud-only group. You can use Microsoft Entra security groups or Microsoft 365 Groups for both moving users to MFA and for Conditional Access policies.

+ You can use either Microsoft Entra ID or on-premises groups for Conditional Access.

+* **To invoke Microsoft Entra multifactor authentication for AD FS applications with claims rules.**

+ You must use an on-premises Active Directory security group. Once Microsoft Entra multifactor authentication is an additional authentication method, you can designate groups of users to use that method on each relying party trust. For example, you can call Microsoft Entra multifactor authentication for users you already migrated, and MFA Server for users who aren't migrated yet. This strategy is helpful both in testing and during migration.

+As users are migrated to cloud authentication, they'll start using Microsoft Entra multifactor authentication as defined by your Conditional Access policies.

+In this case, you'll need to analyze your claims rules on the Microsoft Entra ID relying party trust and create Conditional Access policies that support the same security goals.

+By specifying an additional authentication method, you can transition to Microsoft Entra multifactor authentication while keeping other authentication intact during the transition.

+<a name='configure-claims-rules-to-invoke-azure-ad-mfa'></a>

+### Configure claims rules to invoke Microsoft Entra multifactor authentication

+Now that Microsoft Entra multifactor authentication is an additional authentication method, you can assign groups of users to use Microsoft Entra multifactor authentication by configuring claims rules, also known as *relying party trusts*. By using groups, you can control which authentication provider is called either globally or by application. For example, you can call Microsoft Entra multifactor authentication for users who registered for combined security information or had their phone numbers migrated, while calling MFA Server for users whose phone numbers haven't migrated.

+You'll need to have a specific group in which you place users for whom you want to invoke Microsoft Entra multifactor authentication. You'll need to find the security identifier (SID) for that group.

+<a name='setting-the-claims-rules-to-call-azure-ad-mfa'></a>

+#### Setting the claims rules to call Microsoft Entra multifactor authentication

+The following Microsoft Graph PowerShell cmdlets invoke Microsoft Entra multifactor authentication for users in the group when they aren't on the corporate network.

+<a name='configure-azure-ad-mfa-as-an-authentication-provider-in-ad-fs'></a>

+### Configure Microsoft Entra multifactor authentication as an authentication provider in AD FS

+In order to configure Microsoft Entra multifactor authentication for AD FS, you must configure each AD FS server. If multiple AD FS servers are in your farm, you can configure them remotely using Microsoft Graph PowerShell.

+After you configure the servers, you can add Microsoft Entra multifactor authentication as an additional authentication method.

+

+<a name='register-users-for-azure-ad-mfa'></a>

+## Register users for Microsoft Entra multifactor authentication

+We recommend that you [secure the security registration process with Conditional Access](../conditional-access/howto-conditional-access-policy-registration.md) that requires the registration to occur from a trusted device or location. For information on tracking registration statuses, see [Authentication method activity for Microsoft Entra ID](howto-authentication-methods-activity.md).

+You can use the [MFA Server Migration utility](how-to-mfa-server-migration-utility.md) to synchronize registered MFA settings for users from MFA Server to Microsoft Entra ID.

+* Only after you add users to the appropriate Conditional Access rules, add users to the group that you created for Staged Rollout. Once done, they'll begin to use the Azure authentication method that you selected (PHS or PTA) and Microsoft Entra multifactor authentication when they're required to perform MFA.

+These reports can be found in Microsoft Entra ID in the navigation pane under **Monitoring**.

+<a name='monitoring-azure-ad-mfa-registration'></a>

+### Monitoring Microsoft Entra multifactor authentication registration

+Microsoft Entra multifactor authentication registration can be monitored using the [Authentication methods usage & insights report](https://portal.azure.com/#blade/Microsoft_AAD_IAM/AuthenticationMethodsMenuBlade/AuthMethodsActivity/menuId/AuthMethodsActivity). This report can be found in Microsoft Entra ID. Select **Monitoring**, then select **Usage & insights**.

+Detailed Microsoft Entra multifactor authentication registration information can be found on the Registration tab. You can drill down to view a list of registered users by selecting the **Users registered for Azure multifactor authentication** hyperlink.

+Monitor applications you moved to Microsoft Entra ID with the App sign-in health workbook or the application activity usage report.

+* **Microsoft Entra application activity usage report**. This [report](https://portal.azure.com/#blade/Microsoft_AAD_IAM/UsageAndInsightsMenuBlade/Azure%20AD%20application%20activity) can be used to view the successful and failed sign-ins for individual applications as well as the ability to drill down and view sign-in activity for a specific application.

+After you move all users to Microsoft Entra cloud authentication and Microsoft Entra multifactor authentication, you're ready to decommission your MFA Server.

+You should now [convert your federated domains in Microsoft Entra ID to managed](../hybrid/connect/migrate-from-federation-to-cloud-authentication.md#convert-domains-from-federated-to-managed) and remove the Staged Rollout configuration.

+Follow the steps under [Configure claims rules to invoke Microsoft Entra multifactor authentication](#configure-claims-rules-to-invoke-azure-ad-mfa) to revert the claims rules and remove any AzureMFAServerAuthentication claims rules.

+This change ensures only Microsoft Entra multifactor authentication is used as an authentication provider.

+1. Under **Services**, right-click on **Authentication Methods**, and select **Edit multifactor authentication Methods**.

+1. Clear the **Azure multifactor authentication Server** checkbox.

+* Uninstall multifactor authentication Server from the Control Panel on the server.

+* Uninstall the multifactor authentication Web Server SDK, if applicable including any files left over inetpub\wwwroot\MultiFactorAuthWebServiceSdk and/or MultiFactorAuth directories.

+* For pre-8.0.x versions of MFA Server, it may also be necessary to remove the multifactor authentication Phone App Web Service.

+<a name='move-application-authentication-to-azure-active-directory'></a>

+## Move application authentication to Microsoft Entra ID

+

+For more information about migrating applications to Azure, see [Resources for migrating applications to Microsoft Entra ID](../manage-apps/migration-resources.md).

+- [Migrate from Microsoft MFA Server to Microsoft Entra multifactor authentication (Overview)](how-to-migrate-mfa-server-to-azure-mfa.md)

+- [Migrate applications from Windows Active Directory to Microsoft Entra ID](../manage-apps/migrate-adfs-apps-phases-overview.md)

+ Title: Migrate to Microsoft Entra multifactor authentication with federations

+description: Step-by-step guidance to move from MFA Server on-premises to Microsoft Entra multifactor authentication with federation

+# Migrate to Microsoft Entra multifactor authentication with federation

+Moving your multifactor-authentication (MFA) solution to Microsoft Entra ID is a great first step in your journey to the cloud. Consider also moving to Microsoft Entra ID for user authentication in the future. For more information, see the process for migrating to Microsoft Entra multifactor authentication with cloud authentication.

+To migrate to Microsoft Entra multifactor authentication with federation, the Microsoft Entra multifactor authentication authentication provider is installed on AD FS. The Microsoft Entra ID relying party trust and other relying party trusts are configured to use Microsoft Entra multifactor authentication for migrated users.

+To create new Conditional Access policies, you'll need to assign those policies to groups. You can use Microsoft Entra security groups or Microsoft 365 Groups for this purpose. You can also create or sync new ones.

+You'll also need a Microsoft Entra security group for iteratively migrating users to Microsoft Entra multifactor authentication. These groups are used in your claims rules.

+In AD FS 2019, you can specify additional authentication methods for a relying party, such as an application. You use group membership to determine authentication provider. By specifying an additional authentication method, you can transition to Microsoft Entra multifactor authentication while keeping other authentication intact during the transition. For more information, see [Upgrading to AD FS in Windows Server 2016 using a WID database](/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server). The article covers both upgrading your farm to AD FS 2019 and upgrading your FBL to 4.

+<a name='configure-claims-rules-to-invoke-azure-ad-mfa'></a>

+### Configure claims rules to invoke Microsoft Entra multifactor authentication

+Now that Microsoft Entra multifactor authentication is an additional authentication method, you can assign groups of users to use it. You do so by configuring claims rules, also known as relying party trusts. By using groups, you can control which authentication provider is called globally or by application. For example, you can call Microsoft Entra multifactor authentication for users who have registered for combined security information, while calling MFA Server for those who haven't.

+You'll need to have a specific group in which you place users for whom you want to invoke Microsoft Entra multifactor authentication. You'll need the security identifier (SID) for that group.

+<a name='setting-the-claims-rules-to-call-azure-ad-mfa'></a>

+#### Setting the claims rules to call Microsoft Entra multifactor authentication

+The following PowerShell cmdlets invoke Microsoft Entra multifactor authentication for users in the group when not on the corporate network. Replace "YourGroupSid" with the SID found by running the above cmdlet.

+<a name='configure-azure-ad-mfa-as-an-authentication-provider-in-ad-fs'></a>

+### Configure Microsoft Entra multifactor authentication as an authentication provider in AD FS

+To configure Microsoft Entra multifactor authentication for AD FS, you must configure each AD FS server. If you have multiple AD FS servers in your farm, you can configure them remotely using Azure AD PowerShell.

+For step-by-step directions on this process, see [Configure the AD FS servers](/windows-server/identity/ad-fs/operations/configure-ad-fs-and-azure-mfa) in the article [Configure Microsoft Entra multifactor authentication as authentication provider with AD FS](/windows-server/identity/ad-fs/operations/configure-ad-fs-and-azure-mfa).

+Once you've configured the servers, you can add Microsoft Entra multifactor authentication as an additional authentication method.

+

+<a name='prepare-azure-ad-and-implement-migration'></a>

+## Prepare Microsoft Entra ID and implement migration

+For federated domains, MFA may be enforced by Microsoft Entra Conditional Access or by the on-premises federation provider. Each federated domain has a Microsoft Graph PowerShell security setting named **federatedIdpMfaBehavior**. You can set **federatedIdpMfaBehavior** to `enforceMfaByFederatedIdp` so Microsoft Entra ID accepts MFA that's performed by the federated identity provider. If the federated identity provider didn't perform MFA, Microsoft Entra ID redirects the request to the federated identity provider to perform MFA. For more information, see [federatedIdpMfaBehavior](/graph/api/resources/internaldomainfederation?view=graph-rest-beta#federatedidpmfabehavior-values&preserve-view=true).

+- Once **federatedIdpMfaBehavior** property is set, Microsoft Entra ID ignores the **SupportsMfa** setting.

+- If the **federatedIdpMfaBehavior** property is never set, Microsoft Entra ID will continue to honor the **SupportsMfa** setting.

+- If **federatedIdpMfaBehavior** or **SupportsMfa** isn't set, Microsoft Entra ID will default to `acceptIfMfaDoneByFederatedIdp` behavior.

+If your federated domain(s) have SupportsMfa set to false, analyze your claims rules on the Microsoft Entra ID relying party trust and create Conditional Access policies that support the same security goals.

+After creating Conditional Access policies to enforce the same controls as AD FS, you can back up and remove your claim rules customizations on the Microsoft Entra ID Relying Party.

+<a name='register-users-for-azure-ad-mfa'></a>

+## Register users for Microsoft Entra multifactor authentication

+We recommend that you [secure the security registration process with Conditional Access](../conditional-access/howto-conditional-access-policy-registration.md) that requires the registration to occur from a trusted device or location. For information on tracking registration statuses, see [Authentication method activity for Microsoft Entra ID](howto-authentication-methods-activity.md).

+You can use the [MFA Server Migration utility](how-to-mfa-server-migration-utility.md) to synchronize registered MFA settings for users from MFA Server to Microsoft Entra ID.

+Microsoft Entra multifactor authentication registration can be monitored using the [Authentication methods usage & insights report](https://portal.azure.com/). This report can be found in Microsoft Entra ID. Select **Monitoring**, then select **Usage & insights**.

+Detailed Microsoft Entra multifactor authentication registration information can be found on the Registration tab. You can drill down to view a list of registered users by selecting the **Users capable of Azure multifactor authentication** hyperlink.

+Once you have completed migration to Microsoft Entra multifactor authentication and are ready to decommission the MFA Server, do the following three things:

+1. Remove MFA server as an authentication provider in AD FS. This will ensure all users use Microsoft Entra multifactor authentication as it will be the only additional authentication method enabled.

+Follow the steps under Configure claims rules to invoke Microsoft Entra multifactor authentication to revert back to the backed up claims rules and remove any AzureMFAServerAuthentication claims rules.

+This change ensures only Microsoft Entra multifactor authentication is used as an authentication provider.

+1. Under **Services**, right-click on **Authentication Methods**, and select **Edit multifactor authentication Methods**.

+1. Uncheck the box next to **Azure multifactor authentication Server**.

+* Uninstall multifactor authentication Server from the Control Panel on the server

+* Uninstall the multifactor authentication Web Server SDK if applicable, including any files left over in etpub\wwwroot\MultiFactorAuthWebServiceSdk and or MultiFactorAuth directories

+* For MFA Server versions prior to 8.0, it may also be necessary to remove the multifactor authentication Phone App Web Service

+- [Migrate applications to Microsoft Entra ID](../manage-apps/migrate-adfs-apps-phases-overview.md)

+ A Microsoft Entra ID P1 or P2 license is required to access usage and insights. Microsoft Entra multifactor authentication and self-service password reset (SSPR) licensing information can be found on the [Microsoft Entra pricing site](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing).

+You can access the **Registration** tab to show the number of users capable of multifactor authentication, passwordless authentication, and self-service password reset.

+- **Users capable of Azure multifactor authentication** shows the breakdown of users who are both:

+ This number doesn't reflect users registered for MFA outside of Microsoft Entra ID.

+**Sign-ins by authentication requirement** shows the number of successful user interactive sign-ins that were required for single-factor versus multifactor authentication in Microsoft Entra ID. Sign-ins where MFA was enforced by a third-party MFA provider are not included.

+- The **PhoneAppNotification** or **PhoneAppOTP** methods that a user might have configured are not displayed in the dashboard on **Microsoft Entra authentication methods - Policies**.

+ Title: Plan a passwordless authentication deployment in Microsoft Entra ID

+# Plan a passwordless authentication deployment in Microsoft Entra ID

+Microsoft offers the following [three passwordless authentication options](concept-authentication-passwordless.md) that integrate with Microsoft Entra ID:

+| Microsoft Entra role| Description |

+| [Combined registration for Microsoft Entra multifactor authentication and self-service password reset (SSPR)](howto-registration-mfa-sspr-combined.md) is enabled| √| √|

+| [Users can perform Microsoft Entra multifactor authentication](howto-mfa-getstarted.md)| √| √|

+| [Users have registered for Microsoft Entra multifactor authentication and SSPR](howto-registration-mfa-sspr-combined.md)| √| √|

+| [Users have registered their mobile devices to Microsoft Entra ID](../devices/overview.md)| √| |

+* [Guidance on combined registration for both Microsoft Entra multifactor authentication and SSPR](howto-registration-mfa-sspr-combined.md)

+Users register their passwordless method as a part of the **combined security information workflow** at [https://aka.ms/mysecurityinfo](https://aka.ms/mysecurityinfo). Microsoft Entra ID logs registration of security keys and the Authenticator app, and any other changes to the authentication methods.

+**Active Directory Federation Services (AD FS) Integration** - When a user enables the Authenticator passwordless credential, authentication for that user defaults to sending a notification for approval. Users in a hybrid tenant are prevented from being directed to AD FS for sign-in unless they select "Use your password instead." This process also bypasses any on-premises Conditional Access policies, and pass-through authentication (PTA) flows. However, if a login_hint is specified, the user is forwarded to AD FS and bypasses the option to use the passwordless credential. For non-Microsoft 365 applications which use AD FS for authentication, Microsoft Entra Conditional Access policies will not be applied and you will need to set up access control policies within AD FS.

+**MFA server** - End users enabled for multifactor authentication through an organization's on-premises MFA server can create and use a single passwordless phone sign-in credential. If the user attempts to upgrade multiple installations (5 or more) of the Authenticator app with the credential, this change may result in an error.

+> In September 2022, Microsoft announced deprecation of Azure multifactor authentication Server. Beginning September 30, 2024, Azure multifactor authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their users' authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Azure MFA service by using the latest Migration Utility included in the most recent [Azure MFA Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure MFA Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+**Device registration** - To use the Authenticator app for passwordless authentication, the device must be registered in the Microsoft Entra tenant and can't be a shared device. A device can only be registered in a single tenant. This limit means that only one work or school account is supported for phone sign-in using the Authenticator app.

+* Microsoft Entra web apps on a supported browser

+* Microsoft Entra joined Windows 10 devices

+* Microsoft Entra hybrid joined Windows 10 devices

+**For Microsoft Entra web apps and Microsoft Entra joined Windows devices**, use:

+**For hybrid Microsoft Entra domain joined devices**, use:

+* Latest version of Microsoft Entra Connect.

+ * Only supported for Microsoft Entra hybrid joined devices.

+> These steps must also be completed for any Microsoft Entra hybrid joined devices to utilize FIDO2 security keys for Windows 10 sign-in.

+<a name='passwordless-fido-sign-in-to-azure-active-directory-joined-windows-10-devices'></a>

+#### Passwordless FIDO sign in to Microsoft Entra joined Windows 10 devices

+<a name='passwordless-fido-sign-in-to-azure-ad-web-apps'></a>

+#### Passwordless FIDO sign-in to Microsoft Entra web apps

+For more information on what authentication methods can be managed in Microsoft Graph, see [Microsoft Entra authentication methods API overview](/graph/api/resources/authenticationmethods-overview).

+Microsoft Entra ID has reports that provide technical and business insights. Have your business and technical application owners assume ownership of and consume these reports based on your organization's requirements.

+Microsoft Entra ID adds entries to the audit logs when:

+* A user makes any kind of change to their credentials within Microsoft Entra ID.

+**Microsoft Entra ID keeps most auditing data for 30 days** and makes the data available by using the [Microsoft Entra admin center](https://entra.microsoft.com) or API for you to download into your analysis systems. If you require longer retention, export and consume logs in a SIEM tool such as [Microsoft Sentinel](../../sentinel/connect-azure-active-directory.md), Splunk, or Sumo Logic. We recommend longer retention for auditing, trend analysis, and other business needs as applicable

+For more information, see [track registered authentication methods and usage across the Microsoft Entra organization](howto-authentication-methods-activity.md).

+description: Learn about some frequently asked questions for passwordless hybrid FIDO2 security key sign-in using Microsoft Entra ID

+# Deployment frequently asked questions (FAQs) for hybrid FIDO2 security keys in Microsoft Entra ID

+This article covers deployment frequently asked questions (FAQs) for Microsoft Entra hybrid joined devices and passwordless sign-in to on-prem resources. With this passwordless feature, you can enable Microsoft Entra authentication on Windows 10 devices for Microsoft Entra hybrid joined devices using FIDO2 security keys. Users can sign into Windows on their devices with modern credentials like FIDO2 keys and access traditional Active Directory Domain Services (AD DS) based resources with a seamless single sign-on (SSO) experience to their on-prem resources.

+* Sign in to Microsoft Entra hybrid joined devices using FIDO2 security keys and get SSO access to on-prem resources.

+* Sign in to Microsoft Entra joined devices using FIDO2 security keys and get SSO access to on-prem resources.

+* [What are the specific end points that are required to be open to Microsoft Entra ID?](#what-are-the-specific-end-points-that-are-required-to-be-open-to-azure-ad)

+* [How do I identify the domain join type (Microsoft Entra joined or Microsoft Entra hybrid joined) for my Windows 10 device?](#how-do-i-identify-the-domain-join-type-azure-ad-joined-or-hybrid-azure-ad-joined-for-my-windows-10-device)

+<a name='what-are-the-specific-end-points-that-are-required-to-be-open-to-azure-ad'></a>

+### What are the specific end points that are required to be open to Microsoft Entra ID?

+<a name='how-do-i-identify-the-domain-join-type-azure-ad-joined-or-hybrid-azure-ad-joined-for-my-windows-10-device'></a>

+### How do I identify the domain join type (Microsoft Entra joined or Microsoft Entra hybrid joined) for my Windows 10 device?

+The following sample output shows that the device is Microsoft Entra joined as *AzureADJoined* is set to *YES*:

+The following sample output shows that the device is Microsoft Entra hybrid joined as *DomainedJoined* is also set to *YES*. The *DomainName* is also shown:

+The default security policy doesn't grant Microsoft Entra permission to sign high privilege accounts on to on-premises resources.

+To unblock the accounts, use **Active Directory Users and Computers** to modify the *msDS-NeverRevealGroup* property of the *Microsoft Entra Kerberos Computer object (CN=AzureADKerberos,OU=Domain Controllers,\<domain-DN>)*.

+* [How is Microsoft Entra Kerberos linked to my on-premises Active Directory Domain Services environment?](#how-is-azure-ad-kerberos-linked-to-my-on-premises-active-directory-domain-services-environment)

+* [Where can I view these Kerberos server objects that are created in AD and published in Microsoft Entra ID?](#where-can-i-view-these-kerberos-server-objects-that-are-created-in-ad-ds-and-published-in-azure-ad)

+* [Why do we need Microsoft Entra Connect? Does it write any info back to AD DS from Microsoft Entra ID?](#why-do-we-need-azure-ad-connect-does-it-write-any-info-back-to-ad-ds-from-azure-ad)

+<a name='how-is-azure-ad-kerberos-linked-to-my-on-premises-active-directory-domain-services-environment'></a>

+### How is Microsoft Entra Kerberos linked to my on-premises Active Directory Domain Services environment?

+There are two parts: the on-premises AD DS environment and the Microsoft Entra tenant.

+The Microsoft Entra Kerberos server is represented in an on-premises AD DS environment as a domain controller (DC) object. This DC object is made up of multiple objects:

+* *CN=900274c4-b7d2-43c8-90ee-00a9f650e335,CN=Microsoft Entra ID,CN=System,\<domain-DN>*

+ A *ServiceConnectionPoint* object that stores metadata about the Microsoft Entra Kerberos server objects. The administrative tools use this object to identify and locate the Microsoft Entra Kerberos server objects.

+**Microsoft Entra ID**

+The Microsoft Entra Kerberos server is represented in Microsoft Entra ID as a *KerberosDomain* object. Each on-premises AD DS environment is represented as a single *KerberosDomain* object in the Microsoft Entra tenant.

+For example, you may have an AD DS forest with two domains such as *contoso.com* and *fabrikam.com*. If you allow Microsoft Entra ID to issue Kerberos Ticket Granting Tickets (TGTs) for the entire forest, there are two *KerberosDomain* objects in Microsoft Entra ID - one object for *contoso.com* and one for *fabrikam.com*.

+<a name='where-can-i-view-these-kerberos-server-objects-that-are-created-in-ad-ds-and-published-in-azure-ad'></a>

+### Where can I view these Kerberos server objects that are created in AD DS and published in Microsoft Entra ID?

+To view all objects, use the Microsoft Entra Kerberos server PowerShell cmdlets included with the latest version of Microsoft Entra Connect.

+Like any other DC, the Microsoft Entra Kerberos server encryption *krbtgt* keys should be rotated on a regular basis. It's recommended to follow the same schedule as you use to rotate all other AD DS *krbtgt* keys.

+> Although there are other tools to rotate the *krbtgt* keys, you must [use the PowerShell cmdlets to rotate the *krbtgt* keys](howto-authentication-passwordless-security-key-on-premises.md#rotate-the-azure-ad-kerberos-server-key) of your Microsoft Entra Kerberos server. This method makes sure that the keys are updated in both the on-premises AD DS environment and in Microsoft Entra ID.

+<a name='why-do-we-need-azure-ad-connect-does-it-write-any-info-back-to-ad-ds-from-azure-ad'></a>

+### Why do we need Microsoft Entra Connect? Does it write any info back to AD DS from Microsoft Entra ID?

+Microsoft Entra Connect doesn't write info back from Microsoft Entra ID to AD DS. The utility includes the PowerShell module to create the Kerberos Server Object in AD DS and publish it in Microsoft Entra ID.

+Microsoft Entra ID combines the encrypted client key and message buffer into the PRT response as additional properties. The payload is encrypted using the Microsoft Entra Device session key.

+description: Enable passwordless sign-in to Microsoft Entra ID using Microsoft Authenticator

+Microsoft Authenticator can be used to sign in to any Microsoft Entra account without using a password. Microsoft Authenticator uses key-based authentication to enable a user credential that is tied to a device, where the device uses a PIN or biometric. [Windows Hello for Business](/windows/security/identity-protection/hello-for-business/hello-identity-verification) uses a similar technology.

+You can enable passwordless phone sign-in for multiple accounts in Microsoft Authenticator on any supported iOS device. Consultants, students, and others with multiple accounts in Microsoft Entra ID can add each account to Microsoft Authenticator and use passwordless phone sign-in for all of them from the same iOS device.

+The Microsoft Entra accounts can be in the same tenant or different tenants. Guest accounts aren't supported for multiple account sign-ins from one device.

+- Recommended: Microsoft Entra multifactor authentication, with push notifications allowed as a verification method. Push notifications to your smartphone or tablet help the Authenticator app to prevent unauthorized access to accounts and stop fraudulent transactions. The Authenticator app automatically generates codes when set up to do push notifications. A user has a backup sign-in method even if their device doesn't have connectivity.

+To use passwordless authentication in Microsoft Entra ID, first enable the combined registration experience, then enable users for the passwordless method.

+Microsoft Entra ID lets you choose which authentication methods can be used during the sign-in process. Users then register for the methods they'd like to use. The **Microsoft Authenticator** authentication method policy manages both the traditional push MFA method and the passwordless authentication method.

+Users register themselves for the passwordless authentication method of Microsoft Entra ID. For users who already registered the Microsoft Authenticator app for [multifactor authentication](./concept-mfa-howitworks.md), skip to the next section, [enable phone sign-in](#enable-phone-sign-in).

+When a user has enabled any passwordless credential, the Microsoft Entra login process stops using the login\_hint. Therefore the process no longer accelerates the user toward a federated login location.

+An end user can be enabled for multifactor authentication through an on-premises identity provider. The user can still create and utilize a single passwordless phone sign-in credential.

+To learn about Microsoft Entra authentication and passwordless methods, see the following articles:

+- [Learn about Microsoft Entra multifactor authentication](../authentication/howto-mfa-getstarted.md)

+description: Learn how to enable passwordless security key sign-in to on-premises resources by using Microsoft Entra ID

+# Enable passwordless security key sign-in to on-premises resources by using Microsoft Entra ID

+This document discusses how to enable passwordless authentication to on-premises resources for environments with both *Microsoft Entra joined* and *Microsoft Entra hybrid joined* Windows 10 devices. This passwordless authentication functionality provides seamless single sign-on (SSO) to on-premises resources when you use Microsoft-compatible security keys, or with [Windows Hello for Business Cloud trust](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust)

+Microsoft Entra ID can issue Kerberos ticket-granting tickets (TGTs) for one or more of your Active Directory domains. With this functionality, users can sign in to Windows with modern credentials, such as FIDO2 security keys, and then access traditional Active Directory-based resources. Kerberos Service Tickets and authorization continue to be controlled by your on-premises Active Directory domain controllers (DCs).

+A Microsoft Entra Kerberos server object is created in your on-premises Active Directory instance and then securely published to Microsoft Entra ID. The object isn't associated with any physical servers. It's simply a resource that can be used by Microsoft Entra ID to generate Kerberos TGTs for your Active Directory domain.

+1. A user signs in to a Windows 10 device with an FIDO2 security key and authenticates to Microsoft Entra ID.

+1. Microsoft Entra ID checks the directory for a Kerberos Server key that matches the user's on-premises Active Directory domain.

+ Microsoft Entra ID generates a Kerberos TGT for the user's on-premises Active Directory domain. The TGT includes the user's SID only, and no authorization data.

+1. The TGT is returned to the client along with the user's Microsoft Entra Primary Refresh Token (PRT).

+1. The client machine now has a Microsoft Entra PRT and a full Active Directory TGT and can access both cloud and on-premises resources.

+ - A Microsoft Entra user who is a member of the Global Administrators role. Referred to as **$cloudCred**.

+<a name='install-the-azure-ad-kerberos-powershell-module'></a>

+## Install the Microsoft Entra Kerberos PowerShell module

+The [Microsoft Entra Kerberos PowerShell module](https://www.powershellgallery.com/packages/AzureADHybridAuthenticationManagement) provides FIDO2 management features for administrators.

+1. Install the Microsoft Entra Kerberos PowerShell module:

+> - The Microsoft Entra Kerberos PowerShell module uses the [AzureADPreview PowerShell module](https://www.powershellgallery.com/packages/AzureADPreview) to provide advanced Microsoft Entra management features. If the [Azure Active Directory PowerShell module](https://www.powershellgallery.com/packages/AzureAD) is already installed on your local computer, the installation described here might fail because of conflict. To prevent any conflicts during installation, be sure to include the "-AllowClobber" option flag.

+> - You can install the Microsoft Entra Kerberos PowerShell module on any computer from which you can access your on-premises Active Directory Domain Controller, without dependency on the Microsoft Entra Connect solution.

+> - The Microsoft Entra Kerberos PowerShell module is distributed through the [PowerShell Gallery](https://www.powershellgallery.com/). The PowerShell Gallery is the central repository for PowerShell content. In it, you can find useful PowerShell modules that contain PowerShell commands and Desired State Configuration (DSC) resources.

+Administrators use the Microsoft Entra Kerberos PowerShell module to create a Microsoft Entra Kerberos server object in their on-premises directory.

+Run the following steps in each domain and forest in your organization that contain Microsoft Entra users:

+1. Run the following PowerShell commands to create a new Microsoft Entra Kerberos server object both in your on-premises Active Directory domain and in your Microsoft Entra tenant.

+<a name='view-and-verify-the-azure-ad-kerberos-server'></a>

+### View and verify the Microsoft Entra Kerberos server

+You can view and verify the newly created Microsoft Entra Kerberos server by using the following command:

+This command outputs the properties of the Microsoft Entra Kerberos server. You can review the properties to verify that everything is in good order.

+| ComputerAccount | The computer account object of the Microsoft Entra Kerberos server object (the DC). |

+| UserAccount | The disabled user account object that holds the Microsoft Entra Kerberos server TGT encryption key. The domain name of this account is `CN=krbtgt_AzureAD,CN=Users,<Domain-DN>`. |

+| KeyVersion | The key version of the Microsoft Entra Kerberos server TGT encryption key. The version is assigned when the key is created. The version is then incremented every time the key is rotated. The increments are based on replication metadata and likely greater than one. For example, the initial *KeyVersion* could be *192272*. The first time the key is rotated, the version could advance to *212621*. The important thing to verify is that the *KeyVersion* for the on-premises object and the *CloudKeyVersion* for the cloud object are the same. |

+| KeyUpdatedOn | The date and time that the Microsoft Entra Kerberos server TGT encryption key was updated or created. |

+| KeyUpdatedFrom | The DC where the Microsoft Entra Kerberos server TGT encryption key was last updated. |

+| CloudId | The ID from the Microsoft Entra object. Must match the ID from the first line of the table. |

+| CloudDomainDnsName | The *DomainDnsName* from the Microsoft Entra object. Must match the *DomainDnsName* from the second line of the table. |

+| CloudKeyVersion | The *KeyVersion* from the Microsoft Entra object. Must match the *KeyVersion* from the fifth line of the table. |

+| CloudKeyUpdatedOn | The *KeyUpdatedOn* from the Microsoft Entra object. Must match the *KeyUpdatedOn* from the sixth line of the table. |

+<a name='rotate-the-azure-ad-kerberos-server-key'></a>

+### Rotate the Microsoft Entra Kerberos server key

+The Microsoft Entra Kerberos server encryption *krbtgt* keys should be rotated on a regular basis. We recommend that you follow the same schedule you use to rotate all other Active Directory DC *krbtgt* keys.

+> There are other tools that could rotate the *krbtgt* keys. However, you must use the tools mentioned in this document to rotate the *krbtgt* keys of your Microsoft Entra Kerberos server. This ensures that the keys are updated in both on-premises Active Directory and Microsoft Entra ID.

+<a name='remove-the-azure-ad-kerberos-server'></a>

+### Remove the Microsoft Entra Kerberos server

+If you want to revert the scenario and remove the Microsoft Entra Kerberos server from both the on-premises Active Directory and Microsoft Entra ID, run the following command:

+The Microsoft Entra Kerberos server object is represented in Microsoft Entra ID as a *KerberosDomain* object. Each on-premises Active Directory domain is represented as a single *KerberosDomain* object in Microsoft Entra ID.

+For example, let's say that your organization has an Active Directory forest with two domains, `contoso.com` and `fabrikam.com`. If you choose to allow Microsoft Entra ID to issue Kerberos TGTs for the entire forest, there are two *KerberosDomain* objects in Microsoft Entra ID, one *KerberosDomain* object for `contoso.com` and the other for `fabrikam.com`. If you have multiple Active Directory forests, there is one *KerberosDomain* object for each domain in each forest.

+Follow the instructions in [Create a Kerberos Server object](#create-a-kerberos-server-object) in each domain and forest in your organization that contains Microsoft Entra users.

+<a name='what-can-i-do-if-im-unable-to-use-the-fido-security-key-immediately-after-i-create-a-hybrid-azure-ad-joined-machine'></a>

+### What can I do if I'm unable to use the FIDO security key immediately after I create a Microsoft Entra hybrid joined machine?

+If you're clean-installing a Microsoft Entra hybrid joined machine, after the domain join and restart process, you must sign in with a password and wait for the policy to sync before you can use the FIDO security key to sign in.

+description: Learn how to enable passwordless security key sign-in to Microsoft Entra ID using FIDO2 security keys

+# Enable passwordless security key sign-in to Windows 10 devices with Microsoft Entra ID

+This document focuses on enabling FIDO2 security key based passwordless authentication with Windows 10 devices. At the end of this article, you will be able to sign in to both your Microsoft Entra ID and Microsoft Entra hybrid joined Windows 10 devices with your Microsoft Entra account using a FIDO2 security key.

+| Device Type | Microsoft Entra joined | Microsoft Entra hybrid joined |

+| [Microsoft Entra multifactor authentication](howto-mfa-getstarted.md) | X | X |

+| [Microsoft Entra joined devices](../devices/concept-directory-join.md) require Windows 10 version 1909 or higher | X | |

+| [Microsoft Entra hybrid joined devices](../devices/concept-hybrid-join.md) require Windows 10 version 2004 or higher | | X |

+| [Microsoft Entra Hybrid Authentication Management module](https://www.powershellgallery.com/packages/AzureADHybridAuthenticationManagement/2.1.1.0) | | X |

+- Signing in or unlocking a Windows 10 device with a security key containing multiple Microsoft Entra accounts. This scenario utilizes the last account added to the security key. WebAuthN allows users to choose the account they wish to use.

+Microsoft Entra joined devices must run Windows 10 version 1909 or higher.

+Microsoft Entra hybrid joined devices must run Windows 10 version 2004 or newer.

+- [Enable with Group Policy (Microsoft Entra hybrid joined devices only)](#enable-with-group-policy)

+> Organizations with **Microsoft Entra hybrid joined devices** must **also** complete the steps in the article, [Enable FIDO2 authentication to on-premises resources](howto-authentication-passwordless-security-key-on-premises.md) before Windows 10 FIDO2 security key authentication works.

+> Organizations with **Microsoft Entra joined devices** must do this before their devices can authenticate to on-premises resources with FIDO2 security keys.

+For **Microsoft Entra hybrid joined devices**, organizations can configure the following Group Policy setting to enable FIDO security key sign-in. The setting can be found under **Computer Configuration** > **Administrative Templates** > **System** > **Logon** > **Turn on security key sign-in**:

+In the example below, a user named Bala Sandhu has already provisioned their FIDO2 security key using the steps in the previous article, [Enable passwordless security key sign in](howto-authentication-passwordless-security-key.md#user-registration-and-management-of-fido2-security-keys). For Microsoft Entra hybrid joined devices, make sure you have also [enabled passwordless security key sign-in to on-premises resources](howto-authentication-passwordless-security-key-on-premises.md). Bala can choose the security key credential provider from the Windows 10 lock screen and insert the security key to sign into Windows.

+[Enable access to on-premises resources for Microsoft Entra ID and Microsoft Entra hybrid joined devices](howto-authentication-passwordless-security-key-on-premises.md)

+[Learn more about Microsoft Entra multifactor authentication](../authentication/howto-mfa-getstarted.md)

+description: Enable passwordless security key sign-in to Microsoft Entra ID using FIDO2 security keys

+This document focuses on enabling security key based passwordless authentication. At the end of this article, you'll be able to sign in to web-based applications with your Microsoft Entra account using a FIDO2 security key.

+- [Microsoft Entra multifactor authentication](howto-mfa-getstarted.md)

+For Microsoft Entra joined devices, the best experience is on Windows 10 version 1903 or higher.

+Microsoft Entra hybrid joined devices must run Windows 10 version 2004 or higher.

+ 1. If the user already has at least one Microsoft Entra multifactor authentication method registered, they can immediately register a FIDO2 security key.

+ 1. If they don't have at least one Microsoft Entra multifactor authentication method registered, they must add one.

+[Learn more about Microsoft Entra multifactor authentication](../authentication/howto-mfa-getstarted.md)

+description: Learn about some known issues and ways to troubleshoot passwordless hybrid FIDO2 security key sign-in using Microsoft Entra ID

+# Troubleshooting for hybrid deployments of FIDO2 security keys in Microsoft Entra ID

+This article covers frequently asked questions for Microsoft Entra hybrid joined devices and passwordless sign-in to on-prem resources. With this passwordless feature, you can enable Microsoft Entra authentication on Windows 10 devices for Microsoft Entra hybrid joined devices using FIDO2 security keys. Users can sign into Windows on their devices with modern credentials like FIDO2 keys and access traditional Active Directory Domain Services (AD DS) based resources with a seamless single sign-on (SSO) experience to their on-prem resources.

+* Sign in to Microsoft Entra hybrid joined devices using FIDO2 security keys and get SSO access to on-prem resources.

+* Sign in to Microsoft Entra joined devices using FIDO2 security keys and get SSO access to on-prem resources.

+* [Users aren't able to use FIDO2 security keys immediately after they create a Microsoft Entra hybrid joined machine](#users-arent-able-to-use-fido2-security-keys-immediately-after-they-create-a-hybrid-azure-ad-joined-machine)

+<a name='users-arent-able-to-use-fido2-security-keys-immediately-after-they-create-a-hybrid-azure-ad-joined-machine'></a>

+### Users aren't able to use FIDO2 security keys immediately after they create a Microsoft Entra hybrid joined machine

+After the domain-join and restart process on a clean install of a Microsoft Entra hybrid joined machine, you must sign in with a password and wait for policy to synchronize before you can use to use a FIDO2 security key to sign in.

+To troubleshoot issues with deploying the Microsoft Entra Kerberos server, use the logs for the new [AzureADHybridAuthenticationManagement](https://www.powershellgallery.com/packages/AzureADHybridAuthenticationManagement) PowerShell module.

+The Microsoft Entra Kerberos server PowerShell cmdlets in the [AzureADHybridAuthenticationManagement](https://www.powershellgallery.com/packages/AzureADHybridAuthenticationManagement) module use the same logging as the standard Microsoft Entra Connect Wizard. To view information or error details from the cmdlets, complete the following steps:

+<a name='viewing-the-azure-ad-kerberos-server-objects'></a>

+#### Viewing the Microsoft Entra Kerberos server Objects

+To view the Microsoft Entra Kerberos server Objects and verify they are in good order, complete the following steps:

+1. On the Microsoft Entra Connect Server or any other machine where the [AzureADHybridAuthenticationManagement](https://www.powershellgallery.com/packages/AzureADHybridAuthenticationManagement) module is installed, open PowerShell and navigate to `C:\Program Files\Microsoft Azure Active Directory Connect\AzureADKerberos\`

+1. Run the following PowerShell commands to view the Microsoft Entra Kerberos server from both Microsoft Entra ID and on-premises AD DS.

+The command outputs the properties of the Microsoft Entra Kerberos server from both Microsoft Entra ID and on-premises AD DS. Review the properties to verify that everything is in good order. Use the table below to verify the properties.

+The first set of properties is from the objects in the on-premises AD DS environment. The second half (the properties that begin with *Cloud**) are from the Kerberos Server object in Microsoft Entra ID:

+| ComputerAccount | The computer account object of the Microsoft Entra Kerberos server object (the DC). |

+| UserAccount | The disabled user account object that holds the Microsoft Entra Kerberos server TGT encryption key. The DN of this account is *CN=krbtgt_AzureAD,CN=Users,\<Domain-DN\>* |

+| KeyVersion | The key version of the Microsoft Entra Kerberos server TGT encryption key. The version is assigned when the key is created. The version is then incremented every time the key is rotated. The increments are based on replication meta-data and will likely be greater than one.<br /><br /> For example, the initial *KeyVersion* could be *192272*. The first time the key is rotated, the version could advance to *212621*.<br /><br /> The important thing to verify is that the *KeyVersion* for the on-premises object and the *CloudKeyVersion* for the cloud object are the same. |

+| KeyUpdatedOn | The date and time that the Microsoft Entra Kerberos server TGT encryption key was updated or created. |

+| KeyUpdatedFrom | The DC where the Microsoft Entra Kerberos server TGT encryption key was last updated. |

+| CloudId | The *Id* from the Microsoft Entra Object. Must match the *Id* above. |

+| CloudDomainDnsName | The *DomainDnsName* from the Microsoft Entra Object. Must match the *DomainDnsName* above. |

+| CloudKeyVersion | The *KeyVersion* from the Microsoft Entra Object. Must match the *KeyVersion* above. |

+| CloudKeyUpdatedOn | The *KeyUpdatedOn* from the Microsoft Entra Object. Must match the *KeyUpdatedOn* above. |

+ Title: SMS-based user sign-in for Microsoft Entra ID

+description: Learn how to configure and enable users to sign-in to Microsoft Entra ID using SMS

+# Configure and enable users for SMS-based authentication using Microsoft Entra ID

+To simplify and secure sign-in to applications and services, Microsoft Entra ID provides multiple authentication options. SMS-based authentication lets users sign-in without providing, or even knowing, their user name and password. After their account is created by an identity administrator, they can enter their phone number at the sign-in prompt. They receive an SMS authentication code that they can provide to complete the sign-in. This authentication method simplifies access to applications and services, especially for Frontline workers.

+This article shows you how to enable SMS-based authentication for select users or groups in Microsoft Entra ID. For a list of apps that support using SMS-based sign-in, see [App support for SMS-based authentication](how-to-authentication-sms-supported-apps.md).

+* A Microsoft Entra tenant associated with your subscription.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+* You need *global administrator* privileges in your Microsoft Entra tenant to enable SMS-based authentication.

+* Each user that's enabled in the SMS authentication method policy must be licensed, even if they don't use it. Each enabled user must have one of the following Microsoft Entra ID, EMS, Microsoft 365 licenses:

+ * [Microsoft Entra ID P1 or P2][azure-ad-pricing]

+* SMS-based authentication isn't currently compatible with Microsoft Entra multifactor authentication.

+First, let's enable SMS-based authentication for your Microsoft Entra tenant.

+With SMS-based authentication enabled in your Microsoft Entra tenant, now select some users or groups to be allowed to use this authentication method.

+Users are now enabled for SMS-based authentication, but their phone number must be associated with the user profile in Microsoft Entra ID before they can sign-in. The user can [set this phone number themselves](https://support.microsoft.com/account-billing/set-up-sms-sign-in-as-a-phone-verification-method-0aa5b3b3-a716-4ff2-b0d6-31d2bcfbac42) in *My Account*, or you can assign the phone number using the Microsoft Entra admin center. Phone numbers can be set by *global admins*, *authentication admins*, or *privileged authentication admins*.

+When a phone number is set for SMS-based sign-in, it's also then available for use with [Microsoft Entra multifactor authentication][tutorial-azure-mfa] and [self-service password reset][tutorial-sspr].

+1. Search for and select **Microsoft Entra ID**.

+1. From the navigation menu on the left-hand side of the Microsoft Entra window, select **Users**.

+If a user has already registered for Microsoft Entra multifactor authentication and / or self-service password reset (SSPR), they already have a phone number associated with their account. This phone number isn't automatically available for use with SMS-based sign-in.

+A user that has a phone number already set for their account is displayed a button to *Enable for SMS sign-in* in their **My Profile** page. Select this button, and the account is enabled for use with SMS-based sign-in and the previous Microsoft Entra multifactor authentication or SSPR registration.

+- For more ways to sign-in to Microsoft Entra ID without a password, such as the Microsoft Authenticator App or FIDO2 security keys, see [Passwordless authentication options for Microsoft Entra ID][concepts-passwordless].

+ Title: Configure a Temporary Access Pass in Microsoft Entra ID to register passwordless authentication methods

+# Configure Temporary Access Pass in Microsoft Entra ID to register passwordless authentication methods

+- Using existing Microsoft Entra multifactor authentication methods

+After you enable a policy, you can create a Temporary Access Pass for a user in Microsoft Entra ID.

+>For federated domains, a Temporary Access Pass is preferred over federation. A user with a Temporary Access Pass completes the authentication in Microsoft Entra ID and isn't redirected to the federated Identity Provider (IdP).

+For joined devices to Microsoft Entra ID:

+- Users in scope for Self Service Password Reset (SSPR) registration policy *or* [Identity Protection multifactor authentication registration policy](../identity-protection/howto-identity-protection-configure-mfa-policy.md) are required to register authentication methods after they've signed in with a Temporary Access Pass using a browser.

+- [Plan a passwordless authentication deployment in Microsoft Entra ID](howto-authentication-passwordless-deployment.md)

+ Title: Sign-in to Microsoft Entra ID with email as an alternate login ID

+description: Learn how to enable users to sign in to Microsoft Entra ID with their email as an alternate login ID

+# Sign-in to Microsoft Entra ID with email as an alternate login ID (Preview)

+> Sign-in to Microsoft Entra ID with email as an alternate login ID is a public preview feature of Microsoft Entra ID. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://aka.ms/EntraPreviewsTermsOfUse).

+Many organizations want to let users sign in to Microsoft Entra ID using the same credentials as their on-premises directory environment. With this approach, known as hybrid authentication, users only need to remember one set of credentials.

+* By default, the Microsoft Entra User Principal Name (UPN) is set to the same value as the on-premises UPN.

+* Changing the Microsoft Entra UPN creates a mismatch between on-premises and Microsoft Entra environments that could cause problems with certain applications and services.

+* Due to business or compliance reasons, the organization doesn't want to use the on-premises UPN to sign in to Microsoft Entra ID.

+To move toward hybrid authentication, you can configure Microsoft Entra ID to let users sign in with their email as an alternate login ID. For example, if *Contoso* rebranded to *Fabrikam*, rather than continuing to sign in with the legacy `ana@contoso.com` UPN, email as an alternate login ID can be used. To access an application or service, users would sign in to Microsoft Entra ID using their non-UPN email, such as `ana@fabrikam.com`.

+* The feature is available in Microsoft Entra ID Free edition and higher.

+* The feature enables sign-in with *ProxyAddresses*, in addition to UPN, for cloud-authenticated Microsoft Entra users. More on how this applies to Microsoft Entra business-to-business (B2B) collaboration in the [B2B](#b2b-guest-user-sign-in-with-an-email-address) section.

+ * [Staged rollout policy](#enable-staged-rollout-to-test-user-sign-in-with-an-email-address) - Use this option to test the feature with specific Microsoft Entra groups. Global Administrator privileges required. When you first add a security group for staged rollout, you're limited to 200 users to avoid a UX time-out. After you've added the group, you can add more users directly to it, as required.

+ * User is prompted to sign in with UPN when directed to Microsoft Entra sign-in with `login_hint=<non-UPN email>`.

+ * When a user is signed-in with a non-UPN email, they cannot change their password. Microsoft Entra self-service password reset (SSPR) should work as expected. During SSPR, the user may see their UPN if they verify their identity using a non-UPN email.

+ * [Microsoft Entra hybrid joined devices](../devices/concept-hybrid-join.md)

+ * [Microsoft Entra joined devices](../devices/concept-directory-join.md)

+ * [Microsoft Entra registered devices](../devices/concept-device-registration.md)

+To sign in to Microsoft Entra ID, users enter a value that uniquely identifies their account. Historically, you could only use the Microsoft Entra UPN as the sign-in identifier.

+For organizations where the on-premises UPN is the user's preferred sign-in email, this approach was great. Those organizations would set the Microsoft Entra UPN to the exact same value as the on-premises UPN, and users would have a consistent sign-in experience.

+However, in some organizations the on-premises UPN isn't used as a sign-in identifier. In the on-premises environments, you would configure the local AD DS to allow sign-in with an alternate login ID. Setting the Microsoft Entra UPN to the same value as the on-premises UPN isn't an option as Microsoft Entra ID would then require users to sign in with that value.

+<a name='alternate-login-id-in-azure-ad-connect'></a>

+### Alternate Login ID in Microsoft Entra Connect

+The typical workaround to this issue was to set the Microsoft Entra UPN to the email address the user expects to sign in with. This approach works, though results in different UPNs between the on-premises AD and Microsoft Entra ID, and this configuration isn't compatible with all Microsoft 365 workloads.

+A different approach is to synchronize the Microsoft Entra ID and on-premises UPNs to the same value and then configure Microsoft Entra ID to allow users to sign in to Microsoft Entra ID with a verified email. To provide this ability, you define one or more email addresses in the user's *ProxyAddresses* attribute in the on-premises directory. *ProxyAddresses* are then synchronized to Microsoft Entra ID automatically using Microsoft Entra Connect.

+| [Alternate Login ID in Microsoft Entra Connect](../hybrid/connect/plan-connect-userprincipalname.md#alternate-login-id) | Synchronize an alternate attribute (such as Mail) as the Microsoft Entra UPN. |

+| Email as an Alternate Login ID | Enable sign-in with verified domain *ProxyAddresses* for Microsoft Entra users. |

+<a name='synchronize-sign-in-email-addresses-to-azure-ad'></a>

+## Synchronize sign-in email addresses to Microsoft Entra ID

+Traditional Active Directory Domain Services (AD DS) or Active Directory Federation Services (AD FS) authentication happens directly on your network and is handled by your AD DS infrastructure. With hybrid authentication, users can instead sign in directly to Microsoft Entra ID.

+To support this hybrid authentication approach, you synchronize your on-premises AD DS environment to Microsoft Entra ID using [Microsoft Entra Connect][azure-ad-connect] and configure it to use PHS or PTA. For more information, see [Choose the right authentication method for your Microsoft Entra hybrid identity solution][hybrid-auth-methods].

+In both configuration options, the user submits their username and password to Microsoft Entra ID, which validates the credentials and issues a ticket. When users sign in to Microsoft Entra ID, it removes the need for your organization to host and manage an AD FS infrastructure.

+One of the user attributes that's automatically synchronized by Microsoft Entra Connect is *ProxyAddresses*. If users have an email address defined in the on-premises AD DS environment as part of the *ProxyAddresses* attribute, it's automatically synchronized to Microsoft Entra ID. This email address can then be used directly in the Microsoft Entra sign-in process as an alternate login ID.

+> Only emails in verified domains for the tenant are synchronized to Microsoft Entra ID. Each Microsoft Entra tenant has one or more verified domains, for which you have proven ownership, and are uniquely bound to your tenant.

+> For more information, see [Add and verify a custom domain name in Microsoft Entra ID][verify-domain].

+Email as an alternate login ID applies to [Microsoft Entra B2B collaboration](../external-identities/what-is-b2b.md) under a "bring your own sign-in identifiers" model. When email as an alternate login ID is enabled in the home tenant, Microsoft Entra users can perform guest sign in with non-UPN email on the resource tenant endpoint. No action is required from the resource tenant to enable this functionality.

+Once users with the *ProxyAddresses* attribute applied are synchronized to Microsoft Entra ID using Microsoft Entra Connect, you need to enable the feature for users to sign in with email as an alternate login ID for your tenant. This feature tells the Microsoft Entra login servers to not only check the sign-in identifier against UPN values, but also against *ProxyAddresses* values for the email address.

+1. From the navigation menu on the left-hand side of the Microsoft Entra window, select **Microsoft Entra Connect > Email as alternate login ID**.

+Once users with the *ProxyAddresses* attribute applied are synchronized to Microsoft Entra ID using Microsoft Entra Connect, you need to enable the feature for users to sign-in with email as an alternate login ID for your tenant. This feature tells the Microsoft Entra login servers to not only check the sign-in identifier against UPN values, but also against *ProxyAddresses* values for the email address.

+1. Sign-in to your Microsoft Entra tenant using the `Connect-MgGraph` cmdlet:

+Staged rollout policy allows tenant administrators to enable features for specific Microsoft Entra groups. It is recommended that tenant administrators use staged rollout to test user sign-in with an email address. When administrators are ready to deploy this feature to their entire tenant, they should use [HRD policy](#enable-user-sign-in-with-an-email-address).

+1. Sign in to your Microsoft Entra tenant as a *Global Administrator* using the [Connect-AzureAD][Connect-AzureAD] cmdlet:

+1. Add the group to the staged rollout policy as shown in the following example. Replace the value in the *-Id* parameter with the value returned for the policy ID in step 4 and replace the value in the *-RefObjectId* parameter with the *Id* noted in step 5. It may take up to 1 hour before users in the group can sign in to Microsoft Entra ID with email as an alternate login ID.

+For new members added to the group, it may take up to 24 hours before they can sign in to Microsoft Entra ID with email as an alternate login ID.

+1. If using HRD policy, confirm that the Microsoft Entra ID *HomeRealmDiscoveryPolicy* has the *AlternateIdLogin* definition property set to *"Enabled": true* and the *IsOrganizationDefault* property set to *True*:

+ If using staged rollout policy, confirm that the Microsoft Entra ID *FeatureRolloutPolicy* has the *IsEnabled* property set to *True*:

+1. Make sure the user account has their email address set in the *ProxyAddresses* attribute in Microsoft Entra ID.

+You can review the [sign-in logs in Microsoft Entra ID][sign-in-logs] for more information. Sign-ins with email as an alternate login ID will emit `proxyAddress` in the *Sign-in identifier type* field and the inputted username in the *Sign-in identifier* field.

+1. Sign in to your Microsoft Entra tenant as a *Global Administrator* using the [Connect-AzureAD][Connect-AzureAD] cmdlet:

+To learn more about hybrid identity, such as Microsoft Entra application proxy or Microsoft Entra Domain Services, see [Microsoft Entra hybrid identity for access and management of on-prem workloads][hybrid-overview].

+ Title: Secure resources with Microsoft Entra multifactor authentication and ADFS

+description: This is the Microsoft Entra multifactor authentication page that describes how to get started with Microsoft Entra multifactor authentication and AD FS in the cloud.

+# Securing cloud resources with Microsoft Entra multifactor authentication and AD FS

+If your organization is federated with Microsoft Entra ID, use Microsoft Entra multifactor authentication or Active Directory Federation Services (AD FS) to secure resources that are accessed by Microsoft Entra ID. Use the following procedures to secure Microsoft Entra resources with either Microsoft Entra multifactor authentication or Active Directory Federation Services.

+<a name='secure-azure-ad-resources-using-ad-fs'></a>

+## Secure Microsoft Entra resources using AD FS

+To secure your cloud resource, set up a claims rule so that Active Directory Federation Services emits the multipleauthn claim when a user performs two-step verification successfully. This claim is passed on to Microsoft Entra ID. Follow this procedure to walk through the steps:

+<a name='configure-azure-ad-multi-factor-authentication-trusted-ips-with-federated-users'></a>

+### Configure Microsoft Entra multifactor authentication Trusted IPs with federated users

+ 

+4. On the Service Settings page, under **trusted IPs**, select **Skip multifactor-authentication for requests from federated users on my intranet**.

+ Title: Configure app passwords for Microsoft Entra multifactor authentication

+description: Learn how to configure and use app passwords for legacy applications in Microsoft Entra multifactor authentication

+# Enforce Microsoft Entra multifactor authentication with legacy applications using app passwords

+Some older, non-browser apps like Office 2010 or earlier and Apple Mail before iOS 11 don't understand pauses or breaks in the authentication process. A Microsoft Entra multifactor authentication (Microsoft Entra multifactor authentication) user who attempts to sign in to one of these older, non-browser apps, can't successfully authenticate. To use these applications in a secure way with Microsoft Entra multifactor authentication enforced for user accounts, you can use app passwords. These app passwords replaced your traditional password to allow an app to bypass multifactor authentication and work correctly.

+Modern authentication is supported for the Microsoft Office 2013 clients and later. Office 2013 clients, including Outlook, support modern authentication protocols and can work with two-step verification. After Microsoft Entra multifactor authentication is enforced, app passwords aren't required for the client.

+This article shows you how to use app passwords for legacy applications that don't support multifactor authentication prompts.

+When a user account is enforced for Microsoft Entra multifactor authentication, the regular sign-in prompt is interrupted by a request for additional verification. Some older applications don't understand this break in the sign-in process, so authentication fails. To maintain user account security and leave Microsoft Entra multifactor authentication enforced, app passwords can be used instead of the user's regular username and password. When an app password used during sign-in, there's no additional verification prompt, so authentication is successful.

+* After Microsoft Entra multifactor authentication is enforced on a user's account, app passwords can be used with most non-browser clients like Outlook and Microsoft Skype for Business. However, administrative actions can't be performed by using app passwords through non-browser applications, such as Windows PowerShell. The actions can't be performed even when the user has an administrative account.

+Microsoft Entra ID supports federation, or single sign-on (SSO), with on-premises Active Directory Domain Services (AD DS). If your organization is federated with Microsoft Entra ID and you're using Microsoft Entra multifactor authentication, the following app password considerations apply:

+* App passwords are verified by Microsoft Entra ID, 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 Microsoft Entra ID.

+Some advanced architectures require a combination of credentials for multifactor authentication 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 Microsoft Entra ID, an app password is required.

+* Your on-premises instance of Active Directory is federated with Microsoft Entra ID.

+* You use Microsoft Entra multifactor authentication.

+6. On the **multifactor authentication** page, select the **Allow users to create app passwords to sign in to non-browser apps** option.

+ 

+When users complete their initial registration for Microsoft Entra multifactor authentication, there's an option to create app passwords at the end of the registration process.

+- For more information on how to allow users to quickly register for Microsoft Entra multifactor authentication, see [Combined security information registration overview](concept-registration-mfa-sspr-combined.md).

+- For more information about enabled and enforced user states for Microsoft Entra multifactor authentication, see [Enable per-user Microsoft Entra multifactor authentication to secure sign-in events](howto-mfa-userstates.md)

+ Title: Deployment considerations for Microsoft Entra multifactor authentication

+description: Learn about deployment considerations and strategy for successful implementation of Microsoft Entra multifactor authentication

+# Plan a Microsoft Entra multifactor authentication deployment

+Microsoft Entra multifactor authentication helps safeguard access to data and applications, providing another layer of security by using a second form of authentication. Organizations can enable multifactor authentication with [Conditional Access](../conditional-access/overview.md) to make the solution fit their specific needs.

+This deployment guide shows you how to plan and implement an [Microsoft Entra multifactor authentication](concept-mfa-howitworks.md) roll-out.

+<a name='prerequisites-for-deploying-azure-ad-multi-factor-authentication'></a>

+## Prerequisites for deploying Microsoft Entra multifactor authentication

+|**Hybrid identity** scenarios | Deploy [Microsoft Entra Connect](../hybrid/whatis-hybrid-identity.md) and synchronize user identities between the on-premises Active Directory Domain Services (AD DS) and Microsoft Entra ID. |

+| **On-premises legacy applications** published for cloud access| Deploy [Microsoft Entra application proxy](../app-proxy/application-proxy-deployment-plan.md) |

+- [What authentication and verification methods are available in Microsoft Entra ID?](concept-authentication-methods.md)

+Microsoft Entra multifactor authentication is enforced with Conditional Access policies. These policies allow you to prompt users for MFA when needed for security and stay out of users' way when not needed.

+To learn more about creating Conditional Access policies, see [Conditional Access policy to prompt for Microsoft Entra multifactor authentication when a user signs in](tutorial-enable-azure-mfa.md). This helps you to:

+For end-to-end guidance on Microsoft Entra Conditional Access deployment, see the [Conditional Access deployment plan](../conditional-access/plan-conditional-access.md).

+<a name='common-policies-for-azure-ad-multi-factor-authentication'></a>

+### Common policies for Microsoft Entra multifactor authentication

+Common use cases to require Microsoft Entra multifactor authentication include:

+If your organization uses [Microsoft Entra ID Protection](../identity-protection/overview-identity-protection.md) to detect risk signals, consider using [risk-based policies](../identity-protection/howto-identity-protection-configure-risk-policies.md) instead of named locations. Policies can be created to force password changes when there is a threat of compromised identity or require MFA when a sign-in is deemed [at risk](../identity-protection/howto-identity-protection-configure-risk-policies.md) such as leaked credentials, sign-ins from anonymous IP addresses, and more.

+- [Require all users to register for Microsoft Entra multifactor authentication](../identity-protection/howto-identity-protection-configure-mfa-policy.md)

+When planning your multifactor authentication deployment, it's important to think about how frequently you would like to prompt your users. Asking users for credentials often seems like a sensible thing to do, but it can backfire. If users are trained to enter their credentials without thinking, they can unintentionally supply them to a malicious credential prompt. Microsoft Entra ID has multiple settings that determine how often you need to reauthenticate. Understand the needs of your business and users and configure settings that provide the best balance for your environment.

+For more information, see [Optimize reauthentication prompts and understand session lifetime for Microsoft Entra multifactor authentication](concepts-azure-multi-factor-authentication-prompts-session-lifetime.md).

+A major step in every multifactor authentication deployment is getting users registered to use Microsoft Entra multifactor authentication. Authentication methods such as Voice and SMS allow pre-registration, while others like the Authenticator App require user interaction. Administrators must determine how users will register their methods.

+<a name='combined-registration-for-sspr-and-azure-ad-mfa'></a>

+### Combined registration for SSPR and Microsoft Entra multifactor authentication

+[The combined registration experience for Microsoft Entra multifactor authentication and self-service password reset (SSPR)](howto-registration-mfa-sspr-combined.md) enables users to register for both MFA and SSPR in a unified experience. SSPR allows users to reset their password in a secure way using the same methods they use for Microsoft Entra multifactor authentication. To make sure you understand the functionality and end-user experience, see the [Combined security information registration concepts](concept-registration-mfa-sspr-combined.md).

+Microsoft Entra ID Protection contributes both a registration policy for and automated risk detection and remediation policies to the Microsoft Entra multifactor authentication story. Policies can be created to force password changes when there is a threat of compromised identity or require MFA when a sign-in is deemed risky.

+If you use Microsoft Entra ID Protection, [configure the Microsoft Entra multifactor authentication registration policy](../identity-protection/howto-identity-protection-configure-mfa-policy.md) to prompt your users to register the next time they sign in interactively.

+If you don't have licenses that enable Microsoft Entra ID Protection, users are prompted to register the next time that MFA is required at sign-in.

+Applications that authenticate directly with Microsoft Entra ID and have modern authentication (WS-Fed, SAML, OAuth, OpenID Connect) can make use of Conditional Access policies.

+Some legacy and on-premises applications do not authenticate directly against Microsoft Entra ID and require additional steps to use Microsoft Entra multifactor authentication. You can integrate them by using Microsoft Entra application proxy or [Network policy services](/windows-server/networking/core-network-guide/core-network-guide#BKMK_optionalfeatures).

+We recommend migrating applications secured with Active Directory Federation Services (AD FS) to Microsoft Entra ID. However, if you are not ready to migrate these to Microsoft Entra ID, you can use the Azure multifactor authentication adapter with AD FS 2016 or newer.

+If your organization is federated with Microsoft Entra ID, you can [configure Microsoft Entra multifactor authentication as an authentication provider with AD FS resources](/windows-server/identity/ad-fs/operations/configure-ad-fs-and-azure-mfa) both on-premises and in the cloud.

+<a name='radius-clients-and-azure-ad-multi-factor-authentication'></a>

+### RADIUS clients and Microsoft Entra multifactor authentication

+For applications that are using RADIUS authentication, we recommend moving client applications to modern protocols such as SAML, OpenID Connect, or OAuth on Microsoft Entra ID. If the application cannot be updated, then you can deploy [Network Policy Server (NPS) with the Azure MFA extension](howto-mfa-nps-extension.md). The network policy server (NPS) extension acts as an adapter between RADIUS-based applications and Microsoft Entra multifactor authentication to provide a second factor of authentication.

+Many vendors now support SAML authentication for their applications. When possible, we recommend federating these applications with Microsoft Entra ID and enforcing MFA through Conditional Access. If your vendor doesn't support modern authentication ΓÇô you can use the NPS extension.

+<a name='deploy-azure-ad-multi-factor-authentication'></a>

+## Deploy Microsoft Entra multifactor authentication

+Your Microsoft Entra multifactor authentication rollout plan should include a pilot deployment followed by deployment waves that are within your support capacity. Begin your rollout by applying your Conditional Access policies to a small group of pilot users. After evaluating the effect on the pilot users, process used, and registration behaviors, you can either add more groups to the policy or add more users to the existing groups.

+1. Configure Microsoft Entra multifactor authentication registration policies

+<a name='manage-azure-ad-multi-factor-authentication'></a>

+## Manage Microsoft Entra multifactor authentication

+This section provides reporting and troubleshooting information for Microsoft Entra multifactor authentication.

+Microsoft Entra ID has reports that provide technical and business insights, follow the progress of your deployment and check if your users are successful at sign-in with MFA. Have your business and technical application owners assume ownership of and consume these reports based on your organization's requirements.

+The Microsoft Entra sign-in reports include authentication details for events when a user is prompted for MFA, and if any Conditional Access policies were in use. You can also use PowerShell for reporting on users registered for Microsoft Entra multifactor authentication.

+For more information, and additional Microsoft Entra multifactor authentication reports, see [Review Microsoft Entra multifactor authentication events](howto-mfa-reporting.md#view-the-azure-ad-sign-ins-report).

+<a name='troubleshoot-azure-ad-multi-factor-authentication'></a>

+### Troubleshoot Microsoft Entra multifactor authentication

+See [Troubleshooting Microsoft Entra multifactor authentication](https://support.microsoft.com/help/2937344/troubleshooting-azure-multi-factor-authentication-issues) for common issues.

+ Title: Configure Microsoft Entra multifactor authentication

+description: Learn how to configure settings for Microsoft Entra multifactor authentication

+# Configure Microsoft Entra multifactor authentication settings

+To customize the end-user experience for Microsoft Entra multifactor authentication, you can configure options for settings like account lockout thresholds or fraud alerts and notifications.

+The following Microsoft Entra multifactor authentication settings are available:

+| [Account lockout (MFA Server only)](#account-lockout-mfa-server-only) | Temporarily lock accounts from using Microsoft Entra multifactor authentication if there are too many denied authentication attempts in a row. This feature applies only to users who use MFA Server to enter a PIN to authenticate. |

+| [Block/unblock users](#block-and-unblock-users) | Block specific users from being able to receive Microsoft Entra multifactor authentication requests. Any authentication attempts for blocked users are automatically denied. Users remain blocked for 90 days from the time that they're blocked or until they're manually unblocked. |

+| [OATH tokens](concept-authentication-oath-tokens.md) | Used in cloud-based Microsoft Entra multifactor authentication environments to manage OATH tokens for users. |

+

+1. Browse to **Protection** > **multifactor authentication** > **Account lockout**.

+If a user's device is lost or stolen, you can block Microsoft Entra multifactor authentication attempts for the associated account. Any Microsoft Entra multifactor authentication attempts for blocked users are automatically denied. Users remain blocked for 90 days from the time that they're blocked. For a video that explains how to do this, see [how to block and unblock users in your tenant](https://www.youtube.com/watch?v=WdeE1On4S1o).

+1. Browse to **Microsoft Entra ID** > **Security** > **multifactor authentication** > **Block/unblock users**.

+1. Go to **Microsoft Entra ID** > **Security** > **multifactor authentication** > **Block/unblock users**.

+Users who report an MFA prompt as suspicious are set to **High User Risk**. Administrators can use risk-based policies to limit access for these users, or enable self-service password reset (SSPR) for users to remediate problems on their own. If you previously used the **Fraud Alert** automatic blocking feature and don't have a Microsoft Entra ID P2 license for risk-based policies, you can use risk detection events to identify and disable impacted users and automatically prevent their sign-in. For more information about using risk-based policies, see [Risk-based access policies](../identity-protection/concept-identity-protection-policies.md).

+1. Set **Report suspicious activity** to **Enabled**. The feature remains disabled if you choose **Microsoft managed**. For more information about Microsoft managed values, see [Protecting authentication methods in Microsoft Entra ID](concept-authentication-default-enablement.md).

+- To view the risk detections report, select **Microsoft Entra ID** > **Security** > **Identity Protection** > **Risk detection**. The risk event is part of the standard **Risk Detections** report, and will appear as Detection Type **User Reported Suspicious Activity**, Risk level **High**, Source **End user reported**.

+- To view fraud reports in the Sign-ins report, select **Microsoft Entra ID** > **Sign-in logs** > **Authentication Details**. The fraud report is part of the standard **Microsoft Entra Sign-ins** report and appears in the Result Detail as MFA denied, Fraud Code Entered.

+- To view fraud reports in the Audit logs, select **Microsoft Entra ID** > **Audit logs**. The fraud report appears under Activity type Fraud reported - user is blocked for MFA or Fraud reported - no action taken based on the tenant-level settings for fraud report.

+You can configure Microsoft Entra ID to send email notifications when users report fraud alerts. These notifications are typically sent to identity administrators, because the user's account credentials are likely compromised. The following example shows what a fraud alert notification email looks like:

+1. Go to **Microsoft Entra ID** > **Security** > **multifactor authentication** > **Notifications**.

+Microsoft Entra ID supports the use of OATH TOTP SHA-1 tokens that refresh codes every 30 or 60 seconds. You can purchase these tokens from the vendor of your choice.

+OATH TOTP hardware tokens typically come with a secret key, or seed, pre-programmed in the token. You need to input these keys into Microsoft Entra ID as described in the following steps. Secret keys are limited to 128 characters, which might not be compatible with all tokens. The secret key can contain only the characters *a-z* or *A-Z* and digits *1-7*. It must be encoded in Base32.

+Programmable OATH TOTP hardware tokens that can be reseeded can also be set up with Microsoft Entra ID in the software token setup flow.

+An Authentication Policy Administrator can sign in to the [Microsoft Entra admin center](https://entra.microsoft.com), go to **Protection** > **multifactor authentication** > **OATH tokens**, and upload the CSV file.

+> When Microsoft Entra multifactor authentication calls are placed through the public telephone network, sometimes the calls are routed through a carrier that doesn't support caller ID. Because of this, caller ID isn't guaranteed, even though Microsoft Entra multifactor authentication always sends it. This applies both to phone calls and text messages provided by Microsoft Entra multifactor authentication. If you need to validate that a text message is from Microsoft Entra multifactor authentication, see [What short codes are used for sending messages?](multi-factor-authentication-faq.yml#what-short-codes-are-used-for-sending-text-messages-to-my-users-).

+1. Go to **Microsoft Entra ID** > **Security** > **multifactor authentication** > **Phone call settings**.

+> When Microsoft Entra multifactor authentication calls are placed through the public telephone network, sometimes the calls are routed through a carrier that doesn't support caller ID. Because of this, caller ID isn't guaranteed, even though Microsoft Entra multifactor authentication always sends it. This applies both to phone calls and text messages provided by Microsoft Entra multifactor authentication. If you need to validate that a text message is from Microsoft Entra multifactor authentication, see [What short codes are used for sending messages?](multi-factor-authentication-faq.yml#what-short-codes-are-used-for-sending-text-messages-to-my-users-).

+You can use your own recordings or greetings for Microsoft Entra multifactor authentication. These messages can be used in addition to the default Microsoft recordings or to replace them.

+1. Go to **Microsoft Entra ID** > **Security** > **multifactor authentication** > **Phone call settings**.

+Settings for app passwords, trusted IPs, verification options, and remembering multifactor authentication on trusted devices are available in the service settings. This is a legacy portal.

+You can access service settings from the [Microsoft Entra admin center](https://entra.microsoft.com) by going to **Protection** > **multifactor authentication** > **Getting started** > **Configure** > **Additional cloud-based MFA settings**. A window or tab opens with additional service settings options.

+The trusted IPs feature of Microsoft Entra multifactor authentication bypasses multifactor authentication prompts for users who sign in from a defined IP address range. You can set trusted IP ranges for your on-premises environments. When users are in one of these locations, there's no Microsoft Entra multifactor authentication prompt. The trusted IPs feature requires Microsoft Entra ID P1 edition.

+> The trusted IPs can include private IP ranges only when you use MFA Server. For cloud-based Microsoft Entra multifactor authentication, you can use only public IP address ranges.

+| Microsoft Entra tenant type | Trusted IP feature options |

+| Managed |**Specific range of IP addresses**: Administrators specify a range of IP addresses that can bypass multifactor authentications for users who sign in from the company intranet. A maximum of 50 trusted IP ranges can be configured.|

+| Federated |**All Federated Users**: All federated users who sign in from inside the organization can bypass multifactor authentications. Users bypass verifications by using a claim that's issued by Active Directory Federation Services (AD FS).<br/>**Specific range of IP addresses**: Administrators specify a range of IP addresses that can bypass multifactor authentication for users who sign in from the company intranet. |

+Trusted IP bypass works only from inside 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 multifactor authentication. The process is the same even if the user presents an AD FS claim.

+When the trusted IPs feature is disabled, multifactor authentication is required for browser flows. App passwords are required for older rich-client applications.

+When trusted IPs are used, multifactor authentication isn't required for browser flows. App passwords aren't required for older rich-client applications if the user hasn't created an app password. After an app password is in use, the password is required.

+Regardless of whether trusted IPs are defined, multifactor authentication is required for browser flows. App passwords are required for older rich-client applications.

+ * **For requests from federated users originating from my intranet**: To choose this option, select the checkbox. All federated users who sign in from the corporate network bypass multifactor authentications by using a claim that's issued by AD FS. Ensure that AD FS has a rule to add the intranet claim to the appropriate traffic. If the rule doesn't exist, create the following rule in AD FS:

+ * Enter up to 50 IP address ranges. Users who sign in from these IP addresses bypass multifactor authentications.

+If you don't want to use Conditional Access policies to enable trusted IPs, you can configure the service settings for Microsoft Entra multifactor authentication by using the following steps:

+1. Browse to **Protection** > **multifactor authentication** > **Service settings**.

+ * **For requests from federated users on my intranet**: To choose this option, select the checkbox. All federated users who sign in from the corporate network bypass multifactor authentication by using a claim that's issued by AD FS. Ensure that AD FS has a rule to add the intranet claim to the appropriate traffic. If the rule doesn't exist, create the following rule in AD FS:

+ * Enter up to 50 IP address ranges. Users who sign in from these IP addresses bypass multifactor authentications.

+You can choose the verification methods that are available for your users in the service settings portal. When your users enroll their accounts for Microsoft Entra multifactor authentication, they choose their preferred verification method from the options that you've enabled. Guidance for the user enrollment process is provided in [Set up my account for multifactor authentication](https://support.microsoft.com/account-billing/how-to-use-the-microsoft-authenticator-app-9783c865-0308-42fb-a519-8cf666fe0acc).

+For more information, see [What authentication and verification methods are available in Microsoft Entra ID?](concept-authentication-methods.md).

+1. Under **multifactor authentication** at the top of the page, select **Service settings**.

+<a name='remember-multi-factor-authentication'></a>

+### Remember multifactor authentication

+ The **remember multifactor authentication** feature lets users bypass subsequent verifications for a specified number of days, after they've successfully signed in to a device by using MFA. To enhance usability and minimize the number of times a user has to perform MFA on a given device, select a duration of 90 days or more.

+> The revoke action revokes the trusted status from all devices, and the user is required to perform multifactor authentication again. You can also instruct your users to restore the original MFA status on their own devices as noted in [Manage your settings for multifactor authentication](https://support.microsoft.com/account-billing/change-your-two-step-verification-method-and-settings-c801d5ad-e0fc-4711-94d5-33ad5d4630f7#turn-on-two-factor-verification-prompts-on-a-trusted-device).

+The **remember multifactor 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 MFA from that browser until the cookie expires. If the user opens a different browser on the same device or clears the 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, Microsoft Entra ID checks that the last multifactor authentication occurred within the specified number of days.

+> The **remember multifactor authentication** feature isn't compatible with the **keep me signed in** feature of AD FS, when users perform multifactor authentication for AD FS through MFA Server or a third-party multifactor authentication solution.

+> If your users select **keep me signed in** on AD FS and also mark their device as trusted for MFA, the user isn't automatically verified after the **remember multifactor authentication** number of days expires. Microsoft Entra ID requests a fresh multifactor authentication, but AD FS returns a token with the original MFA claim and date, rather than performing multifactor authentication again. *This reaction sets off a verification loop between Microsoft Entra ID and AD FS.*

+> The **remember multifactor authentication** feature isn't compatible with B2B users and won't be visible for B2B users when they sign in to the invited tenants.

+> The **remember multifactor authentication** feature isn't compatible with the Sign-in frequency Conditional Access control. For more information, see [Configure authentication session management with Conditional Access](../conditional-access/howto-conditional-access-session-lifetime.md#configuring-authentication-session-controls).

+<a name='enable-remember-multi-factor-authentication'></a>

+#### Enable remember multifactor authentication

+1. Under **multifactor authentication** at the top of the page, select **service settings**.

+1. On the **service settings** page, under **remember multifactor authentication**, select **Allow users to remember multifactor authentication on devices they trust**.

+1. Set the number of days to allow trusted devices to bypass multifactor authentications. For the optimal user experience, extend the duration to 90 or more days.

+After you enable the **remember multifactor authentication** feature, users can mark a device as trusted when they sign in by selecting **Don't ask again**.

+To learn more, see [What authentication and verification methods are available in Microsoft Entra ID?](concept-authentication-methods.md)

+ Title: Configure the Microsoft Entra multifactor authentication NPS extension

+# Advanced configuration options for the NPS extension for multifactor authentication

+The Network Policy Server (NPS) extension extends your cloud-based Microsoft Entra multifactor 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 your needs.

+Within the NPS extension, you can designate an Active Directory attribute to be used as the UPN for Microsoft Entra multifactor authentication. This enables you to protect your on-premises resources with two-step verification without modifying your on-premises UPNs.

+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 multifactor authentication requirements for that list.

+- [Resolve error messages from the NPS extension for Microsoft Entra multifactor authentication](howto-mfa-nps-extension-errors.md)

+- [Use REQUIRE_USER_MATCH to prepare for users that aren't enrolled for MFA](howto-mfa-nps-extension.md#configure-your-nps-extension)

+ Title: Troubleshooting Microsoft Entra multifactor authentication NPS extension

+description: Get help resolving issues with the NPS extension for Microsoft Entra multifactor authentication

+# Resolve error messages from the NPS extension for Microsoft Entra multifactor authentication

+If you encounter errors with the NPS extension for Microsoft Entra multifactor authentication, use this article to reach a resolution faster. NPS extension logs are found in Event Viewer under **Applications and Services Logs** > **Microsoft** > **AzureMfa** > **AuthN** > **AuthZ** on the server where the NPS Extension is installed.

+| **HTTPS_COMMUNICATION_ERROR** | The NPS server is unable to receive responses from Microsoft Entra multifactor authentication. Verify that your firewalls are open bidirectionally for traffic to and from `https://adnotifications.windowsazure.com` and that TLS 1.2 is enabled (default). If TLS 1.2 is disabled, user authentication fails and event ID 36871 with source SChannel is entered in the System log in Event Viewer. To verify TLS 1.2 is enabled, see [TLS registry settings](/windows-server/security/tls/tls-registry-settings#tls-dtls-and-ssl-protocol-version-settings). |

+| **NPS Extension for Microsoft Entra multifactor authentication (AccessReject):** <br> NPS Extension for Microsoft Entra multifactor authentication only performs Secondary Auth for Radius requests in AccessAccept State. Request received for User username with response state AccessReject, ignoring request. | This error usually reflects an authentication failure in AD or that the NPS server is unable to receive responses from Microsoft Entra ID. Verify that your firewalls are open bidirectionally for traffic to and from `https://adnotifications.windowsazure.com` and `https://login.microsoftonline.com` using ports 80 and 443. It's 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 isn't assigned a license. |

+| **NPS Extension for Microsoft Entra multifactor authentication (AccessChallenge):** <br> NPS Extension for Microsoft Entra multifactor authentication only performs Secondary Auth for Radius requests in AccessAccept State. Request received for User username with response state AccessChallenge, ignoring request. | This response is used when additional information is required from the user to complete the authentication or authorization process. The NPS server sends a challenge to the user, requesting further credentials or information. It usually precedes an Access-Accept or Access-Reject response. |

+| **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 Microsoft Entra multifactor authentication 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. |

+| **BecAccessDenied** | MSODS Bec call returned access denied, probably the username isn't defined in the tenant | The user is present in Active Directory on-premises but isn't synced into Microsoft Entra ID by AD Connect. Or, the user is missing for the tenant. Add the user to Microsoft Entra ID and have them add their verification methods according to the instructions in [Manage your settings for two-step verification](https://support.microsoft.com/account-billing/change-your-two-step-verification-method-and-settings-c801d5ad-e0fc-4711-94d5-33ad5d4630f7). |

+| **InvalidSession** | The specified session is invalid or may have expired | The session has taken more than three 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 Microsoft Entra multifactor authentication endpoint. |

+| **TenantIsBlocked** | Tenant is blocked | [Contact support](#contact-microsoft-support) with the *Tenant ID* from the Microsoft Entra properties page in the Microsoft Entra admin center. |

+| **UserNotFound** | The specified user was not found | The tenant is no longer visible as active in Microsoft Entra ID. 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. |

+Sometimes, your users may get messages from multifactor authentication because their authentication request failed. These aren't errors in the product of configuration, but are intentional warnings explaining why an authentication request was denied.

+The [Microsoft Entra multifactor authentication NPS Extension health check script](/samples/azure-samples/azure-mfa-nps-extension-health-check/azure-mfa-nps-extension-health-check/) performs several basic health checks when troubleshooting the NPS extension. Here's a quick summary about each available option when the script is run:

+To collect debug logs for support diagnostics, run the [Microsoft Entra multifactor authentication NPS Extension health check script](/samples/azure-samples/azure-mfa-nps-extension-health-check/azure-mfa-nps-extension-health-check/) on the NPS server and choose option **4** to collect the logs to provide them to Microsoft support.

+ Title: Integrate RDG with Microsoft Entra multifactor authentication NPS extension

+description: Integrate your Remote Desktop Gateway infrastructure with Microsoft Entra multifactor authentication using the Network Policy Server extension for Microsoft Azure

+# Integrate your Remote Desktop Gateway infrastructure using the Network Policy Server (NPS) extension and Microsoft Entra ID

+This article provides details for integrating your Remote Desktop Gateway infrastructure with Microsoft Entra multifactor authentication 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 [multifactor authentication](./concept-mfa-howitworks.md). 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 Microsoft Entra multifactor authentication using the NPS extension for Azure. This enables secure verification for users attempting to sign in to a Remote Desktop Gateway.

+> This article should not be used with MFA Server deployments and should only be used with Microsoft Entra multifactor authentication (Cloud-based) deployments.

+Organizations can also integrate NPS with Microsoft Entra multifactor authentication 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 **Approve**/**Deny** 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](howto-mfa-nps-extension.md#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 Microsoft Entra multifactor authentication environments had to configure and maintain a separate MFA Server in the on-premises environment as documented in [Remote Desktop Gateway and Azure multifactor authentication Server using RADIUS](howto-mfaserver-nps-rdg.md).

+1. 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 Microsoft Entra multifactor authentication.

+1. Microsoft Entra multifactor authentication communicates with Microsoft Entra ID, retrieves the user's details, and performs the secondary authentication using supported methods.

+1. Upon success of the MFA challenge, Microsoft Entra multifactor authentication communicates the result to the NPS extension.

+This section details the prerequisites necessary before integrating Microsoft Entra multifactor authentication with the Remote Desktop Gateway. Before you begin, you must have the following prerequisites in place.

+* Microsoft Entra multifactor authentication License

+* Microsoft Entra GUID ID

+<a name='azure-ad-mfa-license'></a>

+### Microsoft Entra multifactor authentication License

+Required is a license for Microsoft Entra multifactor authentication, which is available through Microsoft Entra ID P1 or P2 or other bundles that include it. Consumption-based licenses for Microsoft Entra multifactor authentication, such as per user or per authentication licenses, are not compatible with the NPS extension. For more information, see [How to get Microsoft Entra multifactor authentication](concept-mfa-licensing.md). For testing purposes, you can use a trial subscription.

+To use the NPS extension, on-premises users must be synced with Microsoft Entra ID and enabled for MFA. This section assumes that on-premises users are synched with Microsoft Entra ID using AD Connect. For information on Microsoft Entra Connect, see [Integrate your on-premises directories with Microsoft Entra ID](../hybrid/whatis-hybrid-identity.md).

+<a name='azure-active-directory-guid-id'></a>

+### Microsoft Entra GUID ID

+To install NPS extension, you need to know the GUID of the Microsoft Entra ID. Instructions for finding the GUID of the Microsoft Entra ID are provided below.

+<a name='configure-multi-factor-authentication'></a>

+## Configure multifactor authentication

+This section provides instructions for integrating Microsoft Entra multifactor authentication with the Remote Desktop Gateway. As an administrator, you must configure the Microsoft Entra multifactor authentication service before users can self-register their multifactor devices or applications.

+Follow the steps in [Getting started with Microsoft Entra multifactor authentication in the cloud](howto-mfa-getstarted.md) to enable MFA for your Microsoft Entra users.

+Follow the steps in [What does Microsoft Entra multifactor authentication mean for me?](https://support.microsoft.com/account-billing/how-to-use-the-microsoft-authenticator-app-9783c865-0308-42fb-a519-8cf666fe0acc) to understand and properly configure your devices for MFA with your user account.

+> The sign-in behavior for Remote Desktop Gateway doesn't provide the option to enter a verification code with Microsoft Entra multifactor authentication. A user account must be configured for phone verification or the Microsoft Authenticator App with **Approve**/**Deny** push notifications.

+> If neither phone verification or the Microsoft Authenticator App with **Approve**/**Deny** push notifications is configured for a user, the user won't be able to complete the Microsoft Entra multifactor authentication challenge and sign in to Remote Desktop Gateway.

+This section provides instructions for configuring RDS infrastructure to use Microsoft Entra multifactor authentication for client authentication with the Remote Desktop Gateway.

+As part of the configuration of the NPS extension, you must supply administrator credentials and the ID of your Microsoft Entra tenant. To get the tenant ID, complete the following steps:

+1. In the NPS Extension For Microsoft Entra multifactor authentication Setup dialog box, review the software license terms, check **I agree to the license terms and conditions**, and click **Install**.

+1. In the NPS Extension For Microsoft Entra multifactor authentication Setup dialog box, click **Close**.

+* Associates public key of certificate to service principal on Microsoft Entra ID

+If you want to use your own certificates, you need to associate the public key of your certificate to the service principal on Microsoft Entra ID, and so on.

+To use the script, provide the extension with your Microsoft Entra Admin credentials and the Microsoft Entra tenant ID that you copied earlier. Run the script on each NPS server where you installed the NPS extension. Then do the following:

+1. 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 Microsoft Entra admin credentials and password, and click **Sign In**.

+ 

+Remote Desktop connection authorization policies (RD CAPs) specify the requirements for connecting to a Remote Desktop Gateway server. RD CAPs can be stored locally (default) or they can be stored in a central RD CAP store that is running NPS. To configure integration of Microsoft Entra multifactor authentication with RDS, you need to specify the use of a central store.

+By default, when you configure the RD Gateway to use a central policy store for connection authorization policies, the RD Gateway is configured to forward CAP requests to the NPS server. The NPS server with the Microsoft Entra multifactor authentication extension installed, processes the RADIUS access request. The following steps show you how to verify the default connection request policy.

+Recall that the NPS server with the Microsoft Entra multifactor authentication 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.

+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 Microsoft Entra multifactor authentication.

+If you successfully authenticate with the secondary authentication method you previously configured in Microsoft Entra multifactor authentication, you are connected to the resource. However, if the secondary authentication is not successful, you are denied access to the resource.

+On the server where you installed the NPS extension for Microsoft Entra multifactor authentication, you can find Event Viewer application logs specific to the extension at _Application and Services Logs\Microsoft\AzureMfa_.

+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 Microsoft Entra multifactor authentication. Have the user sign in to the [Microsoft Entra admin center](https://entra.microsoft.com). If users are prompted for secondary verification and can successfully authenticate, you can eliminate an incorrect configuration of Microsoft Entra multifactor authentication.

+If Microsoft Entra multifactor authentication is working for the user(s), you should review the relevant Event logs. These include the Security Event, Gateway operational, and Microsoft Entra multifactor authentication logs that are discussed in the previous section.

+

+[How to get Microsoft Entra multifactor authentication](concept-mfa-licensing.md)

+[Remote Desktop Gateway and Azure multifactor authentication Server using RADIUS](howto-mfaserver-nps-rdg.md)

+[Integrate your on-premises directories with Microsoft Entra ID](../hybrid/whatis-hybrid-identity.md)

+ Title: VPN with Microsoft Entra multifactor authentication using the NPS extension

+description: Integrate your VPN infrastructure with Microsoft Entra multifactor authentication by using the Network Policy Server extension for Microsoft Azure.

+# Integrate your VPN infrastructure with Microsoft Entra multifactor authentication by using the Network Policy Server extension for Azure

+The Network Policy Server (NPS) extension for Azure allows organizations to safeguard Remote Authentication Dial-In User Service (RADIUS) client authentication using cloud-based [Microsoft Entra multifactor authentication](howto-mfaserver-nps-rdg.md), which provides two-step verification.

+To enhance security and provide a high level of compliance, organizations can integrate NPS with Microsoft Entra multifactor 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 multifactor authentication Server using RADIUS.

+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 Microsoft Entra multifactor authentication.

+5. Microsoft Entra multifactor authentication communicates with Microsoft Entra ID, 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, Microsoft Entra multifactor authentication communicates the result to the NPS extension.

+* Microsoft Entra multifactor authentication license

+* Microsoft Entra GUID ID

+<a name='azure-ad-mfa-license'></a>

+### Microsoft Entra multifactor authentication License

+A license is required for Microsoft Entra multifactor authentication, and it is available through a Microsoft Entra ID P1 or P2, Enterprise Mobility + Security, or a multifactor authentication stand-alone license. Consumption-based licenses for Microsoft Entra multifactor authentication such as per user or per authentication licenses are not compatible with the NPS extension. For more information, see [How to get Microsoft Entra multifactor authentication](concept-mfa-licensing.md). For testing purposes, you can use a trial subscription.

+- [Azure AD PowerShell Module for Windows PowerShell version 1.1.166.0](https://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=59185)

+To use the NPS extension, on-premises users must be synced with Microsoft Entra ID and enabled for MFA. This guide assumes that on-premises users are synced with Microsoft Entra ID via Microsoft Entra Connect. Instructions for enabling users for MFA are provided below.

+For information about Microsoft Entra Connect, see [Integrate your on-premises directories with Microsoft Entra ID](../hybrid/whatis-hybrid-identity.md).

+<a name='azure-active-directory-guid-id'></a>

+### Microsoft Entra GUID ID

+To install the NPS extension, you need to know the GUID of the Microsoft Entra ID. Instructions for finding the GUID of the Microsoft Entra ID are provided in the next section.

+<a name='configure-multi-factor-authentication'></a>

+## Configure multifactor authentication

+For assistance configuring users for multifactor authentication see the articles [Planning a cloud-based Microsoft Entra multifactor authentication deployment](howto-mfa-getstarted.md#plan-conditional-access-policies) and [Set up my account for two-step verification](https://support.microsoft.com/account-billing/how-to-use-the-microsoft-authenticator-app-9783c865-0308-42fb-a519-8cf666fe0acc)

+After you install and configure the NPS extension, all RADIUS-based client authentication that is processed by this server is required to use MFA. If all your VPN users are not enrolled in Microsoft Entra multifactor authentication, you can do either of the following:

+* Create a registry entry that allows challenged users to provide a second authentication factor if they are enrolled in Microsoft Entra multifactor authentication.

+If the value is set to *TRUE* or is blank, all authentication requests are subject to an MFA challenge. If the value is set to *FALSE*, MFA challenges are issued only to users who are enrolled in Microsoft Entra multifactor authentication. Use the *FALSE* setting only in testing or in production environments during an onboarding period.

+As part of the configuration of the NPS extension, you must supply administrator credentials and the ID of your Microsoft Entra tenant. To get the tenant ID, complete the following steps:

+4. In the **NPS Extension For Microsoft Entra multifactor authentication Setup** window, review the software license terms, select the **I agree to the license terms and conditions** check box, and then select **Install**.

+ 

+5. In the **NPS Extension For Microsoft Entra multifactor authentication Setup** window, select **Close**.

+* Associates the public key of the certificate to the service principal on Microsoft Entra ID.

+If you want to use your own certificates, you must associate the public key of your certificate with the service principal on Microsoft Entra ID, and so on.

+To use the script, provide the extension with your Microsoft Entra administrative credentials and the Microsoft Entra tenant ID that you copied earlier. The account must be in the same Microsoft Entra tenant as you wish to enable the extension for. Run the script on each NPS server where you install the NPS extension.

+4. Enter your Microsoft Entra administrator credentials and password, and then select **Sign in**.

+ 

+If you successfully authenticate with the secondary verification method that you previously configured in Microsoft Entra multifactor authentication, you are connected to the resource. However, if the secondary authentication is unsuccessful, you are denied access to the resource.

+On the server where you installed the NPS extension for Microsoft Entra multifactor authentication, you can find Event Viewer application logs that are specific to the extension at *Application and Services Logs\Microsoft\AzureMfa*.

+If MFA is working for the user, review the relevant Event Viewer logs. The logs include the security event, Gateway operational, and Microsoft Entra multifactor authentication logs that are discussed in the previous section.

+A related event from the Microsoft Entra multifactor authentication log is shown here:

+

+For more information, see [Integrate your existing NPS infrastructure with Microsoft Entra multifactor authentication](howto-mfa-nps-extension.md).

+[Get Microsoft Entra multifactor authentication](concept-mfa-licensing.md)

+[Remote Desktop Gateway and Azure multifactor authentication Server using RADIUS](howto-mfaserver-nps-rdg.md)

+[Integrate your on-premises directories with Microsoft Entra ID](../hybrid/whatis-hybrid-identity.md)

+ Title: Use Microsoft Entra multifactor authentication with NPS

+description: Learn how to use Microsoft Entra multifactor authentication capabilities with your existing Network Policy Server (NPS) authentication infrastructure

+# Integrate your existing Network Policy Server (NPS) infrastructure with Microsoft Entra multifactor authentication

+The Network Policy Server (NPS) extension for Microsoft Entra multifactor authentication 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.

+The NPS extension acts as an adapter between RADIUS and cloud-based Microsoft Entra multifactor authentication to provide a second factor of authentication for federated or synced users.

+When you use the NPS extension for Microsoft Entra multifactor authentication, the authentication flow includes the following components:

+1. **NPS Extension** triggers a request to Microsoft Entra multifactor authentication 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.

+1. **Microsoft Entra multifactor authentication** communicates with Microsoft Entra ID to retrieve the user's details and performs the secondary authentication using a verification method configured to the user.

+

+The NPS server may not respond to the VPN server's original request before the connection times out as the MFA request may still be being processed. The user may not have successfully responded to the MFA prompt, so the Microsoft Entra multifactor authentication NPS extension is waiting for that event to complete. In this situation, the NPS server identifies additional VPN server requests as a duplicate request. The NPS server discards these duplicate VPN server requests.

+If you look at the NPS server logs, you may see these additional requests being discarded. This behavior is by design to protect the end user from getting multiple requests for a single authentication attempt. Discarded requests in the NPS server event log don't indicate there's a problem with the NPS server or the Microsoft Entra multifactor authentication NPS extension.

+Due to this UDP protocol behavior, the NPS server could receive a duplicate request and send another MFA prompt, even after the user has already responded to the initial request. To avoid this timing condition, the Microsoft Entra multifactor authentication NPS extension continues to filter and discard duplicate requests for up to 10 seconds after a successful response has been sent to the VPN server.

+Again, you may see discarded requests in the NPS server event logs, even when the Microsoft Entra multifactor authentication prompt was successful. This is expected behavior, and doesn't indicate a problem with the NPS server or Microsoft Entra multifactor authentication NPS extension.

+You can create as many Microsoft Entra multifactor authentication-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 certificate 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 Microsoft Entra multifactor authentication-enabled NPS servers.

+The NPS Extension for Microsoft Entra multifactor authentication is available to customers with [licenses for Microsoft Entra multifactor authentication](./concept-mfa-howitworks.md) (included with Microsoft Entra ID P1 and Premium P2 or Enterprise Mobility + Security). Consumption-based licenses for Microsoft Entra multifactor authentication, such as per user or per authentication licenses, aren't compatible with the NPS extension.

+- [Azure AD PowerShell Module for Windows PowerShell version 1.1.166.0](https://www.powershellgallery.com/packages/MSOnline/1.1.166.0)

+The Azure AD PowerShell Module for Windows PowerShell is also installed through a configuration script you run as part of the setup process, if not already present. There's no need to install this module ahead of time if it's not already installed.

+As part of the configuration of the NPS extension, you must supply administrator credentials and the ID of your Microsoft Entra tenant. To get the tenant ID, complete the following steps:

+The NPS server connects to Microsoft Entra ID and authenticates the MFA requests. Choose one server for this role. We recommend choosing a server that doesn't handle requests from other services, because the NPS extension throws errors for any requests that aren't RADIUS. The NPS server must be set up as the primary and secondary authentication server for your environment. It can't proxy RADIUS requests to another server.

+This step may already be complete on your tenant, but it's good to double-check that Microsoft Entra Connect has synchronized your databases recently.

+1. Browse to **Identity** > **Hybrid management** > **Microsoft Entra Connect**.

+If you need to kick off a new round of synchronization, see [Microsoft Entra Connect Sync: Scheduler](../hybrid/connect/how-to-connect-sync-feature-scheduler.md#start-the-scheduler).

+ - **PAP** supports all the authentication methods of Microsoft Entra multifactor authentication in the cloud: phone call, one-way text message, mobile app notification, OATH hardware tokens, and mobile app verification code.

+Before you deploy and use the NPS extension, users that are required to perform Microsoft Entra multifactor authentication need to be registered for MFA. To test the extension as you deploy it, you also need at least one test account that is fully registered for Microsoft Entra multifactor authentication.

+1. Browse to **Protection** > **multifactor authentication** and enable for the test account.

+> Make sure that users have successfully registered for Microsoft Entra multifactor authentication. If users have previously only registered for self-service password reset (SSPR), *StrongAuthenticationMethods* is enabled for their account. Microsoft Entra multifactor authentication is enforced when *StrongAuthenticationMethods* is configured, even if the user only registered for SSPR.

+> Combined security registration can be enabled that configures SSPR and Microsoft Entra multifactor authentication at the same time. For more information, see [Enable combined security information registration in Microsoft Entra ID](howto-registration-mfa-sspr-combined.md).

+> Users who connect to the NPS server using username and password will be required to complete a multifactor authentication prompt.

+<a name='download-and-install-the-nps-extension-for-azure-ad-mfa'></a>

+### Download and install the NPS extension for Microsoft Entra multifactor authentication

+* Associates the public key of the certificate to the service principal on Microsoft Entra ID.

+1. When prompted, sign in to Microsoft Entra ID as a Global administrator.

+- The NPS extension for Microsoft Entra multifactor authentication doesn't include tools to migrate users and settings from MFA Server to the cloud. For this reason, we suggest using the extension for new deployments, rather than existing deployment. If you use the extension on an existing deployment, your users have to perform proof-up again to populate their MFA details in the cloud.

+- The NPS extension uses the UPN from the on-premises AD DS environment to identify the user on Microsoft Entra multifactor authentication for performing the Secondary Auth. The extension can be configured to use a different identifier like alternate login ID or custom AD DS field other than UPN. For more information, see the article, [Advanced configuration options for the NPS extension for multifactor authentication](howto-mfa-nps-extension-advanced.md).

+You can choose to create this key and set it to *FALSE* while your users are onboarding, and may not all be enrolled for Microsoft Entra multifactor authentication 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.

+The [Microsoft Entra multifactor authentication NPS Extension health check script](/samples/azure-samples/azure-mfa-nps-extension-health-check/azure-mfa-nps-extension-health-check/) performs a basic health check when troubleshooting the NPS extension. Run the script and choose one of available options.

+If for any reason the "Azure multifactor authentication Client" service principal was not created in the tenant, it can be manually created by running the `New-MsolServicePrincipal` cmdlet as shown below.

+Once done, sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as a [Global Administrator](../roles/permissions-reference.md#global-administrator). Browse to **Identity** > **Applications** > **Enterprise applications** > and search for "Azure multifactor authentication Client". Then click **Check properties for this app**. Confirm if the service principal is enabled or disabled. Click the application entry > **Properties**. If the option **Enabled for users to sign-in?** is set to **No**, set it to **Yes**.

+<a name='how-can-i-verify-that-my-client-certificate-is-associated-to-my-tenant-in-azure-ad'></a>

+### How can I verify that my client certificate is associated to my tenant in Microsoft Entra ID?

+3. Verify that the certificate is associated with your tenant on Microsoft Entra ID.

+Verify that AD Connect is running, and that the user is present in both the on-premises AD DS environment and in Microsoft Entra ID.

+A VPN server may send repeated requests to the NPS server if the timeout value is too low. The NPS server detects these duplicate requests and discards them. This behavior is by design, and doesn't indicate a problem with the NPS server or the Microsoft Entra multifactor authentication NPS extension.

+Additional troubleshooting guidance and possible solutions can be found in the article, [Resolve error messages from the NPS extension for Microsoft Entra multifactor authentication](howto-mfa-nps-extension-errors.md).

+- 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 multifactor authentication](howto-mfa-nps-extension-advanced.md)

+- [Resolve error messages from the NPS extension for Microsoft Entra multifactor authentication](howto-mfa-nps-extension-errors.md)

+ Title: Microsoft Entra user data collection

+description: What information is used to help authenticate users by self-service password reset and Microsoft Entra multifactor authentication?

+# Microsoft Entra user data collection for multifactor authentication and self-service password reset

+This document explains how to find user information collected by Azure multifactor authentication Server (MFA Server), Microsoft Entra multifactor authentication (Cloud-based), and self-service password reset (SSPR) in the event you would like to remove it.

+MFA Server, the NPS Extension, and the Windows Server 2016 Microsoft Entra multifactor authentication AD FS Adapter collect and store the following information for 90 days.

+Changes (used to sync user changes to MFA Server or Microsoft Entra ID):

+<a name='gather-data-from-windows-server-2016-azure-ad-mfa-ad-fs-adapter'></a>

+## Gather data from Windows Server 2016 Microsoft Entra multifactor authentication AD FS Adapter

+<a name='delete-data-from-windows-server-2016-azure-ad-mfa-ad-fs-adapter'></a>

+## Delete data from Windows Server 2016 Microsoft Entra multifactor authentication AD FS Adapter

+<a name='gather-data-for-azure-ad-mfa'></a>

+## Gather data for Microsoft Entra multifactor authentication

+<a name='delete-data-for-azure-ad-mfa'></a>

+## Delete data for Microsoft Entra multifactor authentication

+Global Administrators can remove data collected for any user. On the **Users** page in Microsoft Entra ID, click **Authentication methods** and select a user to remove their phone or email address.

+ Title: Sign-in event details for Microsoft Entra multifactor authentication

+description: Learn how to view sign-in activity for Microsoft Entra multifactor authentication events and status messages.

+# Use the sign-ins report to review Microsoft Entra multifactor authentication events

+To review and understand Microsoft Entra multifactor authentication events, you can use the Microsoft Entra sign-ins report. This report shows authentication details for events when a user is prompted for multifactor authentication, and if any Conditional Access policies were in use. For detailed information on the sign-ins report, see the [overview of sign-in activity reports in Microsoft Entra ID](../reports-monitoring/concept-sign-ins.md).

+<a name='view-the-azure-ad-sign-ins-report'></a>

+## View the Microsoft Entra sign-ins report

+The sign-ins report provides you with information about the usage of managed applications and user sign-in activities, which includes information about multifactor authentication usage. The MFA data gives you insights into how MFA is working in your organization. It answers questions like:

+ [](media/howto-mfa-reporting/sign-in-report.png#lightbox)

+- Volume of sign-ins protected by multifactor authentication

+Identify users who have registered for MFA using the PowerShell that follows. This set of commands excludes disabled users since these accounts can't authenticate against Microsoft Entra ID:

+Identify users who aren't registered for MFA by running the following PowerShell commands. This set of commands excludes disabled users since these accounts can't authenticate against Microsoft Entra ID:

+| Blocked User History | Microsoft Entra ID > Security > MFA > Block/unblock users | Shows the history of requests to block or unblock users. |

+| Usage for on-premises components | Microsoft Entra ID > Security > MFA > Activity Report | Provides information on overall usage for MFA Server. NPS extension and AD FS logs for cloud MFA activity are now included in the [Sign-in logs](../reports-monitoring/concept-sign-ins.md), and no longer published on this report. |

+| Bypassed User History | Microsoft Entra ID > Security > MFA > One-time bypass | Provides a history of MFA Server requests to bypass MFA for a user. |

+| Server status | Microsoft Entra ID > Security > MFA > Server status | Displays the status of MFA Servers associated with your account. |

+Organizations that run the latest version of NPS extension or use Microsoft Entra Connect Health will have location IP address in events.

+This article provided an overview of the sign-ins activity report. For more detailed information on what this report contains, see [sign-in activity reports in Microsoft Entra ID](../reports-monitoring/concept-sign-ins.md).

+> The caching feature is not intended to be used for sign-ins to Microsoft Entra ID.

+1. Browse to **Microsoft Entra ID** > **Security** > **MFA** > **Caching rules**.

+ Title: Manage authentication methods for Microsoft Entra multifactor authentication

+description: Learn how you can configure Microsoft Entra user settings for Microsoft Entra multifactor authentication

+# Manage user authentication methods for Microsoft Entra multifactor authentication

+Users in Microsoft Entra ID have two distinct sets of contact information:

+- Authentication methods, which are always kept private and only used for authentication, including multifactor authentication. Administrators can manage these methods in a user's authentication method blade and users can manage their methods in Security Info page of MyAccount.

+When managing Microsoft Entra multifactor authentication methods for your users, Authentication administrators can:

+1. Select **multifactor authentication**. You may need to scroll to the right to see this menu option. Select the example screenshot below to see the full window and menu location:

+ [](media/howto-mfa-userstates/selectmfa.png#lightbox)

+This article showed you how to configure individual user settings. To configure overall Microsoft Entra multifactor authentication service settings, see [Configure Microsoft Entra multifactor authentication settings](howto-mfa-mfasettings.md).

+If your users need help, see the [User guide for Microsoft Entra multifactor authentication](https://support.microsoft.com/account-billing/how-to-use-the-microsoft-authenticator-app-9783c865-0308-42fb-a519-8cf666fe0acc).

+ Title: Enable per-user multifactor authentication

+description: Learn how to enable per-user Microsoft Entra multifactor authentication by changing the user state

+# Enable per-user Microsoft Entra multifactor authentication to secure sign-in events

+To secure user sign-in events in Microsoft Entra ID, you can require multifactor authentication. Enabling Microsoft Entra multifactor authentication using Conditional Access policies is the recommended approach to protect users. Conditional Access is a Microsoft Entra ID P1 or P2 feature that lets you apply rules to require MFA as needed in certain scenarios. To get started using Conditional Access, see [Tutorial: Secure user sign-in events with Microsoft Entra multifactor authentication](tutorial-enable-azure-mfa.md).

+For Microsoft Entra ID Free tenants without Conditional Access, you can [use security defaults to protect users](../fundamentals/security-defaults.md). Users are prompted for MFA as needed, but you can't define your own rules to control the behavior.

+If needed, you can instead enable each account for per-user Microsoft Entra multifactor authentication. When users are enabled individually, they perform multifactor authentication each time they sign in (with some exceptions, such as when they sign in from trusted IP addresses or when the _remember MFA on trusted devices_ feature is turned on).

+Changing [user states](#azure-ad-multi-factor-authentication-user-states) isn't recommended unless your Microsoft Entra ID licenses don't include Conditional Access and you don't want to use security defaults. For more information on the different ways to enable MFA, see [Features and licenses for Microsoft Entra multifactor authentication](concept-mfa-licensing.md).

+> This article details how to view and change the status for per-user Microsoft Entra multifactor authentication. If you use Conditional Access or security defaults, you don't review or enable user accounts using these steps.

+> Enabling Microsoft Entra multifactor authentication through a Conditional Access policy doesn't change the state of the user. Don't be alarmed if users appear disabled. Conditional Access doesn't change the state.

+> **Don't enable or enforce per-user Microsoft Entra multifactor authentication if you use Conditional Access policies.**

+<a name='azure-ad-multi-factor-authentication-user-states'></a>

+## Microsoft Entra multifactor authentication user states

+A user's state reflects whether an admin has enrolled them in per-user Microsoft Entra multifactor authentication. User accounts in Microsoft Entra multifactor authentication have the following three distinct states:

+| Disabled | The default state for a user not enrolled in per-user Microsoft Entra multifactor authentication. | No | No | No |

+| Enabled | The user is enrolled in per-user Microsoft Entra multifactor authentication, but can still use their password for legacy authentication. If the user hasn't yet registered MFA authentication methods, they receive a prompt to register the next time they sign in using modern authentication (such as via a web browser). | No. Legacy authentication continues to work until the registration process is completed. | Yes. After the session expires, Microsoft Entra multifactor authentication registration is required.| Yes. After the access token expires, Microsoft Entra multifactor authentication registration is required. |

+| Enforced | The user is enrolled per-user in Microsoft Entra multifactor authentication. If the user hasn't yet registered authentication methods, they receive a prompt to register the next time they sign in using modern authentication (such as via a web browser). Users who complete registration while in the *Enabled* state are automatically moved to the *Enforced* state. | Yes. Apps require app passwords. | Yes. Microsoft Entra multifactor authentication is required at sign-in. | Yes. Microsoft Entra multifactor authentication is required at sign-in. |

+All users start out *Disabled*. When you enroll users in per-user Microsoft Entra multifactor authentication, their state changes to *Enabled*. When enabled users sign in and complete the registration process, their state changes to *Enforced*. Administrators may move users between states, including from *Enforced* to *Enabled* or *Disabled*.

+ :::image type="content" border="true" source="media/howto-mfa-userstates/selectmfa-cropped.png" alt-text="Screenshot of select multifactor authentication from the Users window in Azure AD.":::

+ 

+To change the per-user Microsoft Entra multifactor authentication state for a user, complete the following steps:

+1. Use the previous steps to [view the status for a user](#view-the-status-for-a-user) to get to the Microsoft Entra multifactor authentication **users** page.

+1. Find the user you want to enable for per-user Microsoft Entra multifactor authentication. You might need to change the view at the top to **users**.

+ > *Enabled* users are automatically switched to *Enforced* when they register for Microsoft Entra multifactor authentication. Don't manually change the user state to *Enforced* unless the user is already registered or if it is acceptable for the user to experience interruption in connections to legacy authentication protocols.

+After you enable users, notify them via email. Tell the users that a prompt is displayed to ask them to register the next time they sign in. Also, if your organization uses non-browser apps that don't support modern authentication, they need to create app passwords. For more information, see the [Microsoft Entra multifactor authentication end-user guide](https://support.microsoft.com/account-billing/how-to-use-the-microsoft-authenticator-app-9783c865-0308-42fb-a519-8cf666fe0acc) to help them get started.

+If your users were enabled using per-user enabled and enforced Microsoft Entra multifactor authentication the following PowerShell can assist you in making the conversion to Conditional Access based Microsoft Entra multifactor authentication.

+To configure Microsoft Entra multifactor authentication settings, see [Configure Microsoft Entra multifactor authentication settings](howto-mfa-mfasettings.md).

+To manage user settings for Microsoft Entra multifactor authentication, see [Manage user settings with Microsoft Entra multifactor authentication](howto-mfa-userdevicesettings.md).

+To understand why a user was prompted or not prompted to perform MFA, see [Microsoft Entra multifactor authentication reports](howto-mfa-reporting.md).

+ Title: Use Microsoft Entra multifactor authentication Server with AD FS 2.0

+description: Describes how to get started with Microsoft Entra multifactor authentication and AD FS 2.0.

+# Configure Azure multifactor authentication Server to work with AD FS 2.0

+This article is for organizations that are federated with Microsoft Entra ID, and want to secure resources that are on-premises or in the cloud. Protect your resources by using the Azure multifactor 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 multifactor authentication Server with AD FS 2.0. For information about AD FS, see [Securing cloud and on-premises resources using Azure multifactor authentication Server with Windows Server](howto-mfaserver-adfs-windows-server.md).

+> In September 2022, Microsoft announced deprecation of Azure multifactor authentication Server. Beginning September 30, 2024, Azure multifactor authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Microsoft Entra multifactor authentication service by using the latest Migration Utility included in the most recent [Microsoft Entra multifactor authentication Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Microsoft Entra multifactor authentication Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+> To get started with cloud-based MFA, see [Tutorial: Secure user sign-in events with Azure multifactor authentication](tutorial-enable-azure-mfa.md).

+> If you use cloud-based MFA, see [Securing cloud resources with Azure multifactor authentication and AD FS](howto-mfa-adfs.md).

+To secure AD FS 2.0 with a proxy, install the Azure multifactor authentication Server on the AD FS proxy server.

+1. In the Azure multifactor authentication Server, click the **IIS Authentication** icon in the left menu.

+5. Check the **Require Azure multifactor authentication user match** box if all users have been or will be imported into the Server and subject to two-step verification. If a significant number of users haven't yet been imported into the Server and/or will be exempt from two-step verification, leave the box unchecked.

+7. In the Add Form-Based Website dialog box, enter the URL to the AD FS login page in the Submit URL field (like `https://sso.contoso.com/adfs/ls`) and enter an Application name (optional). The Application name appears in Azure multifactor authentication reports and may be displayed within SMS or Mobile App authentication messages.

+10. Check the **Require Azure multifactor authentication user match** box if all users have been or will be imported into the Server and subject to two-step verification. If a significant number of users haven't yet been imported into the Server and/or will be exempt from two-step verification, leave the box unchecked.

+4. Open the registry editor and go to HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Positive Networks/PhoneFactor on a 64-bit server. If you use a 32-bit server, remove **/Wow6432Node** from the path. Create a DWORD registry key called "UsernameCxz_stripPrefixDomain" and set the value to 1. Azure multifactor authentication is now securing the AD FS proxy.

+You can secure AD FS when the AD FS proxy isn't used. Install the Azure multifactor authentication Server on the AD FS server and configure the Server per the following steps:

+1. Within the Azure multifactor authentication Server, click the **IIS Authentication** icon in the left menu.

+4. In the Add Base URL dialogue box, enter the URL for the AD FS website where HTTP authentication is performed (like `https://sso.domain.com/adfs/ls/auth/integrated`) into the Base URL field. Then, enter an Application name (optional). The Application name appears in Azure multifactor authentication reports and may be displayed within SMS or Mobile App authentication messages.

+6. Check the **Require Azure multifactor authentication user match** box if all users have been or will be imported into the Server and subject to two-step verification. If a significant number of users haven't yet been imported into the Server and/or will be exempt from two-step verification, leave the box unchecked.

+Azure multifactor authentication is now securing AD FS.

+Trusted IPs allow users to bypass Azure multifactor 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.

+description: This article describes how to get started with Azure multifactor authentication and AD FS in Windows Server 2016.

+# Configure Azure multifactor authentication Server to work with AD FS in Windows Server

+If you use Active Directory Federation Services (AD FS) and want to secure cloud or on-premises resources, you can configure Azure multifactor authentication Server to work with AD FS. This configuration triggers two-step verification for high-value endpoints.

+In this article, we discuss using Azure multifactor authentication Server with AD FS beginning with Windows Server 2016. For more information, read about how to [secure cloud and on-premises resources by using Azure multifactor authentication Server with AD FS 2.0](howto-mfaserver-adfs-2.md).

+> In September 2022, Microsoft announced deprecation of Azure multifactor authentication Server. Beginning September 30, 2024, Azure multifactor authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Azure MFA service by using the latest Migration Utility included in the most recent [Azure MFA Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure MFA Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+> To get started with cloud-based MFA, see [Tutorial: Secure user sign-in events with Azure multifactor authentication](tutorial-enable-azure-mfa.md).

+> If you use cloud-based MFA, see [Securing cloud resources with Microsoft Entra multifactor authentication and AD FS](howto-mfa-adfs.md).

+<a name='secure-windows-server-ad-fs-with-azure-multi-factor-authentication-server'></a>

+## Secure Windows Server AD FS with Azure multifactor authentication Server

+When you install Azure multifactor authentication Server, you have the following options:

+* Install Azure multifactor authentication Server locally on the same server as AD FS

+* Install the Azure multifactor authentication adapter locally on the AD FS server, and then install multifactor authentication Server on a different computer

+* You don't have to install Azure multifactor authentication Server on your AD FS server. However, you must install the multifactor authentication adapter for AD FS on a Windows Server 2012 R2 or Windows Server 2016 that is running AD FS. You can install the server on a different computer if you install the AD FS adapter separately on your AD FS federation server. See the following procedures to learn how to install the adapter separately.

+* The multifactor Authentication AD FS adapter installation wizard creates a security group called PhoneFactor Admins in your instance of Active Directory. It then adds the AD FS service account of your federation service to this group. Verify that the PhoneFactor Admins group was created on your domain controller, and that the AD FS service account is a member of this group. If necessary, manually add the AD FS service account to the PhoneFactor Admins group on your domain controller.

+* For information about installing the Web Service SDK with the user portal, see [deploying the user portal for Azure multifactor authentication Server.](howto-mfaserver-deploy-userportal.md)

+<a name='install-azure-multi-factor-authentication-server-locally-on-the-ad-fs-server'></a>

+### Install Azure multifactor authentication Server locally on the AD FS server

+1. Download and install Azure multifactor authentication Server on your AD FS server. For installation information, read about [getting started with Azure multifactor authentication Server](howto-mfaserver-deploy.md).

+2. In the Azure multifactor authentication Server management console, click the **AD FS** icon. Select the options **Allow user enrollment** and **Allow users to select method**.

+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 multifactor 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 window 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 multifactor 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 multifactor authentication Server creates the PhoneFactor Admins group and adds the AD FS service account to the PhoneFactor Admins group.

+9. In the multifactor authentication AD FS adapter installer, click **Next**.

+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 **multifactor authentication** section, click the **Edit** link next to the **Global Settings** section. In the **Edit Global Authentication Policy** window, select **multifactor 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, multifactor authentication Server is set up to be an additional authentication provider to use with AD FS.

+1. Install the Web Service SDK on the server that is running multifactor authentication Server.

+2. Copy the following files from the \Program Files\multifactor authentication Server directory to the server on which you plan to install the AD FS adapter:

+4. In the multifactor authentication AD FS adapter installer, click **Next** to start the installation.

+2. Set the value for **WebServiceSdkUrl** to the URL of the multifactor authentication Web Service SDK. For example: *https:\/\/contoso.com/\<certificatename>/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx*, Where *\<certificatename>* is the name of your certificate.

+Finally, to register the adapter, run the \Program Files\multifactor authentication Server\Register-MultiFactorAuthenticationAdfsAdapter.ps1 script in PowerShell. The adapter is registered as WindowsAzureMultiFactorAuthentication. Restart the AD FS service for the registration to take effect.

+<a name='secure-azure-ad-resources-using-ad-fs'></a>

+## Secure Microsoft Entra resources using AD FS

+To secure your cloud resource, set up a claims rule so that Active Directory Federation Services emits the multipleauthn claim when a user performs two-step verification successfully. This claim is passed on to Microsoft Entra ID. Follow this procedure to walk through the steps:

+For troubleshooting help, see the [Azure multifactor authentication FAQs](multi-factor-authentication-faq.yml)

+description: Deploy multiple instances of Azure multifactor authentication Server in configurations that provide high availability.

+# Configure Azure multifactor authentication Server for high availability

+> In September 2022, Microsoft announced deprecation of Azure multifactor authentication Server. Beginning September 30, 2024, Azure multifactor authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Azure MFA service by using the latest Migration Utility included in the most recent [Azure MFA Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure MFA Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+> To get started with cloud-based MFA, see [Tutorial: Secure user sign-in events with Microsoft Entra multifactor authentication](tutorial-enable-azure-mfa.md).

+An MFA Server is a Windows Server that has the Azure multifactor 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.

+# Enable mobile app authentication with Microsoft Entra multifactor authentication Server

+The Microsoft Authenticator app offers an extra out-of-band verification option. Instead of placing an automated phone call or SMS to the user during login, Microsoft Entra multifactor authentication pushes a notification to the 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.

+> In September 2022, Microsoft announced deprecation of Microsoft Entra multifactor authentication Server. Beginning September 30, 2024, Microsoft Entra multifactor authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Azure MFA service by using the latest Migration Utility included in the most recent [Azure MFA Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure MFA Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+> To get started with cloud-based MFA, see [Tutorial: Secure user sign-in events with Microsoft Entra multifactor authentication](tutorial-enable-azure-mfa.md).

+> If you have installed Microsoft Entra multifactor 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](#configure-the-mobile-app-settings-in-mfa-server).

+To use the Authenticator app, you must be running Microsoft Entra multifactor authentication Server v8.x or higher

+- [Advanced scenarios with Microsoft Entra multifactor authentication Server and third-party VPNs](howto-mfaserver-nps-vpn.md).

+ Title: Upgrade PhoneFactor to Microsoft Entra multifactor authentication Server

+description: Get started with Microsoft Entra multifactor authentication Server when you upgrade from the older phonefactor agent.

+# Upgrade the PhoneFactor Agent to Microsoft Entra multifactor authentication Server

+To upgrade the PhoneFactor Agent v5.x or older to Microsoft Entra multifactor authentication Server, uninstall the PhoneFactor Agent and affiliated components first. Then the multifactor authentication Server and its affiliated components can be installed.

+> In September 2022, Microsoft announced deprecation of Microsoft Entra multifactor authentication Server. Beginning September 30, 2024, Microsoft Entra multifactor authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Azure MFA service by using the latest Migration Utility included in the most recent [Azure MFA Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure MFA Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+> To get started with cloud-based MFA, see [Tutorial: Secure user sign-in events with Microsoft Entra multifactor authentication](tutorial-enable-azure-mfa.md).

+<a name='install-the-multi-factor-authentication-server'></a>

+## Install the multifactor authentication Server

+The installation path is picked up from the registry from the previous PhoneFactor Agent installation, so it should install in the same location (for example, C:\Program Files\PhoneFactor). New installations have a different default install path (for example, C:\Program Files\multifactor authentication Server). The data file left by the previous PhoneFactor Agent should be upgraded during installation, so your users and settings should still be there after installing the new multifactor authentication Server.

+1. If prompted, activate the multifactor authentication Server and ensure it is assigned to the correct replication group.

+2. If the Web Service SDK was previously installed, install the new Web Service SDK through the multifactor authentication Server User Interface.

+3. If the User portal was previously installed on the PhoneFactor Agent Server, install the new multifactor authentication User portal through the multifactor authentication Server User Interface.

+ The default virtual directory name is now **MultiFactorAuth** instead of **PhoneFactor**. If you want to use the previous name, you must change the name of the virtual directory during installation. Otherwise, if you allow the install to use the new default name, you should click the User portal icon in the multifactor authentication Server and update the User portal URL on the Settings tab.

+ The default virtual directory name is now **MultiFactorAuth** instead of **PhoneFactor**. If you want to use the previous name, you must change the name of the virtual directory during installation. Otherwise, if you allow the install to use the new default name, you should click the User portal icon in the multifactor authentication Server and update the User portal URL on the Settings tab. Existing users need to be informed of the new URL.

+- [Install the users portal](howto-mfaserver-deploy-userportal.md) for the Microsoft Entra multifactor authentication Server.

+description: Steps and guidance to upgrade the Microsoft Entra multifactor authentication Server to a newer version.

+# Upgrade to the latest Microsoft Entra multifactor authentication Server

+This article walks you through the process of upgrading Microsoft Entra multifactor authentication Server v6.0 or higher. If you need to upgrade an old version of the PhoneFactor Agent, refer to [Upgrade the PhoneFactor Agent to Microsoft Entra multifactor authentication Server](howto-mfaserver-deploy-upgrade-pf.md).

+> In September 2022, Microsoft announced deprecation of Microsoft Entra multifactor authentication Server. Beginning September 30, 2024, Microsoft Entra multifactor authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Azure MFA service by using the latest Migration Utility included in the most recent [Azure MFA Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure MFA Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+> To get started with cloud-based MFA, see [Tutorial: Secure user sign-in events with Microsoft Entra multifactor authentication](tutorial-enable-azure-mfa.md).

+1. Use the instructions in [Download the Microsoft Entra multifactor authentication Server](howto-mfaserver-deploy.md#download-the-mfa-server) to get the latest version of the Azure MFA Server installer.

+2. Make a backup of the MFA Server data file located at C:\Program Files\multifactor authentication Server\Data\PhoneFactor.pfdata (assuming the default install location) on your primary MFA Server.

+ > You do not need to uninstall your current MFA Server before running the installer. The installer performs an in-place upgrade. The installation path is picked up from the registry from the previous installation, so it installs in the same location (for example, C:\Program Files\multifactor authentication Server).

+These instructions only apply if you run multifactor authentication Server separately from your AD FS servers. If both services run on the same servers, skip this section and go to the installation steps.

+3. Go to **AD FS** > **Authentication Policies** > **Edit Global multifactor authentication Policy**. Uncheck **WindowsAzureMultiFactorAuthentication** or **AzureMFAServerAuthentication** (depending on the current version installed).

+8. Go to **AD FS** > **Authentication Policies** > **Edit Global multifactor authentication Policy**. Check **AzureMfaServerAuthentication**.

+* Get examples of [Advanced scenarios with Microsoft Entra multifactor authentication and third-party VPNs](howto-mfaserver-nps-vpn.md)

+# User portal for the Microsoft Entra multifactor authentication Server

+The user portal is an IIS web site that allows users to enroll in Microsoft Entra multifactor authentication 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.

+Depending on your environment, you may want to deploy the user portal on the same server as Microsoft Entra multifactor authentication Server or on another internet-facing server.

+> In September 2022, Microsoft announced deprecation of Microsoft Entra multifactor authentication Server. Beginning September 30, 2024, Microsoft Entra multifactor authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Azure MFA service by using the latest Migration Utility included in the most recent [Azure MFA Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure MFA Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+> To get started with cloud-based MFA, see [Tutorial: Secure user sign-in events with Microsoft Entra multifactor authentication](tutorial-enable-azure-mfa.md).

+> The user portal is only available with multifactor authentication Server. If you use multifactor authentication in the cloud, refer your users to the [Set-up your account for two-step verification](https://support.microsoft.com/account-billing/how-to-use-the-microsoft-authenticator-app-9783c865-0308-42fb-a519-8cf666fe0acc) or [Manage your settings for two-step verification](https://support.microsoft.com/account-billing/change-your-two-step-verification-method-and-settings-c801d5ad-e0fc-4711-94d5-33ad5d4630f7).

+In either scenario, if the Microsoft Entra multifactor authentication Web Service SDK is **not** already installed on the Microsoft Entra multifactor authentication Server, complete the steps that follow.

+1. Open the multifactor authentication Server console.

+<a name='deploy-the-user-portal-on-the-same-server-as-the-azure-ad-multi-factor-authentication-server'></a>

+## Deploy the user portal on the same server as the Microsoft Entra multifactor authentication Server

+The following pre-requisites are required to install the user portal on the **same server** as the Microsoft Entra multifactor authentication Server:

+* Secure the Microsoft Entra multifactor authentication Web Service SDK with a TLS/SSL certificate.

+1. Open the Microsoft Entra multifactor authentication Server console, click the **User Portal** icon in the left menu, then click **Install User Portal**.

+If the server where Microsoft Entra multifactor authentication Server is running isn't internet-facing, you should install the user portal on a **separate, internet-facing server**.

+* Use v6.0 or higher of the Microsoft Entra multifactor authentication Server.

+* Secure the Microsoft Entra multifactor authentication Web Service SDK with a TLS/SSL certificate.

+* Ensure that the user portal can connect to the Microsoft Entra multifactor authentication Web Service SDK over TLS/SSL.

+* Ensure that the user portal can authenticate to the Microsoft Entra multifactor authentication Web Service SDK using the credentials of a service account in the "PhoneFactor Admins" security group. This service account and group should exist in Active Directory if the Microsoft Entra multifactor authentication Server is running on a domain-joined server. This service account and group exist locally on the Microsoft Entra multifactor authentication Server if it isn't joined to a domain.

+Installing the user portal on a server other than the Microsoft Entra multifactor authentication Server requires the following steps:

+1. **On the MFA Server**, browse to the installation path (Example: C:\Program Files\multifactor authentication Server), and copy the file **MultiFactorAuthenticationUserPortalSetup64** to a location accessible to the internet-facing server where you'll install it.

+<a name='configure-user-portal-settings-in-the-azure-ad-multi-factor-authentication-server'></a>

+## Configure user portal settings in the Microsoft Entra multifactor authentication Server

+Now that the user portal is installed, you need to configure the Microsoft Entra multifactor authentication Server to work with the portal.

+1. In the Microsoft Entra multifactor authentication Server console, click the **User Portal** icon. On the Settings tab, enter the URL to the user portal in the **User Portal URL** textbox. If email functionality has been enabled, this URL is included in the emails that are sent to users when they're imported into the Microsoft Entra multifactor authentication Server.

+Microsoft Entra multifactor authentication server provides several options for the user portal. The following table provides a list of these options and an explanation of what they're used for.

+| Allow user enrollment | Allow a user to enroll in multifactor authentication by taking them to a setup screen that prompts them for additional information such as telephone number. Prompt for backup phone allows users to specify a secondary phone number. Prompt for third-party OATH token allows users to specify a third-party OATH token. |

+| Enable logging | Enable logging on the user portal. The log files are located at: C:\Program Files\multifactor authentication Server\Logs. |

+> Starting in March of 2019 the phone call options will not be available to MFA Server users in free/trial Microsoft Entra tenants. SMS messages are not impacted by this change. Phone call will continue to be available to users in paid Microsoft Entra tenants. This change only impacts free/trial Microsoft Entra tenants.

+For example, when a user signs in to the user portal for the first time, they're then taken to the Microsoft Entra multifactor authentication User Setup page. Depending on how you have configured Microsoft Entra multifactor authentication, the user may be able to select their authentication method.

+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. Microsoft Entra multifactor 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. Microsoft Entra multifactor 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).

+After the activation is complete, the user clicks the **Authenticate Me Now** button. Microsoft Entra multifactor 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 Microsoft Entra multifactor 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.

+- [Deploy the Microsoft Entra multifactor authentication Server Mobile App Web Service](howto-mfaserver-deploy-mobileapp.md)

+ Title: Getting started Microsoft Entra multifactor authentication Server

+description: Step-by-step get started with Microsoft Entra multifactor authentication Server on-premises

+# Getting started with the Microsoft Entra multifactor authentication Server

+This page covers a new installation of the server and setting it up with on-premises Active Directory. If you already have the MFA server installed and are looking to upgrade, see [Upgrade to the latest Azure multifactor authentication Server](howto-mfaserver-deploy-upgrade.md). If you're looking for information on installing just the web service, see [Deploying the Azure multifactor authentication Server Mobile App Web Service](howto-mfaserver-deploy-mobileapp.md).

+> In September 2022, Microsoft announced deprecation of Azure multifactor authentication Server. Beginning September 30, 2024, Azure multifactor authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Microsoft Entra multifactor authentication service by using the latest Migration Utility included in the most recent [Microsoft Entra multifactor authentication Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Microsoft Entra multifactor authentication Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+> To get started with cloud-based MFA, see [Tutorial: Secure user sign-in events with Azure multifactor authentication](tutorial-enable-azure-mfa.md).

+Before you download the Azure multifactor authentication Server, think about what your load and high availability requirements are. Use this information to decide how and where to deploy.

+Do you need to set up multiple servers for high availability or load balancing? There are many ways to set up this configuration with Microsoft Entra multifactor authentication Server. When you install your first Microsoft Entra multifactor authentication Server, it becomes the master. Any other 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 Microsoft Entra multifactor authentication 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.

+Make sure the server that you're using for Azure multifactor authentication meets the following requirements.

+| Azure multifactor authentication Server Requirements | Description |

+¹If Microsoft Entra multifactor authentication Server fails to activate on an Azure VM that runs Windows Server 2019 or later, try using an earlier version of Windows Server.

+<a name='azure-active-directory-multi-factor-authentication-server-components'></a>

+### Microsoft Entra multifactor authentication Server Components

+There are three web components that make up Microsoft Entra multifactor authentication Server:

+* Web Service SDK - Enables communication with the other components and is installed on the Microsoft Entra multifactor authentication application server

+* User portal - An IIS web site that allows users to enroll in Azure multifactor authentication and maintain their accounts.

+All three components can be installed on the same server if the server is internet-facing. If breaking up the components, the Web Service SDK is installed on the Microsoft Entra multifactor authentication application server and the User portal and Mobile App Web Service are installed on an internet-facing server.

+<a name='azure-multi-factor-authentication-server-firewall-requirements'></a>

+### Azure multifactor authentication Server firewall requirements

+Follow these steps to download the Microsoft Entra multifactor authentication Server:

+> In September 2022, Microsoft announced deprecation of Azure multifactor authentication Server. Beginning September 30, 2024, Azure multifactor authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Microsoft Entra multifactor authentication service by using the latest Migration Utility included in the most recent [Microsoft Entra multifactor authentication Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Microsoft Entra multifactor authentication Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+> To get started with cloud-based MFA, see [Tutorial: Secure user sign-in events with Azure multifactor authentication](tutorial-enable-azure-mfa.md).

+1. Browse to **Protection** > **multifactor authentication** > **Server settings**.

+5. Back on the page that you downloaded the server from, click the **Generate Activation Credentials** button. Copy this information into the Microsoft Entra multifactor authentication Server in the boxes provided and click **Activate**.

+The email you send should be determined by how you configure your users for two-step verification. For example, if you are able to import phone numbers from the company directory, the email should include the default phone numbers so that users know what to expect. If you do not import phone numbers, or your users are going to use the mobile app, send them an email that directs them to complete their account enrollment. Include a hyperlink to the Azure multifactor authentication User portal in the email.

+1. In the Microsoft Entra multifactor authentication Server, on the left, select **Users**.

+1. In the Microsoft Entra multifactor authentication Server, on the left, select **Directory Integration**.

+<a name='how-the-azure-ad-multi-factor-authentication-server-handles-user-data'></a>

+## How the Microsoft Entra multifactor authentication Server handles user data

+When you use the multifactor authentication Server on-premises, a user's data is stored in the on-premises servers. No persistent user data is stored in the cloud. When the user performs a two-step verification, the MFA Server sends data to the Microsoft Entra multifactor authentication cloud service to perform the verification. When these authentication requests are sent to the cloud service, the following fields are sent in the request and logs so that they are available in the customer's authentication/usage reports. Some of the fields are optional so they can be enabled or disabled within the multifactor authentication Server. The communication from the MFA Server to the MFA cloud service uses SSL/TLS over port 443 outbound. These fields are:

+> Starting in March of 2019 the phone call options will not be available to MFA Server users in free/trial Microsoft Entra tenants. SMS messages are not impacted by this change. Phone call will continue to be available to users in paid Microsoft Entra tenants. This change only impacts free/trial Microsoft Entra tenants.

+<a name='back-up-and-restore-azure-active-directory-multi-factor-authentication-server'></a>

+## Back up and restore Microsoft Entra multifactor authentication Server

+To back up Microsoft Entra multifactor authentication Server, ensure that you have a copy of the **C:\Program Files\multifactor authentication Server\Data** folder including the **PhoneFactor.pfdata** file.

+1. Reinstall Microsoft Entra multifactor authentication Server on a new server.

+2. Activate the new Microsoft Entra multifactor authentication Server.

+- Set up and configure the Microsoft Entra multifactor authentication Server with [Active Directory Federation Service](multi-factor-authentication-get-started-adfs.md), [RADIUS Authentication](howto-mfaserver-dir-radius.md), or [LDAP Authentication](howto-mfaserver-dir-ldap.md).

+- Set up and configure [Remote Desktop Gateway and Azure multifactor authentication Server using RADIUS](howto-mfaserver-nps-rdg.md).

+- [Deploy the Azure multifactor authentication Server Mobile App Web Service](howto-mfaserver-deploy-mobileapp.md).

+- [Advanced scenarios with Azure multifactor authentication and third-party VPNs](howto-mfaserver-nps-vpn.md).

+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 Microsoft Entra 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.

+description: Deploying RADIUS Authentication and Azure multifactor authentication Server.

+# Integrate RADIUS authentication with Azure multifactor authentication Server

+RADIUS is a standard protocol to accept authentication requests and to process those requests. The Azure multifactor 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 multifactor authentication 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 multifactor authentication, and sends a response back to the RADIUS client. The authentication request only succeeds if both the primary authentication and the Azure multifactor authentication succeed.

+> In September 2022, Microsoft announced deprecation of Azure multifactor authentication Server. Beginning September 30, 2024, Azure multifactor authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Azure MFA service by using the latest Migration Utility included in the most recent [Azure MFA Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure MFA Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+> To get started with cloud-based MFA, see [Tutorial: Secure user sign-in events with Microsoft Entra multifactor authentication](tutorial-enable-azure-mfa.md).

+> If you use cloud-based MFA, see [Integrate your existing NPS infrastructure with Azure multifactor authentication](howto-mfa-nps-extension.md).

+To configure RADIUS authentication, install the Azure multifactor 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 multifactor authentication Server:

+1. In the Azure multifactor authentication Server, click the RADIUS Authentication icon in the left menu.

+5. Enter the IP address of the appliance/server that will authenticate to the Azure multifactor authentication Server, an application name (optional), and a shared secret.

+ The shared secret needs to be the same on both the Azure multifactor authentication Server and appliance/server.

+6. Check the **Require multifactor authentication user match** box if all users have been imported into the Server and subject to multifactor 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.

+ The shared secret needs to be the same on both the Azure multifactor authentication Server and RADIUS server. Change the Authentication port and Accounting port if different ports are used by the RADIUS server.

+1. 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 multifactor authentication Server.

+You've successfully configured the Azure multifactor authentication Server. The Server is now listening on the configured ports for RADIUS access requests from the configured clients.

+* Configure your appliance/server to authenticate via RADIUS to the Azure multifactor authentication Server's IP address, which acts as the RADIUS server.

+Learn how to [integrate with RADIUS authentication](howto-mfa-nps-extension.md) if you have Microsoft Entra multifactor authentication in the cloud.

+> When you use cloud-based Azure Multi-Factor Authentication, there is no alternative to the IIS plugin provided by Azure Multi-Factor Authentication (MFA) Server. Instead, use Web Application Proxy (WAP) with Active Directory Federation Services (AD FS) or Microsoft Entra application proxy.

+Azure multifactor authentication Server (Azure MFA Server) can be used to seamlessly connect with various third-party VPN solutions. This article focuses on Cisco&reg; 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](howto-mfaserver-deploy.md#next-steps).

+> As of July 1, 2019, Microsoft no longer offers MFA Server for new deployments. New customers that want to require multifactor authentication during sign-in events should use cloud-based Microsoft Entra multifactor authentication.

+> To get started with cloud-based MFA, see [Tutorial: Secure user sign-in events with Microsoft Entra multifactor authentication](tutorial-enable-azure-mfa.md).

+- [Augment your existing authentication infrastructure with the NPS extension for Azure multifactor authentication](howto-mfa-nps-extension.md)

+- [Configure Azure multifactor authentication settings](howto-mfa-mfasettings.md)

+description: Deploying Windows Authentication and Azure multifactor authentication Server.

+# Windows Authentication and Azure multifactor authentication Server

+Use the Windows Authentication section of the Azure multifactor 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 multifactor authentication for Terminal Services to take effect.

+* If 'Require Azure multifactor 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.

+> As of July 1, 2019, Microsoft no longer offers MFA Server for new deployments. New customers that want to require multifactor authentication during sign-in events should use cloud-based Microsoft Entra multifactor authentication.

+> To get started with cloud-based MFA, see [Tutorial: Secure user sign-in events with Microsoft Entra multifactor authentication](tutorial-enable-azure-mfa.md).

+1. In the Azure multifactor authentication Server click the Windows Authentication icon.

+6. The Trusted IPs tab allows you to skip Azure multifactor authentication for Windows sessions originating from specific IPs. For example, if employees use the application from the office and from home, you may decide you don't want their phones ringing for Azure multifactor authentication while at the office. For this, you would specify the office subnet as Trusted IPs entry.

+# Microsoft Entra Password Protection agent version history

+To download the most recent version, see [Microsoft Entra Password Protection for Windows Server Active Directory](https://www.microsoft.com/download/details.aspx?id=57071).

+* Fixed issue with Microsoft Entra Connect Agent Updater not being updated

+It has been almost two years since the GA versions of the on-premises Microsoft Entra Password Protection agents were released. A new update is now available - see change descriptions below. Thank you to everyone who has given us feedback on the product.

+* The Proxy service now supports automatic upgrade. Automatic upgrade uses the Microsoft Entra Connect Agent Updater service, which is installed side by side with the Proxy service. Automatic upgrade is on by default.

+* 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; see [Monitor Microsoft Entra Password Protection](howto-password-ban-bad-on-premises-monitor.md).

+> 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 Microsoft Entra password protection Proxy service is required. It is not required to re-register the forest.

+[Deploy Microsoft Entra Password Protection](howto-password-ban-bad-on-premises-deploy.md)

+ Title: Deploy on-premises Microsoft Entra Password Protection

+description: Learn how to plan and deploy Microsoft Entra Password Protection in an on-premises Active Directory Domain Services environment

+# Plan and deploy on-premises Microsoft Entra Password Protection

+Users often create passwords that use common local words such as a school, sports team, or famous person. These passwords are easy to guess, and weak against dictionary-based attacks. To enforce strong passwords in your organization, Microsoft Entra Password Protection provides a global and custom banned password list. A password change request fails if there's a match in this banned password list.

+To protect your on-premises Active Directory Domain Services (AD DS) environment, you can install and configure Microsoft Entra Password Protection to work with your on-prem DC. This article shows you how to install and register the Microsoft Entra Password Protection proxy service and Microsoft Entra Password Protection DC agent in your on-premises environment.

+For more information on how Microsoft Entra Password Protection works in an on-premises environment, see [How to enforce Microsoft Entra Password Protection for Windows Server Active Directory](concept-password-ban-bad-on-premises.md).

+The following diagram shows how the basic components of Microsoft Entra 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. For more information, see [Conceptual overview of Microsoft Entra Password Protection](concept-password-ban-bad-on-premises.md).

+It is important to note that Microsoft Entra Password Protection can only validate passwords during password change or set operations. Passwords that were accepted and stored in Active Directory prior to the deployment of Microsoft Entra Password Protection will never be validated and will continue working as-is. Over time, all users and accounts will eventually start using Microsoft Entra Password Protection-validated passwords as their existing passwords expire normally. Accounts configured with "password never expires" are exempt from this.

+There are no additional requirements to deploy Microsoft Entra Password Protection across multiple forests.

+Each forest is independently configured, as described in the following section to [deploy on-prem Microsoft Entra Password Protection](#download-required-software). Each Microsoft Entra Password Protection proxy can only support domain controllers from the forest that it's joined to.

+The Microsoft Entra Password Protection software in any forest is unaware of password protection software that's deployed in other forests, regardless of Active Directory trust configurations.

+Password change or set events aren't processed and persisted on read-only domain controllers (RODCs). Instead, they're forwarded to writable domain controllers. You don't have to install the Microsoft Entra Password Protection DC agent software on RODCs.

+Further, it's not supported to run the Microsoft Entra Password Protection proxy service on a read-only domain controller.

+The main concern for password protection is the availability of Microsoft Entra Password Protection proxy servers when the DCs in a forest try to download new policies or other data from Azure. Each Microsoft Entra Password Protection 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 Microsoft Entra Password Protection proxy servers is enough to ensure availability. This configuration results in timely download of new policies and other data. You can deploy additional Microsoft Entra Password Protection proxy servers if desired.

+The design of the Microsoft Entra Password Protection DC agent software mitigates the usual problems that are associated with high availability. The Microsoft Entra Password Protection DC agent maintains a local cache of the most recently downloaded password policy. Even if all registered proxy servers become unavailable, the Microsoft Entra Password Protection 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 Microsoft Entra Password Protection.

+For information on licensing, see [Microsoft Entra Password Protection licensing requirements](concept-password-ban-bad.md#license-requirements).

+* All machines, including domain controllers, that have Microsoft Entra Password Protection components installed must have the Universal C Runtime installed.

+* You need an account that has Active Directory domain administrator privileges in the forest root domain to register the Windows Server Active Directory forest with Microsoft Entra ID.

+* Network connectivity must exist between at least one domain controller in each domain and at least one server that hosts the proxy service for Microsoft Entra 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.

+* All machines where the Microsoft Entra Password Protection Proxy service will be installed must have network access to the following endpoints:

+ |`https://enterpriseregistration.windows.net`|Microsoft Entra Password Protection functionality|

+ |`https://autoupdate.msappproxy.net` | Microsoft Entra Password Protection auto-upgrade functionality |

+<a name='azure-ad-password-protection-dc-agent'></a>

+### Microsoft Entra Password Protection DC agent

+The following requirements apply to the Microsoft Entra Password Protection DC agent:

+* Machines where the Microsoft Entra Password Protection DC agent software will be installed can run any supported version of Windows Server, including Windows Server Core editions.

+* All machines where the Microsoft Entra Password Protection DC agent will be installed must have .NET 4.7.2 installed.

+* Any Active Directory domain that runs the Microsoft Entra Password Protection DC agent service must use Distributed File System Replication (DFSR) for sysvol replication.

+ * If your domain isn't already using DFSR, you must migrate before installing Microsoft Entra Password Protection. For more information, see [SYSVOL Replication Migration Guide: FRS to DFS Replication](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd640019(v=ws.10))

+ > The Microsoft Entra Password Protection DC agent software will currently install on domain controllers in domains that are still using FRS (the predecessor technology to DFSR) for sysvol replication, but the software will NOT work properly in this environment.

+ > Migrate your domain to use DFSR as soon as possible, both for DFSR's inherent benefits and to unblock the deployment of Microsoft Entra Password Protection. Future versions of the software will be automatically disabled when running in a domain that's still using FRS.

+<a name='azure-ad-password-protection-proxy-service'></a>

+### Microsoft Entra Password Protection proxy service

+The following requirements apply to the Microsoft Entra Password Protection proxy service:

+* All machines where the Microsoft Entra Password Protection proxy service will be installed must run Windows Server 2012 R2 or later, including Windows Server Core editions.

+ > The Microsoft Entra Password Protection proxy service deployment is a mandatory requirement for deploying Microsoft Entra Password Protection even though the domain controller may have outbound direct internet connectivity.

+* All machines where the Microsoft Entra Password Protection proxy service will be installed must have .NET 4.7.2 installed.

+* All machines that host the Microsoft Entra Password Protection proxy service must be configured to grant domain controllers the ability to log on to the proxy service. This ability is controlled via the "Access this computer from the network" privilege assignment.

+* All machines that host the Microsoft Entra Password Protection proxy service must be configured to allow outbound TLS 1.2 HTTP traffic.

+* A *Global Administrator* account is required to register the Microsoft Entra Password Protection proxy service for the first time in a given tenant. Subsequent proxy and forest registrations with Microsoft Entra ID may use an account with either *Global Administrator* or *Security Administrator* credentials.

+<a name='microsoft-azure-ad-connect-agent-updater-prerequisites'></a>

+### Microsoft Entra Connect Agent Updater prerequisites

+The Microsoft Entra Connect Agent Updater service is installed side by side with the Microsoft Entra Password Protection Proxy service. Additional configuration is required in order for the Microsoft Entra Connect Agent Updater service to be able to function:

+* The Microsoft Entra Connect Agent Updater service also requires the TLS 1.2 steps specified in [TLS requirements](../app-proxy/application-proxy-add-on-premises-application.md#tls-requirements).

+> Microsoft Entra Password Protection proxy and Microsoft Entra application proxy install different versions of the Microsoft Entra Connect Agent Updater service, which is why the instructions refer to Application Proxy content. These different versions are incompatible when installed side by side and doing so will prevent the Agent Updater service from contacting Azure for software updates, so you should never install Microsoft Entra Password Protection Proxy and Application Proxy on the same machine.

+There are two required installers for an on-premises Microsoft Entra Password Protection deployment:

+* Microsoft Entra Password Protection DC agent (*AzureADPasswordProtectionDCAgentSetup.msi*)

+* Microsoft Entra Password Protection proxy (*AzureADPasswordProtectionProxySetup.exe*)

+The Microsoft Entra Password Protection proxy service is typically on a member server in your on-premises AD DS environment. Once installed, the Microsoft Entra Password Protection proxy service communicates with Microsoft Entra ID to maintain a copy of the global and customer banned password lists for your Microsoft Entra tenant.

+In the next section, you install the Microsoft Entra Password Protection DC agents on domain controllers in your on-premises AD DS environment. These DC agents communicate with the proxy service to get the latest banned password lists for use when processing password change events within the domain.