Merge branch 'MicrosoftDocs:main' into Mar-10-2023-SelectiveDisk

Author: AbhishekMallick01

.openpublishing.redirection.json

@@ -1,5 +1,10 @@
 {
     "redirections": [
+    {
+      "source_path": "articles/databox-online/azure-stack-edge-zero-touch-provisioning.md",
+      "redirect_url": "/azure/databox-online/azure-stack-edge-powershell-based-configuration",
+      "redirect_document_id": false
+    },
     {
       "source_path": "articles/azure-video-analyzer/video-analyzer-docs/access-policies.md",
       "redirect_url": "/previous-versions/azure/azure-video-analyzer/video-analyzer-docs/access-policies",

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

@@ -4,82 +4,78 @@ titleSuffix: Azure AD B2C
 description: Tutorial to configure Azure Active Directory B2C with BioCatch to identify risky and fraudulent users
 services: active-directory-b2c
 author: gargi-sinha
-manager: CelesteDG
+manager: martinco
 ms.reviewer: kengaderdus
-
 ms.service: active-directory
 ms.workload: identity
 ms.topic: how-to
-ms.date: 09/20/2021
+ms.date: 03/13/2023
 ms.author: gasinh
 ms.subservice: B2C
 ---
 
 # Tutorial: Configure BioCatch with Azure Active Directory B2C
 
-In this sample tutorial, learn how to integrate Azure Active Directory (AD) B2C authentication with [BioCatch](https://www.biocatch.com/) to further augment your Customer Identity and Access Management (CIAM) security posture. BioCatch analyzes a user's physical and cognitive digital behaviors to generate insights that distinguish between legitimate customers and cyber-criminals.
-
-## Prerequisites
+Learn how to integrate Azure Active Directory B2C (Azure AD B2C) authentication with BioCatch technology to augment your Customer Identity and Access Management (CIAM) security posture. BioCatch products analyze user physical and cognitive digital behaviors for insights that help distinguish legitimate customers.
 
-To get started, you'll need:
+Go to biocatch.com to learn more [BioCatch](https://www.biocatch.com/)
 
-- An Azure subscription. If you don't have a subscription, you can get a [free account](https://azure.microsoft.com/free/).
+## Prerequisites
 
-- [An Azure AD B2C tenant](tutorial-create-tenant.md) that is linked to your Azure subscription.
+To get started, you need:
 
-- A [BioCatch](https://www.biocatch.com/contact-us) account.
+* An Azure subscription
+  * If you don't have one, get an [Azure free account](https://azure.microsoft.com/free/)
+* An Azure AD B2C tenant linked to the Azure subscription
+  * See, [Tutorial: Create an Azure Active Directory B2C tenant](tutorial-create-tenant.md)
+* Go to the biocatch.com [Contact Us](https://www.biocatch.com/contact-us) page to request an account
+  * Mention Azure AD B2C integration
 
 ## Scenario description
 
 BioCatch integration includes the following components:
 
-- **A web app or web service** - The user first browses to this web service. This web service instantiates a unique client session ID that is sent to BioCatch. The client session ID then immediately begins transmitting user behavior characteristics to BioCatch.
-
-- **A method** - Sends the unique client session ID to Azure AD B2C. In the provided example, JavaScript is used to input the value into a hidden HTML field.
-
-- **An Azure AD B2C customized UI** - Hides an HTML field for the client session ID input from JavaScript, if using the above method
-
-- **Azure AD B2C custom policy**
+* **A web app or web service** - users browse to this web service that instantiates a unique client session ID that goes to BioCatch 
+  * The session ID transmits user behavior characteristics to BioCatch
+* **A method** - sends the session ID to Azure AD B2C. In the example, JavaScript inputs the value into a hidden HTML field.
+* **An Azure AD B2C customized UI** - hides an HTML field for the session ID input from JavaScript
+* **Azure AD B2C custom policy**:
+  * Takes the session ID as a claim via a self-asserted technical profile
+  * Integrates with BioCatch via a REST API claims provider and passes the session ID to BioCatch
+  * Multiple custom claims return from BioCatch for the custom policy logic 
+  * A user journey evaluates a returned claim, and executes a conditional action, such as multi-factor authentication
 
-  - Takes the custom client session ID from the UI in the form of a claim. This is achieved via a self-asserted technical profile
+Learn more: 
 
-  - Integrates with BioCatch via a REST API claims provider and passes the client session ID to the BioCatch platform
+* [Azure AD B2C custom policy overview](custom-policy-overview.md)
+* [Tutorial: Create user flows and custom policies in Azure AD B2C](./tutorial-create-user-flows.md?pivots=b2c-custom-policy&tabs=applications)
 
-  - Multiple custom claims are returned from BioCatch for the custom policy logic to then act upon
+The following diagram illustrates user flows with session information. 
 
-  - A userjourney, which evaluates a returned claim, for example, session risk, and conditionally executes an action, such as invoke Multi-factor authentication (MFA).
+   ![Diagram of user flows with session information.](media/partner-biocatch/biocatch-architecture-diagram.png)
 
-![Diagram of the bio catch architecture.](media/partner-biocatch/biocatch-architecture-diagram.png)
+1. The user browses to the web service, which returns HTML, CSS, or JavaScript values, then loads the BioCatch JavaScript SDK. Client-side JavaScript configures a client session ID for the BioCatch SDK. Alternately, the web service pre-configures client session ID and sends it to the client. You can configure the instantiated BioCatch JavaScript SDK for BioCatch, which sends user behavior to BioCatch from the client device, using the client session ID.
+2. User signs-up or signs-in and is redirected to Azure AD B2C. 
+3. The user journey includes a self-asserted claims provider, which inputs the client session ID. This field is hidden. Use JavaScript to input the session ID into the field. Select **Next**, to continue sign-up or sign-in. The session ID goes to BioCatch for a risk score. BioCatch returns session information, and recommends allow or block. The user journey has a conditional check, which acts upon the returned claims.
+4. Based on the conditional check result, an action is invoked.
+5. The web service can use the session ID to query BioCatch API to determine risk and session information.
 
-| Step  | Description |
-|:---|:-----------------------|
-|1a     | The user browses the web service. The web service then returns HTML, CSS, or JavaScript values and configures to load the BioCatch JavaScript SDK. Client-side JavaScript configures/sets client session ID for the BioCatch SDK. Alternately, the web service can pre-configure client session ID and send to the client.        |
-|1b    |  Configure the instantiated BioCatch JavaScript SDK against the BioCatch platform. Immediately begin to send user behavior characteristics to BioCatch from the client device, using the client session ID from step 1a.    |
-|2     |  User tries to sign-up/sign-in and is redirected to Azure AD B2C.      |
-|3a    | Part of the userjourney is a self-asserted claimsprovider, which takes the client session ID as input. This field is hidden on the screen. You can use JavaScript to input the session ID into the field. Select the *next* button, to continue the sign-up/sign-in process.|
-|3b     | The client session ID is submitted to the BioCatch platform to determine a risk score. |
-|3c     | BioCatch returns information about the session, such as risk score, and a recommendation on what to do – allow or block |
-|3d    |The userjourney has a conditional check step, which acts upon the returned claims|
-| 4   | Based on the conditional check result, an action such as *step-up MFA* is invoked|
-|5    | At any time from when the user first hits the web service page, the web service can use the client session ID to query the BioCatch API to determine risk score and session information in real-time. |
+## Get started with BioCatch
 
-## Onboard with BioCatch
-
-Contact [BioCatch](https://www.biocatch.com/contact-us) and create an account.
+Go to the biocatch.com [Contact Us](https://www.biocatch.com/contact-us) page to initiate an account.
 
 ## Configure the custom UI
 
-It's recommended to hide the client session ID field. Use CSS, JavaScript, or any other method to hide the field. For testing purposes, you may unhide the field. For example, JavaScript is used to hide the input field as:
+We recommended you hide the Client Session ID field with CSS, JavaScript, or another method. For testing, unhide the field. For example, JavaScript hides the input field as:
 
 ```JavaScript
 document.getElementById("clientSessionId").style.display = 'none';
 ```
 
-## Configure  Azure AD B2C Identity Experience Framework policies
-
-1. Configure the initial [custom policy configuration](./tutorial-create-user-flows.md?pivots=b2c-custom-policy).
+## Configure Azure AD B2C Identity Experience Framework policies
 
-2. Create a new file, which inherits from the extensions file.
+1. To get started, See [Tutorial: Create user flows and custom policies in Azure AD B2C](./tutorial-create-user-flows.md?pivots=b2c-custom-policy).
+2. Create a new file that inherits from the extensions file.
 
     ```xml
     <BasePolicy> 
@@ -107,7 +103,7 @@ document.getElementById("clientSessionId").style.display = 'none';
         </ContentDefinitions>
     ```
 
-4. Add the following claims under the BuildingBlocks resource.
+4. Under the BuildingBlocks resource, add the following claims.
 
     ```xml
     <ClaimsSchema> 
@@ -141,7 +137,7 @@ document.getElementById("clientSessionId").style.display = 'none';
     </ClaimsSchema> 
     ```
 
-5. Configure self-asserted claims provider for the client session ID field.
+5. Configure a self-asserted claims provider for the client session ID field.
 
     ```xml
     <ClaimsProvider> 
@@ -185,7 +181,7 @@ document.getElementById("clientSessionId").style.display = 'none';
         </ClaimsProvider> 
     ```
 
-6. Configure REST API claims provider for BioCatch. 
+6. Configure a REST API claims provider for BioCatch. 
 
     ```xml
     <TechnicalProfile Id="BioCatch-API-GETSCORE"> 
@@ -234,15 +230,13 @@ document.getElementById("clientSessionId").style.display = 'none';
     ```
 
     > [!NOTE]
-    > BioCatch will provide you the URL, customer ID and unique user ID (UUID) to configure. The customer SessionID claim is passed through as a query string parameter to BioCatch. You can choose the activity type, for example *MAKE_PAYMENT*.
-
-7. Configure the userjourney; follow the example
-
-   1. Get the clientSessionID as a claim
+    > BioCatch provides the URL, customer ID, and unique user ID (UUID). The customer SessionID claim passes through as a query string parameter to BioCatch. You can select the activity type, for example **MAKE_PAYMENT**.
 
-   1. Call the BioCatch API to get the session information
+7. Configure the user journey using the following example:
 
-   1. If the returned claim *risk* equals *low*, skip the step for MFA, else force user MFA
+   * Get the clientSessionID as a claim.
+   * Call BioCatch API to get the session information.
+   * If the returned claim risk is **low**, skip the step for MFA, otherwise enforce user MFA.
 
     ```xml
     <OrchestrationStep Order="8" Type="ClaimsExchange"> 
@@ -288,9 +282,7 @@ document.getElementById("clientSessionId").style.display = 'none';
           </ClaimsExchanges>
     ```
 
-8. Configure on relying party configuration (optional)
-
-    It is useful to pass the BioCatch returned information to your application as claims in the token, specifically *risklevel* and *score*.
+8. Configure relying party (optional). You can pass the BioCatch returned information to your application as claims in the token: risklevel and score.
 
     ```xml
     <RelyingParty> 
@@ -346,21 +338,28 @@ document.getElementById("clientSessionId").style.display = 'none';
 
 ## Integrate with Azure AD B2C
 
-Follow these steps to add the policy files to Azure AD B2C
+Add the policy files to Azure AD B2C. For the following instructions, use the directory with the Azure AD B2C tenant. 
 
-1. Sign in to the [**Azure portal**](https://portal.azure.com/) as the global administrator of your Azure AD B2C tenant.
-1. Make sure you're using the directory that contains your Azure AD B2C tenant. Select the **Directories + subscriptions** icon in the portal toolbar.
-1. On the **Portal settings | Directories + subscriptions** page, find your Azure AD B2C directory in the **Directory name** list, and then select **Switch**.
-1. Choose **All services** in the top-left corner of the Azure portal, search for and select Azure AD B2C.
-1. Navigate to **Azure AD B2C** > **Identity Experience Framework**
-1. Upload all the policy files to your tenant.
+1. Sign in to the [**Azure portal**](https://portal.azure.com/) as the Global Administrator of the Azure AD B2C tenant.
+1. In the portal toolbar, select **Directories + subscriptions**.
+1. On the **Portal settings, Directories + subscriptions** page, in the **Directory name** list, locate the Azure AD B2C directory.
+2. Select **Switch**.
+3. In the top-left corner of the Azure portal, select **All services**.
+4. Search for and select **Azure AD B2C**.
+5. Navigate to **Azure AD B2C** > **Identity Experience Framework**.
+6. Upload the policy files to the tenant.
 
 ## Test the solution
 
-1. [Register a dummy application, which redirects to JWT.MS](./tutorial-register-applications.md?tabs=app-reg-ga)  
-1. Under the **Identity Experience Framework**, select the policy you created
-1. In the policy window, select the dummy JWT.MS application, and select **run now**
-1. Go through sign-up flow and create an account. Token returned to JWT.MS should have 2x claims for riskLevel and score. Follow the example.  
+For the following instructions, see [Tutorial: Register a web application in Azure Active Directory B2C](./tutorial-register-applications.md?tabs=app-reg-ga)
+
+1. Register a dummy application that redirects to JWT.MS. 
+2. Under **Identity Experience Framework**, select the policy you created.
+3. In the policy window, select the dummy JWT.MS application
+4. Select **run now**.
+5. Perform a sign-up flow and create an account. 
+6. The token returned to JWT.MS has 2x claims for riskLevel and score. 
+7. Use the following example.  
 
     ```JavaScript
     { 
@@ -413,6 +412,5 @@ Follow these steps to add the policy files to Azure AD B2C
 
 ## Additional resources
 
-- [Custom policies in Azure AD B2C](./custom-policy-overview.md)
-
-- [Get started with custom policies in Azure AD B2C](./tutorial-create-user-flows.md?pivots=b2c-custom-policy&tabs=applications)
+* [Azure AD B2C custom policy overview](./custom-policy-overview.md)
+* [Tutorial: Create user flows and custom policies in Azure AD B2C](./tutorial-create-user-flows.md?pivots=b2c-custom-policy&tabs=applications)

articles/active-directory-domain-services/migrate-from-classic-vnet.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: how-to
-ms.date: 03/10/2023
+ms.date: 03/14/2023
 ms.author: justinha 
 ---
 
@@ -177,10 +177,11 @@ Before you begin the migration process, complete the following initial checks an
     | Source      | Source service tag                 | Source port ranges |  Destination  | Service | Destination port ranges | Protocol | Action | Required | Purpose |
     |:-----------:|:----------------------------------:|:------------------:|:-------------:|:-------:|:-----------------------:|:--------:|:------:|:--------:|:--------|
     | Service tag | AzureActiveDirectoryDomainServices | *                  | Any           | WinRM   | 5986        | TCP       | Allow  | Yes       | Management of your domain |
-    | Service tag | CorpNetSaw                         | *                  | Any           | WinRM   | 3389        | TCP       | Allow  | Optional  | Debugging for support |
-    | Service tag | AzureActiveDirectoryDomainServices | *                  | Any           | WinRM   | 636         | TCP       | Allow  | Optional  | Secure LDAP |
+    | Service tag | CorpNetSaw                         | *                  | Any           | RDP   | 3389        | TCP       | Allow  | Optional  | Debugging for support |
+    
+    Make a note of the target resource group, target virtual network, and target virtual network subnet. These resource names are used during the migration process.
 
-    Make a note of this target resource group, target virtual network, and target virtual network subnet. These resource names are used during the migration process.
+    Note that the **CorpNetSaw** service tag isn't available by using Azure portal, and the network security group rule for **CorpNetSaw** has to be added by using [PowerShell](powershell-create-instance.md#create-a-network-security-group).
 
 1. Check the managed domain health in the Azure portal. If you have any alerts for the managed domain, resolve them before you start the migration process.
 1. Optionally, if you plan to move other resources to the Resource Manager deployment model and virtual network, confirm that those resources can be migrated. For more information, see [Platform-supported migration of IaaS resources from Classic to Resource Manager][migrate-iaas].

articles/active-directory-domain-services/network-considerations.md

@@ -9,8 +9,9 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 01/29/2023
+ms.date: 03/14/2023
 ms.author: justinha
+ms.reviewer: xyuan
 
 ---
 # Virtual network design considerations and configuration options for Azure Active Directory Domain Services
@@ -110,10 +111,13 @@ The following sections cover network security groups and Inbound and Outbound po
 
 The following network security group Inbound rules are required for the managed domain to provide authentication and management services. Don't edit or delete these network security group rules for the virtual network subnet for your managed domain.
 
-| Inbound port number | Protocol | Source                             | Destination | Action | Required | Purpose |
-|:-----------:|:--------:|:----------------------------------:|:-----------:|:------:|:--------:|:--------|
-| 5986        | TCP      | AzureActiveDirectoryDomainServices | Any         | Allow  | Yes      | Management of your domain. |
-| 3389        | TCP      | CorpNetSaw                         | Any         | Allow  | Optional      | Debugging for support. |
+| Source      | Source service tag                 | Source port ranges |  Destination  | Service | Destination port ranges | Protocol | Action | Required | Purpose |
+|:-----------:|:----------------------------------:|:------------------:|:-------------:|:-------:|:-----------------------:|:--------:|:------:|:--------:|:--------|
+| Service tag | AzureActiveDirectoryDomainServices | *                  | Any           | WinRM   | 5986            | TCP | Allow | Yes | Management of your domain. |
+| Service tag | CorpNetSaw                         | *                  | Any           | RDP     | 3389            | TCP | Allow | Optional | Debugging for support |
+
+
+Note that the **CorpNetSaw** service tag isn't available by using Azure portal, and the network security group rule for **CorpNetSaw** has to be added by using [PowerShell](powershell-create-instance.md#create-a-network-security-group).
 
 Azure AD DS also relies on the Default Security rules AllowVnetInBound and AllowAzureLoadBalancerInBound.