Merge pull request #226698 from MicrosoftDocs/main

2/08 AM Publish

Author: huypub

.openpublishing.publish.config.json

@@ -994,6 +994,7 @@
   "articles/object-anchors/.openpublishing.redirection.object-anchors.json",
   "articles/postgresql/.openpublishing.redirection.postgresql.json",
   "articles/purview/.openpublishing.redirection.purview.json",
+  "articles/sap/.openpublishing.redirection.sap.json",
   "articles/service-bus-messaging/.openpublishing.redirection.service-bus-messaging.json",
   "articles/spatial-anchors/.openpublishing.redirection.spatial-anchors.json",
   "articles/spring-apps/.openpublishing.redirection.spring-apps.json",

articles/active-directory-b2c/add-identity-provider.md

@@ -6,7 +6,7 @@ author: garrodonnell
 manager: CelesteDG
 
 ms.author: godonnell
-ms.date: 01/19/2022
+ms.date: 02/08/2023
 ms.custom: mvc
 ms.topic: how-to
 ms.service: active-directory
@@ -19,7 +19,7 @@ You can configure Azure AD B2C to allow users to sign in to your application wit
 
 With external identity provider federation, you can offer your consumers the ability to sign in with their existing social or enterprise accounts, without having to create a new account just for your application.
 
-On the sign-up or sign-in page, Azure AD B2C presents a list of external identity providers the user can choose for sign-in. Once they select one of the external identity providers, they're taken (redirected) to the selected provider's website to complete the sign-in process. After the user successfully signs in, they're returned to Azure AD B2C for authentication of the account in your application.
+On the sign-up or sign-in page, Azure AD B2C presents a list of external identity providers the user can choose for sign-in. Once a user selects an external identity provider, they're redirected to the selected provider's website to complete their sign-in. After they successfully sign in, they're returned to Azure AD B2C for authentication with your application.
 
 ![Diagram showing mobile sign-in example with a social account (Facebook).](media/add-identity-provider/external-idp.png)
 

articles/active-directory-b2c/identity-provider-azure-ad-single-tenant.md

@@ -9,7 +9,7 @@ manager: CelesteDG
 ms.service: active-directory
 ms.workload: identity
 ms.topic: how-to
-ms.date: 10/11/2022
+ms.date: 02/07/2023
 ms.author: godonnell
 ms.subservice: B2C
 ms.custom: fasttrack-edit, project-no-code
@@ -67,26 +67,6 @@ To enable sign-in for users with an Azure AD account from a specific Azure AD or
 1. Select **Certificates & secrets**, and then select **New client secret**.
 1. Enter a **Description** for the secret, select an expiration, and then select **Add**. Record the **Value** of the secret for use in a later step.
 
