-When you use Application Insights with Azure AD B2C, all you need to do is create a resource and get the instrumentation key. For information, see [Create an Application Insights resource](../azure-monitor/app/create-new-resource.md).

-In this sample tutorial, learn how to integrate Azure Active Directory (AD) B2C authentication with [BlokSec](https://bloksec.com/). BlokSec simplifies the end-user login experience by providing customers passwordless authentication and tokenless multifactor authentication (MFA). BlokSec protects customers against identity-centric cyber-attacks such as password stuffing, phishing, and man-in-the-middle attacks.

-## Scenario description

-BlokSec integration includes the following components:

-The following architecture diagram shows the implementation.

-

-|Steps| Description|

-|:|:-|

-|1.| User attempts to log in to an Azure AD B2C application and is forwarded to Azure AD B2CΓÇÖs combined sign-in and sign-up policy.|

-|2.| Azure AD B2C redirects the user to the BlokSec decentralized identity router using the OIDC authorization code flow.|

-|3.| The BlokSec decentralized router sends a push notification to the userΓÇÖs mobile app including all context details of the authentication and authorization request.|

-|4.| The user reviews the authentication challenge, if accepted the user is prompted for biometry such as fingerprint or facial scan as available on their device, proving the userΓÇÖs identity.|

-|5.| The response is digitally signed with the userΓÇÖs unique digital key. Final authentication response provides proof of possession, presence, and consent. The respond is returned to the BlokSec decentralized identity router.|

-|6.| The BlokSec decentralized identity router verifies the digital signature against the userΓÇÖs immutable unique public key that is stored in a distributed ledger, then replies to Azure AD B2C with the authentication result.|

-|7.| Based on the authentication result user is granted/denied access.|

-## Onboard to BlokSec

-Request a demo tenant with BlokSec by filling out [the form](https://bloksec.com/). In the message field indicates that you would like to onboard with Azure AD B2C. Download and install the free BlokSec yuID mobile app from the app store. Once your demo tenant has been prepared, you'll receive an email. On your mobile device where the BlokSec application is installed, select the link to register your admin account with your yuID app.

-## Prerequisites

-To get started, you'll need:

-To get started, you'll need:

-### Part 1 - Create an application registration in BlokSec

-1. Sign in to the BlokSec admin portal. A link will be included as part of your account registration email received when you onboard to BlokSec.

-2. On the main dashboard, select **Add Application > Create Custom**

-3. Complete the application details as follows and submit:

- |Property |Value |

- |||

- | Name |Azure AD B2C or your desired application name|

- |SSO type | OIDC|

- |Logo URI |[https://bloksec.io/assets/AzureB2C.png](https://bloksec.io/assets/AzureB2C.png) a link to the image of your choice|

- |Redirect URIs | https://**your-B2C-tenant-name**.b2clogin.com/**your-B2C-tenant-name**.onmicrosoft.com/oauth2/authresp<BR>**For Example**: 'https://fabrikam.b2clogin.com/fabrikam.onmicrosoft.com/oauth2/authresp' <BR><BR>If you use a custom domain, enter https://**your-domain-name**/**your-tenant-name**.onmicrosoft.com/oauth2/authresp. <BR> Replace your-domain-name with your custom domain, and your-tenant-name with the name of your tenant. |

- |Post log out redirect URIs |https://**your-B2C-tenant-name**.b2clogin.com/**your-B2C-tenant-name**.onmicrosoft.com/**{policy}**/oauth2/v2.0/logout <BR> [Send a sign-out request](./openid-connect.md#send-a-sign-out-request). |

-4. Once saved, select the newly created Azure AD B2C application to open the application configuration, select **Generate App Secret**.

->You'll need application ID and application secret later to configure the Identity provider in Azure AD B2C.

-### Part 2 - Add a new Identity provider in Azure AD B2C

-1. Sign-in to the [Azure portal](https://portal.azure.com/#home) 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, then search for and select **Azure AD B2C**.

-1. Navigate to **Dashboard** > **Azure Active Directory B2C** > **Identity providers**.

-1. Select New **OpenID Connect Provider**.

-1. Select **Add**.

-### Part 3 - Configure an Identity provider

-1. Fill out the form to set up the Identity provider:

-|Property |Value |

-|:|:|

-|Name |Enter BlokSec yuID ΓÇô Passwordless or a name of your choice|

-|Metadata URL| `https://api.bloksec.io/oidc/.well-known/openid-configuration` |

-|Client ID|The application ID from the BlokSec admin UI captured in **Part 1**|

-|Client Secret|The application Secret from the BlokSec admin UI captured in **Part 1**|

-|Scope|OpenID email profile|

-|Response type|Code|

-|Domain hint|yuID|

-1. Select **OK**.

-1. Select **Map this identity providerΓÇÖs claims**.

-1. Fill out the form to map the Identity provider:

-|Property |Value |

-|:|:|

-|User ID|sub|

-|Display name|name|

-|Given name|given_name|

-|Surname|family_name|

-|Email|email|

-1. Select **Save** to complete the setup for your new OIDC Identity provider.

-### Part 4 - User registration

-1. Sign-in to BlokSec admin console with the credential provided earlier.

-1. Navigate to Azure AD B2C application that was created earlier. Select the gear icon at the top-right, and then select **Create Account**.

-1. Enter the userΓÇÖs information in the Create Account form, making note of the Account Name, and select **Submit**.

-The user will receive an **account registration email** at the provided email address. Have the user follow the registration link on the mobile device where the BlokSec yuID app is installed,

-### Part 5 - Create a user flow policy

-You should now see BlokSec as a new OIDC Identity provider listed within your B2C identity providers.

-1. Select **New user flow**

-1. Select **Sign up and sign in** > **Version** > **Create**.

-1. Enter a **Name** for your policy.

-1. In the Identity providers section, select your newly created BlokSec Identity provider.

-1. Select **None** for Local Accounts to disable email and password-based authentication.

-1. Select **Run user flow**

-1. In the form, enter the Replying URL, such as `https://jwt.ms`.

-1. The browser will be redirected to the BlokSec login page. Enter the account name registered during User registration. The user will receive a push notification to their mobile device where the BlokSec yuID application is installed; upon opening the notification, the user will be presented with an authentication challenge

-1. Once the authentication challenge is accepted, the browser will redirect the user to the replying URL.

-## Next steps

-For additional information, review the following articles:

->In Azure Active Directory B2C, [**custom policies**](./user-flow-overview.md) are designed primarily to address complex scenarios. For most scenarios, we recommend that you use built-in [**user flows**](./user-flow-overview.md).

-### Part 2 - Create a policy key

-Store the client secret that you previously recorded in 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, and then search for and select **Azure AD B2C**.

-1. On the Overview page, select **Identity Experience Framework**.

-1. Select **Policy Keys** and then select **Add**.

-1. For **Options**, choose `Manual`.

-1. Enter a **Name** for the policy key. For example, `BlokSecAppSecret`. The prefix `B2C_1A_` is added automatically to the name of your key.

-1. In **Secret**, enter your client secret that you previously recorded.

-1. For **Key usage**, select `Signature`.

-1. Select **Create**.

-### Part 3 - Configure BlokSec as an Identity provider

-To enable users to sign in using BlokSec decentralized identity, you need to define BlokSec as a claims provider that Azure AD B2C can communicate with through an endpoint. The endpoint provides a set of claims that are used by Azure AD B2C to verify a specific user has authenticated using biometry such as fingerprint or facial scan as available on their device, proving the userΓÇÖs identity.

-You can define BlokSec as a claims provider by adding it to the **ClaimsProvider** element in the extension file of your policy

-2. Find the **ClaimsProviders** element. If it dosen't exist, add it under the root element.

-3. Add a new **ClaimsProvider** as follows:

-5. Save the file.

-### Part 4 - Add a user journey

-At this point, the identity provider has been set up, but it's not yet available in any of the sign-in pages. If you don't have your own custom user journey, create a duplicate of an existing template user journey, otherwise continue to the next step.

-1. Open the `TrustFrameworkBase.xml` file from the starter pack.

-2. Find and copy the entire contents of the **UserJourneys** element that includes ID=`SignUpOrSignIn`.

-3. Open the `TrustFrameworkExtensions.xml` and find the **UserJourneys** element. If the element doesn't exist, add one.

-4. Paste the entire content of the **UserJourney** element that you copied as a child of the **UserJourneys** element.

-5. Rename the ID of the user journey. For example, ID=`CustomSignUpSignIn`.

-### Part 5 - Add the identity provider to a user journey

-Now that you have a user journey, add the new identity provider to the user journey. First add a sign-in button, then link the button to an action. The action is the technical profile you created earlier.

-1. Find the orchestration step element that includes Type=`CombinedSignInAndSignUp`, or Type=`ClaimsProviderSelection` in the user journey. It's usually the first orchestration step. The **ClaimsProviderSelections** element contains a list of identity providers that a user can sign in with. The order of the elements controls the order of the sign-in buttons presented to the user. Add a **ClaimsProviderSelection** XML element. Set the value of **TargetClaimsExchangeId** to a friendly name.

-2. In the next orchestration step, add a **ClaimsExchange** element. Set the **Id** to the value of the target claims exchange ID. Update the value of **TechnicalProfileReferenceId** to the ID of the technical profile you created earlier.

-The following XML demonstrates the first two orchestration steps of a user journey with the identity provider:

-### Part 6 - Configure the relying party policy

-The relying party policy, for example [SignUpSignIn.xml](https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/master/SocialAndLocalAccounts/SignUpOrSignin.xml), specifies the user journey which Azure AD B2C will execute. Find the **DefaultUserJourney** element within relying party. Update the **ReferenceId** to match the user journey ID, in which you added the identity provider.

-### Part 7 - Upload the custom policy

-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. In the [Azure portal](https://portal.azure.com/#home), search for and select **Azure AD B2C**.

-1. Under Policies, select **Identity Experience Framework**.

-Select **Upload Custom Policy**, and then upload the two policy files that you changed, in the following order: the extension policy, for example `TrustFrameworkExtensions.xml`, then the relying party policy, such as `SignUpSignIn.xml`.

-### Part 8 - Test your custom policy

-1. For **Application**, select a web application that you [previously registered](./tutorial-register-applications.md). The **Reply URL** should show `https://jwt.ms`.

-1. Select the **Run now** button.

-1. From the sign-up or sign-in page, select **Google** to sign in with Google account.

-If the sign-in process is successful, your browser is redirected to `https://jwt.ms`, which displays the contents of the token returned by Azure AD B2C.

-For additional information, review the following articles:

-# Configure eID-Me with Azure Active Directory B2C for identity verification

-In this sample article, we provide guidance on how to integrate Azure Active Directory B2C (Azure AD B2C) authentication with [eID-Me](https://bluink.ca). eID-Me is an identity verification and decentralized digital identity solution for Canadian citizens. With eID-Me, Azure AD B2C tenants can strongly verify the identity of their users, obtain verified identity claims during sign up and sign in, and support multifactor authentication (MFA) and password-free sign-in using a secure digital identity. It enables organizations to meet Identity Assurance Level (IAL) 2 and Know Your Customer (KYC) requirements. This solution provides users secure sign-up and sign in experience while reducing fraud.

-To get started, you'll need:

-account](https://azure.microsoft.com/free).

-The eID-Me apps also provide strong authentication of the user during any transaction. X509 public key authentication using a private signing key contained within the eID-Me digital identity provides passwordless MFA.

-The following diagram shows the identity proofing process, which occurs outside of Azure AD B2C flows.

-

-| Steps | Description |

-| :- | :-- |

-| 1. | User uploads a selfie capture into the eID-Me smartphone application. |

-| 2. | User scans and uploads a government issued identification document such as Passport or Driver license into the eID-Me smartphone application. |

-| 3. | The eID-Me smartphone application submits this data to eID-Me identity service for verification. |

-| 4. | A digital identity is issued to the user and saved in the application. |

-The following architecture diagram shows the implementation.

-

-| Steps | Description |

-| :- | :-- |

-| 1. | User opens Azure AD B2C's sign in page, and then signs in or signs up by entering their username. |

-| 2. | User is forwarded to Azure AD B2CΓÇÖs combined sign-in and sign-up policy. |

-| 3. | Azure AD B2C redirects the user to the eID-Me identity router using the OIDC authorization code flow. |

-| 4. | The eID-Me router sends a push notification to the userΓÇÖs mobile app including all context details of the authentication and authorization request. |

-| 5. | The user reviews the authentication challenge; if accepted the user is prompted for identity claims, proving the userΓÇÖs identity. |

-| 6. | The challenge response is returned to the eID-Me router. |

-| 7. | The eID-Me router then replies to Azure AD B2C with the authentication result. |

-| 8. | Response from Azure AD B2C is sent as an ID token to the application. |

-| 9. | Based on the authentication result, the user is granted or denied access. |

-## Onboard with eID-Me

-[Contact eID-Me](https://bluink.ca/contact) and configure a test or production environment to set up Azure AD B2C tenants as a Relying Party. Tenants must determine what identity claims they'll need from their consumers as they sign up using eID-Me.

-## Step 1: Configure an application in eID-Me

-To configure your tenant application as a Relying Party in eID-Me the following information should be supplied to eID-Me:

-| Property | Description |

-| : | : |

-| Name | Azure AD B2C/your desired application name |

-| Domain | name.onmicrosoft.com |

-| Redirect URIs | https://jwt.ms |

-| Redirect URLs | `https://your-B2C-tenant-name.b2clogin.com/your-B2C-tenant-name.onmicrosoft.com/oauth2/authresp`<br>For Example: `https://fabrikam.b2clogin.com/fabrikam.onmicrosoft.com/oauth2/authresp`<br>If you use a custom domain, enter https://your-domain-name/your-tenant-name.onmicrosoft.com/oauth2/authresp.<br> Replace your-domain-name with your custom domain, and your-tenant-name with the name of your tenant. |

-| URL for application home page | Will be displayed to the end user |

-| URL for application privacy policy | Will be displayed to the end user |

-eID-Me will provide a Client ID and a Client Secret once the Relying Party has been configured with eID-Me.

->You'll need Client ID and Client secret later to configure the Identity provider in Azure AD B2C.

-## Step 2: Add a new Identity provider in Azure AD B2C

-1. Sign in to the [Azure portal](https://portal.azure.com/#home) as the global administrator of your Azure AD B2C tenant.

-2. Make sure you're using the directory that contains your Azure AD B2C tenant by selecting the **Directory + subscription** filter in the top menu and choosing the directory that contains your tenant.

-3. Choose **All services** in the top-left corner of the Azure portal, search for and select **Azure AD B2C**.

-4. Navigate to **Dashboard** > **Azure Active Directory B2C** > **Identity providers**.

-5. Select **New OpenID Connect Provider**.

-6. Select **Add**.

-## Step 3: Configure an Identity provider

-To configure an identity provider, follow these steps:

-1. Select **Identity provider type** > **OpenID Connect**

-2. Fill out the form to set up the Identity provider:

- | Property | Value |

- | : | :- |

- | Name | Enter eID-Me Passwordless/a name of your choice |

- | Client ID | Provided by eID-Me |

- | Client Secret | Provided by eID-Me |

- | Scope | openid email profile |

- | Response type | code |

- | Response mode | form post |

-3. Select **OK**.

-4. Select **Map this identity providerΓÇÖs claims**.

-5. Fill out the form to map the Identity provider:

- | Property | Value |

- | :-- | :- |

- | User ID | sub |

- | Display name | name |

- | Given name | given_name |

- | Surname | family_name |

- | Email | email |

-6. Select **Save** to complete the setup for your new OIDC Identity provider.

-## Step 4: Configure multi-factor authentication

-eID-Me is a decentralized digital identity with strong two-factor user authentication built in. Since eID-Me is already a multi-factor authenticator, you don't need to configure any multi-factor authentication settings in your user flows when using eID-Me. eID-Me offers a fast and simple user experience, which also eliminates the need for any additional passwords.

-## Step 5: Create a user flow policy

-You should now see eID-Me as a new OIDC Identity provider listed within your B2C identity providers.

-1. In your Azure AD B2C tenant, under **Policies**, select **User flows**.

-2. Select **New user flow**

-4. Enter a **Name** for your policy.

-5. In the Identity providers section, select your newly created eID-Me Identity provider.

-6. Select **None** for Local Accounts to disable email and password-based authentication.

-7. Select **Run user flow**

-8. In the form, enter the Replying URL, such as `https://jwt.ms`.

-9. The browser will be redirected to the eID-Me sign-in page. Enter the account name registered during User registration. The user will receive a push notification to their mobile device where the eID-Me application is installed; upon opening the notification, the user will be presented with an authentication challenge

-10. Once the authentication challenge is accepted, the browser will redirect the user to the replying URL.

-## Next steps

-For additional information, review the following articles:

->In Azure AD B2C, [**custom policies**](./user-flow-overview.md) are designed primarily to address complex scenarios. For most scenarios, we recommend that you use built-in [**user flows**](./user-flow-overview.md).

-## Step 2: Create a policy key

-Store the client secret that you previously recorded in your Azure AD B2C tenant.

-2. Make sure you're using the directory that contains your Azure AD B2C tenant. Select the **Directories + subscriptions** icon in the portal toolbar.

-3. On the **Portal settings | Directories + subscriptions** page, find your Azure AD B2C directory in the **Directory name** list, and then select **Switch**.

-4. Choose **All services** in the top-left corner of the Azure portal, and then search for and select **Azure AD B2C**.

-5. On the Overview page, select **Identity Experience Framework**.

-6. Select **Policy Keys** and then select **Add**.

-7. For **Options**, choose `Manual`.

-8. Enter a **Name** for the policy key. For example, `eIDMeClientSecret`. The prefix `B2C_1A_` is added automatically to the name of your key.

-9. In **Secret**, enter your client secret that you previously recorded.

-10. For **Key usage**, select `Signature`.

-11. Select **Create**.

-## Step 3: Configure eID-Me as an Identity provider

-To enable users to sign in using eID-Me decentralized identity, you need to define eID-Me as a claims provider that Azure AD B2C can communicate with through an endpoint. The endpoint provides a set of claims that are used by Azure AD B2C to verify a specific user has authenticated using digital ID available on their device, proving the userΓÇÖs identity.

-You can define eID-Me as a claims provider by adding it to the **ClaimsProvider** element in the extension file of your policy

-2. Find the **ClaimsProviders** element. If it doesn't exist, add it under the root element.

-3. Add a new **ClaimsProvider** as follows:

-4. Set **eid_me_rp_client_id** with your eID-Me Relying Party Client ID.

-5. Save the file.

-There are additional identity claims that eID-Me supports and can be added.

-1. Open the `TrustFrameworksExtension.xml`

-2. Find the `BuildingBlocks` element. This is where additional identity claims that eID-Me supports can be added. Full lists of supported eID-Me identity claims with descriptions are mentioned at `http://www.oid-info.com/get/1.3.6.1.4.1.50715` with the OIDC identifiers used here [https://eid-me.bluink.ca/.well-known/openid-configuration](https://eid-me.bluink.ca/.well-known/openid-configuration).

-## Step 4: Add a user journey

-At this point, the identity provider has been set up, but it's not yet available in any of the sign-in pages. If you don't have your own custom user journey, create a duplicate of an existing template user journey, otherwise continue to the next step.

-1. Open the `TrustFrameworkBase.xml` file from the starter pack.

-2. Find and copy the entire contents of the **UserJourneys** element that includes ID=`SignUpOrSignIn`.

-3. Open the `TrustFrameworkExtensions.xml` and find the **UserJourneys** element. If the element doesn't exist, add one.

-4. Paste the entire content of the **UserJourney** element that you copied as a child of the **UserJourneys** element.

-5. Rename the ID of the user journey. For example, ID=`CustomSignUpSignIn`

-## Step 5: Add the identity provider to a user journey

-Now that you have a user journey, add the new identity provider to the user journey.

-1. Find the orchestration step element that includes Type=`CombinedSignInAndSignUp`, or Type=`ClaimsProviderSelection` in the user journey. It's usually the first orchestration step. The **ClaimsProviderSelections** element contains a list of identity providers that a user can sign in with. The order of the elements controls the order of the sign-in buttons presented to the user. Add a **ClaimsProviderSelection** XML element. Set the value of **TargetClaimsExchangeId** to a friendly name.

-2. In the next orchestration step, add a **ClaimsExchange** element. Set the **Id** to the value of the target claims exchange ID. Update the value of **TechnicalProfileReferenceId** to the ID of the technical profile you created earlier.

- The following XML demonstrates **7** orchestration steps of a user journey with the identity provider:

-## Step 6: Configure the relying party policy

-The relying party policy specifies the user journey which Azure AD B2C will execute. You can also control what claims are passed to your application by adjusting the **OutputClaims** element of the **eID-Me-OIDC-Signup** TechnicalProfile element. In this sample, the application will receive the userΓÇÖs postal code, locality, region, IAL, portrait, middle name, and birth date. It also receives the boolean **signupConditionsSatisfied** claim, which indicates whether an account has been created or not:

-## Step 7: Upload the custom policy

-1. Sign in to the [Azure portal](https://portal.azure.com/#home).

-2. Make sure you're using the directory that contains your Azure AD B2C tenant. Select the **Directories + subscriptions** icon in the portal toolbar.

-3. On the **Portal settings | Directories + subscriptions** page, find your Azure AD B2C directory in the **Directory name** list, and then select **Switch**.

-4. In the [Azure portal](https://portal.azure.com/#home), search for and select **Azure AD B2C**.

-5. Under Policies, select **Identity Experience Framework**.

-Select **Upload Custom Policy**, and then upload the two policy files that you changed, in the following order: the extension policy, for example `TrustFrameworkBase.xml`, then the relying party policy, such as `SignUp.xml`.

-## Step 8: Test your custom policy

-1. Select your relying party policy, for example `B2C_1A_signup`.

-2. For **Application**, select a web application that you [previously registered](./tutorial-register-applications.md). The **Reply URL** should show `https://jwt.ms`.

-3. Select the **Run now** button.

-4. The sign-up policy should invoke eID-Me immediately. If sign-in is used, then select eID-Me to sign in with eID-Me.

-If the sign-in process is successful, your browser is redirected to `https://jwt.ms`, which displays the contents of the token returned by Azure AD B2C.

-For additional information, review the following articles:

-|  integration helps you sign in securely and enables passwordless authentication, MFA, and digital license scanning. |

-description: Learn how to integrate Azure AD B2C authentication with IDEMIA for relying party to consume IDEMIA or US State issued mobile IDs

-# Tutorial: Configure IDEMIA with Azure Active Directory B2C for relying party to consume IDEMIA or US State issued mobile identity credentials (Preview)

-This feature is available only for custom policies. For setup steps, select **Custom policy** in the preceding selector.

-In this sample tutorial, learn how to integrate Azure Active Directory (Azure AD) B2C with [IDEMIA](https://www.idemia.com/). IDEMIA is a passwordless authentication provider, which provides real-time consent-based services with biometric authentication like face ID and fingerprinting eliminating fraud and credential reuse. IDEMIAΓÇÖs Mobile ID allows citizens to benefit from a government-issued trusted digital ID, as a complement to their physical ID. This application is used to verify identity by using a self-selected PIN or touch ID/face ID. Mobile ID allows citizens to control their identities by allowing them to share only the information needed for a transaction and enables fraud protection.

-IDEMIA integration includes the following components:

-IDEMIA provides mID for many US State departments of motor vehicles (DMVs).

-The mID is a digitizing of an identification document into a strong mobile identity token that is highly portable for verification and that serves as an index for authorization **mID Services**. The mID Service allows the DMVs to proof identities of individuals by using credential document authentication using their issued drivers licenses and biometric **selfie**-to-credential facial recognition matching services.

-Once created, the mID is stored on the end user's mobile phone as a digitally signed **identity on the edge**. The end users are now able to use that signed credential for access to other identity sensitive services such as proof of age, financial know your customer, account accessΓÇÖs where security is paramount.

-The offer to Microsoft is the support of these services as the Relying party (RP) that will use a State issued mID to provide services using the attributes sent by the owner of the mID.

-The following diagram shows the implementation for web or on-premises scenarios:

-

-| Step | Description |

-|:--|:--|

-| 1. | User visits the Azure AD B2C login page, which is the replying party in this case on their device to conduct a transaction and logs in via their mID app. |

-| 2. | Azure AD B2C requires an ID check and for that redirects the user to the IDEMIA router using the OIDC authorization code flow|

-| 3. | The IDEMIA router sends a biometric challenge to the userΓÇÖs mobile app including all context details of the authentication and authorization request.|

-| 4. | Depending on the level of security needed, the user may require to provide additional details, input their PIN, take a live selfie, or both.|

-| 5. | Final authentication response provides proof of possession, presence, and consent. The response is returned to the IDEMIA router.|

-| 6. | IDEMIA router verifies the information provided by the user and replies to Azure AD B2C with the authentication result.|

-|7. | Based on the authentication result user is granted/denied access. |

-## Onboard with IDEMIA

-Get in touch with [IDEMIA](https://www.idemia.com/get-touch/) to request a demo. While filling out the request form, in the message field indicate that you want to onboard with Azure AD B2C.

-## Integrate IDEMIA with Azure AD B2C

-To get started, you'll need:

->[!NOTE]

->The contents of the token never leave your browser.

-### Part 1 - Submit a Relying Party application on-boarding for mID

-As part of your integration with IDEMIA, you'll be provided with the following information:

-| Application Name | Azure AD B2C or your desired application name |

-| Client_ID | This is the unique identifier provided by the IdP |

-| Client Secret | Password the relying party application will use to authenticate with the IDEMIA IdP |

-| Metadata endpoint | A URL that points to a token issuer configuration document, which is also known as an OpenID well-known configuration endpoint. |

-|Redirect URIs | `https://your-B2C-tenant-name.b2clogin.com/your-B2C-tenant-name.onmicrosoft.com/oauth2/authresp`<br>For example, `https://fabrikam.b2clogin.com/fabrikam.onmicrosoft.com/oauth2/authresp`<br><br>If you use a custom domain, enter `https://your-domain-name/your-tenant-name.onmicrosoft.com/oauth2/authresp`.<br>Replace your-domain-name with your custom domain, and your-tenant-name with the name of your tenant. |

-|Post log out redirect URIs | `https://your-B2C-tenant-name.b2clogin.com/your-B2C-tenant-name.onmicrosoft.com/{policy}/oauth2/v2.0/logout`<br>Send a sign-out request. |

->[!NOTE]

->You'll need IDEMIA client ID and client secret later to configure the IdP in Azure AD B2C.

-### Part 2 - Create a policy key

-Store the IDEMIA client secret that you previously recorded in your Azure AD B2C tenant.

-2. Make sure you're using the directory that contains your Azure AD B2C tenant. Select the **Directories + subscriptions** icon in the portal toolbar.

-3. On the **Portal settings | Directories + subscriptions** page, find your Azure AD B2C directory in the **Directory name** list, and then select **Switch**.

-4. Choose **All services** in the top-left corner of the Azure portal, and then search for and select **Azure AD B2C**.

-5. On the **Overview** page, select **Identity Experience Framework**.

-6. Select **Policy Keys** and then select **Add**.

-7. For **Options**, choose **Manual**.

-8. Enter a **Name** for the policy key. For example, IdemiaAppSecret. The prefix B2C_1A_ is added automatically to the name of your key.

-9. In **Secret**, enter your client secret that you previously recorded.

-10. For **Key** usage, select **Signature**.

-11. Select **Create**.

-### Part 3 - Configure IDEMIA as an External IdP

-To enable users to sign in using IDEMIA mobile ID passwordless identity, you need to define IDEMIA as a claims provider that Azure AD B2C can communicate with through an endpoint. The endpoint provides a set of claims that are used by Azure AD B2C to verify a specific user has authenticated using biometry such as fingerprint or facial scan as available on their device, proving the userΓÇÖs identity.

-You can define IDEMIA as a claims provider by adding it to the **ClaimsProvider** element in the extension file of your policy.

-|:|:-|

-|Scope| For OpenID Connect (OIDC) the minimum requirement is that the scope parameter be set to **openid**. Additional scopes may be appended as a space-delimited list.|

-|redirect_uri | This defines where the user agent sends the authorization code back to Azure AD B2C.|

-|response_type| For the authorization code flow, this is set to **code**|

-|acr_values| This parameter controls the authentication methods that the user is required to perform during the authentication process. |

-One of the following values must be selected:

-|:|:-|

-|`loa-2`| Crypto-based Azure AD Multi-Factor Authentication only|

-|`loa-3`| Crypto-based Azure AD Multi-Factor Authentication plus one additional factor|

-|`loa-4`| Crypto-based Azure AD Multi-Factor Authentication with the requirement that the user must also perform pin-based and biometric authentication |

-The **/userinfo** endpoint provides the claims for the scope(s) requested in the authorization request. For the **<mt_scope>** this includes such claims as First Name, Last Name, and Driver's License Number, among other items.

-The claims set for any given scope are published in the **scope_to_claims_mapping** section of the discovery API.

-Azure AD B2C requests claims from the claims endpoint and returns those claims in the OutputClaims element. You may need to map the name of the claim defined in your policy to the name defined in the IdP making sure to define the claim type in the [ClaimSchema element](claimsschema.md):

-### Part 4 - Add a user journey

-At this point, the IdP has been set up, but it's not yet available in any of the sign-in pages. If you don't have your own custom user journey, create a duplicate of an existing template user journey, otherwise continue to the next step.

-1. Open the `TrustFrameworkBase.xml` file from the starter pack.

-2. Find and copy the entire contents of the **UserJourneys** element that includes `ID=SignUpOrSignIn`.

-3. Open the `TrustFrameworkExtensions.xml` and find the **UserJourneys** element. If the element doesn't exist, add one.

-4. Paste the entire content of the **UserJourney** element that you copied as a child of the UserJourneys element.

-5. Rename the ID of the user journey. For example, `ID=CustomSignUpSignIn`.

-### Part 5 - Add the IdP to a user journey

-Now that you have a user journey, add the new IdP to the user journey. First add a sign-in button, then link the button to an action. The action is the technical profile you created earlier.

-1. Find the orchestration step element that includes Type=`CombinedSignInAndSignUp`, or Type=`ClaimsProviderSelection` in the user journey. It's usually the first orchestration step. The **ClaimsProviderSelections** element contains a list of IdPs that a user can sign in with. The order of the elements controls the order of the sign-in buttons presented to the user. Add a **ClaimsProviderSelection** XML element. Set the value of **TargetClaimsExchangeId** to a friendly name.

-2. In the next orchestration step, add a **ClaimsExchange** element. Set the **Id** to the value of the target claims exchange ID. Update the value of **TechnicalProfileReferenceId** to the ID of the technical profile you created earlier.

-### Part 6 - Configure the relying party policy

-The relying party policy, for example [SignUpSignIn.xml](https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/master/SocialAndLocalAccounts/SignUpOrSignin.xml), specifies the user journey which Azure AD B2C will execute. Find the **DefaultUserJourney** element within relying party. Update the **ReferenceId** to match the user journey ID, in which you added the IdP.

-### Part 7 - Upload the custom policy

-1. Sign in to the [Azure portal](https://portal.azure.com/#home).

-2. Make sure you're using the directory that contains your Azure AD B2C tenant. Select the **Directories + subscriptions** icon in the portal toolbar.

-3. On the **Portal settings | Directories + subscriptions** page, find your Azure AD B2C directory in the **Directory name** list, and then select **Switch**.

-4. In the [Azure portal](https://portal.azure.com/#home), search for and select **Azure AD B2C**.

-5. Under Policies, select **Identity Experience Framework**.

-Select **Upload Custom Policy**, and then upload the two policy files that you changed, in the following order: the extension policy, for example `TrustFrameworkExtensions.xml`, then the relying party policy, such as `SignUpSignIn.xml`.

-### Part 8 - Test your custom policy

-2. For **Application**, select a web application that you [previously registered](./tutorial-register-applications.md). The **Reply URL** should show `https://jwt.ms`.

-3. Select the **Run now** button.

-4. From the sign-up or sign-in page, select **IDEMIA** to sign in with an IDEMIA - US State issued mID (Mobile ID Credential).

-If the sign-in process is successful, your browser is redirected to `https://jwt.ms`, which displays the contents of the token returned by Azure AD B2C.

-For additional information, review the following articles:

-description: Learn how to add Trusona as an identity provider on Azure AD B2C to enable passwordless authentication.

-# Integrating Trusona with Azure Active Directory B2C

-Trusona is an independent software vendor (ISV) provider that helps secure sign-in by enabling passwordless authentication, multi-factor authentication, and digital license scanning. In this article, you'll learn how to add Trusona as an identity provider in Azure AD B2C to enable passwordless authentication.

-To get started, you'll need:

-* An Azure AD subscription. If you don't have a subscription, you can get a [free account](https://azure.microsoft.com/free/).

-* [An Azure AD B2C tenant](tutorial-create-tenant.md) that is linked to your Azure subscription.

-* A [trial account](https://www.trusona.com/) at Trusona

-In this scenario, Trusona acts as an identity provider for Azure AD B2C to enable passwordless authentication. The following components make up the solution:

-* An Azure AD B2C combined sign-in and sign-up policy

-* Trusona added to Azure AD B2C as an identity provider

-* The downloadable Trusona app

-

-| Step | Description |

-|||

-|1 | A user attempts to sign in to or sign up with the application. The user is authenticated via the Azure AD B2C sign-up and sign-in policy. During sign-up, the user's previously verified email address from the Trusona app is used. |

-|2 | Azure B2C redirects the user to the Trusona OpenID Connect (OIDC) identity provider. |

-|3 | For desktop PC-based logins, Trusona displays a unique, stateless, animated, and dynamic QR code for scanning with the Trusona app. For mobile-based logins, Trusona uses a "deep link" to open the Trusona app. These two methods are used for device and ultimately user discovery. |

-|4 | The user scans the displayed QR code with the Trusona app. |

-|5 | The user's account is found in the Trusona cloud service and the authentication is prepared. |

-|6 | The Trusona cloud service issues an authentication challenge to the user via a push notification sent to the Trusona app:<br>a. The user is prompted with the authentication challenge. <br> b. The user chooses to accept or reject the challenge. <br> c. The user is asked to use OS security (for example, biometric, passcode, PIN, or pattern) to confirm and sign the challenge with a private key in the Secure Enclave/Trusted Execution environment. <br> d. The Trusona app generates a dynamic anti-replay payload based on the parameters of the authentication in real time. <br> e. The entire response is signed (for a second time) by a private key in the Secure Enclave/Trusted Execution environment and returned to the Trusona cloud service for verification. |

-|7 | The Trusona cloud service redirects the user back to the initiating application with an id_token. Azure AD B2C verifies the id_token using Trusona's published OpenID configuration as configured during identity provider setup. |

-| | |

-## Onboard with Trusona

-1. Fill out the [form](https://www.trusona.com/) to create a Trusona account and get started.

-1. Download the Trusona mobile app from the app store. Install the app and register your email.

-1. Verify your email through the secure "magic link" sent by the software.

-1. Go to the [Trusona DeveloperΓÇÖs dashboard](https://dashboard.trusona.com) for self-service.

-1. Select **IΓÇÖm Ready** and authenticate yourself with your Trusona app.

-1. From the left navigation panel, choose **OIDC Integrations**.

-1. Select **Create OpenID Connect Integration**.

-1. Provide a **Name** of your choice and use the domain information previously provided (for example, Contoso) in the **Client Redirect Host field**.

- > [!NOTE]

- > Azure Active DirectoryΓÇÖs initial domain name is used as the Client Redirect host.

-1. Follow the instructions in the [Trusona integration guide](https://docs.trusona.com/integrations/aad-b2c-integration/). When prompted, use the initial domain name (for example, Contoso) referred in the previous step.

-## Integrate with Azure AD B2C

-### Add a new identity provider

-> [!NOTE]

-> If you don't have one already, [create an Azure AD B2C tenant](tutorial-create-tenant.md) that is linked to your Azure subscription.

-### Configure an identity provider

-1. Fill out the form to set up the identity provider:

- | Metadata URL | `https://gateway.trusona.net/oidc/.well-known/openid-configuration`|

- | Client ID | Will be emailed to you from Trusona |

- | Response type | Id_token |

- | Response mode | Form_post |

-1. Fill out the form to map the identity provider:

- | UserID | Sub |

- | Surname | Family_name |

-1. Select **OK** to complete the setup for your new OIDC identity Provider.

-### Create a user flow policy

-You should now see Trusona as a **new OpenID Connect Identity Provider** listed within your B2C identity providers.

-1. In the **Identity providers** section, select your newly created **Trusona Identity Provider**.

-### Test the policy

- 1. **Application**: Select the registered app.

- 1. **Reply URL**: Select the redirect URL.

-1. Select **Run user flow**. You should be redirected to the Trusona OIDC gateway. On the Trusona gateway, scan the displayed Secure QR code with the Trusona app or with a custom app using the Trusona mobile SDK.

-1. After you scan the Secure QR code, you should be redirected to the Reply URL you defined.

- | 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. |

- | 636 | TCP | AzureActiveDirectoryDomainServices | Inbound | Allow | Optional | Secure LDAP. |

-Use the Azure Active Directory portal to view and manage all applications that are configured for single sign-on in a directory. Enterprise apps are apps that are deployed and used within your organization. Follow these steps to view and manage your enterprise applications:

-1. Open the [Azure Active Directory portal](https://aad.portal.azure.com).

-1. Select **Enterprise applications** from the left pane. A list of all configured apps is shown, including apps that were added from the gallery.

-1. Sign in to the [Azure Active Directory portal](https://aad.portal.azure.com).

-1. Select **Enterprise applications** from the left pane. A list of all configured apps is shown, including apps that were added from the gallery.

- 1. Sign in to the [Azure Active Directory portal](https://aad.portal.azure.com), select **Enterprise Applications**, select your application, and then select **Provisioning**.

-1. The Azure AD provisioning service queries the ECMA Connector Host to see if the user exists. It uses the **matching attribute** as the filter. This attribute is defined in the Azure AD portal under Enterprise applications -> On-premises provisioning -> provisioning -> attribute matching. It is denoted by the 1 for matching precedence.

-Use the Azure AD portal to view and manage all the applications that support provisioning. See [Finding your apps in the portal](../app-provisioning/configure-automatic-user-provisioning-portal.md).

-

-In a request to a user provisioning, the value of the resource argument is an instance of the Microsoft.SCIM.Core2EnterpriseUser class, defined in the Microsoft.SCIM.Schemas library. If the request to provision the user succeeds, then the implementation of the method is expected to return an instance of the Microsoft.SCIM.Core2EnterpriseUser class, with the value of the Identifier property set to the unique identifier of the newly provisioned user.

-To update a user known to exist in an identity store fronted by an SCIM, Azure AD proceeds by requesting the current state of that user from the service with a request such as:

-In the example of a request to retrieve the current state of a user, the values of the properties of the object provided as the value of the parameters argument are as follows:

-In the example of a request to update a user, the object provided as the value of the patch argument has these property values:

-1. Sign in to the [Azure AD portal](https://aad.portal.azure.com). You can get access a free trial for Azure AD with P2 licenses by signing up for the [developer program](https://developer.microsoft.com/microsoft-365/dev-program))

-1. Select **Enterprise applications** from the left pane. A list of all configured apps is shown, including apps that were added from the gallery.

-Best practices (recommended, but not required):

-* Support multiple redirect URLs. Administrators can configure provisioning from both "portal.azure.com" and "aad.portal.azure.com". Supporting multiple redirect URLs will ensure that users can authorize access from either portal.

-* Support multiple secrets for easy renewal, without downtime.

-description: How to troubleshoot issues creating Application Proxy applications in the Azure Active Directory Admin portal

-For more detailed instructions, see [Add your custom domain name using the Azure Active Directory portal](../fundamentals/add-custom-domain.md).

-To change the home page URL of your app through the Azure AD portal, follow these steps:

-1. Sign in to the [Azure Active Directory portal](https://aad.portal.azure.com/). The **Dashboard** for the **Azure Active Directory admin center** appears.

-1. In the sidebar, select **Azure Active Directory**. The **Azure Active Directory** overview page appears.

-1. In the Azure AD overview sidebar, select **App registrations**. The list of all app registrations appears.

-The required info in the sample code can be found in the Azure AD portal, as follows:

-| Info required | How to find it in the Azure AD portal |

-1. The Admin customizes the attribute mappings required by the application in the Azure AD portal.

-Azure AD provides additional insights into your organizationΓÇÖs application usage and operational health through [audit logs and reports](../reports-monitoring/concept-provisioning-logs.md?context=azure/active-directory/manage-apps/context/manage-apps-context). Application Proxy also makes it very easy to monitor connectors from the Azure AD portal and Windows Event Logs.

-The connectors and the service take care of all the high availability tasks. You can monitor the status of your connectors from the Application Proxy page in the Azure AD Portal. For more information about connector maintainence see [Understand Azure AD Application Proxy Connectors](./application-proxy-connectors.md#maintenance).

-1. Sign in to the [Azure Active Directory portal](https://aad.portal.azure.com/) as an application administrator. The **Azure Active Directory admin center** page appears.

-1. Select **Azure Active Directory** > **Application proxy** > **Download connector service**. The **Application Proxy Connector Download** page appears.

-1. If you didn't in the last section, sign in to the [Azure Active Directory portal](https://aad.portal.azure.com/) as an application administrator.

-1. Select **Enterprise applications** > **New application** > **Add an on-premises application**. The **Add your own on-premises application** page appears.

-1. From the **Azure Active Directory admin center** sidebar, select **Azure Active Directory** > **App registrations**. A list of applications appears.

-1. From the **Azure Active Directory admin center** sidebar, select **Azure Active Directory** > **App registrations**. A list of applications appears.

-1. Sign in to the [Azure Active Directory portal](https://aad.portal.azure.com/) as an application administrator.

-1. Select **Azure Active Directory** > **App registrations**. A list of applications appears.

-Those steps help you install PingAccess and set up a PingAccess account (if you don't already have one). Then, to create an Azure AD OpenID Connect (OIDC) connection, you set up a token provider with the **Directory (tenant) ID** value that you copied from the Azure AD portal. Next, to create a web session on PingAccess, you use the **Application (client) ID** and `PingAccess key` values. After that, you can set up identity mapping and create a virtual host, site, and application.

-You can check the status of this feature in your own tenant by navigating to the [Azure AD portal](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade), then in the left pane, click **Security** > **MFA** > **Phone call settings**. Check **Operator required to transfer extensions** to see if the setting is **On** or **Off**.

-1. In the Azure AD portal, click **All users (preview)**.

-1. In the Azure AD portal, search for and select *Azure Active Directory*.

-1. In the Azure AD portal, search for and select *Azure Active Directory*.

-1. In the Azure AD portal, search for and select *Azure Active Directory*.

-Inside the **includeTarget** for each featureSetting, change the **id** from **all_users** to the ObjectID of the group from the Azure AD portal.

-Inside the **includeTarget** for each featureSetting, change the **id** from **all_users** to the ObjectID of the group from the Azure AD portal.

-Inside the **includeTarget** for each featureSetting, change the **id** from **all_users** to the ObjectID of the group from the Azure AD portal.

-In addition, for each of the features, you'll change the id of the excludeTarget to the ObjectID of the group from the Azure AD portal. This change excludes that group from seeing application name or geographic location.

-To enable application name or geographic location in the Azure AD portal, complete the following steps:

-1. In the Azure AD portal, click **Security** > **Authentication methods** > **Microsoft Authenticator**.

-To enable number matching in the Azure AD portal, complete the following steps:

-1. In the Azure AD portal, click **Security** > **Authentication methods** > **Microsoft Authenticator**.

-Inside the **includeTarget**, you'll need to change the **id** from **all_users** to the ObjectID of the group from the Azure AD portal.

-To enable a registration campaign in the Azure AD portal, complete the following steps:

-1. In the Azure AD portal, click **Security** > **Authentication methods** > **Registration campaign**.

-The script will instruct you to grant admin consent to the newly created application. Navigate to the URL provided, or within the Azure AD portal, click **Application Registrations**, find and select the **MFA Server Migration Utility** app, click on **API permissions** and then granting the appropriate permissions.

-| Test rolling back phone sign-in registration by turning off passwordless sign-in in the Authenticator app. Do this within the Authentication methods screen in the Azure AD portal| Previously enabled users unable to use passwordless sign-in from the Authenticator app. |

-| Test rolling back FIDO2 device registration by turning off FIDO2 Security Keys within the Authentication method window in the Azure Active Directory portal| Users will: <li> be prompted to sign in using their security key <li> successfully sign in and see an error: "Your company policy requires that you use a different method to sign in". <li>be able to select a different method and successfully sign in. Close the window and sign in again to verify they do not see the same error message. |

-1. Sign in to the Azure AD portal and search for the user account from which the FIDO key is to be removed.

-1. In the Azure AD portal, browse to **Users**, select a user, such as *Tap User*, then choose **Authentication methods**.

-Settings for app passwords, trusted IPs, verification options, and remembering multi-factor authentication on trusted devices are available in the service settings. This is a legacy portal. It isn't part of the regular Azure AD portal.

-Once done , go to https://aad.portal.azure.com > "Enterprise Applications" > Search for "Azure Multi-Factor Auth Client" > Check properties for this app > Confirm if the service principal is enabled or disabled > Click on the application entry > Go to Properties of the app > If the option "Enabled for users to sign-in? is set to No in Properties of this app , please set it to Yes.

-While SSPR does not typically create user issues, it is important to prepare support staff to deal with issues that may arise. While an administrator can reset the password for end users through the Azure AD portal, it is better to help resolve the issue via a self-service support process.

- 1. In the Azure AD portal, select **Permissions Management**, and then select the link to purchase a license or begin a trial.

-### In the Azure Active Directory admin center

- | **8080** (optional) | Agents report their status every 10 minutes over port 8080, if port 443 is unavailable. This status is displayed in the Azure AD portal. |

-### In the Azure Active Directory admin center

- | **8080** (optional) | Agents report their status every 10 minutes over port 8080, if port 443 is unavailable. This status is displayed on the Azure AD portal. |

-1. Sign in to the Azure AD portal.

-### In the Azure Active Directory admin center

- | **8080** (optional) | Agents report their status every 10 minutes over port 8080, if port 443 is unavailable. This status is displayed on the Azure AD portal. |

-1. Sign in to the Azure AD portal.

-For more information about these authentication protocols and services, see [Sign-in activity reports in the Azure Active Directory portal](../reports-monitoring/concept-sign-ins.md#filter-sign-in-activities).

-Planning your Conditional Access deployment is critical to achieving your organization's access strategy for apps and resources.

-

-### Prerequisites

-* A working Azure AD tenant with Azure AD Premium or trial license enabled. If needed, [create one for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* An account with privileges to create Conditional Access policies.

-* A test user (non-administrator) that allows you to verify policies work as expected before you impact real users. If you need to create a user, see [Quickstart: Add new users to Azure Active Directory](../fundamentals/add-users-azure-active-directory.md).

-#### Permissions

-Conditional Access policies can be created or modified by anyone assigned the following roles:

-Conditional Access policies can be read by anyone assigned the following roles:

-## Understand Conditional Access policy components

-Policies answer questions about who should access your resources, what resources they should access, and under what conditions. Policies can be designed to grant access, limit access with session controls, or to block access. You [build a Conditional Access policy](concept-conditional-access-policies.md) by defining the if-then statements: **If an assignment is met, then apply the access controls**.

-**Users or workload identities**

-* Which users, groups, directory roles and workload identities will be included in or excluded from the policy?

-**Cloud apps or actions**

-* What application(s) will the policy apply to?

-**Conditions**

-* What are the organizationΓÇÖs trusted locations?

-* What locations will be included in or excluded from the policy?

-* Do you have policies that would drive excluding Azure AD joined devices or Hybrid Azure AD joined devices from policies?

-* If using [Identity Protection](../identity-protection/concept-identity-protection-risks.md), do you want to incorporate sign-in risk protection?

-**Grant or Block**

-* Require MFA

-* Require device to be marked as compliant

-* Require hybrid Azure AD joined device

-* Require approved client app

-* Require app protection policy

-* Require password change

-* Use Terms of Use

-**Session control**

-### Access token issuance

-[Access tokens](../develop/access-tokens.md) grant or deny access based on whether the user making a request has been authorized and authenticated. If the requestor can prove they're who they claim to be, they can access the protected resources or functionality.

-

-**Access tokens are by default issued if a Conditional Access policy condition does not trigger an access control**.

-This doesnΓÇÖt prevent the app to have separate authorization to block access. For example, consider a policy where:

- * IF user is in finance team, THEN force MFA to access their payroll app.

- * IF a user not in finance team attempts to access the payroll app, the user will be issued an access token.

- * To ensure users outside of finance group can't access the payroll app, a separate policy should be created to block all other users. If all users except for finance team and emergency access accounts group, accessing payroll app, then block access.

-## Follow best practices

-Conditional Access provides you with great configuration flexibility. However, great flexibility also means you should carefully review each configuration policy before releasing it to avoid undesirable results.

-### Set up emergency access accounts

-**If you misconfigure a policy, it can lock the organizations out of the Azure portal**.

-Mitigate the impact of accidental administrator lockout by creating two or more [emergency access accounts](../roles/security-emergency-access.md) in your organization. Create a user account dedicated to policy administration and excluded from all your policies.

-**Ensure that every app has at least one Conditional Access policy applied**. From a security perspective it's better to create a policy that encompasses **All cloud apps**, and then exclude applications that you don't want the policy to apply to. This ensures you don't need to update Conditional Access policies every time you onboard a new application.

-> [!IMPORTANT]

-### Set up report-only mode

-It can be difficult to predict the number and names of users affected by common deployment initiatives such as:

-* Blocking legacy authentication

-* Requiring MFA

-* Implementing sign-in risk policies

-[Report-only mode ](concept-conditional-access-report-only.md) allows administrators to evaluate the impact of Conditional Access policies before enabling them in their environment. **First configure your policies in report-only mode and let it run for an interval before enforcing it in your environment**.

-If you rely on a single access control such as MFA or a network location to secure your IT systems, you're susceptible to access failures if that single access control becomes unavailable or misconfigured.

-**To reduce the risk of lockout during unforeseen disruptions, [plan strategies](../authentication/concept-resilient-controls.md) to adopt for your organization**.

-

-**Example**; A policy to require MFA for marketing users accessing the Dynamics CRP app from external networks might be:

-

-**Example**

-The following name indicates that this policy is the first of four policies to enable if there's an MFA disruption:

-## Deploy Conditional Access policy

-When new policies are ready, deploy your Conditional Access policies in phases.

-### Build your Conditional Access policy

-Refer to common [Conditional Access policies](concept-conditional-access-policy-common.md) for a head start. A convenient way will be to use the Conditional Access template that comes with Microsoft recommendations. Make sure you exclude your emergency access accounts.

-### Evaluate the policy impact

-Before you see the impact of your Conditional Access policy in your production environment, we recommend that you use the following two tools to run the simulation.

-#### Set up report-only mode

-By default, each policy is created in report-only mode, we recommended organizations test and monitor usage, to ensure intended result, before turning on each policy.

-[Enable the policy in report-only mode](howto-conditional-access-insights-reporting.md). Once you save the policy in report-only mode, you can see the impact on real-time sign-ins in the sign-in logs. From the sign-in logs, select an event and navigate to the Report-only tab to see the result of each report-only policy.

-You can view the aggregate impact of your Conditional Access policies in the Insights and Reporting workbook. To access the workbook, you need an Azure Monitor subscription and you'll need to [stream your sign-in logs to a log analytics workspace](../reports-monitoring/howto-integrate-activity-logs-with-log-analytics.md) .

-#### Simulate sign-ins using the What If tool

-Another way to validate your Conditional Access policy is by using the [What If tool](troubleshoot-conditional-access-what-if.md), which simulates which policies would apply to a user signing in under hypothetical circumstances. Select the sign-in attributes you want to test (such as user, application, device platform, and location) and see which policies would apply.

-> [!NOTE]

-> While a simulated run gives you a good idea of the impact a Conditional Access policy has, it does not replace an actual test run.

-### Test your policy

-Perform each test in your test plan with test users. The test plan is important to have a comparison between the expected results and the actual results. The following table outlines example test cases. Adjust the scenarios and expected results based on how your Conditional Access policies are configured.

-| Policy| Scenario| Expected Result |

-| - | - | - |

-| [Risky sign-ins](../identity-protection/howto-identity-protection-configure-risk-policies.md)| User signs into App using an unapproved browser| Calculates a risk score based on the probability that the sign-in wasn't performed by the user. Requires user to self-remediate using MFA |

-| [Device management](require-managed-devices.md)| Authorized user attempts to sign in from an authorized device| Access granted |

-| [Device management](require-managed-devices.md)| Authorized user attempts to sign in from an unauthorized device| Access blocked |

-| [Password change for risky users](../identity-protection/howto-identity-protection-configure-risk-policies.md)| Authorized user attempts to sign in with compromised credentials (high risk sign in)| User is prompted to change password or access is blocked based on your policy |

-After confirming impact using **report-only mode**, an administrator can move the **Enable policy** toggle from **Report-only** to **On**.

-### Roll back policies

- 

- 

-> [!NOTE]

-> This option should be used sparingly, only in situations where the user is trusted. The user should be added back into the policy or group as soon as possible.

-* **Delete the policy.** If the policy is no longer required, [delete](../authentication/tutorial-enable-azure-mfa.md?bc=%2fazure%2factive-directory%2fconditional-access%2fbreadcrumb%2ftoc.json&toc=%2fazure%2factive-directory%2fconditional-access%2ftoc.json) it.

-## Troubleshoot Conditional Access policy

-When a user is having an issue with a Conditional Access policy, collect the following information to facilitate troubleshooting.

-* Correlation ID (this is unique to the sign-in)

-

-Workbooks are a set of queries that collect and visualize information that is available in Azure Active Directory (Azure AD) logs. [Learn more about the sign-in logs schema here](../reports-monitoring/reference-azure-monitor-sign-ins-log-schema.md). The Sign-ins workbook in the Azure AD admin portal now has a table to assist you in determining which applications use ADAL and how often they are used. First, weΓÇÖll detail how to access the workbook before showing the visualization for the list of applications.

- :::image type="content" source="media/howto-get-list-of-all-active-directory-auth-library-apps/sign-in-workbook.png" alt-text="Screenshot of the Azure Active Directory portal workbooks interface highlighting the sign-ins workbook.":::

-> | Blazor | Blazor Server Series <br/> &#8226; [Sign in users](https://github.com/Azure-Samples/ms-identity-blazor-server/tree/main/WebApp-OIDC/MyOrg) <br/> &#8226; [Sign in users (B2C)](https://github.com/Azure-Samples/ms-identity-blazor-server/tree/main/WebApp-OIDC/B2C) <br/> &#8226; [Call Microsoft Graph](https://github.com/Azure-Samples/ms-identity-blazor-server/tree/main/WebApp-graph-user/Call-MSGraph) <br/> &#8226; [Call web API](https://github.com/Azure-Samples/ms-identity-blazor-server/tree/main/WebApp-your-API/MyOrg) <br/> &#8226; [Call web API (B2C)](https://github.com/Azure-Samples/ms-identity-blazor-server/tree/main/WebApp-your-API/B2C) | MSAL.NET | Authorization code Grant Flow|

-When registering an application with the Microsoft identity platform for developers, you're asked to select which account types your application supports. In the application object and manifest, this property is `signInAudience`.

-The options include the following values:

-For registered applications, you can find the value for supported account types on the **Authentication** section of an application. You can also find it under the `signInAudience` property in the **Manifest**.

-The value you select for this property has implications on other app object properties. As a result, if you change this property you may need to change other properties first.

- 1. Sign in to the [Azure AD Portal](https://aad.portal.azure.com) using a user account in your organization's primary tenant.

- 2. Navigate to [Role Management](https://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RolesAndAdministrators).

-1. Sign in to [Azure AD admin center](https://aad.portal.azure.com/).

-1. Select **Azure Active Directory** > **Users** > **All users**.

-**Potential issue**: The field for **SettingsUrl** is empty and the device doesn't sync. The user may have last logged in to the device before Enterprise State Roaming was enabled in the Azure Active Directory Portal. Restart the device and have the user login. Optionally, in the portal, try having the IT Admin navigate to **Azure Active Directory** > **Devices** > **Enterprise State Roaming** disable and re-enable **Users may sync settings and app data across devices**. Once re-enabled, restart the device and have the user login. If this doesn't resolve the issue, **SettingsUrl** may be empty if there's a bad device certificate. In this case, running ΓÇ£*dsregcmd.exe /leave*ΓÇ¥ in an elevated command prompt window, rebooting, and trying registration again may help with this issue.

-**Potential issue**: If your device is configured to require Multifactor Authentication on the Azure Active Directory portal, you may fail to sync settings while signing in to a Windows 10 or newer device using a password. This type of Multifactor Authentication configuration is intended to protect an Azure administrator account. Admin users may still be able to sync by signing in to their Windows 10 or newer devices with their Windows Hello for Business PIN or by completing Multifactor Authentication while accessing other Azure services like Microsoft 365.

-* If you have multiple verified domain names (as shown in the Azure AD portal or via the **Get-MsolDomain** cmdlet), set the value of **$multipleVerifiedDomainNames** in the script to **$true**. Also make sure that you remove any existing **issuerid** claim that might have been created by Azure AD Connect or via other means. Here's an example for this rule:

-There are two types of delegated administration relationships that are visible in the Azure AD admin portal experience. The newer type of delegated admin relationship is known as Granular Delegated Admin Permission. The older type of relationship is known as Delegated Admin Permission. You can see both types of relationship if you sign in to the Azure AD admin portal and then select **Delegated administration**.

-If you have any GDAP relationships in your tenant, you will see a notification banner on the **Delegated Administration** page in the Azure AD admin portal. Select the notification banner to see and manage GDAP relationships in the **Partners** page in Microsoft Admin Center.

-If you have any DAP relationships in your tenant, you will see them in the list on the Delegated Administration page in the Azure AD admin portal. To remove a DAP relationship for a CSP, follow the link to the Partners page in the Microsoft Admin Center.

-1. Sign in to the [Azure AD admin center](https://aad.portal.azure.com) with an account that is the global administrator for your organization.

-1. After you've deleted a subscription in your organization and 72 hours have elapsed, sign in to the Azure AD admin center again. Confirm that no required actions or subscriptions are blocking your organization deletion. You should be able to successfully delete your Azure AD organization.

-You can put a self-service sign-up product like Microsoft Power BI or Azure RMS into a **Delete** state to be immediately deleted in the Azure AD portal:

-1. Sign in to the [Azure AD admin center](https://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview) with an account that is a global administrator in the organization. If you're trying to delete the Contoso organization that has the initial default domain `contoso.onmicrosoft.com`, sign in with a UPN such as `admin@contoso.onmicrosoft.com`.

-1. After you've deleted all the products, sign in to the Azure AD admin center again. Confirm that no required actions or products are blocking your organization deletion. You should be able to successfully delete your Azure AD organization.

-6. Sign in to the [Azure AD admin center](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview) with an account that is the Global Administrator for the Azure AD organization.

-> [!Note]

-You can **ForceDelete** a domain name in the [Azure AD Admin Center](https://aad.portal.azure.com) or using [Microsoft Graph API](/graph/api/domain-forcedelete). These options use an asynchronous operation and update all references from the custom domain name like ΓÇ£user@contoso.comΓÇ¥ to the initial default domain name such as ΓÇ£user@contoso.onmicrosoft.com.ΓÇ¥

-In the Azure AD portal, when the parent domain is federated and the admin tries to verify a managed subdomain on the **Custom domain names** page, you'll get a 'Failed to add domain' error with the reason "One or more properties contains invalid values." If you try to add this subdomain from the Microsoft 365 admin center, you will receive a similar error. For more information about the error, see [A child domain doesn't inherit parent domain changes in Office 365, Azure, or Intune](/office365/troubleshoot/administration/child-domain-fails-inherit-parent-domain-changes).

-1. Sign in to the [Azure AD admin center](https://aad.portal.azure.com).

-1. Select **Groups**, and then select **New group**.

-1. Sign in to the [Azure AD admin center](https://aad.portal.azure.com) with a Groups admin account, or as a group owner.

-1. Select **Groups**.

-1. Sign in to the [Azure AD admin center](https://aad.portal.azure.com) with a Global Administrator or Groups admin account, or as a group owner.

-1. Select **Groups**.

-1. Sign in to the [Azure AD admin center](https://aad.portal.azure.com) with a Global or Group administrator account or as group owner.

-1. Select **Groups**.

-description: Add group members in bulk in the Azure Active Directory admin center.

-description: Learn how to convert existing groups from static to dynamic membership using either Azure AD Admin center or PowerShell cmdlets.

-You can change a group's membership from static to dynamic (or vice-versa) In Azure Active Directory (Azure AD), part of Microsoft Entra. Azure AD keeps the same group name and ID in the system, so all existing references to the group are still valid. If you create a new group instead, you would need to update those references. Dynamic group membership eliminates management overhead adding and removing users. This article tells you how to convert existing groups from static to dynamic membership using either Azure AD Admin center or PowerShell cmdlets.

-1. Sign in to the [Azure AD admin center](https://aad.portal.azure.com) with an account that is a global administrator, user administrator, or groups administrator in your Azure AD organization.

-2. Select **Groups**.

-1. Sign in to the [Azure AD admin center](https://aad.portal.azure.com) with an account that is in the Global administrator, Intune administrator, or User administrator role in the Azure AD organization.

-1. Search for and select **Groups**.

-1. Sign in to the [Azure AD admin center](https://aad.portal.azure.com) with an account that is in the Global administrator, Group administrator, Intune administrator, or User administrator role in the Azure AD organization.

-1. Select **Groups** > **All groups**.

-This feature can be used in the Azure AD portal, Microsoft Graph, and in PowerShell. Because memberOf isn't yet supported in the rule builder, you must enter your rule in the rule editor.

-1. Open the [Azure AD admin center](https://aad.portal.azure.com) with an account that is a global administrator in your Azure AD organization.

-2. Select **Groups**, then select **Expiration** to open the expiration settings.

-1. Sign in to the [Azure AD admin center](https://aad.portal.azure.com) with a Group Administrator account.

-1. Select **Groups**, then select **Naming policy** to open the Naming policy page.

-Azure Active Directory portals | The Azure AD portal and the Access Panel portal show the naming policy enforced name when the user types in a group name when creating or editing a group. When a user enters a custom blocked word, an error message with the blocked word is displayed so that the user can remove it.

-1. Sign in to the [Azure AD admin center](https://aad.portal.azure.com) with a User administrator account.

-1. Select **Groups**, then select **Naming policy** to open the Naming policy page.

-1. Sign in to the [Azure AD admin center](https://aad.portal.azure.com) with a User administrator account.

-2. Select **Groups**, then select **Deleted groups** to view the deleted groups that are available to restore.

-1. In the [Azure AD admin center](https://aad.portal.azure.com), select **Enterprise applications**.

-2. Select an application that you added from the Application Gallery to open it.

-3. Select **Users and groups**, and then select **Add user**.

-4. On **Add Assignment**, select **Users and groups** to open the **Users and groups** selection list.

-6. Select as many groups or users as you want, then click or tap **Select** to add them to the **Add Assignment** list. You can also assign a role to a user at this stage.

-7. Select **Assign** to assign the users or groups to the selected enterprise application.

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com) with an account that's been assigned the Global Administrator or Groups Administrator role for the directory.

-1. Select **Groups**, and then select **General** settings.

-description: The access points for group writeback to on-premises Active Directory in the Azure Active Directory admin center.

-# Group writeback in the Azure Active Directory admin center (preview)

-Group writeback is a valuable tool for administrators of Azure Active Directory (Azure AD) tenants being synced with on-premises Active Directory groups. Microsoft is now previewing new capabilities for group writeback for tenants with an Azure AD Premium license and Azure AD Connect version 2021 December release or later. In this preview, once you have [enabled Azure AD Connect group writeback](..//hybrid/how-to-connect-group-writeback-v2.md), you can specify in the Azure AD admin center which groups you want to write back and what youΓÇÖd like each group to write back as. You can write Microsoft 365 groups back to on-premises Active Directory as Distribution, Mail-enabled Security, or Security groups, and write Security groups back as Security groups. Groups are written back with a scope of universalΓÇï.

-1. Sign in to the [**Azure AD admin center**](https://aad.portal.azure.com) with a license administrator account. To manage licenses, the account must be a license administrator, user administrator, or global administrator.

-1. Select **Licenses** to open a page where you can see and manage all licensable products in the organization.

-You can allow users in your organization to access their LinkedIn connections within some Microsoft apps. No data is shared until users consent to connect their accounts. You can integrate your organization in the [admin center](https://aad.portal.azure.com) for Azure Active Directory (Azure AD), part of Microsoft Entra.

-1. Sign in to the [Azure AD admin center](https://aad.portal.azure.com/) with an account that's a Global Administrator for the Azure AD organization.

-1. Select **Users**.

-1. Use the group from the previous as the selected group in the LinkedIn account connections setting in the Azure AD admin center.

-To use the group from step two as the selected group in the LinkedIn account connections setting in the Azure AD admin center, see [Enable LinkedIn account connections in the Azure portal](#enable-linkedin-account-connections-in-the-azure-portal).

-* [View your current LinkedIn integration setting in the Azure portal](https://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/UserManagementMenuBlade/UserSettings)

-description: Add users in bulk in the Azure AD admin center in Azure Active Directory

-Azure Active Directory (Azure AD), part of Microsoft Entra, supports bulk user create and delete operations and supports downloading lists of users. Just fill out comma-separated values (CSV) template you can download from the Azure AD portal.

-1. [Sign in to your Azure AD organization](https://aad.portal.azure.com) with an account that is a User administrator in the organization.

-1. In Azure AD, select **Users** > **Bulk create**.

-1. [Sign in to the Azure AD admin center](https://aad.portal.azure.com) with an account that is a User administrator in the organization.

-1. In the navigation pane, select **Azure Active Directory**.

-1. Under **Manage**, select **Users**.

-1. [Sign in to your Azure AD organization](https://aad.portal.azure.com) with an account that is a User administrator in the organization.

-1. In Azure AD, select **Users** > **Bulk operations** > **Bulk delete**.

-# Download a list of users in Azure Active Directory portal

-1. [Sign in to your Azure AD organization](https://aad.portal.azure.com).

-description: Restore deleted users in bulk in the Azure AD admin center in Azure Active Directory

-1. [Sign in to your Azure AD organization](https://aad.portal.azure.com) with an account that is a User administrator in the Azure AD organization.

-1. In Azure AD, select **Users** > **Deleted**.

-1. [Sign in to the Azure AD admin center](https://aad.portal.azure.com) with an account that is a User administrator in the organization.

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure AD admin center](https://aad.portal.azure.com) with Global administrator permissions.

-1. On the **Azure Active Directory** overview page for your organization, select **User settings**.

-There are many ways you can invite external partners to your apps and services with Azure Active Directory B2B collaboration. In the previous quickstart, you saw how to add guest users directly in the Azure Active Directory admin portal. You can also use PowerShell to add guest users, either one at a time or in bulk. In this quickstart, youΓÇÖll use the New-MgInvitation command to add one guest user to your Azure tenant.

-Next, you'll [configure SAML/WS-Fed IdP federation in Azure AD](direct-federation.md#step-3-configure-samlws-fed-idp-federation-in-azure-ad) either in the Azure AD portal or by using the Microsoft Graph API.

-Next, you'll configure federation with the IdP configured in step 1 in Azure AD. You can use either the Azure AD portal or the [Microsoft Graph API](/graph/api/resources/samlorwsfedexternaldomainfederation?view=graph-rest-beta&preserve-view=true). It might take 5-10 minutes before the federation policy takes effect. During this time, don't attempt to redeem an invitation for the federation domain. The following attributes are required:

-### To configure federation in the Azure AD portal

-To remove a configuration for an IdP in the Azure AD portal:

-Now you'll set the Facebook client ID and client secret, either by entering it in the Azure AD portal or by using PowerShell. You can test your Facebook configuration by signing up via a user flow on an app enabled for self-service sign-up.

-### To configure Facebook federation in the Azure AD portal

-### To delete Facebook federation in the Azure AD portal:

-**To delete Google federation in the Azure AD portal**

-## Easily invite guest users from the Azure AD portal

-| Where the group is created| Azure AD portal<br>Microsoft 365 portal, if mail-enabled)<br>PowerShell<br>Microsoft Graph<br>End user portal| Microsoft 365 portal<br>Azure AD portal<br>PowerShell<br>Microsoft Graph<br>In Microsoft 365 applications |

-To create a mail-enabled security group, go to the [Microsoft 365 admin center](https://admin.microsoft.com/). Enable a security group for mail during creation. You canΓÇÖt enable it later. You can't create the group in the Azure AD portal.

-* [Azure Active Directory admin center](https://aad.portal.azure.com/)

-1. Go to the Azure Active Directory admin center.

-2. Select **All Services**.

-3. Under **Categories**, select **Identity**.

-4. From the list, select **External Identities**.

-5. Select **External collaboration settings**.

-6. Find the **Guest user access** options.

-7. To prevent guest-user access to other guest-user details, and to prevent enumeration of group membership, select **Guest users have limited access to properties and memberships of directory objects**.

-In the Azure AD admin center, you can use the External Sharing settings for SharePoint and OneDrive to help configure sharing policies. OneDrive restrictions can't be more permissive than SharePoint settings.

-# Add your custom domain name using the Azure Active Directory portal

- The domain part of the user name must use either the initial default domain name, *\<yourdomainname>.onmicrosoft.com*, or a custom domain name, such as *contoso.com*. For more information about how to create a custom domain name, see [Add your custom domain name using the Azure Active Directory portal](add-custom-domain.md).

-You can delete an existing user using Azure Active Directory portal.

-Some groups can't be managed in the Azure AD portal:

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-# Assign or remove licenses in the Azure Active Directory portal

-* An administrator intentionally deletes a user in the Azure AD portal in response to a request or as part of routine user maintenance.

-User settings changes are made on the Azure AD portal **User settings** page. Password reset changes are made on the **Password reset** page. Changes made on these pages are captured in the Audit log as detailed in the following table.

-You can make changes to these settings on the **External identities** or **External collaboration** settings pages in the Azure AD portal.

-Users, Microsoft 365 Groups, and applications can be soft deleted. Soft-deleted items are sent to the Azure AD recycle bin. While in the recycle bin, items aren't available for use. However, they retain all their properties and can be restored via a Microsoft Graph API call or in the Azure AD portal. Items in the soft-delete state that aren't restored within 30 days are permanently, or hard, deleted.

-**Auditing**. Auditing provides traceability through logs for all changes done by specific features within Azure AD. Examples of activities found in audit logs include changes made to any resources within Azure AD like adding or removing users, apps, groups, roles, and policies. Reporting in Azure AD enables you to audit sign-in activities, risky sign-ins, and users flagged for risk. For more information, see [Audit activity reports in the Azure Active Directory portal](../reports-monitoring/concept-audit-logs.md).

-**Role-based Access Control (RBAC)**: Two RBAC roles are available to provide the appropriate level of access to these virtual machines. These RBAC roles can be configured via the Azure AD Portal or via the Azure Cloud Shell Experience. For more information, see [Configure role assignments for the VM](../devices/howto-vm-sign-in-azure-ad-windows.md).

- * [Audit activity reports in the Azure Active Directory portal](../reports-monitoring/concept-audit-logs.md)

-* Azure AD Sign-In Logs in the Azure AD portal

-Azure Service Health supports service outage notifications to Tenant Admins for Azure Active Directory issues. These outages will also appear on the Azure AD Admin Portal Overview page with appropriate links to Azure Service Health. Outage events will be able to be seen by built-in Tenant Administrator Roles. We'll continue to send outage notifications to subscriptions within a tenant for transition. More information is available at: [What are Service Health notifications in Azure Active Directory?](../reports-monitoring/overview-service-health-notifications.md).

-### Public Preview - New Azure AD Portal All Devices list

-We're enhancing the All Devices list in the Azure AD Portal to make it easier to filter and manage your devices. Improvements include:

-### Public Preview - New Azure AD Portal All Users list and User Profile UI

-We're enhancing the All Users list and User Profile in the Azure AD Portal to make it easier to find and manage your users. Improvements include:

-Azure Service Health will soon support service outage notifications to Tenant Admins for Azure Active Directory issues soon. These outages will also appear on the Azure AD admin portal overview page with appropriate links to Azure Service Health. Outage events will be able to be seen by built-in Tenant Administrator Roles. We'll continue to send outage notifications to subscriptions within a tenant for transition. More information will be available when this capability is released. The expected release is for June 2022.

-The Azure AD portal has been updated to make it easier to find users in the All users and Deleted users pages. Changes in the preview include:

-10 Azure AD built-in roles have been renamed so that they're aligned across the [Microsoft 365 admin center](/microsoft-365/admin/microsoft-365-admin-center-preview), [Azure AD portal](https://portal.azure.com/), and [Microsoft Graph](https://developer.microsoft.com/graph/). To learn more about the new roles, refer to [Administrator role permissions in Azure Active Directory](../roles/permissions-reference.md#all-roles).

-Customers can download the provisioning logs as a CSV or JSON file through the UI and via graph API. To learn more, refer to [Provisioning reports in the Azure Active Directory portal](../reports-monitoring/concept-provisioning-logs.md).

-Some Azure Active Directory (AD) built-in roles have names that differ from those that appear in Microsoft 365 admin center, the Azure AD portal, and Microsoft Graph. This inconsistency can cause problems in automated processes. With this update, we're renaming 10 role names to make them consistent. The following table has the new role names:

-End users can [access their recovery keys via My Account](https://support.microsoft.com/account-billing/manage-your-work-or-school-account-connected-devices-from-the-devices-page-6b5a735d-0a7f-4e94-8cfd-f5da6bc13d4e#view-a-bitlocker-key). IT admins can access recovery keys via the [BitLocker recovery key API](/graph/api/resources/bitlockerrecoverykey) or via the Azure AD Portal. To learn more, see [View or copy BitLocker keys in the Azure AD Portal](../devices/device-management-azure-portal.md#view-or-copy-bitlocker-keys).

-The Azure AD portal has been updated to make it easier to find users in the All users and Deleted users pages. Changes in the preview include:

-You can now view role assignments across all scopes for a role in the "Roles and administrators" tab in the Azure AD portal. You can also download those role assignments for each role into a CSV file. For guidance on viewing and adding role assignments, see [View and assign administrator roles in Azure Active Directory](../roles/manage-roles-portal.md).

-### Bulk activity and downloads in the Azure AD admin portal experience

-Now you can perform bulk activities on users and groups in Azure AD by uploading a CSV file in the Azure AD admin portal experience. You can create users, delete users, and invite guest users. And you can add and remove members from a group.

-You can also download lists of Azure AD resources from the Azure AD admin portal experience. You can download the list of users in the directory, the list of groups in the directory, and the members of a particular group.

-To require users to re-register, you can select the **Required re-register multifactor authentication (MFA)** option from the user's authentication methods in the Azure AD portal.

-### Consolidated Security menu item in the Azure AD portal

-### Bulk manage groups and members using CSV files in the Azure AD portal (Public Preview)

-We're pleased to announce public preview availability of the bulk group management experiences in the Azure AD portal. You can now use a CSV file and the Azure AD portal to manage groups and member lists, including:

-The Global Reader role works with the new Microsoft 365 Admin Center, Exchange Admin Center, Teams Admin Center, Security Center, Compliance Center, Azure AD Admin Center, and the Device Management Admin Center.

-### Enhanced search, filtering, and sorting for groups is available in the Azure AD portal (Public Preview)

-We're pleased to announce public preview availability of the enhanced groups-related experiences in the Azure AD portal. These enhancements help you better manage groups and member lists, by providing:

-For more information, see [Provisioning reports in the Azure Active Directory portal (preview)](../reports-monitoring/concept-provisioning-logs.md).

-### New check for duplicate group names in the Azure AD portal

-Now, when you create or update a group name from the Azure AD portal, we'll perform a check to see if you are duplicating an existing group name in your resource. If we determine that the name is already in use by another group, you'll be asked to modify your name.

-For more information, see [Manage groups in the Azure AD portal](./active-directory-groups-create-azure-portal.md?context=azure%2factive-directory%2fusers-groups-roles%2fcontext%2fugr-context).

-For more information about this feature, see [Usage and insights report in the Azure Active Directory portal](../reports-monitoring/concept-usage-insights-report.md)

-### Improved groups creation and management experiences in the Azure AD portal

-We've made improvements to the groups-related experiences in the Azure AD portal. These improvements allow administrators to better manage groups lists, members lists, and to provide additional creation options.

-### Configure a naming policy for Office 365 groups in Azure AD portal (General availability)

-Administrators can now configure a naming policy for Office 365 groups, using the Azure AD portal. This change helps to enforce consistent naming conventions for Office 365 groups created or edited by users in your organization.

-### Configure a naming policy for Office 365 groups in Azure AD portal (Public preview)

-Administrators can now configure a naming policy for Office 365 groups, using the Azure AD portal. This change helps to enforce consistent naming conventions for Office 365 groups created or edited by users in your organization.

-### Restore and manage your deleted Office 365 groups in the Azure AD portal

-You can now view and manage your deleted Office 365 groups from the Azure AD portal. This change helps you to see which groups are available to restore, along with letting you permanently delete any groups that aren't needed by your organization.

-For more information about the new **Audit logs** page, see [Audit activity reports in the Azure Active Directory portal](../reports-monitoring/concept-audit-logs.md).

-### Azure AD portal supports using the ForceDelete domain API to delete custom domains

-### Application access (preview) provides faster access to the Azure AD portal

-Today, when activating a role using PIM, it can take over 10 minutes for the permissions to take effect. If you choose to use Application access, which is currently in public preview, administrators can access the Azure AD portal as soon as the activation request completes.

-Currently, Application access only supports the Azure AD portal experience and Azure resources. For more information about PIM and Application access, see [What is Azure AD Privileged Identity Management?](../privileged-identity-management/pim-configure.md)

-With the introduction of the **Client App** field in the Sign-in activity logs, customers can now see users that are using legacy authentications. Customers will be able to access this information using the Sign-ins Microsoft Graph API or through the Sign-in activity logs in Azure AD portal where you can use the **Client App** control to filter on legacy authentications. Check out the documentation for more details.

-We've updated the Azure AD Admin center to support this functionality. Now, customers can convert existing groups from dynamic membership to assigned membership and vice-versa. The existing PowerShell cmdlets are also still available.

-As of January 8, 2018, the Azure AD administration experience in the Azure classic portal has been retired. This took place in conjunction with the retirement of the Azure classic portal itself. In the future, you should use the [Azure AD admin center](https://aad.portal.azure.com) for all your portal-based administration of Azure AD.

-The new Device Overview in the Azure Active Directory portal provides meaningful and actionable insights about devices in your tenant.

-For more information about licenses, see [Assign or remove licenses using the Azure Active Directory portal](../fundamentals/license-users-groups.md).

-1. For Logic Apps authorization policy, we'll need the managed identities **Application ID**. Since the Azure portal only shows the Object ID, we need to look up the Application ID. You can search for the managed identity by Object ID under **Enterprise Applications in the Azure AD Portal** to find the required Application ID.

-* Groups created manually in the Azure AD portal or via scripting through Microsoft Graph might not necessarily have owners defined. Define them either through the Azure AD portal in the group's **Owners** section or via Microsoft Graph.

-1. Set the group to be written back to on-premises Active Directory. For instructions, see [Group writeback in the Azure Active Directory admin center](../enterprise-users/groups-write-back-portal.md).

-For more information about licenses, see [Assign or remove licenses using the Azure Active Directory portal](../fundamentals/license-users-groups.md).

-> The next stage of the review won't become active until the duration specified during the access review setup has passed. If the administrator believes a stage is done but the review duration for this stage has not expired yet, they can use the **Stop current stage** button in the overview of the access review in the Azure AD portal. This action will close the active stage and start the next stage.

-|Is there a health monitoring solution?|Not required|Agent status provided by [Azure Active Directory admin center](../../active-directory/hybrid/tshoot-connect-pass-through-authentication.md)|[Azure AD Connect Health](../../active-directory/hybrid/how-to-connect-health-adfs.md)|

-If you have successfully added a new domain in the Azure AD portal and then attempt to convert it using `Convert-MsolDomaintoFederated -DomainName <your domain>`, you will get the following error.

- | **8080** (optional) | Authentication Agents report their status every ten minutes over port 8080, if port 443 is unavailable. This status is displayed on the Azure AD portal. Port 8080 is _not_ used for user sign-ins. |

-1. Sign in to the [Azure Active Directory admin center](https://aad.portal.azure.com) with the Global Administrator credentials for your tenant.

-

-3. **Download the latest version of the Authentication Agent (versions 1.5.2482.0 or later)**: Sign in to the [Azure Active Directory admin center](https://aad.portal.azure.com) with your tenant's Global Administrator credentials. Select **Azure Active Directory -> Azure AD Connect -> Pass-through Authentication -> Download agent**. Accept the [terms of service](https://aka.ms/authagenteula) and download the latest version of the Authentication Agent. You can also download the Authentication Agent from [here](https://aka.ms/getauthagent).

->[!NOTE]

->If you check the Pass-through Authentication blade on the [Azure Active Directory admin center](https://aad.portal.azure.com) after completing the preceding steps, you'll see two Authentication Agent entries per server - one entry showing the Authentication Agent as **Active** and the other as **Inactive**. This is _expected_. The **Inactive** entry is automatically dropped after a few days.

-2. **Download the latest version of the Authentication Agent (versions 1.5.2482.0 or later)**: Sign in to the [Azure Active Directory admin center](https://aad.portal.azure.com) with your tenant's Global Administrator credentials. Select **Azure Active Directory -> Azure AD Connect -> Pass-through Authentication -> Download agent**. Accept the terms of service and download the latest version.

->[!NOTE]

->If you check the Pass-through Authentication blade on the [Azure Active Directory admin center](https://aad.portal.azure.com) after completing the preceding steps, you'll see two Authentication Agent entries per server - one entry showing the Authentication Agent as **Active** and the other as **Inactive**. This is _expected_. The **Inactive** entry is automatically dropped after a few days.

-1. Sign in to the [Azure Active Directory administrative center](https://aad.portal.azure.com) with the Hybrid Identity Administrator account credentials for your tenant.

-In Active Directory, the default UPN suffix is the domain DNS name where you created the user account. In most cases, you register this domain name as the enterprise domain. If you create the user account in the contoso.com domain, the default UPN is: username@contoso.com. However, you can add more UPN suffixes by using Active Directory domains and trusts. Learn more: [Add your custom domain name using the Azure Active Directory portal](../fundamentals/add-custom-domain.md).

- > [Add your custom domain name using the Azure Active Directory portal](../fundamentals/add-custom-domain.md)

-Sign in to the [Azure AD portal](https://aad.portal.azure.com/), select **Azure AD Connect** and verify the **USER SIGN_IN** settings as shown in this diagram:

-1. In the Azure AD portal, select **Azure Active Directory**, and then select **Azure AD Connect**.

-1. In the Azure AD portal, select **Azure Active Directory**, and then select **Azure AD Connect**.

-1. In the Azure AD portal, select **Azure Active Directory**, and then select **Azure AD Connect**.

-3. In the Azure AD portal, select **Azure Active Directory > Azure AD Connect**.

-### Sign-in failure reasons on the Azure Active Directory admin center (needs Premium license)

-Navigate to **Azure Active Directory** -> **Sign-ins** on the [Azure Active Directory admin center](https://aad.portal.azure.com/) and click a specific user's sign-in activity. Look for the **SIGN-IN ERROR CODE** field. Map the value of that field to a failure reason and resolution using the following table:

-Ensure that the Seamless SSO feature is still **Enabled** on your tenant. You can check the status by going to the **Azure AD Connect** pane in the [Azure Active Directory admin center](https://aad.portal.azure.com/).

-

-

-## Sign-in failure reasons in the Azure Active Directory admin center (needs a Premium license)

-If your tenant has an Azure AD Premium license associated with it, you can also look at the [sign-in activity report](../reports-monitoring/concept-sign-ins.md) in the [Azure Active Directory admin center](https://aad.portal.azure.com/).

-

-Browse to **Azure Active Directory** > **Sign-ins** in the [Azure Active Directory admin center](https://aad.portal.azure.com/), and then select a specific user's sign-in activity. Look for the **SIGN-IN ERROR CODE** field. Map the value of that field to a failure reason and resolution by using the following table:

-1. In the [Azure portal](https://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview), be sure to close the **All users** pane.

-1. In the [Azure portal](https://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview), be sure to close the **All users** pane.

-If password reset isn't an option for you from the Azure AD portal, you can choose to manually dismiss user risk. Dismissing user risk doesn't have any impact on the user's existing password, but this process will change the user's Risk State from At Risk to Dismissed. It's important that you change the user's password using whatever means are available to you in order to bring the identity back to a safe state.

- 1. Under **Assignments**

- 1. **Users** - Choose **All users** or **Select individuals and groups** if limiting your rollout.

- 1. Optionally you can choose to exclude users or groups from the policy.

-Identity Protection uses the learnings Microsoft has acquired from their position in organizations with Azure Active Directory, the consumer space with Microsoft Accounts, and in gaming with Xbox to protect your users. Microsoft analyses trillions of signals per day to identify and protect customers from threats. Identity Protection allows organizations to accomplish three key tasks:

-In this quickstart, you use the Azure Active Directory Admin Center to create a user account in your Azure Active Directory (Azure AD) tenant. After you create the account, you can assign it to the enterprise application that you added to your tenant.

-1. Go to the [Azure Active Directory Admin Center](https://aad.portal.azure.com) and sign in using one of the roles listed in the prerequisites.

-1. In the left menu, select **Users**.

-1. In the [Azure Active Directory Admin Center](https://aad.portal.azure.com), select **Enterprise applications**, and then search for and select the application to which you want to assign the user account. For example, the application that you created in the previous quickstart named **Azure AD SAML Toolkit 1**.

-1. Go to the [Azure Active Directory Admin Center](https://aad.portal.azure.com) and sign in using one of the roles listed in the prerequisites.

-1. In the left menu, select **Enterprise applications**. The **All applications** pane opens and displays a list of the applications in your Azure AD tenant. Search for and select the application that you want to use.

-1. Go to the [Azure Active Directory Admin Center](https://aad.portal.azure.com) and sign in using one of the roles listed in the prerequisites.

-1. In the left menu, select **Enterprise applications**. The **All applications** pane opens and displays a list of the applications in your Azure AD tenant.

-In this article, you use the Azure Active Directory Admin Center to enable single sign-on (SSO) for an enterprise application that you added to your Azure Active Directory (Azure AD) tenant. After you configure SSO, your users can sign in by using their Azure AD credentials.

-1. Go to the [Azure Active Directory Admin Center](https://aad.portal.azure.com) and sign in using one of the roles listed in the prerequisites.

-1. In the left menu, select **Enterprise applications**. The **All applications** pane opens and displays a list of the applications in your Azure AD tenant. Search for and select the application that you want to use. For example, **Azure AD SAML Toolkit 1**.

-In this quickstart, you use the Azure Active Directory Admin Center to add an enterprise application to your Azure Active Directory (Azure AD) tenant. Azure AD has a gallery that contains thousands of enterprise applications that have been pre-integrated. Many of the applications your organization uses are probably already in the gallery. This quickstart uses the application named **Azure AD SAML Toolkit** as an example, but the concepts apply for most [enterprise applications in the gallery](../saas-apps/tutorial-list.md).

-1. Go to the [Azure Active Directory Admin Center](https://aad.portal.azure.com) and sign in using one of the roles listed in the prerequisites.

-1. In the left menu, select **Enterprise applications**. The **All applications** pane opens and displays a list of the applications in your Azure AD tenant.

- 2 - [How do I grant admin consent in the Azure AD portal](https://www.youtube.com/watch?v=LSYcelwdhHI&list=PLlrxD0HtieHiBPIyUWkqVzoMrgfwKi4dY&index=5)(1:19)

- - **Azure AD - Enterprise applications** ΓÇô Apps added to your tenant using the **Enterprise applications** option on the Azure AD portal. Usually apps integrated using the SAML standard.

- - **Azure AD - App registrations** ΓÇô Apps added to your tenant using the **App registrations** option on the Azure AD portal. Usually custom developed apps using the Open ID Connect and OAuth standards.

-These applications are configured on behalf of the user in the Azure AD portal. The application must be configured properly and assigned to the user or a group the user is a member of to see the application in My Apps.

-1. In the [Azure Active Directory Admin Center](https://aad.portal.azure.com), select **Enterprise applications**, and then search for and select the application to which you want to assign the user or group account.

-1. In the left pane, select **Users and groups**, and then select **Add user/group**.

-1. In the [Azure Active Directory portal](https://aad.portal.azure.com/), sign in to your account. The **Azure Active Directory admin center** page appears.

-1. In the left pane, select **Enterprise applications**. A list of the enterprise applications in your account appears.

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure AD portal](https://portal.azure.com) and sign in using one of the roles listed in the prerequisites.

- - The [Azure AD portal](https://azure.microsoft.com/features/azure-portal/)

-1. Sign in to the Azure AD portal with application admin rights.

-1. Sign in to the [Azure AD portal](https://portal.azure.com) by using an account with Application Administrator permissions.

-1. Sign-in to the Azure AD portal using an account with application administrative rights.

-1. Sign-in to the [Azure AD portal](https://portal.azure.com/) using an account with Application Administrative rights

-1. Sign in to the [Azure AD portal](https://portal.azure.com) with Application Administrator permissions.

-1. Sign in to the [Azure AD portal](https://portal.azure.com) using an account with Application Administrative rights.

-1. Sign in to the [Azure AD portal](https://portal.azure.com/) with Application Administrative rights

-1. Sign in to the [Azure AD portal](https://portal.azure.com/) with Application Administrative rights

-1. Sign in to the [Azure AD portal](https://portal.azure.com/) with Application Administrative rights

-1. Sign-in to the [Azure AD portal](https://portal.azure.com/) using an account with Application Administrative rights

-You can access the Azure AD portal to get contextual PowerShell scripts to perform the actions.

-In this article, you learn how to enable self-service application access using the Azure Active Directory Admin Center.

-Follow the migration process detailed in this article. Then go to the [Azure portal](https://aad.portal.azure.com/) to test if the migration was a success.

-1. Select **Enterprise Applications** > **All applications** and find your app from the list.

-Once you have migrated the apps, go to the [Azure portal](https://aad.portal.azure.com/) to test if the migration was a success. Follow the instructions below:

-2. In the [Azure Active Directory admin center](https://aad.portal.azure.com), select **Azure Active Directory** > **Enterprise applications** > **+ New application**.

-7. Upload the XML file you downloaded from the Azure AD portal. Then select **Create**.

-11. To upload the file to the Azure AD portal, in the Azure AD **Enterprise applications** page, in the SAML SSO settings, select **Upload metadata file**.

-1. In the [Azure AD portal](https://aad.portal.azure.com), select **Azure Active Directory** > **Enterprise applications**.

- Configure Conditional Access policies by following [best

-practices for deploying and designing Conditional Access](../conditional-access/plan-conditional-access.md#understand-conditional-access-policy-components).

-1. Go to the [Azure AD portal](https://aad.portal.azure.com/).

-1. In the **Configuration** profile, select **Enable**.

-* **App migration** - Create a workflow to integrate apps with Azure AD without using the Azure AD portal

-* **Conditional Access** - Enable customers to apply Azure AD policies to apps in your solution without using the Azure AD portal

-> You can find your directory ID in the [Azure Active Directory portal](https://aad.portal.azure.com/). Sign in as an administrator, select **Azure Active Directory**, then select **Properties**.

-1. Sign in to the [Azure Active Directory portal](https://aad.portal.azure.com/). The **Azure Active Directory admin center** dashboard appears.

-2. In the left pane, select **Azure Active Directory**. The Azure Active Directory overview page appears.

-1. Make the new certificate active in the Azure Active Directory portal.

-1. Sign in to the [Azure Active Directory portal](https://aad.portal.azure.com/). The **Azure Active Directory admin center** page appears.

-1. Select **Enterprise applications**.

-In this quickstart, you learn how to use the Azure Active Directory Admin Center to search for and view the enterprise applications that are already configured in your Azure Active Directory (Azure AD) tenant.

-1. Go to the [Azure Active Directory Admin Center](https://aad.portal.azure.com) and sign in using one of the roles listed in the prerequisites.

-1. In the left menu, select **Enterprise applications**. The **All applications** pane opens and displays a list of the applications in your Azure AD tenant.

-1. Sign in to the [Azure portal](https://aad.portal.azure.com) with Privileged Role administrator role permissions, and open Azure AD.

-1. [Sign in to Azure AD portal](https://aad.portal.azure.com).

-1. [Sign in to Azure AD portal](https://aad.portal.azure.com).

-1. [Sign in to Azure AD portal](https://aad.portal.azure.com).

-1. [Sign in to Azure AD portal](https://aad.portal.azure.com).

-1. [Sign in to Azure AD](https://aad.portal.azure.com).

-1. [Sign in to Azure AD](https://aad.portal.azure.com) with appropriate role permissions.

-1. [Sign in to Azure AD portal](https://aad.portal.azure.com).

-1. [Sign in to Azure AD portal](https://aad.portal.azure.com).

-1. [Sign in to Azure AD](https://aad.portal.azure.com).

-1. [Sign in to Azure AD portal](https://aad.portal.azure.com).

-> To assign a PIM for Groups to a role for administrative access to Exchange, Security & Compliance Center, or SharePoint, use the Azure AD portal **Roles and Administrators** experience and not in the PIM for Groups experience to make the user or group eligible for activation into the group.

-Azure Active Directory (Azure AD) guest users are part of the business-to-business (B2B) collaboration capabilities within Azure AD so that you can manage external guest users and vendors as guests in Azure AD. For example, you can use these Privileged Identity Management features for Azure identity tasks with guests such as assigning access to specific Azure resources, specifying assignment duration and end date, or requiring two-step verification on active assignment or activation. For more information on how to invite a guest to your organization and manage their access, see [Add B2B collaboration users in the Azure AD portal](../external-identities/add-users-administrator.md).

-1. Sign in to the [Azure Active Directory admin center](https://aad.portal.azure.com) with Privileged Role Administrator permissions.

-1. [Sign in to Azure AD](https://aad.portal.azure.com/)

-1. [Sign in to Azure AD](https://aad.portal.azure.com/)

-Use the following cmdlet to retrieve all role assignments for a particular user. This list is also known as "My Roles" in the Azure AD portal. The only difference here is that you have added a filter for the subject ID. The subject ID in this context is the user ID or the group ID.

-For more information about licenses, see [Assign or remove licenses using the Azure Active Directory portal](../fundamentals/license-users-groups.md).

-description: Introduction to usage and insights report in the Azure Active Directory portal

-* The following roles in Azure Active Directory (if you're accessing Log Analytics through Azure Active Directory portal)

-2. Ensure that you have one of the following roles in Azure AD (if you're accessing the workspace through the Azure AD portal):

-1. In the Azure AD portal, go to **Sign-in logs** > **Add Filters**.

-Reviewing flagged sign-in events requires permissions to read the Sign-in Report events in the Azure AD portal. For more information, see [who can access it?](concept-sign-ins.md#how-do-you-access-the-sign-in-logs)

-1. Return Advanced Editor window on the Azure AD portal and paste the JSON file over the exiting text.

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-> The Azure AD admin portal does not yet support adding the permissions listed in this article to a custom directory role definition. You must [use Azure AD PowerShell to create a custom directory role](custom-create.md#create-a-role-using-powershell) with the permissions listed in this article.

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com) with Application Developer permissions.

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com) as a Global Administrator, User Administrator, or Group Administrator.

-You can view audit logs for actions taken in My Staff in the Azure Active Directory portal. If an audit log was generated by an action taken in My Staff, you will see this indicated under ADDITIONAL DETAILS in the audit event.

-* Granting a specific set of non-admin users access to Azure portal when "Restrict access to Azure AD portal to admins only" is set to "Yes".

-Users in this role can read settings and administrative information across Microsoft 365 services but can't take management actions. Global Reader is the read-only counterpart to Global Administrator. Assign Global Reader instead of Global Administrator for planning, audits, or investigations. Use Global Reader in combination with other limited admin roles like Exchange Administrator to make it easier to get work done without the assigning the Global Administrator role. Global Reader works with Microsoft 365 admin center, Exchange admin center, SharePoint admin center, Teams admin center, Microsoft 365 Defender portal, Microsoft Purview compliance portal, Azure AD admin center, and Device Management admin center.

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com) as an existing Global Administrator.

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com) with an account assigned to the User Administrator role.

-description: You can now see and manage members of an Azure Active Directory administrator role in the Azure Active Directory admin center.

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-1. Sign in to the [Azure portal](https://portal.azure.com) or [Azure AD admin center](https://aad.portal.azure.com).

-Akamai EAA Application is set up individually on the Azure AD Portal. Admin can configure Individual he Conditional Access policy on the Application(s) and once the conditions are satisfied users can directly be redirected to the specific application.

-* Configure Check Point Infinity Portal application user roles in Azure AD portal

-#### Configure Check Point Infinity Portal application user roles in Azure AD portal

-1. Compose a list of the Azure AD Groups you want the Descartes Application use for the Role-based configuration. A list of User Roles Descartes application modules can be found at https://www.gln.com/docs/Descartes_Application_User_Roles.pdf. You can find the Azure Active Direction Group GUIDs please download the Groups from your Azure AD Portal Groups.

- i. In the **Identity Provider Certificates** section, select **ADD CERTIFICATE**, upload the certificate you downloaded from Azure AD portal, and select **SAVE**.

-1. Sign-in to the [Azure AD portal](https://portal.azure.com/) using an account with Application Administrative rights.

-1. Sign in to the [Azure AD portal](https://portal.azure.com/) with Application Administrative rights

-1. Sign in to the [Azure AD portal](https://portal.azure.com/) with Application Administrative rights

-1. Sign-in to the [Azure AD portal](https://portal.azure.com/) using an account with Application Administrative rights

- 

-> * Remove users in G Suite when they do not require access anymore

- > These values are not real. Update these values with the actual Identifier and Reply URL. Contact [LeanDNA Client support team](mailto:it@leandna.com) to get these values. You can also refer to the patterns shown in the **Basic SAML Configuration** section in the Azure portal.

-To configure single sign-on on **LeanDNA** side, you need to send the downloaded **Federation Metadata XML** and appropriate copied URLs from Azure portal to [LeanDNA support team](mailto:it@leandna.com). They set this setting to have the SAML SSO connection set properly on both sides.

-In this section, you create a user called Britta Simon at LeanDNA. Work with [LeanDNA support team](mailto:it@leandna.com) to add the users in the LeanDNA platform. Users must be created and activated before you use single sign-on.

-In this section, you'll configure and test Azure AD SSO with MiCloud Connect or CloudLink Platform based on a test user named **_Britta Simon_**. For single sign-on to work, a link must be established between the user in Azure AD portal and the corresponding user on the Mitel platform. Refer to the following sections for information about configuring and testing Azure AD SSO with MiCloud Connect or CloudLink Platform.

-description: Learn how to configure single sign-on between Azure Active Directory and MURAL Identity.

-# Tutorial: Azure AD SSO integration with MURAL Identity

-In this tutorial, you'll learn how to integrate MURAL Identity with Azure Active Directory (Azure AD). When you integrate MURAL Identity with Azure AD, you can:

-* Control in Azure AD who has access to MURAL Identity.

-* Enable your users to be automatically signed-in to MURAL Identity with their Azure AD accounts.

-* MURAL Identity single sign-on (SSO) enabled subscription.

-* MURAL Identity supports **SP and IDP** initiated SSO.

-* MURAL Identity supports **Just In Time** user provisioning.

-## Add MURAL Identity from the gallery

-To configure the integration of MURAL Identity into Azure AD, you need to add MURAL Identity from the gallery to your list of managed SaaS apps.

-1. In the **Add from the gallery** section, type **MURAL Identity** in the search box.

-1. Select **MURAL Identity** from results panel and then add the app. Wait a few seconds while the app is added to your tenant.

-## Configure and test Azure AD SSO for MURAL Identity

-Configure and test Azure AD SSO with MURAL Identity using a test user called **B.Simon**. For SSO to work, you need to establish a link relationship between an Azure AD user and the related user in MURAL Identity.

-To configure and test Azure AD SSO with MURAL Identity, perform the following steps:

-1. **[Configure MURAL Identity SSO](#configure-mural-identity-sso)** - to configure the single sign-on settings on application side.

- 1. **[Create MURAL Identity test user](#create-mural-identity-test-user)** - to have a counterpart of B.Simon in MURAL Identity that is linked to the Azure AD representation of user.

-1. In the Azure portal, on the **MURAL Identity** application integration page, find the **Manage** section and select **single sign-on**.

-1. MURAL Identity application expects the SAML assertions in a specific format, which requires you to add custom attribute mappings to your SAML token attributes configuration. The following screenshot shows the list of default attributes.

-1. In addition to above, MURAL Identity application expects few more attributes to be passed back in SAML response which are shown below. These attributes are also pre populated but you can review them as per your requirements.

-1. On the **Set up MURAL Identity** section, copy the appropriate URL(s) based on your requirement.

-In this section, you'll enable B.Simon to use Azure single sign-on by granting access to MURAL Identity.

-1. In the applications list, select **MURAL Identity**.

-## Configure MURAL Identity SSO

-1. Log in to the MURAL Identity website as an administrator.

-d. Select **HTTP-POST** as the Request binding type and select **SHA256** as the Sign in algorithm type.

-### Create MURAL Identity test user

-In this section, a user called Britta Simon is created in MURAL Identity. MURAL Identity supports just-in-time user provisioning, which is enabled by default. There is no action item for you in this section. If a user doesn't already exist in MURAL Identity, a new one is created after authentication.

-* Click on **Test this application** in Azure portal. This will redirect to MURAL Identity Sign on URL where you can initiate the login flow.

-* Go to MURAL Identity Sign on URL directly and initiate the login flow from there.

-* Click on **Test this application** in Azure portal and you should be automatically signed in to the MURAL Identity for which you set up the SSO.

-You can also use Microsoft My Apps to test the application in any mode. When you click the MURAL Identity tile in the My Apps, if configured in SP mode you would be redirected to the application sign-on page for initiating the login flow and if configured in IDP mode, you should be automatically signed in to the MURAL Identity for which you set up the SSO. For more information about the My Apps, see [Introduction to the My Apps](../user-help/my-apps-portal-end-user-access.md).

-Once you configure MURAL Identity you can enforce session control, which protects exfiltration and infiltration of your organizationΓÇÖs sensitive data in real time. Session control extends from Conditional Access. [Learn how to enforce session control with Microsoft Cloud App Security](/cloud-app-security/proxy-deployment-aad).

-> * Provision groups and group memberships in Netsparker Enterprise

-To configure single sign-on on **Pennylane** side, you need to send the downloaded **Certificate (Base64)** and appropriate copied URLs from Azure portal to [Pennylane support team](mailto:tech@pennylane.com). They set this setting to have the SAML SSO connection set properly on both sides.

-In this section, you create a user called Britta Simon at Pennylane. Work with [Pennylane support team](mailto:tech@pennylane.com) to add the users in the Pennylane platform. Users must be created and activated before you use single sign-on.

-description: Learn how to configure single sign-on between Azure Active Directory and Projectplace.

-# Tutorial: Azure AD SSO integration with Projectplace

-In this tutorial, you'll learn how to integrate Projectplace with Azure Active Directory (Azure AD). When you integrate Projectplace with Azure AD, you can:

-* Control in Azure AD who has access to Projectplace.

-* Enable your users to be automatically signed-in to Projectplace with their Azure AD accounts.

-* Users can be provisioned in Projectplace automatically.

-* Projectplace single sign-on (SSO) enabled subscription.

-* Projectplace supports **SP and IDP** initiated SSO and supports **Just In Time** user provisioning.

-## Add Projectplace from the gallery

-To configure the integration of Projectplace into Azure AD, you need to add Projectplace from the gallery to your list of managed SaaS apps.

-1. In the **Add from the gallery** section, type **Projectplace** in the search box.

-1. Select **Projectplace** from results panel and then add the app. Wait a few seconds while the app is added to your tenant.

-## Configure and test Azure AD SSO for Projectplace

-Configure and test Azure AD SSO with Projectplace using a test user called **B.Simon**. For SSO to work, you need to establish a link relationship between an Azure AD user and the related user in Projectplace.

-To configure and test Azure AD SSO with Projectplace, perform the following steps:

-1. **[Configure Projectplace SSO](#configure-projectplace-sso)** - to configure the single sign-on settings on application side.

- 1. **[Create Projectplace test user](#create-projectplace-test-user)** - to have a counterpart of B.Simon in Projectplace that is linked to the Azure AD representation of user.

-1. In the Azure portal, on the **Projectplace** application integration page, find the **Manage** section and select **Single sign-on**.

-1. Click **Set additional URLs** and perform the following step if you wish to configure the application in **SP** initiated mode:

- In the **Sign-on URL** text box, type the URL:

-1. On the **Set up Projectplace** section, copy the appropriate URL(s) based on your requirement.

-In this section, you'll enable B. Simon to use Azure single sign-on by granting access to Projectplace.

-1. In the applications list, select **Projectplace**.

-## Configure Projectplace SSO

-To configure single sign-on on the **Projectplace** side, you need to send the copied **App Federation Metadata Url** from the Azure portal to the [Projectplace support team](https://success.planview.com/Projectplace/Support). This team ensures the SAML SSO connection is set properly on both sides.

->The single sign-on configuration has to be performed by the [Projectplace support team](https://success.planview.com/Projectplace/Support). You'll get a notification as soon as the configuration is complete.

-### Create Projectplace test user

->You can skip this step if you have provisioning enabled in Projectplace. You can ask the [Projectplace support team](https://success.planview.com/Projectplace/Support) to enable provisoning, once done users will be created in Projectplace during the first login.

-To enable Azure AD users to sign in to Projectplace, you need to add them to Projectplace. You need to add them manually.

-1. Sign in to your **Projectplace** company site as an admin.

->You can also use any other user-account creation tool or API provided by Projectplace to add Azure AD user accounts.

-* Click on **Test this application** in Azure portal. This will redirect to Projectplace Sign on URL where you can initiate the login flow.

-* Go to Projectplace Sign-on URL directly and initiate the login flow from there.

-* Click on **Test this application** in Azure portal and you should be automatically signed in to the Projectplace for which you set up the SSO.

-You can also use Microsoft My Apps to test the application in any mode. When you click the Projectplace tile in the My Apps, if configured in SP mode you would be redirected to the application sign on page for initiating the login flow and if configured in IDP mode, you should be automatically signed in to the Projectplace for which you set up the SSO. For more information about the My Apps, see [Introduction to the My Apps](../user-help/my-apps-portal-end-user-access.md).

-Once you configure Projectplace you can enforce session control, which protects exfiltration and infiltration of your organizationΓÇÖs sensitive data in real time. Session control extends from Conditional Access. [Learn how to enforce session control with Microsoft Defender for Cloud Apps](/cloud-app-security/proxy-deployment-aad).

-1. In the **Admin Credentials** section, enter your ServiceNow admin credentials and username. Select **Test Connection** to ensure that Azure AD can connect to ServiceNow. If the connection fails, ensure that your ServiceNow account has admin permissions and try again.

- 

-1. Sign in to the [Azure Active Directory portal](https://aad.portal.azure.com/).

-1. Go to **Enterprise applications**, and then select **All applications**.

-# Path to the public key of the Azure AD SAML signing certificate (self-signed), downloaded from the Enterprise application in the Azure AD portal

-* Manage all of the end users and groups used by your WSS account from your Azure AD portal.

-On the **Select a Role** page in your Azure Active Directory portal, the Tableau Site Role values that are valid include the following: **Creator, SiteAdministratorCreator, Explorer, SiteAdministratorExplorer, ExplorerCanPublish, Viewer, or Unlicensed**.

-> TMWS doesn't support testing single sign-on from the Azure AD portal, under **Overview** > **Single sign-on** > **Set up Single Sign-on with SAML** > **Test** of your new enterprise application.

-| AC.L2-3.1.18<br><br>**Practice statement:** Control connection of mobile devices.<br><br>**Objectives:**<br>Determine if:<br>[a.] mobile devices that process, store, or transmit CUI are identified;<br>[b.] mobile device connections are authorized; and<br>[c.] mobile device connections are monitored and logged. | Configure device management policies via MDM (such as Microsoft Intune), Microsoft Intune, Configuration Manager, or group policy objects (GPO) to enforce mobile device configuration and connection profile. Configure Conditional Access policies to enforce device compliance.<br><br>**Conditional Access**<br>[Require device to be marked as compliant](../conditional-access/concept-conditional-access-grant.md)<br>[Require hybrid Azure AD joined device](../conditional-access/concept-conditional-access-grant.md)<br><br>**InTune**<br>[Device compliance policies in Microsoft Intune](/mem/intune/protect/device-compliance-get-started)<br>[What is app management in Microsoft Intune?](/mem/intune/apps/app-management) |

-| AC.L2-3.1.21<br><br>**Practice statement:** Limit use of portable storage devices on external systems.<br><br>**Objectives:**<br>Determine if:<br>[a.] the use of portable storage devices containing CUI on external systems is identified and documented;<br>[b.] limits on the use of portable storage devices containing CUI on external systems are defined; and<br>[c.] the use of portable storage devices containing CUI on external systems is limited as defined. | Configure device management policies via MDM (such as Microsoft Intune), Microsoft Intune, Configuration Manager, or group policy objects (GPO) to control the use of portable storage devices on systems. Configure policy settings on the Windows device to completely prohibit or restrict use of portable storage at the OS level. For all other devices where you may be unable to granularly control access to portable storage block download entirely with Microsoft Defender for Cloud Apps. Configure Conditional Access policies to enforce device compliance.<br><br>**Conditional Access**<br>[Require device to be marked as compliant](../conditional-access/concept-conditional-access-grant.md)<br>[Require hybrid Azure AD joined device](../conditional-access/concept-conditional-access-grant.md)<br>[Configure authentication session management - Azure Active Directory](../conditional-access/howto-conditional-access-session-lifetime.md)<br><br>**InTune**<br>[Device compliance policies in Microsoft Intune](/mem/intune/protect/device-compliance-get-started)<br>[Restrict USB devices using administrative templates in Microsoft Intune](/mem/intune/configuration/administrative-templates-restrict-usb)<br><br>**Microsoft Defender for Cloud Apps**<br>[Create session policies in Defender for Cloud Apps](/defender-cloud-apps/session-policy-aad)

-| AU.L2-3.3.1<br><br>**Practice statement:** Create and retain system audit logs and records to enable monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.<br><br>**Objectives:**<br>Determine if:<br>[a.] audit logs (for example, event types to be logged) to enable monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified;<br>[b.] the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined;<br>[c.] audit records are created (generated);<br>[d.] audit records, once created, contain the defined content;<br>[e.] retention requirements for audit records are defined; and<br>[f.] audit records are retained as defined.<br><br>AU.L2-3.3.2<br><br>**Practice statement:** Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.<br><br>**Objectives:**<br>Determine if:<br>[a.] the content of the audit records needed to support the ability to uniquely trace users to their actions is defined; and<br>[b.] audit records, once created, contain the defined content. | All operations are audited within the Azure AD audit logs. Each audit log entry contains a userΓÇÖs immutable objectID that can be used to uniquely trace an individual system user to each action. You can collect and analyze logs by using a Security Information and Event Management (SIEM) solution such as Microsoft Sentinel. Alternatively, you can use Azure Event Hubs to integrate logs with third-party SIEM solutions to enable monitoring and notification.<br>[Audit activity reports in the Azure Active Directory portal](../reports-monitoring/concept-audit-logs.md)<br>[Connect Azure Active Directory data to Microsoft Sentinel](../../sentinel/connect-azure-active-directory.md)<br>[Tutorial: Stream logs to an Azure event hub](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md) |

-| AU.L2-3.3.6<br><br>**Practice statement:** Provide audit record reduction and report generation to support on-demand analysis and reporting.<br><br>**Objectives:**<br>Determine if:<br>[a.] an audit record reduction capability that supports on-demand analysis is provided; and<br>[b.] a report generation capability that supports on-demand reporting is provided. | Ensure Azure AD events are included in event logging strategy. You can collect and analyze logs by using a Security Information and Event Management (SIEM) solution such as Microsoft Sentinel. Alternatively, you can use Azure Event Hubs to integrate logs with third-party SIEM solutions to enable monitoring and notification. Use Azure AD entitlement management with access reviews to ensure compliance status of accounts. <br>[Audit activity reports in the Azure Active Directory portal](../reports-monitoring/concept-audit-logs.md)<br>[Connect Azure Active Directory data to Microsoft Sentinel](../../sentinel/connect-azure-active-directory.md)<br>[Tutorial: Stream logs to an Azure event hub](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md) |

-| IR.L2-3.6.1<br><br>**Practice statement:** Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.<br><br>**Objectives:**<br>Determine if:<br>[a.] an operational incident-handling capability is established;<br>[b.] the operational incident-handling capability includes preparation;<br>[c.] the operational incident-handling capability includes detection;<br>[d.] the operational incident-handling capability includes analysis;<br>[e.] the operational incident-handling capability includes containment;<br>[f.] the operational incident-handling capability includes recovery; and<br>[g.] the operational incident-handling capability includes user response activities. | Implement incident handling and monitoring capabilities. The audit logs record all configuration changes. Authentication and authorization events are audited within the sign-in logs, and any detected risks are audited in the Identity Protection logs. You can stream each of these logs directly into a SIEM solution, such as Microsoft Sentinel. Alternatively, use Azure Event Hubs to integrate logs with third-party SIEM solutions.<br><br>**Audit events**<br>[Audit activity reports in the Azure Active Directory portal](../reports-monitoring/concept-audit-logs.md)<br>[Sign-in activity reports in the Azure Active Directory portal](../reports-monitoring/concept-sign-ins.md)<br>[How To: Investigate risk](../identity-protection/howto-identity-protection-investigate-risk.md)<br><br>**SIEM integrations**<br>[Microsoft Sentinel : Connect data from Azure Active Directory (Azure AD)](../../sentinel/connect-azure-active-directory.md)[Stream to Azure event hub and other SIEMs](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md) |

-| MP.L2-3.8.7<br><br>**Practice statement:** Control the use of removable media on system components.<br><br>**Objectives:**<br>Determine if:<br>[a.] the use of removable media on system components is controlled. | Configure device management policies via MDM (such as Microsoft Intune), Microsoft Intune, Configuration Manager, or group policy objects (GPO) to control the use of removable media on systems. Deploy and manage Removable Storage Access Control using Intune, Configuration Manager, or Group Policy. Configure Conditional Access policies to enforce device compliance.<br><br>**Conditional Access**<br>[Require device to be marked as compliant](../conditional-access/concept-conditional-access-grant.md)<br>[Require hybrid Azure AD joined device](../conditional-access/concept-conditional-access-grant.md#require-hybrid-azure-ad-joined-device)<br><br>**Intune**<br>[Device compliance policies in Microsoft Intune](/mem/intune/protect/device-compliance-get-started)<br><br>**Removable storage access control**<br>[Deploy and manage Removable Storage Access Control using Intune](/microsoft-365/security/defender-endpoint/deploy-manage-removable-storage-intune?view=o365-worldwide&preserve-view=true)<br>[Deploy and manage Removable Storage Access Control using group policy](/microsoft-365/security/defender-endpoint/deploy-manage-removable-storage-group-policy?view=o365-worldwide&preserve-view=true) |

-| SC.L2-3.13.4<br><br>**Practice statement:** Prevent unauthorized and unintended information transfer via shared system resources.<br><br>**Objectives:**<br>Determine if:<br>[a.] unauthorized and unintended information transfer via shared system resources is prevented. | Configure device management policies via MDM (such as Microsoft Intune), Microsoft Intune, Configuration Manager, or group policy objects (GPO) to ensure devices are compliant with system hardening procedures. Include compliance with company policy regarding software patches to prevent attackers from exploiting flaws.<br><br>Configure Conditional Access policies to enforce device compliance.<br><br>**Conditional Access**<br>[Require device to be marked as compliant](../conditional-access/concept-conditional-access-grant.md)<br>[Require hybrid Azure AD joined device](../conditional-access/concept-conditional-access-grant.md)<br><br>**InTune**<br>[Device compliance policies in Microsoft Intune](/mem/intune/protect/device-compliance-get-started) |

-| SC.L2-3.13.13<br><br>**Practice statement:** Control and monitor the use of mobile code.<br><br>**Objectives:**<br>Determine if:<br>[a.] use of mobile code is controlled; and<br>[b.] use of mobile code is monitored. | Configure device management policies via MDM (such as Microsoft Intune), Microsoft Intune, Configuration Manager, or group policy objects (GPO) to disable the use of mobile code. Where use of mobile code is required monitor the use with endpoint security such as Microsoft Defender for Endpoint.<br><br>Configure Conditional Access policies to enforce device compliance.<br><br>**Conditional Access**<br>[Require device to be marked as compliant](../conditional-access/concept-conditional-access-grant.md)<br>[Require hybrid Azure AD joined device](../conditional-access/concept-conditional-access-grant.md)<br><br>**InTune**<br>[Device compliance policies in Microsoft Intune](/mem/intune/protect/device-compliance-get-started)<br><br>**Defender for Endpoint**<br>[Microsoft Defender for Endpoint](/microsoft-365/security/defender-endpoint/microsoft-defender-endpoint?view=o365-worldwide&preserve-view=true) |

-| SI.L2-3.14.7<br><br>**Practice statement:**<br><br>**Objectives:** Identify unauthorized use of organizational systems.<br>Determine if:<br>[a.] authorized use of the system is defined; and<br>[b.] unauthorized use of the system is identified. | Consolidate telemetry: Azure AD logs to stream to SIEM, such as Azure Sentinel Configure device management policies via MDM (such as Microsoft Intune), Microsoft Intune, Configuration Manager, or group policy objects (GPO) to require Intrusion Detection/Protection (IDS/IPS) such as Microsoft Defender for Endpoint is installed and in use. Use telemetry provided by the IDS/IPS to identify unusual activities or conditions related to inbound and outbound communications traffic or unauthorized use.<br><br>Configure Conditional Access policies to enforce device compliance.<br><br>**Conditional Access**<br>[Require device to be marked as compliant](../conditional-access/concept-conditional-access-grant.md)<br>[Require hybrid Azure AD joined device](../conditional-access/concept-conditional-access-grant.md)<br><br>**InTune**<br>[Device compliance policies in Microsoft Intune](/mem/intune/protect/device-compliance-get-started)<br><br>**Defender for Endpoint**<br>[Microsoft Defender for Endpoint](/microsoft-365/security/defender-endpoint/microsoft-defender-endpoint?view=o365-worldwide&preserve-view=true) |

-| AC-02 | **Implement account lifecycle management for customer-controlled accounts. Monitor the use of accounts and notify account managers of account lifecycle events. Review accounts for compliance with account management requirements every month for privileged access and every six months for nonprivileged access.**<p>Use Azure AD to provision accounts from external HR systems, on-premises Active Directory, or directly in the cloud. All account lifecycle operations are audited within the Azure AD audit logs. You can collect and analyze logs by using a Security Information and Event Management (SIEM) solution such as Microsoft Sentinel. Alternatively, you can use Azure Event Hubs to integrate logs with third-party SIEM solutions to enable monitoring and notification. Use Azure AD entitlement management with access reviews to ensure compliance status of accounts.<p>Provision accounts<br><li>[Plan cloud HR application to Azure Active Directory user provisioning](../app-provisioning/plan-cloud-hr-provision.md)<br><li>[Azure AD Connect sync: Understand and customize synchronization](../hybrid/how-to-connect-sync-whatis.md)<br><li>[Add or delete users using Azure Active Directory](../fundamentals/add-users-azure-active-directory.md)<p>Monitor accounts<br><li>[Audit activity reports in the Azure Active Directory portal](../reports-monitoring/concept-audit-logs.md)<br><li>[Connect Azure Active Directory data to Microsoft Sentinel](../../sentinel/connect-azure-active-directory.md) <br><li>[Tutorial: Stream logs to an Azure event hub](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md)<p>Review accounts<br><li>[What is Azure AD entitlement management?](../governance/entitlement-management-overview.md)<br><li>[Create an access review of an access package in Azure AD entitlement management](../governance/entitlement-management-access-reviews-create.md)<br><li>[Review access of an access package in Azure AD entitlement management](../governance/entitlement-management-access-reviews-review-access.md)<p>Resources<br><li>[Administrator role permissions in Azure Active Directory](../roles/permissions-reference.md)<br><li>[Dynamic Groups in Azure AD](../enterprise-users/groups-create-rule.md) |

-| AC-02(1)| **Employ automated mechanisms to support management of customer-controlled accounts.**<p>Configure automated provisioning of customer-controlled accounts from external HR systems or on-premises Active Directory. For applications that support application provisioning, configure Azure AD to automatically create user identities and roles in cloud software as a solution (SaaS) applications that users need access to. In addition to creating user identities, automatic provisioning includes the maintenance and removal of user identities as status or roles change. To ease monitoring of account usage, you can stream Azure AD Identity Protection logs, which show risky users, risky sign-ins, and risk detections, and audit logs directly into Microsoft Sentinel or Event Hubs.<p>Provision<br><li>[Plan cloud HR application to Azure Active Directory user provisioning](../app-provisioning/plan-cloud-hr-provision.md)<br><li>[Azure AD Connect sync: Understand and customize synchronization](../hybrid/how-to-connect-sync-whatis.md)<br><li>[What is automated SaaS app user provisioning in Azure AD?](../app-provisioning/user-provisioning.md)<br><li>[SaaS app integration tutorials for use with Azure AD](../saas-apps/tutorial-list.md)<p>Monitor and audit<br><li>[Investigate risk](../identity-protection/howto-identity-protection-investigate-risk.md)<br><li>[Audit activity reports in the Azure Active Directory portal](../reports-monitoring/concept-audit-logs.md)<br><li>[What is Microsoft Sentinel?](../../sentinel/overview.md)<br><li>[Microsoft Sentinel: Connect data from Azure Active Directory](../../sentinel/connect-azure-active-directory.md)<br><li>[Tutorial: Stream Azure Active Directory logs to an Azure event hub](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md)ΓÇÄ|

-| AC-02(4)| **Implement an automated audit and notification system for the lifecycle of managing customer-controlled accounts.**<p>All account lifecycle operations, such as account creation, modification, enabling, disabling, and removal actions, are audited within the Azure audit logs. You can stream the logs directly into Microsoft Sentinel or Event Hubs to help with notification.<p>Audit<br><li>[Audit activity reports in the Azure Active Directory portal](../reports-monitoring/concept-audit-logs.md)<br><li>[Microsoft Sentinel: Connect data from Azure Active Directory](../../sentinel/connect-azure-active-directory.md)<P>Notification<br><li>[What is Microsoft Sentinel?](../../sentinel/overview.md)<br><li>[Tutorial: Stream Azure Active Directory logs to an Azure event hub](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md) |

-| AC-02(7)| **Administer and monitor privileged role assignments by following a role-based access scheme for customer-controlled accounts. Disable or revoke privilege access for accounts when no longer appropriate.**<p>Implement Azure AD Privileged Identity Management with access reviews for privileged roles in Azure AD to monitor role assignments and remove role assignments when no longer appropriate. You can stream audit logs directly into Microsoft Sentinel or Event Hubs to help with monitoring.<p>Administer<br><li>[What is Azure AD Privileged Identity Management?](../privileged-identity-management/pim-configure.md)<br><li>[Activation maximum duration](../privileged-identity-management/pim-how-to-change-default-settings.md?tabs=new)<p>Monitor<br><li>[Create an access review of Azure AD roles in Privileged Identity Management](../privileged-identity-management/pim-create-azure-ad-roles-and-resource-roles-review.md)<br><li>[View audit history for Azure AD roles in Privileged Identity Management](../privileged-identity-management/pim-how-to-use-audit-log.md?tabs=new)<br><li>[Audit activity reports in the Azure Active Directory portal](../reports-monitoring/concept-audit-logs.md)<br><li>[What is Microsoft Sentinel?](../../sentinel/overview.md)<br><li>[Connect data from Azure Active Directory](../../sentinel/connect-azure-active-directory.md)<br><li>[Tutorial: Stream Azure Active Directory logs to an Azure event hub](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md) |

-| AC-02(12)| **Monitor and report customer-controlled accounts with privileged access for atypical usage.**<p>For help with monitoring of atypical usage, you can stream Identity Protection logs, which show risky users, risky sign-ins, and risk detections, and audit logs, which help with correlation with privilege assignment, directly into a SIEM solution such as Microsoft Sentinel. You can also use Event Hubs to integrate logs with third-party SIEM solutions.<p>Identity protection<br><li>[What is Azure AD Identity Protection?](../identity-protection/overview-identity-protection.md)<br><li>[Investigate risk](../identity-protection/howto-identity-protection-investigate-risk.md)<br><li>[Azure Active Directory Identity Protection notifications](../identity-protection/howto-identity-protection-configure-notifications.md)<p>Monitor accounts<br><li>[What is Microsoft Sentinel?](../../sentinel/overview.md)<br><li>[Audit activity reports in the Azure Active Directory portal](../reports-monitoring/concept-audit-logs.md)<br><li>[Connect Azure Active Directory data to Microsoft Sentinel](../../sentinel/connect-azure-active-directory.md) <br><li>[Tutorial: Stream logs to an Azure event hub](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md) |

-| AU-02 <br>AU-03 <br>AU-03(1)<br>AU-03(2)| Ensure the system is capable of auditing events defined in AU-02 Part a. Coordinate with other entities within the organization's subset of auditable events to support after-the-fact investigations. Implement centralized management of audit records.<p>All account lifecycle operations (account creation, modification, enabling, disabling, and removal actions) are audited within the Azure AD audit logs. All authentication and authorization events are audited within Azure AD sign-in logs, and any detected risks are audited in the Identity Protection logs. You can stream each of these logs directly into a security information and event management (SIEM) solution such as Microsoft Sentinel. Alternatively, use Azure Event Hubs to integrate logs with third-party SIEM solutions.<p>Audit events<li> [Audit activity reports in the Azure Active Directory portal](../reports-monitoring/concept-audit-logs.md)<li> [Sign-in activity reports in the Azure Active Directory portal](../reports-monitoring/concept-sign-ins.md)<li>[How To: Investigate risk](../identity-protection/howto-identity-protection-investigate-risk.md)<p>SIEM integrations<li> [Microsoft Sentinel : Connect data from Azure Active Directory (Azure AD)](../../sentinel/connect-azure-active-directory.md)<li>[Stream to Azure event hub and other SIEMs](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md) |

-| IR-04<br>IR-04(1)<br>IR-04(2)<br>IR-04(3)<br>IR-04(4)<br>IR-04(6)<br>IR-04(8)<br>IR-05<br>IR-05(1)| Implement incident handling and monitoring capabilities. This includes Automated Incident Handling, Dynamic Reconfiguration, Continuity of Operations, Information Correlation, Insider Threats, Correlation with External Organizations, and Incident Monitoring and Automated Tracking. <p>The audit logs record all configuration changes. Authentication and authorization events are audited within the sign-in logs, and any detected risks are audited in the Identity Protection logs. You can stream each of these logs directly into a SIEM solution, such as Microsoft Sentinel. Alternatively, use Azure Event Hubs to integrate logs with third-party SIEM solutions. Automate dynamic reconfiguration based on events within the SIEM by using Microsoft Graph or Azure AD PowerShell.<p>Audit events<br><li>[Audit activity reports in the Azure Active Directory portal](../reports-monitoring/concept-audit-logs.md)<li>[Sign-in activity reports in the Azure Active Directory portal](../reports-monitoring/concept-sign-ins.md)<li>[How To: Investigate risk](../identity-protection/howto-identity-protection-investigate-risk.md)<p>SIEM integrations<li>[Microsoft Sentinel : Connect data from Azure Active Directory (Azure AD)](../../sentinel/connect-azure-active-directory.md)<li>[Stream to Azure event hub and other SIEMs](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md)<p>Dynamic reconfiguration<li>[AzureAD Module](/powershell/module/azuread/)<li>[Overview of Microsoft Graph](/graph/overview?view=graph-rest-1.0&preserve-view=true) |

-> Classic alerts in Azure Monitor were retired in August 2019. We recommended that you upgrade your classic storage account to use Resource Manager to retain alerting functionality with the new platform. For more information, see [classic alerts retirement](../azure-monitor/alerts/monitoring-classic-retirement.md#retirement-of-classic-monitoring-and-alerting-platform).

-| `SecurityPatch`|AKS will update the node's virtual hard disk (VHD) with patches from the image maintainer labeled "security only" on a regular basis. Where possible, patches will also be applied without disruption to existing nodes. Some patches, such as kernel patches, can't be applied to existing nodes without disruption. For such patches, the VHD will be updated and existing machines will be upgraded to that VHD following maintenance windows and surge settings. This option incurs the extra cost of hosting the VHDs in your node resource group. If you use this channel, Linux [unattended upgrades][unattended-upgrades] will be disabled by default.|N/A|

-## Upgrade existing clusters

-To update an existing cluster to use Azure CNI overlay, there are a couple prerequisites:

-* The cluster must use Azure CNI without the pod subnet feature.

-* The cluster is _not_ using network policies.

-* The Overlay Pod CIDR needs to be an address range that _does not_ overlap with the existing cluster's VNet.

-* If you have subnet Network Security Group rules, they must allow traffic to and from the Pod CIDR (refer to the [network security groups](#network-security-groups) section in this document for more information).

-To update a cluster, run the following Azure CLI command.

-```azurecli

-az aks update --name $clusterName --resource-group $resourceGroup --network-plugin azure --network-plugin-mode overlay --pod-cidr $overlayPodCidr

-```

-The HTTP application routing solution makes it easy to access applications that are deployed to your Azure Kubernetes Service (AKS) cluster. When the solution's enabled, it configures an [Ingress controller](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) in your AKS cluster. As applications are deployed, the solution also creates publicly accessible DNS names for application endpoints.

-When the add-on is enabled, it creates a DNS Zone in your subscription. For more information about DNS cost, see [DNS pricing][dns-pricing].

-> [!CAUTION]

-> The HTTP application routing add-on is designed to let you quickly create an ingress controller and access your applications. This add-on is not currently designed for use in a production environment and is not recommended for production use. For production-ready ingress deployments that include multiple replicas and TLS support, see [Create an HTTPS ingress controller](./ingress-tls.md).

-Azure provides several tools that help streamline Kubernetes, such as DevOps Starter.

-### DevOps Starter

-DevOps Starter provides a simple solution for bringing existing code and Git repositories into Azure. DevOps Starter automatically:

-* Creates Azure resources (such as AKS).

-* Configures a release pipeline in Azure DevOps Services that includes a build pipeline for CI.

-* Sets up a release pipeline for CD.

-* Generates an Azure Application Insights resource for monitoring.

-For more information, see [DevOps Starter][azure-devops].

-[azure-monitor]: ../azure-monitor/containers/containers.md

-To use Application Insights, [create an instance of the Application Insights service](../azure-monitor/app/create-new-resource.md). To create an instance using the Azure portal, see [Workspace-based Application Insights resources](../azure-monitor/app/create-workspace-resource.md).

-1. To enable [availability monitoring](../azure-monitor/app/monitor-web-app-availability.md) of your API Management instance in Application Insights, select the **Add availability monitor** checkbox.

-You can modify general email settings for notifications that are sent from your API Management instance. You can change the administrator email address, the name of the organization sending notifications, and the originating email address.

- > [!NOTE]

- > When you change the Originating email address, some recipients may not receive the auto-generated emails from API Management or emails may get sent to the Junk/Spam folder. This happens because the email no longer passes SPF Authentication after you change the Originating email address domain. To ensure successful SPF Authentication and delivery of email, create the following TXT record in the DNS database of the domain specified in the email address. For instance, if the email address is `noreply@contoso.com`, you will need to contact the administrator of contoso.com to add the following TXT record: **"v=spf1 include:spf.protection.outlook.com include:_spf-ssg-a.microsoft.com -all"**

-If your application uses [Logback](https://logback.qos.ch/) or [Log4j](https://logging.apache.org/log4j) for tracing, you can forward these traces for review into Azure Application Insights using the logging framework configuration instructions in [Explore Java trace logs in Application Insights](../azure-monitor/app/deprecated-java-2x.md#explore-java-trace-logs-in-application-insights).

-The following App Service Environment configurations can be migrated using the migration feature. The table gives the App Service Environment v3 configuration you'll end up with when using the migration feature based on your existing App Service Environment. All supported App Service Environments can be migrated to a [zone redundant App Service Environment v3](../../availability-zones/migrate-app-service-environment.md) using the migration feature as long as the environment is [in a region that supports zone redundancy](./overview.md#regions). You can [configure zone redundancy](#choose-your-app-service-environment-v3-configurations) during the migration process.

-The following scenarios aren't supported by the migration feature. See the [manual migration options](migration-alternatives.md) if your App Service Environment falls into one of these categories.

-The App Service platform will review your App Service Environment to confirm migration support. If your scenario doesn't pass all validation checks, you won't be able to migrate at this time using the migration feature. If your environment is in an unhealthy or suspended state, you won't be able to migrate until you make the needed updates.

-|Migration cannot be called on this ASE, please contact support for help migrating. |Support will need to be engaged for migrating this App Service Environment. This is potentially due to custom settings used by this environment. |Engage support to resolve your issue. |

-|Full migration cannot be called before IP addresses are generated. |You'll see this error if you attempt to migrate before finishing the pre-migration steps. |Ensure you've completed all pre-migration steps before you attempt to migrate. See the [step-by-step guide for migrating](how-to-migrate.md). |

-|Migration to ASEv3 is not allowed for this ASE. |You won't be able to migrate using the migration feature. |Migrate using one of the [manual migration options](migration-alternatives.md). |

-|`<ZoneRedundant><DedicatedHosts><ASEv3/ASE>` is not available in this location. |You'll see this error if you're trying to migrate an App Service Environment in a region that doesn't support one of your requested features. |Migrate using one of the [manual migration options](migration-alternatives.md) if you want to migrate immediately. Otherwise, wait for the migration feature to support this App Service Environment configuration. |

-|Migrate cannot be called on this ASE until the active upgrade has finished. |App Service Environments can't be migrated during platform upgrades. You can set your [upgrade preference](how-to-upgrade-preference.md) from the Azure portal. In some cases, an upgrade will be initiated when visiting the migration page if your App Service Environment isn't on the current build. |Wait until the upgrade finishes and then migrate. |

-|App Service Environment management operation in progress. |Your App Service Environment is undergoing a management operation. These operations can include activities such as deployments or upgrades. Migration is blocked until these operations are complete. |You'll be able to migrate once these operations are complete. |

-Migration consists of a series of steps that must be followed in order. Key points are given for a subset of the steps. It's important to understand what will happen during these steps and how your environment and apps will be impacted. After reviewing the following information and when you're ready to migrate, follow the [step-by-step guide](how-to-migrate.md).

-The platform will create the [new inbound IP (if you're migrating an ELB App Service Environment) and the new outbound IP](networking.md#addresses) addresses. While these IPs are getting created, activity with your existing App Service Environment won't be interrupted, however, you won't be able to scale or make changes to your existing environment. This process will take about 15 minutes to complete.

-When completed, you'll be given the new IPs that will be used by your future App Service Environment v3. These new IPs have no effect on your existing environment. The IPs used by your existing environment will continue to be used up until your existing environment is shut down during the migration step.

-Once the new IPs are created, you'll have the new default outbound to the internet public addresses so you can adjust any external firewalls, DNS routing, network security groups, and any other resources that rely on these IPs, in preparation for the migration. For ELB App Service Environment, you'll also have the new inbound IP address that you can use to set up new endpoints with services like [Traffic Manager](../../traffic-manager/traffic-manager-overview.md) or [Azure Front Door](../../frontdoor/front-door-overview.md). **It's your responsibility to update any and all resources that will be impacted by the IP address change associated with the new App Service Environment v3. Don't move on to the next step until you've made all required updates.**

-App Service Environment v3 requires the subnet it's in to have a single delegation of `Microsoft.Web/hostingEnvironments`. Migration won't succeed if the App Service Environment's subnet isn't delegated or it's delegated to a different resource.

-Virtual network locks will block platform operations during migration. If your virtual network has locks, you'll need to remove them before migrating. The locks can be readded if needed once migration is complete. Locks can exist at three different scopes: subscription, resource group, and resource. When you apply a lock at a parent scope, all resources within that scope inherit the same lock. If you have locks applied at the subscription, resource group, or resource scope, they'll need to be removed before the migration. For more information on locks and lock inheritance, see [Lock your resources to protect your infrastructure](../../azure-resource-manager/management/lock-resources.md).

-Your App Service Environment v3 can be deployed across availability zones in the regions that support it. This architecture is known as [zone redundancy](../../availability-zones/migrate-app-service-environment.md). Zone redundancy can only be configured during App Service Environment creation. If you want your new App Service Environment v3 to be zone redundant, enable the configuration during the migration process. Any App Service Environment that is using the migration feature to migrate can be configured as zone redundant as long as you're using a [region that supports zone redundancy for App Service Environment v3](./overview.md#regions). If you're existing environment is using a region that doesn't support zone redundancy, the configuration option will be disabled and you won't be able to configure it. The migration feature doesn't support changing regions. If you'd like to use a different region, use one of the [manual migration options](migration-alternatives.md).

-If your existing App Service Environment uses a custom domain suffix, you'll be prompted to configure a custom domain suffix for your new App Service Environment v3. You'll need to provide the custom domain name, managed identity, and certificate. For more information on App Service Environment v3 custom domain suffix including requirements, step-by-step instructions, and best practices, see [Configure custom domain suffix for App Service Environment](./how-to-custom-domain-suffix.md). You must configure a custom domain suffix for your new environment even if you no longer want to use it. Once migration is complete, you can remove the custom domain suffix configuration if needed.

-If your migration includes a custom domain suffix, for App Service Environment v3, the custom domain will no longer be shown in the **Essentials** section of the **Overview** page of the portal as it is for App Service Environment v1/v2. Instead, for App Service Environment v3, go to the **Custom domain suffix** page where you can confirm your custom domain suffix is configured correctly.

-During migration, which requires up to a three hour service window for App Service Environment v2 to v3 migrations and up to a six hour service window depending on environment size for v1 to v3 migrations, scaling and environment configurations are blocked and the following events will occur:

-As in the IP generation step, you won't be able to scale, modify your App Service Environment, or deploy apps to it during this process. When migration is complete, the apps that were on the old App Service Environment will be running on the new App Service Environment v3.

-There's no cost to migrate your App Service Environment. You'll stop being charged for your previous App Service Environment as soon as it shuts down during the migration process, and you'll begin getting charged for your new App Service Environment v3 as soon as it's deployed. For more information about App Service Environment v3 pricing, see the [pricing details](overview.md#pricing).

- You won't be able migrate using the migration feature at this time. If you have an unsupported environment and want to migrate immediately, see the [manual migration options](migration-alternatives.md). This doc will be updated as additional regions and supported scenarios become available.

- No, all of your apps running on the old environment will be automatically migrated to the new environment and run like before. No user input is needed.

- You'll now be on App Service Environment v3 so be sure to review the [features and feature differences](overview.md#feature-differences) compared to previous versions. For ILB App Service Environment, you'll keep the same ILB IP address. For internet facing App Service Environment, the public IP address and the outbound IP address will change. Note for ELB App Service Environment, previously there was a single IP for both inbound and outbound. For App Service Environment v3, they're separate. For more information, see [App Service Environment v3 networking](networking.md#addresses).

- If there's an unexpected issue, support teams will be on hand. It's recommended to migrate dev environments before touching any production environments.

- If you decide to migrate an App Service Environment using the migration feature, the old environment gets shut down, deleted, and all of your apps are migrated to a new environment. Your old environment will no longer be accessible. A rollback to the old environment won't be possible.

- az webapp up --resource-group myAuthResourceGroup --name <front-end-app-name> --plan myPlan --sku FREE --location "West Europe"--runtime "NODE:16-lts"

- az webapp up --resource-group myAuthResourceGroup --name <back-end-app-name> --plan myPlan --runtime "NODE:16-lts"

-You can use different types of logs in Azure to manage and troubleshoot application gateways. You can access some of these logs through the portal. All logs can be extracted from Azure Blob storage and viewed in different tools, such as [Azure Monitor logs](../azure-monitor/insights/azure-networking-analytics.md), Excel, and Power BI. You can learn more about the different types of logs from the following list:

-[Azure Monitor logs](../azure-monitor/insights/azure-networking-analytics.md) can collect the counter and event log files from your Blob storage account. It includes visualizations and powerful search capabilities to analyze your logs.

-* Visualize counter and event logs by using [Azure Monitor logs](../azure-monitor/insights/azure-networking-analytics.md).

-* Visualize counter and event logs by using [Azure Monitor logs](../azure-monitor/insights/azure-networking-analytics.md).

-This article describes how to work with scope configurations when using the [Change Tracking and Inventory](overview.md) feature to deploy changes to your VMs. For more information, see [Targeting monitoring solutions in Azure Monitor (Preview)](../../azure-monitor/insights/solution-targeting.md).

-For more information, see [Log Analytics workspace and Automation account](../../azure-monitor/insights/solutions.md#log-analytics-workspace-and-automation-account).

-If your machine shows up in the query results, verify the scope configuration. See [Targeting monitoring solutions in Azure Monitor](../../azure-monitor/insights/solution-targeting.md).

-The scheduled deployment defines which target machines receive the applicable updates. It does so either by explicitly specifying certain machines or by selecting a [computer group](../../azure-monitor/logs/computer-groups.md) that's based on log searches of a specific set of machines (or based on an [Azure query](query-logs.md) that dynamically selects Azure VMs based on specified criteria). These groups differ from [scope configuration](../../azure-monitor/insights/solution-targeting.md), which is used to control the targeting of machines that receive the configuration to enable Update Management. This prevents them from performing and reporting update compliance, and install approved required updates.

-This article describes how to work with scope configurations when using the [Update Management](overview.md) feature to deploy updates and patches to your machines. For more information, see [Targeting monitoring solutions in Azure Monitor (Preview)](../../azure-monitor/insights/solution-targeting.md).

-# Quickstart: Create a Python app with Azure App Configuration (preview)

-> [!IMPORTANT]

-> The Python provider for Azure App Configuration is currently in preview.

-> See the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

-In this quickstart, you will use the Python provider for Azure App Configuration (preview) to centralize storage and management of application settings using the [Azure App Configuration Python provider client library](https://github.com/Azure/azure-sdk-for-python/tree/main/sdk/appconfiguration/azure-appconfiguration-provider).

-The Python App Configuration provider is a library in preview running on top of the [Azure SDK for Python](https://github.com/Azure/azure-sdk-for-python/tree/main/sdk/appconfiguration/azure-appconfiguration), helping Python developers easily consume the App Configuration service. It enables configuration settings to be used like a dictionary.

- load_provider,

- config = load_provider(connection_string=connection_string)

- config = load_provider(connection_string=connection_string, trim_prefixes=trimmed)

- config = load_provider(connection_string=connection_string, selects=selects)

-In order to use Arc resource bridge in a region, Arc resource bridge and the private cloud product must be supported in the region. For example, to use Arc resource bridge with Azure Stack HCI in East US, Arc resource bridge and Azure Stack HCI must be supported in East US. Please check with the private cloud product for their region availability - it is typically called out in their deployment instructions of Arc resource bridge. There are instances where Arc Resource Bridge may be available in a region where private cloud support is not yet available.

-| [Geo-replication](#geo-replication) | Linked cache instances in two regions, with user-controlled failover | Premium; Enterprise (see [details](https://azure.microsoft.com/support/legal/sla/cache/v1_1/)) |-|Passive|Active|

-Azure Cache for Redis has a high availability architecture that ensures your managed instance is functioning, even when outages affect the underlying virtual machines (VMs). Whether the outage is planned or unplanned outages, Azure Cache for Redis delivers much greater percentage availability rates than what's attainable by hosting Redis on a single VM.

-Also, Azure Cache for Redis provides more replica nodes in the Premium tier. A [multi-replica cache](cache-how-to-multi-replicas.md) can be configured with up to three replica nodes. Having more replicas generally improves resiliency because you have nodes backing up the primary. Even with more replicas, an Azure Cache for Redis instance still can be severely impacted by a data center or Availability Zone outage. You can increase cache availability by using multiple replicas with [zone redundancy](#zone-redundancy).

-If a cache is configured to use two or more zones as described above, the cache nodes are created in different zones. When a zone goes down, cache nodes in other zones are available to keep the cache functioning as usual.

-Azure Cache for Redis distributes nodes in a zone redundant cache in a round-robin manner over the selected Availability Zones. It also determines which node will serve as the primary initially.

-A zone redundant cache provides automatic failover. When the current primary node is unavailable, one of the replicas will take over. Your application may experience higher cache response time if the new primary node is located in a different AZ. Availability Zones are geographically separated. Switching from one AZ to another alters the physical distance between where your application and cache are hosted. This change impacts round-trip network latencies from your application to the cache. The extra latency is expected to fall within an acceptable range for most applications. We recommend you test your application to ensure it does well with a zone-redundant cache.

-## Geo-replication

-[Geo-replication](cache-how-to-geo-replication.md) is a mechanism for linking two or more Azure Cache for Redis instances, typically spanning two Azure regions. Geo-replication is designed mainly for disaster recovery. Two Premium tier cache instances are connected through geo-replication in a way that provides reads and writes to your primary cache, and that data is replicated to the secondary cache.

-The Enterprise tiers support a more advanced form of geo-replication called [active geo-replication](cache-how-to-active-geo-replication.md). The Azure Cache for Redis Enterprise software uses conflict-free replicated data types to support writes to multiple cache instances, merges changes, and resolves conflicts. You can join up to five Enterprise tier cache instances in different Azure regions to form a geo-replication group.

-If you experience a regional outage, consider recreating your cache in a different region, and updating your application to connect to the new cache instead. It's important to understand that data will be lost during a regional outage. Your application code should be resilient to data loss.

-Import/Export is an Azure Cache for Redis data management operation. It allows you to import data into Azure Cache for Redis or export data from Azure Cache for Redis by importing and exporting an Azure Cache for Redis Database (RDB) snapshot from a premium cache to a blob in an Azure Storage Account.

-Import/Export is available only in the premium pricing tier.

-Many clients libraries support Redis clustering but not all. Check the documentation for the library you're using to verify you're using a library and version that support clustering. StackExchange.Redis is one library that does support clustering, in its newer versions. For more information on other clients, see the [Playing with the cluster](https://redis.io/topics/cluster-tutorial#playing-with-the-cluster) section of the [Redis cluster tutorial](https://redis.io/topics/cluster-tutorial).

-The clustering protoco