Merge pull request #224713 from MicrosoftDocs/main

1/23 AM Publish

Author: huypub

.openpublishing.redirection.active-directory.json

@@ -11055,6 +11055,16 @@
       "source_path_from_root": "/articles/active-directory/develop/microsoft-graph-intro.md",
       "redirect_url": "/graph/overview?toc=/azure/active-directory/develop/toc.json&bc=/azure/active-directory/develop/breadcrumb/toc.json",
       "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/articles/active-directory/privileged-identity-management/concept-privileged-access-versus-role-assignable.md",
+      "redirect_url": "azure/active-directory/privileged-identity-management/concept-pim-for-groups",
+      "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/articles/active-directory/privileged-identity-management/groups-features.md",
+      "redirect_url": "azure/active-directory/privileged-identity-management/concept-pim-for-groups",
+      "redirect_document_id": false
     }
   ]
 }

.openpublishing.redirection.azure-monitor.json

@@ -3787,14 +3787,19 @@
             "redirect_url": "/azure/azure-monitor/alerts/alerts-classic-portal",
             "redirect_document_id": false
         },
+        {
+            "source_path_from_root": "/articles/azure-monitor/platform/alerts-common-schema-definitions.md",
+            "redirect_url": "/azure/azure-monitor/alerts/alerts-common-schema",
+            "redirect_document_id": false
+        },
         {
             "source_path_from_root": "/articles/azure-monitor/platform/alerts-common-schema.md",
             "redirect_url": "/azure/azure-monitor/alerts/alerts-common-schema",
             "redirect_document_id": false
         },
         {
-            "source_path_from_root": "/articles/azure-monitor/platform/alerts-common-schema-definitions.md",
-            "redirect_url": "/azure/azure-monitor/alerts/alerts-common-schema-definitions",
+            "source_path_from_root": "/articles/azure-monitor/alerts/alerts-common-schema-definitions.md",
+            "redirect_url": "/azure/azure-monitor/alerts/alerts-common-schema",
             "redirect_document_id": false
         },
         {
@@ -5661,6 +5666,11 @@
             "source_path_from_root": "/articles/azure-monitor/vm/monitor-virtual-machine-workloads.md",
             "redirect_url": "/azure/azure-monitor/vm/monitor-virtual-machine-data-collection",
             "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/azure-monitor/logs/azure-data-explorer-monitor-cross-service-query.md",
+            "redirect_url": "/azure/azure-monitor/logs/azure-monitor-data-explorer-proxy",
+            "redirect_document_id": false
         }
     ]
 }

articles/active-directory-b2c/media/partner-datawiza/pass-user-attributes-new.png

@@ -10,7 +10,7 @@ ms.workload: identity
 ms.topic: overview
 ms.date: 10/26/2022
 ms.custom: engagement-fy23
-ms.author: kengaderdus
+ms.author: godonnell
 ms.subservice: B2C
 ---
 

articles/active-directory-b2c/overview.md

@@ -16,7 +16,7 @@ ms.subservice: B2C
 
 # Tutorial: Configure Azure Active Directory B2C with Datawiza to provide secure hybrid access
 