-### Configuring optional claims
-
-If you want to get the `family_name` and `given_name` claims from Azure AD, you can configure optional claims for your application in the Azure portal UI or application manifest. For more information, see [How to provide optional claims to your Azure AD app](../active-directory/develop/active-directory-optional-claims.md).
-
-1. Sign in to the [Azure portal](https://portal.azure.com) using your organizational Azure AD tenant. Or if you're already signed in, make sure you're using the directory that contains your organizational Azure AD tenant (for example, Contoso):
-    1. Select the **Directories + subscriptions** icon in the portal toolbar.
-    2. On the **Portal settings | Directories + subscriptions** page, find your Azure AD directory in the **Directory name** list, and then select **Switch**. 
-1. In the Azure portal, search for and select **Azure Active Directory**.
-1. In the left menu, under **Manage**, select **App registrations**.
-1. Select the application you want to configure optional claims for in the list, such as `Azure AD B2C App`. 
-1. From the **Manage** section, select **Token configuration**.
-1. Select **Add optional claim**.
-1. For the **Token type**, select **ID**.
-1. Select the optional claims to add, `family_name` and `given_name`.
-1. Select **Add**. If **Turn on the Microsoft Graph profile permission (required for claims to appear in token)** appears, enable it, and then select **Add** again.
-
-## [Optional] Verify your app authenticity
-
-[Publisher verification](../active-directory/develop/publisher-verification-overview.md) helps your users understand the authenticity of the app you [registered](#register-an-azure-ad-app). A verified app means that the publisher of the app has [verified](/partner-center/verification-responses) their identity using their Microsoft Partner Network (MPN). Learn how to [mark your app as publisher verified](../active-directory/develop/mark-app-as-publisher-verified.md). 
-
 ::: zone pivot="b2c-user-flow"
 
 ## Configure Azure AD as an identity provider
@@ -254,6 +234,26 @@ If the sign-in process is successful, your browser is redirected to `https://jwt
 
 ::: zone-end
 
+### [Optional] Configuring optional claims
+
+If you want to get the `family_name` and `given_name` claims from Azure AD, you can configure optional claims for your application in the Azure portal UI or application manifest. For more information, see [How to provide optional claims to your Azure AD app](../active-directory/develop/active-directory-optional-claims.md).
+
+1. Sign in to the [Azure portal](https://portal.azure.com) using your organizational Azure AD tenant. Or if you're already signed in, make sure you're using the directory that contains your organizational Azure AD tenant (for example, Contoso):
+    1. Select the **Directories + subscriptions** icon in the portal toolbar.
+    2. On the **Portal settings | Directories + subscriptions** page, find your Azure AD directory in the **Directory name** list, and then select **Switch**. 
+1. In the Azure portal, search for and select **Azure Active Directory**.
+1. In the left menu, under **Manage**, select **App registrations**.
+1. Select the application you want to configure optional claims for in the list, such as `Azure AD B2C App`. 
+1. From the **Manage** section, select **Token configuration**.
+1. Select **Add optional claim**.
+1. For the **Token type**, select **ID**.
+1. Select the optional claims to add, `family_name` and `given_name`.
+1. Select **Add**. If **Turn on the Microsoft Graph profile permission (required for claims to appear in token)** appears, enable it, and then select **Add** again.
+
+## [Optional] Verify your app authenticity
+
+[Publisher verification](../active-directory/develop/publisher-verification-overview.md) helps your users understand the authenticity of the app you [registered](#register-an-azure-ad-app). A verified app means that the publisher of the app has [verified](/partner-center/verification-responses) their identity using their Microsoft Partner Network (MPN). Learn how to [mark your app as publisher verified](../active-directory/develop/mark-app-as-publisher-verified.md). 
+
 ## Next steps
 
 Learn how to [pass the Azure AD token to your application](idp-pass-through-user-flow.md).

articles/active-directory-b2c/identity-provider-generic-saml.md

@@ -139,10 +139,10 @@ The **OutputClaims** element contains a list of claims returned by the SAML iden
 
 In the example above, *Contoso-SAML2* includes the claims returned by a SAML identity provider:
 
-* The **issuerUserId** claim is mapped to the **assertionSubjectName** claim.
+* The **assertionSubjectName** claim is mapped to the **issuerUserId** claim.
 * The **first_name** claim is mapped to the **givenName** claim.
 * The **last_name** claim is mapped to the **surname** claim.
-* The **displayName** claim is mapped to the `http://schemas.microsoft.com/identity/claims/displayname` claim.
+* The `http://schemas.microsoft.com/identity/claims/displayname` claim is mapped to the **displayName** claim.
 * The **email** claim without name mapping.
 
 The technical profile also returns claims that aren't returned by the identity provider:
@@ -237,4 +237,4 @@ If the sign-in process is successful, your browser is redirected to `https://jwt
 
 - [Configure SAML identity provider options with Azure Active Directory B2C](identity-provider-generic-saml-options.md)
 
-::: zone-end
+::: zone-end

articles/active-directory-b2c/sign-in-options.md

@@ -9,7 +9,7 @@ manager: CelesteDG
 ms.service: active-directory
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 01/18/2022
+ms.date: 02/08/2023
 ms.author: godonnell
 ms.subservice: B2C
 

articles/active-directory/conditional-access/concept-continuous-access-evaluation.md

@@ -179,7 +179,7 @@ When Conditional Access policy or group membership changes need to be applied to
 Modern networks often optimize connectivity and network paths for applications differently. This optimization frequently causes variations of the routing and source IP addresses of connections, as seen by your identity provider and resource providers. You may observe this split path or IP address variation in multiple network topologies, including, but not limited to: 
 
 - On-premises and cloud-based proxies.
-- Virtual private network (VPN) implementations, like split tunneling.
+- Virtual private network (VPN) implementations, like [split tunneling](/microsoft-365/enterprise/microsoft-365-vpn-implement-split-tunnel).
 - Software defined wide area network (SD-WAN) deployments.
 - Load balanced or redundant network egress network topologies, like those using [SNAT](https://wikipedia.org/wiki/Network_address_translation#SNAT). 
 - Branch office deployments that allow direct internet connectivity for specific applications.
@@ -189,9 +189,10 @@ Modern networks often optimize connectivity and network paths for applications d
 In addition to IP variations, customers also may employ network solutions and services that: 
 
 - Use IP addresses that may be shared with other customers. For example, cloud-based proxy services where egress IP addresses are shared between customers.
-- Use easily varied or undefinable IP addresses. For example, topologies where there are large, dynamic sets of egress IP addresses used, like large enterprise scenarios or split VPN and local egress network traffic.
+- Use easily varied or undefinable IP addresses. For example, topologies where there are large, dynamic sets of egress IP addresses used, like large enterprise scenarios or [split VPN](/microsoft-365/enterprise/microsoft-365-vpn-implement-split-tunnel) and local egress network traffic.
+
+Networks where egress IP addresses may change frequently or are shared may affect Azure AD Conditional Access and Continues Access Evaluation (CAE). This variability can affect how these features work and their recommended configurations. Split Tunneling may also cause unexpected blocks when an environment is configured using [Split Tunneling VPN Best Practices](/microsoft-365/enterprise/microsoft-365-vpn-implement-split-tunnel). Routing [Optimized IPs](/microsoft-365/enterprise/microsoft-365-vpn-implement-split-tunnel#optimize-ip-address-ranges) through a Trusted IP/VPN may be required to prevent blocks related to "insufficient_claims" or "Instant IP Enforcement check failed".
 
-Networks where egress IP addresses may change frequently or are shared may affect Azure AD Conditional Access and Continues Access Evaluation (CAE). This variability can affect how these features work, and their recommended configurations.
 
 The following table summarizes Conditional Access and CAE feature behaviors and recommendations for different types of network deployments: 
 

articles/active-directory/develop/active-directory-optional-claims.md

@@ -234,7 +234,7 @@ Within the SAML tokens, these claims will be emitted with the following URI form
 
 ## Configuring groups optional claims
 
-This section covers the configuration options under optional claims for changing the group attributes used in group claims from the default group objectID to attributes synced from on-premises Windows Active Directory. You can configure groups optional claims for your application through the UI or application manifest.
+This section covers the configuration options under optional claims for changing the group attributes used in group claims from the default group objectID to attributes synced from on-premises Windows Active Directory. You can configure groups optional claims for your application through the UI or application manifest. Group optional claims are only emitted in the JWT for **user principals**. **Service principals** _will not_ have group optional claims emitted in the JWT.
 
 > [!IMPORTANT]
 > Azure AD limits the number of groups emitted in a token to 150 for SAML assertions and 200 for JWT, including nested groups.  For more information on group limits and important caveats for group claims from on-premises attributes, see [Configure group claims for applications with Azure AD](../hybrid/how-to-connect-fed-group-claims.md).

articles/active-directory/develop/msal-shared-devices.md

@@ -9,15 +9,15 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 02/06/2023
+ms.date: 02/08/2023
 ms.author: henrymbugua
 ms.reviewer: brandwe
 ms.custom: aaddev
 ---
 
 # Overview of shared device mode
 
-Shared device mode is a feature of Azure Active Directory(Azure AD) that allows you to build and deploy applications that support frontline workers and educational scenarios that require shared Android and iOS devices.
+Shared device mode is a feature of Azure Active Directory (Azure AD) that allows you to build and deploy applications that support frontline workers and educational scenarios that require shared Android and iOS devices.
 
 > [!IMPORTANT]
 > Shared device mode for iOS [!INCLUDE [PREVIEW BOILERPLATE](../../../includes/active-directory-develop-preview.md)]
@@ -36,7 +36,7 @@ Azure AD enables these scenarios with a feature called **shared device mode**.
 
 As mentioned, shared device mode is a feature of Azure AD that enables you to:
 
-- Build applications that support frontline workers
+- Build applications that support frontline workers.
 - Deploy devices to frontline workers with apps that support shared device mode.
 
 ### Build applications that support frontline workers