**What does it not do?**
It doesn't restrict access to Microsoft Entra data using PowerShell, Microsoft GraphAPI, or other clients such as Visual Studio.
It doesn't restrict access as long as a user is assigned a custom role (or any role).
**When should I use this switch?**
Use this option to prevent users from misconfiguring the resources that they own.
**When should I not use this switch?**
Don't use this switch as a security measure. Instead, create a Conditional Access policy that targets Microsoft Azure Management that blocks non-administrators access to [Microsoft Azure Management](~/identity/conditional-access/concept-conditional-access-cloud-apps.md#microsoft-azure-management).
**How do I grant only a specific non-administrator users the ability to use the Microsoft Entra administration portal?**
Set this option to **Yes**, then assign them a role like global reader.
**Restrict access to the Microsoft Entra administration portal**
A Conditional Access policy that targets Microsoft Azure Management targets access to all Azure management. |
+| **Restrict access to Microsoft Entra administration portal** | **What does this switch do?**
**No** lets non-administrators browse the Microsoft Entra administration portal.
**Yes** Restricts non-administrators from browsing the Microsoft Entra administration portal. Non-administrators who are owners of groups or applications are unable to use the Azure portal to manage their owned resources.
**What does it not do?**
It doesn't restrict access to Microsoft Entra data using PowerShell, Microsoft GraphAPI, or other clients such as Visual Studio.
It doesn't restrict access as long as a user is assigned a custom role (or any role).
**When should I use this switch?**
Use this option to prevent users from misconfiguring the resources that they own.
**When should I not use this switch?**
Don't use this switch as a security measure. Instead, create a Conditional Access policy that targets Windows Azure Service Management API that blocks non-administrators access to [Windows Azure Service Management API](~/identity/conditional-access/concept-conditional-access-cloud-apps.md#windows-azure-service-management-api).
**How do I grant only a specific non-administrator users the ability to use the Microsoft Entra administration portal?**
Set this option to **Yes**, then assign them a role like global reader.
**Restrict access to the Microsoft Entra administration portal**
A Conditional Access policy that targets Windows Azure Service Management API targets access to all Azure management. |
| **Restrict non-admin users from creating tenants** | Users can create tenants in the Microsoft Entra ID and Microsoft Entra administration portal under Manage tenant. The creation of a tenant is recorded in the Audit log as category DirectoryManagement and activity Create Company. Anyone who creates a tenant becomes the Global Administrator of that tenant. The newly created tenant doesn't inherit any settings or configurations.
**What does this switch do?**
Setting this option to **Yes** restricts creation of Microsoft Entra tenants to the Global Administrator or tenant creator roles. Setting this option to **No** allows non-admin users to create Microsoft Entra tenants. Tenant create will continue to be recorded in the Audit log.
**How do I grant only a specific non-administrator users the ability to create new tenants?**
Set this option to Yes, then assign them the tenant creator role.|
| **Restrict users from recovering the BitLocker key(s) for their owned devices** | This setting can be found in the Microsoft Entra admin center in the Device Settings. Setting this option to **Yes** restricts users from being able to self-service recover BitLocker key(s) for their owned devices. Users will have to contact their organization's helpdesk to retrieve their BitLocker keys. Setting this option to **No** allows users to recover their BitLocker key(s). |
| **Read other users** | This setting is available in Microsoft Graph and PowerShell only. Setting this flag to `$false` prevents all non-admins from reading user information from the directory. This flag doesn't prevent reading user information in other Microsoft services like Exchange Online.
This setting is meant for special circumstances, so we don't recommend setting the flag to `$false`. | diff --git a/docs/fundamentals/whats-new-archive.md b/docs/fundamentals/whats-new-archive.md index 9089e8df145..ed907ebd35c 100644 --- a/docs/fundamentals/whats-new-archive.md +++ b/docs/fundamentals/whats-new-archive.md @@ -2092,154 +2092,4 @@ With this new parity update, customers can now integrate non-gallery application For more information, see [Claims mapping policy - Microsoft Entra](~/identity-platform/reference-claims-mapping-policy-type.md#claim-schema-entry-elements). ---- - -## June 2022 - - -### Public preview - New provisioning connectors in the Azure AD Application Gallery - June 2022 - -**Type:** New feature -**Service category:** App Provisioning -**Product capability:** 3rd Party Integration - - -You can now automate creating, updating, and deleting user accounts for these newly integrated apps: - -- [Whimsical](~/identity/saas-apps/whimsical-provisioning-tutorial.md) - -For more information about how to better secure your organization by using automated user account provisioning, see [Automate user provisioning to SaaS applications with Azure AD](~/identity/app-provisioning/user-provisioning.md). - - ---- - - -### Public Preview - Roles are being assigned outside of Privileged Identity Management - -**Type:** New feature -**Service category:** Privileged Identity Management -**Product capability:** Privileged Identity Management - -Customers can be alerted on assignments made outside PIM either directly on the Azure portal or also via email. For the current public preview, the assignments are being tracked at the subscription level. For more information, see [Configure security alerts for Azure roles in Privileged Identity Management](~/id-governance/privileged-identity-management/pim-resource-roles-configure-alerts.md#alerts). - ---- - - -### General Availability - Temporary Access Pass is now available - -**Type:** New feature -**Service category:** MFA -**Product capability:** User Authentication - - - -Temporary Access Pass (TAP) is now generally available. TAP can be used to securely register password-less methods such as Phone Sign-in, phishing resistant methods such as FIDO2, and even help Windows onboarding (AADJ and WHFB). TAP also makes recovery easier when a user has lost or forgotten their strong authentication methods and needs to sign in to register new authentication methods. For more information, see: [Configure Temporary Access Pass in Azure AD to register Passwordless authentication methods](~/identity/authentication/howto-authentication-temporary-access-pass.md). - - ---- - - - -### Public Preview of Dynamic Group support for MemberOf - -**Type:** New feature -**Service category:** Group Management -**Product capability:** Directory - - - -Create "nested" groups with Azure AD Dynamic Groups! This feature enables you to build dynamic Azure AD Security Groups and Microsoft 365 groups based on other groups! For example, you can now create Dynamic-Group-A with members of Group-X and Group-Y. For more information, see: [Steps to create a memberOf dynamic group](~/identity/users/groups-dynamic-rule-member-of.md#steps-to-create-a-memberof-dynamic-group). - - ---- - - - -### New Federated Apps available in Azure AD Application gallery - June 2022 - -**Type:** New feature -**Service category:** Enterprise Apps -**Product capability:** 3rd Party Integration - - - -In June 2022 we've added the following 22 new applications in our App gallery with Federation support: - -[Leadcamp Mailer](https://app.leadcamp.io/sign-in), [PULCE](https://ups.pulce.tech/index.php), [Hive Learning](~/identity/saas-apps/hive-learning-tutorial.md), [Planview LeanKit](~/identity/saas-apps/planview-leankit-tutorial.md), [Javelo](~/identity/saas-apps/javelo-tutorial.md), [きょうしつでビスケット,Agile Provisioning](https://online.viscuit.com/v1/all/?server=7), [xCarrier®](~/identity/saas-apps/xcarrier-tutorial.md), [Skillcast](~/identity/saas-apps/skillcast-tutorial.md), [JTRA](https://www.jingtengtech.com/r/#/register?id=1), [InnerSpace inTELLO](https://intello.innerspace.io/), [Seculio](~/identity/saas-apps/seculio-tutorial.md), [XplicitTrust Partner Console](https://console.xplicittrust.com/#/partner/auth), [Veracity Single-Sign On](https://www.veracity.com/), [Guardium Data Protection](~/identity/saas-apps/guardium-data-protection-tutorial.md), [IntellicureEHR v7](https://www.intellicure.com/wound-care-software/ehr/), [BMIS - Battery Management Information System](~/identity/saas-apps/battery-management-information-system-tutorial.md), [Finbiosoft Cloud](https://account.finbiosoft.com/), [Standard for Success K-12](~/identity/saas-apps/standard-for-success-tutorial.md), [E2open LSP](~/identity/saas-apps/e2open-lsp-tutorial.md), [TVU Service](~/identity/saas-apps/tvu-service-tutorial.md), [S4 - Digitsec](~/identity/saas-apps/s4-digitsec-tutorial.md). - -You can also find the documentation of all the applications from here https://aka.ms/AppsTutorial, - -For listing your application in the Azure AD app gallery, see the details here https://aka.ms/AzureADAppRequest - - - - - ---- - - - -### General Availability – Protect against by-passing of cloud Azure AD Multi-Factor Authentication when federated with Azure AD - -**Type:** New feature -**Service category:** MS Graph -**Product capability:** Identity Security & Protection - - - -We're delighted to announce a new security protection that prevents bypassing of cloud Azure AD Multi-Factor Authentication when federated with Azure AD. When enabled for a federated domain in your Azure AD tenant, it ensures that a compromised federated account can't bypass Azure AD Multi-Factor Authentication by imitating that a multi factor authentication has already been performed by the identity provider. The protection can be enabled via new security setting, [federatedIdpMfaBehavior](/graph/api/resources/internaldomainfederation?view=graph-rest-1.0&preserve-view=true#federatedidpmfabehavior-values). - -We highly recommend enabling this new protection when using Azure AD Multi-Factor Authentication as your multi factor authentication for your federated users. To learn more about the protection and how to enable it, visit [Enable protection to prevent by-passing of cloud Azure AD Multi-Factor Authentication when federated with Azure AD](/windows-server/identity/ad-fs/deployment/best-practices-securing-ad-fs#enable-protection-to-prevent-by-passing-of-cloud-azure-ad-multi-factor-authentication-when-federated-with-azure-ad). - - ---- - - - -### Public Preview - New Azure portal All Users list and User Profile UI - -**Type:** Changed feature -**Service category:** User Management -**Product capability:** User Management - - -We're enhancing the All Users list and User Profile in the Azure portal to make it easier to find and manage your users. Improvements include: - - -All Users List: -- Infinite scrolling (yes, no 'Load more') -- More user properties can be added as columns and filtered on -- Columns can be reordered via drag and drop -- Default columns shown and their order can be managed via the column picker -- The ability to copy and share the current view - - -User Profile: -- A new Overview page that surfaces insights (that is, group memberships, account enabled, MFA capable, risky user, etc.) -- A new monitoring tab -- More user properties can be viewed and edited in the properties tab - - For more information, see: [User management enhancements in Azure Active Directory](~/identity/users/users-search-enhanced.md). - ---- - - - -### General Availability - More device properties supported for Dynamic Device groups - -**Type:** Changed feature -**Service category:** Group Management -**Product capability:** Directory - - - -You can now create or update dynamic device groups using the following properties: -- deviceManagementAppId -- deviceTrustType -- extensionAttribute1-15 -- profileType - -For more information on how to use this feature, see: [Dynamic membership rule for device groups](~/identity/users/groups-dynamic-membership.md#rules-for-devices). - - --- diff --git a/docs/id-governance/deploy-access-reviews.md b/docs/id-governance/deploy-access-reviews.md index b11f477ad65..889fcc9f997 100644 --- a/docs/id-governance/deploy-access-reviews.md +++ b/docs/id-governance/deploy-access-reviews.md @@ -167,14 +167,14 @@ Typical targets for review include: ### Who will create and manage access reviews? -The administrative role required to create, manage, or read an access review depends on the type of resource being reviewed. The following table denotes the roles required for each resource type. Custom roles with permission Microsoft.Authorization/* can create and manage reviews of any resource type, and custom roles with at least permissions Microsoft.Authorization/*/read can read reviews of any resource type. +The administrative role required to create, manage, or read an access review depends on the type of resource whose membership is being reviewed. The following table denotes the roles required for each resource type. | Resource type| Create and manage access reviews (creators)| Read access review results | | - | - | -| | Group or application| Global administrator
User administrator
Identity Governance administrator
Privileged Role administrator (only does reviews for Microsoft Entra role-assignable groups)
Group owner ([if enabled by an admin](create-access-review.md#allow-group-owners-to-create-and-manage-access-reviews-of-their-groups))| Global administrator
Global reader
User administrator
Identity Governance administrator
Privileged Role administrator
Security reader
Group owner ([if enabled by an admin](create-access-review.md#allow-group-owners-to-create-and-manage-access-reviews-of-their-groups)) | |Microsoft Entra roles| Global administrator
Privileged Role administrator| Global administrator
Global reader
User administrator
Privileged Role administrator
Security reader | -| Azure resource roles| User Access Administrator (for the resource)
Resource owner| User Access Administrator (for the resource)
Resource owner
Reader (for the resource) | -| Access package| Global administrator
User administrator
Identity Governance administrator
Catalog owner (for the access package)
Access package manager (for the access package)| Global administrator
Global reader
User administrator
Identity Governance administrator
Catalog owner (for the access package)
Access package manager (for the access package)
Security reader | +| Azure resource roles| User Access Administrator (for the resource)
Resource owner
Custom roles with Microsoft.Authorization/* permission.| User Access Administrator (for the resource)
Resource owner
Reader (for the resource)
Custom roles with Microsoft.Authorization/*/read permissions. | +| Access package| Global administrator
Identity Governance administrator
Catalog owner (for the access package)
Access package manager (for the access package)| Global administrator
Global reader
User administrator
Identity Governance administrator
Catalog owner (for the access package)
Access package manager (for the access package)
Security reader |
For more information, see [Administrator role permissions in Microsoft Entra ID](~/identity/role-based-access-control/permissions-reference.md).
diff --git a/docs/id-governance/entitlement-management-access-package-resources.md b/docs/id-governance/entitlement-management-access-package-resources.md
index 9900953b656..14d93cfb81a 100644
--- a/docs/id-governance/entitlement-management-access-package-resources.md
+++ b/docs/id-governance/entitlement-management-access-package-resources.md
@@ -125,19 +125,19 @@ For more information, see [Compare groups](/office365/admin/create-groups/compar
You can have Microsoft Entra ID automatically assign users access to a Microsoft Entra enterprise application, including both SaaS applications and your organization's applications integrated with Microsoft Entra ID, when a user is assigned an access package. For applications that integrate with Microsoft Entra ID through federated single sign-on, Microsoft Entra ID issues federation tokens for users assigned to the application.
-Applications can have multiple app roles defined in their manifest. When you add an application to an access package, if that application has more than one app role, you need to specify the appropriate role for those users in each access package. If you're developing applications, you can read more about how those roles are added to your applications in [How to: Configure the role claim issued in the SAML token for enterprise applications](~/identity-platform/enterprise-app-role-management.md). If you're using the Microsoft Authentication Libraries, there is also a [code sample](~/identity-platform/sample-v2-code.md) for how to use app roles for access control.
+Applications can have multiple app roles defined in their manifest and managed through the [app roles UI](~/identity-platform/howto-add-app-roles-in-apps.md#app-roles-ui). When you add an application to an access package, if that application has more than one app role, you need to specify the appropriate role for those users in each access package. If you're developing applications, you can read more about how those roles are added to your applications in [How to: Configure the role claim issued in the SAML token for enterprise applications](~/identity-platform/enterprise-app-role-management.md). If you're using the Microsoft Authentication Libraries, there is also a [code sample](~/identity-platform/sample-v2-code.md) for how to use app roles for access control.
> [!NOTE]
-> If an application has multiple roles, and more than one role of that application are in an access package, then the user will receive all those application's roles. If instead you want users to only have some of the application's roles, then you will need to create multiple access packages in the catalog, with separate access packages for each of the application roles.
+> If an application has multiple app roles, and more than one role of that application are in an access package, then the user will receive all those application's included roles. If instead you want users to only have some of the application's roles, then you will need to create multiple access packages in the catalog, with separate access packages for each of the app roles.
-Once an application role is part of an access package:
+Once an app role is a resource of an access package:
-- When a user is assigned that access package, the user is added to that application role, if not already present.
-- When a user's access package assignment expires, their access is removed from the application, unless they have an assignment to another access package that includes that application role.
+- When a user is assigned that access package, the user is added to that app role, if not already present.
+- When a user's access package assignment expires, their access is removed from the application, unless they have an assignment to another access package that includes that app role.
Here are some considerations when selecting an application:
-- Applications may also have groups assigned to their app roles as well. You can choose to add a group in place of an application role in an access package, however then the application won't be visible to the user as part of the access package in the My Access portal.
+- Applications may also have groups assigned to their app roles as well. You can choose to add a group in place of an application and its role in an access package, however then the application won't be visible to the user as part of the access package in the My Access portal.
- Microsoft Entra admin center may also show service principals for services that can't be selected as applications. In particular, **Exchange Online** and **SharePoint Online** are services, not applications that have resource roles in the directory, so they can't be included in an access package. Instead, use group-based licensing to establish an appropriate license for a user who needs access to those services.
- Applications that only support Personal Microsoft Account users for authentication, and don't support organizational accounts in your directory, don't have application roles and can't be added to access package catalogs.
@@ -149,7 +149,7 @@ Here are some considerations when selecting an application:
1. Select **Select**.
-1. In the **Role** list, select an application role.
+1. In the **Role** list, select an app role.
diff --git a/docs/id-governance/identity-governance-applications-deploy.md b/docs/id-governance/identity-governance-applications-deploy.md
index d9e2f42fa5d..3a31eba6d11 100644
--- a/docs/id-governance/identity-governance-applications-deploy.md
+++ b/docs/id-governance/identity-governance-applications-deploy.md
@@ -80,7 +80,7 @@ At regular intervals, such as weekly, monthly or quarterly, based on the volume
* **Check that provisioning and deprovisioning are working as expected.** If you had previously configured provisioning of users to the application, then when the results of a review are applied, or a user's assignment to an access package expires, Microsoft Entra ID begins deprovisioning denied users from the application. You can [monitor the process of deprovisioning users](~/identity/app-provisioning/application-provisioning-when-will-provisioning-finish-specific-user.md). If provisioning indicates an error with the application, you can [download the provisioning log](~/identity/monitoring-health/concept-provisioning-logs.md) to investigate if there was a problem with the application.
-* **Update the Microsoft Entra configuration with any role or group changes in the application.** If the application adds new application roles in its manifest, updates existing roles, or relies upon additional groups, then you need to update the access packages and access reviews to account for those new roles or groups.
+* **Update the Microsoft Entra configuration with any role or group changes in the application.** If the application administrator adds new app roles in its [manifest](~/identity-platform/howto-add-app-roles-in-apps.md#app-roles-ui), updates existing roles, or relies upon additional groups, then you need to update the access packages and access reviews to account for those new roles or groups.
## Next steps
diff --git a/docs/id-governance/identity-governance-applications-integrate.md b/docs/id-governance/identity-governance-applications-integrate.md
index 273331114a6..cf0347d5b79 100644
--- a/docs/id-governance/identity-governance-applications-integrate.md
+++ b/docs/id-governance/identity-governance-applications-integrate.md
@@ -29,7 +29,7 @@ In order for Microsoft Entra ID Governance to be used for an application, the ap
* The application relies upon Microsoft Entra ID for federated SSO, and Microsoft Entra ID controls authentication token issuance. If Microsoft Entra ID is the only identity provider for the application, then only users who are assigned to one of the application's roles in Microsoft Entra ID are able to sign into the application. Those users that lose their application role assignment can no longer get a new token to sign in to the application.
* The application relies upon user or group lists that are provided to the application by Microsoft Entra ID. This fulfillment could be done through a provisioning protocol such as SCIM, by the application querying Microsoft Entra ID via Microsoft Graph, or the application using AD Kerberos to obtain a user's group memberships.
-If neither of those criteria are met for an application, for example when the application doesn't rely upon Microsoft Entra ID, then identity governance can still be used. However, there may be some limitations using identity governance without meeting the criteria. For instance, users that aren't in your Microsoft Entra ID, or aren't assigned to the application roles in Microsoft Entra ID, won't be included in access reviews of the application, until you add them to the application roles. For more information, see [Preparing for an access review of users' access to an application](access-reviews-application-preparation.md).
+If neither of those criteria are met for an application, for example when the application doesn't rely upon Microsoft Entra ID, then identity governance can still be used. However, there may be some limitations using identity governance without meeting the criteria. For instance, users that aren't in your Microsoft Entra ID, or aren't assigned to the application roles in Microsoft Entra ID, won't be included in access reviews of the application, until you assign them to the application roles. For more information, see [Preparing for an access review of users' access to an application](access-reviews-application-preparation.md).
@@ -63,7 +63,7 @@ Next, if the application implements a provisioning protocol, then you should con
| Integrated Windows Auth (IWA) | Deploy the [application proxy](~/identity/app-proxy/application-proxy.md), configure an application for [Integrated Windows authentication SSO](~/identity/app-proxy/application-proxy-configure-single-sign-on-with-kcd.md), and set firewall rules to prevent access to the application's endpoints except via the proxy.|
| header-based authentication | Deploy the [application proxy](~/identity/app-proxy/application-proxy.md) and configure an application for [header-based SSO](~/identity/app-proxy/application-proxy-configure-single-sign-on-with-headers.md) |
-1. If your application has multiple roles, each user has only one role in the application, and the application relies upon Microsoft Entra ID to send a user's single application-specific role as a claim of a user signing into the application, then configure those application roles in Microsoft Entra ID on your application, and then assign each user to the application role. You can use the [app roles UI](~/identity-platform/howto-add-app-roles-in-apps.md#app-roles-ui) to add those roles to the application manifest. If you're using the Microsoft Authentication Libraries, there is a [code sample](~/identity-platform/sample-v2-code.md) for how to use app roles inside your application for access control. If a user could have multiple roles simultaneously, then you may wish to implement the application to check security groups, either in the token claims or available via Microsoft Graph, instead of using application roles from the app manifest for access control.
+1. If your application has multiple roles, each user has only one role in the application, and the application relies upon Microsoft Entra ID to send a user's single application-specific role as a claim of a user signing into the application, then configure those app roles in Microsoft Entra ID on your application, and then assign each user to the application role. You can use the [app roles UI](~/identity-platform/howto-add-app-roles-in-apps.md#app-roles-ui) to add those roles to the application manifest. If you're using the Microsoft Authentication Libraries, there is a [code sample](~/identity-platform/sample-v2-code.md) for how to use app roles inside your application for access control. If a user could have multiple roles simultaneously, then you may wish to implement the application to check security groups, either in the token claims or available via Microsoft Graph, instead of using app roles from the app manifest for access control.
1. If the application supports provisioning, then [configure provisioning](~/identity/app-provisioning/configure-automatic-user-provisioning-portal.md) of assigned users and groups from Microsoft Entra ID to that application. If this is a private or custom application, you can also select the integration that's most appropriate, based on the location and capabilities of the application.
diff --git a/docs/identity/app-provisioning/on-premises-migrate-microsoft-identity-manager.md b/docs/identity/app-provisioning/on-premises-migrate-microsoft-identity-manager.md
index 7b057fc7410..e230b4cddeb 100644
--- a/docs/identity/app-provisioning/on-premises-migrate-microsoft-identity-manager.md
+++ b/docs/identity/app-provisioning/on-premises-migrate-microsoft-identity-manager.md
@@ -16,11 +16,11 @@ ms.collection: M365-identity-device-management
# 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.
+You can import into the Microsoft Entra ECMA Connector Host a configuration for a specific connector from a Microsoft Identity Manager Synchronization Service (MIM Sync) installation.
## Create a connector configuration in MIM Sync
-This section is included for illustrative purposes, if you wish to set up MIM Sync with a connector. If you already have MIM Sync with your ECMA connector configured, skip to the next section.
+This section is included for illustrative purposes, if you wish to set up MIM Sync with a connector. The MIM Sync installation is only used for the initial configuration, not for the ongoing synchronization from Microsoft Entra ID. If you already have MIM Sync with your ECMA connector configured, skip to the next section.
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. Create an account for use during the MIM Sync installation. It can be a local account on that Windows Server instance. To create a local account, open **Control Panel** > **User Accounts**, and add the user account **mimsync**.
diff --git a/docs/identity/app-provisioning/on-premises-web-services-connector.md b/docs/identity/app-provisioning/on-premises-web-services-connector.md
index 11f8e8a6bf6..57d6b69f0de 100644
--- a/docs/identity/app-provisioning/on-premises-web-services-connector.md
+++ b/docs/identity/app-provisioning/on-premises-web-services-connector.md
@@ -33,7 +33,7 @@ The web services connector implements the following functionalities:
- Connector Space Schema configuration: Allows the administrator to configure the connector space schema. The schema configuration will include a listing of Object Types and attributes for a specific implementation. The administrator can specify the object types that will be supported by the Web Service MA. The administrator may also choose here the attributes that will be part of the Connector space Schema.
-- Operation Flow configuration: Workflow designer UI for configuring the implementation of FIM operations (Import/Export) per object type through exposed web service operations functions such as:
+- Operation Flow configuration: Workflow designer UI for configuring the implementation of operations (Import/Export) per object type through exposed web service operations functions such as:
- Assignment of parameters from connector space to web service functions.
- Assignment of parameters from web service functions to the connector space.
diff --git a/docs/identity/authentication/tutorial-enable-azure-mfa.md b/docs/identity/authentication/tutorial-enable-azure-mfa.md
index e87ec40a1e7..a8757ab54c9 100644
--- a/docs/identity/authentication/tutorial-enable-azure-mfa.md
+++ b/docs/identity/authentication/tutorial-enable-azure-mfa.md
@@ -111,9 +111,9 @@ For this tutorial, configure the Conditional Access policy to require multifacto
> [!TIP]
> You can choose to apply the Conditional Access policy to **All cloud apps** or **Select apps**. To provide flexibility, you can also exclude certain apps from the policy.
-1. Browse the list of available sign-in events that can be used. For this tutorial, select **Microsoft Azure Management** so that the policy applies to sign-in events. Then choose **Select**.
+1. Browse the list of available sign-in events that can be used. For this tutorial, select **Windows Azure Service Management API** so that the policy applies to sign-in events. Then choose **Select**.
- :::image type="content" alt-text="A screenshot of the Conditional Access page, where you select the app, Microsoft Azure Management, to which the new policy will apply." source="media/tutorial-enable-azure-mfa/tutorial-enable-azure-mfa-conditional-access-menu-select-apps.png":::
+ :::image type="content" alt-text="A screenshot of the Conditional Access page, where you select the app, Windows Azure Service Management API, to which the new policy will apply." source="media/tutorial-enable-azure-mfa/tutorial-enable-azure-mfa-conditional-access-menu-select-apps.png":::
diff --git a/docs/identity/conditional-access/concept-condition-filters-for-devices.md b/docs/identity/conditional-access/concept-condition-filters-for-devices.md
index 310155b3aa0..3668a04f7d7 100644
--- a/docs/identity/conditional-access/concept-condition-filters-for-devices.md
+++ b/docs/identity/conditional-access/concept-condition-filters-for-devices.md
@@ -21,9 +21,9 @@ When creating Conditional Access policies, administrators have asked for the abi
There are multiple scenarios that organizations can now enable using filter for devices condition. The following scenarios provide examples of how to use this new condition.
-- **Restrict access to privileged resources**. For this example, lets say you want to allow access to Microsoft Azure Management from a user who is assigned a privileged role Global Administrator, has satisfied multifactor authentication and accessing from a device that is [privileged or secure admin workstations](/security/compass/privileged-access-devices) and attested as compliant. For this scenario, organizations would create two Conditional Access policies:
- - Policy 1: All users with the directory role of Global Administrator, accessing the Microsoft Azure Management cloud app, and for Access controls, Grant access, but require multifactor authentication and require device to be marked as compliant.
- - Policy 2: All users with the directory role of Global Administrator, accessing the Microsoft Azure Management cloud app, excluding a filter for devices using rule expression device.extensionAttribute1 equals SAW and for Access controls, Block. Learn how to [update extensionAttributes on a Microsoft Entra device object](/graph/api/device-update?view=graph-rest-1.0&tabs=http&preserve-view=true).
+- **Restrict access to privileged resources**. For this example, lets say you want to allow access to Windows Azure Service Management API from a user who is assigned a privileged role Global Administrator, has satisfied multifactor authentication and accessing from a device that is [privileged or secure admin workstations](/security/compass/privileged-access-devices) and attested as compliant. For this scenario, organizations would create two Conditional Access policies:
+ - Policy 1: All users with the directory role of Global Administrator, accessing the Windows Azure Service Management API cloud app, and for Access controls, Grant access, but require multifactor authentication and require device to be marked as compliant.
+ - Policy 2: All users with the directory role of Global Administrator, accessing the Windows Azure Service Management API cloud app, excluding a filter for devices using rule expression device.extensionAttribute1 equals SAW and for Access controls, Block. Learn how to [update extensionAttributes on a Microsoft Entra device object](/graph/api/device-update?view=graph-rest-1.0&tabs=http&preserve-view=true).
- **Block access to organization resources from devices running an unsupported Operating System**. For this example, lets say you want to block access to resources from Windows OS version older than Windows 10. For this scenario, organizations would create the following Conditional Access policy:
- All users, accessing all cloud apps, excluding a filter for devices using rule expression device.operatingSystem equals Windows and device.operatingSystemVersion startsWith "10.0" and for Access controls, Block.
- **Do not require multifactor authentication for specific accounts on specific devices**. For this example, lets say you want to not require multifactor authentication when using service accounts on specific devices like Teams phones or Surface Hub devices. For this scenario, organizations would create the following two Conditional Access policies:
@@ -39,7 +39,7 @@ Filter for devices is an optional control when creating a Conditional Access pol
The following steps will help create two Conditional Access policies to support the first scenario under [Common scenarios](#common-scenarios).
-Policy 1: All users with the directory role of Global Administrator, accessing the Microsoft Azure Management cloud app, and for Access controls, Grant access, but require multifactor authentication and require device to be marked as compliant.
+Policy 1: All users with the directory role of Global Administrator, accessing the Windows Azure Service Management API cloud app, and for Access controls, Grant access, but require multifactor authentication and require device to be marked as compliant.
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Conditional Access Administrator](~/identity/role-based-access-control/permissions-reference.md#conditional-access-administrator).
1. Browse to **Protection** > **Conditional Access**.
@@ -53,12 +53,12 @@ Policy 1: All users with the directory role of Global Administrator, accessing t
1. Under **Exclude**, select **Users and groups** and choose your organization's emergency access or break-glass accounts.
1. Select **Done**.
-1. Under **Target resources** > **Cloud apps** > **Include** > **Select apps**, choose **Microsoft Azure Management**, and select **Select**.
+1. Under **Target resources** > **Cloud apps** > **Include** > **Select apps**, choose **Windows Azure Service Management API**, and select **Select**.
1. Under **Access controls** > **Grant**, select **Grant access**, **Require multifactor authentication**, and **Require device to be marked as compliant**, then select **Select**.
1. Confirm your settings and set **Enable policy** to **On**.
1. Select **Create** to create to enable your policy.
-Policy 2: All users with the directory role of Global Administrator, accessing the Microsoft Azure Management cloud app, excluding a filter for devices using rule expression device.extensionAttribute1 equals SAW and for Access controls, Block.
+Policy 2: All users with the directory role of Global Administrator, accessing the Windows Azure Service Management API cloud app, excluding a filter for devices using rule expression device.extensionAttribute1 equals SAW and for Access controls, Block.
1. Select **Create new policy**.
1. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.
@@ -70,7 +70,7 @@ Policy 2: All users with the directory role of Global Administrator, accessing t
1. Under **Exclude**, select **Users and groups** and choose your organization's emergency access or break-glass accounts.
1. Select **Done**.
-1. Under **Target resources** > **Cloud apps** > **Include** > **Select apps**, choose **Microsoft Azure Management**, and select **Select**.
+1. Under **Target resources** > **Cloud apps** > **Include** > **Select apps**, choose **Windows Azure Service Management API**, and select **Select**.
1. Under **Conditions**, **Filter for devices**.
1. Toggle **Configure** to **Yes**.
1. Set **Devices matching the rule** to **Exclude filtered devices from policy**.
diff --git a/docs/identity/conditional-access/concept-conditional-access-cloud-apps.md b/docs/identity/conditional-access/concept-conditional-access-cloud-apps.md
index ef65daf9fe7..25490631d4f 100644
--- a/docs/identity/conditional-access/concept-conditional-access-cloud-apps.md
+++ b/docs/identity/conditional-access/concept-conditional-access-cloud-apps.md
@@ -29,7 +29,7 @@ Target resources (formerly Cloud apps, actions, and authentication context) are
Many of the existing Microsoft cloud applications are included in the list of applications you can select from.
-Administrators can assign a Conditional Access policy to the following cloud apps from Microsoft. Some apps like Office 365 and Microsoft Azure Management include multiple related child apps or services. We continually add more apps, so the following list isn't exhaustive and is subject to change.
+Administrators can assign a Conditional Access policy to the following cloud apps from Microsoft. Some apps like Office 365 and Windows Azure Service Management API include multiple related child apps or services. We continually add more apps, so the following list isn't exhaustive and is subject to change.
- [Office 365](#office-365)
- Azure Analysis Services
@@ -41,7 +41,7 @@ Administrators can assign a Conditional Access policy to the following cloud app
- Common Data Service
- Microsoft Application Insights Analytics
- [Microsoft Azure Information Protection](/azure/information-protection/faqs#i-see-azure-information-protection-is-listed-as-an-available-cloud-app-for-conditional-accesshow-does-this-work)
-- [Microsoft Azure Management](#microsoft-azure-management)
+- [Windows Azure Service Management API](#windows-azure-service-management-api)
- Microsoft Defender for Cloud Apps
- Microsoft Commerce Tools Access Control Portal
- Microsoft Commerce Tools Authentication Service
@@ -82,9 +82,9 @@ Administrators can exclude the entire Office 365 suite or specific Office 365 cl
A complete list of all services included can be found in the article [Apps included in Conditional Access Office 365 app suite](reference-office-365-application-contents.md).
-### Microsoft Azure Management
+### Windows Azure Service Management API
-When you target the Microsoft Azure Management application, policy is enforced for tokens issued to a set of services closely bound to the portal. This grouping includes the application IDs of:
+When you target the Windows Azure Service Management API application, policy is enforced for tokens issued to a set of services closely bound to the portal. This grouping includes the application IDs of:
- Azure Resource Manager
- Azure portal, which also covers the Microsoft Entra admin center
@@ -108,9 +108,9 @@ Because the policy is applied to the Azure management portal and API, services,
- Microsoft IoT Central
> [!NOTE]
-> The Microsoft Azure Management application applies to [Azure PowerShell](/powershell/azure/what-is-azure-powershell), which calls the [Azure Resource Manager API](/azure/azure-resource-manager/management/overview). It does not apply to [Microsoft Graph PowerShell](/powershell/microsoftgraph/overview), which calls the [Microsoft Graph API](/graph/overview).
+> The Windows Azure Service Management API application applies to [Azure PowerShell](/powershell/azure/what-is-azure-powershell), which calls the [Azure Resource Manager API](/azure/azure-resource-manager/management/overview). It does not apply to [Microsoft Graph PowerShell](/powershell/microsoftgraph/overview), which calls the [Microsoft Graph API](/graph/overview).
-For more information on how to set up a sample policy for Microsoft Azure Management, see [Conditional Access: Require MFA for Azure management](howto-conditional-access-policy-azure-management.md).
+For more information on how to set up a sample policy for Windows Azure Service Management API, see [Conditional Access: Require MFA for Azure management](howto-conditional-access-policy-azure-management.md).
> [!TIP]
> For Azure Government, you should target the Azure Government Cloud Management API application.
@@ -130,7 +130,7 @@ When a Conditional Access policy targets the Microsoft Admin Portals cloud app,
We're continually adding more administrative portals to the list.
> [!NOTE]
-> The Microsoft Admin Portals app applies to interactive sign-ins to the listed admin portals only. Sign-ins to the underlying resources or services like Microsoft Graph or Azure Resource Manager APIs are not covered by this application. Those resources are protected by the [Microsoft Azure Management](#microsoft-azure-management) app. This enables customers to move along the MFA adoption journey for admins without impacting automation that relies on APIs and PowerShell. When you are ready, Microsoft recommends using a [policy requiring administrators perform MFA always](howto-conditional-access-policy-admin-mfa.md) for comprehensive protection.
+> The Microsoft Admin Portals app applies to interactive sign-ins to the listed admin portals only. Sign-ins to the underlying resources or services like Microsoft Graph or Azure Resource Manager APIs are not covered by this application. Those resources are protected by the [Windows Azure Service Management API](#windows-azure-service-management-api) app. This enables customers to move along the MFA adoption journey for admins without impacting automation that relies on APIs and PowerShell. When you are ready, Microsoft recommends using a [policy requiring administrators perform MFA always](howto-conditional-access-policy-admin-mfa.md) for comprehensive protection.
### Other applications
diff --git a/docs/identity/conditional-access/howto-conditional-access-policy-all-users-mfa.md b/docs/identity/conditional-access/howto-conditional-access-policy-all-users-mfa.md
index e5db9c19a39..b6f9869aad2 100644
--- a/docs/identity/conditional-access/howto-conditional-access-policy-all-users-mfa.md
+++ b/docs/identity/conditional-access/howto-conditional-access-policy-all-users-mfa.md
@@ -32,7 +32,7 @@ Organizations may have many cloud applications in use. Not all of those applicat
### Subscription activation
-Organizations that use [Subscription Activation](/windows/deployment/windows-10-subscription-activation) to enable users to “step-up” from one version of Windows to another, may want to exclude the Universal Store Service APIs and Web Application, AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f from their all users all cloud apps MFA policy.
+Organizations that use [Subscription Activation](/windows/deployment/windows-10-subscription-activation) to enable users to “step-up” from one version of Windows to another, may want to exclude the Windows Store for Business, AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f from their all users all cloud apps MFA policy.
[!INCLUDE [active-directory-policy-deploy-template](~/includes/entra-policy-deploy-template.md)]
diff --git a/docs/identity/conditional-access/howto-conditional-access-policy-azure-management.md b/docs/identity/conditional-access/howto-conditional-access-policy-azure-management.md
index f6fa0942dd7..85c827d7f23 100644
--- a/docs/identity/conditional-access/howto-conditional-access-policy-azure-management.md
+++ b/docs/identity/conditional-access/howto-conditional-access-policy-azure-management.md
@@ -29,7 +29,7 @@ These tools can provide highly privileged access to resources that can make the
- Service settings
- Subscription billing
-To protect these privileged resources, Microsoft recommends requiring multifactor authentication for any user accessing these resources. In Microsoft Entra ID, these tools are grouped together in a suite called [Microsoft Azure Management](concept-conditional-access-cloud-apps.md#microsoft-azure-management). For Azure Government, this suite should be the Azure Government Cloud Management API app.
+To protect these privileged resources, Microsoft recommends requiring multifactor authentication for any user accessing these resources. In Microsoft Entra ID, these tools are grouped together in a suite called [Windows Azure Service Management API](concept-conditional-access-cloud-apps.md#windows-azure-service-management-api). For Azure Government, this suite should be the Azure Government Cloud Management API app.
## User exclusions
[!INCLUDE [active-directory-policy-exclusions](~/includes/entra-policy-exclude-user.md)]
@@ -38,10 +38,10 @@ To protect these privileged resources, Microsoft recommends requiring multifacto
## Create a Conditional Access policy
-The following steps will help create a Conditional Access policy to require users who access the [Microsoft Azure Management](concept-conditional-access-cloud-apps.md#microsoft-azure-management) suite do multifactor authentication.
+The following steps will help create a Conditional Access policy to require users who access the [Windows Azure Service Management API](concept-conditional-access-cloud-apps.md#windows-azure-service-management-api) suite do multifactor authentication.
> [!CAUTION]
-> Make sure you understand how Conditional Access works before setting up a policy to manage access to Microsoft Azure Management. Make sure you don't create conditions that could block your own access to the portal.
+> Make sure you understand how Conditional Access works before setting up a policy to manage access to Windows Azure Service Management API. Make sure you don't create conditions that could block your own access to the portal.
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Conditional Access Administrator](~/identity/role-based-access-control/permissions-reference.md#conditional-access-administrator).
1. Browse to **Protection** > **Conditional Access**.
@@ -50,7 +50,7 @@ The following steps will help create a Conditional Access policy to require user
1. Under **Assignments**, select **Users or workload identities**.
1. Under **Include**, select **All users**.
1. Under **Exclude**, select **Users and groups** and choose your organization's emergency access or break-glass accounts.
-1. Under **Target resources** > **Cloud apps** > **Include** > **Select apps**, choose **Microsoft Azure Management**, and select **Select**.
+1. Under **Target resources** > **Cloud apps** > **Include** > **Select apps**, choose **Windows Azure Service Management API**, and select **Select**.
1. Under **Access controls** > **Grant**, select **Grant access**, **Require multifactor authentication**, and select **Select**.
1. Confirm your settings and set **Enable policy** to **Report-only**.
1. Select **Create** to create to enable your policy.
diff --git a/docs/identity/conditional-access/howto-conditional-access-policy-compliant-device-admin.md b/docs/identity/conditional-access/howto-conditional-access-policy-compliant-device-admin.md
index 054606b0d2e..1022d297920 100644
--- a/docs/identity/conditional-access/howto-conditional-access-policy-compliant-device-admin.md
+++ b/docs/identity/conditional-access/howto-conditional-access-policy-compliant-device-admin.md
@@ -95,7 +95,7 @@ On Windows 7, iOS, Android, macOS, and some third-party web browsers, Microsoft
#### Subscription activation
-Organizations that use the [Subscription Activation](/windows/deployment/windows-10-subscription-activation) feature to enable users to “step-up” from one version of Windows to another, may want to exclude the Universal Store Service APIs and Web Application, AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f from their device compliance policy.
+Organizations that use the [Subscription Activation](/windows/deployment/windows-10-subscription-activation) feature to enable users to “step-up” from one version of Windows to another, may want to exclude the Windows Store for Business, AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f from their device compliance policy.
## Next steps
diff --git a/docs/identity/conditional-access/howto-conditional-access-policy-compliant-device.md b/docs/identity/conditional-access/howto-conditional-access-policy-compliant-device.md
index 1eb278124d9..f9c8825fe8a 100644
--- a/docs/identity/conditional-access/howto-conditional-access-policy-compliant-device.md
+++ b/docs/identity/conditional-access/howto-conditional-access-policy-compliant-device.md
@@ -64,7 +64,7 @@ On Windows 7, iOS, Android, macOS, and some third-party web browsers, Microsoft
#### Subscription activation
-Organizations that use the [Subscription Activation](/windows/deployment/windows-10-subscription-activation) feature to enable users to “step-up” from one version of Windows to another, may want to exclude the Universal Store Service APIs and Web Application, AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f from their Conditional Access policy.
+Organizations that use the [Subscription Activation](/windows/deployment/windows-10-subscription-activation) feature to enable users to “step-up” from one version of Windows to another, may want to exclude the Windows Store for Business, AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f from their Conditional Access policy.
## Next steps
diff --git a/docs/identity/conditional-access/location-condition.md b/docs/identity/conditional-access/location-condition.md
index 91289b40940..1e31c087e7a 100644
--- a/docs/identity/conditional-access/location-condition.md
+++ b/docs/identity/conditional-access/location-condition.md
@@ -151,7 +151,7 @@ When you configure the location condition, you can distinguish between:
- Any location
- All trusted locations
-- All Network Access locations
+- All Compliant Network locations
- Selected locations
### Any location
@@ -171,7 +171,7 @@ Using the trusted IPs section of multifactor authentication's service settings i
If you have these trusted IPs configured, they show up as **MFA Trusted IPs** in the list of locations for the location condition.
-### All Network Access locations of my tenant
+### All Compliant Network locations
Organizations with access to Global Secure Access preview features have another location listed that is made up of users and devices that comply with your organization's security policies. For more information, see the section [Enable Global Secure Access signaling for Conditional Access](/entra/global-secure-access/how-to-compliant-network#enable-global-secure-access-signaling-for-conditional-access). It can be used with Conditional Access policies to perform a compliant network check for access to resources.
diff --git a/docs/identity/conditional-access/require-tou.md b/docs/identity/conditional-access/require-tou.md
index 3a562e63d9f..f3341a6c7ea 100644
--- a/docs/identity/conditional-access/require-tou.md
+++ b/docs/identity/conditional-access/require-tou.md
@@ -76,7 +76,7 @@ The scenario in this quickstart uses:
1. Under Assignments, select **Cloud apps or actions**.
1. Select **Cloud apps or actions**.
1. Under Include, choose **Select apps**.
- 1. Select **Microsoft Azure Management**, and then choose **Select**.
+ 1. Select **Windows Azure Service Management API**, and then choose **Select**.
1. Under **Access controls**, select **Grant**.
1. Select **Grant access**.
1. Select the terms of use you created previously called **My TOU** and choose **Select**.
diff --git a/docs/identity/conditional-access/service-dependencies.md b/docs/identity/conditional-access/service-dependencies.md
index b2310109382..10f9b5f1e71 100644
--- a/docs/identity/conditional-access/service-dependencies.md
+++ b/docs/identity/conditional-access/service-dependencies.md
@@ -46,7 +46,7 @@ The below table lists some more service dependencies, where the client apps must
| Client apps | Downstream service | Enforcement |
| :-- | :-- | --- |
-| Azure Data Lake | Microsoft Azure Management (portal and API) | Early-bound |
+| Azure Data Lake | Windows Azure Service Management API (portal and API) | Early-bound |
| Microsoft Classroom | Exchange | Early-bound |
| | SharePoint | Early-bound |
| Microsoft Teams | Exchange | Early-bound |
@@ -59,14 +59,14 @@ The below table lists some more service dependencies, where the client apps must
| | SharePoint | Late-bound |
| Outlook groups | Exchange | Early-bound |
| | SharePoint | Early-bound |
-| Power Apps | Microsoft Azure Management (portal and API) | Early-bound |
+| Power Apps | Windows Azure Service Management API (portal and API) | Early-bound |
| | Windows Azure Active Directory | Early-bound |
| | SharePoint | Early-bound |
| | Exchange | Early-bound |
| Power Automate | Power Apps | Early-bound |
| Project | Dynamics CRM | Early-bound |
| Skype for Business | Exchange | Early-bound |
-| Visual Studio | Microsoft Azure Management (portal and API) | Early-bound |
+| Visual Studio | Windows Azure Service Management API (portal and API) | Early-bound |
| Microsoft Forms | Exchange | Early-bound |
| | SharePoint | Early-bound |
| Microsoft To-Do | Exchange | Early-bound |
diff --git a/docs/identity/devices/assign-local-admin.md b/docs/identity/devices/assign-local-admin.md
index 961f9f01698..e5387e7e57f 100644
--- a/docs/identity/devices/assign-local-admin.md
+++ b/docs/identity/devices/assign-local-admin.md
@@ -47,7 +47,7 @@ To view and update the membership of the [Global Administrator](~/identity/role-
You can manage the [Microsoft Entra Joined Device Local Administrator](~/identity/role-based-access-control/permissions-reference.md#microsoft-entra-joined-device-local-administrator) role from **Device settings**.
-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Cloud Device Administrator](~/identity/role-based-access-control/permissions-reference.md#cloud-device-administrator).
+1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Privileged Role Administrator](~/identity/role-based-access-control/permissions-reference.md#privileged-role-administrator).
1. Browse to **Identity** > **Devices** > **All devices** > **Device settings**.
1. Select **Manage Additional local administrators on all Microsoft Entra joined devices**.
1. Select **Add assignments** then choose the other administrators you want to add and select **Add**.
diff --git a/docs/identity/devices/howto-vm-sign-in-azure-ad-windows.md b/docs/identity/devices/howto-vm-sign-in-azure-ad-windows.md
index 5a227385028..d7808a3fa7d 100644
--- a/docs/identity/devices/howto-vm-sign-in-azure-ad-windows.md
+++ b/docs/identity/devices/howto-vm-sign-in-azure-ad-windows.md
@@ -301,10 +301,10 @@ You're now logged in to the Windows Server 2019 Azure virtual machine with the r
## Enforce Conditional Access policies
-You can enforce Conditional Access policies, such as "phishing resistant MFA" using require authentication strength (preview) grant control or multifactor authentication or user sign-in risk check, before you authorize access to Windows VMs in Azure that are enabled with Microsoft Entra login. To apply a Conditional Access policy, you must select the **Azure Windows VM Sign-In** app from the cloud apps or actions assignment option. Then use sign-in risk as a condition and/or "phishing resistant MFA" using require authentication strength (preview) grant control or require MFA as a control for granting access.
+You can enforce Conditional Access policies, such as "phishing resistant MFA" using require authentication strength (preview) grant control or multifactor authentication or user sign-in risk check, before you authorize access to Windows VMs in Azure that are enabled with Microsoft Entra login. To apply a Conditional Access policy, you must select the **Microsoft Azure Windows Virtual Machine Sign-In** app from the cloud apps or actions assignment option. Then use sign-in risk as a condition and/or "phishing resistant MFA" using require authentication strength (preview) grant control or require MFA as a control for granting access.
> [!NOTE]
-> If you require MFA as a control for granting access to the Azure Windows VM Sign-In app, then you must supply an MFA claim as part of the client that initiates the RDP session to the target Windows VM in Azure. This can be achieved using passwordless authentication method for RDP that satisfies the Conditional Access polices, however if you are using limited passwordless method for RDP then the only way to achieve this on a Windows 10 or later client is to use a Windows Hello for Business PIN or biometric authentication with the RDP client. Support for biometric authentication was added to the RDP client in Windows 10 version 1809. Remote desktop using Windows Hello for Business authentication is available only for deployments that use a certificate trust model. It's currently not available for a key trust model.
+> If you require MFA as a control for granting access to the Microsoft Azure Windows Virtual Machine Sign-In app, then you must supply an MFA claim as part of the client that initiates the RDP session to the target Windows VM in Azure. This can be achieved using passwordless authentication method for RDP that satisfies the Conditional Access polices, however if you are using limited passwordless method for RDP then the only way to achieve this on a Windows 10 or later client is to use a Windows Hello for Business PIN or biometric authentication with the RDP client. Support for biometric authentication was added to the RDP client in Windows 10 version 1809. Remote desktop using Windows Hello for Business authentication is available only for deployments that use a certificate trust model. It's currently not available for a key trust model.
## Use Azure Policy to meet standards and assess compliance
@@ -468,7 +468,7 @@ Set-MsolUser -UserPrincipalName username@contoso.com -StrongAuthenticationRequir
(Get-MsolUser -UserPrincipalName username@contoso.com).StrongAuthenticationRequirements
```
-If you haven't deployed Windows Hello for Business and if that isn't an option for now, you can configure a Conditional Access policy that excludes the Azure Windows VM Sign-In app from the list of cloud apps that require MFA. To learn more about Windows Hello for Business, see [Windows Hello for Business overview](/windows/security/identity-protection/hello-for-business/hello-identity-verification).
+If you haven't deployed Windows Hello for Business and if that isn't an option for now, you can configure a Conditional Access policy that excludes the Microsoft Azure Windows Virtual Machine Sign-In app from the list of cloud apps that require MFA. To learn more about Windows Hello for Business, see [Windows Hello for Business overview](/windows/security/identity-protection/hello-for-business/hello-identity-verification).
> [!NOTE]
> Windows Hello for Business PIN authentication with RDP has been supported for several versions of Windows 10. Support for biometric authentication with RDP was added in Windows 10 version 1809. Using Windows Hello for Business authentication during RDP is available for deployments that use a certificate trust model or key trust model.
@@ -477,11 +477,11 @@ Share your feedback about this feature or report problems with using it on the [
### Missing application
-If the Azure Windows VM Sign-In application is missing from Conditional Access, make sure that the application is in the tenant:
+If the Microsoft Azure Windows Virtual Machine Sign-In application is missing from Conditional Access, make sure that the application is in the tenant:
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Cloud Application Administrator](~/identity/role-based-access-control/permissions-reference.md#cloud-application-administrator).
1. Browse to **Identity** > **Applications** > **Enterprise applications**.
-1. Remove the filters to see all applications, and search for **VM**. If you don't see **Azure Windows VM Sign-In** as a result, the service principal is missing from the tenant.
+1. Remove the filters to see all applications, and search for **VM**. If you don't see **Microsoft Azure Windows Virtual Machine Sign-In** as a result, the service principal is missing from the tenant.
Another way to verify it is via Graph PowerShell:
@@ -489,11 +489,11 @@ Another way to verify it is via Graph PowerShell:
1. Run `Connect-MgGraph -Scopes "ServicePrincipalEndpoint.ReadWrite.All"`, followed by `"Application.ReadWrite.All"`.
1. Sign in with a Global Administrator account.
1. Consent to the permission prompt.
-1. Run `Get-MgServicePrincipal -ConsistencyLevel eventual -Search '"DisplayName:Azure Windows VM Sign-In"'`.
+1. Run `Get-MgServicePrincipal -ConsistencyLevel eventual -Search '"DisplayName:Microsoft Azure Windows Virtual Machine Sign-In"'`.
- If this command results in no output and returns you to the PowerShell prompt, you can create the service principal with the following Graph PowerShell command:
`New-MgServicePrincipal -AppId 372140e0-b3b7-4226-8ef9-d57986796201`
- - Successful output shows that the Azure Windows VM Sign-In app and its ID were created.
+ - Successful output shows that the Microsoft Azure Windows Virtual Machine Sign-In app and its ID were created.
1. Sign out of Graph PowerShell by using the `Disconnect-MgGraph` command.
## Next steps
diff --git a/docs/identity/hybrid/connect/concept-azure-ad-connect-sync-architecture.md b/docs/identity/hybrid/connect/concept-azure-ad-connect-sync-architecture.md
index 844479dc807..8e8ae1fa22b 100644
--- a/docs/identity/hybrid/connect/concept-azure-ad-connect-sync-architecture.md
+++ b/docs/identity/hybrid/connect/concept-azure-ad-connect-sync-architecture.md
@@ -19,7 +19,7 @@ ms.author: billmath
ms.collection: M365-identity-device-management
---
# Microsoft Entra Connect Sync: Understanding the architecture
-This topic covers the basic architecture for Microsoft Entra Connect Sync. In many aspects, it is similar to its predecessors MIIS 2003, ILM 2007, and FIM 2010. Microsoft Entra Connect Sync is the evolution of these technologies. If you are familiar with any of these earlier technologies, the content of this topic will be familiar to you as well. If you are new to synchronization, then this topic is for you. It is however not a requirement to know the details of this topic to be successful in making customizations to Microsoft Entra Connect Sync (called sync engine in this topic).
+This topic covers the basic architecture for Microsoft Entra Connect Sync. If you are familiar with earlier identity synchronization technologies, the content of this topic will be familiar to you as well. If you are new to synchronization, then this topic is for you. It is however not a requirement to know the details of this topic to be successful in making customizations to Microsoft Entra Connect Sync (called sync engine in this topic).
## Architecture
The sync engine creates an integrated view of objects that are stored in multiple connected data sources and manages identity information in those data sources. This integrated view is determined by the identity information retrieved from connected data sources and a set of rules that determine how to process this information.
diff --git a/docs/identity/hybrid/connect/how-to-connect-install-prerequisites.md b/docs/identity/hybrid/connect/how-to-connect-install-prerequisites.md
index 930eb79ddd7..53285ac538a 100644
--- a/docs/identity/hybrid/connect/how-to-connect-install-prerequisites.md
+++ b/docs/identity/hybrid/connect/how-to-connect-install-prerequisites.md
@@ -104,7 +104,7 @@ We recommend that you harden your Microsoft Entra Connect server to decrease the
* If you use a different installation of SQL Server, these requirements apply:
* Microsoft Entra Connect support all mainstream supported SQL Server versions up to SQL Server 2022 running on Windows. Please refer to the [SQL Server lifecycle article](/lifecycle/products/?products=sql-server) to verify the support status of your SQL Server version. SQL Server 2012 is no longer supported. Azure SQL Database *isn't supported* as a database. This includes both Azure SQL Database and Azure SQL Managed Instance.
* You must use a case-insensitive SQL collation. These collations are identified with a \_CI_ in their name. Using a case-sensitive collation identified by \_CS_ in their name *isn't supported*.
- * You can have only one sync engine per SQL instance. Sharing a SQL instance with FIM/MIM Sync, DirSync, or Azure AD Sync *isn't supported*.
+ * You can have only one sync engine per SQL instance. Sharing a SQL instance with MIM Sync, DirSync, or Azure AD Sync *isn't supported*.
### Accounts
* You must have a Microsoft Entra Global Administrator account or Hybrid Identity Administrator account for the Microsoft Entra tenant you want to integrate with. This account must be a *school or organization account* and can't be a *Microsoft account*.
diff --git a/docs/identity/hybrid/connect/how-to-connect-install-roadmap.md b/docs/identity/hybrid/connect/how-to-connect-install-roadmap.md
index 19ae949cbc7..560756deac4 100644
--- a/docs/identity/hybrid/connect/how-to-connect-install-roadmap.md
+++ b/docs/identity/hybrid/connect/how-to-connect-install-roadmap.md
@@ -90,7 +90,7 @@ The [prevent accidental deletes](how-to-connect-sync-feature-prevent-accidental-
## Customize Microsoft Entra Connect Sync
Microsoft Entra Connect Sync comes with a default configuration that is intended to work for most customers and topologies. But there are always situations where the default configuration does not work and must be adjusted. It is supported to make changes as documented in this section and linked topics.
-If you have not worked with a synchronization topology before you want to start to understand the basics and the terms used as described in the [technical concepts](how-to-connect-sync-technical-concepts.md). Microsoft Entra Connect is the evolution of MIIS2003, ILM2007, and FIM2010. Even if some things are identical, a lot has changed as well.
+If you have not worked with a synchronization topology before you want to start to understand the basics and the terms used as described in the [technical concepts](how-to-connect-sync-technical-concepts.md). Even if some things are similar, a lot has changed as well.
The [default configuration](concept-azure-ad-connect-sync-default-configuration.md) assumes there might be more than one forest in the configuration. In those topologies a user object might be represented as a contact in another forest. The user might also have a linked mailbox in another resource forest. The behavior of the default configuration is described in [users and contacts](concept-azure-ad-connect-sync-user-and-contacts.md).
diff --git a/docs/identity/hybrid/connect/how-to-connect-install-select-installation.md b/docs/identity/hybrid/connect/how-to-connect-install-select-installation.md
index fbd051a678f..bf3e9d427d0 100644
--- a/docs/identity/hybrid/connect/how-to-connect-install-select-installation.md
+++ b/docs/identity/hybrid/connect/how-to-connect-install-select-installation.md
@@ -66,8 +66,8 @@ If you are currently using Azure AD Sync, then you can follow the [same steps](h
- In-place upgrade to install Connect on the same server.
- Swing-migration to install Connect on a new server while the existing Azure AD Sync server is still operational.
-## Migrate from FIM2010 or MIM2016
-If you are currently using Forefront Identity Manager 2010 or Microsoft Identity Manager 2016 with the Microsoft Entra Connector, then your only option is a migration. Follow the steps described in [swing-migration](how-to-upgrade-previous-version.md#swing-migration). In the steps, replace any mention of Azure AD Sync with FIM2010/MIM2016.
+## Migrate from MIM
+If you are currently using Microsoft Identity Manager 2016 with the Microsoft Entra Connector, then your only option is a migration. Follow the steps described in [swing-migration](how-to-upgrade-previous-version.md#swing-migration). In the steps, replace any mention of Azure AD Sync with MIM 2016.
## Next steps
Depending on the option you have selected to use, use the table of content to the left to find your article with the detailed steps.
diff --git a/docs/identity/hybrid/connect/how-to-connect-sync-technical-concepts.md b/docs/identity/hybrid/connect/how-to-connect-sync-technical-concepts.md
index 266c5870e1c..338e00e5850 100644
--- a/docs/identity/hybrid/connect/how-to-connect-sync-technical-concepts.md
+++ b/docs/identity/hybrid/connect/how-to-connect-sync-technical-concepts.md
@@ -23,11 +23,11 @@ This article is a summary of the topic [Understanding architecture](how-to-conne
Microsoft Entra Connect Sync builds upon a solid metadirectory synchronization platform.
The following sections introduce the concepts for metadirectory synchronization.
-Building upon MIIS (Microsoft Identity Integration Server), ILM (Identity Lifecycle Manager), and FIM (Forefront Identity Manager), the Azure Active Directory Sync Services provides the next platform for connecting to data sources, synchronizing data between data sources, as well as the provisioning and deprovisioning of identities.
+The Azure Active Directory Sync Services provides a platform for connecting to data sources, synchronizing data between data sources, as well as the provisioning and deprovisioning of identities.
-The following sections provide more details about the following aspects of the FIM Synchronization Service:
+The following sections provide more details about the following aspects of the Synchronization Service:
* Connector
* Attribute flow
diff --git a/docs/identity/hybrid/connect/how-to-connect-sync-whatis.md b/docs/identity/hybrid/connect/how-to-connect-sync-whatis.md
index 5c24595ffcf..f31448f3c47 100644
--- a/docs/identity/hybrid/connect/how-to-connect-sync-whatis.md
+++ b/docs/identity/hybrid/connect/how-to-connect-sync-whatis.md
@@ -19,7 +19,7 @@ ms.author: billmath
ms.collection: M365-identity-device-management
---
# Microsoft Entra Connect Sync: Understand and customize synchronization
-The Microsoft Entra Connect synchronization services (Microsoft Entra Connect Sync) is a main component of Microsoft Entra Connect. It takes care of all the operations that are related to synchronize identity data between your on-premises environment and Microsoft Entra ID. Microsoft Entra Connect Sync is the successor of DirSync, Azure AD Sync, and Forefront Identity Manager with the Microsoft Entra Connector configured.
+The Microsoft Entra Connect synchronization services (Microsoft Entra Connect Sync) is a main component of Microsoft Entra Connect. It takes care of all the operations that are related to synchronize identity data between your on-premises environment and Microsoft Entra ID. Microsoft Entra Connect Sync is the successor of DirSync and Azure AD Sync.
This topic is the home for **Microsoft Entra Connect Sync** (also called **sync engine**) and lists links to all other topics related to it. For links to Microsoft Entra Connect, see [Integrating your on-premises identities with Microsoft Entra ID](../whatis-hybrid-identity.md).
diff --git a/docs/identity/hybrid/connect/how-to-upgrade-previous-version.md b/docs/identity/hybrid/connect/how-to-upgrade-previous-version.md
index 4a1a8975a9a..7198c535720 100644
--- a/docs/identity/hybrid/connect/how-to-upgrade-previous-version.md
+++ b/docs/identity/hybrid/connect/how-to-upgrade-previous-version.md
@@ -28,7 +28,7 @@ This topic describes the different methods that you can use to upgrade your Micr
> It's important that you keep your servers current with the latest releases of Microsoft Entra Connect. We are constantly making upgrades to Microsoft Entra Connect, and these upgrades include fixes to security issues and bugs, as well as serviceability, performance, and scalability improvements.
> To see what the latest version is, and to learn what changes have been made between versions, please refer to the [release version history](./reference-connect-version-history.md)
-Any versions older than Microsoft Entra Connect V2 are currently deprecated, see [Introduction to Microsoft Entra Connect V2](whatis-azure-ad-connect-v2.md) for more information. It's currently supported to upgrade from any version of Microsoft Entra Connect to the current version. In-place upgrades of DirSync or ADSync aren't supported, and a swing migration is required. If you want to upgrade from DirSync, see [Upgrade from Azure AD Sync tool (DirSync)](how-to-dirsync-upgrade-get-started.md) or the [Swing migration](#swing-migration) section.
+Any versions older than Microsoft Entra Connect V2 are currently deprecated. For more information, see [Introduction to Microsoft Entra Connect V2](whatis-azure-ad-connect-v2.md). It's currently supported to upgrade from any version of Microsoft Entra Connect to the current version. In-place upgrades of DirSync or ADSync aren't supported, and a swing migration is required. If you want to upgrade from DirSync, see [Upgrade from Azure AD Sync tool (DirSync)](how-to-dirsync-upgrade-get-started.md) or the [Swing migration](#swing-migration) section.
In practice, customers on old versions may encounter problems not directly related to Microsoft Entra Connect. Servers that have been in production for several years typically have had several patches applied to them and not all of these can be accounted for. Customers who haven't upgraded in 12-18 months (about 1 and a half years) should consider a swing upgrade instead as this is the most conservative and least risky option.
@@ -38,7 +38,7 @@ There are a few different strategies that you can use to upgrade Microsoft Entra
| --- | --- | --- | --- |
| [Automatic upgrade](how-to-connect-install-automatic-upgrade.md) |This is the easiest method for customers with an express installation |- No manual intervention |- Auto-upgrade version might not include the latest features |
| [In-place upgrade](#in-place-upgrade) |If you have a single server, you can upgrade the installation in-place on the same server |- Doesn't require another server
|- If there's an issue while in-place upgrading, you can't roll back the new release or configuration and change the active server when you are ready
|
-| [Swing migration](#swing-migration) |You can built a new updated server aside, before switching |- Safest approach and smoother transition to a newer version
- Supports Windows OS (Operating Systems) upgrade
- Sync is not interrupted and doesn't impose a risk to production |- Requires installation on a separate server
|
+| [Swing migration](#swing-migration) |You can build a new updated server aside, before switching |- Safest approach and smoother transition to a newer version
- Supports Windows OS (Operating Systems) upgrade
- Sync is not interrupted and doesn't impose a risk to production |- Requires installation on a separate server
|
For permissions information, see the [permissions required for an upgrade](reference-connect-accounts-permissions.md#upgrade).
@@ -47,7 +47,7 @@ For permissions information, see the [permissions required for an upgrade](refer
> After you've enabled your new Microsoft Entra Connect server to start synchronizing changes to Microsoft Entra ID, you must not roll back to using DirSync or Azure AD Sync. Downgrading from Microsoft Entra Connect to legacy clients, including DirSync and Azure AD Sync, is not supported and can lead to issues such as data loss in Microsoft Entra ID.
## In-place upgrade
-An in-place upgrade works for moving from Azure AD Sync or Microsoft Entra Connect. It doesn't work for moving from DirSync or for a solution with Forefront Identity Manager (FIM) + Microsoft Entra Connector.
+An in-place upgrade works for moving from Azure AD Sync or Microsoft Entra Connect. It doesn't work for moving from DirSync.
This method is preferred when you have a single server and less than about 100,000 objects. If there are any changes to the out-of-box sync rules, a full import and full synchronization will occur after the upgrade. This method ensures that the new configuration is applied to all existing objects in the system. This run might take a few hours, depending on the number of objects that are in scope of the sync engine. The normal delta synchronization scheduler (which synchronizes every 30 minutes by default) is suspended, but password synchronization continues. You might consider doing the in-place upgrade during the weekend. If there are no changes to the out-of-box configuration with the new Microsoft Entra Connect release, then a normal delta import/sync starts instead.
@@ -77,7 +77,7 @@ The two servers can use different versions. For example, the active server that
> [!NOTE]
> Some customers prefer to have three or four servers for this scenario. When the staging server is upgraded, you don't have a backup server for [disaster recovery](how-to-connect-sync-staging-server.md#disaster-recovery). With three or four servers, you can prepare one set of primary/standby servers with the updated version, which ensures that there's always a staging server that's ready to take over.
-These steps also work to move from Azure AD Sync or a solution with FIM + Microsoft Entra Connector. These steps don't work for DirSync, but the same swing migration method (also called parallel deployment) with steps for DirSync is in [Upgrade Azure Active Directory Sync (DirSync)](how-to-dirsync-upgrade-get-started.md).
+These steps also work to move from Azure AD Sync or a solution with MIM and the Microsoft Entra Connector. These steps don't work for DirSync, but the same swing migration method (also called parallel deployment) with steps for DirSync is in [Upgrade Azure Active Directory Sync (DirSync)](how-to-dirsync-upgrade-get-started.md).
### Use a swing migration to upgrade
1. If you only have one Microsoft Entra Connect server, if you are upgrading from AD Sync, or upgrading from an old version, it's a good idea to install the new version on a new Windows Server. If you already have two Microsoft Entra Connect servers, upgrade the staging server first. and promote the staging to active. It's recommended to always keep a pair of active/staging server running the same version, but it's not required.
diff --git a/docs/identity/hybrid/connect/plan-connect-topologies.md b/docs/identity/hybrid/connect/plan-connect-topologies.md
index 57c8efa1541..2bed07f81d0 100644
--- a/docs/identity/hybrid/connect/plan-connect-topologies.md
+++ b/docs/identity/hybrid/connect/plan-connect-topologies.md
@@ -28,7 +28,7 @@ Here's the legend for pictures in the article:
| On-premises Active Directory with filtered import | |
| Microsoft Entra Connect Sync server | |
| Microsoft Entra Connect Sync server “staging mode” | |
-| GALSync with Forefront Identity Manager (FIM) 2010 or Microsoft Identity Manager (MIM) 2016 | |
+| GALSync with Microsoft Identity Manager (MIM) 2016 | |
| Microsoft Entra Connect Sync server, detailed | |
| Microsoft Entra ID | |
| Unsupported scenario | |
@@ -105,7 +105,7 @@ Common to all these scenarios is that distribution and security groups can conta
A full mesh topology allows users and resources to be located in any forest. Commonly, there are two-way trusts between the forests.
-If Exchange is present in more than one forest, there might be (optionally) an on-premises GALSync solution. Every user is then represented as a contact in all other forests. GALSync is commonly implemented through FIM 2010 or MIM 2016. Microsoft Entra Connect cannot be used for on-premises GALSync.
+If Exchange is present in more than one forest, there might be (optionally) an on-premises GALSync solution. Every user is then represented as a contact in all other forests. GALSync is commonly implemented through Microsoft Identity Manager. Microsoft Entra Connect cannot be used for on-premises GALSync.
In this scenario, identity objects are joined via the mail attribute. A user who has a mailbox in one forest is joined with the contacts in the other forests.
@@ -154,7 +154,7 @@ We recommend having a single tenant in Microsoft Entra ID for an organization. B
This topology implements the following use cases:
-* AADConnect can synchronize the users, groups, and contacts from a single Active Directory to multiple Microsoft Entra tenants. These tenants can be in different Azure environments, such as the Microsoft Azure operated by 21Vianet environment or the Azure Government environment, but they could also be in the same Azure environment, such as two tenants that are both in Azure Commercial. For more details on options, see [Planning identity for Azure Government applications] (/azure/azure-government/documentation-government-plan-identity).
+* AADConnect can synchronize the users, groups, and contacts from a single Active Directory to multiple Microsoft Entra tenants. These tenants can be in different Azure environments, such as the Microsoft Azure operated by 21Vianet environment or the Azure Government environment, but they could also be in the same Azure environment, such as two tenants that are both in Azure Commercial. For more information on options, see [Planning identity for Azure Government applications](/azure/azure-government/documentation-government-plan-identity).
* The same Source Anchor can be used for a single object in separate tenants (but not for multiple objects in the same tenant). (The verified domain can't be the same in two tenants. More details are needed to enable the same object to have two UPNs.)
* You will need to deploy an AADConnect server for every Microsoft Entra tenant you want to synchronize to - one AADConnect server cannot synchronize to more than one Microsoft Entra tenant.
* It is supported to have different sync scopes and different sync rules for different tenants.
@@ -174,7 +174,7 @@ This topology implements the following use cases:
### GALSync with on-premises sync server
-You can use FIM 2010 or MIM 2016 on-premises to sync users (via GALSync) between two Exchange organizations. The users in one organization appear as foreign users/contacts in the other organization. These different on-premises Active Directory instances can then be synchronized with their own Microsoft Entra tenants.
+You can use Microsoft Identity Manager on-premises to sync users (via GALSync) between two Exchange organizations. The users in one organization appear as foreign users/contacts in the other organization. These different on-premises Active Directory instances can then be synchronized with their own Microsoft Entra tenants.
diff --git a/docs/identity/hybrid/connect/reference-connect-dirsync-deprecated.md b/docs/identity/hybrid/connect/reference-connect-dirsync-deprecated.md
index 9ab17d5f51f..2f7060a1109 100644
--- a/docs/identity/hybrid/connect/reference-connect-dirsync-deprecated.md
+++ b/docs/identity/hybrid/connect/reference-connect-dirsync-deprecated.md
@@ -60,8 +60,6 @@ DirSync/Azure AD Sync will continue to work on April 13, 2017. However, Microso
**Q: Which DirSync versions can I upgrade from?**
It's supported to upgrade from any DirSync release currently being used.
-**Q: What about the Microsoft Entra Connector for FIM/MIM?**
-The Microsoft Entra Connector for FIM/MIM has **not** been announced as deprecated. It's at **feature freeze**; no new functionality is added and it receives no bug fixes. Microsoft recommends customers using it to plan to move from it to Microsoft Entra Connect. It's strongly recommended to not start any new deployments using it. This Connector will be announced deprecated in the future.
## Additional Resources
* [Integrating your on-premises identities with Microsoft Entra ID](../whatis-hybrid-identity.md)