-In this sample tutorial, learn how to integrate [Microsoft Dynamics 365 Fraud Protection](/dynamics365/fraud-protection/overview) (DFP) with Azure Active Directory (AD) B2C.

-However, for a data source such as SQL, which is flat, not hierarchical, the DN needs to be either already present in one of the table or created from the information we provide to the ECMA Connector Host.

-This can be achieved by checking **Autogenerated** in the checkbox when configuring the genericSQL connector. When you choose DN to be autogenerated, the ECMA host will generate a DN in an LDAP format: CN=<anchorvalue>,OBJECT=<type>. This also assumes that DN is Anchor is **unchecked** in the Connectivity page.

-2. ECMA Connector Host receives the GET request and queries its internal cache to see if the user exists and has based imported. This is done using the matching attribute(s) above. If you define multiple matching attributes, the Azure AD provisioning service will send a GET request for each attribute and the ECMA host will check it's cache for a match until it finds one.

-This article lists the versions and features of Azure Active Directory Connect Provisioning Agent that have been released. The Azure AD team regularly updates the Provisioning Agent with new features and functionality. Please ensure that you do not use the same agent for on-prem provisioning and Cloud Sync / HR-driven provisioning.

-Acquire the signing key data necessary to validate the signature by using the [OpenID Connect metadata document](v2-protocols-oidc.md#fetch-the-openid-connect-metadata-document) located at:

-Apps that have claims mapping enabled must validate their token signing keys by appending `appid={client_id}` to their [OpenID Connect metadata requests](v2-protocols-oidc.md#fetch-the-openid-connect-metadata-document). Below is the format of the OpenID Connect metadata document you should use:

-The UserInfo endpoint is part of the [OpenID Connect standard](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) (OIDC), designed to return claims about the user that authenticated. For the Microsoft identity platform, the UserInfo endpoint is hosted on Microsoft Graph (https://graph.microsoft.com/oidc/userinfo).

-You can programmatically discover the UserInfo endpoint using the OpenID Connect discovery document, at `https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration`. ItΓÇÖs listed in the `userinfo_endpoint` field, and this pattern can be used across clouds to help point to the right endpoint. We do not recommend hard-coding the UserInfo endpoint in your app ΓÇô use the OIDC discovery document to find this endpoint at runtime instead.

-As part of the OpenID Connect specification, the UserInfo endpoint is often automatically called by [OIDC compliant libraries](https://openid.net/developers/certified/) to get information about the user. Without hosting such an endpoint, the Microsoft identity platform would not be standards compliant and some libraries would fail. From the [list of claims identified in the OIDC standard](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) we produce the name claims, subject claim, and email when available and consented for.

-## Consider: Use an ID Token instead

-The information available in the ID token that your app can receive is a superset of the information it can get from the UserInfo endpoint. Because you can get an ID token at the same time you get a token to call the UserInfo endpoint, we suggest that you use that ID token to get information about the user instead of calling the UserInfo endpoint. Using the ID token will eliminate one to two network requests from your application launch, reducing latency in your application.

-If you require more details about the user, you should call the [Microsoft Graph `/user` API](/graph/api/user-get) to get information like office number or job title. You can also use [optional claims](active-directory-optional-claims.md) to include additional user information in your ID and access tokens.

-UserInfo is a standard OAuth Bearer token API, called like any other Microsoft Graph API using the access token received when getting a token for Microsoft Graph. It returns a JSON response containing claims about the user.

-Use the following [OIDC permissions](v2-permissions-and-consent.md#openid-connect-scopes) to call the UserInfo API. `openid` is required, and the `profile` and `email` scopes ensure that additional information is provided in the response.

-|Permission type | Permissions |

-|:--|:|

-|Delegated (work or school account) | openid (required), profile, email |

-|Delegated (personal Microsoft account) | openid (required), profile, email |

-|Application | Not applicable |

-> Copy this URL in your browser to get a token for the UserInfo endpoint as well as an [ID token](id-tokens.md) and replace the client ID and redirect URI with your own. Note that it only requests scopes for OpenID or Graph scopes, and nothing else. This is required, since you cannot request permissions for two different resources in the same token request.

-> You can use this access token in the next section.

-As with any other Microsoft Graph token, the token you receive here may not be a JWT. If you signed in a Microsoft account user, it will be an encrypted token format. This is because Microsoft Graph has a special token issuance pattern. This does not impact your ability to use the access token to call the UserInfo endpoint.

-The UserInfo API supports both GET and POST, per the OIDC spec.

-The claims listed here are all of the claims that the UserInfo endpoint can return. These are the same values that the app would see in the [ID token](id-tokens.md) issued to the app.

-* If you want to call this UserInfo endpoint you must use the v2.0 endpoint. If you use the v1.0 endpoint you will get a token for the v1.0 UserInfo endpoint, hosted on login.microsoftonline.com. We recommend that all OIDC compliant apps and libraries use the v2.0 endpoint to ensure compatibility.

-* The response from the UserInfo endpoint cannot be customized. If youΓÇÖd like to customize claims, please use [claims mapping]( active-directory-claims-mapping.md) to edit the information returned in the tokens.

-* The response from the UserInfo endpoint cannot be added to. If youΓÇÖd like to get additional claims about the user, please use [optional claims]( active-directory-optional-claims.md) to add new claims to the tokens.

-* [Review the contents of ID tokens](id-tokens.md)

-* [Customize the contents of an ID token using optional claims](active-directory-optional-claims.md)

-* [Request an access token and ID token using the OAuth2 protocol](v2-protocols-oidc.md)

-description: Build web applications by using the Microsoft identity platform implementation of the OpenID Connect authentication protocol.

-# Microsoft identity platform and OpenID Connect protocol

-OpenID Connect (OIDC) is an authentication protocol built on OAuth 2.0 that you can use to securely sign in a user to an application. When you use the Microsoft identity platform's implementation of OpenID Connect, you can add sign-in and API access to your apps. This article shows how to do this independent of language and describes how to send and receive HTTP messages without using any [Microsoft open-source libraries](reference-v2-libraries.md).

-[OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html) extends the OAuth 2.0 *authorization* protocol for use as an *authentication* protocol, so that you can do single sign-on using OAuth. OpenID Connect introduces the concept of an *ID token*, which is a security token that allows the client to verify the identity of the user. The ID token also gets basic profile information about the user. It also introduces the [UserInfo endpoint](userinfo.md), an API that returns information about the user.

-## Protocol diagram: Sign-in

-The most basic sign-in flow has the steps shown in the next diagram. Each step is described in detail in this article.

-

-## Fetch the OpenID Connect metadata document

-OpenID Connect describes a metadata document [(RFC)](https://openid.net/specs/openid-connect-discovery-1_0.html) that contains most of the information required for an app to do sign in. This includes information such as the URLs to use and the location of the service's public signing keys. You can find this document by appending the discovery document path to the authority URL:

-Discovery document path: `/.well-known/openid-configuration`

-Authority: `https://login.microsoftonline.com/{tenant}/v2.0`

-The `{tenant}` can take one of four values:

-| `8eaef023-2b34-4da1-9baa-8bc8c9d6a490` or `contoso.onmicrosoft.com` | Only users from a specific Azure AD tenant (whether they are members in the directory with a work or school account, or they are guests in the directory with a personal Microsoft account) can sign in to the application. Either the friendly domain name of the Azure AD tenant or the tenant's GUID identifier can be used. You can also use the consumer tenant, `9188040d-6c67-4c5b-b112-36a304b66dad`, in place of the `consumers` tenant. |

-The authority differs across national clouds - e.g. `https://login.microsoftonline.de` for the Azure AD Germany instance. If you do not use the public cloud, please review the [national cloud endpoints](authentication-national-cloud.md#azure-ad-authentication-endpoints) to find the appropriate one for you. Ensure that the tenant and `/v2.0/` are present in your request so you can use the v2.0 version of the endpoint.

-> [!TIP]

-> Try it! Click [https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration](https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration) to see the `common` configuration.

-To call the userinfo endpoint for the common authority on the public cloud, use the following:

-The metadata is a simple JavaScript Object Notation (JSON) document. See the following snippet for an example. The contents are fully described in the [OpenID Connect specification](https://openid.net/specs/openid-connect-discovery-1_0.html#rfc.section.4.2).

-If your app has custom signing keys as a result of using the [claims-mapping](active-directory-claims-mapping.md) feature, you must append an `appid` query parameter containing the app ID in order to get a `jwks_uri` pointing to your app's signing key information. For example: `https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391e` contains a `jwks_uri` of `https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391e`.

-Typically, you would use this metadata document to configure an OpenID Connect library or SDK; the library would use the metadata to do its work. However, if you're not using a pre-built OpenID Connect library, you can follow the steps in the remainder of this article to do sign-in in a web app by using the Microsoft identity platform.

-When your web app needs to authenticate the user, it can direct the user to the `/authorize` endpoint. This request is similar to the first leg of the [OAuth 2.0 authorization code flow](v2-oauth2-auth-code-flow.md), with these important distinctions:

-* The request must include the `openid` scope in the `scope` parameter.

-* The `response_type` parameter must include `id_token`.

-* The request must include the `nonce` parameter.

-> [!IMPORTANT]

-> In order to successfully request an ID token from the /authorization endpoint, the app registration in the [registration portal](https://portal.azure.com) must have the implicit grant of id_tokens enabled in the Authentication tab (which sets the `oauth2AllowIdTokenImplicitFlow` flag in the [application manifest](reference-app-manifest.md) to `true`). If it isn't enabled, an `unsupported_response` error will be returned: "The provided value for the input parameter 'response_type' isn't allowed for this client. Expected value is 'code'"

-For example:

-// Line breaks are for legibility only.

-| `nonce` | Required | A value included in the request, generated by the app, that will be included in the resulting id_token value as a claim. The app can verify this value to mitigate token replay attacks. The value typically is a randomized, unique string that can be used to identify the origin of the request. |

-| `prompt` | Optional | Indicates the type of user interaction that is required. The only valid values at this time are `login`, `none`, `consent`, and `select_account`. The `prompt=login` claim forces the user to enter their credentials on that request, which negates single sign-on. The `prompt=none` parameter is the opposite, and should be paired with a `login_hint` to indicate which user must be signed in. These parameters ensure that the user isn't presented with any interactive prompt at all. If the request can't be completed silently via single sign-on (because no user is signed in, the hinted user isn't signed in, or there are multiple users signed in and no hint is provided), the Microsoft identity platform returns an error. The `prompt=consent` claim triggers the OAuth consent dialog after the user signs in. The dialog asks the user to grant permissions to the app. Finally, `select_account` shows the user an account selector, negating silent SSO but allowing the user to pick which account they intend to sign in with, without requiring credential entry. You cannot use `login_hint` and `select_account` together.|

-A successful response when you use `response_mode=form_post` looks like this:

-| `id_token` | The ID token that the app requested. You can use the `id_token` parameter to verify the user's identity and begin a session with the user. For more information about ID tokens and their contents, see the [`id_tokens` reference](id-tokens.md). |

-Error responses might also be sent to the redirect URI so that the app can handle them. An error response looks like this:

-| `invalid_request` | Protocol error, such as a missing, required parameter. |Fix and resubmit the request. This is a development error that typically is caught during initial testing. |

-| `unauthorized_client` | The client application can't request an authorization code. |This usually occurs when the client application isn't registered in Azure AD or isn't added to the user's Azure AD tenant. The application can prompt the user with instructions to install the application and add it to Azure AD. |

-| `unsupported_response_type` |The authorization server does not support the response type in the request. |Fix and resubmit the request. This is a development error that typically is caught during initial testing. |

-| `invalid_resource` | The target resource is invalid because either it does not exist, Azure AD can't find it, or it isn't correctly configured. |This indicates that the resource, if it exists, hasn't been configured in the tenant. The application can prompt the user with instructions for installing the application and adding it to Azure AD. |

-Just receiving an id_token isn't always sufficient to authenticate the user; you may also need to validate the id_token's signature and verify the claims in the token per your app's requirements. Like all OIDC platforms, the Microsoft identity platform uses [JSON Web Tokens (JWTs)](https://tools.ietf.org/html/rfc7519) and public key cryptography to sign ID tokens and verify that they're valid.

-Not all apps benefit from verifying the ID token - native apps and single page apps, for instance, rarely benefit from validating the ID token. Someone with physical access to the device (or browser) can bypass the validation in many ways - from editing the web traffic to the device to provide fake tokens and keys to simply debugging the application to skip the validation logic. On the other hand, web apps and APIs using an ID token to authorization must validate the ID token carefully since they are gating access to data.

-Once you've validated the signature of the id_token, there are a few claims you'll be required to verify. See the [`id_token` reference](id-tokens.md) for more information, including [Validating Tokens](id-tokens.md#validating-an-id-token) and [Important Information About Signing Key Rollover](active-directory-signing-key-rollover.md). We recommend making use of a library for parsing and validating tokens - there is at least one available for most languages and platforms.

-You may also wish to validate additional claims depending on your scenario. Some common validations include:

-Once you have validated the id_token, you can begin a session with the user and use the claims in the id_token to obtain information about the user in your app. This information can be used for display, records, personalization, etc.

-Many web apps need to not only sign the user in, but also to access a web service on behalf of the user by using OAuth. This scenario combines OpenID Connect for user authentication while simultaneously getting an authorization code that you can use to get access tokens if you are using the OAuth authorization code flow.

-The full OpenID Connect sign-in and token acquisition flow looks similar to the next diagram. We describe each step in detail in the next sections of the article.

-## Get an access token to call UserInfo

-To acquire a token for the OIDC UserInfo endpoint, modify the sign-in request:

-client_id=6731de76-14a6-49ae-97bc-6eba6914391e // Your registered Application ID

-&response_type=id_token%20token // this will return both an id_token and an access token

-&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F // Your registered redirect URI, URL encoded

-&scope=openid+profile+email // `openid` is required. `profile` and `email` provide additional information in the UserInfo endpoint the same way they do in an ID token.

-&state=12345 // Any value, provided by your app

-&nonce=678910 // Any value, provided by your app

-You can also use the [authorization code flow](v2-oauth2-auth-code-flow.md), the [device code flow](v2-oauth2-device-code.md), or a [refresh token](v2-oauth2-auth-code-flow.md#refresh-the-access-token) in place of `response_type=token` to get a token for your app.

-A successful response from using `response_mode=form_post` looks like this:

-| `scope` | The permissions granted on the access token. Note that since the UserInfo endpoint is hosted on MS Graph, there may be additional Graph scopes listed here (e.g. user.read) if they were previously granted to the app. That's because a token for a given resource always includes every permission currently granted to the client. |

-| `id_token` | The ID token that the app requested. You can use the ID token to verify the user's identity and begin a session with the user. You'll find more details about ID tokens and their contents in the [`id_tokens` reference](id-tokens.md). |

-Error responses might also be sent to the redirect URI so that the app can handle them appropriately. An error response looks like this:

-When you want to sign out the user from your app, it isn't sufficient to clear your app's cookies or otherwise end the user's session. You must also redirect the user to the Microsoft identity platform to sign out. If you don't do this, the user reauthenticates to your app without entering their credentials again, because they will have a valid single sign-in session with the Microsoft identity platform.

-You can redirect the user to the `end_session_endpoint` (which supports both HTTP GET and POST requests) listed in the OpenID Connect metadata document:

-| `logout_hint` | Optional | Enables sign-out to occur without prompting the user to select an account. To use `logout_hint`, enable the `login_hint` [optional claim](active-directory-optional-claims.md) in your client application and use the value of the `login_hint` optional claim as the `logout_hint` parameter. Do not use UPNs or phone numbers as the value of the `logout_hint` parameter.

-* Review the [UserInfo documentation](userinfo.md)

-* Learn how to [customize the values in a token](active-directory-claims-mapping.md) with data from your on-premises systems.

-* Learn how to [include additional standard claims in tokens](active-directory-optional-claims.md).

- ```JSON

- {

- "attestations": {

- "idTokenHints": [

- {

- "mapping": [

- {

- "outputClaim": "firstName",

- "required": true,

- "inputClaim": "$.given_name",

- "indexed": false

- },

- "outputClaim": "lastName",

- "required": true,

- "inputClaim": "$.family_name",

- "indexed": false

- "required": false

- ],

- "validityInterval": 2592000,

- "vc": {

- "type": [

- "VerifiedCredentialExpert"

- ]

- }

- }

- ```

-Azure NPM for Linux uses Linux *IPTables* and Azure NPM for Windows uses *Host Network Service (HNS) ACLPolicies* to enforce the specified policies. Policies are translated into sets of allowed and disallowed IP pairs. These pairs are then programmed as IPTable/HNS ACLPolicy filter rules.

-| Supported platforms | Linux, Windows Server 2022 | Linux, Windows Server 2019 and 2022 |

-## Limitations:

-Azure Network Policy Manager(NPM) does not support IPv6. Otherwise, Azure NPM fully supports the network policy spec in Linux.

-* In Windows, Azure NPM does not support the following:

- * named ports

- * SCTP protocol

- * negative match label or namespace selectors (e.g. all labels except "debug=true")

- * "except" CIDR blocks (a CIDR with exceptions)

->[!NOTE]

-> * Azure NPM pod logs will record an error if an unsupported policy is created.

-### Create an AKS cluster with Azure NPM enabled - Linux only

-### Create an AKS cluster with Azure NPM enabled - Windows Server 2022 (Preview)

-In this section, we will work on creating a cluster with Windows node pools and Azure NPM enabled.

-Please execute the following commands prior to creating a cluster:

-```azurecli

- az extension add --name aks-preview

- az extension update --name aks-preview

- az feature register --namespace Microsoft.ContainerService --name AKSWindows2022Preview

- az feature register --namespace Microsoft.ContainerService --name WindowsNetworkPolicyPreview

- az provider register -n Microsoft.ContainerService

-```

-> [!NOTE]

-> At this time, Azure NPM with Windows nodes is available on Windows Server 2022 only

->

-Now, you should replace the values for *$RESOURCE_GROUP_NAME*, *$CLUSTER_NAME* and *$WINDOWS_USERNAME* variables.

-```azurecli-interactive

-$RESOURCE_GROUP_NAME=myResourceGroup-NP

-$CLUSTER_NAME=myAKSCluster

-$WINDOWS_USERNAME=myWindowsUserName

-$LOCATION=canadaeast

-```

-Create a username to use as administrator credentials for your Windows Server containers on your cluster. The following command prompts you for a username. Set it to `$WINDOWS_USERNAME`(remember that the commands in this article are entered into a BASH shell).

-```azurecli-interactive

-echo "Please enter the username to use as administrator credentials for Windows Server containers on your cluster: " && read WINDOWS_USERNAME

-```

-Use the following command to create a cluster :

-```azurecli

-az aks create \

- --resource-group $RESOURCE_GROUP_NAME \

- --name $CLUSTER_NAME \

- --node-count 1 \

- --windows-admin-username $WINDOWS_USERNAME \

- --network-plugin azure \

- --network-policy azure

-```

-It takes a few minutes to create the cluster. By default, your cluster is created with only a Linux node pool. If you would like to use Windows node pools, you can add one. For example:

-```azurecli

-az aks nodepool add \

- --resource-group $RESOURCE_GROUP_NAME \

- --cluster-name $CLUSTER_NAME \

- --os-type Windows \

- --name npwin \

- --node-count 1

-```

-Some services have a curated monitoring experience. That is, Microsoft provides customized functionality meant to act as a starting point for monitoring those services. These experiences are collectively known as **curated visualizations** with the larger more complex of them being called **Insights**.

-The experiences collect and analyze a subset of logs and metrics and depending on the service and might also provide out-of-the-box alerting. They present this telemetry in a visual layout. The visualizations vary in size and scale. Some are considered part of Azure Monitor and follow the support and service level agreements for Azure. They are supported in all Azure regions where Azure Monitor is available. Other curated visualizations provide less functionality, might not scale, and might have different agreements. Some might be based solely on Azure Monitor Workbooks, while others might have an extensive custom experience.

-The table below lists the available curated visualizations and more detailed information about them.

->[!NOTE]

-> Another type of older visualization called **monitoring solutions** are no longer in active development. The replacement technology is the Azure Monitor Insights mentioned above. We suggest you use the insights and not deploy new instances of solutions. For more information on the solutions, see [Monitoring solutions in Azure Monitor](./insights/solutions.md).

-|Name with docs link| State | [Azure portal Link](https://portal.azure.com/#blade/Microsoft_Azure_Monitoring/AzureMonitoringBrowseBlade/more)| Description |

-| [Azure Monitor Workbooks for Azure Active Directory](../active-directory/reports-monitoring/howto-use-azure-monitor-workbooks.md) | GA (General availability) | [Yes](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Workbooks) | Azure Active Directory provides workbooks to understand the effect of your Conditional Access policies, to troubleshoot sign-in failures, and to identify legacy authentications. |

-| [Azure Monitor for Azure Cache for Redis (preview)](../azure-cache-for-redis/redis-cache-insights-overview.md) | GA | [Yes](https://portal.azure.com/#blade/Microsoft_Azure_Monitoring/AzureMonitoringBrowseBlade/redisCacheInsights) | Provides a unified, interactive view of overall performance, failures, capacity, and operational health |

-| [Azure Container Insights](/azure/azure-monitor/insights/container-insights-overview) | GA | [Yes](https://portal.azure.com/#blade/Microsoft_Azure_Monitoring/AzureMonitoringBrowseBlade/containerInsights) | Monitors the performance of container workloads that are deployed to managed Kubernetes clusters hosted on Azure Kubernetes Service (AKS). It gives you performance visibility by collecting metrics from controllers, nodes, and containers that are available in Kubernetes through the Metrics API. Container logs are also collected. After you enable monitoring from Kubernetes clusters, these metrics and logs are automatically collected for you through a containerized version of the Log Analytics agent for Linux. |

-| [Azure Data Explorer insights](/azure/data-explorer/data-explorer-insights) | GA | [Yes](https://portal.azure.com/#blade/Microsoft_Azure_Monitoring/AzureMonitoringBrowseBlade/adxClusterInsights) | Azure Data Explorer Insights provides comprehensive monitoring of your clusters by delivering a unified view of your cluster performance, operations, usage, and failures. |

-| [Azure HDInsight (preview)](../hdinsight/log-analytics-migration.md#insights) | Preview | No | An Azure Monitor workbook that collects important performance metrics from your HDInsight cluster and provides the visualizations and dashboards for most common scenarios. Gives a complete view of a single HDInsight cluster including resource utilization and application status|

- | [Azure IoT Edge](../iot-edge/how-to-explore-curated-visualizations.md) | GA | No | Visualize and explore metrics collected from the IoT Edge device right in the Azure portal using Azure Monitor Workbooks based public templates. The curated workbooks use built-in metrics from the IoT Edge runtime. These views don't need any metrics instrumentation from the workload modules. |

- | [Azure Monitor Application Insights](./app/app-insights-overview.md) | GA | [Yes](https://portal.azure.com/#blade/Microsoft_Azure_Monitoring/AzureMonitoringBrowseBlade/applicationsInsights) | Extensible Application Performance Management (APM) service which monitors the availability, performance, and usage of your web applications whether they're hosted in the cloud or on-premises. It leverages the powerful data analysis platform in Azure Monitor to provide you with deep insights into your application's operations. It enables you to diagnose errors without waiting for a user to report them. Application Insights includes connection points to a variety of development tools and integrates with Visual Studio to support your DevOps processes. |

- | [Azure Service Bus Insights](../service-bus-messaging/service-bus-insights.md) | Preview | [Yes](https://portal.azure.com/#blade/Microsoft_Azure_Monitoring/AzureMonitoringBrowseBlade/serviceBusInsights) | Azure Service Bus insights provide a view of the overall performance, failures, capacity, and operational health of all your Service Bus resources in a unified interactive experience. |

- | [Azure SQL insights (preview)](/azure/azure-sql/database/sql-insights-overview) | Preview | [Yes](https://portal.azure.com/#blade/Microsoft_Azure_Monitoring/AzureMonitoringBrowseBlade/sqlWorkloadInsights) | A comprehensive interface for monitoring any product in the Azure SQL family. SQL insights uses dynamic management views to expose the data you need to monitor health, diagnose problems, and tune performance. Note: If you are just setting up SQL monitoring, use this instead of the SQL Analytics solution. |

- | [Azure Network Insights](../network-watcher/network-insights-overview.md) | GA | [Yes](https://portal.azure.com/#blade/Microsoft_Azure_Monitoring/AzureMonitoringBrowseBlade/networkInsights) | Provides a comprehensive view of health and metrics for all your network resource. The advanced search capability helps you identify resource dependencies, enabling scenarios like identifying resource that are hosting your website, by simply searching for your website name. |

- | [Azure Monitor for Resource Groups](./insights/resource-group-insights.md) | GA | No | Triage and diagnose any problems your individual resources encounter, while offering context as to the health and performance of the resource group as a whole. |

- | [Azure Monitor SAP](../virtual-machines/workloads/sap/monitor-sap-on-azure.md) | GA | No | An Azure-native monitoring product for anyone running their SAP landscapes on Azure. It works with both SAP on Azure Virtual Machines and SAP on Azure Large Instances. Collects telemetry data from Azure infrastructure and databases in one central location and visually correlate the data for faster troubleshooting. You can monitor different components of an SAP landscape, such as Azure virtual machines (VMs), high-availability cluster, SAP HANA database, SAP NetWeaver, and so on, by adding the corresponding provider for that component. |

- | [Azure Stack HCI insights](/azure-stack/hci/manage/azure-stack-hci-insights) | Preview | [Yes](https://portal.azure.com/#blade/Microsoft_Azure_Monitoring/AzureMonitoringBrowseBlade/azureStackHCIInsights) | Azure Monitor Workbook based. Provides health, performance, and usage insights about registered Azure Stack HCI, version 21H2 clusters that are connected to Azure and are enrolled in monitoring. It stores its data in a Log Analytics workspace, which allows it to deliver powerful aggregation and filtering and analyze data trends over time. |

- | [Azure VM Insights](/azure/azure-monitor/insights/vminsights-overview) | GA | [Yes](https://portal.azure.com/#blade/Microsoft_Azure_Monitoring/AzureMonitoringBrowseBlade/virtualMachines) | Monitors your Azure virtual machines (VM) and virtual machine scale sets at scale. It analyzes the performance and health of your Windows and Linux VMs, and monitors their processes and dependencies on other resources and external processes. |

-| [Azure Automation](../automation/index.yml) | Manage operating system updates and track changes on Windows and Linux computers. See [Change Tracking](../automation/change-tracking/overview.md) and [Update Management](../automation/update-management/overview.md). |

-| [Defender for the Cloud (was Azure Security Center)](../defender-for-cloud/defender-for-cloud-introduction.md) | Collect and analyze security events and perform threat analysis. See [Data collection in Defender for the Cloud](../defender-for-cloud/enable-data-collection.md) |

-| [Microsoft Sentinel](../sentinel/index.yml) | Connects to different sources including Office 365 and Amazon Web Services Cloud Trail. See [Connect data sources](../sentinel/connect-data-sources.md). |

-| Network [Traffic Analytics](../network-watcher/traffic-analytics.md) | Analyzes Network Watcher network security group (NSG) flow logs to provide insights into traffic flow in your Azure cloud. |

-| [System Center Operations Manager](/system-center/scom) | Collect data from Operations Manager agents by connecting their management group to Azure Monitor. See [Connect Operations Manager to Azure Monitor](agents/om-agents.md)<br> Assess the risk and health of your System Center Operations Manager management group with [Operations Manager Assessment](insights/scom-assessment.md) solution. |

-| **The following solutions also integrate with parts of Azure Monitor. Note that solutions, are no longer under active development. Use [insights](#insights-and-curated-visualizations) instead.** | |

-| Network - [Azure Application Gateway Solution](insights/azure-networking-analytics.md#azure-application-gateway-analytics) | .

-| [SQL Analytics solution](insights/azure-sql.md) | Use SQL Insights instead |

-| [ITSM](alerts/itsmc-overview.md) | The IT Service Management Connector (ITSMC) allows you to connect Azure and a supported IT Service Management (ITSM) product/service. |

-| [Azure Monitor Partners](./partners.md) | A list of partners that integrate with Azure Monitor in some form |

-| [Azure Monitor Partner integrations](../partner-solutions/overview.md)| Specialized integrations between Azure Monitor and other non-Microsoft monitoring platforms if you've already built on them. Examples include Datadog and Elastic|

-Azure Monitor can collect data from resources outside of Azure using the methods listed in the following table.

-| Applications | Monitor web applications outside of Azure using Application Insights. See [What is Application Insights?](./app/app-insights-overview.md). |

-| REST API Client | Separate APIs are available to write data to Azure Monitor Logs and Metrics from any REST API client. See [Send log data to Azure Monitor with the HTTP Data Collector API](logs/data-collector-api.md) for Logs and [Send custom metrics for an Azure resource to the Azure Monitor metric store by using a REST API](essentials/metrics-store-custom-rest-api.md) for Metrics. |

-| Service | Resource Provider Namespace | Has Metrics | Has Logs | Insight | Notes

- | [API Management](../api-management/index.yml) | Microsoft.ApiManagement/service | [**Yes**](./essentials/metrics-supported.md#microsoftapimanagementservice) | [**Yes**](./essentials/resource-logs-categories.md#microsoftapimanagementservice) | | |

- | [Content Delivery Network](../cdn/index.yml) | Microsoft.Cdn/CdnWebApplicationFirewallPolicies | [**Yes**](./essentials/metrics-supported.md#microsoftcdncdnwebapplicationfirewallpolicies) | [**Yes**](./essentials/resource-logs-categories.md#microsoftcdncdnwebapplicationfirewallpolicies) | | |

- | [Content Delivery Network](../cdn/index.yml) | Microsoft.Cdn/profiles | [**Yes**](./essentials/metrics-supported.md#microsoftcdnprofiles) | [**Yes**](./essentials/resource-logs-categories.md#microsoftcdnprofiles) | | |

- | [Content Delivery Network](../cdn/index.yml) | Microsoft.Cdn/profiles/endpoints | No | [**Yes**](./essentials/resource-logs-categories.md#microsoftcdnprofilesendpoints) | | |

- | [Virtual Network (Classic)](../virtual-network/network-security-groups-overview.md) | Microsoft.ClassicNetwork/networkSecurityGroups | No | [**Yes**](./essentials/resource-logs-categories.md#microsoftclassicnetworknetworksecuritygroups) | | |

- | [Azure Storage Blobs (Classic)](../storage/blobs/index.yml) | Microsoft.ClassicStorage/storageAccounts/blobServices | [**Yes**](./essentials/metrics-supported.md#microsoftclassicstoragestorageaccountsblobservices) | No | [Storage Insights](/azure/azure-monitor/insights/storage-insights-overview) | |

- | [Azure Storage Files (Classic)](../storage/files/index.yml) | Microsoft.ClassicStorage/storageAccounts/fileServices | [**Yes**](./essentials/metrics-supported.md#microsoftclassicstoragestorageaccountsfileservices) | No | [Storage Insights](/azure/azure-monitor/insights/storage-insights-overview) | |

- | [Azure Storage Queues (Classic)](../storage/queues/index.yml) | Microsoft.ClassicStorage/storageAccounts/queueServices | [**Yes**](./essentials/metrics-supported.md#microsoftclassicstoragestorageaccountsqueueservices) | No | [Storage Insights](/azure/azure-monitor/insights/storage-insights-overview) | |

- | [Azure Storage Tables (Classic)](../storage/tables/index.yml) | Microsoft.ClassicStorage/storageAccounts/tableServices | [**Yes**](./essentials/metrics-supported.md#microsoftclassicstoragestorageaccountstableservices) | No | [Storage Insights](/azure/azure-monitor/insights/storage-insights-overview) | |

- | [Azure Virtual Machines](../virtual-machines/index.yml)<br />[Virtual Machine Scale Sets](../virtual-machine-scale-sets/index.yml) | Microsoft.Compute/disks | [**Yes**](./essentials/metrics-supported.md#microsoftcomputedisks) | No | [VM Insights](/azure/azure-monitor/insights/vminsights-overview) | |

- | [Azure Virtual Machines](../virtual-machines/index.yml)<br />[Virtual Machine Scale Sets](../virtual-machine-scale-sets/index.yml) | Microsoft.Compute/virtualMachines | [**Yes**](./essentials/metrics-supported.md#microsoftcomputevirtualmachines) | No | [VM Insights](/azure/azure-monitor/insights/vminsights-overview) | Agent required to monitor guest operating system and workflows.|

- | [Azure Virtual Machines](../virtual-machines/index.yml)<br />[Virtual Machine Scale Sets](../virtual-machine-scale-sets/index.yml) | Microsoft.Compute/virtualMachineScaleSets | [**Yes**](./essentials/metrics-supported.md#microsoftcomputevirtualmachinescalesets) | No | [VM Insights](/azure/azure-monitor/insights/vminsights-overview) | Agent required to monitor guest operating system and workflows.|

- | [Azure Virtual Machines](../virtual-machines/index.yml)<br />[Virtual Machine Scale Sets](../virtual-machine-scale-sets/index.yml) | Microsoft.Compute/virtualMachineScaleSets/virtualMachines | [**Yes**](./essentials/metrics-supported.md#microsoftcomputevirtualmachinescalesetsvirtualmachines) | No | [VM Insights](/azure/azure-monitor/insights/vminsights-overview) | Agent required to monitor guest operating system and workflows.|

- | [Azure Kubernetes Service (AKS)](../aks/index.yml) | Microsoft.ContainerService/managedClusters | [**Yes**](./essentials/metrics-supported.md#microsoftcontainerservicemanagedclusters) | [**Yes**](./essentials/resource-logs-categories.md#microsoftcontainerservicemanagedclusters) | [Container Insights](/azure/azure-monitor/insights/container-insights-overview) | |

- | [StorSimple](../storsimple/index.yml) | microsoft.hybridnetwork/networkfunctions | [**Yes**](./essentials/metrics-supported.md#microsofthybridnetworknetworkfunctions) | No | | |

- | [StorSimple](../storsimple/index.yml) | microsoft.hybridnetwork/virtualnetworkfunctions | [**Yes**](./essentials/metrics-supported.md#microsofthybridnetworkvirtualnetworkfunctions) | No | | |

- | [Azure Kubernetes Service (AKS)](../aks/index.yml) | Microsoft.Kubernetes/connectedClusters | [**Yes**](./essentials/metrics-supported.md#microsoftkubernetesconnectedclusters) | No | | |

- | [Application Gateway](../application-gateway/index.yml) | Microsoft.Network/applicationGateways | [**Yes**](./essentials/metrics-supported.md#microsoftnetworkapplicationgateways) | [**Yes**](./essentials/resource-logs-categories.md#microsoftnetworkapplicationgateways) | | |

- | [VPN Gateway](../vpn-gateway/index.yml) | Microsoft.Network/connections | [**Yes**](./essentials/metrics-supported.md#microsoftnetworkconnections) | No | | |

- | [Service Fabric](../service-fabric/index.yml) | Microsoft.ServiceFabric | No | No | [Service Fabric](../service-fabric/index.yml) | Agent required to monitor guest operating system and workflows.|

- | [Azure Storage Blobs](../storage/blobs/index.yml) | Microsoft.Storage/storageAccounts/blobServices | [**Yes**](./essentials/metrics-supported.md#microsoftstoragestorageaccountsblobservices) | [**Yes**](./essentials/resource-logs-categories.md#microsoftstoragestorageaccountsblobservices) | [Azure Storage Insights](/azure/azure-monitor/insights/storage-insights-overview) | |

- | [Azure Storage Files](../storage/files/index.yml) | Microsoft.Storage/storageAccounts/fileServices | [**Yes**](./essentials/metrics-supported.md#microsoftstoragestorageaccountsfileservices) | [**Yes**](./essentials/resource-logs-categories.md#microsoftstoragestorageaccountsfileservices) | [Azure Storage Insights](/azure/azure-monitor/insights/storage-insights-overview) | |

- | [Azure Storage Queue Services](../storage/queues/index.yml) | Microsoft.Storage/storageAccounts/queueServices | [**Yes**](./essentials/metrics-supported.md#microsoftstoragestorageaccountsqueueservices) | [**Yes**](./essentials/resource-logs-categories.md#microsoftstoragestorageaccountsqueueservices) | [Azure Storage Insights](/azure/azure-monitor/insights/storage-insights-overview) | |

- | [Azure Table Services](../storage/tables/index.yml) | Microsoft.Storage/storageAccounts/tableServices | [**Yes**](./essentials/metrics-supported.md#microsoftstoragestorageaccountstableservices) | [**Yes**](./essentials/resource-logs-categories.md#microsoftstoragestorageaccountstableservices) | [Azure Storage Insights](/azure/azure-monitor/insights/storage-insights-overview) | |

-description: With exploration, Personalizer is able to continue delivering good results, even as user behavior changes. Choosing an exploration setting is a business decision about the proportion of user interactions to explore with, in order to improve the model.

-# Exploration and exploitation

-With exploration, Personalizer is able to continue delivering good results, even as user behavior changes.

-* Uses exploitation to match the most probable user behavior based on the current machine learning model.

-Personalizer determines whether to explore or exploit with this probability on each rank call. This is different than the behavior in some A/B frameworks that lock a treatment on specific user IDs.

-It is important not to change the application behavior based on whether you see if Personalizer is exploring or exploiting. This would lead to learning biases that ultimately would decrease the potential performance.

-[Reinforcement learning](concepts-reinforcement-learning.md)

-> Azure Communication Services provides short term media storage for recordings. **Export any recorded content you wish to preserve within 48 hours.** After 48 hours, recordings will no longer be available.

- myContactGroups ='("action-group-resource-id-01", "action-group-resource-id-02")'

- $myContactGroups = @("action-group-resource-id-01", "action-group-resource-id-02")

- - **contactGroups**: First create a variable that holds your contact groups and then pass that variable. Replace the sample contact groups with the list of action groups to send the budget notification to when the threshold is exceeded.

-Use updated [default parameterization template.](https://docs.microsoft.com/azure/data-factory/continuous-integration-delivery-resource-manager-custom-parameters#default-parameterization-template) as one time migration to new method of including global parameters. This template references to all values in global parameter list.

-Learn more about the [advanced protection plans of Microsoft Defender for Cloud](defender-for-cloud-introduction.md).

-* **If you want to use transit routing between ExpressRoute and VPN, the ASN of Azure VPN Gateway must be set to 65515.** Azure VPN Gateway supports the BGP routing protocol. For ExpressRoute and Azure VPN to work together, you must keep the Autonomous System Number of your Azure VPN gateway at its default value, 65515. If you previously selected an ASN other than 65515 and you change the setting to 65515, you must reset the VPN gateway for the setting to take effect.

-* If you need more help, you can submit a support request from the [Azure portal](https://portal.azure.com/?#blade/Microsoft_Azure_Support/HelpAndSupportBlade/). Select **Support** from the menu bar or open the **Help + support** hub. For more detailed information, review [How to create an Azure support request](../../azure-portal/supportability/how-to-create-azure-support-request.md). Access to Subscription Management and billing support is included with your Microsoft Azure subscription, and Technical Support is provided through one of the [Azure Support Plans](https://azure.microsoft.com/support/plans/).

-To learn more, see [Authenticating devices signed with X.509 CA certificates](../iot-hub/iot-hub-x509ca-overview.md#authenticating-devices-signed-with-x509-ca-certificates).

-> To learn about obtaining certificates suitable for use in production, see [How to get an X.509 CA certificate](../iot-hub/iot-hub-x509ca-overview.md#how-to-get-an-x509-ca-certificate) in the Azure IoT Hub documentation.

- :::image type="content" source="./media/quick-create-simulated-device-x509/add-individual-enrollment-with-cert.png" alt-text="Screenshot that shows adding an individual enrollment with X.509 attestation to D P S in Azure portal.":::

- :::image type="content" source="./media/quick-create-simulated-device-x509/copy-id-scope.png" alt-text="Screenshot of the I D scope on Azure portal.":::

- :::image type="content" source="./media/quick-create-simulated-device-x509/copy-id-scope.png" alt-text="Screenshot of the I D scope on Azure portal.":::

-3. In your Windows command prompt, change to the X509Sample directory. This is located in the *.\azure-iot-samples-csharp\provisioning\Samples\device\X509Sample* directory off the directory where you cloned the samples on your computer.

- :::image type="content" source="./media/quick-create-simulated-device-x509/copy-id-scope-and-global-device-endpoint.png" alt-text="Screenshot of the I D scope and global device endpoint on Azure portal.":::

- :::image type="content" source="./media/quick-create-simulated-device-x509/copy-id-scope-and-global-device-endpoint.png" alt-text="Screenshot of the I D scope and global device endpoint on Azure portal.":::

- :::image type="content" source="./media/quick-create-simulated-device-x509/copy-id-scope-and-global-device-endpoint.png" alt-text="Screenshot of the I D scope and global device endpoint on Azure portal.":::

-# Register components with Device Update: Contoso Virtual Vacuum component enumerator

-This article shows an example implementation of the Contoso Virtual Vacuum component enumerator. You can reference this example to implement a custom component enumerator for your Internet of Things (IoT) devices. A *component* is an identity beneath the device level that has a composition relationship with the host device.

-## What is Contoso Virtual Vacuum?

-Contoso Virtual Vacuum is a virtual IoT device that we use to demonstrate the *proxy update* feature.

-Proxy update enables updating multiple components on the same IoT device or multiple sensors connected to the IoT device with a single over-the-air deployment. Proxy update supports an installation order for updating components. It also supports multiple-step updating with pre-installation, installation, and post-installation capabilities.

-The Device Update Agent runs on the host device. It can send each update to a specific component or to a group of components of the same hardware class (that is, requiring the same software or firmware update).

-For this demonstration, Contoso Virtual Vacuum consists of five logical components:

-We used the following directory structure to simulate the components:

-> [!NOTE]

-> For this demo, to update the components' firmware, we'll copy *firmware.json* or *diskimage.json* (update payload) to the targeted components' directory.

-> Contoso Virtual Vacuum contains software or firmware versions for the purpose of demonstrating proxy update. It doesn't provide any other functionality.

-## What is a component enumerator?

-A component enumerator is a Device Update Agent extension that provides information about every component that you need for an over-the-air update via a host device's Azure IoT Hub connection.

-The Device Update Agent is device and component agnostic. By itself, the agent doesn't know anything about components on (or connected to) a host device at the time of the update.

-To enable proxy updates, device builders must identify all updateable components on the device and assign a unique name to each component. Also, a group name can be assigned to components of the same hardware class, so that the same update can be installed onto all components in the same group. The update content handler can then install and apply the update to the correct components.

-Here are the responsibilities of each part of the proxy update flow:

- - Design and build the device.

- - Integrate the Device Update Agent and its dependencies.

- - Implement a device-specific component enumerator extension and register with the Device Update Agent.

-

- The component enumerator uses the information from a component inventory or a configuration file to augment static component data (Device Update required) with dynamic data (for example, firmware version, connection status, and hardware identity).

- - Create a proxy update that contains one or more child updates that target one or more components on (or connected to) the device.

- - Send the update to the solution operator.

- - Import the update (and manifest) to the Device Update service.

- - Deploy the update to a group of devices.

- - Get update information from Azure IoT Hub (via device twin or module twin).

- - Invoke a *steps handler* to process the proxy update intended for one or more components on the device.

-

- This example has two updates: `host-fw-1.1` and `motors-fw-1.1`. For each child update, the parent steps handler invokes a child steps handler to enumerate all components that match the `Compatibilities` properties specified in the child update's manifest file. Next, the handler downloads, installs, and applies the child update to all targeted components.

-

- To get the matching components, the child update calls a `SelectComponents` API provided by the component enumerator. If there are no matching components, the child update is skipped.

- - Collect all update results from parent and child updates, and report those results to Azure IoT Hub.

- - Iterate through a list of component instances that are compatible with the child update content. For more information, see [Steps handler](https://github.com/Azure/iot-hub-device-update/tree/main/src/content_handlers/steps_handler).

-In production, device builders can use [existing handlers](https://github.com/Azure/iot-hub-device-update/tree/main/src/content_handlers) or implement a custom handler that invokes any installer needed for an over-the-air update. For more information, see [Implement a custom update content handler](https://github.com/Azure/iot-hub-device-update/tree/main/docs/agent-reference/how-to-implement-custom-update-handler.md).

-## Implement a component enumerator for the Device Update Agent (C language)

-|`name`| string| A component's logical name. This is the name that a device builder assigns to a component that's available in every device of the same `device` class.<br/><br/>For example, every Contoso Virtual Vacuum device contains a motor that drives a left wheel. Contoso assigned *left motor* as a common (logical) name for this motor to easily refer to this component, instead of hardware ID, which can be globally unique.|

-|`manufacturer`|string|For a physical hardware component, this is a manufacturer or vendor name.<br/><br/>For a logical component, such as a disk partition or directory, it can be any device builder's defined value.|

-|`model`|string|For a physical hardware component, this is a model name.<br/><br/>For a logical component, such as a disk partition or directory, this can be any device builder's defined value.|

-Here's an example of `ComponentInfo` code:

-Following is a JSON document returned from the `GetAllComponents` function. It's based on the example implementation of the Contoso component enumerator.

-The example implementation shown earlier for the Contoso component enumerator will read the device-specific components' information from the *component-inventory.json* file. Note that this example implementation is only for demonstration purposes.

-In a production scenario, some properties should be retrieved directly from the actual components. These properties include `id`, `manufacturer`, and `model`.

-#### Example component-inventory.json file

-This example is written in C++. You can choose to use C if you prefer. To explore example source codes, see:

-Device Update for IoT Hub has several features focused on making it easier to diagnose and troubleshoot device-side errors. With the release of the v0.8.0 agent, there are two diagnostic features available:

-* **Deployment error codes** can now be viewed directly in the latest preview version of the Device Update user interface

-When a device reports a deployment failure to the Device Update service, the Device Update user interface now displays the device's reported resultCode and extendedResultCode in the user interface. You can view these codes using the following steps:

-1. Navigate to the **Groups and Deployments** tab.

-2. Click on the name of a group with an active deployment to get to the **Group details** page.

-3. Click on any device name in the **Device list** to open the device details panel. Here you can see the Result code the device has reported.

-4. The DU reference agent follows standard HTTP status code convention for the Result code field (e.g. "200" indicates success). For more information on how to parse Result codes, see the [Device Update client error codes](device-update-error-codes.md) page.

- > If you have modified your DU Agent to report customized Result codes, the numerical codes will still be passed through to the Device Update user interface. You may then refer to any documentation you have created to parse these numerical codes.

-When more information from the device is necessary to diagnose and troubleshoot an error, you can use the log collection feature to instruct targeted devices to upload on-device diagnostic logs to a linked Azure Blob storage account. You can start using this feature by following these [instructions](device-update-log-collection.md).

-1. The user creates a new log operation using the Device Update user interface or APIs, targeting up to 100 devices that have implemented the Diagnostics Interface.

-2. The DU service sends a log collection start message to the targeted devices using the Diagnostics Interface. This start message includes the log operation ID and a SAS token for uploading to the associated Azure Storage account.

-3. Upon receiving the start message, the DU agent of the targeted device will attempt to collect and upload the files in the pre-defined filepath(s) specified in the on-device agent configuration file. The DU reference agent is configured to upload the DU Agent diagnostic log ("aduc.log"), and the DO Agent diagnostic log ("do-agent.log") by default.

-4. The DU agent then reports the state of the operation ("Succeeded" / "Failed") back to the service, including the log operation ID, a ResultCode, and an ExtendedResultCode. If the DU Agent fails a log operation, it will automatically attempt to retry three times, reporting only the final state back to the service.

-5. Once all targeted devices have reported their terminal state back to the DU service, the DU service marks the log operation as "Succeeded" or "Failed." "Succeeded" indicates that all targeted devices successfully completed the log operation. "Failed" indicates that at least one targeted device failed the log operation.

- > [!NOTE]

- > Since the log operation is carried out in parallel by the targeted devices, it is possible that some targeted devices successfully uploaded logs, but the overall log operation is marked as "Failed." You can see which devices succeeded and which failed by viewing the log operation details through the user interface or APIs.

-## Next steps

-Learn how to use Device Update's remote log collection feature:

-This document provides an overview of the various limits that are imposed on the Device Update for IoT Hub resource and its associated operations. It also indicates whether the limits are adjustable by contacting Microsoft Support or not.

-During preview, the Device Update for IoT Hub service is provided at no cost to customers. More restrictive limits are imposed during the service's preview offering. These limits

-are expected to change once the service is Generally Available.

-

-# Multi-Step Ordered Execution

-Based on customer requests we have added the ability to run pre-install and post-install tasks when deploying an over-the-air update. This capability is called Multi-Step Ordered Execution (MSOE) and is part of the Public Preview Refresh Update Manifest v4 schema.

-See the [Update Manifest](update-manifest.md) documentation before reviewing the following changes as part of the Public Preview Refresh release.

-With MSOE we have introduced are two types of Steps:

-Example Update Manifest with one Inline Step:

-Example Update Manifest with two Inline Steps:

-Example Update Manifest with one Reference Step:

-```json

-{

- "updateId": {...},

- "isDeployable": true,

- "compatibility": [

- {

- "deviceManufacturer": "du-device",

- "deviceModel": "e2e-test"

- }

- ],

- "instructions": {

- "steps": [

- {

- "type": "reference",

- "description": "Cameras Firmware Update",

- "updateId": {

- "provider": "contoso",

- "name": "virtual-camera",

- "version": "1.2"

- }

- }

- ]

- },

- "manifestVersion": "4.0",

- "importedDateTime": "2021-11-17T07:26:14.7484389Z",

- "createdDateTime": "2021-11-17T07:22:10.6014567Z"

-}

-```

-```json

-{

- "updateId": {

- "provider": "contoso",

- "name": "virtual-camera",

- "version": "1.2"

- },

- "isDeployable": false,

- "compatibility": [

- {

- "group": "cameras"

- }

- ],

- "instructions": {

- "steps": [

- {

- "description": "Cameras Update - pre-install step",

- "handler": "microsoft/script:1",

- "files": [

- "contoso-camera-installscript.sh"

- ],

- "handlerProperties": {

- "scriptFileName": "contoso-camera-installscript.sh",

- "arguments": "--pre-install-sim-success --component-name --component-name-val --component-group --component-group-val --component-prop path --component-prop-val path",

- "installedCriteria": "contoso-virtual-camera-1.2-step-0"

- }

- },

- {

- "description": "Cameras Update - firmware installation (failure - missing file)",

- "handler": "microsoft/script:1",

- "files": [

- "contoso-camera-installscript.sh",

- "camera-firmware-1.1.json"

- ],

- "handlerProperties": {

- "scriptFileName": "missing-contoso-camera-installscript.sh",

- "arguments": "--firmware-file camera-firmware-1.1.json --component-name --component-name-val --component-group --component-group-val --component-prop path --component-prop-val path",

- "installedCriteria": "contoso-virtual-camera-1.2-step-1"

- }

- },

- {

- "description": "Cameras Update - post-install step",

- "handler": "microsoft/script:1",

- "files": [

- "contoso-camera-installscript.sh"

- ],

- "handlerProperties": {

- "scriptFileName": "contoso-camera-installscript.sh",

- "arguments": "--post-install-sim-success --component-name --component-name-val --component-group --component-group-val --component-prop path --component-prop-val path",

- "installedCriteria": "contoso-virtual-camera-1.2-stop-2"

- }

- }

- ]

- },

- "referencedBy": [

- {

- "provider": "DU-Client-Eng",

- "name": "MSOE-Update-Demo",

- "version": "3.1"

- }

- ],

- "manifestVersion": "4.0",

- "importedDateTime": "2021-11-17T07:26:14.7376536Z",

- "createdDateTime": "2021-11-17T07:22:09.2232968Z",

- "etag": "\"ad7a553d-24a8-492b-9885-9af424d44d58\""

-}

-```

-> In the [update manifest](/azure/iot-hub-device-update/update-manifest), each step should have different ΓÇ£installedCriteriaΓÇ¥ string if that string is being used to determine whether the step should be performed or not.

-## Parent Update vs. Child Update

-For Public Preview Refresh, we will refer to the top-level Update Manifest as `Parent Update` and refer to an Update Manifest specified in a Reference Step as `Child Update`.

-Currently, a `Child Update` must not contain any reference steps. This restriction is validated at import time and if not followed the import will fail.

-### Inline Step In Parent Update

-Inline step(s) specified in `Parent Update` will be applied to the Host Device. Here the ADUC_WorkflowData object that is passed to a Step Handler (also known as Update Content Handler) and it will not contain the `Selected Components` data. The handler for this type of step should *not* be a `Component-Aware` handler.

-> [!NOTE]

-> See [Steps Content Handler](https://github.com/Azure/iot-hub-device-update/tree/main/src/content_handlers/steps_handler/README.md) and [Implementing a custom component-Aware Content Handler](https://github.com/Azure/iot-hub-device-update/tree/main/docs/agent-reference/how-to-implement-custom-update-handler.md) for more details.

-> [!NOTE]

-> Steps Content Handler:

-> IsInstalled validation logic for each step: The Device Update agentΓÇÖs [step handler](https://github.com/Azure/iot-hub-device-update/blob/main/src/content_handlers/steps_handler/README.md) checks to see if particular update is already installed i.e., checks for IsInstalled() resulted in a result code ΓÇ£900ΓÇ¥ which means ΓÇÿtrueΓÇÖ. If an update is already installed, to avoid re-installing an update that is already on the device, the DU agent will skip future steps because we use it to determine whether to perform the step or not.

-> Reporting an update result: The result of a step handler execution must be written to ADUC_Result struct in a desired result file as specified in --result-file option [learn more](https://github.com/Azure/iot-hub-device-update/blob/main/src/content_handlers/steps_handler/README.md#steps-content-handler). Then based on results of the execution, for success return 0, for any fatal errors return -1 or 0xFF.

-### Reference Step In Parent Update

-Reference step(s) specified in `Parent Update` will be applied to the component on or components connected to the Host Device. A **Reference Step** is a step that contains update identifier of another Update, called as a `Child Update`. When processing a Reference Step, the Steps Handler will download a Detached Update Manifest file specified in the Reference Step data, then validate the file integrity.

-Next, the Steps Handler will parse the Child Update Manifest and create ADUC_Workflow object (also known as Child Workflow Data) by combining the data from Child Update Manifest and File URLs information from the Parent Update Manifest. This Child Workflow Data also has a 'level' property set to '1'.

-> [!NOTE]

-> For Update Manfiest version v4, the Child Udpate cannot contain any Reference Steps.

-## Detached Update Manifest

-To avoid deployment failure because of IoT Hub Twin Data Size Limits, any large Update Manifest will be delivered in the form of a JSON data file, also called as a 'Detached Update Manifest'.

-If an update with large content is imported into Device Update for IoT Hub, the generated Update Manifest will contain another payload file called `Detached Update Manifest`, which contains the full data of the Update Manifest.

-The `UpdateManifest` property in the Device or Module Twin will contain the Detached Update Manifest file information.

-When processing PnP Property Changed Event, the Device Update Agent will automatically download the Detached Update Manifest file, and create ADUC_WorkflowData object that contains the full Update Manifest data.

-

-# Proxy Updates and multi-component updating

-With Proxy updates, you can (1) target over-the-air updates to multiple components on the IoT device or (2) target over-the-air updates to multiple sensors connected to the IoT device. Use cases where proxy updates is applicable include:

-* Targeting specific update files to sensors connected to an IoT devices. These sensors could be connected to the IoT device over a network protocol (for example, USB, CANbus etc.).

-## Prerequisite

-In order to update a component or components that connected to a target IoT Device, the device builder must register a custom **Component Enumerator Extension** that is built specifically for their IoT devices. The Component Enumerator Extension is required so that the Device Update Agent can map a **'child update'** with a specific component, or group of components, which the update is intended for. See [Contoso Component Enumerator](components-enumerator.md) for an example on how to implement and register a custom Component Enumerator extension.

-> Device Update *service* does not know anything about **component(s)** on the target device. Only the Device Update agent does the above mapping.

-## Example Proxy update

-In the following example, we will demonstrate how to do a Proxy update and use the multi-step ordered execution feature introduced in the Public Preview Refresh Release. Multi-step ordered execution feature allows for granular update controls including an install order, pre-install, install, and post-install steps. Use cases include, for example, a required preinstall check that is needed to validate the device state before starting an update, etc. Learn more about [multi-step ordered execution](device-update-multi-step-updates.md).

-IoT Hub is not a full-featured MQTT broker and does not support all the behaviors specified in the MQTT v3.1.1 standard. This article describes how devices can use supported MQTT behaviors to communicate with IoT Hub.

-[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 choosen [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 Web Sockets 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 C# SDK defines the default value of the MQTT KeepAliveInSeconds property as 300 seconds but in reality the SDK sends a ping request 4 times per keep-alive duration set. This means the SDK sends a keep-alive ping every 75 seconds.

-If you are using the [device SDKs](https://github.com/Azure/azure-iot-sdks), switching from using AMQP to MQTT requires changing the protocol parameter in the client initialization, as stated previously.

-* MQTT does not support the *reject* operations when receiving [cloud-to-device messages](iot-hub-devguide-messaging.md). If your back-end app needs to receive a response from the device app, consider using [direct methods](iot-hub-devguide-direct-methods.md).

-* AMQP is not supported in the Python SDK.

-* Mosquitto_sendmessage: to send a simple text message to an Azure IoT hub acting as a device.

-* Mosquitto_subscribe: to see events occurring in an Azure IoT hub.

-If a device cannot use the device SDKs, it can still connect to the public device endpoints using the MQTT protocol on port 8883. In the **CONNECT** packet, the device should use the following values:

- It's strongly recommended to include api-version in the field. Otherwise it could cause unexpected behaviors.

-The device app can specify a **Will** message in the **CONNECT** packet. The device app should use `devices/{device-id}/messages/events/` or `devices/{device-id}/messages/events/{property-bag}` as the **Will** topic name to define **Will** messages to be forwarded as a telemetry message. In this case, if the network connection is closed, but a **DISCONNECT** packet was not previously received from the device, then IoT Hub sends the **Will** message supplied in the **CONNECT** packet to the telemetry channel. The telemetry channel can be either the default **Events** endpoint or a custom endpoint defined by IoT Hub routing. The message has the **iothub-MessageType** property with a value of **Will** assigned to it.

-For more information about using MQTT with modules, see [Publish and subscribe with IoT Edge](../iot-edge/how-to-publish-subscribe.md) and learn more about the [Edge Hub MQTT endpoint](https://github.com/Azure/iotedge/blob/main/doc/edgehub-api.md#edge-hub-mqtt-endpoint).

-To authenticate using a device certificate, update the code snippet above with the following changes (see [How to get an X.509 CA certificate](./iot-hub-x509ca-overview.md#how-to-get-an-x509-ca-certificate) on how to prepare for certificate-based authentication):

-After making a successful connection, a device 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 additional properties in a url-encoded format. For example:

-* IoT Hub does not support QoS 2 messages. If a device app publishes a message with **QoS 2**, IoT Hub closes the network connection.

-* IoT Hub does not persist Retain messages. If a device sends a message with the **RETAIN** flag set to 1, IoT Hub adds the **mqtt-retain** application property to the message. In this case, instead of persisting the retain message, IoT Hub passes it to the backend app.

-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 additional properties in the topic name. IoT Hub does not allow the usage of the `#` or `?` wildcards for filtering of subtopics. Since IoT Hub is not a general-purpose pub-sub messaging broker, it only supports the documented topic names and topic filters.

-To update reported properties, the device issues a request to IoT Hub via a publication over a designated MQTT topic. After processing the request, IoT Hub responds the success or failure status of the update operation via a publication to another topic. This topic can be subscribed by the device in order to notify it about the result of its twin update request. To implement this type of request/response interaction in MQTT, we leverage the notion of request ID (`$rid`) provided initially by the device in its update request. This request ID is also included in the response from IoT Hub to allow the device to correlate the response to its particular earlier request.

-The request message body contains a JSON document, that contains new values for reported properties. Each member in the JSON document updates or add the corresponding member in the device twin's document. A member set to `null` deletes the member from the containing object. For example:

-As for property updates, `null` values mean that the JSON object member is being deleted. Also, note that `$version` indicates the new version of the desired properties section of the twin.

-# Conceptual understanding of X.509 CA certificates in the IoT industry

-This article describes the value of using X.509 certificate authority (CA) certificates in IoT device manufacturing and authentication to IoT Hub. It includes information about supply chain setup and highlight advantages.

-This article describes:

-* What X.509 CA certificates are and how to get them

-* How to register your X.509 CA certificate to IoT Hub

-* How to set up a manufacturing supply chain for X.509 CA-based authentication

-* How devices signed with X.509 CA connect to IoT Hub

-## Overview

-X.509 Certificate Authority (CA) authentication is an approach for authenticating devices to IoT Hub using a method that dramatically simplifies device identity creation and life-cycle management in the supply chain.

-A distinguishing attribute of the X.509 CA authentication is a one-to-many relationship a CA certificate has with its downstream devices. This relationship enables registration of any number of devices into IoT Hub by registering an X.509 CA certificate once, otherwise device unique certificates must be pre-registered for every device before a device can connect. This one-to-many relationship also simplifies device certificates life-cycle management operations.

-Another important attribute of the X.509 CA authentication is simplification of supply chain logistics. Secure authentication of devices requires that each device holds a unique secret like a key as basis for trust. In certificates-based authentication, this secret is a private key. A typical device manufacturing flow involves multiple steps and custodians. Securely managing device private keys across multiple custodians and maintaining trust is difficult and expensive. Using certificate authorities solves this problem by signing each custodian into a cryptographic chain of trust rather than entrusting them with device private keys. Each custodian in turn signs devices at their respective process step of the manufacturing flow. The overall result is an optimal supply chain with built-in accountability through use of the cryptographic chain of trust. It is worth noting that this process yields the most security when devices protect their unique private keys. To this end, we urge the use of Hardware Secure Modules (HSM) capable of internally generating private keys that will never see the light of day.

-This article offers an end-to-end view of using the X.509 CA authentication, from supply chain setup to device connection, while making use of a real world example to solidify understanding.

-You can also use enrollment groups with the Azure IoT Hub Device Provisioning Service (DPS) to handle provisioning of devices to hubs. For more information on using DPS to provision X.509 certificate devices, see [Tutorial: Provision multiple X.509 devices using enrollment groups](../iot-dps/tutorial-custom-hsm-enrollment-group-x509.md).

-## Introduction

-The X.509 CA certificate is a digital certificate whose holder can sign other certificates. This digital certificate is X.509 because it conforms to a certificate formatting standard prescribed by IETF's RFC 5280 standard, and is a certificate authority (CA) because its holder can sign other certificates.

-The use of X.509 CA is best understood in relation to a concrete example. Consider Company-X, a maker of Smart-X-Widgets designed for professional installation. Company-X outsources both manufacturing and installation. It contracts manufacturer Factory-Y to manufacture the Smart-X-Widgets, and service provider Technician-Z to install. Company-X desires that Smart-X-Widget directly ships from Factory-Y to Technician-Z for installation and that it connects directly to Company-X's instance of IoT Hub after installation without further intervention from Company-X. To make this happen, Company-X need to complete a few one-time setup operations to prime Smart-X-Widget for automatic connection. With the end-to-end scenario in mind, the rest of this article is structured as follows:

-* Acquire the X.509 CA certificate

-* Register X.509 CA certificate to IoT Hub

-* Sign devices into a certificate chain of trust

-* Device connection

-## Acquire the X.509 CA certificate

-Company-X has the option of purchasing an X.509 CA certificate from a public root certificate authority or creating one through a self-signed process. One option would be optimal over the other depending on the application scenario. Regardless of the option, the process entails two fundamental steps, generating a public/private key pair and signing the public key into a certificate.

-Details on how to accomplish these steps differ with various service providers.

-### Purchasing an X.509 CA certificate

-Purchasing a CA certificate has the benefit of having a well-known root CA act as a trusted third party to vouch for the legitimacy of IoT devices when the devices connect. Company-X would choose this option if they intend Smart-X-Widget to interact with third-party products or services after initial connection to IoT Hub.

-To purchase an X.509 CA certificate, Company-X would choose a root certificates services provider. An internet search for the phrase 'Root CA' will yield good leads. The root CA will guide Company-X on how to create the public/private key pair and how to generate a Certificate Signing Request (CSR) for their services. A CSR is the formal process of applying for a certificate from a certificate authority. The outcome of this purchase is a certificate for use as an authority certificate. Given the ubiquity of X.509 certificates, the certificate is likely to have been properly formatted to IETF's RFC 5280 standard.

-### Creating a Self-Signed X.509 CA certificate

-The process to create a Self-Signed X.509 CA certificate is similar to purchasing with the exception of involving a third-party signer like the root certificate authority. In our example, Company-X will sign its authority certificate instead of a root certificate authority. Company-X may choose this option for testing until they're ready to purchase an authority certificate. Company-X may also use a self-signed X.509 CA certificate in production, if Smart-X-Widget is not intended to connect to any third-party services outside of the IoT Hub.

-## Register the X.509 certificate to IoT Hub

-Company-X needs to register the X.509 CA to IoT Hub where it will serve to authenticate Smart-X-Widgets as they connect. This is a one-time process that enables the ability to authenticate and manage any number of Smart-X-Widget devices. This is a one-time process because of a one-to-many relationship between CA certificate and device certificates that are signed by the CA certificate or an intermediate certificate. This relationship constitutes one of the main advantages of using the X.509 CA authentication method. The alternative is to upload individual certificate thumbprints for each and every Smart-X-Widget device thereby adding to operational costs.

-Registering the X.509 CA certificate is a two-step process, the certificate upload and certificate proof-of-possession.

-### X.509 CA Certificate Upload

-The X.509 CA certificate upload process is just that, upload the CA certificate to IoT Hub. IoT Hub expects the certificate in a file. Company-X simply uploads the certificate file. The certificate file MUST NOT under any circumstances contain any private keys. Best practices from standards governing Public Key Infrastructure (PKI) mandates that knowledge of Company-X's private in this case resides exclusively within Company-X.

-### Proof-of-Possession of the Certificate

-The X.509 CA certificate, just like any digital certificate, is public information that is susceptible to eavesdropping. As such, an eavesdropper may intercept a certificate and try to upload it as their own. In our example, IoT Hub would like to make sure that the CA certificate Company-X is uploading really belongs to Company-X. It does so by challenging Company-X to prove that they in fact possess the certificate through a [proof-of-possession (PoP) flow](https://tools.ietf.org/html/rfc5280#section-3.1). The proof-of-possession flow entails IoT Hub generating a random number to be signed by Company-X using its private key. If Company-X followed PKI best practices and protected their private key then only they would be in position to correctly respond to the proof-of-possession challenge. IoT Hub proceeds to register the X.509 CA certificate upon a successful response of the proof-of-possession challenge.

-## Sign Devices into a Certificate Chain of Trust

-IoT requires every device to possess a unique identity. These identities are in the form certificates for certificate-based authentication schemes. In our example, this means every Smart-X-Widget must possess a unique device certificate. How does Company-X setup for this in its supply chain?

-One way to go about this is to pre-generate certificates for Smart-X-Widgets and entrusting knowledge of corresponding unique device private keys with supply chain partners. For Company-X, this means entrusting Factory-Y and Technician-Z. While this is a valid method, it comes with challenges that must be overcome to ensure trust as follows:

-1. Having to share device private keys with supply chain partners, besides ignoring PKI best practices of never sharing private keys, makes building trust in the supply chain expensive. It means capital systems like secure rooms to house device private keys, and processes like periodic security audits need to be installed. Both add cost to the supply chain.

-2. Securely accounting for devices in the supply chain and later managing them in deployment becomes a one-to-one task for every key-to-device pair from the point of device unique certificate (hence private key) generation to device retirement. This precludes group management of devices unless the concept of groups is explicitly built into the process somehow. Secure accounting and device life-cycle management, therefore, becomes a heavy operations burden. In our example, Company-X would bear this burden.

-X.509 CA certificate authentication offers elegant solutions to afore listed challenges through the use of certificate chains. A certificate chain results from a CA signing an intermediate CA that in turn signs another intermediate CA and so goes on until a final intermediate CA signs a device. In our example, Company-X signs Factory-Y, which in turn signs Technician-Z that finally signs Smart-X-Widget.

-Above cascade of certificates in the chain presents the logical hand-off of authority. Many supply chains follow this logical hand-off whereby each intermediate CA gets signed into the chain while receiving all upstream CA certificates, and the last intermediate CA finally signs each device and inject all the authority certificates from the chain into the device. This is common when the contract manufacturing company with a hierarchy of factories commissions a particular factory to do the manufacturing. While the hierarchy may be several levels deep (for example, by geography/product type/manufacturing line), only the factory at the end gets to interact with the device but the chain is maintained from the top of the hierarchy.

-Alternate chains may have different intermediate CA interact with the device in which case the CA interacting with the device injects certificate chain content at that point. Hybrid models are also possible where only some of the CA has physical interaction with the device.

-In our example, both Factory-Y and Technician-Z interact with the Smart-X-Widget. While Company-X owns Smart-X-Widget, it actually does not physically interact with it in the entire supply chain. The certificate chain of trust for Smart-X-Widget therefore comprise Company-X signing Factory-Y which in turn signs Technician-Z that will then provide final signature to Smart-X-Widget. The manufacture and installation of Smart-X-Widget comprise Factory-Y and Technician-Z using their respective intermediate CA certificates to sign each and every Smart-X-Widgets. The end result of this entire process is Smart-X-Widgets with unique device certificates and certificate chain of trust going up to Company-X CA certificate.

-This is a good point to review the value of the X.509 CA method. Instead of pre-generating and handing off certificates for every Smart-X-Widget into the supply chain, Company-X only had to sign Factory-Y once. Instead of having to track every device throughout the device's life-cycle, Company-X may now track and manage devices through groups that naturally emerge from the supply chain process, for example, devices installed by Technician-Z after July of some year.

-Last but not least, the CA method of authentication infuses secure accountability into the device manufacturing supply chain. Because of the certificate chain process, the actions of every member in the chain is cryptographically recorded and verifiable.

-This process relies on certain assumptions that must be surfaced for completeness. It requires independent creation of device unique public/private key pair and that the private key be protected within the device. Fortunately, secure silicon chips in the form of Hardware Secure Modules (HSM) capable of internally generating keys and protecting private keys exist. Company-X only need to add one of such chips into Smart-X-Widget's component bill of materials.

-## Device Connection

-Previous sections above have been building up to device connection. By simply registering an X.509 CA certificate to IoT Hub one time, how do potentially millions of devices connect and get authenticated from the first time? Simple; through the same certificate upload and proof-of-possession flow we earlier encountered with registering the X.509 CA certificate.

-Devices manufactured for X.509 CA authentication are equipped with device unique certificates and a certificate chain from their respective manufacturing supply chain. Device connection, even for the very first time, happens in a two-step process: certificate chain upload and proof-of-possession.

-During the certificate chain upload, the device uploads its device unique certificate together with the certificate chain installed within it to IoT Hub. Using the pre-registered X.509 CA certificate, IoT Hub can cryptographically validate a couple of things, that the uploaded certificate chain is internally consistent, and that the chain was originated by the valid owner of the X.509 CA certificate. Just was with the X.509 CA registration process, IoT Hub would initiate a proof-of-possession challenge-response process to ascertain that the chain and hence device certificate actually belongs to the device uploading it. It does so by generating a random challenge to be signed by the device using its private key for validation by IoT Hub. A successful response triggers IoT Hub to accept the device as authentic and grant it connection.

-Notice that the foundation of trust rests in protecting private keys including device private keys. We therefore cannot stress enough the importance of secure silicon chips in the form of Hardware Secure Modules (HSM) for protecting device private keys, and the overall best practice of never sharing any private keys, like one factory entrusting another with its private key.

-# Device Authentication using X.509 CA Certificates

-This article describes how to use X.509 Certificate Authority (CA) certificates to authenticate devices connecting IoT Hub. In this article you will learn:

-## Overview

-The X.509 CA feature enables device authentication to IoT Hub using a Certificate Authority (CA). It greatly simplifies initial device enrollment process, and supply chain logistics during device manufacturing. [Learn more in this scenario article about the value of using X.509 CA certificates](iot-hub-x509ca-concept.md) for device authentication. We encourage you to read this scenario article before proceeding as it explains why the steps that follow exist.

-## Prerequisite

-Using the X.509 CA feature requires that you have an IoT Hub account. [Learn how to create an IoT Hub instance](../iot-develop/quickstart-send-telemetry-iot-hub.md?pivots=programming-language-csharp) if you don't already have one.

-## How to get an X.509 CA certificate

-For production environment, we recommend that you purchase an X.509 CA certificate from a public root certificate authority. Purchasing a CA certificate has the benefit of the root CA acting as a trusted third party to vouch for the legitimacy of your devices. Consider this option if you intend your devices to be part of an open IoT network where they are expected to interact with third-party products or services.

-Regardless of how you obtain your X.509 CA certificate, make sure to keep its corresponding private key secret and protected at all times. This is necessary for trust building trust in the X.509 CA authentication.

-Learn how to [create a self-signed CA certificate](https://github.com/Azure/azure-iot-sdk-c/blob/master/tools/CACertificates/CACertificateOverview.md), which you can use for experimentation throughout this feature description.

-The owner of an X.509 CA certificate can cryptographically sign an intermediate CA who can in turn sign another intermediate CA, and so on, until the last intermediate CA terminates this process by signing a device. The result is a cascaded chain of certificates known as a certificate chain of trust. In real life this plays out as delegation of trust towards signing devices. This delegation is important because it establishes a cryptographically variable chain of custody and avoids sharing of signing keys.

-The device certificate (also called a leaf certificate) must have the *Subject Name* set to the **Device ID** (`CN=deviceId`) that was used when registering the IoT device in the Azure IoT Hub. This setting is required for authentication.

-Learn here how to [create a certificate chain](https://github.com/Azure/azure-iot-sdk-c/blob/master/tools/CACertificates/CACertificateOverview.md) as done when signing devices.

-## How to register the X.509 CA certificate to IoT Hub

-Register your X.509 CA certificate to IoT Hub where it will be used to authenticate your devices during registration and connection. Registering the X.509 CA certificate is a two-step process that comprises certificate file upload and proof of possession.

-The proof of possession step involves a cryptographic challenge and response process between you and IoT Hub. Given that digital certificate contents are public and therefore susceptible to eavesdropping, IoT Hub would like to ascertain that you really own the CA certificate. It shall do so by generating a random challenge that you must sign with the CA certificate's corresponding private key. If you kept the private key secret and protected as earlier advised, then only you will possess the knowledge to complete this step. Secrecy of private keys is the source of trust in this method. After signing the challenge, complete this step by uploading a file containing the results.

-Learn here how to [register your CA certificate](./tutorial-x509-scripts.md)

-## How to create a device on IoT Hub

-To preclude device impersonation, IoT Hub requires you to let it know what devices to expect. You do this by creating a device entry in the IoT Hub's device registry. This process is automated when using IoT Hub [Device Provisioning Service](../iot-dps/about-iot-dps.md).

-Learn here how to [manually create a device in IoT Hub](./tutorial-x509-scripts.md).

-Create an X.509 device for your IoT hub

-## Authenticating devices signed with X.509 CA certificates

-With X.509 CA certificate registered and devices signed into a certificate chain of trust, what remains is device authentication when the device connects, even for the first time. When an X.509 CA signed device connects, it uploads its certificate chain for validation. The chain includes all intermediate CA and device certificates. With this information, IoT Hub authenticates the device in a two-step process. IoT Hub cryptographically validates the certificate chain for internal consistency, and then issues a proof-of-possession challenge to the device. IoT Hub declares the device authentic on a successful proof-of-possession response from the device. This declaration assumes that the device's private key is protected and that only the device can successfully respond to this challenge. We recommend use of secure chips like Hardware Secure Modules (HSM) in devices to protect private keys.

-A successful device connection to IoT Hub completes the authentication process and is also indicative of a proper setup. Every time a device connects, IoT Hub renegotiates the TLS session and verifies the deviceΓÇÖs X.509 certificate.

-Learn here how to [complete this device connection step](./tutorial-x509-scripts.md).

-Get started with IoT Hub [Device Provisioning Service](../iot-dps/index.yml).

-This error occurs when Azure Resource Manager can't find a required resource. For example, you will receive this error if a storage account was referred to but cannot be found at the path on which it was specified. Be sure to double check resources that might have been supplied by exact path or the spelling of their names.

-For more information, see [Resolve resource not found errors](../azure-resource-manager/troubleshooting/error-not-found.md).

-1. At the bottom, select **View all properties in Azure portal**

-1. Copy the value from Azure portal into the code.

- - **Alert**: This term needs attention.

- cd ~/sapcon/<SID>

- ls

- mv metadata.db metadata.old

-> Config Server takes `master` (om Git itself) as the default label if you don't specify one. But GitHub has changed the default branch from `master` to `main` recently. To avoid Azure Spring Apps Config Server failure, be sure to pay attention to the default label when setting up Config Server with GitHub, especially for newly-created repositories.

-4. Use [the MSI installer (MsMmrHostMri)](https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE4QWrF) to install both the host native component and the multimedia redirection extensions for your internet browser on your Azure VM.

-Azure NPM implementation works in conjunction with the Azure CNI that provides VNet integration for containers. NPM is supported only on Linux and Windows Server 2022 today. The implementation enforces traffic filtering by configuring allow and deny IP rules in Linux IPTables or Windows HNS ACLPolicies based on the defined policies. These rules are grouped together using Linux IPSets or Windows HNS SetPolicies.

-Azure-managed Default Rule Set includes rules against the following threat categories:

-The version number of the Default Rule Set increments when new attack signatures are added to the rule set.

-Default Rule Set is enabled by default in Detection mode in your WAF policies. You can disable or enable individual rules within the Default Rule Set to meet your application requirements. You can also set specific actions (ALLOW/BLOCK/REDIRECT/LOG) per rule.

-Sometimes you may need to omit certain request attributes from a WAF evaluation. A common example is Active Directory-inserted tokens that are used for authentication. You may configure an exclusion list for a managed rule, rule group, or for the entire rule set.

-The Default action is to BLOCK. Additionally, custom rules can be configured in the same WAF policy if you wish to bypass any of the pre-configured rules in the Default Rule Set.

-The Microsoft Threat Intelligence Collection rules are written in partnership with the Microsoft Intelligence team to provide increased coverage, patches for specific vulnerabilities, and better false positive reduction.

-### Anomaly Scoring mode

-OWASP has two modes for deciding whether to block traffic: Traditional mode and Anomaly Scoring mode.

-In Traditional mode, traffic that matches any rule is considered independently of any other rule matches. This mode is easy to understand. But the lack of information about how many rules match a specific request is a limitation. So, Anomaly Scoring mode was introduced. It's the default for OWASP 3.*x*.

-In Anomaly Scoring mode, traffic that matches any rule isn't immediately blocked when the firewall is in Prevention mode. Rules have a certain severity: *Critical*, *Error*, *Warning*, or *Notice*. That severity affects a numeric value for the request, which is called the Anomaly Score. For example, one *Warning* rule match contributes 3 to the score. One *Critical* rule match contributes 5.

-|Severity |Value |

-|||

-|Critical |5|

-|Error |4|

-|Warning |3|

-|Notice |2|

-There's a threshold of 5 for the Anomaly Score to block traffic. So, a single *Critical* rule match is enough for the WAF to block a request, even in Prevention mode. But one *Warning* rule match only increases the Anomaly Score by 3, which isn't enough by itself to block the traffic. For more information, see [What content types does WAF support?](waf-faq.yml#what-content-types-does-waf-support-) in the FAQ to learn what content types are supported for body inspection with different DRS versions.

-DRS 2.0 includes 17 rule groups, as shown in the following table. Each group contains multiple rules, which can be disabled.

-The following rule groups and rules are available when using Web Application Firewall on Azure

-Front Door.

-# Web Application Firewall (WAF) with Front Door Service exclusion lists

- {

- "customRules": [

- {

- "name": "blockEvilBot",

- "ruleType": "MatchRule",

- "priority": 2,

- "action": "Block",

- "matchConditions": [

- {

- "matchVariable": "RequestHeaders",

- "operator": "User-Agent",

- "matchValues": [

- "evilbot"

- ]

- }

- ]

- }

- ]

- }

- {

- "customRules": [

- {

- "name": "blockEvilBot",

- "ruleType": "MatchRule",

- "priority": 2,

- "action": "Block",

- "matchConditions": [

- {

- "matchVariable": "RequestHeaders",

- "operator": "User-Agent",

- "matchValues": [

- "evilbot"

- ]

- }

- ]

- }

- ]

- }

- {

- "customRules": [

- {

- "name": "allowUS",

- "ruleType": "MatchRule",

- "priority": 2,

- "action": "Block",

- "matchConditions": [

- {

- "matchVariable": "RemoteAddr",

- "operator": "GeoMatch",

- "NegationConditon": false,

- "matchValues": [

- "US"

- ]

- }

- ]

- }

- ]

- }

- {

- "customRules": [

- {

- "name": "myrule1",

- "ruleType": "MatchRule",

- "priority": 10,

- "action": "Block",

- "matchConditions": [

- {

- "matchVariable": "RemoteAddr",

- "operator": "IPMatch",

- "matchValues": [

- "192.168.5.0/24"

- ]

- }

- ]

- }

- ]

- }

-{

- "customRules": [

- {

- "name": "myrule",

- "ruleType": "MatchRule",

- "priority": 10,

- "action": "block",

- "matchConditions": [

- {

- "matchVariable": "RemoteAddr",

- "operator": "IPMatch",

- "negateCondition": false,

- "matchValues": [

- "192.168.5.0/24"

- ]

- },

- {

- "matchVariable": "RequestHeaders",

- "selector": "User-Agent",

- "operator": "Contains",

- "transforms": [

- "Lowercase"

- ],

- "matchValues": [

- "evilbot"

- ]

- }

- ]

- }

- ]

- }

- "customRules": [

- {

- "name": "myrule1",

- "ruleType": "MatchRule",

- "priority": 10,

- "action": "block",

- "matchConditions": [

- {

- "matchVariable": "RequestHeaders",

- "operator": "IPMatch",

- "negateCondition": true,

- "matchValues": [

- "192.168.5.0/24"

- ]

- }

- ]

- },

- {

- "name": "myrule2",

- "ruleType": "MatchRule",

- "priority": 20,

- "action": "block",

- "matchConditions": [

- {

- "matchVariable": "RequestHeaders",

- "selector": "User-Agent",

- "operator": "Contains",

- "negateCondition": true,

- "transforms": [

- "Lowercase"

- ],

- "matchValues": [

- "chrome"

- ]

- }

- ]

- }

- ]

- }

-You want to block custom SQLI. Since the logic used here is **or**, and all the values are in the *RequestUri*, all of the *MatchValues* can be in a comma-separated list.

-Logic: p **or** q **or** r

-```azurepowershell

-$variable1 = New-AzApplicationGatewayFirewallMatchVariable `

- -VariableName RequestUri

-$condition1 = New-AzApplicationGatewayFirewallCondition `

- -MatchVariable $variable1 `

- -Operator Contains `

- -MatchValue "1=1", "drop tables", "'ΓÇö" `

- -NegationCondition $False

-$rule1 = New-AzApplicationGatewayFirewallCustomRule `

- -Name myrule4 `

- -Priority 10 `

- -RuleType MatchRule `

- -MatchCondition $condition1 `

- -Action Block

-```

-Corresponding JSON:

-```json

- {

- "customRules": [

- {

- "name": "myrule4",

- "ruleType": "MatchRule",

- ΓÇ£priorityΓÇ¥: 10

- "action": "block",

- "matchConditions": [

- {

- "matchVariable": "RequestUri",

- "operator": "Contains",

- "matchValues": [

- "1=1",

- "drop tables",

- "'--"

- ]

- }

- ]

- }

- ]

- }

-```

-Alternative Azure PowerShell:

-$variable1 = New-AzApplicationGatewayFirewallMatchVariable `

- -VariableName RequestUri

-$condition1 = New-AzApplicationGatewayFirewallCondition `

- -MatchVariable $variable1 `

- -Operator Contains `

- -MatchValue "1=1" `

- -NegationCondition $False

-$rule1 = New-AzApplicationGatewayFirewallCustomRule `

- -Name myrule1 `

- -Priority 10 `

- -RuleType MatchRule `

- -MatchCondition $condition1 `

-$variable2 = New-AzApplicationGatewayFirewallMatchVariable `

- -VariableName RequestUri

-$condition2 = New-AzApplicationGatewayFirewallCondition `

- -MatchVariable $variable2 `

- -Operator Contains `

- -MatchValue "drop tables" `

- -NegationCondition $False

-$rule2 = New-AzApplicationGatewayFirewallCustomRule `

- -Name myrule2 `

- -Priority 20 `

- -RuleType MatchRule `

- -MatchCondition $condition2 `

- -Action Block

-$variable3 = New-AzApplicationGatewayFirewallMatchVariable `

- -VariableName RequestUri

-$condition3 = New-AzApplicationGatewayFirewallCondition `

- -MatchVariable $variable3 `

- -Operator Contains `

- -MatchValue "ΓÇÖΓÇö" `

- -NegationCondition $False

-$rule3 = New-AzApplicationGatewayFirewallCustomRule `

- -Name myrule3 `

- -Priority 30 `

- -MatchCondition $condition3 `

- {

- "customRules": [

- {

- "name": "myrule1",

- "ruleType": "MatchRule",

- "priority": 10,

- "action": "block",

- "matchConditions": [

- {

- "matchVariable": "RequestUri",

- "operator": "Contains",

- "matchValues": [

- "1=1"

- ]

- }

- ]

- },

- {

- "name": "myrule2",

- "ruleType": "MatchRule",

- "priority": 20,

- "action": "block",

- "matchConditions": [

- {

- "matchVariable": "RequestUri",

- "operator": "Contains",

- "transforms": [

- "Lowercase"

- ],

- "matchValues": [

- "drop tables"

- ]

- }

- ]

- },

- {

- "name": "myrule3",

- "ruleType": "MatchRule",

- "priority": 30,

- "action": "block",

- "matchConditions": [

- {

- "matchVariable": "RequestUri",

- "operator": "Contains",

- "matchValues": [

- "'--"

- ]

- }

- ]

- }

- ]

- }

-It is not uncommon to see Azure Front Door deployed in front of Application Gateway. In order to make sure the traffic received by Application Gateway comes from the Front Door deployment, the best practice is to check if the `X-Azure-FDID` header contains the expected unique value. For more information on this, please see [How to lock down the access to my backend to only Azure Front Door](../../frontdoor/front-door-faq.yml#how-do-i-lock-down-the-access-to-my-backend-to-only-azure-front-door-)

- {

- "customRules": [

- {

- "name": "blockNonAFDTraffic",

- "priority": 2,

- "ruleType": "MatchRule",

- "action": "Block",

- "matchConditions": [

- {

- "matchVariables": [

- {

- "variableName": "RequestHeaders",

- "selector": "X-Azure-FDID"

- }

- ],

- "operator": "Equal",

- "negationConditon": true,

- "matchValues": [

- "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

- ],

- "transforms": [

- "Lowercase"

- ]

- }

- ]

- }

- ]

- }

-# Azure Resource Manager templates for Azure Web Application Firewall

-The following table includes links to Azure Resource Manager templates for Azure Web Application Firewall.