Merge pull request #232814 from MicrosoftDocs/main

3/30 AM Publish

Author: huypub

articles/active-directory-b2c/user-profile-attributes.md

@@ -21,7 +21,7 @@ Your Azure Active Directory B2C (Azure AD B2C) directory user profile comes with
 Most of the attributes that can be used with Azure AD B2C user profiles are also supported by Microsoft Graph. This article describes supported Azure AD B2C user profile attributes. It also notes those attributes that are not supported by Microsoft Graph, as well as Microsoft Graph attributes that should not be used with Azure AD B2C.
 
 > [!IMPORTANT]
-> You should'nt use built-in or extension attributes to store sensitive personal data, such as account credentials, government identification numbers, cardholder data, financial account data, healthcare information, or sensitive background information.
+> You shouldn't use built-in or extension attributes to store sensitive personal data, such as account credentials, government identification numbers, cardholder data, financial account data, healthcare information, or sensitive background information.
 
 You can also integrate with external systems. For example, you can use Azure AD B2C for authentication, but delegate to an external customer relationship management (CRM) or customer loyalty database as the authoritative source of customer data. For more information, see the [remote profile](https://github.com/azure-ad-b2c/samples/tree/master/policies/remote-profile) solution.
 

articles/active-directory/authentication/how-to-mfa-server-migration-utility.md

@@ -6,7 +6,7 @@ services: multi-factor-authentication
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: how-to
-ms.date: 01/29/2023
+ms.date: 03/27/2023
 
 ms.author: justinha
 author: justinha
@@ -192,15 +192,15 @@ Migrating user data doesn't remove or alter any data in the Multi-Factor Authent
 
 The MFA Server Migration utility targets a single Azure AD 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 Azure AD group you want to migrate. Once complete, press Tab or click outside the window and the utility will begin searching for the appropriate group. The window will populate all users in the group. A large group can take several minutes to finish.
+To begin the migration process, enter the name or GUID of the Azure AD 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.
 
 To view attribute data for a user, highlight the user, and select **View**:
 
 :::image type="content" border="true" source="./media/how-to-mfa-server-migration-utility/view-user.png" alt-text="Screenshot of how to view use settings.":::
 
-This window displays the attributes for the selected user in both Azure AD and the on-premises MFA Server. You can use this window to view how data was written to a user after they’ve been migrated.
+This window displays the attributes for the selected user in both Azure AD and the on-premises MFA Server. You can use this window to view how data was written to a user after migration.
 
-The settings option allows you to change the settings for the migration process:
+The **Settings** option allows you to change the settings for the migration process:
 
 :::image type="content" border="true" source="./media/how-to-mfa-server-migration-utility/settings.png" alt-text="Screenshot of settings.":::
 
@@ -209,17 +209,21 @@ The settings option allows you to change the settings for the migration process:
   - The migration utility tries direct matching to UPN before using the on-premises Active Directory attribute.  
   - If no match is found, it calls a Windows API to find the Azure AD UPN and get the SID, which it uses to search the MFA Server user list. 
   - If the Windows API doesn’t find the user or the SID isn’t found in the MFA Server, then it will use the configured Active Directory attribute to find the user in the on-premises Active Directory, and then use the SID 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 Azure AD at the specified time interval defined
+- 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 Azure AD at the specified time interval defined.
+- Synchronization server – Allows the MFA Server Migration Sync service to run on a secondary MFA Server rather than only run on the primary. To configure the Migration Sync service to run on a secondary server, the `Configure-MultiFactorAuthMigrationUtility.ps1` script must be run on the server to register a certificate with the MFA Server Migration Utility app registration. The certificate is used to authenticate to Microsoft Graph. 
 
-The migration process can be an automatic process, or a manual process.
+The migration process can be automatic or manual.
 
 The manual process steps are:
 
 1. To begin the migration process for a user or selection of multiple users, press and hold the Ctrl key while selecting each of the user(s) you wish to migrate. 
 1. After you select the desired users, click **Migrate Users** > **Selected users** > **OK**.
 1. To migrate all users in the group, click **Migrate Users** > **All users in AAD group** > **OK**.
+1. You can migrate users even if they are unchanged. By default, the utility is set to **Only migrate users that have changed**. Click **Migrate all users** to re-migrate previously migrated users that are unchanged. Migrating unchanged users can be useful during testing if an administrator needs to reset a user’s Azure MFA settings and wants to re-migrate them.
 
-For the automatic process, click **Automatic synchronization** in the settings dialog, and then select whether you want all users to be synced, or only members of a given Azure AD group.
+   :::image type="content" border="true" source="./media/how-to-mfa-server-migration-utility/migrate-users.png" alt-text="Screenshot of Migrate users dialog.":::
+
+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 Azure AD group.
 
 The following table lists the sync logic for the various methods.
 

articles/active-directory/authentication/media/how-to-mfa-server-migration-utility/migrate-users.png

@@ -122,6 +122,8 @@
       href: troubleshoot-conditional-access-what-if.md
     - name: Troubleshoot continuous access evaluation
       href: howto-continuous-access-evaluation-troubleshoot.md
+  - name: Approved client app migration
+    href: migrate-approved-client-app.md
   - name: Custom controls
     href: controls.md
   - name: Classic policies

articles/active-directory/authentication/media/how-to-mfa-server-migration-utility/settings.png

@@ -94,4 +94,4 @@ After confirming your settings using [report-only mode](howto-conditional-access
 
 [Conditional Access common policies](concept-conditional-access-policy-common.md)
 
-[Simulate sign in behavior using the Conditional Access What If tool](troubleshoot-conditional-access-what-if.md)
+[Migrate approved client app to application protection policy in Conditional Access](migrate-approved-client-app.md)

articles/active-directory/conditional-access/TOC.yml

@@ -0,0 +1,85 @@
+---
+title: Migrate approved client app to application protection policy in Conditional Access 
+description: The approved client app control is going away. Migrate to App protection policies.
+
+services: active-directory
+ms.service: active-directory
+ms.subservice: conditional-access
+ms.topic: how-to
+ms.date: 03/28/2023
+
+ms.author: joflore
+author: MicrosoftGuyJFlo
+manager: amycolannino
+ms.reviewer: jogro
+
+ms.collection: M365-identity-device-management
+---
+# Migrate approved client app to application protection policy in Conditional Access
+
+In this article, you learn how to migrate from the approved client app Conditional Access grant to the application protection policy grant. App protection policies provide the same data loss and protection as approved client app policies, but with other benefits. For more information about the benefits of using app protection policies, see the article [App protection policies overview](/mem/intune/apps/app-protection-policy). 
+
+The approved client app grant is retiring in early March 2026. Organizations must transition all current Conditional Access policies that use only the Require Approved Client App grant to Require Approved Client App or Application Protection Policy by March 2026. Additionally, for any new Conditional Access policy, only apply the Require application protection policy grant. 
+
+After March 2026, Microsoft will stop enforcing require approved client app control, and it will be as if this grant isn't selected. Use the following steps before March 2026 to protect your organization’s data. 
+
+## Edit an existing Conditional Access policy
+
+Require approved client apps or app protection policy with mobile devices 
+
+The following steps make an existing Conditional Access policy require an approved client app or an app protection policy when using an iOS/iPadOS or Android device. This policy works in tandem with an app protection policy created in Microsoft Intune. 
+
+Organizations can choose to update their policies using the following steps.
+
+1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.
+1. Browse to **Azure Active Directory** > **Security** > **Conditional Access**.
+1. Select a policy that uses the approved client app grant.
+1. Under **Access controls** > **Grant**, select **Grant access**.
+   1. Select **Require approved client app** and **Require app protection policy**
+   1. **For multiple controls** select **Require one of the selected controls**
+1. Confirm your settings and set **Enable policy** to **Report-only**.
+1. Select **Create** to create to enable your policy.
+
+After confirming your settings using [report-only mode](howto-conditional-access-insights-reporting.md), an administrator can move the **Enable policy** toggle from **Report-only** to **On**.
+
+Repeat the previous steps on all of your policies that use the approved client app grant. 
+
+> [!WARNING] 
+> Not all applications that are supported as approved applications or support application protection policies. For a list of some common client apps, see [App protection policy requirement](concept-conditional-access-grant.md#require-app-protection-policy). If your application is not listed there, contact the application developer. 
+
+## Create a Conditional Access policy
+
+Require app protection policy with mobile devices 
+
+The following steps help create a Conditional Access policy requiring an approved client app or an app protection policy when using an iOS/iPadOS or Android device. This policy works in tandem with an [app protection policy created in Microsoft Intune](/mem/intune/apps/app-protection-policies). 
+
+Organizations can choose to deploy this policy using the following steps.
+
+1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.
+1. Browse to **Azure Active Directory** > **Security** > **Conditional Access**.
+1. Select **New policy**.
+1. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.
+1. Under **Assignments**, select **Users or workload identities**.
+   1. Under **Include**, select **All users**.
+   1. Under **Exclude**, select **Users and groups** and exclude at least one account to prevent yourself from being locked out. If you don't exclude any accounts, you can't create the policy.
+1. Under **Cloud apps or actions**, select **All cloud apps**.
+1. Under **Conditions** > **Device platforms**, set **Configure** to **Yes**.
+   1. Under **Include**, **Select device platforms**.
+   1. Choose **Android** and **iOS**
+   1. Select **Done**.
+1. Under **Access controls** > **Grant**, select **Grant access**.
+   1. Select **Require approved client app** and **Require app protection policy**
+   1. **For multiple controls** select **Require one of the selected controls**
+1. Confirm your settings and set **Enable policy** to **Report-only**.
+1. Select **Create** to create to enable your policy.
+
+After confirming your settings using [report-only mode](howto-conditional-access-insights-reporting.md), an administrator can move the **Enable policy** toggle from **Report-only** to **On**.
+
+> [!NOTE] 
+> If an app does not support **Require app protection policy**, end users trying to access resources from that app will be blocked.
+
+## Next steps
+
+For more information on application protection policies, see: 
+
+[App protection policies overview](/mem/intune/apps/app-protection-policy)

articles/active-directory/conditional-access/howto-policy-approved-app-or-app-protection.md

@@ -6,7 +6,7 @@ author: OwenRichards1
 manager: CelesteDG
 ms.service: active-directory
 ms.subservice: develop
-ms.topic: portal
+ms.topic: conceptual
 ms.date: 08/22/2022
 ROBOTS: NOINDEX
 ms.author: owenrichards

articles/active-directory/conditional-access/migrate-approved-client-app.md

@@ -6,7 +6,7 @@ author: OwenRichards1
 manager: CelesteDG
 ms.service: active-directory
 ms.subservice: develop
-ms.topic: portal
+ms.topic: conceptual
 ms.workload: identity
 ms.date: 08/22/2022
 ROBOTS: NOINDEX

articles/active-directory/develop/console-quickstart-portal-nodejs.md

@@ -6,7 +6,7 @@ author: OwenRichards1
 manager: CelesteDG
 ms.service: active-directory
 ms.subservice: develop
-ms.topic: portal
+ms.topic: conceptual
 ms.workload: identity
 ms.date: 08/22/2022
 ROBOTS: NOINDEX