+|`ENDPOINT`| The URI of your web API (for example, `https://localhost:5000/getAToken`).|

+ENDPOINT = 'https://localhost:5000'

+In this tutorial, learn to configure Azure Active Directory B2C (Azure AD B2C) with [HYPR](https://get.hypr.com). When Azure AD B2C is the identity provider (IdP), you can integrate HYPR with customer applications for passwordless authentication. HYPR replaces passwords with public key encryptions that help prevent fraud, phishing, and credential reuse.

+- An Azure AD subscription

+ - If you don't have one, you can get an [Azure free account](https://azure.microsoft.com/free/)

+- An [Azure AD B2C tenant](./tutorial-create-tenant.md) linked to your Azure subscription

+- A HYPR cloud tenant

+ - Request a HYPR [custom demo](https://get.hypr.com/free-trial)

+- A user mobile device registered using the HYPR REST APIs, or the HYPR Device Manager in your HYPR tenant

+ - For example, see [HYPR SDK for Java Web](https://docs.hypr.com/integratinghypr/docs/hypr-java-web-sdk)

+The HYPR integration has the following components:

+- **Azure AD B2C** ΓÇô The authorization server to verify user credentials, or the identity provider (IdP)

+- **Web and mobile applications** - For mobile or web applications protected by HYPR and Azure AD B2C

+ - HYPR has mobile SDK and a mobile app for iOS and Android

+- **HYPR mobile app** - Use it for this tutorial, if you're not using the mobile SDKs in your mobile applications

+- **HYPR REST APIs** - User device registration and authentication

+ - Go to apidocs.hypr.com for [HYPR Passwordless APIs](https://apidocs.hypr.com)

+ 

+1. User arrives at a sign-in page and selects sign-in or sign-up. User enters username.

+2. The application sends the user attributes to Azure AD B2C for identify verification.

+3. Azure AD B2C sends user attributes to HYPR to authenticate the user through the HYPR mobile app.

+4. HYPR sends a push notification to the registered user mobile device for a Fast Identity Online (FIDO) certified authentication. It can be a user fingerprint, biometric, or decentralized PIN.

+5. After user acknowledges the push notification, user is granted or denied access to the customer application.

+1. Go to [Azure-AD-B2C-HYPR-Sample/policy/](https://github.com/HYPR-Corp-Public/Azure-AD-B2C-HYPR-Sample/tree/master/policy).

+2. Follow the instructions in [Custom policy starter pack](tutorial-create-user-flows.md?pivots=b2c-custom-policy#custom-policy-starter-pack) to download [Active-directory-b2c-custom-policy-starterpack/LocalAccounts/](https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/tree/master/LocalAccounts)

+>Update policies to relate to your tenant.

+1. Open the Azure AD B2C tenant.

+2. Under **Policies**, select **Identity Experience Framework**.

+3. Select the **SignUpSignIn** you created.

+4. Select **Run user flow**.

+5. For **Application**, select the registered app (sample is JWT).

+6. For **Reply URL**, select the **redirect URL**.

+7. Select **Run user flow**.

+8. Complete the sign-up flow to create an account.

+9. After the user attribute is created, HYPR is called.

+>[!TIP]

+>If the flow is incomplete, confirm the user is saved in the directory.

+description: Configure Azure Active Directory B2C with Jumio for automated ID verification, safeguarding customer data.

+In this tutorial, learn to integrate Azure Active Directory B2C (Azure AD B2C) with [Jumio](https://www.jumio.com/), an ID verification service that enables real-time automated ID verification to help protect customer data.

+- An Azure AD subscription

+ - If you don't have one, you can get an [Azure free account](https://azure.microsoft.com/free/)

+- An [Azure AD B2C tenant](./tutorial-create-tenant.md) linked to your Azure subscription

+- **Azure AD B2C** - The authorization server that verifies user credentials, also known as the identity provider (IdP)

+- **Jumio** - Verifies user ID details

+- **Intermediate REST API** - Use it to implement Azure AD B2C and Jumio integration

+- **Azure Blob storage** - Use it to obtain custom UI files for the Azure AD B2C policies

+ 

+1. The user signs in, or signs up, and creates an account. Azure AD B2C collects user attributes.

+2. Azure AD B2C calls the middle-layer API and passes the user attributes.

+3. The middle-layer API converts user attributes into a Jumio API format and sends the attributes to Jumio.

+4. Jumio processes the attributes, and returns results to the middle-layer API.

+5. The middle-layer API processes the results and sends relevant information to Azure AD B2C.

+6. Azure AD B2C receives the information. If the response fails, an error message appears. If the response succeeds, the user is authenticated and written into the directory.

+## Create a Jumio account

+To create a Jumio account, go to the jumio.com [Contact](https://www.jumio.com/contact/) page.

+After you create a Jumio account, use it to configure Azure AD B2C.

+From [samples/Jumio/API/Jumio.Api/](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/Jumio/API/Jumio.Api), deploy the code to an Azure service. You can publish the code from Visual Studio.

+>To configure Azure AD, you'll need the deployed service URL.

+A client certificate helps protect the Jumio API call.

+1. Create a self-signed certificate by using the following PowerShell sample code:

+2. The certificate is exported to the location specified for ``{your-local-path}``.

+3. To import the certificate to Azure App Service, see [Upload a private certificate](../app-service/configure-ssl-certificate.md#upload-a-private-certificate).

+1. Create a random string with a length greater than 64 characters (letters and numbers only).

+ For example: ``C9CB44D98642A7062A0D39B94B6CDC1E54276F2E7CFFBF44288CEE73C08A8A65``

+2. Use the following PowerShell script to create the string:

+You can [configure application settings in Azure App Service](../app-service/configure-common.md#configure-app-settings) without checking them into a repository. You'll need to provide the following settings to the REST API:

+| | | |

+|JumioSettings:AuthUsername | Jumio account configuration | N/A |

+|JumioSettings:AuthPassword | Jumio account configuration | N/A |

+|AppSettings:SigningCertThumbprint|The created self-signed certificate thumbprint| N/A |

+|AppSettings:IdTokenSigningKey| Signing key created using PowerShell |N/A |

+|AppSettings:IdTokenEncryptionKey |Encryption key created using PowerShell|N/A|

+|AppSettings:IdTokenIssuer | Issuer for the JWT token (a GUID value is preferred) |N/A|

+|AppSettings:IdTokenAudience | Audience for the JWT token (a GUID value is preferred) |N/A|

+|AppSettings:BaseRedirectUrl | Azure AD B2C policy base URL | https://{your-tenant-name}.b2clogin.com/{your-application-id}|

+|WEBSITE_LOAD_CERTIFICATES| The created self-signed certificate thumbprint |N/A|

+2. Store the UI files from the [/samples/Jumio/UI/](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/Jumio/UI) in your blob container.

+1. In the UI files, go to [/samples/Jumio/UI/ocean_blue/](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/Jumio/UI/ocean_blue).

+3. Find and replace `{your-ui-blob-container-url}` with your blob container URL.

+4. Find and replace `{your-intermediate-api-url}` with the intermediate API app service URL.

+> We recommend you add consent notification on the attribute collection page. Notify users the information goes to third-party services for identity verification.

+1. Go to the Azure AD B2C policy in [/samples/Jumio/Policies/](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/Jumio/Policies).

+2. Use the instructions in [Custom policy starter pack](tutorial-create-user-flows.md?pivots=b2c-custom-policy#custom-policy-starter-pack) to download the [LocalAccounts](https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/tree/master/LocalAccounts) starter pack.

+>Update policies to relate to your tenant.

+1. Open the Azure AD B2C tenant.

+2. Under **Policies**, select **Identity Experience Framework**.

+3. Select your created **SignUpSignIn**.

+4. Select **Run user flow**.

+5. For **Application**, select the registered app (example is JWT).

+6. For **Reply URL**, select the **redirect URL**.

+7. Select **Run user flow**.

+8. Complete the sign-up flow.

+9. Create an account.

+10. After the user attribute is created, Jumio is called.

+>[!TIP]

+>If the flow is incomplete, confirm the user is, or isn't, saved in the directory.

+In this tutorial, learn how to integrate Azure Active Directory B2C (Azure AD B2C) with [LexisNexis ThreatMetrix](https://risk.lexisnexis.com/products/threatmetrix/?utm_source=bingads&utm_medium=ppc&utm_campaign=SEM%7CLNRS%7CUS%7CEN%7CTMX%7CBR%7CBing&utm_term=threat%20metrix&utm_network=o&utm_device=c&msclkid=1e85e32ec18c1ae9bbc1bc2998e026bd). Learn more about LexisNexis contact methods and [ThreatMetix](https://risk.lexisnexis.com/products/threatmetrix/?utm_source=bingads&utm_medium=ppc&utm_campaign=SEM%7CLNRS%7CUS%7CEN%7CTMX%7CBR%7CBing&utm_term=threat%20metrix&utm_network=o&utm_device=c&msclkid=1e85e32ec18c1ae9bbc1bc2998e026bd), the profiling and identity-validation service that also provides comprehensive risk assessments based on user devices.

+This integration's profiling is based on user information provided during the sign-up flow. ThreatMetrix permits the user to sign in, or not.

+ThreatMetrix risk analysis attributes:

+- Phone number

+- Profiling information collected from the user device

+- An Azure AD subscription

+ - If you don't have one, you can get an [Azure free account](https://azure.microsoft.com/free/)

+- [An Azure AD B2C tenant](./tutorial-create-tenant.md) linked to your Azure subscription

+- **Azure AD B2C** ΓÇô The authorization server that verifies user credentials, also known as the identity provider (IdP)

+- **ThreatMetrix** ΓÇô Combines user input with profiling information from the user device to verify the interaction's security

+- **Custom REST API** ΓÇô Use to implement the Azure AD B2C and ThreatMetrix integration

+ 

+1. User selects sign-up to create a new account and enters attributes. Azure AD B2C collects the attributes.

+2. Azure AD B2C calls the middle layer API and passes the user attributes.

+3. Middle layer API transforms attributes into a consumable API format and sends it to LexisNexis.

+4. LexisNexis validates user identification based on risk analysis and returns the results to the middle layer API.

+5. Middle layer API processes the results and sends relevant information to Azure AD B2C.

+6. Azure AD B2C receives information from middle layer API. If the response fails, an error message appears. If the response succeeds, the user is authenticated and granted access.

+## Create a LexisNexis account and policy

+1. To create a LexisNexis account, go to lexisnexis.com and select [Contact Us](https://risk.lexisnexis.com/products/threatmetrix/?utm_source=bingads&utm_medium=ppc&utm_campaign=SEM%7CLNRS%7CUS%7CEN%7CTMX%7CBR%7CBing&utm_term=threat%20metrix&utm_network=o&utm_device=c&msclkid=1e85e32ec18c1ae9bbc1bc2998e026bd).

+2. Create a policy using [LexisNexis documentation](https://risk.lexisnexis.com/products/threatmetrix/?utm_source=bingads&utm_medium=ppc&utm_campaign=SEM%7CLNRS%7CUS%7CEN%7CTMX%7CBR%7CBing&utm_term=threat%20metrix&utm_network=o&utm_device=c&msclkid=1e85e32ec18c1ae9bbc1bc2998e026bd).

+3. After account creation, you'll receive API configuration information. Use the following sections to complete the process.

+>You'll use the policy name later.

+### Deploy the API

+To deploy the API code to an Azure service, go to [/samples/ThreatMetrix/Api](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/ThreatMetrix/Api). You can publish the code from Visual Studio.

+>You'll need deployed service URL to configure Azure AD.

+### Configure the API

+You can [configure app settings](../app-service/configure-common.md#configure-app-settings) in the Azure App service, without checking them into a repository. You'll provide the following settings to the REST API:

+| | | |

+|ThreatMetrix:Url | ThreatMetrix account configuration |N/A|

+|ThreatMetrix:OrgId | ThreatMetrix account configuration |N/A|

+|ThreatMetrix:ApiKey |ThreatMetrix account configuration|N/A|

+|ThreatMetrix:Policy | Policy name created in ThreatMetrix |N/A|

+| BasicAuth:ApiUsername |Enter an API username| Username is used in the Azure AD B2C configuration|

+| BasicAuth:ApiPassword | Enter an API password | Password is used in the Azure AD B2C configuration|

+### Deploy the UI

+This solution uses custom UI templates loaded by Azure AD B2C. These templates do the profiling that goes to ThreatMetrix.

+Use the instructions in [custom page content walkthrough](./customize-ui-with-html.md#custom-page-content-walkthrough) to deploy the UI files in [/samples/ThreatMetrix/ui-template](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/ThreatMetrix/ui-template) to a blob storage account. The instructions include setting up a blob storage account, configuring cross-origin resource sharing (CORS), and enabling public access.

+The UI is based on the ocean blue template in [/samples/ThreatMetrix/ui-template/ocean_blue](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/ThreatMetrix/ui-template/ocean_blue). Update UI links to refer to the deployed location. In the UI folder, find and replace `https://yourblobstorage/blobcontainer` with the deployed location.

+### Create API policy keys

+To create two policy keys, follow the instructions in [add REST API username and password policy keys](./secure-rest-api.md#add-rest-api-username-and-password-policy-keys). One policy is for the API username, the other is for the API password, you created.

+Example policy key names:

+### Update the API URL

+In [samples/ThreatMetrix/policy/TrustFrameworkExtensions.xml](https://github.com/azure-ad-b2c/partner-integrations/blob/master/samples/ThreatMetrix/policy/TrustFrameworkExtensions.xml), find the `Rest-LexisNexus-SessionQuery` technical profile, and update the `ServiceUrl` metadata item with the deployed API location.

+### Update the UI URL

+In [/samples/ThreatMetrix/policy/TrustFrameworkExtensions.xml](https://github.com/azure-ad-b2c/partner-integrations/blob/master/samples/ThreatMetrix/policy/TrustFrameworkExtensions.xml), search for and replace `https://yourblobstorage/blobcontainer/` with the UI-file location.

+>We recommend you add consent notification on the attribute collection page. Notify users that information goes to third-party services for identity verification.

+### Configure the Azure AD B2C policy

+Go to the [custom policy starter pack](tutorial-create-user-flows.md?pivots=b2c-custom-policy#custom-policy-starter-pack) to download [LocalAccounts](https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/tree/master/LocalAccounts). Configure the policy in [samples/ThreatMetrix/policy/](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/ThreatMetrix/policy) for the Azure AD B2C tenant.

+>Update the policies to relate to your tenant.

+1. Open the Azure AD B2C tenant.

+2. Under **Policies**, select **User flows**.

+3. Select the created **User Flow**.

+4. Select **Run user flow**.

+5. For **Application**, select the registered app (example is JWT).

+6. For **Reply URL**, select the **redirect URL**.

+7. Select **Run user flow**.

+8. Complete the sign-up flow.

+9. Create an account.

+10. Sign out.

+11. Complete the sign-in flow.

+12. Select **Continue**.

+13. The ThreatMetrix puzzle appears.

+In this tutorial, learn to enable passwordless authentication in Azure Active Directory B2C (Azure AD B2C) with the [Nevis](https://www.nevis.net/en/solution/authentication-cloud) Access app to enable customer authentication and comply with Payment Services Directive 2 (PSD2) transaction requirements. PSD2 is a European Union (EU) directive, administered by the European Commission (Directorate General Internal Market) to regulate payment services and payment service providers throughout the EU and European Economic Area (EEA).

+- A Nevis demo account

+ - Go to nevis.net for [Nevis + Microsoft Azure AD B2C](https://www.nevis-security.com/aadb2c/) to request an account

+- An Azure AD subscription

+ - If you don't have one, you can get an [Azure free account](https://azure.microsoft.com/free/)

+- An [Azure AD B2C tenant](./tutorial-create-tenant.md) linked to your Azure subscription

+>[!NOTE]

+>To integrate Nevis into your sign-up policy flow, configure the Azure AD B2C environment to use custom policies. </br>See, [Tutorial: Create user flows and custom policies in Azure Active Directory B2C](/tutorial-create-user-flows.md?pivots=b2c-custom-policy).

+Add the branded Access app to your back-end application for passwordless authentication. The following components make up the solution:

+- **Azure AD B2C tenant** with a combined sign-in and sign-up policy for your back end

+- **Nevis instance** and its REST API to enhance Azure AD B2C

+- Your branded **Access** app

+ 

+1. A user attempts sign-in or sign-up to an application with Azure AD B2C policy.

+2. During sign-up, the Access is registered to the user device using a QR code. A private key is generated on the user device and is used to sign user requests.

+3. Azure AD B2C uses a RESTful technical profile to start sign-in with the Nevis solution.

+4. The sign-in request goes to Access, as a push message, QR code, or a deep-link.

+5. The user approves the sign-in attempt with their biometrics. A message goes to Nevis, which verifies sign-in with the stored public key.

+6. Azure AD B2C sends a request to Nevis to confirm sign-in is complete.

+7. The user is granted, or denied, access to the application with an Azure AD B2C success, or failure, message.

+### Request a Nevis account

+1. Go to nevis.net for [Nevis + Microsoft Azure AD B2C](https://www.nevis-security.com/aadb2c/).

+2. Use the form request an account.

+3. Two emails arrive:

+* Management account notification

+* Mobile app invitation

+1. From the management account trial email, copy your management key.

+2. In a browser, open https://console.nevis.cloud/.

+3. Use the management key to sign in to the management console.

+4. Select **Add Instance**.

+5. Select the created instance.

+6. In the side navigation, select **Custom Integrations**.

+8. For **Integration Name**, enter your Azure AD B2C tenant name.

+9. For **URL/Domain**, enter `https://yourtenant.onmicrosoft.com`.

+11. Select **Done**.

+### Install Nevis Access on your phone

+1. From the Nevis mobile app invitation email, open the **Test Flight app** invitation.

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

+2. Switch to your Azure AD B2C tenant. Note: the Azure AD B2C tenant usually is in a separate tenant.

+3. In the menu, select **Identity Experience Framework (IEF)**.

+4. Select **Policy Keys**.

+5. Select **Add**.

+6. Create a new key.

+7. For **Options**, select **Manual**.

+8. For **Name**, select **AuthCloudAccessToken**.

+9. For **Secret**, paste the stored **Nevis Access Token**.

+10. For **Key Usage**, select **Encryption**.

+11. Select **Create**.

+1. In your Identity Environment (IDE), go to the [/master/samples/Nevis/policy](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/Nevis/policy) folder.

+2. In [/samples/Nevis/policy/nevis.html](https://github.com/azure-ad-b2c/partner-integrations/blob/master/samples/Nevis/policy/nevis.html) open the nevis.html file.

+3. Replace the **authentication_cloud_url** with the Nevis Admin console URL `https://<instance_id>.mauth.nevis.cloud`.

+4. Select **Save**.

+5. [Create an Azure Blob storage account](/customize-ui-with-html.md#2-create-an-azure-blob-storage-account).

+6. Upload the nevis.html file to your Azure blob storage.

+7. [Configure CORS](/customize-ui-with-html.md#3-configure-cors).

+8. Enable cross-origin resource sharing (CORS) for the file.

+9. In the list, select the **nevis.html** file.

+10. In the **Overview** tab, next to the **URL**, select the **copy link** icon.

+11. Open the link in a new browser tab to confirm a grey box appears.

+### Customize TrustFrameworkBase.xml

+1. In your IDE, go to the [/samples/Nevis/policy](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/Nevis/policy) folder.

+2. Open [TrustFrameworkBase.xml](https://github.com/azure-ad-b2c/partner-integrations/blob/master/samples/Nevis/policy/TrustFrameworkBase.xml).

+3. Replace **your tenant** with your Azure tenant account name in **TenantId**.

+4. Replace **your tenant** with your Azure tenant account name in **PublicPolicyURI**.

+5. Replace all **authentication_cloud_url** instances with the Nevis Admin console URL.

+6. Select **Save**.

+### Customize TrustFrameworkExtensions.xml

+1. In your IDE, go to the [/samples/Nevis/policy](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/Nevis/policy) folder.

+2. Open [TrustFrameworkExtensions.xml](https://github.com/azure-ad-b2c/partner-integrations/blob/master/samples/Nevis/policy/TrustFrameworkExtensions.xml).

+3. Replace **your tenant** with your Azure tenant account name in **TenantId**.

+4. Replace **your tenant** with your Azure tenant account name in **PublicPolicyURI**.

+5. Under **BasePolicy**, in the **TenantId**, replace **your tenant** with your Azure tenant account name.

+6. Under **BuildingBlocks**, replace **LoadUri** with the nevis.html blob link URL, in your blob storage account.

+7. Select **Save**.

+### Customize SignUpOrSignin.xml

+1. In your IDE, go to the [/samples/Nevis/policy](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/Nevis/policy) folder.

+2. Open the [SignUpOrSignin.xml](https://github.com/azure-ad-b2c/partner-integrations/blob/master/samples/Nevis/policy/SignUpOrSignin.xml) file.

+3. Replace **your tenant** with your Azure tenant account name in **TenantId**.

+4. Replace **your tenant** with your Azure tenant account name in **PublicPolicyUri**.

+5. Under **BasePolicy**, in **TenantId**, replace **your tenant** with your Azure tenant account name.

+6. Select **Save**.

+### Upload custom policies to Azure AD B2C

+1. In the Azure portal, open your [Azure AD B2C tenant](https://portal.azure.com/#blade/Microsoft_AAD_B2CAdmin/TenantManagementMenuBlade/overview).

+### Test account creation and Access setup

+1. In the Azure portal, open your [Azure AD B2C tenant](https://portal.azure.com/#blade/Microsoft_AAD_B2CAdmin/TenantManagementMenuBlade/overview).

+3. Scroll down to **Custom policies** and select **B2C_1A_signup_signin**.

+5. In the window, select **Sign up now**.

+8. Copy the verification code from the email.

+10. Fill in the form with your new password and display name.

+12. The QR code scan page appears.

+15. The **Authenticator registration was successful** screen appears.

+16. Select **Continue**.

+17. On your phone, authenticate with your face.

+18. The [jwt.ms welcome](https://jwt.ms) page appears with your decoded token details.

+### Test passwordless sign-in

+3. In the window, select **Passwordless Authentication**.

+6. On your phone, in Notifications, select **Nevis Access app notification**.

+8. The [jwt.ms welcome](https://jwt.ms) page appears with your tokens.

+In this tutorial, learn how to integrate Azure Active Directory B2C (Azure AD B2C) with [Onfido](https://onfido.com/), a document ID and facial biometrics verification app. Use it to meet *Know Your Customer* and identity requirements. Onfido uses artificial intelligence (AI) technology that verifies identity by matching a photo ID with facial biometrics. The solution connects a digital identity to a person, provides a reliable onboarding experience, and helps reduce fraud.

+In this tutorial, you'll enable the Onfido service to verify identity in the sign-up, or sign-in, flow. Onfido results inform decisions about which products or services the user accesses.

+- An Azure AD subscription

+ - If you don't have on, you can get an [Azure free account](https://azure.microsoft.com/free/)

+- [An Azure AD B2C tenant](./tutorial-create-tenant.md) linked to your Azure subscription

+- An Onfido trial account

+ - Go to onfido.com [Contact us](https://onfido.com/signup/) and fill out the form

+- **Azure AD B2C tenant** ΓÇô The authorization server that verifies user credentials based on custom policies defined in the tenant. It's also known as the identity provider (IdP). It hosts the Onfido client app, which collects the user documents and transmits them to the Onfido API service.

+- **Onfido client** ΓÇô A configurable, JavaScript client document-collection utility deployed in webpages. It checks details such as document size and quality.

+- **Intermediate REST API** ΓÇô Provides endpoints for the Azure AD B2C tenant to communicate with the Onfido API service. It handles data processing and adheres to security requirements of both.

+- **Onfido API service** ΓÇô The back-end service, which saves and verifies user documents.

+The following architecture diagram shows the implementation.

+ 

+1. User signs up to create a new account and enters attributes. Azure AD B2C collects the attributes. Onfido client app hosted in Azure AD B2C checks for the user information.

+2. Azure AD B2C calls the middle layer API and passes the attributes.

+3. Middle layer API collects attributes and converts them to an Onfido API format.

+4. Onfido processes attributes to validate user identification and sends result to the middle layer API.

+5. Middle layer API processes the results and sends relevant information to Azure AD B2C, in JavaScript Object Notation (JSON) format.

+6. Azure AD B2C receives the information. If the response fails, an error message appears. If the response succeeds, the user is authenticated and written into the directory.

+## Create an Onfido account

+1. Create an Onfido account: go to onfido.com [Contact us](https://onfido.com/signup/) and fill out the form.

+2. Create an API key: go to [Get started (API v3.5)](https://documentation.onfido.com/).

+>[!NOTE]

+> You'll need the key later.

+### Onfido documentation

+Live keys are billable, however, you can use the sandbox keys for testing. Go to onfido.com for, [Sandbox and live differences](https://documentation.onfido.com/?javascript#sandbox-and-live-differences). The sandbox keys produce the same result structure as live keys, however, results are predetermined. Documents aren't processed or saved.

+For more Onfido documentation, see:

+* [Onfido API documentation](https://documentation.onfido.com)

+* [Onfido Developer Hub](https://developers.onfido.com)

+### Deploy the API

+1. Deploy the API code to an Azure service. Go to [samples/OnFido-Combined/API/Onfido.Api/](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/OnFido-Combined/API/Onfido.Api). You can publish the code from Visual Studio.

+2. Set up cross-origin resource sharing (CORS).

+3. Add **Allowed Origin** as `https://{your_tenant_name}.b2clogin.com`.

+>You'll need the deployed service URL to configure Azure AD.

+[Configure app settings](../app-service/configure-common.md#configure-app-settings) in the Azure App service without checking them into a repository.

+REST API settings:

+* **Application setting name**: OnfidoSettings:AuthToken

+* **Source**: Onfido Account

+### Deploy the UI

+#### Configure your storage location

+1. In the Azure portal, [create a container](../storage/blobs/storage-quickstart-blobs-portal.md#create-a-container).

+2. Store the UI files in [/samples/OnFido-Combined/UI](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/OnFido-Combined/UI), in your blob container.

+3. Allow CORS access to the storage container you created: Go to **Settings** >**Allowed Origin**.

+4. Enter `https://{your_tenant_name}.b2clogin.com`.

+5. Replace your tenant name with your Azure AD B2C tenant name, using lower-case letters. For example, `https://fabrikam.b2clogin.com`.

+6. For **Allowed Methods**, select `GET` and `PUT`.

+7. Select **Save**.

+1. In the UI files, go to [samples/OnFido-Combined/UI/ocean_blue](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/OnFido-Combined/UI/ocean_blue).

+3. Find `{your-ui-blob-container-url}`, and replace it with your UI **ocean_blue**, **dist**, and **assets** folder URLs.

+4. Find `{your-intermediate-api-url}`, and replace it with the intermediate API app service URL.

+1. Store the UI folder files in your blob container.

+2. [Use Azure Storage Explorer to manage Azure managed disks](../virtual-machines/disks-use-storage-explorer-managed-disks.md) and access permissions.

+### Configure Azure AD B2C

+In [/samples/OnFido-Combined/Policies](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/OnFido-Combined/Policies), find the following placeholders and replace them with the corresponding values from your instance.

+|Placeholder|Replace with value|Example|

+||||

+|{your_tenant_name}|Your tenant short name|"your tenant" from yourtenant.onmicrosoft.com|

+|{your_tenantID}|Your Azure AD B2C TenantID| 01234567-89ab-cdef-0123-456789abcdef|

+|{your_tenant_IdentityExperienceFramework_appid}|IdentityExperienceFramework app App ID configured in your Azure AD B2C tenant|01234567-89ab-cdef-0123-456789abcdef|

+|{your_tenant_ ProxyIdentityExperienceFramework_appid}|ProxyIdentityExperienceFramework app App ID configured in your Azure AD B2C tenant| 01234567-89ab-cdef-0123-456789abcdef|

+|{your_tenant_extensions_appid}|Your tenant storage application App ID| 01234567-89ab-cdef-0123-456789abcdef|

+|{your_tenant_extensions_app_objectid}|Your tenant storage application Object ID| 01234567-89ab-cdef-0123-456789abcdef|

+|{your_app_insights_instrumentation_key}|Your app insights instance* instrumentation key|01234567-89ab-cdef-0123-456789abcdef|

+|{your_ui_file_base_url}|Location URL of your UI folders **ocean_blue**, **dist**, and **assets**| `https://yourstorage.blob.core.windows.net/UI/`|

+|{your_app_service_URL}|The app service URL you set up|`https://yourapp.azurewebsites.net`|

+*App insights can be in a different tenant. This step is optional. Remove the corresponding TechnicalProfiles and OrchestrationSteps, if they're not needed.

+### Configure Azure AD B2C policy

+See, [Custom policy starter pack](tutorial-create-user-flows.md?pivots=b2c-custom-policy#custom-policy-starter-pack) for instructions to set up your Azure AD B2C tenant and configure policies. Custom policies are a set of XML files you upload to your Azure AD B2C tenant to define technical profiles and user journeys.

+>We recommend you add consent notification on the attribute collection page. Notify users that information goes to third-party services for identity verification.

+1. Open the Azure AD B2C tenant.

+2. Under **Policies** select **Identity Experience Framework**.

+3. Select your previously created **SignUpSignIn**.

+4. Select **Run user flow**.

+5. For **Application**, select the registered app (example is JWT).

+6. For **Reply URL**, select the **redirect URL**.

+7. Select **Run user flow**.

+8. Complete the sign-up flow.

+9. Create an account.

+10. When the user attribute is created, Onfido is called during the flow.

+>[!NOTE]

+>If the flow is incomplete, confirm the user is saved in the directory.

+In this tutorial, learn how to extend the capabilities of Azure Active Directory B2C (Azure AD B2C) with [PingAccess](https://www.pingidentity.com/en/software/pingaccess.html#:~:text=%20Modern%20Access%20Managementfor%20the%20Digital%20Enterprise%20,consistent%20enforcement%20of%20security%20policies%20by...%20More) and [PingFederate](https://www.pingidentity.com/en/software/pingfederate.html). PingAccess provides access to applications and APIs, and a policy engine for authorized user access. PingFederate is an enterprise federation server for user authentication and single sign-on, an authority that permits customers, employees, and partners to access applications from devices. Use them together to enable secure hybrid access (SHA).

+Many e-commerce sites and web applications exposed to the internet are deployed behind proxy systems, or a reverse-proxy system. These proxy systems pre-authenticate, enforce policy, and route traffic. Typical scenarios include protecting web applications from inbound web traffic and providing a uniform session management across distributed server deployments.

+Generally, configurations include an authentication translation layer that externalizes the authentication from the web application. Reverse proxies provide the authenticated user context to the web applications, such as a header value in clear or digest form. The applications aren't using industry standard tokens such as Security Assertion Markup Language (SAML), OAuth, or Open ID Connect (OIDC). Instead, the proxy provides authentication context and maintains the session with the end-user agent such as browser or native application. As a service running as a man-in-the-middle, proxies provide significant session control. The proxy service is efficient and scalable, not a bottleneck for applications behind the proxy service. The diagram is a reverse-proxy implementation and communications flow.

+ 

+## Modernization

+If you want to modernize an identity platform in such configurations, there might be customer concerns:

+- Decouple the effort to modernize applications from modernizing an identity platform

+- Environments with modern and legacy authentication, consuming from the modernized identity service provider

+ - Drive the end-user experience consistency

+ - Provide a single sign-in experience across applications

+In answer to these concerns, the approach in this tutorial is an Azure AD B2C, [PingAccess](https://www.pingidentity.com/en/software/pingaccess.html#:~:text=%20Modern%20Access%20Managementfor%20the%20Digital%20Enterprise%20,consistent%20enforcement%20of%20security%20policies%20by...%20More), and [PingFederate](https://www.pingidentity.com/en/software/pingfederate.html) integration.

+## Shared environment

+A technically viable, and cost-effective, solution is to configure the reverse proxy system to use the modernized identity system, delegating authentication.

+Proxies support the modern authentication protocols and use the redirect-based (passive) authentication that sends users to the new identity provider (IdP).

+### Azure AD B2C as an identity provider

+In Azure AD B2C, you define policies that drive user experiences and behaviors, also called user journeys. Each such policy exposes a protocol endpoint that can perform the authentication as an IdP. On the application side, there's no special handling required for certain policies. An application makes a standard authentication request to the protocol-specific authentication endpoint exposed by a policy.

+You can configure Azure AD B2C to share the same issuer across policies or unique issuer for each policy. Each application can point to policies by making a protocol-native authentication request, which drives user behaviors such as sign-in, sign-up, and profile edits. The diagram shows OIDC and SAML application workflows.

+ 

+The scenario can be challenging for the legacy applications to redirect the user accurately. The access request to the applications might not include the user experience context. In most cases, the proxy layer, or an integrated agent on the web application, intercepts the access request.

+### PingAccess reverse proxy

+You can deploy PingAccess as the reverse proxy. PingAccess intercepts a direct request by being the man-in-the-middle, or as a redirect from an agent running on the web application server.

+Configure PingAccess with OIDC, OAuth2, or SAML for authentication with an upstream authentication provider. You can configure an upstream IdP for this purpose on the PingAccess server. See the following diagram.

+ 

+In a typical Azure AD B2C deployment with policies exposing IdPs, there's a challenge. PingAccess is configured with one, upstream IdP.

+### PingFederate federation proxy

+You can configure PingFederate as an authentication provider, or a proxy. for upstream IdPs. See the following diagram.

+ 

+Use this function to contextually, dynamically, or declaratively switch an inbound request to an Azure AD B2C policy. See the following diagram of protocol sequence flow.

+ 

+- An Azure subscription

+ - If you don't have one, get an [Azure free account](https://azure.microsoft.com/free/)

+- An [Azure AD B2C tenant](/tutorial-create-tenant.md) linked to your Azure subscription

+- PingAccess and PingFederate deployed in Docker containers or on Azure virtual machines (VMs)

+## Connectivity and communication

+Confirm the following connectivity and communication.

+- **PingAccess server** ΓÇô Communicates with the PingFederate server, client browser, OIDC, OAuth well-known and keys discovery published by the Azure AD B2C service and PingFederate server

+- **PingFederate server** ΓÇô Communicates with the PingAccess server, client browser, OIDC, OAuth well-known and keys discovery published by the Azure AD B2C service

+- **Legacy or header-based AuthN application** ΓÇô Communicates to and from PingAccess server

+- **SAML relying party application** ΓÇô Reaches the browser traffic from the client. Accesses the SAML federation metadata published by the Azure AD B2C service.

+- **Modern application** ΓÇô Reaches the browser traffic from the client. Accesses the OIDC, OAuth well-known, and keys discovery published by the Azure AD B2C service.

+- **REST API** ΓÇô Reaches the traffic from a native or web client. Accesses the OIDC, OAuth well-known, and keys discovery published by the Azure AD B2C service

+You can use basic user flows or advanced Identity Enterprise Framework (IEF) policies. PingAccess generates the metadata endpoint, based on the issuer value, by using the [WebFinger](https://tools.ietf.org/html/rfc7033) protocol for discovery convention. To follow this convention, update the Azure AD B2C issuer using user-flow policy properties.

+ 

+In the advanced policies, configuration includes the IssuanceClaimPattern metadata element to AuthorityWithTfp value in the [JWT token issuer technical profile](./jwt-issuer-technical-profile.md).

+## Configure PingAccess and PingFederate

+Use the instructions in the following sections to configure PingAccess and PingFederate. See the following diagram of the overall integration user flow.

+ 

+To configure PingFederate as the token provider for PingAccess, ensure connectivity from PingFederate to PingAccess. Confirm connectivity from PingAccess to PingFederate.

+Go to pingidentity.com for, [Configure PingFederate as the token provider for PingAccess](https://docs.pingidentity.com/bundle/pingaccess-61/page/zgh1581446287067.html).

+Use the following instructions to create a PingAccess application for the target web application, for header-based authentication.

+#### Create a virtual host

+>Create a virtual host for every application. For more information, see [What can I configure with PingAccess?]([https://docs.pingidentity.com/bundle/pingaccess-43/page/reference/pa_c_KeyConsiderations.html](https://docs.pingidentity.com/bundle/pingaccess-71/page/kkj1564006722708.html).

+To create a virtual host:

+1. Go to **Settings** > **Access** > **Virtual Hosts**.

+2. Select **Add Virtual Host**.

+3. For **Host**, enter the FQDN portion of the Application URL.

+4. For **Port**, enter **443**.

+5. Select **Save**.

+#### Create a web session

+To create a web session:

+1. Navigate to **Settings** > **Access** > **Web Sessions**.

+2. Select **Add Web Session**.

+3. Enter a **Name** for the web session.

+4. Select the **Cookie Type**: **Signed JWT** or **Encrypted JWT**.

+5. Enter a unique value for **Audience**.

+6. For **Client ID**, enter the **Azure AD Application ID**.

+7. For **Client Secret**, enter the **Key** you generated for the application in Azure AD.

+8. (Optional) Create and use custom claims with the Microsoft Graph API: Select **Advanced**. Deselect **Request Profile** and **Refresh User Attributes**. Learn more about custom claims: [Header-based single sign-on for on-premises apps with Azure AD App Proxy](../active-directory/app-proxy/application-proxy-configure-single-sign-on-with-headers.md).

+#### Create identity mapping

+>You can use identity mapping with more than one application, if they're expecting the same data in the header.

+To create identity mapping:

+1. Go to **Settings** > **Access** > **Identity Mappings**.

+2. Select **Add Identity Mapping**.

+3. Specify a **Name*.

+4. Select the identity-mapping **Type of Header Identity Mapping**.

+ | Attribute name | Header name |

+#### Create a site

+>In some configurations, a site can contain multiple applications. You can use a site with more than one application, when appropriate.

+To create a site:

+1. Go to **Main** > **Sites**.

+2. Select **Add Site**.

+3. Enter the site **Name**.

+4. Enter the site **Target**. The target is the hostname:port pair for the server hosting the application. Don't enter the application path in this field. For example, an application at https://mysite:9999/AppName has a target value of mysite:9999.

+5. Indicate if the target expects secure connections.

+6. If the target expects secure connections, set the Trusted Certificate Group to **Trust Any**.

+7. Select **Save**.

+#### Create an application

+To create an application in PingAccess for each application in Azure that you want to protect.

+If you've developed apps against Azure Active Directory (v1.0) endpoint in the past, you're likely using ADAL. Since Microsoft identity platform (v2.0) endpoint has changed significantly enough, the new library (MSAL) was built for the new endpoint entirely.

+ Title: Add Azure AD Account as an identity provider

+description: Use Azure Active Directory to enable an external user (guest) to sign in to your Azure AD apps with their Azure AD work or school account.

+Azure Active Directory is available as an identity provider option for [B2B collaboration](what-is-b2b.md#integrate-with-identity-providers) by default. If an external guest user has an Azure AD account through work or school, they can redeem your B2B collaboration invitations or complete your sign-up user flows using their Azure AD account.

+When you [invite a guest user](add-users-administrator.md) to B2B collaboration, you can specify their Azure AD account as the **Email address** they'll use to sign in.

+- **Azure multifactor authentication**

+> [!VIDEO https://learn-video.azurefd.net/vod/player?show=on-net&ep=using-azure-managed-identities]

+* 05/25/2022 - **Schema Discovery** feature enabled on this app.

+* 12/22/2022 - The source attribute of **addresses[type eq "work"].formatted** ha been changed to **Join("", [streetAddress], IIF(IsPresent([city]),", ",""), [city], IIF(IsPresent([state]),", ",""), [state], IIF(IsPresent([postalCode])," ",""), [postalCode]) --> addresses[type eq "work"].formatted**.

+1. Under the **Mappings** section, select **Provision Azure Active Directory Users**.

+1. Under the **Mappings** section, select **Provision Azure Active Directory Groups**.

+To configure single sign-on in Tripwire Enterprise, please see **Using Tripwire Enterprise with SAML Authentication** section in the Tripwire Enterprise Hardeing Guide, available for download on the [Tripwire Customer Center](https://tripwireinc.force.com/customers/home). If you require assistance, contact [Tripwire Enterprise support team](mailto:support@tripwire.com).

+To create a Tripwire Enterprise user, please see **Creating a User Account** section in the Tripwire Enterprise User Guide, available for download on the [Tripwire Customer Center](https://tripwireinc.force.com/customers/home). If you require assistance, contact [Tripwire Enterprise support team](mailto:support@tripwire.com).

+In CMMC Level 1, there are three domains that have one or more practices related to identity:

+In CMMC Level 2, there are 13 domains that have one or more practices related to identity:

+* Access Control

+* Audit & Accountability

+* Configuration Management

+* Identification & Authentication

+* Incident Response

+* Maintenance

+* Media Protection

+* Personnel Security

+* Physical Protection

+* Risk Assessment

+* Security Assessment

+* System and Communications Protection

+* System and Information Integrity

+The remaining articles in this series provide guidance and links to resources, organized by level and domain. For each domain, there's a table with the relevant controls listed, and links to guidance to accomplish the practice.

+In CMMC Level 1, there are three domains that have one or more practices related to identity:

+The following table provides a list of practice statement and objectives, and Azure AD guidance and recommendations to enable you to meet these requirements with Azure AD.

+| CMMC practice statement and objectives | Azure AD guidance and recommendations |

+| AC.L1-3.1.1<br><br>**Practice statement:** Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).<br><br>**Objectives:**<br>Determine if:<br>[a.] authorized users are identified;<br>[b.] processes acting on behalf of authorized users are identified;<br>[c.] devices (and other systems) authorized to connect to the system are identified;<br>[d.] system access is limited to authorized users;<br>[e.] system access is limited to processes acting on behalf of authorized users; and<br>[f.] system access is limited to authorized devices (including other systems). | You're responsible for setting up Azure AD accounts, which is accomplished from external HR systems, on-premises Active Directory, or directly in the cloud. You configure Conditional Access to only grant access from a known (Registered/Managed) device. In addition, apply the concept of least privilege when granting application permissions. Where possible, use delegated permission. <br><br>Set up users<br><li>[Plan cloud HR application to Azure Active Directory user provisioning](../app-provisioning/plan-cloud-hr-provision.md) <li>[Azure AD Connect sync: Understand and customize synchronization](../hybrid/how-to-connect-sync-whatis.md)<li>[Add or delete users ΓÇô Azure Active Directory](../fundamentals/add-users-azure-active-directory.md)<br><br>Set up devices<li>[What is device identity in Azure Active Directory](../devices/overview.md)<br><br>Configure applications<li>[QuickStart: Register an app in the Microsoft identity platform](../develop/quickstart-register-app.md)<li>[Microsoft identity platform scopes, permissions, & consent](../develop/v2-permissions-and-consent.md)<li>[Securing service principals in Azure Active Directory](../fundamentals/service-accounts-principal.md)<br><br>Conditional access<li>[What is Conditional Access in Azure Active Directory](../conditional-access/overview.md)<li>[Conditional Access require managed device](../conditional-access/require-managed-devices.md) |

+| AC.L1-3.1.2<br><br>**Practice statement:** Limit information system access to the types of transactions and functions that authorized users are permitted to execute.<br><br>**Objectives:**<br>Determine if:<br>[a.] the types of transactions and functions that authorized users are permitted to execute are defined; and<br>[b.] system access is limited to the defined types of transactions and functions for authorized users. | You're responsible for configuring access controls such as Role Based Access Controls (RBAC) with built-in or custom roles. Use role assignable groups to manage role assignments for multiple users requiring same access. Configure Attribute Based Access Controls (ABAC) with default or custom security attributes. The objective is to granularly control access to resources protected with Azure AD.<br><br>Set up RBAC<li>[Overview of role-based access control in Active Directory ](../roles/custom-overview.md)[Azure AD built-in roles](../roles/permissions-reference.md)<li>[Create and assign a custom role in Azure Active Directory](../roles/custom-create.md)<br><br>Set up ABAC<li>[What is Azure attribute-based access control (Azure ABAC)](/azure/role-based-access-control/conditions-overview)<li>[What are custom security attributes in Azure AD?](/azure/active-directory/fundamentals/custom-security-attributes-overview)<br><br>Configure groups for role assignment<li>[Use Azure AD groups to manage role assignments](../roles/groups-concept.md) |

+| AC.L1-3.1.20<br><br>**Practice statement:** Verify and control/limit connections to and use of external information systems.<br><br>**Objectives:**<br>Determine if:<br>[a.] connections to external systems are identified;<br>[b.] the use of external systems is identified;<br>[c.] connections to external systems are verified;<br>[d.] the use of external systems is verified;<br>[e.] connections to external systems are controlled and or limited; and<br>[f.] the use of external systems is controlled and or limited. | You're responsible for configuring conditional access policies using device controls and or network locations to control and or limit connections and use of external systems. Configure Terms of Use (TOU) for recorded user acknowledgment of terms and conditions for use of external systems for access.<br><br>Set up Conditional Access as required<li>[What is Conditional Access?](../conditional-access/overview.md)<li>[Require managed devices for cloud app access with Conditional Access](../conditional-access/require-managed-devices.md)<li>[Require device to be marked as compliant](../conditional-access/require-managed-devices.md)<li>[Conditional Access: Filter for devices](/azure/active-directory/conditional-access/concept-condition-filters-for-devices)<br><br>Use Conditional Access to block access<li>[Conditional Access - Block access by location](../conditional-access/howto-conditional-access-policy-location.md)<br><br>Configure terms of use<li>[Terms of use - Azure Active Directory](../conditional-access/terms-of-use.md)<li>[Conditional Access require terms of use ](../conditional-access/require-tou.md) |

+| AC.L1-3.1.22<br><br>**Practice statement:** Control information posted or processed on publicly accessible information systems.<br><br>**Objectives:**<br>Determine if:<br>[a.] individuals authorized to post or process information on publicly accessible systems are identified;<br>[b.] procedures to ensure FCI isn't posted or processed on publicly accessible systems are identified;<br>[c.] a review process is in place prior to posting of any content to publicly accessible systems; and<br>[d.] content on publicly accessible systems is reviewed to ensure that it doesn't include federal contract information (FCI). | You're responsible for configuring Privileged Identity Management (PIM) to manage access to systems where posted information is publicly accessible. Require approvals with justification prior to role assignment in PIM. Configure Terms of Use (TOU) for systems where posted information is publicly accessible for recorded acknowledgment of terms and conditions for posting of publicly accessible information.<br><br>Plan PIM deployment<li>[What is Privileged Identity Management?](../privileged-identity-management/pim-configure.md)<li>[Plan a Privileged Identity Management deployment](../privileged-identity-management/pim-deployment-plan.md)<br><br>Configure terms of use<li>[Terms of use - Azure Active Directory](../conditional-access/terms-of-use.md)<li>[Conditional Access require terms of use ](../conditional-access/require-tou.md)<li>[Configure Azure AD role settings in PIM - Require Justification](../privileged-identity-management/pim-how-to-change-default-settings.md) |

+The following table provides a list of practice statement and objectives, and Azure AD guidance and recommendations to enable you to meet these requirements with Azure AD.

+| CMMC practice statement and objectives | Azure AD guidance and recommendations |

+| IA.L1-3.5.1<br><br>**Practice statement:** Identify information system users, processes acting on behalf of users, or devices.<br><br>**Objectives:**<br>Determine if:<br>[a.] system users are identified;<br>[b.] processes acting on behalf of users are identified; and<br>[c.] devices accessing the system are identified. | Azure AD uniquely identifies users, processes (service principal/workload identities), and devices via the ID property on the respective directory objects. You can filter log files to help with your assessment using the following links. Use the following reference to meet assessment objectives.<br><br>Filtering logs by user properties<li>[User resource type: ID Property](/graph/api/resources/user?view=graph-rest-1.0&preserve-view=true)<br><br>Filtering logs by service properties<li>[ServicePrincipal resource type: ID Property](/graph/api/resources/serviceprincipal?view=graph-rest-1.0&preserve-view=true)<br><br>Filtering logs by device properties<li>[Device resource type: ID Property](/graph/api/resources/device?view=graph-rest-1.0&preserve-view=true) |

+IA.L1-3.5.2<br><br>**Practice statement:** Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.<br><br>**Objectives:**<br>Determine if:<br>[a.] the identity of each user is authenticated or verified as a prerequisite to system access;<br>[b.] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access; and<br>[c.] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access. | Azure AD uniquely authenticates or verifies each user, process acting on behalf of user, or device as a prerequisite to system access. Use the following reference to meet assessment objectives.<br><br>Set up user accounts<li>[What is Azure Active Directory authentication?](../authentication/overview-authentication.md)<br><br>[Configure Azure Active Directory to meet NIST authenticator assurance levels](../standards/nist-overview.md)<br><br>Set up service principal accounts<li>[Service principal authentication](../fundamentals/service-accounts-principal.md)<br><br>Set up device accounts<li>[What is a device identity?](../devices/overview.md)<li>[How it works: Device registration](../devices/device-registration-how-it-works.md)<li>[What is a Primary Refresh Token?](../devices/concept-primary-refresh-token.md)<li>What does the PRT contain |

+The following table provides a list of practice statement and objectives, and Azure AD guidance and recommendations to enable you to meet these requirements with Azure AD.

+| CMMC practice statement | Azure AD guidance and recommendations |

+| SI.L1-3.14.1 - Identify, report, and correct information and information system flaws in a timely manner.<br><br>SI.L1-3.14.2 - Provide protection from malicious code at appropriate locations in organizational information systems.<br><br>SI.L1-3.14.4 - Update malicious code protection mechanisms when new releases are available.<br><br>SI.L1-3.14.5 - Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed. | **Consolidated Guidance for legacy managed devices**<br>Configure conditional access to require Hybrid Azure AD joined device. For devices joined to an on-premises AD, it's assumed that the control over these devices is enforced using management solutions such as Configuration Manager or group policy (GP). Because there's no method for Azure AD to determine whether any of these methods has been applied to a device, requiring a hybrid Azure AD joined device is a relatively weak mechanism to require a managed device. The administrator judges whether the methods applied to your on-premises domain-joined devices are strong enough to constitute a managed device, if the device is also a Hybrid Azure AD joined device.<br><br>**Consolidated guidance for cloud-managed (or co-management) devices**<br>Configure conditional access to require a device to be marked as compliant, the strongest form to request a managed device. This option requires device registration with Azure AD, and indicated as compliant by Intune or a third-party mobile device management (MDM) system that manages Windows 10 devices via Azure AD integration.

+In CMMC Level 2, there are 13 domains that have one or more practices related to identity:

+The following table provides a list of practice statement and objectives, and Azure AD guidance and recommendations to enable you to meet these requirements with Azure AD.

+| CMMC practice statement and objectives | Azure AD guidance and recommendations |

+| AC.L2-3.1.3<br><br>**Practice statement:** Control the flow of CUI in accordance with approved authorizations.<br><br>**Objectives:**<br>Determine if:<br>[a.] information flow control policies are defined;<br>[b.] methods and enforcement mechanisms for controlling the flow of CUI are defined;<br>[c.] designated sources and destinations (for example, networks, individuals, and devices) for CUI within the system and between intercfeetonnected systems are identified;<br>[d.] authorizations for controlling the flow of CUI are defined; and<br>[e.] approved authorizations for controlling the flow of CUI are enforced. | Configure Conditional Access policies to control the flow of CUI from trusted locations, trusted devices, approved applications and require app protection policy. For finer grained authorization to CUI, configure app-enforced restrictions(Exchange/SharePoint Online), App Control (with Microsoft Defender for Cloud Apps), Authentication Context. Deploy Azure AD Application Proxy to secure access to on-premises applications.<br>[Location condition in Azure Active Directory Conditional Access ](../conditional-access/location-condition.md)<br>[Grant controls in Conditional Access policy - Require device to be marked as compliant](../conditional-access/concept-conditional-access-grant.md)<br>[Grant controls in Conditional Access policy - Require hybrid Azure AD joined device](../conditional-access/concept-conditional-access-grant.md)<br>[Grant controls in Conditional Access policy - Require approved client app](../conditional-access/concept-conditional-access-grant.md)<br>[Grant controls in Conditional Access policy - Require app protection policy](../conditional-access/concept-conditional-access-grant.md)<br>[Session controls in Conditional Access policy - Application enforced restrictions](../conditional-access/concept-conditional-access-session.md)<br>[Protect with Microsoft Defender for Cloud Apps Conditional Access App Control](/defender-cloud-apps/proxy-intro-aad)<br>[Cloud apps, actions, and authentication context in Conditional Access policy ](../conditional-access/concept-conditional-access-cloud-apps.md)<br>[Remote access to on-premises apps using Azure AD Application Proxy](../app-proxy/application-proxy.md)<br><br>**Authentication Context**<br>[Configuring Authentication context & Assign to Conditional Access Policy](../conditional-access/concept-conditional-access-cloud-apps.md)<br><br>**Information Protection**<br>Know and protect your data; help prevent data loss.<br>[Protect your sensitive data with Microsoft Purview](/microsoft-365/compliance/information-protection?view=o365-worldwide&preserve-view=true)<br><br>**Conditional Access**<br>[Conditional Access for Azure information protection (AIP)](https://techcommunity.microsoft.com/t5/security-compliance-and-identity/conditional-access-policies-for-azure-information-protection/ba-p/250357) <br><br>**Application Proxy**<br>[Remote access to on-premises apps using Azure AD Application Proxy](../app-proxy/application-proxy.md) |

+|AC.L2-3.1.4<br><br>**Practice statement:** Separate the duties of individuals to reduce the risk of malevolent activity without collusion.<br><br>**Objectives:**<br>Determine if:<br>[a.] the duties of individuals requiring separation are defined;<br>[b.] responsibilities for duties that require separation are assigned to separate individuals; and<br>[c.] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals. | Ensuring adequate separation of duties by scoping appropriate access. Configure Entitlement Management Access packages to govern access to applications, groups, Teams and SharePoint sites. Configure Separation of Duties checks within access packages to avoid a user obtaining excessive access. In Azure AD entitlement management, you can configure multiple policies, with different settings for each user community that will need access through an access package. This configuration includes restrictions such that a user of a particular group, or already assigned a different access package, isn't assigned other access packages, by policy.<br><br>Configure administrative units in Azure Active Directory to scope administrative privilege so that administrators with privileged roles are scoped to only have those privileges on limited set of directory objects(users, groups, devices).<br>[What is entitlement management?](../governance/entitlement-management-overview.md)<br>[What are access packages and what resources can I manage with them?](../governance/entitlement-management-overview.md)<br>[Configure separation of duties for an access package in Azure AD entitlement management](../governance/entitlement-management-access-package-incompatible.md)<br>[Administrative units in Azure Active Directory](../roles/administrative-units.md)|

+| AC.L2-3.1.5<br><br>**Practice statement:** Employ the principle of least privilege, including specific security functions and privileged accounts.<br><br>**Objectives:**<br>Determine if:<br>[a.] privileged accounts are identified;<br>[b.] access to privileged accounts is authorized in accordance with the principle of least privilege;<br>[c.] security functions are identified; and<br>[d.] access to security functions is authorized in accordance with the principle of least privilege. | You're responsible for implementing and enforcing the rule of least privilege. This action can be accomplished with Privileged Identity Management for configuring enforcement, monitoring, and alerting. Set requirements and conditions for role membership.<br><br>Once privileged accounts are identified and managed, use [Entitlement Lifecycle Management](../governance/entitlement-management-overview.md) and [Access reviews](../governance/access-reviews-overview.md) to set, maintain and audit adequate access. Use the [MS Graph API](/graph/api/directoryrole-list-members?view=graph-rest-1.0&tabs=http&preserve-view=true) to discover and monitor directory roles.<br><br>**Assign roles**<br>[Assign Azure AD roles in PIM](../privileged-identity-management/pim-how-to-add-role-to-user.md)<br>[Assign Azure resource roles in Privileged Identity Management](../privileged-identity-management/pim-resource-roles-assign-roles.md)<br>[Assign eligible owners and members for privileged access groups](../privileged-identity-management/groups-assign-member-owner.md)<br><br>**Set role settings** <br>[Configure Azure AD role settings in PIM](../privileged-identity-management/pim-how-to-change-default-settings.md)<br>[Configure Azure resource role settings in PIM](../privileged-identity-management/pim-resource-roles-configure-role-settings.md)<br>[Configure privileged access groups settings in PIM](../privileged-identity-management/groups-role-settings.md)<br><br>**Set up alerts**<br>[Security alerts for Azure AD roles in PIM](../privileged-identity-management/pim-how-to-configure-security-alerts.md)<br>[Configure security alerts for Azure resource roles in Privileged Identity Management](../privileged-identity-management/pim-resource-roles-configure-alerts.md) |

+| AC.L2-3.1.6<br><br>**Practice statement:** Use non-privileged accounts or roles when accessing non security functions.<br><br>**Objectives:**<br>Determine if:<br>[a.] non security functions are identified; and <br>[b.] users are required to use non-privileged accounts or roles when accessing non security functions.<br><br>AC.L2-3.1.7<br><br>**Practice statement:** Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.<br><br>**Objectives:**<br>Determine if:<br>[a.] privileged functions are defined;<br>[b.] non-privileged users are defined;<br>[c.] non-privileged users are prevented from executing privileged functions; and<br>[d.] the execution of privileged functions is captured in audit logs. |Requirements in AC.L2-3.1.6 and AC.L2-3.1.7 complement each other. Require separate accounts for privilege and non-privileged use. Configure Privileged Identity Management (PIM) to bring just-in-time(JIT) privileged access and remove standing access. Configure role based conditional access policies to limit access to productivity application for privileged users. For highly privileged users, secure devices as part of the privileged access story. All privileged actions are captured in the Azure AD Audit logs.<br>[Securing privileged access overview](/security/compass/overview)<br>[Configure Azure AD role settings in PIM](../privileged-identity-management/pim-how-to-change-default-settings.md)<br>[Users and groups in Conditional Access policy](../conditional-access/concept-conditional-access-users-groups.md)<br>[Why are privileged access devices important](/security/compass/privileged-access-devices) |

+| AC.L2-3.1.8<br><br>**Practice statement:** Limit unsuccessful sign-on attempts.<br><br>**Objectives:**<br>Determine if:<br>[a.] the means of limiting unsuccessful sign-on attempts is defined; and<br>[b.] the defined means of limiting unsuccessful sign-on attempts is implemented. | Enable custom smart lock-out settings. Configure lock-out threshold and lock-out duration in seconds to implement these requirements.<br>[Protect user accounts from attacks with Azure Active Directory smart lockout](../authentication/howto-password-smart-lockout.md)<br>[Manage Azure AD smart lockout values](../authentication/howto-password-smart-lockout.md) |

+| AC.L2-3.1.9<br><br>**Practice statement:** Provide privacy and security notices consistent with applicable CUI rules.<br><br>**Objectives:**<br>Determine if:<br>[a.] privacy and security notices required by CUI-specified rules are identified, consistent, and associated with the specific CUI category; and<br>[b.] privacy and security notices are displayed. | With Azure AD, you can deliver notification or banner messages for all apps that require and record acknowledgment before granting access. You can granularly target these terms of use policies to specific users (Member or Guest). You can also customize them per application via conditional access policies.<br><br>**Conditional access** <br>[What is conditional access in Azure AD?](../conditional-access/overview.md)<br><br>**Terms of use**<br>[Azure Active Directory terms of use](../conditional-access/terms-of-use.md)<br>[View report of who has accepted and declined](../conditional-access/terms-of-use.md) |

+| AC.L2-3.1.10<br><br>**Practice statement:** Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.<br><br>**Objectives:**<br>Determine if:<br>[a.] the period of inactivity after which the system initiates a session lock is defined;<br>[b.] access to the system and viewing of data is prevented by initiating a session lock after the defined period of inactivity; and<br>[c.] previously visible information is concealed via a pattern-hiding display after the defined period of inactivity. | Implement device lock by using a conditional access policy to restrict access to compliant or hybrid Azure AD joined devices. Configure policy settings on the device to enforce device lock at the OS level with MDM solutions such as Intune. Endpoint Manager or group policy objects can also be considered in hybrid deployments. For unmanaged devices, configure the Sign-In Frequency setting to force users to reauthenticate.<br>[Require device to be marked as compliant](../conditional-access/require-managed-devices.md)<br>[Grant controls in Conditional Access policy - Require hybrid Azure AD joined device](../conditional-access/concept-conditional-access-grant.md)<br>[User sign-in frequency](../conditional-access/howto-conditional-access-session-lifetime.md)<br><br>Configure devices for maximum minutes of inactivity until the screen locks ([Android](/mem/intune/configuration/device-restrictions-android), [iOS](/mem/intune/configuration/device-restrictions-ios), [Windows 10](/mem/intune/configuration/device-restrictions-windows-10)).|

+| AC.L2-3.1.11<br><br>**Practice statement:** Terminate (automatically) a user session after a defined condition.<br><br>**Objectives:**<br>Determine if:<br>[a.] conditions requiring a user session to terminate are defined; and<br>[b.] a user session is automatically terminated after any of the defined conditions occur. | Enable Continuous Access Evaluation (CAE) for all supported applications. For application that don't support CAE, or for conditions not applicable to CAE, implement policies in Microsoft Defender for Cloud Apps to automatically terminate sessions when conditions occur. Additionally, configure Azure Active Directory Identity Protection to evaluate user and sign-in Risk. Use conditional access with Identity protection to allow user to automatically remediate risk.<br>[Continuous access evaluation in Azure AD](../conditional-access/concept-continuous-access-evaluation.md)<br>[Control cloud app usage by creating policies](/defender-cloud-apps/control-cloud-apps-with-policies)<br>[What is Azure Active Directory Identity Protection?](../identity-protection/overview-identity-protection.md)

+|AC.L2-3.1.12<br><br>**Practice statement:** Monitor and control remote access sessions.<br><br>**Objectives:**<br>Determine if:<br>[a.] remote access sessions are permitted;<br>[b.] the types of permitted remote access are identified;<br>[c.] remote access sessions are controlled; and<br>[d.] remote access sessions are monitored. | In todayΓÇÖs world, users access cloud-based applications almost exclusively remotely from unknown or untrusted networks. It's critical to securing this pattern of access to adopt zero trust principals. To meet these controls requirements in a modern cloud world we must verify each access request explicitly, implement least privilege and assume breach.<br><br>Configure named locations to delineate internal vs external networks. Configure conditional access app control to route access via Microsoft Defender for Cloud Apps (MDCA). Configure MDCA to control and monitor all sessions.<br>[Zero Trust Deployment Guide for Microsoft Azure Active Directory](/security/blog/2020/04/30/zero-trust-deployment-guide-azure-active-directory/)<br>[Location condition in Azure Active Directory Conditional Access](/azure/active-directory/conditional-access/location-condition.md)<br>[Deploy Cloud App Security Conditional Access App Control for Azure AD apps](/cloud-app-security/proxy-deployment-aad.md)<br>[What is Microsoft Defender for Cloud Apps?](/cloud-app-security/what-is-cloud-app-security.md)<br>[Monitor alerts raised in Microsoft Defender for Cloud Apps](/cloud-app-security/monitor-alerts.md) |

+| AC.L2-3.1.13<br><br>**Practice statement:** Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.<br><br>**Objectives:**<br>Determine if:<br>[a.] cryptographic mechanisms to protect the confidentiality of remote access sessions are identified; and<br>[b.] cryptographic mechanisms to protect the confidentiality of remote access sessions are implemented. | All Azure AD customer-facing web services are secured with the Transport Layer Security (TLS) protocol and are implemented using FIPS-validated cryptography.<br>[Azure Active Directory Data Security Considerations (microsoft.com)](https://azure.microsoft.com/resources/azure-active-directory-data-security-considerations/) |

+| AC.L2-3.1.14<br><br>**Practice statement:** Route remote access via managed access control points.<br><br>**Objectives:**<br>Determine if:<br>[a.] managed access control points are identified and implemented; and<br>[b.] remote access is routed through managed network access control points. | Configure named locations to delineate internal vs external networks. Configure conditional access app control to route access via Microsoft Defender for Cloud Apps (MDCA). Configure MDCA to control and monitor all sessions. Secure devices used by privileged accounts as part of the privileged access story.<br>[Location condition in Azure Active Directory Conditional Access](/azure/active-directory/conditional-access/location-condition.md)<br>[Session controls in Conditional Access policy](/azure/active-directory/conditional-access/concept-conditional-access-session.md)<br>[Securing privileged access overview](/security/compass/overview.md) |

+| AC.L2-3.1.15<br><br>**Practice statement:** Authorize remote execution of privileged commands and remote access to security-relevant information.<br><br>**Objectives:**<br>Determine if:<br>[a.] privileged commands authorized for remote execution are identified;<br>[b.] security-relevant information authorized to be accessed remotely is identified;<br>[c.] the execution of the identified privileged commands via remote access is authorized; and<br>[d.] access to the identified security-relevant information via remote access is authorized. | Conditional Access is the Zero Trust control plane to target policies for access to your apps when combined with authentication context. You can apply different policies in those apps. Secure devices used by privileged accounts as part of the privileged access story. Configure conditional access policies to require the use of these secured devices by privileged users when performing privileged commands.<br>[Cloud apps, actions, and authentication context in Conditional Access policy](/azure/active-directory/conditional-access/concept-conditional-access-cloud-apps.md)<br>[Securing privileged access overview](/security/compass/overview.md)<br>[Filter for devices as a condition in Conditional Access policy](/azure/active-directory/conditional-access/concept-condition-filters-for-devices.md) |

+| 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 Endpoint Manager (MEM) 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](/azure/active-directory/conditional-access/concept-conditional-access-grant.md)<br>[Require hybrid Azure AD joined device](/azure/active-directory/conditional-access/concept-conditional-access-grant.md)<br><br>**InTune**<br>[Device compliance policies in Microsoft Intune](/mem/intune/protect/device-compliance-get-started.md)<br>[What is app management in Microsoft Intune?](/mem/intune/apps/app-management.md) |

+| AC.L2-3.1.19<br><br>**Practice statement:** Encrypt CUI on mobile devices and mobile computing platforms.<br><br>**Objectives:**<br>Determine if:<br>[a.] mobile devices and mobile computing platforms that process, store, or transmit CUI are identified; and<br>[b.] encryption is employed to protect CUI on identified mobile devices and mobile computing platforms. | **Managed Device**<br>Configure conditional access policies to enforce compliant or HAADJ device and to ensure managed devices are configured appropriately via device management solution to encrypt CUI.<br><br>**Unmanaged Device**<br>Configure conditional access policies to require app protection policies.<br>[Grant controls in Conditional Access policy - Require device to be marked as compliant](../conditional-access/concept-conditional-access-grant.md)<br>[Grant controls in Conditional Access policy - Require hybrid Azure AD joined device](../conditional-access/concept-conditional-access-grant.md)<br>[Grant controls in Conditional Access policy - Require app protection policy](../conditional-access/concept-conditional-access-grant.md) |

+| 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 Endpoint Manager (MEM) 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](/azure/active-directory/conditional-access/concept-conditional-access-grant.md)<br>[Require hybrid Azure AD joined device](/azure/active-directory/conditional-access/concept-conditional-access-grant.md)<br>[Configure authentication session management - Azure Active Directory](/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.md)<br>[Restrict USB devices using administrative templates in Microsoft Intune](/mem/intune/configuration/administrative-templates-restrict-usb.md)<br><br>**Microsoft Defender for Cloud Apps**<br>[Create session policies in Defender for Cloud Apps](/defender-cloud-apps/session-policy-aad.md)

+In CMMC Level 2, there are 13 domains that have one or more practices related to identity:

+| AU.L2-3.3.1<br><br>AU.L2-3.3.2 | All operations are audited in 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](/azure/active-directory/reports-monitoring/concept-audit-logs)<br>[Connect Azure Active Directory data to Microsoft Sentinel](/azure/sentinel/connect-azure-active-directory)<br>[Tutorial: Stream logs to an Azure event hub](/azure/active-directory/reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub) |

+| CM.L2-3.4.5 | Azure Active Directory (Azure AD) is a cloud-based identity and access management service. Customers don't have physical access to the Azure AD datacenters. As such, each physical access restriction is satisfied by Microsoft and inherited by the customers of Azure AD. Implement Azure AD role based access controls. Eliminate standing privileged access, provide just in time access with approval workflows with Privileged Identity Management.<br>[Overview of Azure Active Directory role-based access control (RBAC)](/azure/active-directory/roles/custom-overview)<br>[What is Privileged Identity Management?](/azure/active-directory/privileged-identity-management/pim-configure)<br>[Approve or deny requests for Azure AD roles in PIM](/azure/active-directory/privileged-identity-management/azure-ad-pim-approval-workflow) |

+# Configure CMMC Level 2 Identification and Authentication (IA) controls

+The following table provides a list of practice statement and objectives, and Azure AD guidance and recommendations to enable you to meet these requirements with Azure AD.

+| CMMC practice statement and objectives | Azure AD guidance and recommendations |

+| IA.L2-3.5.3<br><br>**Practice statement:** Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts. <br><br>**Objectives:**<br>Determine if:<br>[a.] privileged accounts are identified;<br>[b.] multifactor authentication is implemented for local access to privileged accounts;<br>[c.] multifactor authentication is implemented for network access to privileged accounts; and<br>[d.] multifactor authentication is implemented for network access to non-privileged accounts. | The following items are definitions for the terms used for this control area:<li>**Local Access** - Access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network.<li>**Network Access** - Access to an information system by a user (or a process acting on behalf of a user) communicating through a network (for example, local area network, wide area network, Internet).<li>**Privileged User** - A user that's authorized (and therefore, trusted) to perform security-relevant functions that ordinary users aren't authorized to perform.<br><br>Breaking down the previous requirement means:<li>All users are required MFA for network/remote access.<li>Only privileged users are required MFA for local access. If regular user accounts have administrative rights only on their computers, they're not a ΓÇ£privileged accountΓÇ¥ and don't require MFA for local access.<br><br> You're responsible for configuring Conditional Access to require multifactor authentication. Enable Azure AD Authentication methods that meet AAL2 and higher.<br>[Grant controls in Conditional Access policy - Azure Active Directory](/azure/active-directory/conditional-access/concept-conditional-access-grant.md)<br>[Achieve NIST authenticator assurance levels with Azure Active Directory](/azure/active-directory/standards/nist-overview.md)<br>[Authentication methods and features - Azure Active Directory](/azure/active-directory/authentication/concept-authentication-methods.md) |

+| IA.L2-3.5.4<br><br>**Practice statement:** Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.<br><br>**Objectives:**<br>Determine if:<br>[a.] replay-resistant authentication mechanisms are implemented for network account access to privileged and non-privileged accounts. | All Azure AD Authentication methods at AAL2 and above are replay resistant.<br>[Achieve NIST authenticator assurance levels with Azure Active Directory](/azure/active-directory/standards/nist-overview.md) |

+| IA.L2-3.5.5<br><br>**Practice statement:** Prevent reuse of identifiers for a defined period.<br><br>**Objectives:**<br>Determine if:<br>[a.] a period within which identifiers can't be reused is defined; and<br>[b.] reuse of identifiers is prevented within the defined period. | All user, group, device object globally unique identifiers (GUIDs) are guaranteed unique and non-reusable for the lifetime of the Azure AD tenant.<br>[user resource type - Microsoft Graph v1.0](/graph/api/resources/user?view=graph-rest-1.0&preserve-view=true)<br>[group resource type - Microsoft Graph v1.0](/graph/api/resources/group?view=graph-rest-1.0&preserve-view=true)<br>[device resource type - Microsoft Graph v1.0](/graph/api/resources/device?view=graph-rest-1.0&preserve-view=true) |

+| IA.L2-3.5.6<br><br>**Practice statement:** Disable identifiers after a defined period of inactivity.<br><br>**Objectives:**<br>Determine if:<br>[a.] a period of inactivity after which an identifier is disabled is defined; and<br>[b.] identifiers are disabled after the defined period of inactivity. | Implement account management automation with Microsoft Graph and Azure AD PowerShell. Use Microsoft Graph to monitor sign-in activity and Azure AD PowerShell to take action on accounts within the required time frame.<br><br>**Determine inactivity**<br>[Manage inactive user accounts in Azure AD](/azure/active-directory/reports-monitoring/howto-manage-inactive-user-accounts.md)<br>[Manage stale devices in Azure AD](/azure/active-directory/devices/manage-stale-devices.md)<br><br>**Remove or disable accounts**<br>[Working with users in Microsoft Graph](/graph/api/resources/users.md)<br>[Get a user](/graph/api/user-get?tabs=http)<br>[Update user](/graph/api/user-update?tabs=http)<br>[Delete a user](/graph/api/user-delete?tabs=http)<br><br>**Work with devices in Microsoft Graph**<br>[Get device](/graph/api/device-get?tabs=http)<br>[Update device](/graph/api/device-update?tabs=http)<br>[Delete device](/graph/api/device-delete?tabs=http)<br><br>**[Use Azure AD PowerShell](/powershell/module/azuread/)**<br>[Get-AzureADUser](/powershell/module/azuread/get-azureaduser.md)<br>[Set-AzureADUser](/powershell/module/azuread/set-azureaduser.md)<br>[Get-AzureADDevice](/powershell/module/azuread/get-azureaddevice.md)<br>[Set-AzureADDevice](/powershell/module/azuread/set-azureaddevice.md) |

+| IA.L2-3.5.7<br><br>**Practice statement:**<br><br>**Objectives:** Enforce a minimum password complexity and change of characters when new passwords are created.<br>Determine if:<br>[a.] password complexity requirements are defined;<br>[b.] password change of character requirements are defined;<br>[c.] minimum password complexity requirements as defined are enforced when new passwords are created; and<br>[d.] minimum password change of character requirements as defined are enforced when new passwords are created.<br><br>IA.L2-3.5.8<br><br>**Practice statement:** Prohibit password reuse for a specified number of generations.<br><br>**Objectives:**<br>Determine if:<br>[a.] the number of generations during which a password cannot be reused is specified; and<br>[b.] reuse of passwords is prohibited during the specified number of generations. | We **strongly encourage** passwordless strategies. This control is only applicable to password authenticators, so removing passwords as an available authenticator renders this control not applicable.<br><br>Per NIST SP 800-63 B Section 5.1.1: Maintain a list of commonly used, expected, or compromised passwords.<br><br>With Azure AD password protection, default global banned password lists are automatically applied to all users in an Azure AD tenant. To support your business and security needs, you can define entries in a custom banned password list. When users change or reset their passwords, these banned password lists are checked to enforce the use of strong passwords.<br>For customers that require strict password character change, password reuse and complexity requirements use hybrid accounts configured with Password-Hash-Sync. This action ensures the passwords synchronized to Azure AD inherit the restrictions configured in Active Directory password policies. Further protect on-premises passwords by configuring on-premises Azure AD Password Protection for Active Directory Domain Services.<br>[NIST Special Publication 800-63 B](https://pages.nist.gov/800-63-3/sp800-63b.html)<br>[NIST Special Publication 800-53 Revision 5 (IA-5 - Control enhancement (1)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf)<br>[Eliminate bad passwords using Azure AD password protection](../authentication/concept-password-ban-bad.md)<br>[What is password hash synchronization with Azure AD?](../hybrid/whatis-phs.md) |

+| IA.L2-3.5.9<br><br>**Practice statement:** Allow temporary password use for system logons with an immediate change to a permanent password.<br><br>**Objectives:**<br>Determine if:<br>[a.] an immediate change to a permanent password is required when a temporary password is used for system sign-on. | An Azure AD user initial password is a temporary single use password that once successfully used is immediately required to be changed to a permanent password. Microsoft strongly encourages the adoption of passwordless authentication methods. Users can bootstrap Passwordless authentication methods using Temporary Access Pass (TAP). TAP is a time and use limited passcode issued by an admin that satisfies strong authentication requirements. Use of passwordless authentication along with the time and use limited TAP completely eliminates the use of passwords (and their reuse).<br>[Add or delete users - Azure Active Directory](/azure/active-directory/fundamentals/add-users-azure-active-directory.md)<br>[Configure a Temporary Access Pass in Azure AD to register Passwordless authentication methods](/azure/active-directory/authentication/howto-authentication-temporary-access-pass.md)<br>[Passwordless authentication](/security/business/solutions/passwordless-authentication?ef_id=369464fc2ba818d0bd6507de2cde3d58:G:s&OCID=AIDcmmdamuj0pc_SEM_369464fc2ba818d0bd6507de2cde3d58:G:s&msclkid=369464fc2ba818d0bd6507de2cde3d58) |

+| IA.L2-3.5.10<br><br>**Practice statement:** Store and transmit only cryptographically protected passwords.<br><br>**Objectives:**<br>Determine if:<br>[a.] passwords are cryptographically protected in storage; and<br>[b.] passwords are cryptographically protected in transit. | **Secret Encryption at Rest**:<br>In addition to disk level encryption, when at rest, secrets stored in the directory are encrypted using the Distributed Key Manager(DKM). The encryption keys are stored in Azure AD core store and in turn are encrypted with a scale unit key. The key is stored in a container that is protected with directory ACLs, for highest privileged users and specific services. The symmetric key is typically rotated every six months. Access to the environment is further protected with operational controls and physical security.<br><br>**Encryption in Transit**:<br>To assure data security, Directory Data in Azure AD is signed and encrypted while in transit between data centers within a scale unit. The data is encrypted and unencrypted by the Azure AD core store tier, which resides inside secured server hosting areas of the associated Microsoft data centers.<br><br>Customer-facing web services are secured with the Transport Layer Security (TLS) protocol.<br>For more information, [download](https://azure.microsoft.com/resources/azure-active-directory-data-security-considerations/) *Data Protection Considerations - Data Security*. On page 15, there are more details.<br>[Demystifying Password Hash Sync (microsoft.com)](https://www.microsoft.com/security/blog/2019/05/30/demystifying-password-hash-sync/)<br>[Azure Active Directory Data Security Considerations](https://aka.ms/aaddatawhitepaper) |

+|IA.L2-3.5.11<br><br>**Practice statement:** Obscure feedback of authentication information.<br><br>**Objectives:**<br>Determine if:<br>[a.] authentication information is obscured during the authentication process. | By default, Azure AD obscures all authenticator feedback. |

+In today's world of interconnected infrastructures, compliance with governmental and industry frameworks and standards is often mandatory. Microsoft engages with governments, regulators, and standards bodies to understand and meet compliance requirements for Azure. There are [90 Azure compliance certifications](../../compliance/index.yml), which include many for various regions and countries. Azure has 35 compliance offerings for key industries including,

+* Health

+* Government

+* Finance

+* Education

+* Manufacturing

+* Media

+## Azure compliance is a head start

+Compliance is a shared responsibility for Microsoft, cloud service providers (CSPs), and organizations. Use Azure compliance certifications as a basis for your compliance, and then configure Azure Active Directory to meet identity standards.

+CSPs, government agencies, and those who work with them, must meet one or more sets of government standards, which can include:

+* [National Institute of Standards and Technologies (NIST)](/azure/compliance/offerings/offering-nist-800-53)

+CSPs and organizations in industries such as healthcare and finance have standards, such as:

+* [Health Insurance Portability and Accountability Act of 1996 (HIPPA)](/azure/compliance/offerings/offering-hipaa-us)

+* [Sarbanes-Oxley Act of 2002 (SOX)](/azure/compliance/offerings/offering-sox-us)

+* [Configure Azure Active Directory to achieve NIST authenticator assurance levels](nist-overview.md)

+* [Configure Azure Active directory to meet FedRAMP High Impact level](configure-azure-active-directory-for-fedramp-high-impact.md)

+## Auto upgrade limitations

+If youΓÇÖre using Auto-Upgrade you cannot anymore upgrade the control plane first, and then upgrade the individual node pools. Auto-Upgrade will always upgrade the control plane and the node pools together. In Auto-Upgrade there is no concept of upgrading the control plane only, and trying to run the command `az aks upgrade --control-plane-only` will raise the error: `NotAllAgentPoolOrchestratorVersionSpecifiedAndUnchanged: Using managed cluster api, all Agent pools' OrchestratorVersion must be all specified or all unspecified. If all specified, they must be stay unchanged or the same with control plane.`

+[kubectl-get]: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get

+[install-azure-cli]: /cli/azure/install_azure_cli

+3. Create a `pvc-blob-nfs.yaml` file with a *PersistentVolumeClaim*. For example:

+The Azure Files Container Storage Interface (CSI) driver is a [CSI specification][csi-specification]-compliant driver used by Azure Kubernetes Service (AKS) to manage the lifecycle of Azure file shares. The CSI is a standard for exposing arbitrary block and file storage systems to containerized workloads on Kubernetes.

+|skuName | Azure Files storage account type (alias: `storageAccountType`)| `Standard_LRS`, `Standard_ZRS`, `Standard_GRS`, `Standard_RAGRS`, `Standard_RAGZRS`,`Premium_LRS`, `Premium_ZRS` | No | `StandardSSD_LRS`<br> Minimum file share size for Premium account type is 100 GiB.<br> ZRS account type is supported in limited regions.<br> NFS file share only supports Premium account type.|

+| | **Following parameters are only for vnet setting, e.g. NFS, private endpoint** | | |

+> Azure Files supports Azure Premium Storage. The minimum premium file share capacity is 100 GiB.

+In AKS, the built-in `azurefile-csi` storage class already supports expansion, so use the [PVC created earlier with this storage class](#dynamically-create-azure-files-pvs-by-using-the-built-in-storage-classes). The PVC requested a 100GiB file share. We can confirm that by running:

+Create a file named `private-azure-file-sc.yaml`, and then paste the following example manifest in the file. Replace the values for `<resourceGroup>` and `<storageAccountName>`.

+Create a file named `private-pvc.yaml`, and then paste the following example manifest in the file:

+### Prerequisites

+- Your AKS cluster's service principal or managed service identity (MSI) must be added to the Contributor role to the storage account.

+> [!NOTE]

+> You can use a private endpoint instead of allowing access to the selected VNet.

+You can deploy an example **stateful set** that saves timestamps into a file `data.txt` with the [kubectl apply][kubectl-apply] command:

+kubectl apply -f

+apiVersion: apps/v1

+kind: StatefulSet

+metadata:

+ name: statefulset-azurefile

+ labels:

+ app: nginx

+spec:

+ podManagementPolicy: Parallel # default is OrderedReady

+ serviceName: statefulset-azurefile

+ replicas: 1

+ template:

+ metadata:

+ labels:

+ app: nginx

+ spec:

+ nodeSelector:

+ "kubernetes.io/os": linux

+ containers:

+ - name: statefulset-azurefile

+ image: mcr.microsoft.com/oss/nginx/nginx:1.19.5

+ command:

+ - "/bin/bash"

+ - "-c"

+ - set -euo pipefail; while true; do echo $(date) >> /mnt/azurefile/outfile; sleep 1; done

+ volumeMounts:

+ - name: persistent-storage

+ mountPath: /mnt/azurefile

+ updateStrategy:

+ type: RollingUpdate

+ selector:

+ matchLabels:

+ app: nginx

+ volumeClaimTemplates:

+ - metadata:

+ name: persistent-storage

+ annotations:

+ volume.beta.kubernetes.io/storage-class: azurefile-csi-nfs

+ spec:

+ accessModes: ["ReadWriteMany"]

+ resources:

+ requests:

+ storage: 100Gi

+> Note that because the NFS file share is in a Premium account, the minimum file share size is 100 GiB. If you create a PVC with a small storage size, you might encounter an error similar to the following: *failed to create file share ... size (5)...*.

+- To learn how to use CSI driver for Azure Blob storage, see [Use Azure Blob storage with CSI driver][azure-blob-csi].

+* Business continuity and disaster recovery.

+For guidance on a creating full solutions with AKS for production, see [AKS solution guidance][aks-solution-guidance].

+[aks-solution-guidance]: /azure/architecture/reference-architectures/containers/aks-start-here?WT.mc_id=AKSDOCSPAGE

+* Make sure you've been assigned either the `Owner` role or the `Contributor` and `User Access Administrator` roles in the subscription. You can verify it by following steps in [List role assignments for a user or group](../role-based-access-control/role-assignments-list-portal.md#list-role-assignments-for-a-user-or-group).

+1. This section allows you to select an existing AKS cluster and Azure Container Registry (ACR), instead of causing the deployment to create a new one, if desired. This capability enables you to use the sidecar pattern, as shown in the [Azure architecture center](/azure/architecture/patterns/sidecar). You can also adjust the settings for the size and number of the virtual machines in the AKS node pool. Leave all other values at the defaults and select **Next: Networking**.

+ 1. You can provide the TLS/SSL certificate presented by the Azure Application Gateway. Leave the values at the default to cause the offer to generate a self-signed certificate. Don't go to production using a self-signed certificate. For more information about self-signed certificates, see [Create a self-signed public certificate to authenticate your application](../active-directory/develop/howto-create-self-signed-certificate.md).

+ 1. You can enable cookie based affinity, also known as sticky sessions. We want sticky sessions enabled for this article, so ensure this option is selected.

+Follow the steps in this section to deploy the sample application on the Liberty runtime. These steps use Maven.

+In the *aks* directory, we placed three deployment files. *db-secret.xml* is used to create [Kubernetes Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) with DB connection credentials. The file *openlibertyapplication-agic.yaml* is used to deploy the application image. In the *docker* directory, there are two files to create the application image with either Open Liberty or WebSphere Liberty.

+Now that you've gathered the necessary properties, you can build the application. The POM file for the project reads many variables from the environment. As part of the Maven build, these variables are used to populate values in the YAML files located in *src/main/aks*. You can do something similar for your application outside Maven if you prefer.

+# The following variables will be used for deployment file generation into target.

+You can now run and test the project locally before deploying to Azure. For convenience, we use the `liberty-maven-plugin`. To learn more about the `liberty-maven-plugin`, see [Building a web application with Maven](https://openliberty.io/guides/maven-intro.html). For your application, you can do something similar using any other mechanism, such as your local IDE. You can also consider using the `liberty:devc` option intended for development with containers. You can read more about `liberty:devc` in the [Liberty docs](https://openliberty.io/docs/latest/development-mode.html#_container_support_for_dev_mode).

+1. Start the application using `liberty:run`. `liberty:run` will also use the environment variables defined in the previous step.

+1. Press <kbd>Ctrl</kbd>+<kbd>C</kbd> to stop.

+You can now run the `docker build` command to build the image.

+### (Optional) Test the Docker image locally

+You can now use the following steps to test the Docker image locally before deploying to Azure.

+1. Run the image using the following command. Note we're using the environment variables defined previously.

+ ```bash

+ docker run -it --rm -p 9080:9080 \

+ -e DB_SERVER_NAME=${DB_SERVER_NAME} \

+ -e DB_NAME=${DB_NAME} \

+ -e DB_USER=${DB_USER} \

+ -e DB_PASSWORD=${DB_PASSWORD} \

+ javaee-cafe:v1

+ ```

+1. Once the container starts, go to `http://localhost:9080/` in your browser to access the application.

+1. Press <kbd>Ctrl</kbd>+<kbd>C</kbd> to stop.

+[helm]: quickstart-helm.md

+[aks-best-practices]: best-practices.md

+* If a cluster is enabled KMS with private key vault and not using the `API Server VNet integration` tunnel, then stop/start cluster is not allowed.

+- Authorizations feature only supports Service Principal and Managed Identity as access policies.

+- Authorizations feature only supports /.default app-only scopes while acquire token for https://.../authorizationmanager audience.

+az webapp config appsettings set --resource-group myResourceGroup --name <app-name> --settings WORDPRESS_DB_HOST="<mysql-server-name>.mysql.database.azure.com" WORDPRESS_DB_USER="adminuser" WORDPRESS_DB_PASSWORD="My5up3rStr0ngPaSw0rd!" WORDPRESS_DB_NAME="wordpress" MYSQL_SSL_CA="BaltimoreCyberTrustroot.crt.pem"

+ "value": "adminuser"

+ "value": "adminuser"

+For more information, see the [JavaScript/TypeScript SDK Developers Guide](how-to-dev-guide-js-sdk.md).

+The common alert schema standardizes the consumption experience for alert notifications in Azure. Historically, activity log, metric, and log alerts each had their own email templates and webhook schemas. The common alert schema provides one standardized schema for all alert notifications.

+A standardized schema can help you minimize the number of integrations, which simplifies the process of managing and maintaining your integrations.

+The common alert schema provides a consistent structure for:

+- **Email templates**: Use the detailed email template to diagnose issues at a glance. Embedded links to the alert instance on the portal and to the affected resource ensure that you can quickly jump into the remediation process.

+- **JSON structure**: Use the consistent JSON structure to build integrations for all alert types using:

+ - Azure Logic Apps

+ - Azure Functions

+ - Azure Automation runbook

+The new schema enables a richer alert consumption experience across both the Azure portal and the Azure mobile app.

+> [!NOTE]

+> Alerts generated by [VM insights](../vm/vminsights-overview.md) do not support the common schema.

+## Structure of the common schema

+The common schema includes information about the affected resource and the cause of the alert in these sections:

+- **Essentials**: Standardized fields, used by all alert types that describe the resource affected by the alert and common alert metadata, such as severity or description.

+ If you want to route alert instances to specific teams based on criteria such as a resource group, you can use the fields in the **Essentials** section to provide routing logic for all alert types. The teams that receive the alert notification can then use the context fields for their investigation.

+- **Alert context**: Fields that vary depending on the type of the alert. The alert context fields describe the cause of the alert. For example, a metric alert would have fields like the metric name and metric value in the alert context. An activity log alert would have information about the event that generated the alert.

+## Sample alert payload

+```json

+{

+ "schemaId": "azureMonitorCommonAlertSchema",

+ "data": {

+ "essentials": {

+ "alertId": "/subscriptions/<subscription ID>/providers/Microsoft.AlertsManagement/alerts/b9569717-bc32-442f-add5-83a997729330",

+ "alertRule": "WCUS-R2-Gen2",

+ "severity": "Sev3",

+ "signalType": "Metric",

+ "monitorCondition": "Resolved",

+ "monitoringService": "Platform",

+ "alertTargetIDs": [

+ "/subscriptions/<subscription ID>/resourcegroups/pipelinealertrg/providers/microsoft.compute/virtualmachines/wcus-r2-gen2"

+ ],

+ "configurationItems": [

+ "wcus-r2-gen2"

+ ],

+ "originAlertId": "3f2d4487-b0fc-4125-8bd5-7ad17384221e_PipeLineAlertRG_microsoft.insights_metricAlerts_WCUS-R2-Gen2_-117781227",

+ "firedDateTime": "2019-03-22T13:58:24.3713213Z",

+ "resolvedDateTime": "2019-03-22T14:03:16.2246313Z",

+ "description": "",

+ "essentialsVersion": "1.0",

+ "alertContextVersion": "1.0"

+ },

+ "alertContext": {

+ "properties": null,

+ "conditionType": "SingleResourceMultipleMetricCriteria",

+ "condition": {

+ "windowSize": "PT5M",

+ "allOf": [

+ {

+ "metricName": "Percentage CPU",

+ "metricNamespace": "Microsoft.Compute/virtualMachines",

+ "operator": "GreaterThan",

+ "threshold": "25",

+ "timeAggregation": "Average",

+ "dimensions": [

+ {

+ "name": "ResourceId",

+ "value": "3efad9dc-3d50-4eac-9c87-8b3fd6f97e4e"

+ }

+ ],

+ "metricValue": 7.727

+ }

+ ]

+ }

+ }

+ }

+}

+```

+## Essentials fields

+| Field | Description|

+| alertId | The unique resource ID that identifies the alert instance. |

+| alertRule | The name of the alert rule that generated the alert instance. |

+| Severity | The severity of the alert. Possible values are Sev0, Sev1, Sev2, Sev3, or Sev4. |

+| signalType | Identifies the signal on which the alert rule was defined. Possible values are Metric, Log, or Activity Log. |

+| monitorCondition | When an alert fires, the alert's monitor condition is set to **Fired**. When the underlying condition that caused the alert to fire clears, the monitor condition is set to **Resolved**. |

+| monitoringService | The monitoring service or solution that generated the alert. The fields for the alert context are dictated by the monitoring service. |

+| alertTargetIds | The list of the Azure Resource Manager IDs that are affected targets of an alert. For a log alert defined on a Log Analytics workspace or Application Insights instance, it's the respective workspace or application. |

+| configurationItems |The list of affected resources of an alert.<br>In some cases, the configuration items can be different from the alert targets. For example, in metric-for-log or log alerts defined on a Log Analytics workspace, the configuration items are the actual resources sending the telemetry and not the workspace.<br><ul><li>In the log alerts API (Scheduled Query Rules) v2021-08-01, the `configurationItem` values are taken from explicitly defined dimensions in this priority: `Computer`, `_ResourceId`, `ResourceId`, `Resource`.</li><li>In earlier versions of the log alerts API, the `configurationItem` values are taken implicitly from the results in this priority: `Computer`, `_ResourceId`, `ResourceId`, `Resource`.</li></ul>In ITSM systems, the `configurationItems` field is used to correlate alerts to resources in a configuration management database. |

+| originAlertId | The ID of the alert instance, as generated by the monitoring service generating it. |

+| firedDateTime | The date and time when the alert instance was fired in Coordinated Universal Time (UTC). |

+| resolvedDateTime | The date and time when the monitor condition for the alert instance is set to **Resolved** in UTC. Currently only applicable for metric alerts.|

+| description | The description, as defined in the alert rule. |

+|essentialsVersion| The version number for the essentials section.|

+|alertContextVersion | The version number for the `alertContext` section. |

+## Alert context fields for metric alerts

+### Sample metric alert with a static threshold and the monitoringService = `Platform`

+```json

+{

+ "alertContext": {

+ "properties": null,

+ "conditionType": "SingleResourceMultipleMetricCriteria",

+ "condition": {

+ "windowSize": "PT5M",

+ "allOf": [

+ {

+ "metricName": "Percentage CPU",

+ "metricNamespace": "Microsoft.Compute/virtualMachines",

+ "operator": "GreaterThan",

+ "threshold": "25",

+ "timeAggregation": "Average",

+ "dimensions": [

+ {

+ "name": "ResourceId",

+ "value": "3efad9dc-3d50-4eac-9c87-8b3fd6f97e4e"

+ }

+ ],

+ "metricValue": 31.1105

+ }

+ ],

+ "windowStartTime": "2019-03-22T13:40:03.064Z",

+ "windowEndTime": "2019-03-22T13:45:03.064Z"

+ }

+ }

+}

+```

+### Sample metric alert with a dynamic threshold and the monitoringService = Platform

+```json

+{

+ "alertContext": {

+ "properties": null,

+ "conditionType": "DynamicThresholdCriteria",

+ "condition": {

+ "windowSize": "PT5M",

+ "allOf": [

+ {

+ "alertSensitivity": "High",

+ "failingPeriods": {

+ "numberOfEvaluationPeriods": 1,

+ "minFailingPeriodsToAlert": 1

+ },

+ "ignoreDataBefore": null,

+ "metricName": "Egress",

+ "metricNamespace": "microsoft.storage/storageaccounts",

+ "operator": "GreaterThan",

+ "threshold": "47658",

+ "timeAggregation": "Total",

+ "dimensions": [],

+ "metricValue": 50101

+ }

+ ],

+ "windowStartTime": "2021-07-20T05:07:26.363Z",

+ "windowEndTime": "2021-07-20T05:12:26.363Z"

+ }

+ }

+}

+```

+### Sample metric alert for availability tests and the monitoringService = Platform

+```json

+{

+ "alertContext": {

+ "properties": null,

+ "conditionType": "WebtestLocationAvailabilityCriteria",

+ "condition": {

+ "windowSize": "PT5M",

+ "allOf": [

+ {

+ "metricName": "Failed Location",

+ "metricNamespace": null,

+ "operator": "GreaterThan",

+ "threshold": "2",

+ "timeAggregation": "Sum",

+ "dimensions": [],

+ "metricValue": 5,

+ "webTestName": "myAvailabilityTest-myApplication"

+ }

+ ],

+ "windowStartTime": "2019-03-22T13:40:03.064Z",

+ "windowEndTime": "2019-03-22T13:45:03.064Z"

+ }

+ }

+}

+```

+## Alert context fields for Log alerts

+> When you enable the common schema, the fields in the payload are reset to the common schema fields. Therefore, log alerts have these limitations regarding the common schema:

+> - The common schema is not supported for log alerts using webhooks with a custom email subject and/or JSON payload, since the common schema overwrites the custom configurations.

+> - Alerts using the common schema have an upper size limit of 256 KB per alert. If the log alerts payload includes search results that cause the alert to exceed the maximum size, the search results aren't embedded in the log alerts payload. You can check if the payload includes the search results with the `IncludedSearchResults` flag. Use `LinkToFilteredSearchResultsAPI` or `LinkToSearchResultsAPI` to access query results with the [Log Analytics API](/rest/api/loganalytics/dataaccess/query/get) if the search results are not included.

+### Sample log alert when the monitoringService = Platform

+```json

+{

+ "alertContext": {

+ "SearchQuery": "Perf | where ObjectName == \"Processor\" and CounterName == \"% Processor Time\" | summarize AggregatedValue = avg(CounterValue) by bin(TimeGenerated, 5m), Computer",

+ "SearchIntervalStartTimeUtc": "3/22/2019 1:36:31 PM",

+ "SearchIntervalEndtimeUtc": "3/22/2019 1:51:31 PM",

+ "ResultCount": 2,

+ "LinkToSearchResults": "https://portal.azure.com/#Analyticsblade/search/index?_timeInterval.intervalEnd=2018-03-26T09%3a10%3a40.0000000Z&_timeInterval.intervalDuration=3600&q=Usage",

+ "LinkToFilteredSearchResultsUI": "https://portal.azure.com/#Analyticsblade/search/index?_timeInterval.intervalEnd=2018-03-26T09%3a10%3a40.0000000Z&_timeInterval.intervalDuration=3600&q=Usage",

+ "LinkToSearchResultsAPI": "https://api.loganalytics.io/v1/workspaces/workspaceID/query?query=Heartbeat&timespan=2020-05-07T18%3a11%3a51.0000000Z%2f2020-05-07T18%3a16%3a51.0000000Z",

+ "LinkToFilteredSearchResultsAPI": "https://api.loganalytics.io/v1/workspaces/workspaceID/query?query=Heartbeat&timespan=2020-05-07T18%3a11%3a51.0000000Z%2f2020-05-07T18%3a16%3a51.0000000Z",

+ "SeverityDescription": "Warning",

+ "WorkspaceId": "12345a-1234b-123c-123d-12345678e",

+ "SearchIntervalDurationMin": "15",

+ "AffectedConfigurationItems": [

+ "INC-Gen2Alert"

+ ],

+ "SearchIntervalInMinutes": "15",

+ "Threshold": 10000,

+ "Operator": "Less Than",

+ "Dimensions": [

+ {

+ "name": "Computer",

+ "value": "INC-Gen2Alert"

+ }

+ ],

+ "SearchResults": {

+ "tables": [

+ {

+ "name": "PrimaryResult",

+ "columns": [

+ {

+ "name": "$table",

+ "type": "string"

+ },

+ {

+ "name": "Computer",

+ "type": "string"

+ },

+ {

+ "name": "TimeGenerated",

+ "type": "datetime"

+ }

+ ],

+ "rows": [

+ [

+ "Fabrikam",

+ "33446677a",

+ "2018-02-02T15:03:12.18Z"

+ ],

+ [

+ "Contoso",

+ "33445566b",

+ "2018-02-02T15:16:53.932Z"

+ ]

+ ]

+ }

+ ],

+ "dataSources": [

+ {

+ "resourceId": "/subscriptions/a5ea55e2-7482-49ba-90b3-60e7496dd873/resourcegroups/test/providers/microsoft.operationalinsights/workspaces/test",

+ "tables": [

+ "Heartbeat"

+ ]

+ }

+ ]

+ },

+ "IncludedSearchResults": "True",

+ "AlertType": "Metric measurement"

+ }

+}

+```

+### Sample log alert when the monitoringService = Application Insights

+```json

+{

+ "alertContext": {

+ "SearchQuery": "requests | where resultCode == \"500\" | summarize AggregatedValue = Count by bin(Timestamp, 5m), IP",

+ "SearchIntervalStartTimeUtc": "3/22/2019 1:36:33 PM",

+ "SearchIntervalEndtimeUtc": "3/22/2019 1:51:33 PM",

+ "ResultCount": 2,

+ "LinkToSearchResults": "https://portal.azure.com/AnalyticsBlade/subscriptions/12345a-1234b-123c-123d-12345678e/?query=search+*+&timeInterval.intervalEnd=2018-03-26T09%3a10%3a40.0000000Z&_timeInterval.intervalDuration=3600&q=Usage",

+ "LinkToFilteredSearchResultsUI": "https://portal.azure.com/AnalyticsBlade/subscriptions/12345a-1234b-123c-123d-12345678e/?query=search+*+&timeInterval.intervalEnd=2018-03-26T09%3a10%3a40.0000000Z&_timeInterval.intervalDuration=3600&q=Usage",

+ "LinkToSearchResultsAPI": "https://api.applicationinsights.io/v1/apps/0MyAppId0/metrics/requests/count",

+ "LinkToFilteredSearchResultsAPI": "https://api.applicationinsights.io/v1/apps/0MyAppId0/metrics/requests/count",

+ "SearchIntervalDurationMin": "15",

+ "SearchIntervalInMinutes": "15",

+ "Threshold": 10000.0,

+ "Operator": "Less Than",

+ "ApplicationId": "8e20151d-75b2-4d66-b965-153fb69d65a6",

+ "Dimensions": [

+ {

+ "name": "IP",

+ "value": "1.1.1.1"

+ }

+ ],

+ "SearchResults": {

+ "tables": [

+ {

+ "name": "PrimaryResult",

+ "columns": [

+ {

+ "name": "$table",

+ "type": "string"

+ },

+ {

+ "name": "Id",

+ "type": "string"

+ },

+ {

+ "name": "Timestamp",

+ "type": "datetime"

+ }

+ ],

+ "rows": [

+ [

+ "Fabrikam",

+ "33446677a",

+ "2018-02-02T15:03:12.18Z"

+ ],

+ [

+ "Contoso",

+ "33445566b",

+ "2018-02-02T15:16:53.932Z"

+ ]

+ ]

+ }

+ ],

+ "dataSources": [

+ {

+ "resourceId": "/subscriptions/a5ea27e2-7482-49ba-90b3-52e7496dd873/resourcegroups/test/providers/microsoft.operationalinsights/workspaces/test",

+ "tables": [

+ "Heartbeat"

+ ]

+ }

+ ]

+ },

+ "IncludedSearchResults": "True",

+ "AlertType": "Metric measurement"

+ }

+}

+```

+### Sample log alert when the monitoringService = Log Alerts V2

+> [!NOTE]

+> Log alert rules from API version 2020-05-01 use this payload type, which only supports common schema. Search results aren't embedded in the log alerts payload when you use this version. Use [dimensions](./alerts-unified-log.md#split-by-alert-dimensions) to provide context to fired alerts. You can also use `LinkToFilteredSearchResultsAPI` or `LinkToSearchResultsAPI` to access query results with the [Log Analytics API](/rest/api/loganalytics/dataaccess/query/get). If you must embed the results, use a logic app with the provided links to generate a custom payload.

+```json

+{

+ "alertContext": {

+ "properties": {

+ "name1": "value1",

+ "name2": "value2"

+ },

+ "conditionType": "LogQueryCriteria",

+ "condition": {

+ "windowSize": "PT10M",

+ "allOf": [

+ {

+ "searchQuery": "Heartbeat",

+ "metricMeasureColumn": "CounterValue",

+ "targetResourceTypes": "['Microsoft.Compute/virtualMachines']",

+ "operator": "LowerThan",

+ "threshold": "1",

+ "timeAggregation": "Count",

+ "dimensions": [

+ {

+ "name": "Computer",

+ "value": "TestComputer"

+ }

+ ],

+ "metricValue": 0.0,

+ "failingPeriods": {

+ "numberOfEvaluationPeriods": 1,

+ "minFailingPeriodsToAlert": 1

+ },

+ "linkToSearchResultsUI": "https://portal.azure.com#@12345a-1234b-123c-123d-12345678e/blade/Microsoft_Azure_Monitoring_Logs/LogsBlade/source/Alerts.EmailLinks/scope/%7B%22resources%22%3A%5B%7B%22resourceId%22%3A%22%2Fsubscriptions%212345a-1234b-123c-123d-12345678e%2FresourceGroups%2FContoso%2Fproviders%2FMicrosoft.Compute%2FvirtualMachines%2FContoso%22%7D%5D%7D/q/eJzzSE0sKklKTSypUSjPSC1KVQjJzE11T81LLUosSU1RSEotKU9NzdNIAfJKgDIaRgZGBroG5roGliGGxlYmJlbGJnoGEKCpp4dDmSmKMk0A/prettify/1/timespan/2020-07-07T13%3a54%3a34.0000000Z%2f2020-07-09T13%3a54%3a34.0000000Z",

+ "linkToFilteredSearchResultsUI": "https://portal.azure.com#@12345a-1234b-123c-123d-12345678e/blade/Microsoft_Azure_Monitoring_Logs/LogsBlade/source/Alerts.EmailLinks/scope/%7B%22resources%22%3A%5B%7B%22resourceId%22%3A%22%2Fsubscriptions%212345a-1234b-123c-123d-12345678e%2FresourceGroups%2FContoso%2Fproviders%2FMicrosoft.Compute%2FvirtualMachines%2FContoso%22%7D%5D%7D/q/eJzzSE0sKklKTSypUSjPSC1KVQjJzE11T81LLUosSU1RSEotKU9NzdNIAfJKgDIaRgZGBroG5roGliGGxlYmJlbGJnoGEKCpp4dDmSmKMk0A/prettify/1/timespan/2020-07-07T13%3a54%3a34.0000000Z%2f2020-07-09T13%3a54%3a34.0000000Z",

+ "linkToSearchResultsAPI": "https://api.loganalytics.io/v1/subscriptions/12345a-1234b-123c-123d-12345678e/resourceGroups/Contoso/providers/Microsoft.Compute/virtualMachines/Contoso/query?query=Heartbeat%7C%20where%20TimeGenerated%20between%28datetime%282020-07-09T13%3A44%3A34.0000000%29..datetime%282020-07-09T13%3A54%3A34.0000000%29%29&timespan=2020-07-07T13%3a54%3a34.0000000Z%2f2020-07-09T13%3a54%3a34.0000000Z",

+ "linkToFilteredSearchResultsAPI": "https://api.loganalytics.io/v1/subscriptions/12345a-1234b-123c-123d-12345678e/resourceGroups/Contoso/providers/Microsoft.Compute/virtualMachines/Contoso/query?query=Heartbeat%7C%20where%20TimeGenerated%20between%28datetime%282020-07-09T13%3A44%3A34.0000000%29..datetime%282020-07-09T13%3A54%3A34.0000000%29%29&timespan=2020-07-07T13%3a54%3a34.0000000Z%2f2020-07-09T13%3a54%3a34.0000000Z"

+ }

+ ],

+ "windowStartTime": "2020-07-07T13:54:34Z",

+ "windowEndTime": "2020-07-09T13:54:34Z"

+ }

+ }

+}

+```

+## Alert context fields for activity log alerts

+### Sample activity log alert when the monitoringService = Activity Log - Administrative

+```json

+{

+ "alertContext": {

+ "authorization": {

+ "action": "Microsoft.Compute/virtualMachines/restart/action",

+ "scope": "/subscriptions/<subscription ID>/resourceGroups/PipeLineAlertRG/providers/Microsoft.Compute/virtualMachines/WCUS-R2-ActLog"

+ },

+ "channels": "Operation",

+ "claims": "{\"aud\":\"https://management.core.windows.net/\",\"iss\":\"https://sts.windows.net/12345a-1234b-123c-123d-12345678e/\",\"iat\":\"1553260826\",\"nbf\":\"1553260826\",\"exp\":\"1553264726\",\"aio\":\"42JgYNjdt+rr+3j/dx68v018XhuFAwA=\",\"appid\":\"e9a02282-074f-45cf-93b0-50568e0e7e50\",\"appidacr\":\"2\",\"http://schemas.microsoft.com/identity/claims/identityprovider\":\"https://sts.windows.net/12345a-1234b-123c-123d-12345678e/\",\"http://schemas.microsoft.com/identity/claims/objectidentifier\":\"9778283b-b94c-4ac6-8a41-d5b493d03aa3\",\"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier\":\"9778283b-b94c-4ac6-8a41-d5b493d03aa3\",\"http://schemas.microsoft.com/identity/claims/tenantid\":\"12345a-1234b-123c-123d-12345678e\",\"uti\":\"v5wYC9t9ekuA2rkZSVZbAA\",\"ver\":\"1.0\"}",

+ "caller": "9778283b-b94c-4ac6-8a41-d5b493d03aa3",

+ "correlationId": "8ee9c32a-92a1-4a8f-989c-b0ba09292a91",

+ "eventSource": "Administrative",

+ "eventTimestamp": "2019-03-22T13:56:31.2917159+00:00",

+ "eventDataId": "161fda7e-1cb4-4bc5-9c90-857c55a8f57b",

+ "level": "Informational",

+ "operationName": "Microsoft.Compute/virtualMachines/restart/action",

+ "operationId": "310db69b-690f-436b-b740-6103ab6b0cba",

+ "status": "Succeeded",

+ "subStatus": "",

+ "submissionTimestamp": "2019-03-22T13:56:54.067593+00:00"

+ }

+}

+```

+### Sample activity log alert when the monitoringService = Activity Log - Policy

+```json

+{

+ "alertContext": {

+ "authorization": {

+ "action": "Microsoft.Resources/checkPolicyCompliance/read",

+ "scope": "/subscriptions/<GUID>"

+ },

+ "channels": "Operation",

+ "claims": "{\"aud\":\"https://management.azure.com/\",\"iss\":\"https://sts.windows.net/<GUID>/\",\"iat\":\"1566711059\",\"nbf\":\"1566711059\",\"exp\":\"1566740159\",\"aio\":\"42FgYOhynHNw0scy3T/bL71+xLyqEwA=\",\"appid\":\"<GUID>\",\"appidacr\":\"2\",\"http://schemas.microsoft.com/identity/claims/identityprovider\":\"https://sts.windows.net/<GUID>/\",\"http://schemas.microsoft.com/identity/claims/objectidentifier\":\"<GUID>\",\"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier\":\"<GUID>\",\"http://schemas.microsoft.com/identity/claims/tenantid\":\"<GUID>\",\"uti\":\"Miy1GzoAG0Scu_l3m1aIAA\",\"ver\":\"1.0\"}",

+ "caller": "<GUID>",

+ "correlationId": "<GUID>",

+ "eventSource": "Policy",

+ "eventTimestamp": "2019-08-25T11:11:34.2269098+00:00",

+ "eventDataId": "<GUID>",

+ "level": "Warning",

+ "operationName": "Microsoft.Authorization/policies/audit/action",

+ "operationId": "<GUID>",

+ "properties": {

+ "isComplianceCheck": "True",

+ "resourceLocation": "eastus2",

+ "ancestors": "<GUID>",

+ "policies": "[{\"policyDefinitionId\":\"/providers/Microsoft.Authorization/policyDefinitions/<GUID>/\",\"policySetDefinitionId\":\"/providers/Microsoft.Authorization/policySetDefinitions/<GUID>/\",\"policyDefinitionReferenceId\":\"vulnerabilityAssessmentMonitoring\",\"policySetDefinitionName\":\"<GUID>\",\"policyDefinitionName\":\"<GUID>\",\"policyDefinitionEffect\":\"AuditIfNotExists\",\"policyAssignmentId\":\"/subscriptions/<GUID>/providers/Microsoft.Authorization/policyAssignments/SecurityCenterBuiltIn/\",\"policyAssignmentName\":\"SecurityCenterBuiltIn\",\"policyAssignmentScope\":\"/subscriptions/<GUID>\",\"policyAssignmentSku\":{\"name\":\"A1\",\"tier\":\"Standard\"},\"policyAssignmentParameters\":{}}]"

+ },

+ "status": "Succeeded",

+ "subStatus": "",

+ "submissionTimestamp": "2019-08-25T11:12:46.1557298+00:00"

+ }

+}

+```

+### Sample activity log alert when the monitoringService = Activity Log - Autoscale

+```json

+{

+ "alertContext": {

+ "channels": "Admin, Operation",

+ "claims": "{\"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/spn\":\"Microsoft.Insights/autoscaleSettings\"}",

+ "caller": "Microsoft.Insights/autoscaleSettings",

+ "correlationId": "<GUID>",

+ "eventSource": "Autoscale",

+ "eventTimestamp": "2019-08-21T16:17:47.1551167+00:00",

+ "eventDataId": "<GUID>",

+ "level": "Informational",

+ "operationName": "Microsoft.Insights/AutoscaleSettings/Scaleup/Action",

+ "operationId": "<GUID>",

+ "properties": {

+ "description": "The autoscale engine attempting to scale resource '/subscriptions/d<GUID>/resourceGroups/testRG/providers/Microsoft.Compute/virtualMachineScaleSets/testVMSS' from 9 instances count to 10 instances count.",

+ "resourceName": "/subscriptions/<GUID>/resourceGroups/voiceassistancedemo/providers/Microsoft.Compute/virtualMachineScaleSets/alexademo",

+ "oldInstancesCount": "9",

+ "newInstancesCount": "10",

+ "activeAutoscaleProfile": "{\r\n \"Name\": \"Auto created scale condition\",\r\n \"Capacity\": {\r\n \"Minimum\": \"1\",\r\n \"Maximum\": \"10\",\r\n \"Default\": \"1\"\r\n },\r\n \"Rules\": [\r\n {\r\n \"MetricTrigger\": {\r\n \"Name\": \"Percentage CPU\",\r\n \"Namespace\": \"microsoft.compute/virtualmachinescalesets\",\r\n \"Resource\": \"/subscriptions/<GUID>/resourceGroups/testRG/providers/Microsoft.Compute/virtualMachineScaleSets/testVMSS\",\r\n \"ResourceLocation\": \"eastus\",\r\n \"TimeGrain\": \"PT1M\",\r\n \"Statistic\": \"Average\",\r\n \"TimeWindow\": \"PT5M\",\r\n \"TimeAggregation\": \"Average\",\r\n \"Operator\": \"GreaterThan\",\r\n \"Threshold\": 0.0,\r\n \"Source\": \"/subscriptions/<GUID>/resourceGroups/testRG/providers/Microsoft.Compute/virtualMachineScaleSets/testVMSS\",\r\n \"MetricType\": \"MDM\",\r\n \"Dimensions\": [],\r\n \"DividePerInstance\": false\r\n },\r\n \"ScaleAction\": {\r\n \"Direction\": \"Increase\",\r\n \"Type\": \"ChangeCount\",\r\n \"Value\": \"1\",\r\n \"Cooldown\": \"PT1M\"\r\n }\r\n }\r\n ]\r\n}",

+ "lastScaleActionTime": "Wed, 21 Aug 2019 16:17:47 GMT"

+ },

+ "status": "Succeeded",

+ "submissionTimestamp": "2019-08-21T16:17:47.2410185+00:00"

+ }

+}

+```

+### Sample activity log alert when the monitoringService = Activity Log - Security

+```json

+{

+ "alertContext": {

+ "channels": "Operation",

+ "correlationId": "<GUID>",

+ "eventSource": "Security",

+ "eventTimestamp": "2019-08-26T08:34:14+00:00",

+ "eventDataId": "<GUID>",

+ "level": "Informational",

+ "operationName": "Microsoft.Security/locations/alerts/activate/action",

+ "operationId": "<GUID>",

+ "properties": {

+ "threatStatus": "Quarantined",

+ "category": "Virus",

+ "threatID": "2147519003",

+ "filePath": "C:\\AlertGeneration\\test.eicar",

+ "protectionType": "Windows Defender",

+ "actionTaken": "Blocked",

+ "resourceType": "Virtual Machine",

+ "severity": "Low",

+ "compromisedEntity": "testVM",

+ "remediationSteps": "[\"No user action is necessary\"]",

+ "attackedResourceType": "Virtual Machine"

+ },

+ "status": "Active",

+ "submissionTimestamp": "2019-08-26T09:28:58.3019107+00:00"

+ }

+}

+```

+### Sample activity log alert when the monitoringService = ServiceHealth

+```json

+{

+ "alertContext": {

+ "authorization": null,

+ "channels": 1,

+ "claims": null,

+ "caller": null,

+ "correlationId": "f3cf2430-1ee3-4158-8e35-7a1d615acfc7",

+ "eventSource": 2,

+ "eventTimestamp": "2019-06-24T11:31:19.0312699+00:00",

+ "httpRequest": null,

+ "eventDataId": "<GUID>",

+ "level": 3,

+ "operationName": "Microsoft.ServiceHealth/maintenance/action",

+ "operationId": "<GUID>",

+ "properties": {

+ "title": "Azure Synapse Analytics Scheduled Maintenance Pending",

+ "service": "Azure Synapse Analytics",

+ "region": "East US",

+ "communication": "<MESSAGE>",

+ "incidentType": "Maintenance",

+ "trackingId": "<GUID>",

+ "impactStartTime": "2019-06-26T04:00:00Z",

+ "impactMitigationTime": "2019-06-26T12:00:00Z",

+ "impactedServices": "[{\"ImpactedRegions\":[{\"RegionName\":\"East US\"}],\"ServiceName\":\"Azure Synapse Analytics\"}]",

+ "impactedServicesTableRows": "<tr>\r\n<td align='center' style='padding: 5px 10px; border-right:1px solid black; border-bottom:1px solid black'>Azure Synapse Analytics</td>\r\n<td align='center' style='padding: 5px 10px; border-bottom:1px solid black'>East US<br></td>\r\n</tr>\r\n",

+ "defaultLanguageTitle": "Azure Synapse Analytics Scheduled Maintenance Pending",

+ "defaultLanguageContent": "<MESSAGE>",

+ "stage": "Planned",

+ "communicationId": "<GUID>",

+ "maintenanceId": "<GUID>",

+ "isHIR": "false",

+ "version": "0.1.1"

+ },

+ "status": "Active",

+ "subStatus": null,

+ "submissionTimestamp": "2019-06-24T11:31:31.7147357+00:00",

+ "ResourceType": null

+ }

+}

+```

+### Sample activity log alert when the monitoringService = ResourceHealth

+```json

+{

+ "alertContext": {

+ "channels": "Admin, Operation",

+ "correlationId": "<GUID>",

+ "eventSource": "ResourceHealth",

+ "eventTimestamp": "2019-06-24T15:42:54.074+00:00",

+ "eventDataId": "<GUID>",

+ "level": "Informational",

+ "operationName": "Microsoft.Resourcehealth/healthevent/Activated/action",

+ "operationId": "<GUID>",

+ "properties": {

+ "title": "This virtual machine is stopping and deallocating as requested by an authorized user or process",

+ "details": null,

+ "currentHealthStatus": "Unavailable",

+ "previousHealthStatus": "Available",

+ "type": "Downtime",

+ "cause": "UserInitiated"

+ },

+ "status": "Active",

+ "submissionTimestamp": "2019-06-24T15:45:20.4488186+00:00"

+ }

+}

+```

+## Alert context fields for Prometheus alerts

+### Sample Prometheus alert

+```json

+{

+ "alertContext": {

+ "interval": "PT1M",

+ "expression": "sql_up > 0",

+ "expressionValue": "0",

+ "for": "PT2M",

+ "labels": {

+ "Environment": "Prod",

+ "cluster": "myCluster1"

+ },

+ "annotations": {

+ "summary": "alert on SQL availability"

+ },

+ "ruleGroup": "/subscriptions/<subscription ID>/resourceGroups/myResourceGroup/providers/Microsoft.AlertsManagement/prometheusRuleGroups/myRuleGroup"

+ }

+}

+```

+## Enable the common alert schema

+Use action groups in the Azure portal or use the REST API to enable the common alert schema. Schemas are defined at the action level. For example, you must separately enable the schema for an email action and a webhook action.

+> Smart detection alerts support the common schema by default. You don't have to enable the common schema for smart detection alerts.

+### Enable the common schema in the Azure portal

+### Enable the common schema using the REST API

+You can also use the [Action Groups API](/rest/api/monitor/actiongroups) to opt in to the common alert schema. In the [create or update](/rest/api/monitor/actiongroups/createorupdate) REST API call,

+- Set the "useCommonAlertSchema" flag to `true` to enable the common schema

+- Set the "useCommonAlertSchema" flag to `false` to use the non-common schema for email, webhook, Logic Apps, Azure Functions, or Automation runbook actions.

+#### Sample REST API call for using the common schema

+The following [create or update](/rest/api/monitor/actiongroups/createorupdate) REST API request:

+- Enables the common alert schema for the email action "John Doe's email."

+- Disables the common alert schema for the email action "Jane Smith's email."

+- Enables the common alert schema for the webhook action "Sample webhook."

+ > [!NOTE]

+ > The [common schema](alerts-common-schema.md) overwrites custom configurations. Therefore, you can't use both custom properties and the common schema for log alerts.

+ > [!NOTE]

+ > The [common schema](alerts-common-schema.md) overwrites custom configurations. Therefore, you can't use both custom properties and the common schema for activity log alerts.

+## Create a new alert rule using the CLI

+You can create a new alert rule using the [Azure CLI](/cli/azure/get-started-with-azure-cli). The following code examples use [Azure Cloud Shell](../../cloud-shell/overview.md). You can see the full list of the [Azure CLI commands for Azure Monitor](/cli/azure/azure-cli-reference-for-monitor#azure-monitor-references).

+## Create a new alert rule with PowerShell

+- To create a metric alert rule using PowerShell, use the [Add-AzMetricAlertRuleV2](/powershell/module/az.monitor/add-azmetricalertrulev2) cmdlet.

+- To create a log alert rule using PowerShell, use the [New-AzScheduledQueryRule](/powershell/module/az.monitor/new-azscheduledqueryrule) cmdlet.

+- To create an activity log alert rule using PowerShell, use the [Set-AzActivityLogAlert](/powershell/module/az.monitor/set-azactivitylogalert) cmdlet.

+## Create a new alert rule using an ARM template

+You can use an [Azure Resource Manager template (ARM template)](../../azure-resource-manager/templates/syntax.md) to configure alert rules consistently in all of your environments.

+1. Create a new resource, using the following resource types:

+ - For metric alerts: `Microsoft.Insights/metricAlerts`

+ - For log alerts: `Microsoft.Insights/scheduledQueryRules`

+ - For activity log, service health, and resource health alerts: `microsoft.Insights/activityLogAlerts`

+ > [!NOTE]

+ > - Metric alerts for an Azure Log Analytics workspace resource type (`Microsoft.OperationalInsights/workspaces`) are configured differently than other metric alerts. For more information, see [Resource Template for Metric Alerts for Logs](alerts-metric-logs.md#resource-template-for-metric-alerts-for-logs).

+ > - We recommend that you create the metric alert using the same resource group as your target resource.

+1. Copy one of the templates from these sample ARM templates.

+ - For metric alerts: [Resource Manager template samples for metric alert rules](resource-manager-alerts-metric.md)

+ - For log alerts: [Resource Manager template samples for log alert rules](resource-manager-alerts-log.md)

+ - For activity log alerts: [Resource Manager template samples for activity log alert rules](resource-manager-alerts-activity-log.md)

+ - For resource health alerts: [Resource Manager template samples for resource health alert rules](resource-manager-alerts-resource-health.md)

+1. Edit the template file to contain appropriate information for your alert, and save the file as \<your-alert-template-file\>.json.

+1. Edit the corresponding parameters file to customize the alert, and save as \<your-alert-template-file\>.parameters.json.

+1. Set the `metricName` parameter, using one of the values in [Azure Monitor supported metrics](../essentials/metrics-supported.md).

+1. Deploy the template using [PowerShell](../../azure-resource-manager/templates/deploy-powershell.md#deploy-local-template) or the [CLI](../../azure-resource-manager/templates/deploy-cli.md#deploy-local-template).

+### Additional properties for activity log alert ARM templates

+> - Activity log alerts are defined at the subscription level. You can't define a single alert rule on more than one subscription.

+> - It may take up to five minutes for a new activity log alert rule to become active.

+ARM templates for activity log alerts contain additional properties for the conditions fields. The **Resource Health**, **Advisor** and **Service Health** fields have extra properties fields.

+## Create an activity log alert rule from the Activity log pane

+You can also create an activity log alert on future events similar to an activity log event that already occurred.

+1. In the [portal](https://portal.azure.com/), [go to the Activity log pane](../essentials/activity-log.md#view-the-activity-log).

+1. Filter or find the desired event. Then create an alert by selecting **Add activity log alert**.

+ :::image type="content" source="media/alerts-create-new-alert-rule/create-alert-rule-from-activity-log-event-new.png" alt-text="Screenshot that shows creating an alert rule from an activity log event." lightbox="media/alerts-create-new-alert-rule/create-alert-rule-from-activity-log-event-new.png":::

+1. The **Create alert rule** wizard opens, with the scope and condition already provided according to the previously selected activity log event. If necessary, you can edit and modify the scope and condition at this stage. By default, the exact scope and condition for the new rule are copied from the original event attributes. For example, the exact resource on which the event occurred, and the specific user or service name that initiated the event, are both included by default in the new alert rule.

+ If you want to make the alert rule more general, modify the scope and condition accordingly. See steps 3-9 in the section "Create a new alert rule in the Azure portal."

+1. Follow the rest of the steps from [Create a new alert rule in the Azure portal](#create-a-new-alert-rule-in-the-azure-portal).

+ Title: Resource Manager template samples for activity log alerts

+description: Sample Azure Resource Manager templates to deploy Azure Monitor activity log alerts.

+# Resource Manager template samples for activity log alert rules in Azure Monitor

+This article includes samples of [Azure Resource Manager templates](../../azure-resource-manager/templates/syntax.md) to create and configure activity log alerts in Azure Monitor.

+## Activity log alert rule using the **Administrative** condition:

+This example sets the condition to the **Administrative** category:

+```json

+"condition": {

+ "allOf": [

+ {

+ "field": "category",

+ "equals": "Administrative"

+ },

+ {

+ "field": "resourceType",

+ "equals": "Microsoft.Resources/deployments"

+ }

+ ]

+ }

+```

+```json

+{

+ "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",

+ "contentVersion": "1.0.0.0",

+ "parameters": {

+ "activityLogAlertName": {

+ "type": "string",

+ "metadata": {

+ "description": "Unique name (within the Resource Group) for the Activity log alert."

+ }

+ },

+ "activityLogAlertEnabled": {

+ "type": "bool",

+ "defaultValue": true,

+ "metadata": {

+ "description": "Indicates whether or not the alert is enabled."

+ }

+ },

+ "actionGroupResourceId": {

+ "type": "string",

+ "metadata": {

+ "description": "Resource Id for the Action group."

+ }

+ }

+ },

+ "resources": [

+ {

+ "type": "Microsoft.Insights/activityLogAlerts",

+ "apiVersion": "2017-04-01",

+ "name": "[parameters('activityLogAlertName')]",

+ "location": "Global",

+ "properties": {

+ "enabled": "[parameters('activityLogAlertEnabled')]",

+ "scopes": [

+ "[subscription().id]"

+ ],

+ "condition": {

+ "allOf": [

+ {

+ "field": "category",

+ "equals": "Administrative"

+ },

+ {

+ "field": "operationName",

+ "equals": "Microsoft.Resources/deployments/write"

+ },

+ {

+ "field": "resourceType",

+ "equals": "Microsoft.Resources/deployments"

+ }

+ ]

+ },

+ "actions": {

+ "actionGroups":

+ [

+ {

+ "actionGroupId": "[parameters('actionGroupResourceId')]"

+ }

+ ]

+ }

+ }

+ }

+ ]

+}

+```

+## Template to send activity log alerts on service notifications

+The following template creates an action group with an email target and enables all service health notifications for the target subscription. Save this template as `CreateServiceHealthAlert.json`.

+```json

+{

+ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",

+ "contentVersion": "1.0.0.0",

+ "parameters": {

+ "actionGroups_name": {

+ "type": "string",

+ "defaultValue": "SubHealth"

+ },

+ "activityLogAlerts_name": {

+ "type": "string",

+ "defaultValue": "ServiceHealthActivityLogAlert"

+ },

+ "emailAddress": {

+ "type": "string"

+ }

+ },

+ "variables": {

+ "alertScope": "[format('/subscriptions/{0}', subscription().subscriptionId)]"

+ },

+ "resources": [

+ {

+ "type": "microsoft.insights/actionGroups",

+ "apiVersion": "2019-06-01",

+ "name": "[parameters('actionGroups_name')]",

+ "location": "Global",

+ "properties": {

+ "groupShortName": "[parameters('actionGroups_name')]",

+ "enabled": true,

+ "emailReceivers": [

+ {

+ "name": "[parameters('actionGroups_name')]",

+ "emailAddress": "[parameters('emailAddress')]"

+ }

+ ],

+ "smsReceivers": [],

+ "webhookReceivers": []

+ }

+ },

+ {

+ "type": "microsoft.insights/activityLogAlerts",

+ "apiVersion": "2017-04-01",

+ "name": "[parameters('activityLogAlerts_name')]",

+ "location": "Global",

+ "properties": {

+ "scopes": [

+ "[variables('alertScope')]"

+ ],

+ "condition": {

+ "allOf": [

+ {

+ "field": "category",

+ "equals": "ServiceHealth"

+ },

+ {

+ "field": "properties.incidentType",

+ "equals": "Incident"

+ }

+ ]

+ },

+ "actions": {

+ "actionGroups": [

+ {

+ "actionGroupId": "[resourceId('microsoft.insights/actionGroups', parameters('actionGroups_name'))]",

+ "webhookProperties": {}

+ }

+ ]

+ },

+ "enabled": true

+ },

+ "dependsOn": [

+ "[resourceId('microsoft.insights/actionGroups', parameters('actionGroups_name'))]"

+ ]

+ }

+ ]

+}

+```

+## Next steps

+- [Get other sample templates for Azure Monitor](../resource-manager-samples.md).

+- [Learn more about alert rules](./alerts-overview.md).

+ Title: Resource Manager template samples for resource health alerts

+description: Sample Azure Resource Manager templates to deploy Azure Monitor resource health alerts.

+# Resource Manager template samples for resource health alert rules in Azure Monitor

+This article includes samples of [Azure Resource Manager templates](../../azure-resource-manager/templates/syntax.md) to create and configure resource health alerts in Azure Monitor.

+See [Configure resource health alerts using Resource Manager templates](../../service-health/resource-health-alert-arm-template-guide.md) for information about configuring resource health alerts using ARM templates.

+## Basic template for Resource Health alerts

+You can use this base template as a starting point for creating Resource Health alerts. This template will work as written, and will sign you up to receive alerts for all newly activated resource health events across all resources in a subscription.

+```json

+{

+ "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",

+ "contentVersion": "1.0.0.0",

+ "parameters": {

+ "activityLogAlertName": {

+ "type": "string",

+ "metadata": {

+ "description": "Unique name (within the Resource Group) for the Activity log alert."

+ }

+ },

+ "actionGroupResourceId": {

+ "type": "string",

+ "metadata": {

+ "description": "Resource Id for the Action group."

+ }

+ }

+ },

+ "resources": [

+ {

+ "type": "Microsoft.Insights/activityLogAlerts",

+ "apiVersion": "2017-04-01",

+ "name": "[parameters('activityLogAlertName')]",

+ "location": "Global",

+ "properties": {

+ "enabled": true,

+ "scopes": [

+ "[subscription().id]"

+ ],

+ "condition": {

+ "allOf": [

+ {

+ "field": "category",

+ "equals": "ResourceHealth"

+ },

+ {

+ "field": "status",

+ "equals": "Active"

+ }

+ ]

+ },

+ "actions": {

+ "actionGroups":

+ [

+ {

+ "actionGroupId": "[parameters('actionGroupResourceId')]"

+ }

+ ]

+ }

+ }

+ }

+ ]

+}

+```

+## Template to maximize the signal to noise ratio

+This sample template is configured to maximize the signal to noise ratio. Keep in mind that there can be instances cases where the currentHealthStatus, previousHealthStatus, and cause property values may be null in some events.

+See [Configure resource health alerts using Resource Manager templates](../../service-health/resource-health-alert-arm-template-guide.md) for information about configuring resource health alerts using ARM templates.

+```json

+{

+ "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",

+ "contentVersion": "1.0.0.0",

+ "parameters": {

+ "activityLogAlertName": {

+ "type": "string",

+ "metadata": {

+ "description": "Unique name (within the Resource Group) for the Activity log alert."

+ }

+ },

+ "actionGroupResourceId": {

+ "type": "string",

+ "metadata": {

+ "description": "Resource Id for the Action group."

+ }

+ }

+ },

+ "resources": [

+ {

+ "type": "Microsoft.Insights/activityLogAlerts",

+ "apiVersion": "2017-04-01",

+ "name": "[parameters('activityLogAlertName')]",

+ "location": "Global",

+ "properties": {

+ "enabled": true,

+ "scopes": [

+ "[subscription().id]"

+ ],

+ "condition": {

+ "allOf": [

+ {

+ "field": "category",

+ "equals": "ResourceHealth",

+ "containsAny": null

+ },

+ {

+ "anyOf": [

+ {

+ "field": "properties.currentHealthStatus",

+ "equals": "Available",

+ "containsAny": null

+ },

+ {

+ "field": "properties.currentHealthStatus",

+ "equals": "Unavailable",

+ "containsAny": null

+ },

+ {

+ "field": "properties.currentHealthStatus",

+ "equals": "Degraded",

+ "containsAny": null

+ }

+ ]

+ },

+ {

+ "anyOf": [

+ {

+ "field": "properties.previousHealthStatus",

+ "equals": "Available",

+ "containsAny": null

+ },

+ {

+ "field": "properties.previousHealthStatus",

+ "equals": "Unavailable",

+ "containsAny": null

+ },

+ {

+ "field": "properties.previousHealthStatus",

+ "equals": "Degraded",

+ "containsAny": null

+ }

+ ]

+ },

+ {

+ "anyOf": [

+ {

+ "field": "properties.cause",

+ "equals": "PlatformInitiated",

+ "containsAny": null

+ }

+ ]

+ },

+ {

+ "anyOf": [

+ {

+ "field": "status",

+ "equals": "Active",

+ "containsAny": null

+ },

+ {

+ "field": "status",

+ "equals": "Resolved",

+ "containsAny": null

+ },

+ {

+ "field": "status",

+ "equals": "In Progress",

+ "containsAny": null

+ },

+ {

+ "field": "status",

+ "equals": "Updated",

+ "containsAny": null

+ }

+ ]

+ }

+ ]

+ },

+ "actions": {

+ "actionGroups": [

+ {

+ "actionGroupId": "[parameters('actionGroupResourceId')]"

+ }

+ ]

+ }

+ }

+ }

+ ]

+}

+```

+## Next steps

+Learn more about Resource Health:

+- [Azure Resource Health overview](../../service-health/resource-health-overview.md)

+- [Resource types and health checks available through Azure Resource Health](../../service-health/resource-health-checks-resource-types.md)

+- [Configure Alerts for Service Health](../../service-health/alerts-activity-log-service-notifications-arm.md)

+| [AHDSMedTechDiagnosticLogs](/azure/azure-monitor/reference/tables/AHDSMedTechDiagnosticLogs) | Health Data Services operational logs. |

+ | parse RawData with

+>[!IMPORTANT]

+>The AD Site Name field is required to create an Azure NetApp Files AD connection. The AD DS site defined must exist and be properly configured.

+## Key Vault in private network

+If you have configured [Private Endpoint](../private-link/private-endpoint-overview.md) to your Key Vault, Azure Web PubSub Service cannot access the Key Vault via public network. You need to set up a [Shared Private Endpoint](./howto-secure-shared-private-endpoints-key-vault.md) to let Azure Web PubSub Service access your Key Vault via private network.

+After you create a Shared Private Endpoint, you can create a custom certificate as usual. **You don't have to change the domain in Key Vault URI**. For example, if your Key Vault base URI is `https://contoso.vault.azure.net`, you still use this URI to configure custom certificate.

+You don't have to explicitly allow Azure Web PubSub Service IPs in Key Vault firewall settings. For more info, see [Key Vault private link diagnostics](../key-vault/general/private-link-diagnostics.md).

+ Title: Access Key Vault in private network through Shared Private Endpoints

+description: How to access key vault in private network through Shared Private Endpoints

+# Access Key Vault in private network through Shared Private Endpoints

+Azure Web PubSub Service can access your Key Vault in private network through Shared Private Endpoints. In this way you don't have to expose your Key Vault on public network.

+ :::image type="content" alt-text="Diagram showing architecture of shared private endpoint." source="media\howto-secure-shared-private-endpoints-key-vault\shared-private-endpoint-overview.png" :::

+## Shared Private Link Resources Management

+Private endpoints of secured resources that are created through Azure Web PubSub Service APIs are referred to as *shared private link resources*. This is because you're "sharing" access to a resource, such as an Azure Key Vault, that has been integrated with the [Azure Private Link service](https://azure.microsoft.com/services/private-link/). These private endpoints are created inside Azure Web PubSub Service execution environment and aren't directly visible to you.

+> [!NOTE]

+> The examples in this article are based on the following assumptions:

+> * The resource ID of this Azure Web PubSub Service is _/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/contoso/providers/Microsoft.SignalRService/webpubsub/contoso-webpubsub .

+> * The resource ID of Azure Key Vault is _/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/contoso/providers/Microsoft.KeyVault/vaults/contoso-kv_.

+The rest of the examples show how the *contoso-webpubsub* service can be configured so that its outbound calls to Key Vault go through a private endpoint rather than public network.

+### Step 1: Create a shared private link resource to the Key Vault

+#### [Azure portal](#tab/azure-portal)

+1. In the Azure portal, go to your Azure Web PubSub Service resource.

+1. In the menu pane, select **Networking**. Switch to **Private access** tab.

+1. Click **Add shared private endpoint**.

+ :::image type="content" alt-text="Screenshot of shared private endpoints management." source="media\howto-secure-shared-private-endpoints-key-vault\portal-shared-private-endpoints-management.png" lightbox="media\howto-secure-shared-private-endpoints-key-vault\portal-shared-private-endpoints-management.png" :::

+1. Fill in a name for the shared private endpoint.

+1. Select the target linked resource either by selecting from your owned resources or by filling a resource ID.

+1. Click **Add**.

+ :::image type="content" alt-text="Screenshot of adding a shared private endpoint." source="media\howto-secure-shared-private-endpoints-key-vault\portal-shared-private-endpoints-add.png" :::

+1. The shared private endpoint resource will be in **Succeeded** provisioning state. The connection state is **Pending** approval at target resource side.

+ :::image type="content" alt-text="Screenshot of an added shared private endpoint." source="media\howto-secure-shared-private-endpoints-key-vault\portal-shared-private-endpoints-added.png" lightbox="media\howto-secure-shared-private-endpoints-key-vault\portal-shared-private-endpoints-added.png" :::

+#### [Azure CLI](#tab/azure-cli)

+You can make the following API call with the [Azure CLI](/cli/azure/) to create a shared private link resource:

+```dotnetcli

+az rest --method put --uri https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/contoso/providers/Microsoft.SignalRService/webpubsub/contoso-webpubsub/sharedPrivateLinkResources/kv-pe?api-version=2022-08-01-preview --body @create-pe.json

+```

+The contents of the *create-pe.json* file, which represent the request body to the API, are as follows:

+```json

+{

+ "name": "contoso-kv",

+ "properties": {

+ "privateLinkResourceId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/contoso/providers/Microsoft.KeyVault/vaults/contoso-kv",

+ "groupId": "vault",

+ "requestMessage": "please approve"

+ }

+}

+```

+The process of creating an outbound private endpoint is a long-running (asynchronous) operation. As in all asynchronous Azure operations, the `PUT` call returns an `Azure-AsyncOperation` header value that looks like the following:

+```plaintext

+"Azure-AsyncOperation": "https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/contoso/providers/Microsoft.SignalRService/webpubsub/contoso-webpubsub/operationStatuses/c0786383-8d5f-4554-8d17-f16fcf482fb2?api-version=2022-08-01-preview"

+```

+You can poll this URI periodically to obtain the status of the operation.

+If you're using the CLI, you can poll for the status by manually querying the `Azure-AsyncOperationHeader` value,

+```dotnetcli

+az rest --method get --uri https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/contoso/providers/Microsoft.SignalRService/webpubsub/contoso-webpubsub/operationStatuses/c0786383-8d5f-4554-8d17-f16fcf482fb2?api-version=2022-08-01-preview

+```

+Wait until the status changes to "Succeeded" before proceeding to the next steps.

+--

+### Step 2a: Approve the private endpoint connection for the Key Vault

+#### [Azure portal](#tab/azure-portal)

+1. In the Azure portal, select the **Networking** tab of your Key Vault and navigate to **Private endpoint connections**. After the asynchronous operation has succeeded, there should be a request for a private endpoint connection with the request message from the previous API call.

+ :::image type="content" alt-text="Screenshot of the Azure portal, showing the Private endpoint connections pane." source="media\howto-secure-shared-private-endpoints-key-vault\portal-key-vault-approve-private-endpoint.png" :::

+1. Select the private endpoint that Azure Web PubSub Service created. Click **Approve**.

+ Make sure that the private endpoint connection appears as shown in the following screenshot. It could take one to two minutes for the status to be updated in the portal.

+ :::image type="content" alt-text="Screenshot of the Azure portal, showing an Approved status on the Private endpoint connections pane." source="media\howto-secure-shared-private-endpoints-key-vault\portal-key-vault-approved-private-endpoint.png" :::

+#### [Azure CLI](#tab/azure-cli)

+1. List private endpoint connections.

+ ```dotnetcli

+ az network private-endpoint-connection list -n <key-vault-resource-name> -g <key-vault-resource-group-name> --type 'Microsoft.KeyVault/vaults'

+ ```

+ There should be a pending private endpoint connection. Note down its ID.

+ ```json

+ [

+ {

+ "id": "<id>",

+ "location": "",

+ "name": "",

+ "properties": {

+ "privateLinkServiceConnectionState": {

+ "actionRequired": "None",

+ "description": "Please approve",

+ "status": "Pending"

+ }

+ }

+ }

+ ]

+ ```

+1. Approve the private endpoint connection.

+ ```dotnetcli

+ az network private-endpoint-connection approve --id <private-endpoint-connection-id>

+ ```

+--

+### Step 2b: Query the status of the shared private link resource

+It takes minutes for the approval to be propagated to Azure Web PubSub Service. You can check the state using either Azure portal or Azure CLI.

+#### [Azure portal](#tab/azure-portal)

+ :::image type="content" alt-text="Screenshot of an approved shared private endpoint." source="media\howto-secure-shared-private-endpoints-key-vault\portal-shared-private-endpoints-approved.png" lightbox="media\howto-secure-shared-private-endpoints-key-vault\portal-shared-private-endpoints-approved.png" :::

+#### [Azure CLI](#tab/azure-cli)

+```dotnetcli

+az rest --method get --uri https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/contoso/providers/Microsoft.SignalRService/webpubsub/contoso-webpubsub/sharedPrivateLinkResources/func-pe?api-version=2022-08-01-preview

+```

+This would return a JSON, where the connection state would show up as "status" under the "properties" section.

+```json

+{

+ "name": "contoso-kv",

+ "properties": {

+ "privateLinkResourceId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/contoso/providers/Microsoft.KeyVault/vaults/contoso-kv",

+ "groupId": "vaults",

+ "requestMessage": "please approve",

+ "status": "Approved",

+ "provisioningState": "Succeeded"

+ }

+}

+```

+If the "Provisioning State" (`properties.provisioningState`) of the resource is `Succeeded` and "Connection State" (`properties.status`) is `Approved`, it means that the shared private link resource is functional and Azure Web PubSub Service can communicate over the private endpoint.

+--

+At this point, the private endpoint between Azure Web PubSub Service and Azure Key Vault is established.

+Now you can configure features like custom domain as usual. **You don't have to use a special domain for Key Vault**. DNS resolution is automatically handled by Azure Web PubSub Service.

+## Next steps

+Learn more:

+description: This article provides an OData language reference and the full syntax for creating filter expressions in Azure Web PubSub service queries.

+# OData filter syntax in the Azure Web PubSub service

+The Azure Web PubSub `filter` parameter defines inclusion or exclusion criteria for sending messages to connections. This parameter is used in the [Send to all](/rest/api/webpubsub/dataplane/web-pub-sub/send-to-all), [Send to group](/rest/api/webpubsub/dataplane/web-pub-sub/send-to-group), and [Send to user](/rest/api/webpubsub/dataplane/web-pub-sub/send-to-user) operations.

+- A description of the OData syntax of the `filter` parameter with examples.

+- A description of the complete [Extended Backus-Naur Form (EBNF)](#formal-grammar) grammar.

+A filter in the OData language is a Boolean expression. It can be one of several expression types, as shown in the following EBNF description:

+You can use an [interactive syntax diagram](https://aka.ms/awps/filter-syntax-diagram) to explore the syntax grammar rules.

+The [Formal grammar](#formal-grammar) section of this article provides the complete EBNF.

+By using the filter syntax, you can control sending messages to connections that match the identifier criteria. Azure Web PubSub supports the following identifiers:

+| Identifier | Description | Note | Example |

+| `userId` | The user ID of the connection | Case insensitive. It can be used in [string operations](#supported-operations). | `userId eq 'user1'`

+| `connectionId` | The connection ID of the connection | Case insensitive. It can be used in [string operations](#supported-operations). | `connectionId ne '123'`

+| `groups` | The collection of groups that the connection is currently in | Case insensitive. It can be used in [collection operations](#supported-operations). | `'group1' in groups`

+Identifiers refer to the property value of a connection. Azure Web PubSub supports three identifiers that match the property name of the connection model. The service supports the `userId` and `connectionId` identifiers in string operations, and it supports the `groups` identifier in [collection operations](#supported-operations).

+For example, to filter out connections with a user ID of `user1`, you specify the filter as `userId eq 'user1'`. Read through the following sections for more examples of using the filter.

+The expression for a filter is a Boolean expression. Azure Web PubSub sends messages to connections with filter expressions evaluated to `true`.

+The types of Boolean expressions include:

+- Logical expressions that combine other Boolean expressions by using the operators `and`, `or`, and `not`.

+- Comparison expressions, which compare fields or range variables to constant values by using the operators `eq`, `ne`, `gt`, `lt`, `ge`, and `le`.

+- The Boolean literals `true` and `false`. These constants can be useful sometimes when you're programmatically generating filters. Otherwise, they don't tend to be used in practice.

+- Boolean expressions in parentheses. Using parentheses helps to explicitly determine the order of operations in a filter. The [Operator precedence](#operator-precedence) section of this article describes the default precedence of the OData operators.

+| **Logical operators**

+| **Comparison operators**

+| **In operator**

+| `in` | Right operand *must* be either a comma-separated list of primitive values, enclosed in parentheses, or a single expression that resolves to a collection| `userId ne 'user1'`

+| **Grouping operator**

+| **String functions**

+| `string tolower(string p)` | Gets the lower case for the string value | `tolower(userId) eq 'user1'` can match connections for user `USER1`

+| `string toupper(string p)` | Gets the upper case for the string value | `toupper(userId) eq 'USER1'` can match connections for user `user1`

+| `string trim(string p)` | Trims the string value | `trim(userId) eq 'user1'` can match connections for user ` user1 `

+| `bool endswith(string p0, string p1)` | Checks if `p0` ends with `p1` | `endswith(userId,'de')` can match connections for user `user-ab-de`

+| `bool startswith(string p0, string p1)` | Checks if `p0` starts with `p1` | `startswith(userId,'user')` can match connections for user `user-ab-de`

+| `int indexof(string p0, string p1)` | Gets the index of `p1` in `p0`, or returns `-1` if `p0` doesn't contain `p1` | `indexof(userId,'-ab-') ge 0` can match connections for user `user-ab-de`

+| `int length(string p)` | Gets the length of the input string | `length(userId) gt 1` can match connections for user `user-ab-de`

+| **Collection function**

+| `int length(collection p)` | Gets the length of the collection | `length(groups) gt 1` can match connections in two groups

+If you write a filter expression with no parentheses around its subexpressions, the Azure Web PubSub service will evaluate it according to a set of operator precedence rules. These rules are based on which operators are used to combine subexpressions. The following table lists groups of operators in order from highest to lowest precedence:

+| Group | Operators |

+An operator that's higher in the preceding table will "bind more tightly" to its operands than other operators do. For example, `and` has higher precedence than `or`, and comparison operators have higher precedence than either of them. So, the following two expressions are equivalent:

+The `not` operator has the highest precedence of all. It's even higher than the comparison operators. If you write a filter like this:

+This error happens because the operator is associated with just the `length(userId)` expression, and not with the entire comparison expression. The `length(userId)` expression is of type `null` when `userId` is `null`. The fix is to put the operand of `not` in parentheses:

+There are limits to the size and complexity of filter expressions that you can send to the Azure Web PubSub service. The limits are based roughly on the number of clauses in your filter expression. A good guideline is that if you have more than 100 clauses, you're at risk of exceeding the limit. To avoid exceeding the limit, design your application so that it doesn't generate filters of unbounded size.

+Send to multiple groups:

+```odata-filter-expr

+filter='group1' in groups or 'group2' in groups or 'group3' in groups

+```

+Send to multiple users in a specific group:

+```odata-filter-expr

+filter=userId in ('user1', 'user2', 'user3') and 'group1' in groups

+```

+Send to a user but not a specific connection ID:

+```odata-filter-expr

+filter=userId eq 'user1' and connectionId ne '123'

+```

+Send to a user who's not in a specific group:

+```odata-filter-expr

+filter=userId eq 'user1' and (not ('group1' in groups))

+```

+Escape `'` when the user ID contains `'`:

+```odata-filter-expr

+filter=userId eq 'user''1'

+```

+## Formal grammar

+The following [Extended Backus-Naur Form](https://en.wikipedia.org/wiki/Extended_BackusΓÇôNaur_form) grammar can describe the subset of the OData language that the Azure Web PubSub service supports. This grammar lists rules "top down," by starting with the most complex expressions and then breaking them down into more primitive expressions. The top is the grammar rule for `$filter` that corresponds to the specific `filter` parameter of the Azure Web PubSub service's `Send*` REST APIs.

+This article describes how to back up virtual machines on Azure Stack HCI using Microsoft Azure Backup Server (MABS).

+3. On the MABS Administrator console, select **Protection** > **Create protection group** to open the **Create New Protection Group** wizard.

+6. On **Specify Short-Term Goals** > **Retention range**, specify how long you want to retain disk data. In **Synchronization frequency**, specify how often incremental backups of the data should run. Alternatively, instead of selecting an interval for incremental backups you can enable **Just before a recovery point**. With this setting enabled, MABS will run an express full backup just before each scheduled recovery point.

+ * `score`: A float value indicating the confidence in the result. The score is between zero (0) and one (1.0). A low score (<= 0.4) indicates a low confidence.

+\* Please refer to [Inbound calling capabilities page](../telephony/inbound-calling-capabilities.md) for details.

+\* Please refer to [Inbound calling capabilities page](../telephony/inbound-calling-capabilities.md) for details.

+\* Please refer to [Inbound calling capabilities page](../telephony/inbound-calling-capabilities.md) for details.

+\* Please refer to [Inbound calling capabilities page](../telephony/inbound-calling-capabilities.md) for details.

+\* Please refer to [Inbound calling capabilities page](../telephony/inbound-calling-capabilities.md) for details.

+\* Please refer to [Inbound calling capabilities page](../telephony/inbound-calling-capabilities.md) for details.

+\* Please refer to [Inbound calling capabilities page](../telephony/inbound-calling-capabilities.md) for details.

+Then, we get and save the Confidential Ledger service certificate using the Certificate client from the Confidential Ledger Identity URL. The service certificate is a network identity public key certificate used as root of trust for [TLS](https://microsoft.github.io/CCF/main/overview/glossary.html#term-TLS) server authentication. In other words, it's used as the Certificate Authority (CA) for establishing a TLS connection with any of the nodes in the CCF network.

+Console logs originate from the `stderr` and `stdout` messages from the containers in your container app and Dapr sidecars. You can view console logs by querying the `ContainerAppConsoleLogs_CL` table.

+You can query the logs using the tables listed in the **CustomLogs** category **Tables** tab. The tables in this category are the `ContainerAppSystemlogs_CL` and `ContainerAppConsoleLogs_CL` tables.

+1. Navigate to your Azure Cosmos DB account and open the **Azure Synapse Link** under Intergrations in the left pane.

+1. Select **Enable**. This process can take 1 to 5 minutes to complete.

+ :::image type="content" source="./media/configure-synapse-link/enable-synapse-link.png" alt-text="Screenshot showing how to enable Synapse Link feature.":::

+#### New container

+#### Existing container

+1. Sign in to the [Azure portal](https://portal.azure.com/) or the [Azure Cosmos DB Explorer](https://cosmos.azure.com/).

+1. Navigate to your Azure Cosmos DB account and open the **Azure Synapse Link** tab.

+1. Under the **Enable Azure Synapse Link for your containers** section select the container.

+ :::image type="content" source="./media/configure-synapse-link/enable-synapse-link-existing-container.png" alt-text="Screenshot showing how to turn on analytical store for an Azure Cosmos DB existing container.":::

+1. After the container enablement, verify that analytical store has been enabled by clicking **Settings**, right below Documents in Data Explorer, and check if the **Analytical Store Time to Live** option is turned on.

+Budget integration with action groups works for action groups that have enabled or disabled common alert schema. For more information on how to enable common alert schema, see [How do I enable the common alert schema?](../../azure-monitor/alerts/alerts-common-schema.md#enable-the-common-alert-schema)

+ Title: Choose the right integration-runtime configuration for your scenario

+description: Some recommended architectures for each integration runtime.

+# Choose the right integration-runtime configuration for your scenario

+The integration runtime is a very important part of the infrastructure for the data integration solution provided by Azure Data Factory. This requires you to fully consider how to adapt to the existing network structure and data source at the beginning of designing the solution, as well as consider performance, security and cost.

+## Comparison of different types of integration runtimes

+In Azure Data Factory, we have three kinds of integration runtimes: the Azure integration runtime, the self-hosted integration runtime and the Azure-SSIS integration runtime. For the Azure integration runtime, you can also enable a managed virtual network which makes its architecture different than the global Azure integration runtime.

+This table lists the differences in some aspects of all integration runtimes, you can choose the appropriate one according to your actual needs. For the Azure-SSIS integration runtime, you can learn more in the article [Create an Azure-SSIS integration runtime](create-azure-ssis-integration-runtime.md).

+| Feature | Azure integration runtime | Azure integration runtime with managed virtual network | Self-hosted integration runtime |

+| - | - | | - |

+| Managed compute | Y | Y | N |

+| Auto-scale | Y | Y* | N |

+| Dataflow | Y | Y | N |

+| On-premises data access | N | Y** | Y |

+| Private Link/Private Endpoint | N | Y*** | Y |

+| Custom component/driver | N | N | Y |

+ \* When time-to-live (TTL) is enabled, the compute size of integration runtime is reserved according to the configuration and canΓÇÖt be auto-scaled.

+ ** On-premises environments must be connected to Azure via Express Route or VPN. Custom components and drivers are not supported.

+ *** The private endpoints are managed by the Azure Data Factory service.

+It is very important to choose an appropriate type of integration runtime. Not only must it be suitable for your existing architecture and requirements for data integration, but you also need to consider how to further meet growing business needs and any future increase in workload. But there is no one-size-fits-all approach. The following consideration can help you navigate the decision:

+1. What are the integration runtime and data store locations?<br>

+ The integration runtime location defines the location of its back-end compute, and where the data movement, activity dispatching and data transformation are performed. To obtain better performance and transmission efficiency, the integration runtime should be closer to the data source or sink.

+ - The Azure integration runtime automatically detects the most suitable location based on some rules (also known as auto-resolve). See details here: [Azure IR location](concepts-integration-runtime.md#azure-ir-location).

+ - The Azure integration runtime with a managed virtual network has the same region as your data factory. It canΓÇÖt be auto resolved like the Azure integration runtime.

+ - The self-hosted integration runtime is located in the region of your local machines or Azure virtual machines.

+2. Is the data store publicly accessible?<br>

+ If the data store is publicly accessible, the difference between the different types of integration runtimes is not very large. If the store is behind a firewall or in a private network such as an on-premises or virtual network, the better choices are the Azure integration runtime with a managed virtual network or the self-hosted integration runtime.

+ - There is some additional setup needed such as Private Link Service and Load Balancer when using the Azure integration runtime with a managed virtual network to access a data store behind a firewall or in a private network. You can refer to this tutorial [Access on-premises SQL Server from Data Factory Managed VNet using Private Endpoint](tutorial-managed-virtual-network-on-premise-sql-server.md) as an example. If the data store is in an on-premises environment, then the on-premises must be connected to Azure via Express Route or an S2S VPN.

+ - The self-hosted integration runtime is more flexible and does not require additional settings, Express Route, or VPN. But you need to provide and maintain the machine by yourself.

+ - You can also add the public IP addresses of the Azure integration runtime to the allowlist of your firewall and allow it to access the data store, but itΓÇÖs not a desirable solution in highly secure production environments.

+3. What level of security do you require during data transmission?<br>

+ If you need to process highly confidential data, you want to defend against, for example, man-in-the-middle attacks during data transmission. Then you can choose to use a Private Endpoint and Private Link to ensure data security.

+ - You can create managed private endpoints to your data stores when using the Azure integration runtime with a managed virtual network. The private endpoints are maintained by the Azure Data Factory service within the managed virtual network.

+ - You can also create private endpoints in your virtual network and the self-hosted integration runtime can leverage them to access data stores.

+ - The Azure integration runtime doesnΓÇÖt support Private Endpoint and Private Link.

+4. What level of maintenance are you able to provide?<br>

+ Maintaining infrastructure, servers, and equipment is one of the important tasks of the IT department of an enterprise. It usually takes a lot of time and effort.

+ - You donΓÇÖt need to worry about the maintenance such as update, patch and version of the Azure integration runtime and the Azure integration runtime with a managed virtual network. The Azure Data Factory service will take care of all the maintenance efforts.

+ - Because the self-hosted integration runtime is installed on customer machines, the maintenance must be taken care of by end users. You can, however, enable auto-update to automatically get the latest version of the self-hosted integration runtime whenever there is an update. To learn about how to enable auto-update and manage version control of the self-hosted integration runtime, you can refer to the article [Self-hosted integration runtime auto-update and expire notification](self-hosted-integration-runtime-auto-update.md). We also provide a diagnostic tool for the self-hosted integration runtime to health-check some common issues. To learn more about the diagnostic tool, refer to the article [Self-hosted integration runtime diagnostic tool](self-hosted-integration-runtime-diagnostic-tool.md). In addition, we recommend using Azure Monitor and Azure Log Analytics specifically to collect that data and enable a single pane of glass monitoring for your self-hosted integration runtimes. Learn more about configuring this in the article [Configure the self-hosted integration runtime for log analytics collection](how-to-configure-shir-for-log-analytics-collection.md) for instructions.

+5. What concurrency requirements do you have?<br>

+ When processing large-scale data, such as large-scale data migration, we hope to improve the efficiency and speed of processing as much as possible. Concurrency is often a major requirement for data integration.

+ - The Azure integration runtime has the highest concurrency support among all integration runtime types. Data integration unit (DIU) is the unit of capability to run on Azure Data Factory. You can select the desired number of DIU for e.g. Copy activity. Within the scope of DIU, you can run multiple activities at the same time. For different region groups, we will have different upper limitations. Learn about the details of these limits in the article [Data Factory limits](../azure-resource-manager/management/azure-subscription-service-limits.md#data-factory-limits).

+ - The Azure integration runtime with a managed virtual network has a similar mechanism to the Azure integration runtime, but due to some architectural constraints, the concurrency it can support is less than Azure integration runtime.

+ - The concurrent activities that the self-hosted integration runtime can run depend on the machine size and cluster size. You can choose a larger machine or use more self-hosted integration nodes in the cluster if you need greater concurrency.

+6. Do you require any specific features?<br>

+ There are some functional differences between the types of integration runtimes.

+ - Dataflow is supported by the Azure integration runtime and the Azure integration runtime with a managed virtual network. However, you canΓÇÖt run Dataflow using self-hosted integration runtime.

+ - If you need to install custom components, such as ODBC drivers, a JVM, or a SQL Server certificate, the self-hosted integration runtime is your only option. Custom components are not supported by the Azure integration runtime or the Azure integration runtime with a managed virtual network.

+## Architecture for integration runtime

+Based on the characteristics of each integration runtime, different architectures are generally required to meet the business needs of data integration. The following are some typical architectures that can be used as a reference.

+### Azure integration runtime

+The Azure integration runtime is a fully managed, auto-scaled compute that you can use to move data from Azure or non-Azure data sources.

+1. The traffic from the Azure integration runtime to data stores is through public network.

+1. We provide a range of static public IP addresses for the Azure integration runtime and these IP addresses can be added to the allowlist of the target data store firewall. To learn more about how to get public IP addresses of the Azure Integration runtime, refer to the article [Azure Integration Runtime IP addresses](azure-integration-runtime-ip-addresses.md).

+1. The Azure integration runtime can be auto-resolved according to the region of the data source and data sink. Or you can choose a specific region. We recommend you choose the region closest to your data source or sink, which can provide better execution performance. Learn more about performance considerations in the article [Troubleshoot copy activity on Azure IR](copy-activity-performance-troubleshooting.md#troubleshoot-copy-activity-on-azure-ir).

+### Azure integration runtime with managed virtual network

+When using the Azure integration runtime with a managed virtual network, you should use managed private endpoints to connect your data sources to ensure data security during transmission. With some additional settings such as Private Link Service and Load Balancer, managed private endpoints can also be used to access on-premises data sources.

+1. A managed private endpoint canΓÇÖt be reused across different environments. You need to create a set of managed private endpoints for each environment. For all data sources supported by managed private endpoints, refer to the article [Supported data sources and services](managed-virtual-network-private-endpoint.md#supported-data-sources-and-services).

+1. You can also use managed private endpoints for connections to external compute resources that you want to orchestrate such as Azure Databricks and Azure Functions. To see the full list of supported external compute resources, refer to the article [Supported data sources and services](managed-virtual-network-private-endpoint.md#supported-data-sources-and-services).

+1. Managed virtual network is managed by the Azure Data Factory service. VNET peering is not supported between a managed virtual network and a customer virtual network.

+1. Customers canΓÇÖt directly change configurations such as the NSG rule on a managed virtual network.

+1. If any property of a managed private endpoint is different between environments, you can override it by parameterizing that property and providing the respective value during deployment. See details in the article [Best practices for CI/CD](continuous-integration-delivery.md#best-practices-for-cicd).

+### Self-hosted integration runtime

+To prevent data from different environments from interfering with each other and ensure the security of the production environment, we need to create a corresponding self-hosted integration runtime for each environment. This ensures sufficient isolation between different environments.

+Since the self-hosted integration runtime runs on a customer managed machine, in order to reduce the cost, maintenance, and upgrade efforts as much as possible, we can make use of the shared functions of the self-hosted integration runtime for different projects in the same environment. For details on self-hosted integration runtime sharing, refer to the article [Create a shared self-hosted integration runtime in Azure Data Factory](create-shared-self-hosted-integration-runtime-powershell.md). At the same time, to make the data more secure during transmission, we can choose to use a private link to connect the data sources and key vault, and connect the communication between the self-hosted integration runtime and the Azure Data Factory service.

+1. Express Route is not mandatory. Without Express Route, the data will not reach the sink through private networks such as a virtual network or a private link, but through the public network.

+1. If the on-premises network is connected to the Azure virtual network via Express Route or VPN, then the self-hosted integration runtime can be installed on virtual machines in a Hub VNET.

+1. The hub-spoke virtual network architecture can be used not only for different projects but also for different environments (Prod, QA and Dev).

+1. The self-hosted integration runtime can be shared with multiple data factories. The primary data factory references it as a shared self-hosted integration runtime and others refer to it as a linked self-hosted integration runtime. A physical self-hosted integration runtime can have multiple nodes in a cluster. Communication only happens between the primary self-hosted integration runtime and primary node, with work being distributed to secondary nodes from the primary node.

+1. Credentials of on-premises data stores can be stored either in the local machine or an Azure Key Vault. Azure Key Vault is highly recommended.

+1. Communication between the self-hosted integration runtime and data factory can go through a private link. But currently, interactive authoring via Azure Relay and automatically updating to the latest version from the download center donΓÇÖt support private link. The traffic goes through the firewall of on-premises environment. For more details, refer to the article [Azure Private Link for Azure Data Factory](data-factory-private-link.md).

+1. The private link is only required for the primary data factory. All traffic goes through primary data factory, then to other data factories.

+1. The same name of the self-hosted integration runtime across all stages of CI/CD is expected. You can consider using a ternary factory just to contain the shared self-hosted integration runtimes and use linked self-hosted integration runtime in the various production stages. For more details, refer to the article [Continuous integration and delivery](continuous-integration-delivery.md).

+1. You can control how the traffic goes to the download center and Azure Relay using configurations of your on-premises network and Express Route, either through an on-premises proxy or hub virtual network. Make sure the traffic is allowed by proxy or NSG rules.

+1. If you want to secure communication between self-hosted integration runtime nodes, you can enable remote access from the intranet with a TLS/SSL certificate. For more details, refer to the article [Enable remote access from intranet with TLS/SSL certificate (Advanced)](tutorial-enable-remote-access-intranet-tls-ssl-certificate.md).

+1. Go to template **Copy new files only by LastModifiedDate**. Create a **New** connection to to your destination store. The destination store is where you want to copy files to.

+2. Create a **New** connection to your source storage store. The source storage store is where you want to copy files from.

+ Title: Using the asset inventory to view your security posture with Microsoft Defender for Cloud

+The asset inventory page of Microsoft Defender for Cloud shows the [security posture](concept-cloud-security-posture-management.md) of the resources you've connected to Defender for Cloud. Defender for Cloud periodically analyzes the security state of resources connected to your subscriptions to identify potential security issues and provides you with active recommendations. Active recommendations are recommendations that can be resolved to improve your security posture.

+- Which of my subscriptions with [Defender plans](defender-for-cloud-introduction.md#cwpidentify-unique-workload-security-requirements) enabled have outstanding recommendations?

+The security recommendations on the asset inventory page are also shown in the **Recommendations** page, but here they're shown according to the affected resource. Learn more about [implementing security recommendations](review-security-recommendations.md).

+|Clouds:|:::image type="icon" source="./media/icons/yes-icon.png"::: Commercial clouds<br>:::image type="icon" source="./media/icons/yes-icon.png"::: National (Azure Government, Azure China 21Vianet) <br> <br> Software inventory isn't currently supported in national clouds.|

+- **Unhealthy resources**: Resources with active security recommendations that you can implement. [Learn more about implementing security recommendations](review-security-recommendations.md).

+- **Unregistered subscriptions**: Any subscription in the selected scope that hasn't yet been connected to Microsoft Defender for Cloud.

+The multiple filters at the top of the page provide a way to quickly refine the list of resources according to the question you're trying to answer. For example, if you wanted to know which of your machines with the tag 'Production' are missing the Log Analytics agent, you can filter the list for **Agent monitoring**:"Not installed" and **Tags**:"Production".

+Asset inventory utilizes [Azure Resource Graph (ARG)](../governance/resource-graph/index.yml), an Azure service that lets you query Defender for Cloud's security posture data across multiple subscriptions.

+You can use [Kusto Query Language (KQL)](/azure/data-explorer/kusto/query/) in the asset inventory to quickly produce deep insights by cross-referencing Defender for Cloud data with other resource properties.

+1. Use the **Filter by name** box to display a specific resource, or use the filters to focus on specific resources.

+ - **Off** - Resources not protected by a Microsoft Defender plan. You can right-click on the resources and upgrade them:

+ - **On** - Resources protected by a Microsoft Defender plan

+ - **Partial** - **Subscriptions** with some but not all of the Microsoft Defender plans disabled. For example, the following subscription has seven Microsoft Defender plans disabled.

+> The "Blank" option shows machines without Microsoft Defender for Endpoint or without Microsoft Defender for Servers.

+Besides the filters in the asset inventory page, you can explore the software inventory data from Azure Resource Graph Explorer.

+### Why aren't all of my resources shown, such as subscriptions, machines, storage accounts?

+The inventory view lists your Defender for Cloud connected resources from a Cloud Security Posture Management (CSPM) perspective. The filters show only the resources with active recommendations.

+For example, if you have access to eight subscriptions but only seven currently have recommendations, filter by **Resource type = Subscriptions** shows only the seven subscriptions with active recommendations:

+Not all Defender for Cloud monitored resources require agents. For example, Defender for Cloud doesn't require agents to monitor Azure Storage accounts or PaaS resources, such as disks, Logic Apps, Data Lake Analysis, and Event Hubs.

+|Required roles and permissions:|<ul><li>**Security admin** or **Owner** on the resource group</li><li>Write permissions for the target resource.</li><li>If you're using the [Azure Policy 'DeployIfNotExist' policies](#configure-continuous-export-at-scale-using-the-supplied-policies), you'll also need permissions for assigning policies</li><li>To export data to Event Hubs, you'll need Write permission on the Event Hubs Policy.</li><li>To export to a Log Analytics workspace:<ul><li>if it **has the SecurityCenterFree solution**, you'll need a minimum of read permissions for the workspace solution: `Microsoft.OperationsManagement/solutions/read`</li><li>if it **doesn't have the SecurityCenterFree solution**, you'll need write permissions for the workspace solution: `Microsoft.OperationsManagement/solutions/action`</li><li>Learn more about [Azure Monitor and Log Analytics workspace solutions](../azure-monitor/insights/solutions.md)</li></ul></li></ul>|

+You can configure continuous export from the Microsoft Defender for Cloud pages in Azure portal, via the REST API, or at scale using the supplied Azure Policy templates.

+If you're setting up a continuous export to Log Analytics or Azure Event Hubs:

+1. From the "Export target" area, choose where you'd like the data saved. Data can be saved in a target of a different subscription (for example, on a Central Event Hubs instance or a central Log Analytics workspace).

+ You can also send the data to an [Event hubs or Log Analytics workspace in a different tenant](#export-data-to-an-azure-event-hub-or-log-analytics-workspace-in-another-tenant).

+- Azure Event Hubs

+You can also send the data to an [Event Hubs or Log Analytics workspace in a different tenant](#export-data-to-an-azure-event-hub-or-log-analytics-workspace-in-another-tenant).

+To deploy your continuous export configurations across your organization, use the supplied Azure Policy 'DeployIfNotExist' policies to create and configure continuous export procedures.

+1. Select the policy you want to apply from this table:

+### What is the minimum SAS policy permissions required when exporting data to Azure Event Hubs?

+- **Recently pulled** - Since new vulnerabilities are discovered every day, **Microsoft Defender for Containers** also scans, on a weekly basis, any image that has been pulled within the last 30 days. There's no extra charge for these rescans because you're billed once per image.

+1. Select a specific registry to see the repositories in it that have vulnerable repositories.

+1. Select a specific repository to see the repositories in it that have vulnerable images.

+Docker Registry, Microsoft Artifact Registry/Microsoft Container Registry, and Microsoft Azure Red Hat OpenShift (ARO) built-in container image registry aren't supported.

+|<a name="protocol-name"></a>**name** |String. Defines the device name. |Not nullable | For more information, see below. <br><br>**Note**: To extend Defender for IoT support to proprietary protocols, create a Horizon plugin. For more information, see [Extend support to proprietary protocols](../overview.md#extend-support-to-proprietary-ot-protocols).|

+ Title: Dell PowerEdge R350 for OT monitoring - Microsoft Defender for IoT

+description: Learn about the Dell PowerEdge R350 appliance's configuration when used for OT monitoring with Microsoft Defender for IoT in enterprise deployments.

+# Dell PowerEdge R350

+This article describes the Dell PowerEdge R350 appliance, supported for OT sensors in an enterprise deployment.

+The Dell PowerEdge R350 is also available for the on-premises management console.

+|Appliance characteristic | Description|

+|||

+|**Hardware profile** | E1800|

+|**Performance** | Max bandwidth: 1 Gbps<br>Max devices: 10,000<br>Up to 8x RJ45 monitoring ports or 6x SFP (OPT) |

+|**Physical Specifications** | Mounting: 1U<br>Dimensions (H x W x D) 1.70 in x 17.09 in x 22.18 in<br>Dimensions (H x W x D) 4.28 cm x 43.4 cm x 56.3 cm|

+|**Status** | Supported, available as a pre-configured appliance|

+The following image shows a view of the Dell PowerEdge R350 front panel:

+The following image shows a view of the Dell PowerEdge R350 back panel:

+## Specifications

+|Component| Technical specifications|

+|:-|:-|

+|Chassis| 1U rack server|

+|Dimensions| (H x W x D) 1.70 in x 17.09 in x 22.18 in, 4.28 cm x 43.4 cm x 56.3 cm|

+|Weight| Max 28.96 lb/13.14 Kg|

+|Processor| Intel Xeon E-2334 3.4 GHz <br>8M Cache<br> 4C/8T, Turbo (65W), 3200 MT/s, XE Only|

+|Memory|32 GB = 2x 16 GB 3200MT/s DDR4 ECC UDIMM|

+|Storage| 4x 1 TB Hard Drive SATA 6 Gbps 7.2K 512n 3.5in Hot-Plug with PERC H755 Controller Card - RAID 10|

+|Network controller|On-board: Broadcom 5720 Dual Port 1 Gb On-Board LOM <br>On-board LOM: iDRAC9, Enterprise 15G<br>External: Broadcom 5719 Quad Port 1 GbE BASE-T Adapter, PCIe Low Profile|

+|Management|iDRAC9 Enterprise|

+|Device access| Two rear USB 3.0|

+|One front| USB 3.0|

+|Power| Dual, Hot-Plug, Redundant Power Supply (1+1), 600W|

+|Rack support| ReadyRails Sliding Rails With Cable Management Arm|

+## Dell PowerEdge R350 - Bill of Materials

+|Quantity|PN|Description|

+|-||-|

+|1| 210-BBTW | OEM R350XE Server |

+|1| 990-10090 | EX-Works |

+|1| 412-AAPW | Heatsink for 80W or less CPU |

+|1| 370-AAIP | Performance Optimized |

+|1| 370-AGNY | 3200MT/s UDIMM |

+|2| 370-AGQU | 16 GB UDIMM, 3200MT/s, ECC |

+|1| 384-BBBH | Power Saving BIOS Settings |

+|1| 800-BBDM | UEFI BIOS Boot Mode with GPT Partition |

+|2| 450-AKMP | Dual, Hot-Plug, Redundant Power Supply (1+1), 600W |

+|1| 450-AADY | C13 to C14, PDU Style, 10 AMP, 6.5 Feet (2m), Power Cord |

+|1| 330-BBWS | Riser Config 0, 1 x8, 1 x16 slots |

+|1| 384-BCYX | OEM R350 Motherboard with Broadcom 5720 Dual Port 1 Gb On-Board LOM |

+|1| 385-BBQV | iDRAC9, Enterprise 15G |

+|1| 542-BBBP | On-Board LOM |

+|1| 470-AFBU | BOSS Blank |

+|1| 379-BCRF | iDRAC, Legacy Password |

+|1| 379-BCQV | iDRAC Group Manager, Enabled |

+|1| 611-BBBF | No Operating System |

+|1| 605-BBFN | No Media Required |

+|1| 770-BDEL | ReadyRails Sliding Rails With Cable Management Arm |

+|1| 709-BBIJ | Parts Only Warranty 15 Months |

+|1| 865-BBPG | ProSupport and Next Business Day Onsite Service Initial, 15 Month(s) |

+|1| 338-CCOZ | Intel Xeon E-2334 3.4 GHz, 8M Cache, 4C/8T, Turbo (65W), 3200 MT/s, XE Only |

+|1| 325-BEIF | Brand/Bezel, Dell Branded, PowerEdge R350XE |

+|1| 389-ECFF | PowerEdge R350 CE and CCC Marking |

+|1| 321-BGVQ | 3.5" Chassis with up to 4 Hot Plug Hard Drives |

+|1| 750-ADOY | Standard Fan |

+|1| 429-ABHN | DVD +/-RW, SATA, Internal for Hot Plug Chassis |

+|1| 405-ABBT | PERC H755 Controller Card |

+|1| 461-AADZ | No Trusted Platform Module |

+|1| 683-11870 | No Installation Service Selected (Contact Sales Rep for more details) |

+|1| 865-BBPF | ProSupport and Next Business Day Onsite Service Extension, 24 Month(s) |

+|4| 400-BLLH | 1 TB Hard Drive SATA 6 Gbps 7.2K 512n 3.5in Hot-Plug |

+|1| 540-BBDF | Broadcom 5719 Quad Port 1 GbE BASE-T Adapter, PCIe Low Profile |

+|1| 780-BCDQ | RAID 10 |

+## Optional Expansion Modules

+Optional modules for additional monitoring ports can be installed:

+|Location |Type |Specifications |

+|-||-|

+| PCIe Expansion <br>Slot 1 or 2 | Quad Port Ethernet | 540-BBDV<br>Intel QP i350 4 x 1Gbe Copper, PCIe Low Profile |

+| PCIe Expansion <br>Slot 1 or 2 | Quad Port Ethernet | 540-BBDF<br>Broadcom 5719 Quad Port 1GbE BASE-T Adapter, PCIe Low Profile |

+| PCIe Expansion <br>Slot 1 or 2 | Dual Port Ethernet | 540-BCSE<br>Intel X710-T2L DP 2 x 10Gbe Copper, PCIe Low Profile |

+| PCIe Expansion <br>Slot 1 or 2 | Dual Port SFP+ | 540-BBML<br>Intel X710 DP 2 x 10Gbe SFP+, PCIe Low Profile |

+| PCIe Expansion <br>Slot 1 or 2 | Dual Port SFP+ | 540-BBVI<br>Broadcom 57412 Dual Port 10GbE SFP+ Adapter, PCIe Low Profile |

+| PCIe Expansion <br>Slot 1 or 2 | SFP+ Transceiver | 407-BCBN or 407-BBOU - SFP+ 10G SR |

+| PCIe Expansion <br>Slot 1 or 2 | SFP+ Transceiver | 407-BBOP - SFP+ 10G LR |

+| PCIe Expansion <br>Slot 1 or 2 | SFP+ Transceiver | 407-BBOS - SFP+ 1G COPPER |

+| PCIe Expansion <br>Slot 1 or 2 | INTEL X710 SFP+ Transceiver | 407-BBVJ - SFP+ 1G/10G SR (INTEL ONLY) |

+## Dell PowerEdge R350 installation

+This section describes how to install Defender for IoT software on the Dell PowerEdge R350 appliance.

+Before installing the software on the Dell appliance, you need to adjust the appliance's BIOS configuration.

+> [!NOTE]

+> Installation procedures are only relevant if you need to re-install software on a pre-configured device, or if you buy your own hardware and configure the appliance yourself.

+>

+### Prerequisites

+To install the Dell PowerEdge R350 appliance, you'll need:

+- An Enterprise license for Dell Remote Access Controller (iDrac)

+- A BIOS configuration XML

+### Configure the Dell BIOS

+ An integrated iDRAC manages the Dell appliance with Lifecycle Controller (LC). The LC is embedded in every Dell PowerEdge server and provides functionality that helps you deploy, update, monitor, and maintain your Dell PowerEdge appliances.

+To establish the communication between the Dell appliance and the management computer, you need to define the iDRAC IP address and the management computer's IP address on the same subnet.

+When the connection is established, the BIOS is configurable.

+**To configure the iDRAC IP address**:

+1. Power up the sensor.

+1. If the OS is already installed, select the F2 key to enter the BIOS configuration.

+1. Select **iDRAC Settings**.

+1. Select **Network**.

+ > [!NOTE]

+ > During the installation, you must configure the default iDRAC IP address and password mentioned in the following steps. After the installation, you change these definitions.

+1. Change the static IPv4 address to **10.100.100.250**.

+1. Change the static subnet mask to **255.255.255.0**.

+ :::image type="content" source="../media/tutorial-install-components/idrac-network-settings-screen-v2.png" alt-text="Screenshot that shows the static subnet mask in iDRAC settings.":::

+1. Select **Back** > **Finish**.

+**To configure the Dell BIOS**:

+This procedure describes how to update the Dell PowerEdge R350 configuration for your OT deployment.

+Configure the appliance BIOS only if you didn't purchase your appliance from Arrow, or if you have an appliance, but don't have access to the XML configuration file.

+1. Access the appliance's BIOS directly by using a keyboard and screen, or use iDRAC.

+ - If the appliance isn't a Defender for IoT appliance, open a browser and go to the IP address configured beforehand. Sign in with the Dell default administrator privileges. Use **root** for the username and **calvin** for the password.

+ - If the appliance is a Defender for IoT appliance, sign in by using **XXX** for the username and **XXX** for the password.

+1. After you access the BIOS, go to **Device Settings**.

+1. Choose the RAID-controlled configuration by selecting **Integrated RAID controller 1: Dell PERC\<PERC H755 Adapter\> Configuration Utility**.

+1. Select **Configuration Management**.

+1. Select **Create Virtual Disk**.

+1. In the **Select RAID Level** field, select **RAID10**. In the **Virtual Disk Name** field, enter **ROOT** and select **Physical Disks**.

+1. Select **Check All** and then select **Apply Changes**

+1. Select **Ok**.

+1. Scroll down and select **Create Virtual Disk**.

+1. Select the **Confirm** check box and select **Yes**.

+1. Select **OK**.

+1. Return to the main screen and select **System BIOS**.

+1. Select **Boot Settings**.

+1. For the **Boot Mode** option, select **BIOS**.

+1. Select **Back**, and then select **Finish** to exit the BIOS settings.

+### Install Defender for IoT software on the Dell PowerEdge R350

+This procedure describes how to install Defender for IoT software on the Dell PowerEdge R350.

+The installation process takes about 20 minutes. After the installation, the system restarts several times.

+**To install the software**:

+1. Verify that the version media is mounted to the appliance in one of the following ways:

+ - Connect an external CD or disk-on-key that contains the sensor software you downloaded from the Azure portal.

+ - Mount the ISO image by using iDRAC. After signing in to iDRAC, select the virtual console, and then select **Virtual Media**.

+1. In the **Map CD/DVD** section, select **Choose File**.

+1. Choose the version ISO image file for this version from the dialog box that opens.

+1. Select the **Map Device** button.

+ :::image type="content" source="../media/tutorial-install-components/mapped-device-on-virtual-media-screen-v2.png" alt-text="Screenshot that shows a mapped device.":::

+1. The media is mounted. Select **Close**.

+1. Start the appliance. When you're using iDRAC, you can restart the servers by selecting the **Console Control** button. Then, on the **Keyboard Macros**, select the **Apply** button, which will start the Ctrl+Alt+Delete sequence.

+1. Continue by installing OT sensor or on-premises management software. For more information, see [Defender for IoT software installation](../how-to-install-software.md).

+## Next steps

+Continue understanding system requirements for physical or virtual appliances. For more information, see [Which appliances do I need?](../ot-appliance-sizing.md).

+Then, use any of the following procedures to continue:

+- [Purchase sensors or download software for sensors](../onboard-sensors.md#purchase-sensors-or-download-software-for-sensors)

+- [Download software for an on-premises management console](../how-to-manage-the-on-premises-management-console.md#download-software-for-the-on-premises-management-console)

+- [Install software](../how-to-install-software.md)

+- The on-premises management console software [downloaded from Defender for IoT in the Azure portal](../ot-deploy/install-software-on-premises-management-console.md#download-software-files-from-the-azure-portal).

+1. Continue with the [generic procedure for installing on-premises management console software](../ot-deploy/install-software-on-premises-management-console.md).

+- [Install Microsoft Defender for IoT on-premises management console software](../ot-deploy/install-software-on-premises-management-console.md)

+- The on-premises management console software [downloaded from Defender for IoT in the Azure portal](../ot-deploy/install-software-on-premises-management-console.md#download-software-files-from-the-azure-portal).

+1. Continue with the [generic procedure for installing on-premises management console software](../ot-deploy/install-software-on-premises-management-console.md).

+- [Install Microsoft Defender for IoT on-premises management console software](../ot-deploy/install-software-on-premises-management-console.md)

+- The OT sensor software [downloaded from Defender for IoT in the Azure portal](../ot-deploy/install-software-ot-sensor.md#download-software-files-from-the-azure-portal).

+1. Specify the memory allocation [according to your organization's needs](../ot-appliance-sizing.md), in standard RAM denomination (eg. 8192, 16384, 32768). Do not enable **Dynamic Memory**.

+1. Continue with the [generic procedure for installing sensor software](../how-to-install-software.md).

+- [Install OT monitoring software on OT sensors](../ot-deploy/install-software-ot-sensor.md)

+- The OT sensor software [downloaded from Defender for IoT in the Azure portal](../ot-deploy/install-software-ot-sensor.md#download-software-files-from-the-azure-portal).

+1. Continue with the [generic procedure for installing sensor software](../ot-deploy/install-software-ot-sensor.md).

+- **Improved security**, without additional security configurations. [Connect to Azure using specific and secure endpoints](how-to-set-up-your-network.md#sensor-access-to-azure-portal), without the need for any wildcards.

+The following image shows how data can stream into Defender for IoT from network sensors and third-party sources to provide a unified view of IoT/OT security. Defender for IoT in the Azure portal provides asset inventories, vulnerability assessments, and continuous threat monitoring.

+Defender for IoT includes the following OT security monitoring components:

+- **OT network sensors**, to detect OT devices across your network. OT network sensors are deployed on either a virtual machine or a physical appliance, and configured as cloud-connected sensors, or fully on-premises, locally managed sensors.

+- **An on-premises management console** for centralized OT site management in local, air-gapped environments.

+## What is a Defender for IoT committed device?

+- Network sensors are purpose-built for OT networks and connect to a SPAN port or network TAP. OT network sensors can provide visibility into risks within minutes of connecting to the network.

+Data collection, processing, analysis, and alerting takes place directly on the sensor, which can be ideal for locations with low bandwidth or high-latency connectivity. Only the metadata is transferred on for management, either to the Azure portal or an on-premises management console.

+For more information, see [Onboard OT sensors to Defender for IoT](onboard-sensors.md).

+### Cloud-connected vs. local OT sensors

+When you have a cloud connected OT network sensor:

+- View any data for a specific sensor from the sensor console. For a unified view of all information detected by several sensors, use an on-premises management console.

+For more information, see [Manage OT sensors from the sensor console](how-to-manage-individual-sensors.md) and [Manage OT sensors from the management console](how-to-manage-sensors-from-the-on-premises-management-console.md).

+### Analytics engines on OT network sensors

+OT network sensors analyze ingested data using built-in analytics engines, and trigger alerts based on both real-time and pre-recorded traffic.

+For example, the **policy violation detection** engine models industry control system (ICS) networks and alerts users of any deviation from baseline behavior. Deviations might include unauthorized use of specific function codes, access to specific objects, or changes to device configuration.

+Since many detection algorithms were built for IT, rather than OT networks, the extra baseline for ICS networks helps to shorten the system's learning curve for new detections.

+OT network sensors include the following analytics engines:

+|Name |Description |

+|||

+|**Protocol violation detection engine** | Identifies the use of packet structures and field values that violate ICS protocol specifications. <br><br>For example, Modbus exceptions or the initiation of an obsolete function code alerts. |

+|**Industrial malware detection engine** | Identifies behaviors that indicate the presence of known malware, such as Conficker, Black Energy, Havex, WannaCry, NotPetya, and Triton. |

+|**Anomaly detection engine** | Detects unusual machine-to-machine (M2M) communications and behaviors. <br><br>This engine models ICS networks and therefore requires a shorter learning period than analytics developed for IT. Anomalies are detected faster, with minimal false positives. <br><br>For example, Excessive SMB sign-in attempts, and PLC Scan Detected alerts. |

+|**Operational incident detection** | Detects operational issues such as intermittent connectivity that can indicate early signs of equipment failure. <br><br> For example, the device might be disconnected (unresponsive), or the Siemens S7 stop PLC command was sent alerts. |

+- **The Azure portal**. Use the Azure portal as a single pane of glass to view all data ingested from your devices via cloud-connected network sensors. The Azure portal provides extra value, such as [workbooks](workbooks.md), [connections to Microsoft Sentinel](iot-solution.md), [security recommendations](recommendations.md), and more.

+ Also use the Azure portal to obtain new appliances and software updates, onboard and maintain your sensors in Defender for IoT, and update threat intelligence packages. For example:

+- **The OT sensor console**. View detections for devices connected to a specific OT sensor from the sensor's console. Use the sensor console to view a network map for devices detected by that sensor, a timeline of all events that occur on the sensor, forward sensor information to partner systems, and more. For example:

+- **The on-premises management console**. In air-gapped environments, you can get a central view of data from all of your sensors from an on-premises management console. The on-premises management console also lets you organize your network into separate sites and zones to support a [Zero Trust](/security/zero-trust/) mindset, and provides extra maintenance tools and reporting features.

+> [!div class="nextstepaction"]

+> [Understand OT sensor connection methods](architecture-connections.md)

+> [!div class="nextstepaction"]

+> [Connect OT sensors to Microsoft Defender for IoT](connect-sensors.md)

+> [!div class="nextstepaction"]

+> [Frequently asked questions](resources-frequently-asked-questions.md)

+After installing the software for your sensor or on-premises management console, you'll want to perform the [Post-installation validation](ot-deploy/post-install-validation-ot-software.md).

+ Title: Get started with OT network security monitoring - Microsoft Defender for IoT

+description: Use this quickstart to set up a trial OT plan with Microsoft Defender for IoT and understand the next steps required to configure your network sensors.

+# Quickstart: Get started with OT network security monitoring

+This quickstart describes how to set up a trial plan for OT security monitoring with Microsoft Defender for IoT.

+A trial plan for OT monitoring provides 30-day support for 1000 devices. Use this trial with a [virtual sensor](tutorial-onboarding.md) or on-premises sensors to monitor traffic, analyze data, generate alerts, understand network risks and vulnerabilities, and more.

+We recommend that you identify system requirements and plan your OT network monitoring architecture before you start, even if you're starting with a trial subscription.

+- Make sure that you have network switches that support [traffic monitoring](best-practices/traffic-mirroring-methods.md) via a SPAN port and TAPs (Test Access Points).

+- Research your own network architecture and decide which and how much data you'll want to monitor. Check any requirements for creating certificates and other details, and [understand where on your network](best-practices/understand-network-architecture.md) you'll want to place your OT network sensors.

+- If you want to use on-premises sensors, make sure that you have the [hardware appliances](ot-appliance-sizing.md) for those sensors and any administrative user permissions.

+For more information, see the [OT monitoring predeployment checklist](pre-deployment-checklist.md).

+## Add a trial Defender for IoT plan for OT networks

+This procedure describes how to add a trial Defender for IoT plan for OT networks to an Azure subscription.

+**To add your plan**:

+1. In the Azure portal, go to **Defender for IoT** and select **Plans and pricing** > **Add plan**.

+1. In the **Plan settings** pane, define the following settings:

+ - **Subscription**: Select the Azure subscription where you want to add a plan. You'll need a [Security admin](/azure/role-based-access-control/built-in-roles#security-admin), [Contributor](/azure/role-based-access-control/built-in-roles#contributor), or [Owner](/azure/role-based-access-control/built-in-roles#owner) role for the selected subscription.

+ > If your subscription isn't listed, check your account details and confirm your permissions with the subscription owner. Also make sure that you have the right subscriptions selected in your Azure settings > **Directories + subscriptions** page.

+ - **Price plan**: For the sake of this quickstart, select **Trial - 30 days - 1000 assets limit**.

+ :::image type="content" source="media/getting-started/ot-trial.png" alt-text="Screenshot of adding a plan for OT networks to your subscription.":::

+1. Select **Next** to review your selections on the **Review and purchase** tab.

+1. On the **Review and purchase** tab, select the **I accept the terms and conditions** option > **Purchase**.

+Your new plan is listed under the relevant subscription on the **Plans and pricing** > **Plans** page. For more information, see [Manage your subscriptions](how-to-manage-subscriptions.md).

+> [!div class="nextstepaction"]

+> [Onboard and activate a virtual OT sensor](tutorial-onboarding.md)

+> [!div class="nextstepaction"]

+> [Use a pre-configure physical appliance](ot-pre-configured-appliances.md)

+> [!div class="nextstepaction"]

+> [Understand Defender for IoT subscription billing](billing.md)

+> [!div class="nextstepaction"]

+> [Defender for IoT pricing](https://azure.microsoft.com/pricing/details/iot-defender/)

+- [Connect from the sensor console](#connect-sensors-to-the-on-premises-management-console-from-the-sensor-console)

+- [Connect sensors by using tunneling](#connect-sensors-by-using-tunneling)

+After connecting, you must [set up a site](#set-up-a-site) with these sensors.

+**To connect sensors to the on-premises management console from the sensor console**:

+1. In the on-premises management console, select **System Settings**.

+1. On the sensor, go to **System Settings** > **Connection to Management Console**.

+Enhance system security by preventing direct user access to the sensor. Instead of direct access, use proxy tunneling to let users access the sensor from the on-premises management console with a single firewall rule. This technique narrows the possibility of unauthorized access to the network environment beyond the sensor. The user's experience when signing in to the sensor remains the same.

+For example, the following image shows a sample architecture where users access the sensor consoles via the on-premises management console.

+**To set up tunneling at the on-premises management console**:

+1. Sign in to the on-premises management console's CLI with the *cyberx* or the *support* user credentials and run the following command:

+ sudo cyberx-management-tunnel-enable

+ For more information on users, see [Default privileged on-premises users](roles-on-premises.md#default-privileged-on-premises-users).

+

+ When tunneling access is configured, the following URL syntax is used to access the sensor consoles: `https://<on-premises management console address>/<sensor address>/<page URL>`

+**To use a new port**:

+Sign in to the on-premises management console and run the following command:

+```bash

+sudo cyberx-management-tunnel-enable --port 10000

+

+```

+**To disable the connection**:

+```bash

+cyberx-management-tunnel-disable

+```

+**To access the tunneling log files**:

+1. **From the on-premises management console**: Sign in and go to */var/log/apache2.log*.

+1. **From the sensor**: Sign in and go to */var/cyberx/logs/tunnel.log*.

+ Title: Manage OT sensors from the sensor console - Microsoft Defender for IoT

+description: Learn how to manage individual Microsoft Defender for IoT OT network sensors directly from the sensor's console.

+| **General Settings** | Displays a list of the sensor's basic configuration settings and [connectivity status](#validate-connectivity-status). |

+### Validate connectivity status

+Verify that your sensor is successfully connected to the Azure portal directly from the sensor's **Overview** page.

+If there are any connection issues, a disconnection message is shown in the **General Settings** area on the **Overview** page, and a **Service connection error** warning appears at the top of the page in the :::image type="icon" source="media/how-to-manage-individual-sensors/bell-icon.png" border="false"::: **System Messages** area. For example:

+1. Find more information about the issue by hovering over the :::image type="icon" source="media/how-to-manage-individual-sensors/information-icon.png" border="false"::: information icon. For example:

+ :::image type="content" source="media/how-to-manage-individual-sensors/connectivity-message.png" alt-text="Screenshot of a connectivity error message." lightbox="media/how-to-manage-individual-sensors/connectivity-message.png":::

+1. Take action by selecting the **Learn more** option under :::image type="icon" source="media/how-to-manage-individual-sensors/bell-icon.png" border="false"::: **System Messages**. For example:

+ :::image type="content" source="media/how-to-manage-individual-sensors/system-messages.png" alt-text="Screenshot of the system messages pane." lightbox="media/how-to-manage-individual-sensors/system-messages.png":::

+You can continue to work with Defender for IoT features even if the activation file has expired.

+ :::image type="content" source="media/how-to-manage-individual-sensors/connection-string-screen.png" alt-text="Screenshot of the Connection string screen.":::

+ Title: Manage OT sensors from the on-premises management console

+description: Learn how to manage OT sensors from the on-premises management console, including updating sensor versions, pushing system settings to sensors, managing certificates, and enabling and disabling engines on sensors.

+# Manage sensors from the on-premises management console

+| **IBM QRadar** | Send Defender for IoT alerts to IBM QRadar | - OT networks <br>- Cloud connected sensors | Microsoft | [Stream Defender for IoT cloud alerts to a partner SIEM](integrations/send-cloud-data-to-partners.md) |

+| **Splunk** | Send Defender for IoT alerts to Splunk | - OT networks <br>- Cloud connected sensors | Microsoft | [Stream Defender for IoT cloud alerts to a partner SIEM](integrations/send-cloud-data-to-partners.md) |

+> [!div class="nextstepaction"]

+> [Stream Defender for IoT cloud alerts to a partner SIEM](integrations/send-cloud-data-to-partners.md)

+ Title: Stream Microsoft Defender for IoT cloud alerts to a partner SIEM - Microsoft Defender for IoT

+description: Learn how to send Microsoft Defender for IoT data on the cloud to a partner SIEM via Microsoft Sentinel and Azure Event Hubs, using Splunk as an example.

+# Stream Defender for IoT cloud alerts to a partner SIEM

+As more businesses convert OT systems to digital IT infrastructures, security operations center (SOC) teams and chief information security officers (CISOs) are increasingly responsible for handling threats from OT networks.

+We recommend using Microsoft Defender for IoT's out-of-the-box [data connector](../iot-solution.md) and [solution](../iot-advanced-threat-monitoring.md) to integrate with Microsoft Sentinel and bridge the gap between the IT and OT security challenge.

+However, if you have other security information and event management (SIEM) systems, you can also use Microsoft Sentinel to forward Defender for IoT cloud alerts on to that partner SIEM, via [Microsoft Sentinel](/azure/sentinel/) and [Azure Event Hubs](/azure/event-hubs/).

+While this article uses Splunk as an example, you can use the process described below with any SIEM that supports Event Hub ingestion, such as IBM QRadar.

+> [!IMPORTANT]

+> Using Event Hubs and a Log Analytics export rule may incur additional charges. For more information, see [Event Hubs pricing](https://azure.microsoft.com/pricing/details/event-hubs/) and [Log Data Export pricing](https://azure.microsoft.com/pricing/details/monitor/).

+## Prerequisites

+Before you start, you'll need the **Microsoft Defender for IoT** data connector installed in your Microsoft Sentinel instance. For more information, see [Tutorial: Connect Microsoft Defender for IoT with Microsoft Sentinel](../iot-solution.md).

+Also check any prerequisites for each of the procedures linked in the steps below.

+## Register an application in Azure Active Directory

+You'll need Azure Active Directory (Azure AD) defined as a service principal for the [Splunk Add-on for Microsoft Cloud Services](https://splunkbase.splunk.com/app/3110/). To do this, you'll need to create an Azure AD application with specific permissions.

+**To register an Azure AD application and define permissions**:

+1. In [Azure AD](/azure/active-directory/), register a new application. On the **Certificates & secrets** page, add a new client secret for the service principal.

+ For more information, see [Register an application with the Microsoft identity platform](/azure/active-directory/develop/quickstart-register-app)

+1. In your app's **API permissions** page, grant API permissions to read data from your app.

+ 1. Select to add a permission and then select **Microsoft Graph** > **Application permissions** > **SecurityEvents.ReadWrite.All** > **Add permissions**.

+ 1. Make sure that admin consent is required for your permission.

+ For more information, see [Configure a client application to access a web API](/azure/active-directory/develop/quickstart-configure-app-access-web-apis#add-permissions-to-access-your-web-api)

+1. From your app's **Overview** page, note the following values for your app:

+ - **Display name**

+ - **Application (client) ID**

+ - **Directory (tenant) ID**

+1. From the **Certificates & secrets** page, note the values of your client secret **Value** and **Secret ID**.

+## Create an Azure event hub

+Create an Azure event hub to use as a bridge between Microsoft Sentinel and your partner SIEM. Start this step by creating an Azure event hub namespace, and then adding an Azure event hub.

+**To create your event hub namespace and event hub**:

+1. In Azure Event Hubs, create a new event hub namespace. In your new namespace, create a new Azure event hub.

+ In your event hub, make sure to define the **Partition Count** and **Message Retention** settings.

+ For more information, see [Create an event hub using the Azure portal](/azure/event-hubs/event-hubs-create).

+1. In your event hub namespace, select the **Access control (IAM)** page and add a new role assignment.

+ Select to use the **Azure Event Hubs Data Receiver** role, and add the Azure AD service principle app that you'd created [earlier](#register-an-application-in-azure-active-directory) as a member.

+ For more information, see: [Assign Azure roles using the Azure portal](/azure/role-based-access-control/role-assignments-portal).

+1. In your event hub namespace's **Overview** page, make a note of the namespace's **Host name** value.

+1. In your event hub namespace's **Event Hubs** page, make a note of your event hub's name.

+## Forward Microsoft Sentinel incidents to your event hub

+To forward Microsoft Sentinel incidents or alerts to your event hub, create a data export rule from Azure Log Analytics.

+In your rule, make sure to define the following settings:

+- Configure the **Source** as **SecurityIncident**

+- Configure the **Destination** as **Event Type**, using the event hub namespace and event hub name you'd recorded earlier.

+For more information, see [Log Analytics workspace data export in Azure Monitor](/azure/azure-monitor/logs/logs-data-export?tabs=portal#create-or-update-a-data-export-rule).

+## Configure Splunk to consume Microsoft Sentinel incidents

+Once you have your event hub and export rule configured, configure Splunk to consume Microsoft Sentinel incidents from the event hub.

+1. Install the [Splunk Add-on for Microsoft Cloud Services](https://splunkbase.splunk.com/app/3110/) app.

+1. In the Splunk Add-on for Microsoft Cloud Services app, add an Azure App account.

+ 1. Enter a meaningful name for the account.

+ 1. Enter the client ID, client secret, and tenant ID details that you'd recorded earlier.

+ 1. Define the account class type as **Azure Public Cloud**.

+1. Go to the Splunk Add-on for Microsoft Cloud Services inputs, and create a new input for your Azure event hub.

+ 1. Enter a meaningful name for your input.

+ 1. Select the Azure App Account that you'd just created in the Splunk Add-on for Microsoft Services app.

+ 1. Enter your event hub namespace FQDN and event hub name.

+ Leave other settings as their defaults.

+Once data starts getting ingested into Splunk from your event hub, query the data by using the following value in your search field: `sourcetype="mscs:azure:eventhub"`

+## Next steps

+This article describes how to forward alerts generated by cloud-connected sensors only. If you're working on-premises, such as in air-gapped environments, you may be able to create a forwarding alert rule to forward alert data directly from an OT sensor or on-premises management console.

+For more information, see [Integrations with Microsoft and partner services](../integrate-overview.md).

+For more information, see [Install OT monitoring software on an on-premises management console](ot-deploy/install-software-on-premises-management-console.md) and [Default privileged on-premises users](roles-on-premises.md#default-privileged-on-premises-users).

+For more information, see [Install OT monitoring software on OT sensors](how-to-install-software.md) and [Default privileged on-premises users](roles-on-premises.md#default-privileged-on-premises-users).

+ Title: Install Microsoft Defender for IoT on-premises management console software - Microsoft Defender for IoT

+description: Learn how to install Microsoft Defender for IoT on-premises management console software. Use this article if you're reinstalling software on a pre-configured appliance, or if you've chosen to install software on your own appliances.

+# Install Microsoft Defender for IoT on-premises management console software

+Use the procedures in this article when installing Microsoft Defender for IoT software on an on-premises management console. You might be reinstalling software on a [pre-configured appliance](../ot-pre-configured-appliances.md), or you may be installing software on your own appliance.

+## Prerequisites

+Before installing Microsoft Defender for IoT, make sure that you have:

+- [Traffic mirroring configured in your network](../best-practices/traffic-mirroring-methods.md)

+- An [OT plan in Defender for IoT](../how-to-manage-subscriptions.md) on your Azure subscription

+- An OT sensor [onboarded to Defender for IoT](../onboard-sensors.md) in the Azure portal

+- [OT monitoring software installed on an OT network sensor](install-software-ot-sensor.md)

+Each appliance type also comes with its own set of instructions that are required before installing Defender for IoT software. Make sure that you've completed any specific procedures required for your appliance before installing Defender for IoT software.

+For more information, see:

+- The [OT monitoring appliance catalog](../appliance-catalog/index.yml)

+- [Which appliances do I need?](../ot-appliance-sizing.md)

+- [OT monitoring with virtual appliances](../ot-virtual-appliances.md)

+## Download software files from the Azure portal

+Download on-premises management console software from Defender for IoT in the Azure portal.

+On the Defender for IoT > **Getting started** page, select the **On-premises management console** or **Updates** tab and locate the software you need.

+If you're updating from a previous version, check the options carefully to ensure that you have the correct update path for your situation.

+## Install on-premises management console software

+This procedure describes how to install OT management software on an on-premises management console, for a physical or virtual appliance.

+The installation process takes about 20 minutes. After the installation, the system is restarted several times.

+**To install the software**:

+1. Mount the ISO file onto your hardware appliance or VM using one of the following options:

+ - **Physical media** ΓÇô burn the ISO file to your external storage, and then boot from the media.

+ - DVDs: First burn the software to the DVD as an image

+ - USB drive: First make sure that youΓÇÖve created a bootable USB drive with software such as [Rufus](https://rufus.ie/en/), and then save the software to the USB drive. USB drives must have USB version 3.0 or later.

+ Your physical media must have a minimum of 4-GB storage.

+ - **Virtual mount** ΓÇô use iLO for HPE appliances, or iDRAC for Dell appliances to boot the ISO file.

+1. Select your preferred language for the installation process.

+ :::image type="content" source="../media/tutorial-install-components/on-prem-language-select.png" alt-text="Screenshot of selecting your preferred language for the installation process.":::

+1. Select **MANAGEMENT-RELEASE-\<version\>\<deployment type\>**.

+ :::image type="content" source="../media/tutorial-install-components/on-prem-install-screen.png" alt-text="Screenshot of selecting your management release version.":::

+1. In the Installation Wizard, define the network properties:

+ :::image type="content" source="../media/tutorial-install-components/on-prem-first-steps-install.png" alt-text="Screenshot that shows the appliance profile.":::

+ | Parameter | Configuration |

+ |--|--|

+ | **configure management network interface** | For Dell: **eth0, eth1** <br /> For HP: **enu1, enu2** <br> Or <br />**possible value** |

+ | **configure management network IP address** | Enter an IP address |

+ | **configure subnet mask** | Enter an IP address|

+ | **configure DNS** | Enter an IP address |

+ | **configure default gateway IP address** | Enter an IP address|

+1. **(Optional)** If you would like to install a secondary Network Interface Card (NIC), define the following appliance profile, and network properties:

+ | Parameter | Configuration |

+ |--|--|

+ | **configure sensor monitoring interface** (Optional) | **eth1** or **possible value** |

+ | **configure an IP address for the sensor monitoring interface** | Enter an IP address |

+ | **configure a subnet mask for the sensor monitoring interface** | Enter an IP address |

+ For example:

+

+ :::image type="content" source="../media/tutorial-install-components/on-prem-secondary-nic-install.png" alt-text="Screenshot that shows the Secondary NIC install questions.":::

+ If you choose not to install the secondary NIC now, you can [do so at a later time](#add-a-secondary-nic-after-installation-optional).

+1. Accept the settings and continue by typing `Y`.

+1. After about 10 minutes, the two sets of credentials appear. For example:

+ :::image type="content" source="../media/tutorial-install-components/credentials-screen.png" alt-text="Screenshot of the credentials that appear that must be copied as they won't be presented again.":::

+ Save the usernames and passwords, you'll need these credentials to access the platform the first time you use it.

+ For more information, see [Default privileged on-premises users](../roles-on-premises.md#default-privileged-on-premises-users).

+1. Select **Enter** to continue.

+### Add a secondary NIC after installation (optional)

+You can enhance security to your on-premises management console by adding a secondary NIC dedicated for attached sensors within an IP address range. When you use a secondary NIC, the first is dedicated for end-users, and the secondary supports the configuration of a gateway for routed networks.

+Both NICs will support the user interface (UI). If you choose not to deploy a secondary NIC, all of the features will be available through the primary NIC.

+This procedure describes how to add a secondary NIC if you've already installed your on-premises management console.

+**To add a secondary NIC**:

+1. Use the network reconfigure command:

+ ```bash

+ sudo cyberx-management-network-reconfigure

+ ```

+1. Enter the following responses to the following questions:

+ :::image type="content" source="../media/tutorial-install-components/network-reconfig-command.png" alt-text="Screenshot of the required answers to configure your appliance. ":::

+ | Parameters | Response to enter |

+ |--|--|

+ | **Management Network IP address** | `N` |

+ | **Subnet mask** | `N` |

+ | **DNS** | `N` |

+ | **Default gateway IP Address** | `N` |

+ | **Sensor monitoring interface** <br>Optional. Relevant when sensors are on a different network segment.| `Y`, and select a possible value |

+ | **An IP address for the sensor monitoring interface** | `Y`, and enter an IP address that's accessible by the sensors|

+ | **A subnet mask for the sensor monitoring interface** | `Y`, and enter an IP address that's accessible by the sensors|

+ | **Hostname** | Enter the hostname |

+1. Review all choices and enter `Y` to accept the changes. The system reboots.

+### Find a port on your appliance

+If you're having trouble locating the physical port on your appliance, you can use the following command to find your port:

+```bash

+sudo ethtool -p <port value> <time-in-seconds>

+```

+This command will cause the light on the port to flash for the specified time period. For example, entering `sudo ethtool -p eno1 120`, will have port eno1 flash for 2 minutes, allowing you to find the port on the back of your appliance.

+## Next steps

+> [!div class="nextstepaction"]

+> [Validate after installing software](post-install-validation-ot-software.md)

+> [!div class="nextstepaction"]

+> [Troubleshooting](../how-to-troubleshoot-the-sensor-and-on-premises-management-console.md)

+ Title: Install OT network monitoring software on OT sensors - Microsoft Defender for IoT

+description: Learn how to install agentless monitoring software for an OT sensor for Microsoft Defender for IoT. Use this article when reinstalling software on a pre-configured appliance, or if you've chosen to install software on your own appliances.

+# Install OT monitoring software on OT sensors

+Use the procedures in this article when installing Microsoft Defender for IoT software on OT network sensors. You might be reinstalling software on a [pre-configured appliance](../ot-pre-configured-appliances.md), or you may be installing software on your own appliance.

+## Prerequisites

+Before installing Microsoft Defender for IoT, make sure that you have:

+- [Traffic mirroring configured in your network](../best-practices/traffic-mirroring-methods.md)

+- An [OT plan in Defender for IoT](../how-to-manage-subscriptions.md) on your Azure subscription

+- An OT sensor [onboarded to Defender for IoT](../onboard-sensors.md) in the Azure portal

+Each appliance type also comes with its own set of instructions that are required before installing Defender for IoT software. Make sure that you've completed any specific procedures required for your appliance before installing Defender for IoT software.

+For more information, see:

+- The [OT monitoring appliance catalog](../appliance-catalog/index.yml)

+- [Which appliances do I need?](../ot-appliance-sizing.md)

+- [OT monitoring with virtual appliances](../ot-virtual-appliances.md)

+## Download software files from the Azure portal

+Download the OT sensor software from Defender for IoT in the Azure portal.

+On the Defender for IoT > **Getting started** page, select the **Sensor** or **Updates** tab and locate the software you need.

+If you're updating from a previous version, check the options carefully to ensure that you have the correct update path for your situation.

+## Install Defender or IoT software on OT sensors

+This procedure describes how to install OT monitoring software on a sensor.

+> [!Note]

+> Towards the end of this process you will be presented with the usernames and passwords for your device. Make sure to copy these down as these passwords will not be presented again.

+1. Mount the ISO file onto your hardware appliance or VM using one of the following options:

+ - **Physical media** ΓÇô burn the ISO file to your external storage, and then boot from the media.

+ - DVDs: First burn the software to the DVD as an image

+ - USB drive: First make sure that youΓÇÖve created a bootable USB drive with software such as [Rufus](https://rufus.ie/en/), and then save the software to the USB drive. USB drives must have USB version 3.0 or later.

+ Your physical media must have a minimum of 4-GB storage.

+ - **Virtual mount** ΓÇô use iLO for HPE appliances, or iDRAC for Dell appliances to boot the ISO file.

+1. When the installation boots, you're first prompted to select the hardware profile you want to install.

+ :::image type="content" source="../media/tutorial-install-components/sensor-architecture.png" alt-text="Screenshot of the sensor's hardware profile options." lightbox="../media/tutorial-install-components/sensor-architecture.png":::

+ For more information, see [Which appliances do I need?](../ot-appliance-sizing.md).

+ System files are installed, the sensor reboots, and then sensor files are installed. This process can take a few minutes.

+ When the installation steps are complete, the Ubuntu **Package configuration** screen is displayed, with the `Configuring iot-sensor` wizard, showing a prompt to select your monitor interfaces.

+ In this wizard, use the up or down arrows to navigate, and the SPACE bar to select an option. Press ENTER to advance to the next screen.

+1. In the `Select monitor interfaces` screen, select the interfaces you want to monitor.

+ > [!IMPORTANT]

+ > Make sure that you select only interfaces that are connected.

+ > If you select interfaces that are enabled but not connected, the sensor will show a *No traffic monitored* health notification in the Azure portal. If you connect more traffic sources after installation and want to monitor them with Defender for IoT, you can add them via the CLI.

+ By default, `eno1` is reserved for the management interface and we recommend that you leave this option unselected.

+ For example:

+ :::image type="content" source="../media/tutorial-install-components/monitor-interface.png" alt-text="Screenshot of the select monitor interface screen.":::

+1. In the `Select erspan monitor interfaces` screen, select any ERSPAN monitoring ports that you have. The wizard lists available interfaces, even if you don't have any ERSPAN monitoring ports in your system. If you have no ERSPAN monitoring ports, leave all options unselected.

+ For example:

+ :::image type="content" source="../media/tutorial-install-components/erspan-monitor.png" alt-text="Screenshot of the select erspan monitor screen.":::

+1. In the `Select management interface` screen, we recommend keeping the default `eno1` value selected as the management interface.

+ For example:

+ :::image type="content" source="../media/tutorial-install-components/management-interface.png" alt-text="Screenshot of the management interface select screen.":::

+1. In the `Enter sensor IP address` screen, enter the IP address for the sensor appliance you're installing.

+ :::image type="content" source="../media/tutorial-install-components/sensor-ip-address.png" alt-text="Screenshot of the sensor IP address screen.":::

+1. In the `Enter path to the mounted backups folder` screen, enter the path to the sensor's mounted backups. We recommend using the default path of `/opt/sensor/persist/backups`. For example:

+ :::image type="content" source="../media/tutorial-install-components/mounted-backups-path.png" alt-text="Screenshot of the mounted backup path screen.":::

+1. In the `Enter Subnet Mask` screen, enter the IP address for the sensor's subnet mask. For example:

+ :::image type="content" source="../media/tutorial-install-components/sensor-subnet-ip.png" alt-text="Screenshot of the Enter Subnet Mask screen.":::

+1. In the `Enter Gateway` screen, enter the sensor's default gateway IP address. For example:

+ :::image type="content" source="../media/tutorial-install-components/sensor-gateway-ip.png" alt-text="Screenshot of the Enter Gateway screen.":::

+1. In the `Enter DNS server` screen, enter the sensor's DNS server IP address. For example:

+ :::image type="content" source="../media/tutorial-install-components/sensor-dns-ip.png" alt-text="Screenshot of the Enter DNS server screen.":::

+1. In the `Enter hostname` screen, enter the sensor hostname. For example:

+ :::image type="content" source="../media/tutorial-install-components/sensor-hostname.png" alt-text="Screenshot of the Enter hostname screen.":::

+1. In the `Run this sensor as a proxy server (Preview)` screen, select `<Yes>` only if you want to configure a proxy, and then enter the proxy credentials as prompted.

+ The default configuration is without a proxy.

+ For more information, see [Connect Microsoft Defender for IoT sensors without direct internet access by using a proxy (version 10.x)](../how-to-connect-sensor-by-proxy.md).

+1. <a name=credentials></a>The installation process starts running and then shows the credentials screen. For example:

+ :::image type="content" source="../media/tutorial-install-components/login-information.png" alt-text="Screenshot of the final screen of the installation with usernames, and passwords.":::

+ Save the usernames and passwords listed, as the passwords are unique and this is the only time that the credentials are shown. Copy the credentials to a safe place so that you can use them when signing into the sensor for the first time.

+ For more information, see [Default privileged on-premises users](../roles-on-premises.md#default-privileged-on-premises-users).

+ Select `<Ok>` when you're ready to continue.

+ The installation continues running again, and then reboots when the installation is complete. Upon reboot, you're prompted to enter credentials to sign in. For example:

+ :::image type="content" source="../media/tutorial-install-components/sensor-sign-in.png" alt-text="Screenshot of a sensor sign-in screen after installation.":::

+1. Enter the credentials for one of the users that you'd copied down in the [previous step](#credentials).

+ - If the `iot-sensor login:` prompt disappears, press **ENTER** to have it shown again.

+ - When you enter your password, the password characters don't display on the screen. Make sure you enter them carefully.

+ When you've successfully signed in, the following confirmation screen appears:

+ :::image type="content" source="../media/tutorial-install-components/install-complete.png" alt-text="Screenshot of the sign-in confirmation.":::

+Make sure that your sensor is connected to your network, and then you can sign in to your sensor via a network-connected browser. For more information, see [Activate and set up your sensor](../how-to-activate-and-set-up-your-sensor.md#activate-and-set-up-your-sensor)

+## Next steps

+> [!div class="nextstepaction"]

+> [Validate after installing software](post-install-validation-ot-software.md)

+> [!div class="nextstepaction"]

+> [Install software on an on-premises management console](install-software-on-premises-management-console.md)

+> [!div class="nextstepaction"]

+> [Troubleshooting](../how-to-troubleshoot-the-sensor-and-on-premises-management-console.md)

+ Title: Post-installation validation of OT network monitoring software - Microsoft Defender for IoT

+description: Learn how to test your system post installation of OT network monitoring software for Microsoft Defender for IoT. Use this article after you've reinstalled software on a pre-configured appliance, or if you've chosen to install software on your own appliances.

+# Post-installation validation of OT network monitoring software

+After you've installed OT software on your [OT sensors](install-software-ot-sensor.md) or [on-premises management console](install-software-on-premises-management-console.md), test your system to make sure that processes are running correctly. The same validation process applies to all appliance types.

+System health validations are supported via the sensor or on-premises management console UI or CLI, and are available for both the *support* and *cyberx* users.

+## General tests

+After installing OT monitoring software, make sure to run the following tests:

+- **Sanity test**: Verify that the system is running.

+- **Version**: Verify that the version is correct.

+- **ifconfig**: Verify that all the input interfaces configured during the installation process are running.

+## Gateway checks

+Use the `route` command to show the gateway's IP address. For example:

+``` CLI

+<root@xsense:/# route -n

+Kernel IP routing table

+Destination Gateway Genmask Flags Metric Ref Use Iface

+0.0.0.0 172.18.0.1 0.0.0.0 UG 0 0 0 eth0

+172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0

+>

+```

+Use the `arp -a` command to verify that there is a binding between the MAC address and the IP address of the default gateway. For example:

+``` CLI

+<root@xsense:/# arp -a

+cusalvtecca101-gi0-02-2851.network.microsoft.com (172.18.0.1) at 02:42:b0:3a:e8:b5 [ether] on eth0

+mariadb_22.2.6.27-r-c64cbca.iot_network_22.2.6.27-r-c64cbca (172.18.0.5) at 02:42:ac:12:00:05 [ether] on eth0

+redis_22.2.6.27-r-c64cbca.iot_network_22.2.6.27-r-c64cbca (172.18.0.3) at 02:42:ac:12:00:03 [ether] on eth0

+>

+```

+## DNS checks

+Use the `cat /etc/resolv.conf` command to find the IP address that's configured for DNS traffic. For example:

+``` CLI

+<root@xsense:/# cat /etc/resolv.conf

+search reddog.microsoft.com

+nameserver 127.0.0.11

+options ndots:0

+>

+```

+Use the `host` command to resolve an FQDN. For example:

+``` CLI

+<root@xsense:/# host www.apple.com

+www.apple.com is an alias for www.apple.com.edgekey.net.

+www.apple.com.edgekey.net is an alias for www.apple.com.edgekey.net.globalredir.akadns.net.

+www.apple.com.edgekey.net.globalredir.akadns.net is an alias for e6858.dscx.akamaiedge.net.

+e6858.dscx.akamaiedge.net has address 72.246.148.202

+e6858.dscx.akamaiedge.net has IPv6 address 2a02:26f0:5700:1b4::1aca

+e6858.dscx.akamaiedge.net has IPv6 address 2a02:26f0:5700:182::1aca

+>

+```

+## Firewall checks

+Use the `wget` command to verify that port 443 is open for communication. For example:

+``` CLI

+<root@xsense:/# wget https://www.apple.com

+--2022-11-09 11:21:15-- https://www.apple.com/

+Resolving www.apple.com (www.apple.com)... 72.246.148.202, 2a02:26f0:5700:1b4::1aca, 2a02:26f0:5700:182::1aca

+Connecting to www.apple.com (www.apple.com)|72.246.148.202|:443... connected.

+HTTP request sent, awaiting response... 200 OK

+Length: 99966 (98K) [text/html]

+Saving to: 'https://docsupdatetracker.net/index.html.1'

+https://docsupdatetracker.net/index.html.1 100%[===================>] 97.62K --.-KB/s in 0.02s

+2022-11-09 11:21:15 (5.88 MB/s) - 'https://docsupdatetracker.net/index.html.1' saved [99966/99966]

+>

+```

+For more information, see [Check system health](../how-to-troubleshoot-the-sensor-and-on-premises-management-console.md#check-system-health) in our sensor and on-premises management console troubleshooting article.

+## Next steps

+> [!div class="nextstepaction"]

+> [Troubleshoot an OT sensor or on-premises management console](../how-to-troubleshoot-the-sensor-and-on-premises-management-console.md)

+>

+|**E1800** | [HPE ProLiant DL20 Gen10 Plus](appliance-catalog/hpe-proliant-dl20-plus-enterprise.md) (4SFF) <br><br> [Dell PowerEdge R350](appliance-catalog/dell-poweredge-r350-e1800.md) | **Max bandwidth**: 1 Gbp/s<br>**Max devices**: 10,000 <br> 8 Cores/32G RAM/1.8TB | **Mounting**: 1U <br>**Ports**: 8x RJ45 or 6x SFP (OPT) |

+The Internet of Things (IoT) supports billions of connected devices that use both operational technology (OT) and IoT networks. IoT/OT devices and networks are often built using specialized protocols, and may prioritize operational challenges over security.

+When IoT/OT devices can't be protected by traditional security monitoring systems, each new wave of innovation increases the risk and possible attack surfaces across those IoT devices and OT networks.

+Microsoft Defender for IoT is a unified security solution built specifically to identify IoT and OT devices, vulnerabilities, and threats. Use Defender for IoT to secure your entire IoT/OT environment, including existing devices that may not have built-in security agents.

+Defender for IoT provides agentless, network layer monitoring, and integrates with both industrial equipment and security operation center (SOC) tools.

+If your IoT and OT devices don't have embedded security agents, they may remain unpatched, misconfigured, and invisible to IT and security teams. Un-monitored devices can be soft targets for threat actors looking to pivot deeper into corporate networks.

+Defender for IoT uses agentless monitoring to provide visibility and security across your network, and identifies specialized protocols, devices, or machine-to-machine (M2M) behaviors.

+ - Detect advanced threats that you may have missed by static indicators of compromise (IOCs), such as zero-day malware, fileless malware, and living-off-the-land tactics.

+- **Respond to threats** by integrating with Microsoft services such as Microsoft Sentinel, other partner systems, and APIs. Integrate with security information and event management (SIEM) services, security operations and response (SOAR) services, extended detection and response (XDR) services, and more.

+Defender for IoT's centralized user experience in the Azure portal lets the security and OT monitoring teams visualize and secure all their IT, IoT, and OT devices regardless of where the devices are located.

+## Support for cloud, on-premises, and hybrid OT networks

+Install OT network sensors on-premises, at strategic locations in your network to detect devices across your entire OT environment. Then, use any of the following configurations to view your devices and security value:

+- **Cloud services**:

+ While OT network sensors have their own UI console that displays details and security data about detected devices, connect your sensors to Azure to extend your journey to the cloud.

+ From the Azure portal, view data from all connected sensors in a central location, and integrate with other Microsoft services, like Microsoft Sentinel.

+- **Air-gapped and on-premises services**:

+ If you have an air-gapped environment and want to keep all your OT network data fully on-premises, connect your OT network sensors to an on-premises management console for central visibility and control.

+ Continue to view detailed device data and security value in each sensor console.

+- **Hybrid services**:

+ You may have hybrid network requirements where you can deliver some data to the cloud and other data must remain on-premises.

+ In this case, set up your system in a flexible and scalable configuration to fit your needs. Connect some of your OT sensors to the cloud and view data on the Azure portal, and keep other sensors managed on-premises only.

+For more information, see [System architecture for OT system monitoring](architecture.md).

+## Extend support to proprietary OT protocols

+IoT and industrial control system (ICS) devices can be secured using both embedded protocols and proprietary, custom, or non-standard protocols. If you have devices that run on protocols that aren't supported by Defender for IoT out-of-the-box, use the Horizon Open Development Environment (ODE) SDK to develop dissector plug-ins to decode network traffic for your protocols.

+Create custom alerts for your plugin to pinpoint specific network activity and effectively update your security, IT, and operational teams. For example, have alerts triggered when:

+- The sensor detects a write command to a memory register on a specific IP address and Ethernet destination.

+- Any access is performed to a specific IP address.

+For more information, see [Manage proprietary protocols with Horizon plugins](resources-manage-proprietary-protocols.md).

+## Protect enterprise IoT networks

+Use one or both of the following methods to extend Defender for IoT's agentless security features beyond OT environments to enterprise IoT devices.

+- Add an Enterprise IoT plan in Microsoft Defender for Endpoint for added alerts, vulnerabilities, and recommendations for IoT devices in Defender for Endpoint. An Enterprise IoT plan also provides a shared device inventory across the Azure portal and Microsoft 365 Defender.

+- Onboard an Enterprise IoT network sensor in Defender for IoT (Public Preview) to extend Defender for IoT device visibility to devices that aren't covered by Defender for Endpoint.

+Enterprise IoT devices can include devices such as printers, smart TVs, and conferencing systems and purpose-built, proprietary devices.

+For more information, see [Securing IoT devices in the enterprise](concept-enterprise.md).

+## Defender for IoT for device builders

+Defender for IoT also provides a lightweight security micro-agent that you can use to build security straight into your new IoT innovations.

+For more information, see the [Microsoft Defender for IoT for device builders documentation](../device-builders/overview.md).

+## Supported service regions

+Defender for IoT routes all traffic from all European regions to the *West Europe* regional datacenter. It routes traffic from all remaining regions to the *East US* regional datacenter.

+If you're using Defender for IoT OT monitoring software earlier than [22.1](release-notes.md#versions-222x) and are connecting through your own IoT Hub, the IoT Hub supported regions are also relevant for your organization. For more information, see [IoT Hub supported regions](https://azure.microsoft.com/global-infrastructure/services/?products=iot-hub).

+> [!div class="nextstepaction"]

+> [View ICS/OT Security videos](https://www.youtube.com/playlist?list=PLmAptfqzxVEXz5txCCKYUdpQETAMpeOhu)

+> [!div class="nextstepaction"]

+> [Get started with OT security monitoring](getting-started.md)

+> [!div class="nextstepaction"]

+> [Get started with Enterprise IoT security monitoring](eiot-defender-for-endpoint.md)

+| **22.3** | | | |

+| 22.3.4 | 01/2023 | Major | 12/2023 |

+## Versions 22.3.x

+### 22.3.4

+**Release date**: 01/2021

+**Supported until**: 12/2023

+- [Azure connectivity status shown on OT sensors](how-to-manage-individual-sensors.md#validate-connectivity-status)

+[Quickstart: Get started with Defender for IoT](getting-started.md)

+By default, each [sensor](ot-deploy/install-software-ot-sensor.md) and [on-premises management console](ot-deploy/install-software-on-premises-management-console.md) is installed with the *cyberx* and *support* privileged users. OT sensors are also installed with the *cyberx_host* privileged user.

+For more information, see [Install OT monitoring software on OT sensors](../how-to-install-software.md).

+ Title: Onboard and activate a virtual OT sensor - Microsoft Defender for IoT.

+description: This tutorial describes how to set up a virtual OT network sensor to monitor your OT network traffic.

+- Make sure that you have a network switch that supports traffic monitoring via a SPAN port. You'll also need at least one device to monitor, connected to the switch's SPAN port.

+## January 2023

+|**OT networks** | **Version 22.3.4**: [Azure connectivity status shown on OT sensors](#azure-connectivity-status-shown-on-ot-sensors) |

+### Azure connectivity status shown on OT sensors

+Details about Azure connectivity status are now shown on the **Overview** page in OT network sensors, and errors are shown if the sensor's connection to Azure is lost.

+For example:

+For more information, see [Manage individual sensors](how-to-manage-individual-sensors.md) and [Onboard OT sensors to Defender for IoT](onboard-sensors.md).

+## December 2022

+|Service area |Updates |

+|||

+|**OT networks** | - **Cloud feature**: [New purchase experience for OT plans](#new-purchase-experience-for-ot-plans) |

+> The Azure SQL Migration extension for Azure Data Studio doesn't take database backups, or neither initiate any database backups on your behalf. Instead, the service uses existing database backup files for the migration.

+>

+ > - The Azure SQL Migration extension for Azure Data Studio doesn't take database backups, or neither initiate any database backups on your behalf. Instead, the service uses existing database backup files for the migration.

+ > - The Azure SQL Migration extension for Azure Data Studio doesn't take database backups, or neither initiate any database backups on your behalf. Instead, the service uses existing database backup files for the migration.

+To complete the cutover:

+1. Stop all incoming transactions to the source database.

+2. Make application configuration changes to point to the target database in Azure SQL Managed Instance.

+3. Take a final log backup of the source database in the backup location specified

+4. Put the source database in read-only mode. Therefore, users can read data from the database but not modify it.

+5. Ensure all database backups have the status *Restored* in the monitoring details page.

+6. Select *Complete cutover* in the monitoring details page.

+> Each backup can be written to either a separate backup file or multiple backup files. However, appending multiple backups (that is, full and t-log) into a single backup media isn't supported.

+> Use compressed backups to reduce the likelihood of experiencing potential issues associated with migrating large backups.

+ > - The Azure SQL Migration extension for Azure Data Studio doesn't take database backups, or neither initiate any database backups on your behalf. Instead, the service uses existing database backup files for the migration.

+ > - The Azure SQL Migration extension for Azure Data Studio doesn't take database backups, or neither initiate any database backups on your behalf. Instead, the service uses existing database backup files for the migration.

+2. Make application configuration changes to point to the target database in SQL Server on Azure Virtual Machines.

+3. Take a final log backup of the source database in the backup location specified

+4. Put the source database in read-only mode. Therefore, users can read data from the database but not modify it.

+5. Ensure all database backups have the status *Restored* in the monitoring details page.

+6. Select *Complete cutover* in the monitoring details page.

+ - eastus

+ - australiaeast

+- [Understanding dashboards](understanding-dashboards.md)

+Azure Front Door is MicrosoftΓÇÖs modern cloud Content Delivery Network (CDN) that provides fast, reliable, and secure access between your users and your applicationsΓÇÖ static and dynamic web content across the globe. Azure Front Door delivers your content using the MicrosoftΓÇÖs global edge network with hundreds of [global and local points of presence (PoPs)](edge-locations-by-region.md) distributed around the world close to both your enterprise and consumer end users.

+Azure Policy definitions in the category `Guest Configuration` can be assigned

+to management groups when the effect is `AuditIfNotExists` or `DeployIfNotExists`.

+- Azure Resource Manager doesn't validate the management group's existence in the role

+- Namespaces automatically excluded by Azure Policy Add-on for evaluation: _kube-system_ and

+ _gatekeeper-system_.

+|Audit Plug and Play Events<br />_{(AZ-WIN-00182)} |**Description**: This PNP Activity policy setting allows you to audit when plug and play detects an external device. The recommended state for this setting is: `Success`. **Note:** A Windows 10, Server 2016 or higher OS is required to access and set this value in Group Policy.<br />**Key Path**: {0CCE9248-69AE-11D9-BED3-505054503030}<br />**OS**: WS2016, WS2019, WS2022<br />**Server Type**: Domain Controller, Domain Member, Workgroup Member |\>\= Success<br />_(Audit) |Critical |

+After creating the new cluster, you can SSH to your cluster and run `sudo lsb_release -a` to verify that it runs on Ubuntu 18.04. We recommend that you test your applications in your test subscriptions first before moving to production.

+1. Navigate to [RequestBin](https://requestbin.com/).

+1. Select **Create a RequestBin**.

+1. Sign in with one of the available methods.

+1. Copy the URL of your RequestBin endpoint.

+You can export data to a publicly available HTTP Webhook endpoint. You can create a test Webhook endpoint using [RequestBin](https://requestbin.com/). RequestBin throttles request when the request limit is reached:

+1. Navigate to [RequestBin](https://requestbin.com/).

+1. Select **Create a RequestBin**.

+1. Sign in with one of the available methods.

+1. Copy the URL of your RequestBin You use this URL when you test your data export.

+ "url": "https://eofnjsh68jdytan.m.pipedream.net",

+1. Sign in with one of the available methods.

+ |`IOT_HUB_DEVICE_ID` |{*Your Device ID value*}|

+There are many scenarios where you can't easily map your device data into the relatively small device-to-cloud messages that IoT Hub accepts. For example, sending large media files like video; or, sending large telemetry batches, either uploaded by intermittently connected devices or aggregated and compressed to save bandwidth.

+If you need help with deciding when to use reported properties, device-to-cloud messages, or file uploads, see [Device-to-cloud communications guidance](iot-hub-devguide-d2c-guidance.md).

+An IoT hub facilitates file uploads from connected devices by providing them with shared access signature (SAS) URIs on a per-upload basis for a blob container and Azure storage account that have been pre-configured with the hub. There are three parts to using file uploads with IoT Hub: pre-configuring an Azure storage account and blob container on your IoT hub, uploading files from devices, and, optionally, notifying backend services of completed file uploads.

+1. The device initiates the file upload with the IoT hub. It passes the name of a blob in the request and gets a SAS URI and a correlation ID in return. The SAS URI contains a SAS token for Azure storage that grants the device read-write permission on the requested blob in the blob container. For more information, see [Device: Initialize a file upload](#device-initialize-a-file-upload).

+1. The device uses the SAS URI to securely call Azure blob storage APIs to upload the file to the blob container. For more information, see [Device: Upload file using Azure storage APIs](#device-upload-file-using-azure-storage-apis).

+1. When the file upload is complete, the device notifies the IoT hub of the completion status using the correlation ID it received from IoT Hub when it initiated the upload. For more information, see [Device: Notify IoT Hub of a completed file upload](#device-notify-iot-hub-of-a-completed-file-upload).

+Backend services can subscribe to file upload notifications on the IoT hub's service-facing file upload notification endpoint. If you've enabled these notifications on your IoT hub, it delivers them on this endpoint whenever a device notifies the hub that it has completed a file upload. Services can use these notifications to trigger further processing of the blob data. For more information, see [Service: File upload notifications](#service-file-upload-notifications).

+File upload is fully supported by the Azure IoT device and service SDKs. For more information, see [File upload using an SDK](#file-upload-using-an-sdk).

+IoT Hub imposes throttling limits on the number of file uploads that it can initiate in a given period. The threshold is based on the SKU and number of units of your IoT hub. Additionally, each device is limited to 10 concurrent active file uploads at a time. For more information, see [IoT Hub quotas and throttling](iot-hub-devguide-quotas-throttling.md).

+You must associate an Azure storage account and blob container with your IoT hub to use file upload features. All file uploads from devices registered with your IoT hub will go to this container. To configure a storage account and blob container on your IoT hub, see [Configure IoT Hub file uploads using the Azure portal](iot-hub-configure-file-upload.md), [Configure IoT Hub file uploads using Azure CLI](iot-hub-configure-file-upload-cli.md), or [Configure IoT Hub file uploads using PowerShell](iot-hub-configure-file-upload-powershell.md). You can also use the IoT Hub management APIs to configure file uploads programmatically.

+If you use the portal, you can create a storage account and container during configuration. Otherwise, to create a storage account, see [Create a storage account](../storage/common/storage-account-create.md) in the Azure storage documentation. Once you have a storage account, you can see how to create a blob container in the [Azure Blob Storage quickstarts](../storage/blobs/storage-quickstart-blobs-portal.md). By default, Azure IoT Hub uses key-based authentication to connect and authorize with Azure Storage. You can also configure user-assigned or system-assigned managed identities to authenticate Azure IoT Hub with Azure Storage. Managed identities provide Azure services with an automatically managed identity in Azure AD in a secure manner. To learn how to configure managed identities, see the [Configure file upload with managed identities](iot-hub-managed-identity.md#configure-file-upload-with-managed-identities) section of [IoT Hub support for managed identities](iot-hub-managed-identity.md).

+File upload is subject to [Azure Storage's firewall settings](../storage/common/storage-network-security.md). Based on your authentication configuration, you'll need to ensure your devices can communicate with Azure storage.

+The following settings associate a storage account and container with your IoT hub and control how your hub authenticates with Azure storage. These settings don't affect how devices authenticate with Azure storage. Devices always authenticate with the SAS token presented in the SAS URI retrieved from IoT Hub.

+| **storageEndpoints.$default.ttlAsIso8601** | Default TTL for SAS URIs generated by IoT Hub. | ISO_8601 interval up to 48 hours (minimum one minute). Default: one hour. |

+| **fileNotifications.ttlAsIso8601** |Default TTL for file upload notifications. |ISO_8601 interval up to 48 hours (minimum one minute). Default: one hour. |

+The following how-to guides provide complete, step-by-step instructions to upload files using the Azure IoT device and service SDKs. The guides show you how to use the Azure portal to associate a storage account with an IoT hub. The guides also contain code snippets or refer to samples that guide you through an upload.

+> The C device SDK uses a single call on the device client to perform file uploads. For more information, see [IoTHubDeviceClient_UploadToBlobAsync()](https://github.com/Azure/azure-iot-sdk-c/blob/main/iothub_client/inc/iothub_device_client.h#L328) and [IoTHubDeviceClient_UploadMultipleBlocksToBlobAsync()](https://github.com/Azure/azure-iot-sdk-c/blob/main/iothub_client/inc/iothub_device_client.h#L350). These functions perform all aspects of the file upload in a single call: initiating the upload, uploading the file to Azure storage, and notifying IoT Hub when it completes. This interaction means that, in addition to whatever protocol the device is using to communicate with IoT Hub, the device also needs to be able to communicate over HTTPS with Azure storage as these functions make calls to the Azure storage APIs.

+ For example, for the values returned in the previous sample, the SAS URI is, `https://contosostorageaccount.blob.core.windows.net/device-upload-container/mydevice/myfile.txt?sv=2018-03-28&sr=b&sig=mBLiODhpKXBs0y9RVzwk1S...l1X9qAfDuyg%3D&se=2021-07-30T06%3A11%3A10Z&sp=rw`

+The device uses the [Azure Blob Storage REST APIs](/rest/api/storageservices/blob-service-rest-api) or equivalent Azure storage SDK APIs to upload the file to the blob in Azure storage.

+* To learn more about working with blobs in Azure storage, see the [Azure Blob Storage documentation](../storage/blobs/index.yml).

+If file upload notifications are enabled on your IoT hub, your hub generates a notification message for backend services when it receives notification from a device that a file upload is complete. IoT Hub delivers these file upload notifications through a service-facing endpoint. The receive semantics for file upload notifications are the same as for cloud-to-device messages and have the same [message life cycle](iot-hub-devguide-messages-c2d.md#the-cloud-to-device-message-life-cycle). The service SDKs expose APIs to handle file upload notifications.

+* [MQTT v3.1.1](https://mqtt.org/) on TCP port 8883

+* MQTT v3.1.1 over WebSocket on TCP port 443.

+All device communication with IoT Hub must be secured using TLS/SSL. Therefore, IoT Hub doesn't support non-secure connections over TCP port 1883.

+The MQTT port (TCP port 8883) is blocked in many corporate and educational networking environments. If you can't open port 8883 in your firewall, we recommend using MQTT over WebSockets. MQTT over WebSockets communicates over port 443, which is almost always open in networking environments. To learn how to specify the MQTT and MQTT over WebSockets protocols when using the Azure IoT SDKs, see [Using the device SDKs](#using-the-device-sdks).

+[Device SDKs](https://github.com/Azure/azure-iot-sdks) that support the MQTT protocol are available for Java, Node.js, C, C#, and Python. The device SDKs use the chosen [authentication mechanism](iot-concepts-and-iot-hub.md#device-identity-and-authentication) to establish a connection to an IoT hub. To use the MQTT protocol, the client protocol parameter must be set to **MQTT**. You can also specify MQTT over WebSockets in the client protocol parameter. By default, the device SDKs connect to an IoT Hub with the **CleanSession** flag set to **0** and use **QoS 1** for message exchange with the IoT hub. While it's possible to configure **QoS 0** for faster message exchange, you should note that the delivery isn't guaranteed nor acknowledged. For this reason, **QoS 0** is often referred as "fire and forget".

+The following table contains links to code samples for each supported language and specifies the parameter to use to establish a connection to IoT Hub using the MQTT or the MQTT over WebSockets protocol.

+| Language | MQTT protocol parameter | MQTT over WebSockets protocol parameter

+| [C#](https://github.com/Azure/azure-iot-sdk-csharp/tree/main/iothub/device/samples) | [TransportType](/dotnet/api/microsoft.azure.devices.client.transporttype).Mqtt | TransportType.Mqtt falls back to MQTT over WebSockets if MQTT fails. To specify MQTT over WebSockets only, use TransportType.Mqtt_WebSocket_Only |

+The following fragment shows how to specify the MQTT over WebSockets protocol when using the Azure IoT Node.js SDK:

+The following fragment shows how to specify the MQTT over WebSockets protocol when using the Azure IoT Python SDK:

+In order to ensure a client/IoT Hub connection stays alive, both the service and the client regularly send a *keep-alive* ping to each other. The client using IoT SDK sends a keep-alive at the interval defined in the following table:

+*The C# SDK defines the default value of the MQTT KeepAliveInSeconds property as 300 seconds. In reality, the SDK sends a ping request four times per keep-alive duration set. This means the SDK sends a keep-alive ping every 75 seconds.

+Following the [MQTT v3.1.1 specification](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718081), IoT Hub's keep-alive ping interval is 1.5 times the client keep-alive value; however, IoT Hub limits the maximum server-side timeout to 29.45 minutes (1767 seconds). This limit exists because all Azure services are bound to the Azure load balancer TCP idle timeout, which is 29.45 minutes.

+The maximum client keep-alive value you can set is `1767 / 1.5 = 1177` seconds. Any traffic will reset the keep-alive. For example, a successful shared access signature (SAS) token refresh resets the keep-alive.

+In the [IoT MQTT Sample repository](https://github.com/Azure-Samples/IoTMQTTSample), you'll find a couple of C/C++ demo projects showing how to send telemetry messages and receive events with an IoT hub without using the Azure IoT C SDK.

+These samples use the [Eclipse Mosquitto](https://mosquitto.org) library to send messages to the MQTT broker implemented in the IoT hub.

+This repository contains the following examples:

+* `mosquitto_telemetry` contains code to send a telemetry message to an Azure IoT hub, built and run on a Windows machine.

+* `mosquitto_subscribe` contains code to subscribe to events of a given IoT hub on a Windows machine.

+* `mosquitto_device_twin` contains code to query and subscribe to the device twin events of a device in the Azure IoT hub on a Windows machine.

+* `MQTTLinux` contains code and build script to run on Linux (WSL, Ubuntu, and Raspbian have been tested so far).

+* `LinuxConsoleVS2019` contains the same code but in a Visual Studio 2019 (VS2019) project targeting Windows Subsystem for Linux (WSL). This project allows you to debug the code running on Linux step by step from Visual Studio.

+This folder contains two samples commands used with the mosquitto_pub utility tool provided by [Eclipse Mosquitto](https://mosquitto.org).

+* [Send a message](https://github.com/Azure-Samples/IoTMQTTSample/tree/master/mosquitto_pub#send-a-message) sends a text message to an IoT hub, acting as a device.

+* [Subscribe to events](https://github.com/Azure-Samples/IoTMQTTSample/tree/master/mosquitto_pub#subscribe-to-events) subscribes to and displays events occurring in an IoT hub.

+ For more information about how to generate SAS tokens, see the [Use SAS tokens as a device](iot-hub-dev-guide-sas.md#use-sas-tokens-as-a-device) section of [Control access to IoT Hub using Shared Access Signatures](iot-hub-dev-guide-sas.md).

+ You can also use the cross-platform Azure IoT Tools for Visual Studio Code or the CLI extension command [az iot hub generate-sas-token](/cli/azure/iot/hub#az-iot-hub-generate-sas-token) to quickly generate a SAS token. You can then copy and paste the SAS token into your own code for testing purposes.

+You can connect to IoT Hub over MQTT using a module identity, similar to connecting to IoT Hub as a device. For more information about connecting to IoT Hub over MQTT as a device, see [Using the MQTT protocol directly (as a device)](#using-the-mqtt-protocol-directly-as-a-device). However, you need to use the following values:

+The following example demonstrates how to implement this configuration, by using the Python version of the [Paho MQTT library](https://pypi.python.org/pypi/paho-mqtt) by the Eclipse Foundation.

+Then, implement the client in a Python script. Replace these placeholders in the following code snippet:

+To authenticate using a device certificate, update the previous code snippet with the changes specified in the following code snippet. For more information about how to prepare for certificate-based authentication, see the [Get an X.509 CA certificate](./iot-hub-x509ca-overview.md#get-an-x509-ca-certificate) section of [Authenticate devices using X.509 CA certificates](./iot-hub-x509ca-overview.md).

+After a device connects, it can send messages to IoT Hub using `devices/{device-id}/messages/events/` or `devices/{device-id}/messages/events/{property-bag}` as a **Topic Name**. The `{property-bag}` element enables the device to send messages with other properties in a url-encoded format. For example:

+> If you're routing D2C messages to an Azure Storage account and you want to leverage JSON encoding, you must specify the Content Type and Content Encoding information, including `$.ct=application%2Fjson&$.ce=utf-8`, as part of the `{property_bag}` mentioned in the previous note.

+> The format of these attributes are protocol-specific. IoT Hub translates these attributes into their corresponding system properties. For more information, see the [System properties](./iot-hub-devguide-routing-query-syntax.md#system-properties) section of [IoT Hub message routing query syntax](./iot-hub-devguide-routing-query-syntax.md#system-properties).

+The following list describes IoT Hub implementation-specific behaviors:

+* To route messages based on message body, you must first add property 'contentType' (`ct`) to the end of the MQTT topic and set its value to be `application/json;charset=utf-8` as shown in the following example. For more information about routing messages either based on message properties or message body, see the [IoT Hub message routing query syntax documentation](iot-hub-devguide-routing-query-syntax.md).

+For more information, see [Send device-to-cloud and cloud-to-device messages with IoT Hub](iot-hub-devguide-messaging.md).

+To receive messages from IoT Hub, a device should subscribe using `devices/{device-id}/messages/devicebound/#` as a **Topic Filter**. The multi-level wildcard `#` in the Topic Filter is used only to allow the device to receive more properties in the topic name. IoT Hub doesn't allow the usage of the `#` or `?` wildcards for filtering of subtopics. Since IoT Hub isn't a general-purpose pub-sub messaging broker, it only supports the documented topic names and topic filters.

+The device doesn't receive any messages from IoT Hub until it has successfully subscribed to its device-specific endpoint, represented by the `devices/{device-id}/messages/devicebound/#` topic filter. After a subscription has been established, the device receives cloud-to-device messages that were sent to it after the time of the subscription. If the device connects with **CleanSession** flag set to **0**, the subscription is persisted across different sessions. In this case, the next time the device connects with **CleanSession 0** it receives any outstanding messages sent to it while disconnected. If the device uses **CleanSession** flag set to **1** though, it doesn't receive any messages from IoT Hub until it subscribes to its device-endpoint.

+IoT Hub delivers messages with the **Topic Name** `devices/{device-id}/messages/devicebound/`, or `devices/{device-id}/messages/devicebound/{property-bag}` when there are message properties. `{property-bag}` contains url-encoded key/value pairs of message properties. Only application properties and user-settable system properties (such as **messageId** or **correlationId**) are included in the property bag. System property names have the prefix **$**, application properties use the original property name with no prefix. For more information about the format of the property bag, see [Sending device-to-cloud messages](#sending-device-to-cloud-messages).

+The request ID can be any valid value for a message property value, and status is validated as an integer. For more information, see [Send device-to-cloud and cloud-to-device messages with IoT Hub](iot-hub-devguide-messaging.md).

+| 429 | Too many requests (throttled). For more information, see [IoT Hub throttling](iot-hub-devguide-quotas-throttling.md) |

+For more information, see [Understand and use device twins in IoT Hub](iot-hub-devguide-device-twins.md).

+The following Python code snippet demonstrates the twin reported properties update process over MQTT using the Paho MQTT client:

+Upon success of the twin reported properties update process in the previous code snippet, the publication message from IoT Hub will have the following topic: `$iothub/twin/res/204/?$rid=1&$version=6`, where `204` is the status code indicating success, `$rid=1` corresponds to the request ID provided by the device in the code, and `$version` corresponds to the version of reported properties section of device twins after the update.

+For more information, see [Understand and use device twins in IoT Hub](iot-hub-devguide-device-twins.md).

+For more information, see [Understand and use device twins in IoT Hub](iot-hub-devguide-device-twins.md).

+For more information, see [Understand and invoke direct methods from IoT Hub](iot-hub-devguide-direct-methods.md).

+* [Azure Certified Device Catalog](https://devicecatalog.azure.com/)

+* [How an IoT Edge device can be used as a gateway](../iot-edge/iot-edge-as-gateway.md)

+* [Connecting IoT Devices to Azure: IoT Hub and Event Hubs](iot-hub-compare-event-hubs.md)

+* [Choose the right IoT Hub tier for your solution](iot-hub-scaling.md)

+* [Azure IoT Hub concepts overview](iot-hub-devguide.md)

+* [Quickstart: Deploy your first IoT Edge module to a virtual Linux device](../iot-edge/quickstart-linux.md)

+> For more information about the SDK tools available to build both device and back-end apps, see [Azure IoT SDKs](iot-hub-devguide-sdks.md).

+## Create a service app that updates desired properties and queries twins

+In this section, you create a Python console app that adds location metadata to the device twin associated with your **{Device ID}**. The app queries IoT hub for devices located in the US and then queries devices that report a cellular network connection.

+1. In your working directory, open a command prompt and install the **Azure IoT Hub Service SDK for Python**.

+ ```cmd/sh

+ pip install azure-iot-hub

+ ```

+2. Using a text editor, create a new **AddTagsAndQuery.py** file.

+3. Add the following code to import the required modules from the service SDK:

+ ```python

+ import sys

+ from time import sleep

+ from azure.iot.hub import IoTHubRegistryManager

+ from azure.iot.hub.models import Twin, TwinProperties, QuerySpecification, QueryResult

+ ```

+4. Add the following code. Replace `[IoTHub Connection String]` with the IoT hub connection string you copied in [Get the IoT hub connection string](#get-the-iot-hub-connection-string). Replace `[Device Id]` with the device ID (the name) from your registered device in the IoT Hub.

+

+ ```python

+ IOTHUB_CONNECTION_STRING = "[IoTHub Connection String]"

+ DEVICE_ID = "[Device Id]"

+ ```

+5. Add the following code to the **AddTagsAndQuery.py** file:

+ ```python

+ def iothub_service_sample_run():

+ try:

+ iothub_registry_manager = IoTHubRegistryManager(IOTHUB_CONNECTION_STRING)

+ new_tags = {

+ 'location' : {

+ 'region' : 'US',

+ 'plant' : 'Redmond43'

+ }

+ }

+ twin = iothub_registry_manager.get_twin(DEVICE_ID)

+ twin_patch = Twin(tags=new_tags, properties= TwinProperties(desired={'power_level' : 1}))

+ twin = iothub_registry_manager.update_twin(DEVICE_ID, twin_patch, twin.etag)

+ # Add a delay to account for any latency before executing the query

+ sleep(1)

+ query_spec = QuerySpecification(query="SELECT * FROM devices WHERE tags.location.plant = 'Redmond43'")

+ query_result = iothub_registry_manager.query_iot_hub(query_spec, None, 100)

+ print("Devices in Redmond43 plant: {}".format(', '.join([twin.device_id for twin in query_result.items])))

+ print()

+ query_spec = QuerySpecification(query="SELECT * FROM devices WHERE tags.location.plant = 'Redmond43' AND properties.reported.connectivity = 'cellular'")

+ query_result = iothub_registry_manager.query_iot_hub(query_spec, None, 100)

+ print("Devices in Redmond43 plant using cellular network: {}".format(', '.join([twin.device_id for twin in query_result.items])))

+ except Exception as ex:

+ print("Unexpected error {0}".format(ex))

+ return

+ except KeyboardInterrupt:

+ print("IoT Hub Device Twin service sample stopped")

+ ```

+ The **IoTHubRegistryManager** object exposes all the methods required to interact with device twins from the service. The code first initializes the **IoTHubRegistryManager** object, then updates the device twin for **DEVICE_ID**, and finally runs two queries. The first selects only the device twins of devices located in the **Redmond43** plant, and the second refines the query to select only the devices that are also connected through a cellular network.

+6. Add the following code at the end of **AddTagsAndQuery.py** to implement the **iothub_service_sample_run** function:

+ ```python

+ if __name__ == '__main__':

+ print("Starting the Python IoT Hub Device Twin service sample...")

+ print()

+ iothub_service_sample_run()

+ ```

+7. Run the application with:

+ ```cmd/sh

+ python AddTagsAndQuery.py

+ ```

+ You should see one device in the results for the query asking for all devices located in **Redmond43** and none for the query that restricts the results to devices that use a cellular network. In the next section, you'll create a device app that will use a cellular network and you'll rerun this query to see how it changes.

+ 

+X.509 certificates are digital documents that represent a user, computer, service, or device. They're issued by a certification authority (CA), subordinate CA, or registration authority and contain the public key of the certificate subject. They don't contain the subject's private key, which must be stored securely. Public key certificates are documented by [RFC 5280](https://tools.ietf.org/html/rfc5280). They're digitally signed and, in general, contain the following information:

+* **Authority Key Identifier**: This extension can be set to one of two values:

+* **Key Usage** Defines the service for which a certificate can be used. This extension can be set to one or more of the following values:

+* **Basic Constraints**: Allows the certificate to designate whether it's issued to a CA, or to a user, computer, device, or service. This extension also includes a path length constraint that limits the number of subordinate CAs that can exist.

+* **Subject Information Access**: Contains information about how to retrieve more details for a certificate subject

+Certificates can be saved in various formats. Azure IoT Hub authentication typically uses the Privacy-Enhanced Mail (PEM) and Personal Information Exchange (PFX) formats.

+A raw form binary certificate using Distinguished Encoding Rules (DER) ASN.1 encoding.

+A PEM certificate (.pem) file contains a Base64-encoded certificate beginning with `--BEGIN CERTIFICATE--` and ending with `--END CERTIFICATE--`. One of the most common formats for X.509 certificates, PEM format is required by IoT Hub when uploading certain certificates.

+### ASCII PEM key

+Contains a Base64-encoded DER key, optionally with more metadata about the algorithm used for password protection.

+### PKCS #7 certificate

+A format designed for the transport of signed or encrypted data. It's defined by [RFC 2315](https://tools.ietf.org/html/rfc2315). It can include the entire certificate chain.

+### PKCS #8 key

+### PKCS #12 key and certificate

+A complex format that can store and protect a key and the entire certificate chain. It's commonly used with a .pfx extension. PKCS #12 is synonymous with the PFX format.

+For more information, see the following articles:

+* [Understand how X.509 CA certificates are used in IoT](./iot-hub-x509ca-concept.md)

+If you want to generate test certificates that you can use to authenticate devices to your IoT Hub, see the following articles:

+* [Tutorial: Using Microsoft-supplied scripts to create test certificates](tutorial-x509-scripts.md)

+* [Tutorial: Using OpenSSL to create test certificates](tutorial-x509-openssl.md)

+* [Tutorial: Using OpenSSL to create self-signed certificates](tutorial-x509-self-sign.md)

+If you have a certification authority (CA) certificate or subordinate CA certificate and you want to upload it to your IoT hub and prove that you own it, see [Tutorial: Proving possession of a CA certificate](tutorial-x509-prove-possession.md).

+You can authenticate a device to your IoT hub using two self-signed device certificates. This type of authentication is sometimes called *thumbprint authentication* because the certificates contain thumbprints (hash values) that you submit to the IoT hub. The following steps show you how to create two self-signed certificates. This type of certificate is typically used for testing.

+Email Address []:.

+Please enter the following 'extra' attributes

+to be sent with your certificate request

+A challenge password []:.

+An optional company name []:.

+Email Address []:.

+Please enter the following 'extra' attributes

+to be sent with your certificate request

+A challenge password []:.

+An optional company name []:.

+Navigate to your IoT hub in the Azure portal and create a new IoT device identity with the following characteristics:

+Go to [Testing Certificate Authentication](tutorial-x509-test-certificate.md) to determine if your certificate can authenticate your device to your IoT hub. The code on that page requires that you use a PFX certificate. Use the following OpenSSL command to convert your device .crt certificate to .pfx format.

+ Title: 'Quickstart - Create an automated workflow using the Azure portal'

+description: Create your first automated integration workflow running in multi-tenant Azure Logic Apps using the Azure portal.

+# Quickstart: Create an integration workflow in multi-tenant Azure Logic Apps using the Azure portal

+This quickstart shows how to create an example automated workflow that integrates two services, an RSS feed for a website and an email account. More specifically, you'll create a [Consumption](logic-apps-pricing.md#consumption-pricing) logic app resource and workflow that runs in [global, multi-tenant Azure Logic Apps](logic-apps-overview.md#create-and-deploy-to-different-environments).

+>

+> To create a workflow in a Standard logic app resource that runs in single-tenant Azure Logic Apps, review

+The workflow that you create uses the RSS connector and the Office 365 Outlook connector. The RSS connector provides a trigger that checks an RSS feed, based on a schedule. The Office 365 Outlook connector provides an action that sends an email for each new item. The connectors in this example are only two among the [hundreds of connectors](/connectors/connector-reference/connector-reference-logicapps-connectors) that you can use in a workflow. While this example is cloud-based, Azure Logic Apps supports workflows that connect apps, data, services, and systems across cloud, on premises, and hybrid environments.

+As you progress through this quickstart, you'll learn the following basic steps:

+To create and manage a Consumption logic app resource using other tools, review these other Azure Logic Apps quickstarts:

+* [Create and manage logic apps using the Azure CLI](quickstart-logic-apps-azure-cli.md)

+ >

+ > If you want to use the [Gmail connector](/connectors/gmail/), only G Suite accounts can use

+ > this connector without restriction in Azure Logic Apps. If you have a consumer Gmail account,

+ > you can only use this connector with specific Google-approved services, unless you

+ > [create a Google client app to use for authentication with your Gmail connector](/connectors/gmail/#authentication-and-bring-your-own-application). For more information, see

+ > [Data security and privacy policies for Google connectors in Azure Logic Apps](../connectors/connectors-google-data-security-privacy-policy.md).

+* If you have a firewall that limits traffic to specific IP addresses, make sure that you set up your firewall to allow access for both the [inbound](logic-apps-limits-and-config.md#inbound) and [outbound](logic-apps-limits-and-config.md#outbound) IP addresses used by Azure Logic Apps in the Azure region where you create your logic app workflow.

+ This example uses the RSS and Office 365 Outlook connectors, which are [managed by Microsoft](../connectors/managed.md). These connectors require that you set up your firewall to allow access for all the [managed connector outbound IP addresses](/connectors/common/outbound-ip-addresses) in the Azure region for your logic app resource.

+1. In the Azure search box, enter **logic apps**, and select **Logic apps**.

+ 

+ 

+1. On the **Create Logic App** pane, make sure that you first choose the plan type for your logic app resource.

+ Go to the **Plan** section, and then for the **Plan type**, select **Consumption**, which shows only the settings for a Consumption logic app resource. The **Plan type** property specifies the logic app resource type and billing model to use.

+ | **Standard** | This logic app type is the default selection, which runs in single-tenant Azure Logic Apps and uses the [Standard billing model](logic-apps-pricing.md#standard-pricing). |

+1. Now provide the following information for your logic app resource:

+ | **Subscription** | Yes | <*Azure-subscription-name*> | Your Azure subscription name. |

+ | **Resource Group** | Yes | <*Azure-resource-group-name*> | The [Azure resource group](../azure-resource-manager/management/overview.md#terminology) where you create your logic app and related resources. This name must be unique across regions and can contain only letters, numbers, hyphens (**-**), underscores (**_**), parentheses (**()**), and periods (**.**). <br><br>This example creates a resource group named **My-First-LA-RG**. |

+ | **Logic App name** | Yes | <*logic-app-name*> | Your logic app name, which must be unique across regions and can contain only letters, numbers, hyphens (`-`), underscores (`_`), parentheses (`(`, `)`), and periods (`.`). <br><br>This example creates a logic app named **My-First-Logic-App**. |

+ | **Region** | Yes | <*Azure-region*> | The Azure datacenter region for storing your app's information. This example deploys the sample logic app to the **West US** region in Azure. |

+ | **Enable log analytics** | Yes | **No** | This option appears and applies only when you select the **Consumption** logic app type. <br><br>Change this option only when you want to enable diagnostic logging. For this quickstart, keep the default selection. |

+ > section is automatically enabled. This preview section offers the choice to enable availability zone

+ > redundancy for your logic app. However, currently supported Azure regions don't include **West US**,

+1. In the designer search box, enter **rss**. From the **Triggers** list, select the RSS trigger named **When a feed item is published**.

+ 

+1. For the trigger, provide the following information:

+ | **The RSS feed URL** | Yes | <*RSS-feed-URL*> | The RSS feed URL to monitor. <br><br>This example uses the Wall Street Journal's RSS feed at **https://feeds.a.dj.com/rss/RSSMarketsMain.xml**. However, you can use any RSS feed that doesn't require HTTP authorization. Choose an RSS feed that publishes frequently, so you can easily test your workflow. |

+ | **Chosen property will be used to determine** | No | **PublishDate** | The property that determines which items are new. |

+ | **Interval** | Yes | **1** | The number of intervals to wait between feed checks. <br><br>This example uses **1** as the interval. |

+ | **Frequency** | Yes | **Minute** | The unit of frequency to use for every interval. <br><br>This example uses **Minute** as the frequency. |

+Following a trigger, an [action](logic-apps-overview.md#logic-app-concepts) is any subsequent step that runs some operation in the workflow. Any action can use the outputs from the previous step, which can be the trigger or another action. You can choose from many different actions, add multiple actions up to the [limit per workflow](logic-apps-limits-and-config.md#definition-limits), and even create different action paths.

+ >

+ >

+ > This example shows manual authentication for connecting to Office 365 Outlook. However,

+ > other services might support or use different authentication types. Based on your scenario,

+ > you can handle connection authentication in various ways.

+ > For example, if you use use Azure Resource Manager templates for deployment, you can increase

+ > security on inputs that change often by parameterizing values such as connection details.

+ > For more information, review the following documentation:

+ >

+ >

+To check that the workflow runs correctly, you can wait for the trigger to check the RSS feed based on the set schedule. Or, you can manually run the workflow from the designer toolbar.

+* Open the **Run Trigger** menu, and select **Run**.

+ 

+### Example notebooks

+* [Training and tracking an XGBoost classifier with MLflow](https://github.com/Azure/azureml-examples/blob/main/sdk/python/using-mlflow/train-with-mlflow/xgboost_classification_mlflow.ipynb): Demonstrates how to track experiments by using MLflow, log models, and combine multiple flavors into pipelines.

+* [Training and tracking an XGBoost classifier with MLflow using service principal authentication](https://github.com/Azure/azureml-examples/blob/main/sdk/python/using-mlflow/train-with-mlflow/xgboost_service_principal.ipynb): Demonstrates how to track experiments by using MLflow from compute that's running outside Azure Machine Learning. It shows how to authenticate against Azure Machine Learning services by using a service principal.

+* [Hyper-parameter optimization using Hyperopt and nested runs in MLflow](https://github.com/Azure/azureml-examples/blob/main/sdk/python/using-mlflow/train-with-mlflow/xgboost_nested_runs.ipynb): Demonstrates how to use child runs in MLflow to do hyper-parameter optimization for models by using the popular library Hyperopt. It shows how to transfer metrics, parameters, and artifacts from child runs to parent runs.

+* [Logging models with MLflow](https://github.com/Azure/azureml-examples/blob/main/sdk/python/using-mlflow/logging-models/logging_model_with_mlflow.ipynb): Demonstrates how to use the concept of models instead of artifacts with MLflow, including how to construct custom models.

+* [Manage runs and experiments with MLflow](https://github.com/Azure/azureml-examples/blob/main/sdk/python/using-mlflow/run-history/run_history.ipynb): Demonstrates how to query experiments, runs, metrics, parameters, and artifacts from Azure Machine Learning by using MLflow.

+### Example notebooks

+* [Manage model registries with MLflow](https://github.com/Azure/azureml-examples/blob/main/sdk/python/using-mlflow/model-management/model_management.ipynb): Demonstrates how to manage models in registries by using MLflow.

+### Example notebooks

+* [Deploy MLflow to Online Endpoints](https://github.com/Azure/azureml-examples/blob/main/sdk/python/using-mlflow/deploy/mlflow_sdk_online_endpoints.ipynb): Demonstrates how to deploy models in MLflow format to online endpoints using MLflow SDK.

+* [Deploy MLflow to Online Endpoints with safe rollout](https://github.com/Azure/azureml-examples/blob/main/sdk/python/using-mlflow/deploy/mlflow_sdk_online_endpoints_progressive.ipynb): Demonstrates how to deploy models in MLflow format to online endpoints using MLflow SDK with progressive rollout of models and the deployment of multiple model's versions in the same endpoint.

+* [Deploy MLflow to web services (V1)](https://github.com/Azure/azureml-examples/blob/main/sdk/python/using-mlflow/deploy/mlflow_sdk_web_service.ipynb): Demonstrates how to deploy models in MLflow format to web services (ACI/AKS v1) using MLflow SDK.

+* [Deploying models trained in Azure Databricks to Azure Machine Learning with MLflow](https://github.com/Azure/azureml-examples/blob/main/sdk/python/using-mlflow/no-code-deployment/track_with_databricks_deploy_aml.ipynb): Demonstrates how to train models in Azure Databricks and deploy them in Azure ML. It also includes how to handle cases where you also want to track the experiments with the MLflow instance in Azure Databricks.

+### Example notebooks

+* [Train an MLflow project on a local compute](https://github.com/Azure/MachineLearningNotebooks/blob/master/how-to-use-azureml/track-and-monitor-experiments/using-mlflow/train-projects-local/train-projects-local.ipynb)

+* [Train an MLflow project on remote compute](https://github.com/Azure/MachineLearningNotebooks/blob/master/how-to-use-azureml/track-and-monitor-experiments/using-mlflow/train-projects-remote/train-projects-remote.ipynb).

+ - Archive operation on data assets in the Studio requires the following RBAC operation: Microsoft.MachineLearningServices/workspaces/datasets/registered/delete

+The model is based on the [UCI Heart Disease Data Set](https://archive.ics.uci.edu/ml/datasets/Heart+Disease). The database contains 76 attributes, but we are using a subset of 14 of them. The model tries to predict the presence of heart disease in a patient. It is integer valued from 0 (no presence) to 1 (presence). It has been trained using an `XGBBoost` classifier and all the required preprocessing has been packaged as a `scikit-learn` pipeline, making this model an end-to-end pipeline that goes from raw data to predictions.

+The information in this article is based on code samples contained in the [azureml-examples](https://github.com/azure/azureml-examples) repository. To run the commands locally without having to copy/paste files, clone the repo, and then change directories to `sdk/using-mlflow/deploy`.

+- You must have a MLflow model registered in your workspace. Particularly, this example will register a model trained for the [Diabetes dataset](https://www4.stat.ncsu.edu/~boos/var.select/diabetes.html).

+Once the tracking is configured, you'll also need to configure how the authentication needs to happen to the associated workspace. By default, the Azure Machine Learning plugin for MLflow will perform interactive authentication by opening the default browser to prompt for credentials. Refer to [Configure MLflow for Azure Machine Learning: Configure authentication](how-to-use-mlflow-configure-tracking.md#configure-authentication) to additional ways to configure authentication for MLflow in Azure Machine Learning workspaces.

+model_name = 'heart-classifier'

+model_local_path = "model"

+model_name = 'heart-classifier'

+1. Ensure the following libraries are installed in the cluster:

+ :::code language="yaml" source="~/azureml-examples-main/sdk/python/using-mlflow/deploy/model/conda.yaml" range="7-10":::

+1. We'll use a notebook to demonstrate how to create a scoring routine with an MLflow model registered in Azure Machine Learning. Create a notebook and use PySpark as the default language.

+1. Import the required namespaces:

+ ```python

+ import mlflow

+ import pyspark.sql.functions as f

+ ```

+ predict_function = mlflow.pyfunc.spark_udf(spark, model_uri, result_type='double')

+1. You can write your predictions back to storage:

+ ```python

+ scored_data_path = "dbfs:/scored-data"

+ scored_data.to_csv(scored_data_path)

+ ```

+ predict_function = mlflow.pyfunc.spark_udf(spark, args.model, env_manager="conda")

+ > [!TIP]

+ > **Installation of Python packages:** The previous scoring script loads the MLflow model into an UDF function, but it indicates the parameter `env_manager="conda"`. When this parameter is set, MLflow will restore the required packages as specified in the model definition in an isolated environment where only the UDF function runs. For more details see [`mlflow.pyfunc.spark_udf`](https://mlflow.org/docs/latest/python_api/mlflow.pyfunc.html?highlight=env_manager#mlflow.pyfunc.spark_udf) documentation.

+- Install the MLflow SDK package `mlflow` and the Azure Machine Learning plug-in for MLflow `azureml-mlflow`.

+- If you are not running in Azure Machine Learning compute, configure the MLflow tracking URI or MLflow's registry URI to point to the workspace you are working on. See [Configure MLflow for Azure Machine Learning](how-to-use-mlflow-configure-tracking.md) for more details.

+ ```yaml

+ ```pythonS

+ ```yaml

+ Title: Progressive rollout of MLflow models to Online Endpoints

+# Progressive rollout of MLflow models to Online Endpoints

+- If you are not running in Azure Machine Learning compute, configure the MLflow tracking URI or MLflow's registry URI to point to the workspace you are working on. See [Configure MLflow for Azure Machine Learning](how-to-use-mlflow-configure-tracking.md) for more details.

+ ```yaml

+ ```yaml

+ ```yaml

+Azure Machine Learning supports deploying models to both online and batch endpoints. Online Endpoints compare to [MLflow built-in server](https://www.mlflow.org/docs/latest/models.html#built-in-deployment-tools) and they provide a scalable, synchronous, and lightweight way to run models for inference. Batch Endpoints, on the other hand, provide a way to run asynchronous inference over long running inferencing processes that can scale to big amounts of data. This capability is not present by the moment in MLflow server although similar capability can be achieved [using Spark jobs](how-to-deploy-mlflow-model-spark-jobs.md).

+The rest of this section mostly applies to online endpoints but you can learn more of batch endpoint and MLflow models at [Use MLflow models in batch deployments](how-to-mlflow-batch.md).

+* If you are doing remote tracking (tracking experiments running outside Azure Machine Learning), configure MLflow to track experiments using Azure Machine Learning. See [Configure MLflow for Azure Machine Learning](how-to-use-mlflow-configure-tracking.md) for more details.

+## Support matrix for managing models with MLflow

+The MLflow client exposes several methods to retrieve and manage models. The following table shows which of those methods are currently supported in MLflow when connected to Azure ML. It also compares it with other models management capabilities in Azure ML.

+| Feature | MLflow | Azure ML with MLflow | Azure ML CLIv2 | Azure ML Studio |

+| :- | :-: | :-: | :-: | :-: |

+| Registering models in MLflow format | **&check;** | **&check;** | **&check;** | **&check;** |

+| Registering models not in MLflow format | | | **&check;** | **&check;** |

+| Registering models from runs outputs/artifacts | **&check;** | **&check;**<sup>1</sup> | **&check;**<sup>2</sup> | **&check;** |

+| Registering models from runs outputs/artifacts in a different tracking server/workspace | **&check;** | | | |

+| Listing registered models | **&check;** | **&check;** | **&check;** | **&check;** |

+| Retrieving details of registered model's versions | **&check;** | **&check;** | **&check;** | **&check;** |

+| Editing registered model's versions description | **&check;** | **&check;** | **&check;** | **&check;** |

+| Editing registered model's versions tags | **&check;** | **&check;** | **&check;** | **&check;** |

+| Renaming registered models | **&check;** | <sup>3</sup> | <sup>3</sup> | <sup>3</sup> |

+| Deleting a registered model (container) | **&check;** | <sup>3</sup> | <sup>3</sup> | <sup>3</sup> |

+| Deleting a registered model's version | **&check;** | **&check;** | **&check;** | **&check;** |

+| Manage MLflow model stages | **&check;** | **&check;** | | |

+| Search registered models by name | **&check;** | **&check;** | **&check;** | **&check;**<sup>4</sup> |

+| Search registered models using string comparators `LIKE` and `ILIKE` | **&check;** | | | **&check;**<sup>4</sup> |

+| Search registered models by tag | | | | **&check;**<sup>4</sup> |

+> [!NOTE]

+> - <sup>1</sup> Use URIs with format `runs:/<ruin-id>/<path>`.

+> - <sup>2</sup> Use URIs with format `azureml://jobs/<job-id>/outputs/artifacts/<path>`.

+> - <sup>3</sup> Registered models are immutable objects in Azure ML.

+> - <sup>4</sup> Use search box in Azure ML Studio. Partial match supported.

+## Next steps

+- [Logging MLflow models](how-to-log-mlflow-models.md)

+- [Query & compare experiments and runs with MLflow](how-to-track-experiments-mlflow.md)

+- [Guidelines for deploying MLflow models](how-to-deploy-mlflow-models.md)

+### Connect to your workspace

+First, let's connect MLflow to your Azure Machine Learning workspace.

+# [Azure Machine Learning compute](#tab/aml)

+Tracking is already configured for you. Your default credentials will also be used when working with MLflow.

+# [Remote compute](#tab/remote)

+**Configure tracking URI**

+**Configure authentication**

+Once the tracking is configured, you'll also need to configure how the authentication needs to happen to the associated workspace. By default, the Azure Machine Learning plugin for MLflow will perform interactive authentication by opening the default browser to prompt for credentials. Refer to [Configure MLflow for Azure Machine Learning: Configure authentication](how-to-use-mlflow-configure-tracking.md#configure-authentication) to additional ways to configure authentication for MLflow in Azure Machine Learning workspaces.

+**Configure tracking URI**

+1. Get the tracking URI for your workspace:

+ # [Azure CLI](#tab/cli)

+

+ [!INCLUDE [cli v2](../../includes/machine-learning-cli-v2.md)]

+

+ 1. Login and configure your workspace:

+

+ ```bash

+ az account set --subscription <subscription>

+ az configure --defaults workspace=<workspace> group=<resource-group> location=<location>

+ ```

+

+ 1. You can get the tracking URI using the `az ml workspace` command:

+

+ ```bash

+ az ml workspace show --query mlflow_tracking_uri

+ ```

+

+ # [Python](#tab/python)

+

+ [!INCLUDE [sdk v2](../../includes/machine-learning-sdk-v2.md)]

+

+ You can get the Azure ML MLflow tracking URI using the [Azure Machine Learning SDK v2 for Python](concept-v2.md). Ensure you have the library `azure-ai-ml` installed in the compute you are using. The following sample gets the unique MLFLow tracking URI associated with your workspace.

+

+ 1. Login into your workspace using the `MLClient`. The easier way to do that is by using the workspace config file:

+

+ ```python

+ from azure.ai.ml import MLClient

+ from azure.identity import DefaultAzureCredential

+

+ ml_client = MLClient.from_config(credential=DefaultAzureCredential())

+ ```

+

+ > [!TIP]

+ > You can download the workspace configuration file by:

+ > 1. Navigate to [Azure ML studio](https://ml.azure.com)

+ > 2. Click on the upper-right corner of the page -> Download config file.

+ > 3. Save the file `config.json` in the same directory where you are working on.

+

+ 1. Alternatively, you can use the subscription ID, resource group name and workspace name to get it:

+

+ ```python

+ from azure.ai.ml import MLClient

+ from azure.identity import DefaultAzureCredential

+

+ #Enter details of your AzureML workspace

+ subscription_id = '<SUBSCRIPTION_ID>'

+ resource_group = '<RESOURCE_GROUP>'

+ workspace_name = '<WORKSPACE_NAME>'

+

+ ml_client = MLClient(credential=DefaultAzureCredential(),

+ subscription_id=subscription_id,

+ resource_group_name=resource_group)

+ ```

+

+ > [!IMPORTANT]

+ > `DefaultAzureCredential` will try to pull the credentials from the available context. If you want to specify credentials in a different way, for instance using the web browser in an interactive way, you can use `InteractiveBrowserCredential` or any other method available in [`azure.identity`](https://pypi.org/project/azure-identity/) package.

+

+ 1. Get the Azure Machine Learning Tracking URI:

+

+ ```python

+ mlflow_tracking_uri = ml_client.workspaces.get(ml_client.workspace_name).mlflow_tracking_uri

+ ```

+

+ # [Studio](#tab/studio)

+

+ Use the Azure Machine Learning portal to get the tracking URI:

+

+ 1. Open the [Azure Machine Learning studio portal](https://ml.azure.com) and log in using your credentials.

+ 1. In the upper right corner, click on the name of your workspace to show the __Directory + Subscription + Workspace__ blade.

+ 1. Click on __View all properties in Azure Portal__.

+ 1. On the __Essentials__ section, you will find the property __MLflow tracking URI__.

+

+

+ # [Manually](#tab/manual)

+

+ The Azure Machine Learning Tracking URI can be constructed using the subscription ID, region of where the resource is deployed, resource group name and workspace name. The following code sample shows how:

+

+ > [!WARNING]

+ > If you are working in a private link-enabled workspace, the MLflow endpoint will also use a private link to communicate with Azure Machine Learning. As a consequence, the tracking URI will look different as proposed here. You need to get the tracking URI using the Azure ML SDK or CLI v2 on those cases.

+

+ ```python

+ region = "<LOCATION>"

+ subscription_id = '<SUBSCRIPTION_ID>'

+ resource_group = '<RESOURCE_GROUP>'

+ workspace_name = '<AML_WORKSPACE_NAME>'

+

+ mlflow_tracking_uri = f"azureml://{region}.api.azureml.ms/mlflow/v1.0/subscriptions/{subscription_id}/resourceGroups/{resource_group}/providers/Microsoft.MachineLearningServices/workspaces/{workspace_name}"

+ ```

+1. Configuring the tracking URI:

+ # [Using MLflow SDK](#tab/mlflow)

+

+ Then the method [`set_tracking_uri()`](https://mlflow.org/docs/latest/python_api/mlflow.html#mlflow.set_tracking_uri) points the MLflow tracking URI to that URI.

+

+ ```python

+ import mlflow

+

+ mlflow.set_tracking_uri(mlflow_tracking_uri)

+ ```

+

+ # [Using environment variables](#tab/environ)

+

+ You can set the MLflow environment variables [MLFLOW_TRACKING_URI](https://mlflow.org/docs/latest/tracking.html#logging-to-a-tracking-server) in your compute to make any interaction with MLflow in that compute to point by default to Azure Machine Learning.

+

+ ```bash

+ MLFLOW_TRACKING_URI=$(az ml workspace show --query mlflow_tracking_uri | sed 's/"//g')

+ ```

+

+

+ > [!TIP]

+ > When working on shared environments, like an Azure Databricks cluster, Azure Synapse Analytics cluster, or similar, it is useful to set the environment variable `MLFLOW_TRACKING_URI` at the cluster level to automatically configure the MLflow tracking URI to point to Azure Machine Learning for all the sessions running in the cluster rather than to do it on a per-session basis.

+ >

+ > 

+ >

+ > Once the environment variable is configured, any experiment running in such cluster will be tracked in Azure Machine Learning.

+**Configure authentication**

+Once the tracking is configured, you'll also need to configure how the authentication needs to happen to the associated workspace. By default, the Azure Machine Learning plugin for MLflow will perform interactive authentication by opening the default browser to prompt for credentials. Refer to [Configure MLflow for Azure Machine Learning: Configure authentication](how-to-use-mlflow-configure-tracking.md#configure-authentication) to additional ways to configure authentication for MLflow in Azure Machine Learning workspaces.

+__Configure tracking URI__

+__Configure authentication__

+Once the tracking is configured, you'll also need to configure how the authentication needs to happen to the associated workspace. By default, the Azure Machine Learning plugin for MLflow will perform interactive authentication by opening the default browser to prompt for credentials. Refer to [Configure MLflow for Azure Machine Learning: Configure authentication](how-to-use-mlflow-configure-tracking.md#configure-authentication) to additional ways to configure authentication for MLflow in Azure Machine Learning workspaces.

+description: Use MLflow to log metrics and artifacts from machine learning runs

+### Connect to your workspace

+First, let's connect to Azure Machine Learning workspace where your model is registered.

+# [Azure Machine Learning compute](#tab/aml)

+Tracking is already configured for you. Your default credentials will also be used when working with MLflow.

+# [Remote compute](#tab/remote)

+**Configure tracking URI**

+**Configure authentication**

+Once the tracking is configured, you'll also need to configure how the authentication needs to happen to the associated workspace. By default, the Azure Machine Learning plugin for MLflow will perform interactive authentication by opening the default browser to prompt for credentials. Refer to [Configure MLflow for Azure Machine Learning: Configure authentication](how-to-use-mlflow-configure-tracking.md#configure-authentication) to additional ways to configure authentication for MLflow in Azure Machine Learning workspaces.

+ Title: Configure MLflow for Azure Machine Learning

+description: Connect MLflow to Azure Machine Learning workspaces to log metrics, artifacts and deploy models.

+ms.devlang: azurecli

+# Configure MLflow for Azure Machine Learning

+Azure Machine Learning workspaces are MLflow compatible, which means they can act as an MLflow server without any extra configuration. Each workspace has an MLflow tracking URI that can be used by MLflow to connect to the workspace. In this article, learn how you can configure MLflow to connect to an Azure Machine Learning for tracking, registries, and deployment.

+> [!IMPORTANT]

+> When running on Azure Compute (Azure ML Notebooks, Jupyter notebooks hosted on Azure ML Compute Instances, or jobs running on Azure ML compute clusters) you don't have to configure the tracking URI. It's automatically configured for you.

+## Prerequisites

+You will need the following prerequisites to follow this tutorial:

+## Configure MLflow tracking URI

+To connect MLflow to an Azure Machine Learning workspace you will need the tracking URI for the workspace. Each workspace has its own tracking URI and it has the protocol `azureml://`.

+## Configure authentication

+Once the tracking is set, you'll also need to configure how the authentication needs to happen to the associated workspace. By default, the Azure Machine Learning plugin for MLflow will perform interactive authentication by opening the default browser to prompt for credentials.

+The Azure Machine Learning plugin for MLflow supports several authentication mechanisms through the package `azure-identity`, which is installed as a dependency for the plugin `azureml-mlflow`. The following authentication methods are tried one by one until one of them succeeds:

+1. __Environment__: it will read account information specified via environment variables and use it to authenticate.

+1. __Managed Identity__: If the application is deployed to an Azure host with Managed Identity enabled, it will authenticate with it.

+1. __Azure CLI__: if a user has signed in via the Azure CLI `az login` command, it will authenticate as that user.

+1. __Azure PowerShell__: if a user has signed in via Azure PowerShell's `Connect-AzAccount` command, it will authenticate as that user.

+1. __Interactive browser__: it will interactively authenticate a user via the default browser.

+> [!NOTE]

+> If you'd rather use a certificate instead of a secret, you can configure the environment variables `AZURE_CLIENT_CERTIFICATE_PATH` to the path to a `PEM` or `PKCS12` certificate file (including private key) and

+`AZURE_CLIENT_CERTIFICATE_PASSWORD` with the password of the certificate file, if any.

+## Set experiment name (optional)

+All MLflow runs are logged to the active experiment. By default, runs are logged to an experiment named `Default` that is automatically created for you. You can configure the experiment where tracking is happening.

+> [!TIP]

+> When submitting jobs using Azure ML CLI v2, you can set the experiment name using the property `experiment_name` in the YAML definition of the job. You don't have to configure it on your training script. See [YAML: display name, experiment name, description, and tags](reference-yaml-job-command.md#yaml-display-name-experiment-name-description-and-tags) for details.

+# [MLflow SDK](#tab/mlflow)

+To configure the experiment you want to work on use MLflow command [`mlflow.set_experiment()`](https://mlflow.org/docs/latest/python_api/mlflow.html#mlflow.set_experiment).

+

+```Python

+experiment_name = 'experiment_with_mlflow'

+mlflow.set_experiment(experiment_name)

+```

+# [Using environment variables](#tab/environ)

+You can also set one of the MLflow environment variables [MLFLOW_EXPERIMENT_NAME or MLFLOW_EXPERIMENT_ID](https://mlflow.org/docs/latest/cli.html#cmdoption-mlflow-run-arg-uri) with the experiment name.

+```bash

+export MLFLOW_EXPERIMENT_NAME="experiment_with_mlflow"

+```

+## Next steps

+Now that your environment is connected to your workspace in Azure Machine Learning, you can start to work with it.

+- [Track ML experiments and models with MLflow](how-to-use-mlflow-cli-runs.md)

+- [Manage models registries in Azure Machine Learning with MLflow]()

+- [Train with MLflow Projects (Preview)](how-to-train-mlflow-projects.md)

+- [Guidelines for deploying MLflow models](how-to-deploy-mlflow-models.md)

+Azure Machine Learning uses MLflow Tracking for metric logging and artifact storage for your experiments, whether you created the experiments via the Azure Machine Learning Python SDK, the Azure Machine Learning CLI, or Azure Machine Learning studio. We recommend using MLflow for tracking experiments.

+If you're migrating from SDK v1 to SDK v2, use the information in this section to understand the MLflow equivalents of SDK v1 logging APIs.

+## Why MLflow?

+MLflow, with over 13 million monthly downloads, has become the standard platform for end-to-end MLOps, enabling teams of all sizes to track, share, package and deploy any model for batch or real-time inference. By integrating with MLflow, your training code will not need to hold any specific code related to Azure Machine Learning, achieving true portability and seamless integration with other open-source platforms.

+## Prepare for migrating to MLflow

+To use MLflow tracking, you will need to install `mlflow` and `azureml-mlflow` Python packages. All Azure Machine Learning environments have these packages already available for you but you will need to include them if creating your own environment.

+```bash

+pip install mlflow azureml-mlflow

+> [!TIP]

+> You can use the [`mlflow-skinny`](https://github.com/mlflow/mlflow/blob/master/README_SKINNY.rst) which is a lightweight MLflow package without SQL storage, server, UI, or data science dependencies. This is recommended for users who primarily need the tracking and logging capabilities without importing the full suite of MLflow features including deployments.

+## Connect to your workspace

+Azure Machine Learning allows users to perform tracking in training jobs running on your workspace or running remotely (tracking experiments running outside Azure Machine Learning). If performing remote tracking, you will need to indicate the workspace you want to connect MLflow to.

+# [Azure Machine Learning compute](#tab/aml)

+You are already connected to your workspace when running on Azure Machine Learning compute.

+# [Remote compute](#tab/remote)

+**Configure tracking URI**

+**Configure authentication**

+Once the tracking is configured, you'll also need to configure how the authentication needs to happen to the associated workspace. By default, the Azure Machine Learning plugin for MLflow will perform interactive authentication by opening the default browser to prompt for credentials. Refer to [Configure MLflow for Azure Machine Learning: Configure authentication](how-to-use-mlflow-configure-tracking.md#configure-authentication) for more ways to configure authentication for MLflow in Azure Machine Learning workspaces.

+| Metric rows per metric name |1 million|

+Get started by creating an Azure Managed Grafana workspace using the Azure CLI. Creating a workspace will generate an Azure Managed Grafana instance.

+## Prerequisites

+- An Azure account for work or school and an active subscription. [Create an account for free](https://azure.microsoft.com/free).

+- The [Azure CLI](/cli/azure/install-azure-cli).

+- Minimum required role to create an instance: resource group Contributor.

+- Minimum required role to access an instance: resource group Owner.

+ >[!NOTE]

+ > If you don't meet this requirement, once you've created a new Azure Managed Grafana instance, ask a User Access Administrator, subscription Owner or resource group Owner to grant you a Grafana Admin, Grafana Editor or Grafana Viewer role on the instance.

+The CLI experience for Azure Managed Grafana is part of the `amg` extension for the Azure CLI (version 2.30.0 or higher). The extension will automatically install the first time you run the `az grafana` command.

+> [How to configure data sources for Azure Managed Grafana](./how-to-data-source-plugins-managed-identity.md)

+Get started by creating an Azure Managed Grafana workspace using the Azure portal. Creating a workspace will generate an Azure Managed Grafana instance.

+## Prerequisites

+- An Azure account for work or school and an active subscription. [Create an account for free](https://azure.microsoft.com/free).

+- Minimum required role to create an instance: resource group Contributor.

+- Minimum required role to access an instance: resource group Owner.

+ >[!NOTE]

+ > If you don't meet this requirement, once you've created a new Azure Managed Grafana instance, ask a User Access Administrator, subscription Owner or resource group Owner to grant you a Grafana Admin, Grafana Editor or Grafana Viewer role on the instance.

+> [How to configure data sources for Azure Managed Grafana](./how-to-data-source-plugins-managed-identity.md)

+Sweden | Sweden Central

+## Limitations

+For Azure Database for MySQL flexible server, the support for encryption of data at rest using customers managed key (CMK) has a limitation -

+* This feature is only supported for key vaults, which allow public access from all networks.

+ ```bash

+ log-bin=mysql-bin.log

+ ```