-In this tutorial, learn how to integrate Azure Active Directory B2C (Azure AD B2C) with [Datawiza Access Broker (DAB)](https://www.datawiza.com/access-broker). DAB enables single sign-on (SSO) and granular access control, helping Azure AD B2C protect on-premises legacy applications. With this solution, enterprises can transition from legacy to Azure AD B2C without rewriting applications.
+In this tutorial, learn how to integrate Azure Active Directory B2C (Azure AD B2C) with [Datawiza Access Proxy (DAP)](https://www.datawiza.com/), which enables single sign-on (SSO) and granular access control, helping Azure AD B2C protect on-premises legacy applications. With this solution, enterprises can transition from legacy to Azure AD B2C without rewriting applications.
 
 ## Prerequisites
 
@@ -29,7 +29,7 @@ To get started, you'll need:
   - Your applications can run on platforms such as virtual machine and bare metal
 - An on-premises application to transition from a legacy identity system, to Azure AD B2C
   - In this tutorial, DAB is deployed on the same server as the application
-  - The application runs on localhost: 3001 and DAB proxies traffic to applications via localhost: 9772
+  - The application runs on localhost: 3001 and DAP proxies traffic to applications via localhost: 9772
   - The application traffic reaches DAB first and then is proxied to the application
 
 ## Scenario description
@@ -38,17 +38,17 @@ Datawiza integration includes the following components:
 
 - **Azure AD B2C**: The authorization server to verify user credentials
   - Authenticated users access on-premises applications using a local account stored in the Azure AD B2C directory
-- **Datawiza Access Broker (DAB)**: The service that passes identity to applications through HTTP headers
+- **Datawiza Access Proxy (DAP)**: The service that passes identity to applications through HTTP headers
 - **Datawiza Cloud Management Console (DCMC)**: A management console for DAB. DCMC UI and RESTful APIs help manage DAB configurations and access control policies
 
 The following architecture diagram shows the implementation.
 
    ![Diagram of the architecture of an Azure AD B2C integration with Datawiza for secure access to hybrid applications.](./media/partner-datawiza/datawiza-architecture-diagram.png)
 
 1. The user requests access to an on-premises application. DAB proxies the request to the application.
-2. DAB checks user authentication state. With no session token, or an invalid token, the user goes to Azure AD B2C for authentication.
-3. Azure AD B2C sends the user request to the endpoint specified during DAB registration in the Azure AD B2C tenant.
-4. The DAB evaluates access policies and calculates attribute values in HTTP headers forwarded to the application. The DAB might call to the identity provider (IdP) to retrieve information to set the header values. The DAB sets the header values and sends the request to the application.
+2. DAP checks user authentication state. With no session token, or an invalid token, the user goes to Azure AD B2C for authentication.
+3. Azure AD B2C sends the user request to the endpoint specified during DAP registration in the Azure AD B2C tenant.
+4. The DAP evaluates access policies and calculates attribute values in HTTP headers forwarded to the application. The DAP might call to the identity provider (IdP) to retrieve information to set the header values. The DAP sets the header values and sends the request to the application.
 5. The user is authenticated with access to the application.
 
 ## Onboard with Datawiza
@@ -74,11 +74,11 @@ Go to docs.datawiza.com to:
 
 ## Run DAB with a header-based application
 
-You can use Docker or Kubernetes to run DAB. Use the Docker image for users to create a sample header-based application. 
+You can use Docker or Kubernetes to run DAP. Use the Docker image for users to create a sample header-based application. 
 
-Learn more: To configure DAB and SSO integration, see [Deploy Datawiza Access Proxy With Your App](https://docs.datawiza.com/step-by-step/step3.html) 
+Learn more: To configure DAP and SSO integration, see [Deploy Datawiza Access Proxy With Your App](https://docs.datawiza.com/step-by-step/step3.html) 
 
-A sample docker image `docker-compose.yml file` is provided. Sign in to the container registry to download DAB images and the header-based application. 
+A sample docker image `docker-compose.yml file` is provided. Sign in to the container registry to download DAP images and the header-based application. 
 
 1. [Deploy Datawiza Access Proxy With Your App](https://docs.datawiza.com/step-by-step/step3.html#important-step).
 
@@ -114,17 +114,17 @@ A sample docker image `docker-compose.yml file` is provided. Sign in to the cont
 
 DAB gets user attributes from IdP and passes them to the application with header or cookie. After you configure user attributes, the green check sign appears for user attributes.
 
-   ![Screenshot of passed user attributes.](./media/partner-datawiza/pass-user-attributes.png)
+   ![Screenshot of passed user attributes.](./media/partner-datawiza/pass-user-attributes-new.png)
 
 Learn more: [Pass User Attributes](https://docs.datawiza.com/step-by-step/step4.html) such as email address, firstname, and lastname to the header-based application. 
 
 ## Test the flow
 
 1. Navigate to the on-premises application URL.
-2. The DAB redirects to the page you configured in your user flow.
+2. The DAP redirects to the page you configured in your user flow.
 3. From the list, select the IdP.
 4. At the prompt, enter your credentials. If necessary, include an Azure AD Multi-Factor Authentication (MFA) token.
-5. You're redirected to Azure AD B2C, which forwards the application request to the DAB redirect URI.
+5. You're redirected to Azure AD B2C, which forwards the application request to the DAP redirect URI.
 6. The DAB evaluates policies, calculates headers, and sends the user to the upstream application. 
 7. The requested application appears.
 

articles/active-directory-b2c/partner-datawiza.md

@@ -9,7 +9,7 @@ ms.reviewer: kengaderdus
 ms.service: active-directory
 ms.workload: identity
 ms.topic: how-to
-ms.date: 12/9/2022
+ms.date: 01/20/2023
 ms.author: gasinh
 ms.subservice: B2C
 ---
@@ -22,7 +22,7 @@ Many e-commerce sites and web applications exposed to the internet are deployed
 
 Generally, configurations include an authentication translation layer that externalizes the authentication from the web application. Reverse proxies provide the authenticated user context to the web applications, such as a header value in clear or digest form. The applications aren't using industry standard tokens such as Security Assertion Markup Language (SAML), OAuth, or Open ID Connect (OIDC). Instead, the proxy provides authentication context and maintains the session with the end-user agent such as browser or native application. As a service running as a man-in-the-middle, proxies provide significant session control. The proxy service is efficient and scalable, not a bottleneck for applications behind the proxy service. The diagram is a reverse-proxy implementation and communications flow.
 
-   ![Reverse proxy implementation](./media/partner-ping/reverse-proxy.png)
+   ![Diagram of the reverse proxy implementation.](./media/partner-ping/reverse-proxy.png)
 
 ## Modernization
 
@@ -45,7 +45,7 @@ Proxies support the modern authentication protocols and use the redirect-based (
 In Azure AD B2C, you define policies that drive user experiences and behaviors, also called user journeys. Each such policy exposes a protocol endpoint that can perform the authentication as an IdP. On the application side, there's no special handling required for certain policies. An application makes a standard authentication request to the protocol-specific authentication endpoint exposed by a policy.  
 You can configure Azure AD B2C to share the same issuer across policies or unique issuer for each policy. Each application can point to policies by making a protocol-native authentication request, which drives user behaviors such as sign-in, sign-up, and profile edits. The diagram shows OIDC and SAML application workflows.
 
-  ![O I D C and S A M L implementation](./media/partner-ping/azure-ad-identity-provider.png)
+  ![Diagram of the OIDC and SAML application workflows.](./media/partner-ping/azure-ad-identity-provider.png)
 
 The scenario can be challenging for the legacy applications to redirect the user accurately. The access request to the applications might not include the user experience context. In most cases, the proxy layer, or an integrated agent on the web application, intercepts the access request.
 
@@ -55,27 +55,27 @@ You can deploy PingAccess as the reverse proxy. PingAccess intercepts a direct r
 
 Configure PingAccess with OIDC, OAuth2, or SAML for authentication with an upstream authentication provider. You can configure an upstream IdP for this purpose on the PingAccess server. See the following diagram.
 
-   ![PingAccess with O I D C implementation](./media/partner-ping/authorization-flow.png)
+   ![Diagram of an upstream IDP on a PingAccess server.](./media/partner-ping/authorization-flow.png)
 
 In a typical Azure AD B2C deployment with policies exposing IdPs, there's a challenge. PingAccess is configured with one, upstream IdP.  
 
 ### PingFederate federation proxy
 
-You can configure PingFederate as an authentication provider, or a proxy. for upstream IdPs. See the following diagram.
+You can configure PingFederate as an authentication provider, or a proxy, for upstream IdPs. See the following diagram.
 
-   ![PingFederate implementation](./media/partner-ping/pingfederate.png)
+   ![Diagram of PingFederate configured an authentication provider, or a proxy, for upstream IDPs.](./media/partner-ping/pingfederate.png)
 
 Use this function to contextually, dynamically, or declaratively switch an inbound request to an Azure AD B2C policy. See the following diagram of protocol sequence flow.
 
-   ![image shows the PingAccess and PingFederate workflow](./media/partner-ping/pingaccess-pingfederate-workflow.png)
+   ![Diagram of the protocol sequence flow for PingAccess, PingFederate, Azure AD B2C, and the applicaiton.](./media/partner-ping/pingaccess-pingfederate-workflow.png)
 
 ## Prerequisites
 
 To get started, you'll need:
 
 - An Azure subscription
   - If you don't have one, get an [Azure free account](https://azure.microsoft.com/free/)
-- An [Azure AD B2C tenant](/tutorial-create-tenant.md) linked to your Azure subscription
+- An [Azure AD B2C tenant](tutorial-create-tenant.md) linked to your Azure subscription
 - PingAccess and PingFederate deployed in Docker containers or on Azure virtual machines (VMs)
 
 ## Connectivity and communication
@@ -93,15 +93,15 @@ Confirm the following connectivity and communication.
 
 You can use basic user flows or advanced Identity Enterprise Framework (IEF) policies. PingAccess generates the metadata endpoint, based on the issuer value, by using the [WebFinger](https://tools.ietf.org/html/rfc7033) protocol for discovery convention. To follow this convention, update the Azure AD B2C issuer using user-flow policy properties.
 
-   ![image shows the token settings](./media/partner-ping/token-setting.png)
+   ![Screenshot of the subject sub claim URL on the Token compatibility dialog.](./media/partner-ping/token-setting.png)
 
 In the advanced policies, configuration includes the IssuanceClaimPattern metadata element to AuthorityWithTfp value in the [JWT token issuer technical profile](./jwt-issuer-technical-profile.md).
 
 ## Configure PingAccess and PingFederate
 
 Use the instructions in the following sections to configure PingAccess and PingFederate. See the following diagram of the overall integration user flow.
 
-   ![PingAccess and PingFederate integration](./media/partner-ping/pingaccess.png)
+   ![Diagram of the PingAccess and PingFederate integration user flow](./media/partner-ping/pingaccess.png)
 
 ### Configure PingFederate as the token provider
 
@@ -116,7 +116,7 @@ Use the following instructions to create a PingAccess application for the target
 #### Create a virtual host
 
 >[!IMPORTANT]
->Create a virtual host for every application. For more information, see [What can I configure with PingAccess?]([https://docs.pingidentity.com/bundle/pingaccess-43/page/reference/pa_c_KeyConsiderations.html](https://docs.pingidentity.com/bundle/pingaccess-71/page/kkj1564006722708.html).
+>Create a virtual host for every application. For more information, see [What can I configure with PingAccess?]([https://docs.pingidentity.com/bundle/pingaccess-43/page/reference/pa_c_KeyConsiderations.html].
 
 To create a virtual host:
 

articles/active-directory-b2c/partner-ping-identity.md

@@ -3,14 +3,14 @@ title: "Quickstart: Set up sign in for a desktop app using Azure Active Director
 titleSuffix: Azure AD B2C
 description: In this Quickstart, run a sample WPF desktop application that uses Azure Active Directory B2C to provide account sign in.
 services: active-directory-b2c
-author: kengaderdus
+author: garrodonnell
 manager: CelesteDG
 ms.service: active-directory
 ms.workload: identity
 ms.topic: quickstart
 ms.custom: mvc, mode-other
 ms.date: 01/13/2022
-ms.author: kengaderdus
+ms.author: godonnell
 ms.subservice: B2C
 ---
 

articles/active-directory-b2c/quickstart-native-app-desktop.md

@@ -3,13 +3,13 @@ title: "Quickstart: Set up sign in for a single-page app (SPA)"
 titleSuffix: Azure AD B2C
 description: In this Quickstart, run a sample single-page application that uses Azure Active Directory B2C to provide account sign-in.
 services: active-directory-b2c
-author: kengaderdus
+author: garrodonnell
 manager: CelesteDG
 ms.service: active-directory
 ms.workload: identity
 ms.topic: quickstart
 ms.date: 01/13/2022
-ms.author: kengaderdus
+ms.author: godonnell
 ms.subservice: B2C
 ms.custom: mode-other
 ---

articles/active-directory-b2c/quickstart-single-page-app.md

@@ -148,6 +148,7 @@ The following client apps are confirmed to support this setting, this list isn't
 - Microsoft Cortana
 - Microsoft Edge
 - Microsoft Excel
+- Microsoft Flow Mobile
 - Microsoft Launcher
 - Microsoft Lists
 - Microsoft Office

articles/active-directory/conditional-access/concept-conditional-access-grant.md

@@ -8,10 +8,8 @@
   items:
   - name: License requirements
     href: subscription-requirements.md
-  - name: Privileged Access groups
-    href: groups-features.md
-  - name: Role-assignable vs Privileged Access groups
-    href: concept-privileged-access-versus-role-assignable.md
+  - name: PIM for Groups
+    href: concept-pim-for-groups.md
   - name: Roles you can't manage with PIM 
     href: pim-roles.md
   - name: Secure privileged access in Azure AD
@@ -32,51 +30,51 @@
     href: pim-deployment-plan.md
   - name: Start using PIM
     href: pim-getting-started.md
+  - name: Bring under management
+    items:
+    - name: Azure resources
+      href: pim-resource-roles-discover-resources.md
+    - name: Groups
+      href: groups-discover-groups.md
   - name: Assign
     items:
     - name: Azure AD roles
       href: pim-how-to-add-role-to-user.md
     - name: Azure roles
       href: pim-resource-roles-assign-roles.md
-    - name: Privileged Access groups
+    - name: Groups
       href: groups-assign-member-owner.md
   - name: Activate
     items:
     - name: Azure AD roles
       href: pim-how-to-activate-role.md
     - name: Azure roles
       href: pim-resource-roles-activate-your-roles.md
-    - name: Privileged Access groups
+    - name: Groups
       href: groups-activate-roles.md 
   - name: Approve
     items:
     - name: Azure AD roles
       href: azure-ad-pim-approval-workflow.md
     - name: Azure roles
       href: pim-resource-roles-approval-workflow.md
-    - name: Privileged Access groups
+    - name: Groups
       href: groups-approval-workflow.md
-  - name: Bring under management
-    items:
-    - name: Azure resources
-      href: pim-resource-roles-discover-resources.md
-    - name: Privileged Access groups
-      href: groups-discover-groups.md
   - name: Extend or renew
     items:
     - name: Azure AD roles
       href: pim-how-to-renew-extend.md
     - name: Azure roles
       href: pim-resource-roles-renew-extend.md
-    - name: Privileged Access groups
+    - name: Groups
       href: groups-renew-extend.md
   - name: Set role settings
     items:
     - name: Azure AD roles
       href: pim-how-to-change-default-settings.md
     - name: Azure roles
       href: pim-resource-roles-configure-role-settings.md
-    - name: Privileged Access groups
+    - name: Groups
       href: groups-role-settings.md
   - name: Set up alerts
     items:
@@ -90,7 +88,7 @@
       href: pim-how-to-use-audit-log.md
     - name: Azure roles
       href: azure-pim-resource-rbac.md
-    - name: Privileged Access groups
+    - name: Groups
       href: groups-audit.md
   - name: Review access
     items: