+ Title: Configure Transmit Security with Azure Active Directory B2C for passwordless authentication

+description: Configure Azure AD B2C with Transmit Security BindID for passwordless customer authentication

+In this tutorial, learn to integrate Azure Active Directory B2C (Azure AD B2C) authentication with [Transmit Security](https://www.transmitsecurity.com/bindid) BindID, a passwordless authentication solution. BindID uses strong Fast Identity Online (FIDO2) biometric authentication for reliable omni-channel authentication. The solution ensures a smooth sign in experience for customers across devices and channels, while reducing fraud, phishing, and credential reuse.

+The following architecture diagram illustrates the implementation.

+

+1. User opens the Azure AD B2C sign in page, and signs in or signs up.

+2. Azure AD B2C redirects the user to BindID using an OpenID Connect (OIDC) request.

+3. BindID authenticates the user using appless FIDO2 biometrics, such as fingerprint.

+4. A decentralized authentication response is returned to BindID.

+5. The OIDC response passes to Azure AD B2C.

+6. User is granted or denied access to the application, based on verification results.

+To get started, you need:

+* An Azure AD subscription

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

+* An Azure AD B2C tenant linked to the Azure subscription

+ * See, [Tutorial: Create an Azure Active Directory B2C tenant](./tutorial-create-tenant.md)

+* A BindID tenant

+ * Go to transmitsecurity.com to [get started](https://www.transmitsecurity.com/developer?utm_signup=dev_hub#try)

+* Register a web application in the Azure portal

+ * [Tutorial: Register a web application in Azure Active Directory B2C](./tutorial-register-applications.md)

+* Azure AD B2C custom policies

+ * If you can't use the policies, see [Tutorial: Create user flows and custom policies in Azure AD B2C](./tutorial-create-user-flows.md?pivots=b2c-custom-policy)

+## Register an app in BindID

+To get started:

+1. Go to developer.bindid.io to [Configure Your Application](https://developer.bindid.io/docs/guides/quickstart/topics/quickstart_web#step-1-configure-your-application).

+2. Add an application in [BindID Admin Portal](https://admin.bindid-sandbox.io/console/). Sign-in is required.

+| Name | Application name|

+| Domain | Enter `your-B2C-tenant-name.onmicrosoft.com`. Replace `your-B2C-tenant` with your Azure AD B2C tenant.|

+| Redirect URLs | Enter `https://your-B2C-tenant-name.b2clogin.com/your-B2C-tenant-name.onmicrosoft.com/oauth2/authresp`. Replace `your-B2C-tenant` with your Azure AD B2C tenant. For a custom domain, replace `your-B2C-tenant-name.b2clogin.com` with your custom domain.|

+3. Upon registration, a **Client ID** and **Client Secret** appear.

+4. Record the values to use later.

+## Configure BindID as an identity provider in Azure AD B2C

+For the following instructions, use the directory with your Azure AD B2C tenant.

+1. Sign in to the [Azure portal](https://portal.azure.com/#home) as Global Administrator.

+2. In the portal toolbar, select **Directories + subscriptions**.

+3. On the **Portal settings | Directories + subscriptions** page, in the **Directory name** list, find the Azure AD B2C directory.

+4. Select **Switch**.

+5. In the top-left corner of the Azure portal, select **All services**.

+6. Search for and select **Azure AD B2C**.

+7. Select **Identity providers**.

+8. Select **New OpenID Connect provider**.

+9. Enter a **Name**.

+10. For **Metadata URL**, enter `https://signin.bindid-sandbox.io/.well-known/openid-configuration`.

+11. For **Client ID**, enter the Client ID you recorded.

+12. For **Client secret**, enter the Client Secret you recorded.

+13. For the **Scope**, enter the `openid email`.

+14. For **Response type**, select **code**.

+15. For **Response mode**, select **form_post**.

+16. Under **Identity provider claims mapping**, for **User ID**, select `sub`.

+17. For **Email**, select `email`.

+18. Select **Save**.

+## Create a user flow

+2. Select **New user flow**.

+3. Select **Sign up and sign in** user flow type.

+4. Select **Create**.

+5. Enter a **Name**.

+6. Under **Identity providers**, for **Local Accounts**, select **None**. This action disables email and password-based authentication.

+7. For **Custom identity providers**, select the created BindID Identity provider such as **Login with BindID**.

+8. Select **Create**.

+## Test the user flow

+1. In the Azure AD B2C tenant, select **User flows**.

+2. Select the created user flow, such as **B2C_1_signupsignin**.

+3. For **Application**, select the web application you registered. The **Reply URL** is `https://jwt.ms`.

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

+5. The browser is redirected to the BindID sign in page.

+6. Enter the registered account email.

+7. Authenticates using appless FIDO2 biometrics, such as fingerprint.

+8. The browser is redirect to `https://jwt.ms`. The contents appear for the token returned by Azure AD B2C.

+## Create a BindID policy key

+Add the BindID application Client Secret as a policy key. For the following instructions, use the directory with your Azure AD B2C tenant.

+2. In the portal toolbar, select **Directories + subscriptions**.

+3. On the **Portal settings | Directories + subscriptions** page, in the **Directory name** list, locate the Azure AD B2C directory.

+4. Select **Switch**.

+5. On the Overview page, under **Policies**, select **Identity Experience Framework**.

+6. Select **Policy Keys**.

+7. Select **Add**.

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

+9. Enter a **Name**. The prefix `B2C_1A_` appends to the key name.

+10. In **Secret**, enter the Client Secret you recorded.

+11. For **Key usage**, select **Signature**.

+12. Select **Create**.

+## Configure BindID as an identity provider

+To enable sign in with BindID, define BindID as a claims provider that Azure AD B2C communicates with through an endpoint. The endpoint provides claims used by Azure AD B2C to verify a user authenticated with digital identity on a device.

+Add BindID as a claims provider. To get started, obtain the custom policy starter packs from GitHub, then update the XML files in the SocialAndLocalAccounts starter pack with your Azure AD B2C tenant name:

+1. Open the zip folder [active-directory-b2c-custom-policy-starterpack-main.zip](https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/archive/master.zip) or clone the repository:

+

+ ```

+ git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack

+ ```

+2. In the files in the **LocalAccounts** directory, replace the string `yourtenant` with the Azure AD B2C tenant name.

+3. Open the `LocalAccounts/ TrustFrameworkExtensions.xml`.

+4. Find the **ClaimsProviders** element. If it doesn't appear, add it under the root element.

+5. Add a new **ClaimsProvider** similar to the following example:

+6. Set **client_id** with the BindID Application ID you recorded.

+7. Select **Save**.

+## Add a user journey

+The identity provider isn't on the sign-in pages. If you have a custom user journey, continue to **Add the identity provider to a user journey**, otherwise, create a duplicate template user journey:

+1. From the starter pack, open the `LocalAccounts/ TrustFrameworkBase.xml` file.

+2. Find and copy the contents of the **UserJourney** element that includes `Id=SignUpOrSignIn`.

+3. Open the `LocalAccounts/ TrustFrameworkExtensions.xml`.

+4. Find the **UserJourneys** element. If there's no element, add one.

+5. Paste the UserJourney element as a child of the UserJourneys element.

+6. Rename the user journey **ID**.

+## Add the identity provider to a user journey

+Add the new identity provider to the user journey.

+1. Find the orchestration step element that includes `Type=CombinedSignInAndSignUp`, or `Type=ClaimsProviderSelection` in the user journey. It's usually the first orchestration step. The **ClaimsProviderSelections** element has an identity provider list that users sign in with. The order of the elements controls the order of the sign in buttons.

+2. Add a **ClaimsProviderSelection** XML element.

+3. Set the value of **TargetClaimsExchangeId** to a friendly name.

+4. Add a **ClaimsExchange** element.

+5. Set the **Id** to the value of the target claims exchange ID. This action links the BindID button to `BindID-SignIn`.

+6. Update the **TechnicalProfileReferenceId** value to the technical profile ID you created.

+The following XML demonstrates orchestration user journey with the identity provider.

+## Configure the relying party policy

+The relying party policy, for example SignUpOrSignIn.xml, specifies the user journey Azure AD B2C executes. You can control claims passed to your application by adjusting the **OutputClaims** element of the **PolicyProfile** TechnicalProfile element. In this tutorial, the application receives the user attributes such as display name, given name, surname, email, objectId, identity provider, and tenantId.

+See, [Azure-Samples/active-directory-b2c-custom-policy-starterpack](https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/master/LocalAccounts/SignUpOrSignin.xml)

+## Upload the custom policy

+2. In the portal toolbar, select **Directories + subscriptions**.

+3. On the **Portal settings | Directories + subscriptions** page, in the **Directory name** list, find the Azure AD B2C directory.

+4. Select **Switch**.

+5. In the Azure portal, search for and select **Azure AD B2C**.

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

+7. Select **Upload Custom Policy**.

+8. Upload the files in the **LocalAccounts** starter pack in the following order:

+ * Base policy, for example `TrustFrameworkBase.xml`

+ * Localization policy, for example `TrustFrameworkLocalization.xml`

+ * Extension policy, for example `TrustFrameworkExtensions.xml`

+ * Relying party policy, such as `SignUpOrSignIn.xml`

+## Test your custom policy

+For the following instructions, use the directory with your Azure AD B2C tenant.

+1. In the Azure AD B2C tenant, and under **Policies**, select **Identity Experience Framework**.

+2. Under **Custom policies**, select **B2C_1A_signup_signin**.

+3. For **Application**, select the web application you registered. The **Reply URL** is `https://jwt.ms`.

+4. Select **Run now**.

+5. The browser is redirected to the BindID sign in page.

+6. Enter the registered account email.

+7. Authenticate using appless FIDO2 biometrics, such as fingerprint.

+8. The browser is redirect to `https://jwt.ms`. The token contents, returned by Azure AD B2C, appear.

+- [Azure AD B2C custom policy overview](custom-policy-overview.md)

+- [Tutorial: Create user flows and custom policies in Azure Active Directory B2C](tutorial-create-user-flows.md?pivots=b2c-custom-policy)

+- [TransmitSecurity/azure-ad-b2c-bindid-integration](https://github.com/TransmitSecurity/azure-ad-b2c-bindid-integration) See, Azure AD B2C Integration

+ g. **REGEX MATCH**. Clause returns "true" if the evaluated attribute matches a regular expression pattern. For example: `([1-9][0-9])` matches any number between 10 and 99 (case sensitive).

+|userPrincipalName|REGEX MATCH|`.\*@domain.com`|All users with userPrincipal that has the domain @domain.com will be in scope for provisioning|

+|userPrincipalName|NOT REGEX MATCH|`.\*@domain.com`|All users with userPrincipal that has the domain @domain.com will be out of scope for provisioning|

+|department|EQUALS|`sales`|All users from the sales department are in scope for provisioning|

+|workerID|REGEX MATCH|`(1[0-9][0-9][0-9][0-9][0-9][0-9])`| All employees with workerIDs between 1000000 and 2000000 are in scope for provisioning.|

+[Azure Active Directory user provisioning service](../app-provisioning/user-provisioning.md) integrates with [SAP SuccessFactors Employee Central](https://www.successfactors.com/products-services/core-hr-payroll/employee-central.html) to manage the identity life cycle of users. Azure Active Directory offers three prebuilt integrations:

+> During the full initial sync, both active and terminated workers from SAP SuccessFactors are fetched.

+To validate the data returned by your OData API endpoint for a specific `personIdExternal`, update the `SuccessFactorsAPIEndpoint` in the API query with your API data center server URL and use a tool like [Postman](https://www.postman.com/downloads/) to invoke the query. If the "in" filter doesn't work, you can try the "eq" filter.

+Here's the OData API request template that Azure AD uses to query SuccessFactors for incremental changes. You can update the variables `SuccessFactorsAPIEndpoint`, `LastExecutionTimestamp` and `CurrentExecutionTime` in the request template use a tool like [Postman](https://www.postman.com/downloads/) to check what data is returned. Alternatively, you can also retrieve the actual request payload from SuccessFactors by [enabling OData API Audit logs](#enabling-odata-api-audit-logs-in-successfactors).

+ > If the **Edit attribute list for SuccessFactors** option doesn't show in the Azure portal, use the URL *https://portal.azure.com/?Microsoft_AAD_IAM_forceSchemaEditorEnabled=true* to access the page.

+The default Azure AD SuccessFactors provisioning app schema ships with [90+ predefined attributes](sap-successfactors-attribute-reference.md).

+By default, the following custom attributes are predefined in the Azure AD SuccessFactors provisioning app:

+1. There's a known issue where the connector may disable the account of a terminated worker one day prior to the termination on the last day of work. The issue is documented in [knowledge base article 3047486](https://launchpad.support.sap.com/#/notes/3047486).

+1. If the `PersonEmpTerminationInfo` object gets set to null, during termination, then AD account disabling doesn't work because the provisioning engine filters out records where the `personEmpTerminationInfoNav` object is set to null.

+If you're running into any of these issues or prefer mapping employment status to account status, you can update the mapping to expand the `emplStatus` field and use the employment status code present in the field `emplStatus.externalCode`. Based on [SAP support note 2505526](https://launchpad.support.sap.com/#/notes/2505526), here's a list of employment status codes that you can retrieve in the provisioning app.

+1. Find the attribute `emplStatus` and update the JSONPath to `$.employmentNav.results[0].jobInfoNav.results[0].emplStatusNav.externalCode`. The update makes the connector retrieve the employment status codes in the table.

+You can handle both scenarios so that the new employment data shows up when a conversion or rehire occurs. Bulk update the provisioning app schema using the steps listed:

+> The approach described above only works if SAP SuccessFactors returns the employment objects in ascending order, where the latest employment record is always the last record in the *employmentNav* results array. The order in which multiple employment records are returned isn't guaranteed by SuccessFactors. If your SuccessFactors instance has multiple employment records corresponding to a worker and you always want to retrieve attributes associated with the active employment record, use steps described in the next section.

+1. Perform the following find replace operations. Ensure there's no leading or trailing space when performing the find-replace operations. If you're using `[-1:]` index instead of `[0]`, then update the *string-to-find* field accordingly.

+ | `$.employmentNav.results\[0\].<br>jobInfoNav.results\[0\].emplStatus` | `$.employmentNav..jobInfoNav..results\[?(@.emplStatusNav.externalCode == 'A' \|\| @.emplStatusNav.externalCode == 'U' \|\| @.emplStatusNav.externalCode == 'P' )\].emplStatusNav.externalCode` | With this find-replace, we're adding the ability to expand emplStatusNav OData object. |

+ | `$.employmentNav.results\[0\].<br>jobInfoNav.results\[0\]` | `$.employmentNav..jobInfoNav..results\[?(@.emplStatusNav.externalCode == 'A' \|\| @.emplStatusNav.externalCode == 'U' \|\| @.emplStatusNav.externalCode == 'P')\]` | With this find-replace, we instruct the connector to always retrieve attributes associated with the active SuccessFactors EmpJobInfo record. Attributes associated with terminated/inactive records in SuccessFactors are ignored. |

+ | `$.employmentNav.results\[0\]` | `$.employmentNav..results\[?(@.jobInfoNav..results\[?(@.emplStatusNav.externalCode == 'A' \|\| @.emplStatusNav.externalCode == 'U' \|\| @.emplStatusNav.externalCode == 'P')\])\]` | With this find-replace, we instruct the connector to always retrieve attributes associated with the active SuccessFactors Employment record. Attributes associated with terminated/inactive records in SuccessFactors are ignored. |

+1. For prehire processing to work, the JSONPath associated with `startDate` attribute must use either `[0]` or `[-1:]` index. Under **Show advanced options**, click on **Edit SuccessFactors attribute list**. Find the attribute `startDate` and set it to the value `$.employmentNav.results[-1:].startDate`

+1. Let's say you want to pull the department associated with job 1 and job 2. The predefined attribute *department* already fetches the value of department for the first job. You can define a new attribute called *secondJobDepartment* and set the JSONPath expression to `$.employmentNav.results[1].jobInfoNav.results[0].departmentNav.name_localized`

+Inbound user provisioning from SAP SuccessFactors to on premises Active Directory and Azure AD now supports advance provisioning of prehires present in the SAP SuccessFactors Onboarding 2.0 module. When the Azure AD provisioning service encounters a new hire profile with a future start date, it queries SAP SuccessFactors to get new hires with one of the following status codes: `active`, `inactive`, `active_external_suite`. The status code `active_external_suite` corresponds to prehires present in the SAP SuccessFactors Onboarding 2.0 module. For a description of these status codes, refer to [SAP support note 2736579](https://launchpad.support.sap.com/#/notes/0002736579).

+The default behavior of the provisioning service is to process prehires in the Onboarding module.

+If you want to exclude processing of prehires in the Onboarding module, update your provisioning job configuration as follows:

+1. Edit the Source Object scope to apply a scoping filter `userStatus NOT EQUALS`

+The Azure AD SuccessFactors connector uses SuccessFactors OData API to retrieve changes and provision users. If you observe issues with the provisioning service and want to confirm what data was retrieved from SuccessFactors, you can enable OData API Audit logs in SuccessFactors. To enable audit logs, follow the steps documented in [SAP support note 2680837](https://userapps.support.sap.com/sap/support/knowledge/en/2680837). Retrieve the request payload sent by Azure AD from the audit logs. To troubleshoot, you can copy this request payload in a tool like [Postman](https://www.postman.com/downloads/), set it up to use the same API user that is used by the connector and see if it returns the desired changes from SuccessFactors.

+| 4 | * In SuccessFactors business email is primary. <br> * In Azure AD, check if work telephone number is present, if present, then check if mobile number is also present. Mark work telephone number as primary only if mobile number isn't present. | true | Use expression mapping: `IIF(IsPresent([telephoneNumber]), IIF(IsPresent([mobile]),"false", "true"), "false")` | Use expression mapping: `IIF(IsPresent([mobile]),"false", "true")` | telephoneNumber | mobile |

+* If there's no mapping for phone number in the write-back attribute-mapping, then only email is included in the write-back.

+* During new hire onboarding in Employee Central, business email and phone number may not be available. If setting business email and business phone as primary is mandatory during onboarding, you can set a dummy value for business phone and email during new hire creation. After some time, the write-back app updates the value.

+* As a first step, it looks for *userId* attribute in the changeset. If it's present, then it uses "UserId" for making the SuccessFactors API call.

+* If *userId* isn't found, then it defaults to using the *personIdExternal* attribute value.

+Usually the *personIdExternal* attribute value in SuccessFactors matches the *userId* attribute value. However, in scenarios such as rehiring and worker conversion, an employee in SuccessFactors may have two employment records, one active and one inactive. In such scenarios, to ensure that write-back updates the active user profile, update the configuration of the SuccessFactors provisioning apps as described. This configuration ensures that *userId* is always present in the changeset visible to the connector and is used in the SuccessFactors API call.

+1. Ensure that `extensionAttribute[1-15]` in Azure AD always stores the `userId` of every worker's active employment record. The record maps SuccessFactors `userId` attribute to `extensionAttribute[1-15]` in Azure AD.

+ > If you're using SuccessFactors to on-premises Active Directory user provisioning, configure AAD Connect to sync the *userId* attribute value from on-premises Active Directory to Azure AD.

+1. In the schema editor, hit Ctrl-F and search for the JSON node containing the userId mapping, where it's mapped to a source Azure AD attribute.

+* In Employee Central, during onboarding personal email and personal phone is set as primary. The write-back app can't switch this setting and set business email and business phone as primary.

+* In Employee Central, business phone is set as primary. The write-back app can't change this and set cell phone as primary.

+* The write-back app can't read the current primary flag settings and use the same values for the write operation. The flag values configured in the attribute-mapping are always be used.

+[Azure Active Directory user provisioning service](../app-provisioning/user-provisioning.md) integrates with [Workday HCM](https://www.workday.com) to manage the identity life cycle of users. Azure Active Directory offers three prebuilt integrations:

+1. Access the **Manage Authentication Policies** task to create a new authentication policy. In the authentication policy, use the authentication allowlist to specify the Azure AD IP range and the security group that will be allowed access from this IP range. Save the changes.

+You can limit access by working with your Workday admin and configuring constrained integration system security groups. For more information about Workday, see [Workday community](https://community.workday.com/forums/customer-questions/620393) (*Workday Community access required for this article*).

+| \# | Workday Entity | Included by default | XPATH pattern to specify in mapping to fetch nondefault entities |

+1. Add the following attributes definitions and mark them as "Required". These attributes won't be mapped to any attribute in AD or Azure AD. They just serve as signals to the connector to retrieve the Cost Center, Cost Center Hierarchy and Pay Group information.

+* It's January 15, 2023 and Jane Doe is employed as a contingent worker. HR offers Jane a full-time position.

+* The terms of Jane's contract change require backdating the transaction so it aligns with the start of the current month. HR initiates a backdated worker conversion transaction Workday on January 15, 2023 with effective date as January 1, 2023. Now there are two worker profiles in Workday for Jane. The CW profile is inactive, while the FTE profile is active.

+* The Azure AD provisioning service will detect this change in the Workday transaction log on January 15, 2023 and automatically provision attributes of the new FTE profile in the next sync cycle.

+* It's January 1, 2023 and John Smith starts work at as a contingent worker. As there's no AD account associated with John's *WorkerID* (matching attribute), the provisioning service creates a new AD account and links John's contingent worker *WID (WorkdayID)* to John's AD account.

+* John's contract ends on January 31, 2023. In the provisioning cycle that runs after end of day January 31, John's AD account is disabled.

+* John applies for another position and decides to rejoin the company as full-time employee effective May 1, 2023. HR enters John's information as a prehire employee on April 15, 2023. Now there are two worker profiles in Workday for John. The CW profile is inactive, while the FTE profile is active. The two records have the same *WorkerID* but different *WID*s.

+* On April 15, during incremental cycle, the Azure AD provisioning service automatically transfers ownership of the AD account to the active worker profile. In this case, it unlinks the contingent worker profile from the AD account and establishes a new link between John's active employee worker profile and John's AD account.

+* It's January 1, 2023 and John Smith starts work at as a contingent worker. As there's no AD account associated with John's *WorkerID* (matching attribute), the provisioning service creates a new AD account and links John's contingent worker *WID (WorkdayID)* to John's AD account.

+* On January 15, HR initiates a transaction to convert John from contingent worker to full-time employee effective February 1, 2023.

+* Since Azure AD provisioning service automatically processes future-dated hires, it will process John's new full-time employee worker profile on January 15, and update John's profile in AD with full-time employment details even though he's still a contingent worker.

+* To avoid this behavior and ensure that John's FTE details get provisioned on February 1, 2023, perform the following configuration changes.

+For more information about validating the claims in a token to ensure security, see [Secure applications and APIs by validating claims](claims-validation.md)

+ Title: Secure applications and APIs by validating claims

+description: Learn about securing the business logic of your applications and APIs by validating claims in tokens.

+# Secure applications and APIs by validating claims

+Interacting with tokens is a core piece of building applications to authorize users. In accordance with the [Zero Trust principle](zero-trust-for-developers.md) for least privileged access, it's essential that applications validate the values of certain claims present in the access token when performing authorization.

+Claims based authorization allows applications to ensure that the token contains the correct values for things such as the tenant, subject, and actor present in the token. That being said, claims based authorization can seem complex given the various methods to utilize and scenarios to keep track of. This article intends to simplify the claims based authorization process so that you can ensure your applications adhere to the most secure practices.

+To make sure that your authorization logic is secure, you must validate the following information in claims:

+* The appropriate audience is specified for the token.

+* The tenant ID of the token matches the ID of the tenant where data is stored.

+* The subject of the token is appropriate.

+* The actor (client app) is authorized.

+> [!NOTE]

+>Access tokens are only validated in the web APIs for which they were acquired by a client. The client should not validate access tokens.

+For more information about the claims mentioned in this article, see [Microsoft identity platform access tokens](access-tokens.md).

+## Validate the audience

+The `aud` claim identifies the intended audience of the token. Before validating claims, you must always verify that the value of the `aud` claim contained in the access token matches the Web API. The value can depend on how the client requested the token. The audience in the access token depends on the endpoint:

+* For v2.0 tokens, the audience is the client ID of the web API. It's a GUID.

+* For v1.0 tokens, the audience is one of the appID URIs declared in the web API that validates the token. For example,

+`api://{ApplicationID}`, or a unique name starting with a domain name (if the domain name is associated with a tenant).

+For more information about the appID URI of an application, see [Application ID URI](security-best-practices-for-app-registration.md#application-id-uri).

+## Validate the tenant

+Always check that the `tid` in a token matches the tenant ID used to store data with the application. When information is stored for an application in the context of a tenant, it should only be accessed again later in the same tenant. Never allow data in one tenant to be accessed from another tenant.

+## Validate the subject

+Determine if the token subject, such as the user (or application itself for an app-only token), is authorized.

+You can either check for specific `sub` or `oid` claims.

+Or,

+You can check that the subject belongs to an appropriate role or group with the `roles`, `groups`, `wids` claims. For example, use the immutable claim values `tid` and `oid` as a combined key for application data and determining whether a user should be granted access.

+The `roles`, `groups` or `wids` claims can also be used to determine if the subject has authorization to perform an operation. For example, an administrator may have permission to write to an API, but not a normal user, or the user may be in a group allowed to do some action. The `wid` claim represents the tenant-wide roles assigned to the user from the roles present in the Azure AD built-in roles. For more information, see [Azure AD built-in roles](../roles/permissions-reference.md).

+> [!WARNING]

+> Never use claims like `email`, `preferred_username` or `unique_name` to store or determine whether the user in an access token should have access to data. These claims are not unique and can be controllable by tenant administrators or sometimes users, which makes them unsuitable for authorization decisions. They are only usable for display purposes. Also don't use the `upn` claim for authorization. While the UPN is unique, it often changes over the lifetime of a user principal, which makes it unreliable for authorization.

+## Validate the actor

+A client application that's acting on behalf of a user (referred to as the *actor*), must also be authorized. Use the `scp` claim (scope) to validate that the application has permission to perform an operation. The permissions in `scp` should be limited to what the user actually needs and follows the principles of [least privilege](secure-least-privileged-access.md).

+However, there are known scenarios where `scp` isn't present in the token:

+* Daemon apps / app only permission - validate the role claims instead of the `scp` claim.

+* A separate role-based access control system is used - validate roles instead of `scp`.

+For more information about scopes and permissions, see [Scopes and permissions in the Microsoft identity platform](scopes-oidc.md).

+> [!NOTE]

+> An application may handle app-only tokens (requests from applications without users, such as daemon apps) and want to authorize a specific application across multiple tenants, rather than individual service principal IDs. In that case, the `appid` claim (for v1.0 tokens) or the `azp` claim (for v2.0 tokens) can be used for subject authorization. However, when using these claims, the application must ensure that the token was issued directly for the application by validating the `idtyp` optional claim. Only tokens of type `app` can be authorized this way, as delegated user tokens can potentially be obtained by entities other than the application.

+## Next steps

+* Learn more about tokens and claims in [Security tokens](security-tokens.md)

+View the [Authentication Events Trigger for Azure Functions sample app](https://github.com/Azure/azure-docs-sdk-dotnet/blob/live/api/overview/azure/preview/microsoft.azure.webjobs.extensions.authenticationevents-readme.md).

+## April 2023

+### Updated articles

+- [Allow or block domains](allow-deny-list.md) Screenshots were updated.

+- [Authentication and Conditional Access](authentication-conditional-access.md) Links to other articles were updated.

+- [Code and Azure PowerShell samples](code-samples.md) Minor text updates.

+- [Azure Active Directory](azure-ad-account.md) Minor text updates.

+## April 2023

+### Public Preview - Custom attributes for Azure Active Directory Domain Services

+**Type:** New feature

+**Service category:** Azure Active Directory Domain Services

+**Product capability:** Azure Active Directory Domain Services

+Azure Active Directory Domain Services will now support synchronizing custom attributes from Azure AD for on-premises accounts. For more information, see: [Custom attributes for Azure Active Directory Domain Services](/azure/active-directory-domain-services/concepts-custom-attributes).

+### General Availability - Enablement of combined security information registration for MFA and self-service password reset (SSPR)

+**Type:** New feature

+**Service category:** MFA

+**Product capability:** Identity Security & Protection

+Last year we announced the combined registration user experience for MFA and self-service password reset (SSPR) was rolling out as the default experience for all organizations. We're happy to announce that the combined security information registration experience is now fully rolled out. This change doesn't affect tenants located in the China region. For more information, see: [Combined security information registration for Azure Active Directory overview](../authentication/concept-registration-mfa-sspr-combined.md).

+### General Availability - PIM alert: Alert on active-permanent role assignments in Azure or assignments made outside of PIM

+**Type:** Fixed

+**Service category:** Privileged Identity Management

+**Product capability:** Privileged Identity Management

+[Alert on Azure subscription role assignments made outside of Privileged Identity Management (PIM)](../privileged-identity-management/pim-resource-roles-configure-alerts.md) provides an alert in PIM for Azure subscription assignments made outside of PIM. An owner or User Access Administrator can take a quick remediation action to remove those assignments.

+### Public Preview - Enhanced Create User and Invite User Experiences

+**Type:** Changed feature

+**Service category:** User Management

+**Product capability:** User Management

+Admins can now define more properties when creating and inviting a user in the Entra admin portal. These improvements bring our UX to parity with our [Create User APIS](/graph/api/user-post-users). Additionally, admins can now add users to a group or administrative unit, as well as assign roles. For more information, see: [Add or delete users using Azure Active Directory](../fundamentals/add-users-azure-active-directory.md).

+### Public Preview - Azure AD Conditional Access protected actions

+**Type:** Changed feature

+**Service category:** RBAC

+**Product capability:** Access Control

+The protected actions public preview introduces the ability to apply Conditional Access to select permissions. When a user performs a protected action, they must satisfy Conditional Access policy requirements. For more information, see: [What are protected actions in Azure AD? (preview)](../roles/protected-actions-overview.md).

+### Public Preview - Token Protection for Sign-in Sessions

+**Type:** New feature

+**Service category:** Conditional Access

+**Product capability:** User Authentication

+Token Protection for sign-in sessions is our first release on a road-map to combat attacks involving token theft and replay. It provides conditional access enforcement of token proof-of-possession for supported clients and services that ensures that access to specified resources is only from a device to which the user has signed in. For more information, see: [Conditional Access: Token protection (preview)](../conditional-access/concept-token-protection.md).

+### General Availability- New limits on number and size of group secrets starting June 2023

+**Type:** Plan for change

+**Service category:** Group Management

+**Product capability:** Directory

+Starting in June 2023, the secrets stored on a single group can't exceed 48 individual secrets, or have a total size greater than 10KB across all secrets on a single group. Groups with more than 10KB of secrets will immediately stop working in June 2023. In June, groups exceeding 48 secrets are unable to increase the number of secrets they have, though they may still update or delete those secrets. We highly recommend reducing to fewer than 48 secrets by January 2024.

+Group secrets are typically created when a group is assigned credentials to an app using Password-based single sign-on. To reduce the number of secrets assigned to a group, we recommend creating additional groups, and splitting up group assignments to your Password-based SSO applications across those new groups. For more information, see: [Add password-based single sign-on to an application](../manage-apps/configure-password-single-sign-on-non-gallery-applications.md).

+### Public Preview - Authenticator Lite in Outlook

+**Type:** New feature

+**Service category:** Microsoft Authenticator App

+**Product capability:** User Authentication

+Authenticator Lite is an additional surface for AAD users to complete multifactor authentication using push notifications on their Android or iOS device. With Authenticator Lite, users can satisfy a multifactor authentication requirement from the convenience of a familiar app. Authenticator Lite is currently enabled in the Outlook mobile app. Users may receive a notification in their Outlook mobile app to approve or deny, or use the Outlook app to generate an OATH verification code that can be entered during sign-in. The *'Microsoft managed'* setting for this feature will be set to enabled on May 26th, 2023. This will enable the feature for all users in tenants where the feature is set to Microsoft managed. If you wish to change the state of this feature, please do so before May 26th, 2023. For more information, see: [How to enable Microsoft Authenticator Lite for Outlook mobile (preview)](../authentication/how-to-mfa-authenticator-lite.md).

+### General Availability - Updated look and feel for Per-user MFA

+**Type:** Plan for change

+**Service category:** MFA

+**Product capability:** Identity Security & Protection

+As part of ongoing service improvements, we are making updates to the per-user MFA admin configuration experience to align with the look and feel of Azure. This change does not include any changes to the core functionality and will only include visual improvements.  For more information, see: [Enable per-user Azure AD Multi-Factor Authentication to secure sign-in events](../authentication/howto-mfa-userstates.md).

+### General Availability - Additional terms of use audit logs will be turned off

+**Type:** Fixed

+**Service category:** Terms of Use

+**Product capability:** AuthZ/Access Delegation

+Due to a technical issue, we have recently started to emit additional audit logs for terms of use. The additional audit logs will be turned off by the first of May and are tagged with the core directory service and the agreement category. If you have built a dependency on the additional audit logs, you must switch to the regular audit logs tagged with the terms of use service.

+### General Availability - New Federated Apps available in Azure AD Application gallery - April 2023

+**Type:** New feature

+**Service category:** Enterprise Apps

+**Product capability:** 3rd Party Integration

+In April 2023 we've added the following 10 new applications in our App gallery with Federation support:

+[iTel Alert](https://www.itelalert.nl/), [goFLUENT](../saas-apps/gofluent-tutorial.md), [StructureFlow](https://app.structureflow.co/), [StructureFlow AU](https://au.structureflow.co/), [StructureFlow CA](https://ca.structureflow.co/), [StructureFlow EU](https://eu.structureflow.co/), [StructureFlow USA](https://us.structureflow.co/), [Predict360 SSO](../saas-apps/predict360-sso-tutorial.md), [Cegid Cloud](https://www.cegid.com/fr/nos-produits/), [HashiCorp Cloud Platform (HCP)](../saas-apps/hashicorp-cloud-platform-hcp-tutorial.md), [O'Reilly learning platform](../saas-apps/oreilly-learning-platform-tutorial.md), [LeftClick Web Services ΓÇô RoomGuide](https://www.leftclick.cloud/digital_signage), [LeftClick Web Services ΓÇô Sharepoint](https://www.leftclick.cloud/digital_signage), [LeftClick Web Services ΓÇô Presence](https://www.leftclick.cloud/presence), [LeftClick Web Services - Single Sign-On](https://www.leftclick.cloud/presence), [InterPrice Technologies](http://www.interpricetech.com/), [WiggleDesk SSO](https://wiggledesk.com/), [Application Experience with Mist](https://www.mist.com/), [Connect Plans 360](https://connectplans360.com.au/), [Proactis Rego Source-to-Contract](../saas-apps/proactis-rego-source-to-contract-tutorial.md), [Danomics](https://www.danomics.com/), [Fountain](../saas-apps/fountain-tutorial.md), [Theom](../saas-apps/theom-tutorial.md), [DDC Web](../saas-apps/ddc-web-tutorial.md), [Dozuki](../saas-apps/dozuki-tutorial.md).

+You can also find the documentation of all the applications from here https://aka.ms/AppsTutorial.

+For listing your application in the Azure AD app gallery, read the details here https://aka.ms/AzureADAppRequest

+### Public Preview - New provisioning connectors in the Azure AD Application Gallery - April 2023

+**Type:** New feature

+**Service category:** App Provisioning

+**Product capability:** 3rd Party Integration

+

+We've added the following new applications in our App gallery with Provisioning support. You can now automate creating, updating, and deleting of user accounts for these newly integrated apps:

+- [Alvao](../saas-apps/alvao-provisioning-tutorial.md)

+- [Better Stack](../saas-apps/better-stack-provisioning-tutorial.md)

+- [BIS](../saas-apps/bis-provisioning-tutorial.md)

+- [Connecter](../saas-apps/connecter-provisioning-tutorial.md)

+- [Howspace](../saas-apps/howspace-provisioning-tutorial.md)

+- [Kno2fy](../saas-apps/kno2fy-provisioning-tutorial.md)

+- [Netsparker Enterprise](../saas-apps/netsparker-enterprise-provisioning-tutorial.md)

+- [uniFLOW Online](../saas-apps/uniflow-online-provisioning-tutorial.md)

+For more information about how to better secure your organization by using automated user account provisioning, see: [Automate user provisioning to SaaS applications with Azure AD](../app-provisioning/user-provisioning.md).

+### Public Preview - New PIM Azure resource picker

+**Type:** Changed feature

+**Service category:** Privileged Identity Management

+**Product capability:** End User Experiences

+With this new experience, PIM now automatically manages any type of resource in a tenant, so discovery and activation is no longer required. With the new resource picker, users can directly choose the scope they want to manage from the Management Group down to the resources themselves, making it faster and easier to locate the resources they need to administer. For more information, see: [Assign Azure resource roles in Privileged Identity Management](../privileged-identity-management/pim-resource-roles-assign-roles.md).

+### General availability - Self Service Password Reset (SSPR) now supports PIM eligible users and indirect group role assignment

+**Type:** Changed feature

+**Service category:** Self Service Password Reset

+**Product capability:** Identity Security & Protection

+Self Service Password Reset (SSPR) can now PIM eligible users, and evaluate group-based memberships, along with direct memberships when checking if a user is in a particular administrator role. This capability provides more accurate SSPR policy enforcement by validating if users are in scope for the default SSPR admin policy or your organizations SSPR user policy.

+For more information, see:

+- [Administrator reset policy differences](../authentication/concept-sspr-policy.md#administrator-reset-policy-differences).

+- [Create a role-assignable group in Azure Active Directory](../roles/groups-create-eligible.md)

+- To generate a `lastSignInDateTime` timestamp, you must attempt a sign-in. Either a failed or successful sign-in attempt, as long as it is recorded in the [Azure AD sign-in logs](concept-all-sign-ins.md), will generate a `lastSignInDateTime` timestamp. The value of the `lastSignInDateTime` property may be blank if:

+ Title: Azure Active Directory SSO integration with Alchemer

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

+# Azure Active Directory SSO integration with Alchemer

+In this article, you learn how to integrate Alchemer with Azure Active Directory (Azure AD). Alchemer offers the worldΓÇÖs most flexible feedback and data collection platform that allows organizations to close the loop with their customers and employees quickly and effectively. When you integrate Alchemer with Azure AD, you can:

+* Control in Azure AD who has access to Alchemer.

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

+* Manage your accounts in one central location - the Azure portal.

+You configure and test Azure AD single sign-on for Alchemer in a test environment. Alchemer supports both **SP** and **IDP** initiated single sign-on and Just In Time user provisioning.

+## Prerequisites

+To integrate Azure Active Directory with Alchemer, you need:

+* An Azure AD user account. If you don't already have one, you can [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

+* One of the following roles: Global Administrator, Cloud Application Administrator, Application Administrator, or owner of the service principal.

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

+* Alchemer single sign-on (SSO) enabled subscription.

+## Add application and assign a test user

+Before you begin the process of configuring single sign-on, you need to add the Alchemer application from the Azure AD gallery. You need a test user account to assign to the application and test the single sign-on configuration.

+### Add Alchemer from the Azure AD gallery

+Add Alchemer from the Azure AD application gallery to configure single sign-on with Alchemer. For more information on how to add application from the gallery, see the [Quickstart: Add application from the gallery](../manage-apps/add-application-portal.md).

+### Create and assign Azure AD test user

+Follow the guidelines in the [create and assign a user account](../manage-apps/add-application-portal-assign-users.md) article to create a test user account in the Azure portal called B.Simon.

+Alternatively, you can also use the [Enterprise App Configuration Wizard](https://portal.office.com/AdminPortal/home?Q=Docs#/azureadappintegration). In this wizard, you can add an application to your tenant, add users/groups to the app, and assign roles. The wizard also provides a link to the single sign-on configuration pane in the Azure portal. [Learn more about Microsoft 365 wizards.](/microsoft-365/admin/misc/azure-ad-setup-guides).

+## Configure Azure AD SSO

+Complete the following steps to enable Azure AD single sign-on in the Azure portal.

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

+1. On the **Select a single sign-on method** page, select **SAML**.

+1. On the **Set up single sign-on with SAML** page, select the pencil icon for **Basic SAML Configuration** to edit the settings.

+ 

+1. On the **Basic SAML Configuration** section, perform the following steps:

+ a. In the **Identifier** textbox, type a URL using the following pattern:

+ `https://app.alchemer.com/login/getsamlxml/idp/<INSTANCE>`

+ b. In the **Reply URL** textbox, type a URL using the following pattern:

+ `https://app.alchemer.com/login/ssologin/idp/<INSTANCE>`

+1. If you wish to configure the application in **SP** initiated mode, then perform the following step:

+ In the **Sign on URL** textbox, type a URL using the following pattern:

+ `https://app.alchemer.com/login/initiatelogin/idp/<INSTANCE>`

+ > [!NOTE]

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

+1. On the **Set-up single sign-on with SAML** page, in the **SAML Signing Certificate** section, find **Certificate (Raw)** and select **Download** to download the certificate and save it on your computer.

+ 

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

+ 

+## Configure Alchemer SSO

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

+### Create Alchemer test user

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

+## Test SSO

+In this section, you test your Azure AD single sign-on configuration with following options.

+#### SP initiated:

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

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

+#### IDP initiated:

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

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

+## Additional resources

+* [What is single sign-on with Azure Active Directory?](../manage-apps/what-is-single-sign-on.md)

+* [Plan a single sign-on deployment](../manage-apps/plan-sso-deployment.md).

+## Next steps

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

+1. Find your **Tenant SCIM Endpoint URL**, which should have the format `{ALVAO REST API address}/scim` (for example, https://app.contoso.com/alvaorestapi/scim).

+ Title: Azure Active Directory SSO integration with CMD+CTRL Base Camp

+description: Learn how to configure single sign-on between Azure Active Directory and CMD+CTRL Base Camp.

+# Azure Active Directory SSO integration with CMD+CTRL Base Camp

+In this article, you learn how to integrate CMD+CTRL Base Camp with Azure Active Directory (Azure AD). CMD+CTRL Base Camp is a unique learning platform that combines our modes of software security training courses, labs, and cyber ranges into an engaging and effective integrated learner experience. When you integrate CMD+CTRL Base Camp with Azure AD, you can:

+* Control in Azure AD who has access to CMD+CTRL Base Camp.

+* Enable your users to be automatically signed-in to CMD+CTRL Base Camp with their Azure AD accounts.

+* Manage your accounts in one central location - the Azure portal.

+You configure and test Azure AD single sign-on for CMD+CTRL Base Camp in a test environment. CMD+CTRL Base Camp supports **SP** initiated single sign-on and **Just In Time** user provisioning.

+## Prerequisites

+To integrate Azure Active Directory with CMD+CTRL Base Camp, you need:

+* An Azure AD user account. If you don't already have one, you can [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

+* One of the following roles: Global Administrator, Cloud Application Administrator, Application Administrator, or owner of the service principal.

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

+* CMD+CTRL Base Camp single sign-on (SSO) enabled subscription.

+## Add application and assign a test user

+Before you begin the process of configuring single sign-on, you need to add the CMD+CTRL Base Camp application from the Azure AD gallery. You need a test user account to assign to the application and test the single sign-on configuration.

+### Add CMD+CTRL Base Camp from the Azure AD gallery

+Add CMD+CTRL Base Camp from the Azure AD application gallery to configure single sign-on with CMD+CTRL Base Camp. For more information on how to add application from the gallery, see the [Quickstart: Add application from the gallery](../manage-apps/add-application-portal.md).

+### Create and assign Azure AD test user

+Follow the guidelines in the [create and assign a user account](../manage-apps/add-application-portal-assign-users.md) article to create a test user account in the Azure portal called B.Simon.

+Alternatively, you can also use the [Enterprise App Configuration Wizard](https://portal.office.com/AdminPortal/home?Q=Docs#/azureadappintegration). In this wizard, you can add an application to your tenant, add users/groups to the app, and assign roles. The wizard also provides a link to the single sign-on configuration pane in the Azure portal. [Learn more about Microsoft 365 wizards.](/microsoft-365/admin/misc/azure-ad-setup-guides).

+## Configure Azure AD SSO

+Complete the following steps to enable Azure AD single sign-on in the Azure portal.

+1. In the Azure portal, on the **CMD+CTRL Base Camp** application integration page, find the **Manage** section and select **single sign-on**.

+1. On the **Select a single sign-on method** page, select **SAML**.

+1. On the **Set up single sign-on with SAML** page, select the pencil icon for **Basic SAML Configuration** to edit the settings.

+ 

+1. On the **Basic SAML Configuration** section, perform the following steps:

+ a. In the **Identifier** textbox, type a value using the following pattern:

+ `urn:auth0:cmdnctrl:<ConnectionName>`

+ b. In the **Reply URL** textbox, type a URL using the following pattern:

+ `https://login.cmdnctrl.net/login/callback?connection=<ConnectionName>`

+ c. In the **Sign on URL** textbox, type the URL:

+ `https://login.cmdnctrl.net`

+ > [!NOTE]

+ > These values are not real. Update these values with the actual Identifier and Reply URL. Contact [CMD+CTRL Base Camp Client support team](mailto:support@cmdnctrl.net) to get these values. You can also refer to the patterns shown in the **Basic SAML Configuration** section in the Azure portal.

+1. On the **Set-up single sign-on with SAML** page, in the **SAML Signing Certificate** section, find **Federation Metadata XML** and select **Download** to download the certificate and save it on your computer.

+ 

+1. On the **Set up CMD+CTRL Base Camp** section, copy the appropriate URL(s) based on your requirement.

+ 

+## Configure CMD+CTRL Base Camp SSO

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

+### Create CMD+CTRL Base Camp test user

+In this section, a user called B.Simon is created in CMD+CTRL Base Camp. CMD+CTRL Base Camp supports just-in-time user provisioning, which is enabled by default. There's no action item for you in this section. If a user doesn't already exist in CMD+CTRL Base Camp, a new one is commonly created after authentication.

+## Test SSO

+In this section, you test your Azure AD single sign-on configuration with following options.

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

+* Go to CMD+CTRL Base Camp Sign-on URL directly and initiate the login flow from there.

+* You can use Microsoft My Apps. When you click the CMD+CTRL Base Camp tile in the My Apps, this will redirect to CMD+CTRL Base Camp Sign-on URL. For more information about the My Apps, see [Introduction to the My Apps](../user-help/my-apps-portal-end-user-access.md).

+## Additional resources

+* [What is single sign-on with Azure Active Directory?](../manage-apps/what-is-single-sign-on.md)

+* [Plan a single sign-on deployment](../manage-apps/plan-sso-deployment.md).

+## Next steps

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

+ Title: Azure Active Directory SSO integration with Document360

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

+# Azure Active Directory SSO integration with Document360

+In this article, you learn how to integrate Document360 with Azure Active Directory (Azure AD). Document360 is an online self-service knowledge base software. When you integrate Document360 with Azure AD, you can:

+* Control in Azure AD who has access to Document360.

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

+* Manage your accounts in one central location - the Azure portal.

+You configure and test Azure AD single sign-on for Document360 in a test environment. Document360 supports **SP** and **IDP** initiated single sign-on.

+> [!NOTE]

+> Identifier of this application is a fixed string value so only one instance can be configured in one tenant.

+## Prerequisites

+To integrate Azure Active Directory with Document360, you need:

+* An Azure AD user account. If you don't already have one, you can [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

+* One of the following roles: Global Administrator, Cloud Application Administrator, Application Administrator, or owner of the service principal.

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

+* Document360 single sign-on (SSO) enabled subscription.

+## Add application and assign a test user

+Before you begin the process of configuring single sign-on, you need to add the Document360 application from the Azure AD gallery. You need a test user account to assign to the application and test the single sign-on configuration.

+### Add Document360 from the Azure AD gallery

+Add Document360 from the Azure AD application gallery to configure single sign-on with Document360. For more information on how to add application from the gallery, see the [Quickstart: Add application from the gallery](../manage-apps/add-application-portal.md).

+### Create and assign Azure AD test user

+Follow the guidelines in the [create and assign a user account](../manage-apps/add-application-portal-assign-users.md) article to create a test user account in the Azure portal called B.Simon.

+Alternatively, you can also use the [Enterprise App Configuration Wizard](https://portal.office.com/AdminPortal/home?Q=Docs#/azureadappintegration). In this wizard, you can add an application to your tenant, add users/groups to the app, and assign roles. The wizard also provides a link to the single sign-on configuration pane in the Azure portal. [Learn more about Microsoft 365 wizards.](/microsoft-365/admin/misc/azure-ad-setup-guides).

+## Configure Azure AD SSO

+Complete the following steps to enable Azure AD single sign-on in the Azure portal.

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

+1. On the **Select a single sign-on method** page, select **SAML**.

+1. On the **Set up single sign-on with SAML** page, select the pencil icon for **Basic SAML Configuration** to edit the settings.

+ 

+1. On the **Basic SAML Configuration** section, perform the following steps:

+ a. In the **Identifier** textbox, type one of the following URLs:

+ | **Identifier** |

+ |--|

+ | `https://identity.document360.io/saml` |

+ | `https://identity.us.document360.io/saml` |

+ b. In the **Reply URL** textbox, type a URL using one of the following patterns:

+ | **Reply URL** |

+ | -|

+ | `https://identity.document360.io/signin-saml-<ID>` |

+ | `https://identity.us.document360.io/signin-saml-<ID>` |

+1. If you wish to configure the application in **SP** initiated mode, then perform the following step:

+ In the **Sign on URL** textbox, type one of the following URLs:

+ | **Sign on URL** |

+ |--|

+ | `https://identity.document360.io ` |

+ | `https://identity.us.document360.io` |

+ > [!NOTE]

+ > The Reply URL is not real. Update this value with the actual Reply URL. Contact [Document360 Client support team](mailto:support@document360.com) to get the value. You can also refer to the patterns shown in the **Basic SAML Configuration** section in the Azure portal.

+1. On the **Set-up single sign-on with SAML** page, in the **SAML Signing Certificate** section, find **Certificate (Raw)** and select **Download** to download the certificate and save it on your computer.

+ 

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

+ 

+## Configure Document360 SSO

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

+### Create Document360 test user

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

+## Test SSO

+In this section, you test your Azure AD single sign-on configuration with following options.

+#### SP initiated:

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

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

+#### IDP initiated:

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

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

+## Additional resources

+* [What is single sign-on with Azure Active Directory?](../manage-apps/what-is-single-sign-on.md)

+* [Plan a single sign-on deployment](../manage-apps/plan-sso-deployment.md).

+## Next steps

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

+ > These values are not real. Update these values with the actual Sign on URL and Identifier. Contact [EFI Digital StoreFront Client support team](https://www.efi.com/support-and-downloads/) to get these values. You can also refer to the patterns shown in the **Basic SAML Configuration** section in the Azure portal.

+To configure single sign-on on **EFI Digital StoreFront** side, you need to send the downloaded **Federation Metadata XML** and appropriate copied URLs from Azure portal to [EFI Digital StoreFront Client support team](https://www.efi.com/support-and-downloads/). They set this setting to have the SAML SSO connection set properly on both sides.

+In this section, you create a user called Britta Simon in EFI Digital StoreFront. Work with [EFI Digital StoreFront support team](https://www.efi.com/support-and-downloads/) to add the users in the EFI Digital StoreFront platform. Users must be created and activated before you use single sign-on.

+ > These values are not real. Update these values with the actual Identifier, Reply URL, Sign-on URL and Relay State. Contact Grovo Client support team to get these values. You can also refer to the patterns shown in the **Basic SAML Configuration** section in the Azure portal.

+ Title: 'Tutorial: Configure Sign In Enterprise for automatic host provisioning with Azure Active Directory'

+description: Learn how to automatically provision and de-provision hosts from Azure AD to Sign In Enterprise.

+# Tutorial: Configure Sign In Enterprise for automatic host provisioning

+This tutorial describes the steps you need to perform in both Sign In Enterprise and Azure Active Directory (Azure AD) to configure automatic host provisioning. When configured, Azure AD automatically provisions and de-provisions hosts and host groups to [Sign In Enterprise](https://signinenterprise.com) using the Azure AD Provisioning service. For important details on what this service does, how it works, and frequently asked questions, see [Automate user provisioning and deprovisioning to SaaS applications with Azure Active Directory](../app-provisioning/user-provisioning.md).

+> * Create hosts in Sign In Enterprise.

+> * Provision host groups and their memberships in Sign In Enterprise.

+> * Mark hosts as invisible in Sign In Enterprise that are unassigned from the application.

+> * Delete host groups that are unassigned from the application.

+* A user account in Sign In Enterprise with Admin permissions.

+1. Determine what data to [map between Azure AD and Sign In Enterprise](../app-provisioning/customize-application-attributes.md).

+## Step 2. Gather SCIM Host Provisioning information from Sign In Enterprise

+1. Click on the gear icon in the top-right corner of your Sign In Enterprise account.

+1. Click **Preferences**.

+1. In the **General tab**, scroll down until you get to the **SCIM Host Provisioning** section. You will then need to copy both the URL and the Token, which will be needed in Step 5 below.

+Add Sign In Enterprise Host Provisioning from the Azure AD application gallery to start managing provisioning to Sign In Enterprise. If you have previously setup Sign In Enterprise for SSO you can't use the same application. It's required that you create a separate app for Sign In Enterprise Host Provisioning. Learn more about adding an application from the gallery [here](../manage-apps/add-application-portal.md).

+## Step 5. Configure automatic user provisioning to Sign In Enterprise.

+1. Under the **Admin Credentials** section, input your Sign In Enterprise Tenant URL and Token you copied in Step 2. Click **Test Connection** to ensure Azure AD can connect to Sign In Enterprise. If the connection fails, ensure your and try again.

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

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

+1. Review the group attributes that are synchronized from Azure AD to Sign In Enterprise in the **Attribute-Mapping** section. The attributes selected as **Matching** properties are used to match the groups in Sign In Enterprise for update operations. Select the **Save** button to commit any changes.

+1. Define the users and/or groups that you would like to provision to Sign In Enterprise by choosing the desired values in **Scope** in the **Settings** section.

+ Title: Azure Active Directory SSO integration with SOC SST

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

+# Azure Active Directory SSO integration with SOC SST

+In this article, you learn how to integrate SOC SST with Azure Active Directory (Azure AD). The SOC complies with the mandatory legal documentation, which can be managed within the software by public and private companies that have registered employees (CLT). When you integrate SOC SST with Azure AD, you can:

+* Control in Azure AD who has access to SOC SST.

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

+* Manage your accounts in one central location - the Azure portal.

+You configure and test Azure AD single sign-on for SOC SST in a test environment. SOC SST supports **SP** and **IDP** initiated single sign-on.

+## Prerequisites

+To integrate Azure Active Directory with SOC SST, you need:

+* An Azure AD user account. If you don't already have one, you can [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

+* One of the following roles: Global Administrator, Cloud Application Administrator, Application Administrator, or owner of the service principal.

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

+* SOC SST single sign-on (SSO) enabled subscription.

+## Add application and assign a test user

+Before you begin the process of configuring single sign-on, you need to add the SOC SST application from the Azure AD gallery. You need a test user account to assign to the application and test the single sign-on configuration.

+### Add SOC SST from the Azure AD gallery

+Add SOC SST from the Azure AD application gallery to configure single sign-on with SOC SST. For more information on how to add application from the gallery, see the [Quickstart: Add application from the gallery](../manage-apps/add-application-portal.md).

+### Create and assign Azure AD test user

+Follow the guidelines in the [create and assign a user account](../manage-apps/add-application-portal-assign-users.md) article to create a test user account in the Azure portal called B.Simon.

+Alternatively, you can also use the [Enterprise App Configuration Wizard](https://portal.office.com/AdminPortal/home?Q=Docs#/azureadappintegration). In this wizard, you can add an application to your tenant, add users/groups to the app, and assign roles. The wizard also provides a link to the single sign-on configuration pane in the Azure portal. [Learn more about Microsoft 365 wizards.](/microsoft-365/admin/misc/azure-ad-setup-guides).

+## Configure Azure AD SSO

+Complete the following steps to enable Azure AD single sign-on in the Azure portal.

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

+1. On the **Select a single sign-on method** page, select **SAML**.

+1. On the **Set up single sign-on with SAML** page, select the pencil icon for **Basic SAML Configuration** to edit the settings.

+ 

+1. On the **Basic SAML Configuration** section, perform the following steps:

+ a. In the **Identifier** textbox, type a value using the following pattern:

+ `<InstanceName>.soc.com.br`

+ b. In the **Reply URL** textbox, type a URL using the following pattern:

+ `https://sistema.soc.com.br/WebSoc/sso/<CustomerID>/saml/finalize.action`

+1. If you wish to configure the application in **SP** initiated mode, then perform the following step:

+ In the **Sign on URL** textbox, type a URL using the following pattern:

+ `https://sistema.soc.com.br/WebSoc/sp/<CustomerID>/login`

+ > [!NOTE]

+ > These values are not real. Update these values with the actual Identifier, Reply URL and Sign on URL. Contact [SOC SST Client support team](mailto:suporte@soc.com.br) to get these values. You can also refer to the patterns shown in the **Basic SAML Configuration** section in the Azure portal.

+1. On the **Set up single sign-on with SAML** page, in the **SAML Signing Certificate** section, find **Certificate (PEM)** and select **Download** to download the certificate and save it on your computer.

+ 

+1. On the **Set up SOC SST** section, copy the appropriate URL(s) based on your requirement.

+ 

+## Configure SOC SST SSO

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

+### Create SOC SST test user

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

+## Test SSO

+In this section, you test your Azure AD single sign-on configuration with following options.

+#### SP initiated:

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

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

+#### IDP initiated:

+* Click on **Test this application** in Azure portal and you should be automatically signed in to the SOC SST for which you set up the SSO.

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

+## Additional resources

+* [What is single sign-on with Azure Active Directory?](../manage-apps/what-is-single-sign-on.md)

+* [Plan a single sign-on deployment](../manage-apps/plan-sso-deployment.md).

+## Next steps

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

+ Title: Azure Active Directory SSO integration with VEDA Cloud

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

+# Azure Active Directory SSO integration with VEDA Cloud

+In this article, you learn how to integrate VEDA Cloud with Azure Active Directory (Azure AD). This application enables Azure AD to act as SAML IdP for authenticating users to your VEDA HR Cloud Solutions. When you integrate VEDA Cloud with Azure AD, you can:

+* Control in Azure AD who has access to VEDA Cloud.

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

+* Manage your accounts in one central location - the Azure portal.

+You configure and test Azure AD single sign-on for VEDA Cloud in a test environment. VEDA Cloud supports **SP** initiated single sign-on.

+## Prerequisites

+To integrate Azure Active Directory with VEDA Cloud, you need:

+* An Azure AD user account. If you don't already have one, you can [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

+* One of the following roles: Global Administrator, Cloud Application Administrator, Application Administrator, or owner of the service principal.

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

+* VEDA Cloud single sign-on (SSO) enabled subscription.

+## Add application and assign a test user

+Before you begin the process of configuring single sign-on, you need to add the VEDA Cloud application from the Azure AD gallery. You need a test user account to assign to the application and test the single sign-on configuration.

+### Add VEDA Cloud from the Azure AD gallery

+Add VEDA Cloud from the Azure AD application gallery to configure single sign-on with VEDA Cloud. For more information on how to add application from the gallery, see the [Quickstart: Add application from the gallery](../manage-apps/add-application-portal.md).

+### Create and assign Azure AD test user

+Follow the guidelines in the [create and assign a user account](../manage-apps/add-application-portal-assign-users.md) article to create a test user account in the Azure portal called B.Simon.

+Alternatively, you can also use the [Enterprise App Configuration Wizard](https://portal.office.com/AdminPortal/home?Q=Docs#/azureadappintegration). In this wizard, you can add an application to your tenant, add users/groups to the app, and assign roles. The wizard also provides a link to the single sign-on configuration pane in the Azure portal. [Learn more about Microsoft 365 wizards.](/microsoft-365/admin/misc/azure-ad-setup-guides).

+## Configure Azure AD SSO

+Complete the following steps to enable Azure AD single sign-on in the Azure portal.

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

+1. On the **Select a single sign-on method** page, select **SAML**.

+1. On the **Set up single sign-on with SAML** page, select the pencil icon for **Basic SAML Configuration** to edit the settings.

+ 

+1. On the **Basic SAML Configuration** section, perform the following steps:

+ a. In the **Identifier** textbox, type a URL using one of the following patterns:

+ | **Identifier** |

+ |--|

+ | `https://vedacustomers.b2clogin.com/<CUSTOMER>/B2C_1A_VEDASIGNIN` |

+ | `https://vedacustomersprod.b2clogin.com/<CUSTOMER>/B2C_1A_VEDASIGNIN` |

+ | `https://login.veda.net/<ID>/B2C_1A_VEDASIGNIN` |

+ b. In the **Reply URL** textbox, type a URL using one of the following patterns:

+ | **Reply URL** |

+ | -|

+ | `https://vedacustomers.b2clogin.com/<CUSTOMER>/B2C_1A_VEDASIGNIN/samlp/sso/assertionconsumer` |

+ | `https://vedacustomersprod.b2clogin.com/<CUSTOMER>/B2C_1A_VEDASIGNIN/samlp/sso/assertionconsumer` |

+ | `https://login.veda.net/<ID>/B2C_1A_VEDASIGNIN/samlp/sso/assertionconsumer` |

+ c. In the **Sign on URL** textbox, type a URL using the following pattern:

+ `https://<DOMAIN>.veda.net/<INSTANCE>`

+

+ > [!NOTE]

+ > These values are not real. Update these values with the actual Identifier, Reply URL and Sign on URL. Contact [VEDA Cloud Client support team](mailto:peoplemanagement@veda.net) to get these values. You can also refer to the patterns shown in the **Basic SAML Configuration** section in the Azure portal.

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

+ 

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

+ | Name | Source Attribute|

+ | | |

+ | displayname | user.displayname |

+1. On the **Set up single sign-on with SAML** page, in the **SAML Signing Certificate** section, click copy button to copy **App Federation Metadata Url** and save it on your computer.

+ 

+## Configure VEDA Cloud SSO

+To configure single sign-on on **VEDA Cloud** side, you need to send the **App Federation Metadata Url** to [VEDA Cloud support team](mailto:peoplemanagement@veda.net). They set this setting to have the SAML SSO connection set properly on both sides.

+### Create VEDA Cloud test user

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

+## Test SSO

+In this section, you test your Azure AD single sign-on configuration with following options.

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

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

+* You can use Microsoft My Apps. When you click the VEDA Cloud tile in the My Apps, this will redirect to VEDA Cloud Sign-on URL. For more information about the My Apps, see [Introduction to the My Apps](../user-help/my-apps-portal-end-user-access.md).

+## Additional resources

+* [What is single sign-on with Azure Active Directory?](../manage-apps/what-is-single-sign-on.md)

+* [Plan a single sign-on deployment](../manage-apps/plan-sso-deployment.md).

+## Next steps

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

+The other articles in this guidance address the identity pillar of Zero Trust principles, as described in the US Office of Management and Budget (OMB) [M 22-09 Memorandum for the Heads of Executive Departments and Agencies](https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf). This article covers Zero Trust maturity model areas beyond the identity pillar, and it addresses the following themes:

+* Visibility

+* Analytics

+It's important to monitor your Azure Active Directory (Azure AD) tenant. Assume a breach mindset and meet compliance standards in memorandum 22-09 and [Memorandum 21-31](https://www.whitehouse.gov/wp-content/uploads/2021/08/M-21-31-Improving-the-Federal-Governments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf). Three primary log types are used for security analysis and ingestion:

+* **Azure audit logs** to monitor operational activities of the directory, such as creating, deleting, updating objects like users or groups

+ * Use also to make changes to Azure AD configurations, like modifications to a Conditional Access policy

+ * See, [Audit logs in Azure AD](../reports-monitoring/concept-audit-logs.md)

+* **Provisioning logs** have information about objects synchronized from Azure AD to applications like Service Now with Microsoft Identity Manager

+ * See, [Provisioning logs in Azure Active Directory](../reports-monitoring/concept-provisioning-logs.md)

+* **Azure AD sign-in logs** to monitor sign-in activities associated with users, applications, and service principals.

+ * Sign-in logs have categories for differentiation

+ * Interactive sign-ins show successful and failed sign-ins, policies applied, and other metadata

+ * Non-interactive user sign-ins show no interaction during sign-in: clients signing in on behalf of the user, such as mobile applications or email clients

+ * Service principal sign-ins show service principal or application sign-in: services or applications accessing services, applications, or the Azure AD directory through the REST API

+ * Managed identities for Azure resource sign-in: Azure resources or applications accessing Azure resources, such as a web application service authenticating to an Azure SQL back end.

+ * See, [Sign-in logs in Azure Active Directory (preview)](../reports-monitoring/concept-all-sign-ins.md)

+In Azure AD free tenants, log entries are stored for seven days. Tenants with an Azure AD premium license retain log entries for 30 days.

+Ensure a security information and event management (SIEM) tool ingests logs. Use sign-in and audit events to correlate with application, infrastructure, data, device, and network logs.

+We recommend you integrate Azure AD logs with Microsoft Sentinel. Configure a connector to ingest Azure AD tenant logs.

+Learn more:

+* [What is Microsoft Sentinel?](../../sentinel/overview.md)

+* [Connect Azure AD to Microsoft Sentinel](../../sentinel/connect-azure-active-directory.md)

+For the Azure AD tenant, you can configure the diagnostic settings to send the data to an Azure Storage account, Azure Event Hubs, or a Log Analytics workspace. Use these storage options to integrate other SIEM tools to collect data.

+Learn more:

+* [What is Azure AD monitoring?](../reports-monitoring/overview-monitoring.md)

+* [Azure AD reporting and monitoring deployment dependencies](../reports-monitoring/plan-monitoring-and-reporting.md)

+* **Azure AD Identity Protection** analyzes sign-ins and other telemetry sources for risky behavior

+ * Identity Protection assigns a risk score to sign-in events

+ * Prevent sign-ins, or force a step-up authentication, to access a resource or application based on risk score

+ * See, [What is Identity Protection?](../identity-protection/overview-identity-protection.md)

+* **Azure AD usage and insights reports** have information similar to Azure Sentinel workbooks, including applications with highest usage or sign-in trends.

+ * Use reports to understand aggregate trends that might indicate an attack or other events

+ * See, [Usage and insights in Azure AD](../reports-monitoring/concept-usage-insights-report.md)

+* **Microsoft Sentinel** analyze information from Azure AD:

+ * Microsoft Sentinel User and Entity Behavior Analytics (UEBA) delivers intelligence on potential threats from user, host, IP address, and application entities.

+ * Use analytics rule templates to hunt for threats and alerts in your Azure AD logs. Your security or operation analyst can triage and remediate threats.

+ * Microsoft Sentinel workbooks help visualize Azure AD data sources. See sign-ins by country, region, or applications.

+ * See, [Commonly used Microsoft Sentinel workbooks](../../sentinel/top-workbooks.md)

+ * See, [Visualize collected data](../../sentinel/get-visibility.md)

+ * See, [Identify advanced threats with UEBA in Microsoft Sentinel](../../sentinel/identify-threats-with-entity-behavior-analytics.md)

+Automation in Zero Trust helps remediate alerts due to threats or security changes. In Azure AD, automation integrations help clarify actions to improve your security posture. Automation is based on information received from monitoring and analytics.

+Use Microsoft Graph API REST calls to access Azure AD programmatically. This access requires an Azure AD identity with authorizations and scope. With the Graph API, integrate other tools.

+We recommend you set up an Azure function or an Azure logic app to use a system-assigned managed identity. The logic app or function has steps or code to automate actions. Assign permissions to the managed identity to grant the service principal directory permissions to perform actions. Grant managed identities minimum rights.

+Learn more: [What are managed identities for Azure resources?](../managed-identities-azure-resources/overview.md)

+Another automation integration point is Azure AD PowerShell modules. Use PowerShell to perform common tasks or configurations in Azure AD, or incorporate into Azure functions or Azure Automation runbooks.

+Document your processes for operating the Azure AD environment. Use Azure AD features for governance functionality applied to scopes in Azure AD.

+Learn more:

+* [Azure AD governance operations reference guide](../fundamentals/active-directory-ops-guide-govern.md)

+* [Azure AD security operations guide](../fundamentals/security-operations-introduction.md)

+* [What is Microsoft Entra Identity Governance?](../governance/identity-governance-overview.md)

+* [Meet authorization requirements of memorandum 22-09](memo-22-09-authorization.md).

+* [Meet identity requirements of memorandum 22-09 with Azure AD](memo-22-09-meet-identity-requirements.md)

+* [Enterprise-wide identity management system](memo-22-09-enterprise-wide-identity-management-system.md)

+* [Meet multifactor authentication requirements of memorandum 22-09](memo-22-09-multi-factor-authentication.md)

+* [Meet authorization requirements of memorandum 22-09](memo-22-09-authorization.md)

+* [Securing identity with Zero Trust](/security/zero-trust/deploy/identity)

+|Phone (SMS): Not recommended | Single-factor out-of-band |

+|Microsoft Authenticator App (Passwordless)|Multi-factor out-of-band |

+|Single-factor software certificate | Single-factor crypto software |

+|Hardware protected certificate (smartcard/security key/TPM) <br> FIDO 2 security key <br> Windows Hello for Business with hardware TPM <br> | Multi-factor crypto hardware

+The National Institute of Standards and Technology (NIST) develops technical requirements for US federal agencies implementing identity solutions. Organizations working with federal agencies must meet these requirements.

+| Azure AD authentication method| NIST authenticator type |

+| **Recommended methods** | |

+| Multi-factor Software Certificate (PIN Protected) <br> Windows Hello for Business with software Trusted Platform Module (TPM)| Multi-factor crypto software |

+| Hardware protected certificate (smartcard/security key/TPM) <br> FIDO 2 security key <br> Windows Hello for Business with hardware TPM | Multi-factor crypto hardware |

+|Microsoft Authenticator app (Passwordless) | Multi-factor out-of-band

+| Password <br> **AND** <br>- Microsoft Authenticator app (Push Notification) <br>- **OR** <br>- Phone (SMS) | Memorized secret <br>**AND**<br> Single-factor out-of-band |

+| Password <br> **AND** <br>- OATH hardware tokens (preview) <br>- **OR**<br>- Microsoft Authenticator app (OTP)<br>- **OR**<br>- OATH software tokens | Memorized secret <br>**AND** <br>Single-factor OTP|

+| Password <br>**AND** <br>- Single-factor software certificate <br>- **OR**<br>- Azure AD joined with software TPM <br>- **OR**<br>- Hybrid Azure AD joined with software TPM <br>- **OR**<br>- Compliant mobile device | Memorized secret <br>**AND**<br> Single-factor crypto software |

+| Password <br>**AND**<br>- Azure AD joined with hardware TPM <br>- **OR**<br>- Hybrid Azure AD joined with hardware TPM| Memorized secret <br>**AND**<br>Single-factor crypto hardware |

+> Today, Microsoft Authenticator by itself is not phishing resistant. To gain protection from external phishing threats when using Microsoft Authenticator you must additionally configure conditional access policy requiring a managed device.

+For AAL2, use multi-factor cryptographic hardware or software authenticators. Passwordless authentication eliminates the greatest attack surface (the password), and offers users a streamlined method to authenticate.

+* Certificate stored in software or hardware (smartcard/security key/TPM)

+Microsoft Authenticator app (Push Notification/OTP/passwordless) on iOS uses FIPS 140 level 1 validated cryptographic module and is FIPS 140 compliant. While Microsoft Authenticator app on Android (Push Notification/OTP/passwordless) uses FIPS 140 approved cryptography, it is not FIPS compliant.

+For OATH hardware tokens and smartcards we recommend you consult with your provider for current FIPS validation status.

+FIDO 2 security key providers are in various stages of FIPS certification. We recommend you review the list of [supported FIDO 2 key vendors](../authentication/concept-authentication-passwordless.md#fido2-security-key-providers). Consult with your provider for current FIPS validation status.

+## Reauthentication

+To meet the requirement for reauthentication, regardless of user activity, Microsoft recommends configuring [user sign-in frequency](../conditional-access/howto-conditional-access-session-lifetime.md) to 12 hours.

+## Man-in-the-middle resistance

+## Next steps

+Use the information in this article for National Institute of Standards and Technology (NIST) authenticator assurance level 3 (AAL3).

+Use Microsoft authentication methods to meet required NIST authenticator types.

+| Hardware protected certificate (smartcard/security key/TPM) <br> FIDO 2 security key<br>Windows Hello for Business with hardware TPM| Multi-factor cryptographic hardware |

+| **Additional methods**||

+|Password<br>**AND**<br>- Azure AD joined with hardware TPM <br>- **OR**<br>- Hybrid Azure AD joined with hardware TPM|Memorized secret <br>**AND**<br>Single-factor cryptographic hardware|

+|Password<br>**AND**<br>OATH hardware tokens (Preview) <br>**AND**<br>- Single-factor software certificate<br>- **OR**<br>- Hybrid Azure AD Joined or compliant device with software TPM |Memorized secret<br>**AND**<br>Single-factor OTP hardware <br>**AND**<br>Single-factor cryptographic software|

+### Recommendations

+For AAL3, we recommend using a multi-factor cryptographic hardware authenticator that provides passwordless authentication eliminating the greatest attack surface, the password.

+Single-factor and multi-factor cryptographic hardware authenticator requirements.

+Azure AD joined and Hybrid Azure AD joined devices meet this requirement when:

+Authenticators are required to be:

+FIPS 140 requires the cryptographic boundary, including software, firmware, and hardware, to be in scope for evaluation. Windows operating systems can be paired with thousands of these combinations. As such, it is not feasible for Microsoft to have Windows Hello for Business validated at FIPS 140 Security Level 2. Federal customers should conduct risk assessments and evaluate each of the following component certifications as part of their risk acceptance before accepting this service as AAL3:

+* **Windows 10 and Windows Server** use the [US Government Approved Protection Profile for General Purpose Operating Systems Version 4.2.1](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=442&id=442) from the National Information Assurance Partnership (NIAP). This organization oversees a national program to evaluate commercial off-the-shelf (COTS) information technology products for conformance with the international Common Criteria.

+* **Windows Cryptographic Library** [has FIPS Level 1 Overall in the NIST Cryptographic Module Validation Program](https://csrc.nist.gov/Projects/cryptographic-module-validation-program/Certificate/3544) (CMVP), a joint effort between NIST and the Canadian Center for Cyber Security. This organization validates cryptographic modules against FIPS standards.

+* Choose a **Trusted Platform Module (TPM)** that's FIPS 140 Level 2 Overall, and FIPS 140 Level 3 Physical Security. Your organization ensures hardware TPM meets the AAL level requirements you want.

+## Reauthentication

+To meet the requirement for reauthentication, regardless of user activity, Microsoft recommends configuring [user sign-in frequency](../conditional-access/howto-conditional-access-session-lifetime.md) to 12 hours.

+NIST allows for compensating controls to confirm subscriber presence:

+## Man-in-the-middle resistance

+* Use a cryptographic authenticator that requires the verifier store a public key corresponding to a private key held by the authenticator

+* Store the expected authenticator output by using FIPS-140 validated hash algorithms

+Requiring authentication intent makes it more difficult for directly connected physical authenticators, like multi-factor cryptographic hardware, to be used without the subject's knowledge (for example, by malware on the endpoint). Azure AD methods that meet AAL3 require user entry of pin or biometric, demonstrating authentication intent.

+## Next steps

+|Look-up secret <br> (something you have)| None|

+|Single-factor out-of-band <br>(something you have)| Microsoft Authenticator App (Push Notification) <br> Phone (SMS): Not recommended |

+Multi-factor Out-of-band <br> (something you have + something you know/are) | Microsoft Authenticator App (Passwordless) |

+|Single-factor one-time password (OTP) <br> (something you have)| Microsoft Authenticator App (OTP) <br> Single-factor Hardware/Software OTP<sup data-htmlnode="">1</sup>|

+|Multi-factor OTP <br> (something you have + something you know/are)| Treated as single-factor OTP|

+|Single-factor crypto software <br> (something you have)|Single-factor software certificate <br> Azure AD joined <sup data-htmlnode="">2</sup> with software TPM <br> Hybrid Azure AD joined <sup data-htmlnode="">2</sup> with software TPM <br> Compliant mobile device |

+|Multi-factor crypto software <br> (something you have + something you know/are) | Multi-factor Software Certificate (PIN Protected) <br> Windows Hello for Business with software TPM |

+|Multi-factor crypto hardware <br> (something you have + something you know/are) |Hardware protected certificate (smartcard/security key/TPM) <br> Windows Hello for Business with hardware TPM <br> FIDO 2 security key|

+## Public Switch Telephone Network (PSTN) SMS/Voice are not recommended

+NIST does not recommend SMS or voice. The risks of device swap, SIM changes, number porting, and other behaviors can cause issues. If these actions are malicious, they can result in an insecure experience. Although SMS/Voice are not recommended, they are better than using only a password, because they require more effort for hackers.

+## Next steps

+ Title: Use Container Storage Interface (CSI) driver for Azure Disk on Azure Kubernetes Service (AKS)

+description: Learn how to use the Container Storage Interface (CSI) driver for Azure Disk in an Azure Kubernetes Service (AKS) cluster.

+# Use the Azure Disk Container Storage Interface (CSI) driver in Azure Kubernetes Service (AKS)

+The Azure Disks Container Storage Interface (CSI) driver is a [CSI specification](https://github.com/container-storage-interface/spec/blob/master/spec.md)-compliant driver used by Azure Kubernetes Service (AKS) to manage the lifecycle of Azure Disk.

+* [Access and identity options for AKS](/azure/aks/concepts-identity)

+[kubernetes-rbac]: /azure/aks/concepts-identity#azure-rbac-for-kubernetes-authorization

+>

+While the default storage tier for the Azure Disk CSI driver is Premium SSD, your custom StorageClass can use Premium SSD, Standard SSD, or Standard HDD.

+* Stand-by and proactive scenarios. Microsoft Support provides reactive support to help solve active issues in a timely and professional manner. However, standby or proactive support to help you eliminate operational risks, increase availability, and optimize performance are not covered. [Eligible customers](https://www.microsoft.com/unifiedsupport) can contact their account team to get nominated for Azure Event Management service[https://devblogs.microsoft.com/premier-developer/proactively-plan-for-your-critical-event-in-azure-with-enhanced-support-and-engineering-services/]. It's a paid service delivered by Microsoft support engineers that includes a proactive solution risk assessment and coverage during the event.

+> The open source Azure AD pod-managed identity (preview) in Azure Kubernetes Service has been deprecated as of 10/24/2022 and the projected will be archived in Sept. 2023. For more information, see the [deprecation notice](https://github.com/Azure/aad-pod-identity#-announcement).

+> The AKS Managed add-on will begin deprecation in Sept. 2023.

+## Rotate the OIDC key

+## Check the OIDC keys

+### Get the OIDC Issuer URL

+To get the OIDC Issuer URL, run the [az aks show][az-aks-show] command. Replace the default values for the cluster name and the resource group name.

+```azurecli-interactive

+az aks show -n myAKScluster -g myResourceGroup --query "oidcIssuerProfile.issuerUrl" -otsv

+```

+The output should resemble the following:

+```output

+https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000000/

+```

+### Get the discovery document

+To get the discovery document, copy the URL `https://(OIDC issuer URL).well-known/openid-configuration` and open it in browser.

+The output should resemble the following:

+```output

+{

+ "issuer": "https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000000/",

+ "jwks_uri": "https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000000/openid/v1/jwks",

+ "response_types_supported": [

+ "id_token"

+ ],

+ "subject_types_supported": [

+ "public"

+ ],

+ "id_token_signing_alg_values_supported": [

+ "RS256"

+ ]

+}

+```

+### Get the JWK Set document

+To get the JWK Set document, copy the `jwks_uri` from the discovery document and past it in your browser's address bar.

+The output should resemble the following:

+```output

+{

+ "keys": [

+ {

+ "use": "sig",

+ "kty": "RSA",

+ "kid": "xxx",

+ "alg": "RS256",

+ "n": "xxxx",

+ "e": "AQAB"

+ },

+ {

+ "use": "sig",

+ "kty": "RSA",

+ "kid": "xxx",

+ "alg": "RS256",

+ "n": "xxxx",

+ "e": "AQAB"

+ }

+ ]

+}

+```

+During key rotation, there is one additional key present in the discovery document.

+- See [Azure security baseline for Application Gateway](/security/benchmark/azure/baselines/application-gateway-security-baseline) for more security best practices.

+Use following two components:

+* [`Azure Kubernetes Metric Adapter`](https://github.com/Azure/azure-k8s-metrics-adapter) - We use the metric adapter to expose Application Gateway metrics through the metric server. The Azure Kubernetes Metric Adapter is an open source project under Azure, similar to the Application Gateway Ingress Controller.

+* [`Horizontal Pod Autoscaler`](../aks/concepts-scale.md#horizontal-pod-autoscaler) - We use HPA to use Application Gateway metrics and target a deployment for scaling.

+1. First, create an Azure AD service principal and assign it `Monitoring Reader` access over Application Gateway's resource group.

+1. Now, deploy the [`Azure Kubernetes Metric Adapter`](https://github.com/Azure/azure-k8s-metrics-adapter) using the Azure AD service principal created previously.

+ # use values from service principal created previously to create secret

+1. Create an `ExternalMetric` resource with name `appgw-request-count-metric`. This resource instructs the metric adapter to expose `AvgRequestCountPerHealthyHost` metric for `myApplicationGateway` resource in `myResourceGroup` resource group. You can use the `filter` field to target a specific backend pool and backend HTTP setting in the Application Gateway.

+Once we're able to expose `appgw-request-count-metric` through the metric server, we're ready to use [`Horizontal Pod Autoscaler`](../aks/concepts-scale.md#horizontal-pod-autoscaler) to scale up our target deployment.

+In following example, we target a sample deployment `aspnet`. We scale up Pods when `appgw-request-count-metric` > 200 per Pod up to a max of `10` Pods.

+- If you want to use HTTPS on this application, you need an x509 certificate and its private key.

+The guestbook application is a canonical Kubernetes application that composes of a Web UI frontend, a backend and a Redis database. By default, `guestbook` exposes its application through a service with name `frontend` on port `80`. Without a Kubernetes Ingress Resource, the service isn't accessible from outside the AKS cluster. We use the application and set up Ingress Resources to access the application through HTTP and HTTPS.

+Use the following instructions to deploy the guestbook application.

+To expose the guestbook application, use the following ingress resource:

+This ingress exposes the `frontend` service of the `guestbook-all-in-one` deployment

+Without specifying hostname, the guestbook service is available on all the host-names pointing to the application gateway.

+Now the `guestbook` application is available on both HTTP and HTTPS.

+By specifying hostname, the guestbook service is only available on the specified host.

+Now the `guestbook` application is available on both HTTP and HTTPS only on the specified host (`<guestbook.contoso.com>` in this example).

+The following ingress allows you to add other paths into this ingress and redirect those paths to other

+ ```bash

+ kubectl get AzureIngressProhibitedTargets prohibit-all-targets -o yaml

+ ```

+ - `appgw.environment`: Sets cloud environment. Possible values: `AZURECHINACLOUD`, `AZUREGERMANCLOUD`, `AZUREPUBLICCLOUD`, `AZUREUSGOVERNMENTCLOUD`

+ ```bash

+ curl https://raw.githubusercontent.com/Azure/application-gateway-kubernetes-ingress/master/docs/examples/aspnetapp.yaml -o aspnetapp.yaml

+ ```

+ ```bash

+ kubectl apply -f aspnetapp.yaml

+ ```

+This section configures your AKS to use [LetsEncrypt.org](https://letsencrypt.org/) and automatically obtain a TLS/SSL certificate for your domain. The certificate is installed on Application Gateway, which performs SSL/TLS termination for your AKS cluster. The setup described here uses the [cert-manager](https://github.com/jetstack/cert-manager) Kubernetes add-on, which automates the creation and management of certificates.

+Use the following steps to install [cert-manager](https://docs.cert-manager.io) on your existing AKS cluster.

+ Run the following script to install the `cert-manager` helm chart. The script performs the following actions:

+ - creates a new `cert-manager` namespace on your AKS

+ - creates the following CRDs: Certificate, Challenge, ClusterIssuer, Issuer, Order

+ - installs cert-manager chart (from [docs.cert-manager.io)](https://cert-manager.io/docs/installation/compatibility/)

+ Create a `ClusterIssuer` resource. This is required by `cert-manager` to represent the `Lets Encrypt` certificate authority where the signed certificate is obtained.

+ Using the non-namespaced `ClusterIssuer` resource, cert-manager issues certificates that can be consumed from multiple namespaces. `LetΓÇÖs Encrypt` uses the ACME protocol to verify that you control a given domain name and to issue a certificate. More details on configuring `ClusterIssuer` properties [here](https://docs.cert-manager.io/en/latest/tasks/issuers/https://docsupdatetracker.net/index.html). `ClusterIssuer` instructs `cert-manager` to issue certificates using the `Lets Encrypt` staging environment used for testing (the root certificate not present in browser/client trust stores).

+ The default challenge type in the following YAML is `http01`. Other challenges are documented on [letsencrypt.org - Challenge Types](https://letsencrypt.org/docs/challenge-types/)

+ > Update `<YOUR.EMAIL@ADDRESS>` in the following YAML.

+ # Let's Encrypt uses this to contact you about expiring

+ > Update `<PLACEHOLDERS.COM>` in the following YAML with your own domain (or the Application Gateway one, for example

+ Before the `Lets Encrypt` certificate expires, `cert-manager` automatically updates the certificate in the Kubernetes secret store. At that point, Application Gateway Ingress Controller applies the updated secret referenced in the ingress resources it's using to configure the Application Gateway.

+This feature exposes the ingress endpoint within the `Virtual Network` using a private IP.

+## Prerequisites

+For Application Gateways without a Private IP, Ingresses annotated with `appgw.ingress.kubernetes.io/use-private-ip: "true"` is ignored. This is indicated in the ingress event and AGIC pod log.

+ ```output

+ ```output

+This makes the ingress controller filter the IP address configurations for a Private IP when configuring the frontend listeners on the Application Gateway.

+AGIC can panic and crash if `usePrivateIP: true` and no Private IP is assigned.

+ ```output

+ ```output

+ ```output

+ ```output

+ ```output

+ ```output

+ ```output

+You can use the Azure CLI to create an [application gateway](overview.md) with a certificate for TLS/SSL termination. A routing rule is used to redirect HTTP traffic to the HTTPS port in your application gateway. In this example, you also create a [Virtual Machine Scale Set](../virtual-machine-scale-sets/overview.md) for the backend pool of the application gateway that contains two virtual machine instances.

+* Create a Virtual Machine Scale Set with the default backend pool

+Create the virtual network named *myVNet* and the subnet named *myAGSubnet* using [az network vnet create](/cli/azure/network/vnet). You can then add the subnet named *myBackendSubnet* needed by the backend servers using [az network vnet subnet create](/cli/azure/network/vnet/subnet). Create the public IP address named *myAGPublicIPAddress* using [az network public-ip create](/cli/azure/network/public-ip).

+## Create a Virtual Machine Scale Set

+In this example, you create a Virtual Machine Scale Set named *myvmss* that provides servers for the backend pool in the application gateway. The virtual machines in the scale set are associated with *myBackendSubnet* and *appGatewayBackendPool*. To create the scale set, you can use [az vmss create](/cli/azure/vmss#az-vmss-create).

+description: Learn how to create an application gateway with a Virtual Machine Scale Set to manage web traffic using the Azure CLI.

+Application gateway is used to manage and secure web traffic to servers that you maintain. You can use the Azure CLI to create an [application gateway](overview.md) that uses a [Virtual Machine Scale Set](../virtual-machine-scale-sets/overview.md) for backend servers. In this example, the scale set contains two virtual machine instances. The scale set is added to the default backend pool of the application gateway.

+* Create a Virtual Machine Scale Set with the default backend pool

+ ```azurecli-interactive

+ az group create --name myResourceGroupAG --location eastus

+ ```

+Create the virtual network named *myVNet* and the subnet named *myAGSubnet* using [az network vnet create](/cli/azure/network/vnet). You can then add the subnet named *myBackendSubnet* needed by the backend servers using [az network vnet subnet create](/cli/azure/network/vnet/subnet). Create the public IP address named *myAGPublicIPAddress* using [az network public-ip create](/cli/azure/network/public-ip).

+ ```azurecli-interactive

+ az network vnet create \

+ az network vnet subnet create \

+ az network public-ip create \

+ ```

+ ```azurecli-interactive

+ az network application-gateway create \

+ ```

+It may take several minutes for the application gateway to be created. After the application gateway is created, you'll see these new features:

+In this example, you create a Virtual Machine Scale Set that provides servers for the backend pool in the application gateway. The virtual machines in the scale set are associated with *myBackendSubnet* and *appGatewayBackendPool*. To create the scale set, use [az vmss create](/cli/azure/vmss#az-vmss-create).

+ ```azurecli-interactive

+ az vmss create \

+ ```

+Now you can install NGINX on the Virtual Machine Scale Set so you can test HTTP connectivity to the backend pool.

+ ```azurecli-interactive

+ az vmss extension set \

+ ```

+ ```azurecli-interactive

+ az network public-ip show \

+ ```

+ ```azurecli-interactive

+ az group delete --name myResourceGroupAG --location eastus

+ ```

+* Create Virtual Machine Scale Sets with the backend pools

+## Create Virtual Machine Scale Sets

+In this example, you create three Virtual Machine Scale Sets that support the three backend pools in the application gateway. The scale sets that you create are named *myvmss1*, *myvmss2*, and *myvmss3*. Each scale set contains two virtual machine instances on which you install IIS.

+You can use the Azure CLI to create an [application gateway](overview.md) with a certificate for [TLS termination](ssl-overview.md). For backend servers, you can use a [Virtual Machine Scale Set](../virtual-machine-scale-sets/overview.md). In this example, the scale set contains two virtual machine instances that are added to the default backend pool of the application gateway.

+* Create a Virtual Machine Scale Set with the default backend pool

+Create the virtual network named *myVNet* and the subnet named *myAGSubnet* using [az network vnet create](/cli/azure/network/vnet). You can then add the subnet named *myBackendSubnet* needed by the backend servers using [az network vnet subnet create](/cli/azure/network/vnet/subnet). Create the public IP address named *myAGPublicIPAddress* using [az network public-ip create](/cli/azure/network/public-ip).

+## Create a Virtual Machine Scale Set

+In this example, you create a Virtual Machine Scale Set that provides servers for the default backend pool in the application gateway. The virtual machines in the scale set are associated with *myBackendSubnet* and *appGatewayBackendPool*. To create the scale set, you can use [az vmss create](/cli/azure/vmss#az-vmss-create).

+As an IT administrator managing web traffic, you want to help your customers and users get the information they need as quickly as possible. One way you can optimize their experience is by routing different kinds of web traffic to different server resources. This article shows you how to use the Azure CLI to set up and configure Application Gateway routing for different types of traffic from your application. The routing then directs the traffic to different server pools based on the URL.

+* Create a resource group for the network resources you need

+Create the virtual network named *myVNet* and the subnet named *myAGSubnet* using `az network vnet create`. Then add a subnet named *myBackendSubnet* needed by the backend servers using `az network vnet subnet create`. Create the public IP address named *myAGPublicIPAddress* using `az network public-ip create`.

+|appGatewayBackendHttpSettings |Specifies that port 80 and an HTTP protocol are used for communication.|

+## Create Virtual Machine Scale Sets

+In this article, you create three Virtual Machine Scale Sets that support the three backend pools you created. You create scale sets named *myvmss1*, *myvmss2*, and *myvmss3*. Each scale set contains two virtual machine instances where you install NGINX.

+| `{API_KEY}` | The key for your Form Recognizer resource. You can find it on your resource's **Key and endpoint** page, on the Azure portal. |`{string}`|

+After you've [configured the container](#configure-the-container-to-be-run-in-a-disconnected-environment), the values for the downloaded form recognizer models and container configuration will be generated and displayed in the container output.

+* [Change or end a commitment plan](../../../cognitive-services/containers/disconnected-containers.md#purchase-a-different-commitment-plan-for-disconnected-containers)

+## Video: Form Recognizer models

+The following video introduces Form Recognizer models and their associated output to help you choose the best model to address your document scenario needs.</br></br>

+ > [!VIDEO https://www.microsoft.com/en-us/videoplayer/embed/RE5fX1b]

+> You can't set up this feature for Red Hat OpenShift, or for managed Kubernetes offerings of cloud providers like Elastic Kubernetes Service or Google Kubernetes Engine where the user doesn't have access to the API server of the cluster. For Azure Kubernetes Service (AKS) clusters, this [feature is available natively](../../aks/manage-azure-rbac.md) and doesn't require the AKS cluster to be connected to Azure Arc. For AKS on Azure Stack HCI, see [Use Azure RBAC for AKS hybrid clusters (preview)](/azure/aks/hybrid/azure-rbac-aks-hybrid).

+> [!IMPORTANT]

+> This article describes a way to connect a generic vCenter Server to Azure Arc. If you are trying to enable Arc for Azure VMware Solution (AVS) private cloud, please follow this guide instead - [Deploy Arc for Azure VMware Solution](../../azure-vmware/deploy-arc-for-azure-vmware-solution.md). With the Arc for AVS onboarding process you will need to provide fewer inputs and Arc capabilities are better integrated into the AVS private cloud portal experience.

+ Using this information, Visual Studio Code generates an Azure Functions project with an HTTP trigger. You can view the local project files in the Explorer. To learn more about files that are created, see [Azure Functions JavaScript developer guide](functions-reference-node.md?tabs=javascript).

+ Using this information, Visual Studio Code generates an Azure Functions project with an HTTP trigger. You can view the local project files in the Explorer. To learn more about files that are created, see [Azure Functions TypeScript developer guide](functions-reference-node.md?tabs=typescript).

+* [Azure Functions JavaScript developer guide](functions-reference-node.md?tabs=javascript)

+* [Azure Functions TypeScript developer guide](functions-reference-node.md?tabs=typescript)

+| `node` | [JavaScript](functions-reference-node.md?tabs=javascript)<br/>[TypeScript](functions-reference-node.md?tabs=typescript) |

+* [JavaScript](functions-reference-node.md?tabs=javascript)

+* [TypeScript](functions-reference-node.md?tabs=typescript)

+| **Learn more in-depth** | <li>Learn how functions [automatically increase or decrease](./functions-scale.md) instances to match demand<li>Explore the different [deployment methods](./functions-deployment-technologies.md) available<li>Use built-in [monitoring tools](./functions-monitoring.md) to help analyze your functions<li>Read the [JavaScript](./functions-reference-node.md?tabs=javascript) or [TypeScript](./functions-reference-node.md?tabs=typescript) language reference|

+ Title: Node.js developer reference for Azure Functions

+description: Understand how to develop functions by using Node.js.

+ms.devlang: javascript, typescript

+# Azure Functions Node.js developer guide

+As a Node.js developer, you might also be interested in one of the following articles:

+| <ul><li>[Node.js function using Visual Studio Code](./create-first-function-vs-code-node.md)</li><li>[Node.js function with terminal/command prompt](./create-first-function-cli-node.md)</li><li>[Node.js function using the Azure portal](functions-create-function-app-portal.md)</li></ul> | <ul><li>[Developer guide](functions-reference.md)</li><li>[Hosting options](functions-scale.md)</li><li>[Performance&nbsp; considerations](functions-best-practices.md)</li></ul> | <ul><li>[Create serverless applications](/training/paths/create-serverless-applications/)</li><li>[Refactor Node.js and Express APIs to Serverless APIs](/training/modules/shift-nodejs-express-apis-serverless/)</li></ul> |

+# [JavaScript](#tab/javascript)

+# [TypeScript](#tab/typescript)

+The required folder structure for a TypeScript project looks like the following example:

+```

+<project_root>/

+ | - .vscode/

+ | - dist/

+ | - node_modules/

+ | - myFirstFunction/

+ | | - index.ts

+ | | - function.json

+ | - mySecondFunction/

+ | | - index.ts

+ | | - function.json

+ | - .funcignore

+ | - host.json

+ | - local.settings.json

+ | - package.json

+ | - tsconfig.json

+```

+The main project folder, *<project_root>*, can contain the following files:

+- **.vscode/**: (Optional) Contains the stored Visual Studio Code configuration. To learn more, see [Visual Studio Code settings](https://code.visualstudio.com/docs/getstarted/settings).

+- **dist/**: Contains the compiled JavaScript code after you run a build. The name of this folder can be configured in your "tsconfig.json" file, and should match the `scriptFile` property in your "function.json" files.

+- **myFirstFunction/function.json**: Contains configuration for the function's trigger, inputs, and outputs. The name of the directory determines the name of your function. For TypeScript projects, this file must contain a `scriptFile` property pointing to your compiled JavaScript.

+- **myFirstFunction/index.ts**: Stores your function code. To change this default file path, see [using scriptFile](#using-scriptfile).

+- **.funcignore**: (Optional) Declares files that shouldn't get published to Azure. Usually, this file contains *.vscode/* to ignore your editor setting, *test/* to ignore test cases, and *local.settings.json* to prevent local app settings being published.

+- **host.json**: Contains configuration options that affect all functions in a function app instance. This file does get published to Azure. Not all options are supported when running locally. To learn more, see [host.json](functions-host-json.md).

+- **local.settings.json**: Used to store app settings and connection strings when it's running locally. This file doesn't get published to Azure. To learn more, see [local.settings.file](functions-develop-local.md#local-settings-file).

+- **package.json**: Contains configuration options like a list of package dependencies, the main entrypoint, and scripts.

+- **tsconfig.json**: Contains TypeScript compiler options like the output directory.

+# [JavaScript](#tab/javascript)

+# [TypeScript](#tab/typescript)

+The recommended folder structure for a TypeScript project looks like the following example:

+```

+<project_root>/

+ | - .vscode/

+ | - dist/

+ | - node_modules/

+ | - src/

+ | | - functions/

+ | | | - myFirstFunction.ts

+ | | | - mySecondFunction.ts

+ | - test/

+ | | - functions/

+ | | | - myFirstFunction.test.ts

+ | | | - mySecondFunction.test.ts

+ | - .funcignore

+ | - host.json

+ | - local.settings.json

+ | - package.json

+ | - tsconfig.json

+```

+The main project folder, *<project_root>*, can contain the following files:

+- **.vscode/**: (Optional) Contains the stored Visual Studio Code configuration. To learn more, see [Visual Studio Code settings](https://code.visualstudio.com/docs/getstarted/settings).

+- **dist/**: Contains the compiled JavaScript code after you run a build. The name of this folder can be configured in your "tsconfig.json" file.

+- **src/functions/**: The default location for all functions and their related triggers and bindings.

+- **test/**: (Optional) Contains the test cases of your function app.

+- **.funcignore**: (Optional) Declares files that shouldn't get published to Azure. Usually, this file contains *.vscode/* to ignore your editor setting, *test/* to ignore test cases, and *local.settings.json* to prevent local app settings being published.

+- **host.json**: Contains configuration options that affect all functions in a function app instance. This file does get published to Azure. Not all options are supported when running locally. To learn more, see [host.json](functions-host-json.md).

+- **local.settings.json**: Used to store app settings and connection strings when it's running locally. This file doesn't get published to Azure. To learn more, see [local.settings.file](functions-develop-local.md#local-settings-file).

+- **package.json**: Contains configuration options like a list of package dependencies, the main entrypoint, and scripts.

+- **tsconfig.json**: Contains TypeScript compiler options like the output directory.

+The v3 model registers a function based on the existence of two files. First, you need a `function.json` file located in a folder one level down from the root of your app. Second, you need a JavaScript file that [exports](https://nodejs.org/api/modules.html#modules_module_exports) your function. By default, the model looks for an `index.js` file in the same folder as your `function.json`. If you're using TypeScript, you must use the [`scriptFile`](#using-scriptfile) property in `function.json` to point to the compiled JavaScript file. To customize the file location or export name of your function, see [configuring your function's entry point](functions-reference-node.md#configure-function-entry-point).

+# [JavaScript](#tab/javascript)

+# [TypeScript](#tab/typescript)

+```json

+{

+ "bindings": [

+ {

+ "type": "httpTrigger",

+ "direction": "in",

+ "name": "req",

+ "authLevel": "anonymous",

+ "methods": [

+ "get",

+ "post"

+ ]

+ },

+ {

+ "type": "http",

+ "direction": "out",

+ "name": "res"

+ }

+ ],

+ "scriptFile": "../dist/HttpTrigger1/index.js"

+}

+```

+```typescript

+import { AzureFunction, Context, HttpRequest } from "@azure/functions";

+const httpTrigger: AzureFunction = async function (context: Context, request: HttpRequest): Promise<void> {

+ context.log('Http function was triggered.');

+ context.res = { body: 'Hello, world!' };

+};

+export default httpTrigger;

+```

+# [JavaScript](#tab/javascript)

+app.http('helloWorld1', {

+# [TypeScript](#tab/typescript)

+```typescript

+import { app, HttpRequest, HttpResponseInit, InvocationContext } from "@azure/functions";

+async function helloWorld1(request: HttpRequest, context: InvocationContext): Promise<HttpResponseInit> {

+ context.log('Http function was triggered.');

+ return { body: 'Hello, world!' };

+};

+app.http('helloWorld1', {

+ methods: ['GET', 'POST'],

+ handler: helloWorld1

+});

+```

+ # [JavaScript](#tab/javascript)

+ # [TypeScript](#tab/typescript)

+ ```typescript

+ const httpTrigger: AzureFunction = async function (context: Context, myTrigger: HttpRequest, myInput: any, myOtherInput: any): Promise<void> {

+ ```

+

+ # [JavaScript](#tab/javascript)

+ module.exports = async function (context) {

+ # [TypeScript](#tab/typescript)

+ ```typescript

+ import { AzureFunction, Context } from "@azure/functions";

+ const httpTrigger: AzureFunction = async function (context: Context): Promise<void> {

+ context.log("This is myTrigger: " + context.bindings.myTrigger);

+ context.log("This is myInput: " + context.bindings.myInput);

+ context.log("This is myOtherInput: " + context.bindings.myOtherInput);

+ }

+ export default httpTrigger;

+ ```

+

+ # [JavaScript](#tab/javascript)

+ # [TypeScript](#tab/typescript)

+ ```typescript

+ import { AzureFunction, Context, HttpRequest, HttpResponseSimple } from "@azure/functions";

+ const httpTrigger: AzureFunction = async function (context: Context, request: HttpRequest): Promise<HttpResponseSimple> {

+ return {

+ body: "Hello, world!"

+ };

+ };

+ export default httpTrigger;

+ ```

+

+ # [JavaScript](#tab/javascript)

+ # [TypeScript](#tab/typescript)

+ ```typescript

+ import { AzureFunction, Context, HttpRequest } from "@azure/functions";

+ const httpTrigger: AzureFunction = async function (context: Context, request: HttpRequest): Promise<any> {

+ let message = 'Hello, world!';

+ return {

+ httpResponse: {

+ body: message

+ },

+ queueOutput: message

+ };

+ };

+ export default httpTrigger;

+ ```

+

+ # [JavaScript](#tab/javascript)

+ # [TypeScript](#tab/typescript)

+ ```typescript

+ import { AzureFunction, Context, HttpRequest } from "@azure/functions";

+ const httpTrigger: AzureFunction = async function (context: Context, request: HttpRequest): Promise<void> {

+ let message = 'Hello, world!';

+ context.bindings.httpResponse = {

+ body: message

+ };

+ context.bindings.queueOutput = message;

+ };

+ export default httpTrigger;

+ ```

+

+# [JavaScript](#tab/javascript)

+# [TypeScript](#tab/typescript)

+```typescript

+import { AzureFunction, Context } from "@azure/functions";

+import { Buffer } from 'node:buffer';

+const queueTrigger1: AzureFunction = async function (context: Context, myQueueItem: string | Buffer): Promise<void> {

+ if (typeof myQueueItem === 'string') {

+ context.log('myQueueItem is a string');

+ } else if (Buffer.isBuffer(myQueueItem)) {

+ context.log('myQueueItem is a buffer');

+ }

+};

+export default queueTrigger1;

+```

+# [JavaScript](#tab/javascript)

+ handler: async (request, context) => {

+# [TypeScript](#tab/typescript)

+```typescript

+import { app, HttpRequest, HttpResponseInit, InvocationContext } from "@azure/functions";

+async function helloWorld1(request: HttpRequest, context: InvocationContext): Promise<HttpResponseInit> {

+ ...

+};

+app.http('helloWorld1', {

+ route: 'hello/world',

+ handler: helloWorld1

+});

+```

+# [JavaScript](#tab/javascript)

+ schedule: '0 */5 * * * *',

+ handler: (myTimer, context) => {

+# [TypeScript](#tab/typescript)

+```typescript

+import { app, InvocationContext, Timer, output } from "@azure/functions";

+async function timerTrigger1(myTimer: Timer, context: InvocationContext): Promise<any> {

+ return { hello: 'world' }

+}

+app.timer('timerTrigger1', {

+ schedule: '0 */5 * * * *',

+ return: output.storageQueue({

+ connection: 'storage_APPSETTING',

+ ...

+ }),

+ handler: timerTrigger1

+});

+```

+# [JavaScript](#tab/javascript)

+# [TypeScript](#tab/typescript)

+```typescript

+import { app, InvocationContext, input, output } from "@azure/functions";

+const blobInput = input.storageBlob({

+ connection: 'storage_APPSETTING',

+ path: 'helloworld/{queueTrigger}',

+});

+const blobOutput = output.storageBlob({

+ connection: 'storage_APPSETTING',

+ path: 'helloworld/{queueTrigger}-copy',

+});

+async function copyBlob1(queueItem: unknown, context: InvocationContext): Promise<void> {

+ const blobInputValue = context.extraInputs.get(blobInput);

+ context.extraOutputs.set(blobOutput, blobInputValue);

+}

+app.storageQueue('copyBlob1', {

+ queueName: 'copyblobqueue',

+ connection: 'storage_APPSETTING',

+ extraInputs: [blobInput],

+ extraOutputs: [blobOutput],

+ handler: copyBlob1

+});

+```

+# [JavaScript](#tab/javascript)

+ methods: ['GET', 'POST']

+# [TypeScript](#tab/typescript)

+```typescript

+import { app, InvocationContext, HttpRequest, HttpResponseInit, output, trigger } from "@azure/functions";

+async function helloWorld1(request: HttpRequest, context: InvocationContext): Promise<HttpResponseInit> {

+ context.log(`Http function processed request for url "${request.url}"`);

+ return { body: `Hello, world!` };

+}

+app.generic('helloWorld1', {

+ trigger: trigger.generic({

+ type: 'httpTrigger',

+ methods: ['GET', 'POST']

+ }),

+ return: output.generic({

+ type: 'http'

+ }),

+ handler: helloWorld1

+});

+```

+# [JavaScript](#tab/javascript)

+# [TypeScript](#tab/typescript)

+```typescript

+import { AzureFunction, Context } from "@azure/functions";

+const queueTrigger1: AzureFunction = async function (context: Context, myQueueItem: string): Promise<void> {

+ const blobValue = context.bindings.myInput;

+ context.bindings.myOutput = blobValue;

+};

+export default queueTrigger1;

+```

+# [JavaScript](#tab/javascript)

+# [TypeScript](#tab/typescript)

+```typescript

+import { AzureFunction, Context, HttpRequest } from "@azure/functions";

+const httpTrigger: AzureFunction = function (context: Context, request: HttpRequest): void {

+ context.log("this pattern is now deprecated");

+ context.done();

+};

+export default httpTrigger;

+```

+# [JavaScript](#tab/javascript)

+# [TypeScript](#tab/typescript)

+```typescript

+import { AzureFunction, Context, HttpRequest } from "@azure/functions";

+const httpTrigger: AzureFunction = async function (context: Context, request: HttpRequest): Promise<void> {

+ context.log("you don't need context.done or an awaited call")

+};

+export default httpTrigger;

+```

+> [!NOTE]

+# [JavaScript](#tab/javascript)

+context.log(`Something has happened. Invocation ID: "${context.invocationId}"`);

+# [TypeScript](#tab/typescript)

+```typescript

+context.log(`Something has happened. Invocation ID: "${context.invocationId}"`);

+```

+By default, Azure Functions writes output as traces to Application Insights. For more control, you can instead use the [Application Insights Node.js SDK](https://github.com/microsoft/applicationinsights-node.js) to send custom data to your Application Insights instance.

+# [JavaScript](#tab/javascript)

+# [TypeScript](#tab/typescript)

+```typescript

+import { AzureFunction, Context, HttpRequest } from "@azure/functions";

+import * as appInsights from 'applicationinsights';

+appInsights.setup();

+const client = appInsights.defaultClient;

+const httpTrigger: AzureFunction = async function (context: Context, request: HttpRequest): Promise<void> {

+ // Use this with 'tagOverrides' to correlate custom logs to the parent function invocation.

+ var operationIdOverride = {"ai.operation.id":context.traceContext.traceparent};

+ client.trackEvent({name: "my custom event", tagOverrides:operationIdOverride, properties: {customProperty2: "custom property value"}});

+ client.trackException({exception: new Error("handled exceptions can be logged with this method"), tagOverrides:operationIdOverride});

+ client.trackMetric({name: "custom metric", value: 3, tagOverrides:operationIdOverride});

+ client.trackTrace({message: "trace message", tagOverrides:operationIdOverride});

+ client.trackDependency({target:"http://dbname", name:"select customers proc", data:"SELECT * FROM Customers", duration:231, resultCode:0, success: true, dependencyTypeName: "ZSQL", tagOverrides:operationIdOverride});

+ client.trackRequest({name:"GET /customers", url:"http://myserver/customers", duration:309, resultCode:200, success:true, tagOverrides:operationIdOverride});

+};

+export default httpTrigger;

+```

+ # [JavaScript](#tab/javascript)

+ # [TypeScript](#tab/typescript)

+ ```typescript

+ const httpTrigger: AzureFunction = async function (context: Context, request: HttpRequest): Promise<void> {

+ context.log(`Http function processed request for url "${request.url}"`);

+ ```

+

+- **From the `context.req` property:**

+ # [JavaScript](#tab/javascript)

+ # [TypeScript](#tab/typescript)

+ ```typescript

+ const httpTrigger: AzureFunction = async function (context: Context, request: HttpRequest): Promise<void> {

+ context.log(`Http function processed request for url "${context.req.url}"`);

+ ```

+

+- **From the named input bindings:** This option works the same as any non HTTP binding. The binding name in `function.json` must match the key on `context.bindings`, or "request1" in the following example:

+ # [JavaScript](#tab/javascript)

+ # [TypeScript](#tab/typescript)

+ ```typescript

+ const httpTrigger: AzureFunction = async function (context: Context, request: HttpRequest): Promise<void> {

+ context.log(`Http function processed request for url "${context.bindings.request1.url}"`);

+ ```

+

+# [JavaScript](#tab/javascript)

+# [TypeScript](#tab/typescript)

+```typescript

+async function helloWorld1(request: HttpRequest, context: InvocationContext): Promise<HttpResponseInit> {

+ context.log(`Http function processed request for url "${request.url}"`);

+```

+> [!NOTE]

+- **Set the `context.res` property:**

+ # [JavaScript](#tab/javascript)

+ # [TypeScript](#tab/typescript)

+ ```typescript

+ const httpTrigger: AzureFunction = async function (context: Context, request: HttpRequest): Promise<void> {

+ context.res = { body: `Hello, world!` };

+ ```

+

+ # [JavaScript](#tab/javascript)

+ # [TypeScript](#tab/typescript)

+ ```typescript

+ const httpTrigger: AzureFunction = async function (context: Context, request: HttpRequest): Promise<HttpResponseSimple> {

+ return { body: `Hello, world!` };

+ ```

+

+ # [JavaScript](#tab/javascript)

+ # [TypeScript](#tab/typescript)

+ ```typescript

+ const httpTrigger: AzureFunction = async function (context: Context, request: HttpRequest): Promise<void> {

+ context.bindings.response1 = { body: `Hello, world!` };

+ ```

+

+ # [JavaScript](#tab/javascript)

+ # [TypeScript](#tab/typescript)

+ ```typescript

+ const httpTrigger: AzureFunction = function (context: Context, request: HttpRequest): void {

+ context.res.send(`Hello, world!`);

+ ```

+

+ # [JavaScript](#tab/javascript)

+ # [TypeScript](#tab/typescript)

+ ```typescript

+ return { body: `Hello, world!` };

+ ```

+

+ # [JavaScript](#tab/javascript)

+ # [TypeScript](#tab/typescript)

+ ```typescript

+ const response = new HttpResponse({ body: `Hello, world!` });

+ response.headers.set('content-type', 'application/json');

+ return response;

+ ```

+

+# [JavaScript](#tab/javascript)

+# [TypeScript](#tab/typescript)

+```typescript

+const httpTrigger: AzureFunction = async function (context: Context, request: HttpRequest): Promise<void> {

+ context.log(`WEBSITE_SITE_NAME: ${process.env["WEBSITE_SITE_NAME"]}`);

+}

+```

+# [JavaScript](#tab/javascript)

+# [TypeScript](#tab/typescript)

+```typescript

+async function timerTrigger1(myTimer: Timer, context: InvocationContext): Promise<void> {

+ context.log(`WEBSITE_SITE_NAME: ${process.env["WEBSITE_SITE_NAME"]}`);

+}

+```

+When you run locally, your functions project includes a [`local.settings.json` file](./functions-run-local.md), where you store your environment variables in the `Values` object.

+When you run in Azure, the function app lets you set and use [Application settings](functions-app-settings.md), such as service connection strings, and exposes these settings as environment variables during execution.

+# [JavaScript](#tab/javascript)

+```javascript

+export default httpTrigger;

+```

+# [TypeScript](#tab/typescript)

+```typescript

+import { AzureFunction, Context } from "@azure/functions";

+import { v4 as uuidv4 } from 'uuid';

+const httpTrigger: AzureFunction = async function (context: Context, request: HttpRequest): Promise<void> {

+ context.res.body = uuidv4();

+};

+export default httpTrigger;

+# [JavaScript](#tab/javascript)

+```javascript

+ return { body: uuidv4() };

+app.http('httpTrigger1', {

+ methods: ['GET', 'POST'],

+ handler: httpTrigger1

+});

+# [TypeScript](#tab/typescript)

+```typescript

+import { app, HttpRequest, HttpResponseInit, InvocationContext } from "@azure/functions";

+import { v4 as uuidv4 } from 'uuid';

+async function httpTrigger1(request: HttpRequest, context: InvocationContext): Promise<HttpResponseInit> {

+ return { body: uuidv4() };

+};

+app.http('httpTrigger1', {

+ methods: ['GET', 'POST'],

+ handler: httpTrigger1

+});

+```

+The `function.json` properties `scriptFile` and `entryPoint` can be used to configure the location and name of your exported function. The `scriptFile` property is required when you're using TypeScript and should point to the compiled JavaScript.

+# [JavaScript](#tab/javascript)

+async function logHello(context) {

+ context.log('Hello, world!');

+# [TypeScript](#tab/typescript)

+```typescript

+import { AzureFunction, Context } from "@azure/functions";

+const logHello: AzureFunction = async function (context: Context): Promise<void> {

+ context.log('Hello, world!');

+};

+export default { logHello };

+## Local debugging

+It's recommended to use VS Code for local debugging, which starts your Node.js process in debug mode automatically and attaches to the process for you. For more information, see [run the function locally](./create-first-function-vs-code-node.md#run-the-function-locally).

+If you're using a different tool for debugging or want to start your Node.js process in debug mode manually, add `"languageWorkers__node__arguments": "--inspect"` under `Values` in your [local.settings.json](./functions-develop-local.md#local-settings-file). The `--inspect` argument tells Node.js to listen for a debug client, on port 9229 by default. For more information, see the [Node.js debugging guide](https://nodejs.org/en/docs/guides/debugging-getting-started).

+When you create a function app that uses the App Service plan, we recommend that you select a single-vCPU plan rather than a plan with multiple vCPUs. Today, Functions runs Node.js functions more efficiently on single-vCPU VMs, and using larger VMs doesn't produce the expected performance improvements. When necessary, you can manually scale out by adding more single-vCPU VM instances, or you can enable autoscale. For more information, see [Scale instance count manually or automatically](../azure-monitor/autoscale/autoscale-get-started.md?toc=/azure/app-service/toc.json).

+When you develop Azure Functions in the serverless hosting model, cold starts are a reality. *Cold start* refers to the first time your function app starts after a period of inactivity, taking longer to start up. For Node.js apps with large dependency trees in particular, cold start can be significant. To speed up the cold start process, [run your functions as a package file](run-functions-from-deployment-package.md) when possible. Many deployment methods use this model by default, but if you're experiencing large cold starts you should check to make sure you're running this way.

+When writing Azure Functions in Node.js, you should write code using the `async` and `await` keywords. Writing code using `async` and `await` instead of callbacks or `.then` and `.catch` with Promises helps avoid two common problems:

+# [JavaScript](#tab/javascript)

+# [TypeScript](#tab/typescript)

+```typescript

+// NOT RECOMMENDED PATTERN

+import { AzureFunction, Context } from "@azure/functions";

+import * as fs from 'fs';

+const trigger1: AzureFunction = function (context: Context): void {

+ fs.readFile('./hello.txt', (err, data) => {

+ if (err) {

+ context.log.error('ERROR', err);

+ // BUG #1: This will result in an uncaught exception that crashes the entire process

+ throw err;

+ }

+ context.log(`Data from file: ${data}`);

+ // context.done() should be called here

+ });

+ // BUG #2: Data is not guaranteed to be read before the Azure Function's invocation ends

+ context.done();

+}

+export default trigger1;

+```

+# [JavaScript](#tab/javascript)

+# [TypeScript](#tab/typescript)

+```typescript

+// Recommended pattern

+import { AzureFunction, Context } from "@azure/functions";

+import * as fs from 'fs/promises';

+const trigger1: AzureFunction = async function (context: Context): Promise<void> {

+ let data: Buffer;

+ try {

+ data = await fs.readFile('./hello.txt');

+ } catch (err) {

+ context.log.error('ERROR', err);

+ // This rethrown exception will be handled by the Functions Runtime and will only fail the individual invocation

+ throw err;

+ }

+ context.log(`Data from file: ${data}`);

+}

+export default trigger1;

+```

+```bash

+ df -h

+```output

+```bash

+ cd /var/log

+ du -h syslog*

+```output

+```bash

+ sudo lsof +L1

+```

+```output

+ ```config

+ ```config

+ Title: 'IT Service Management Connector: Secure Webhook in Azure Monitor - Azure configurations'

+description: This article shows you how to configure Azure to connect your ITSM products or services with Secure Webhook in Azure Monitor to centrally monitor and manage ITSM work items.

+# Configure Azure to connect ITSM tools by using Secure Webhook

+To register the application with Azure Active Directory (Azure AD):

+1. In Azure AD, select **Expose application**.

+1. Select **Set** for **Application ID URI**.

+ [](media/itsm-connector-secure-webhook-connections-azure-configuration/azure-ad-expand.png#lightbox)

+1. Select **Save**.

+## Define a service principal

+The action group service is a first-party application. It has permission to acquire authentication tokens from your Azure AD application to authenticate with ServiceNow.

+As an optional step, you can define an application role in the created app's manifest. This way, you can further restrict access so that only certain applications with that specific role can send messages. This role has to be then assigned to the Action Group service principal. Tenant admin privileges are required.

+You can do this step by using the same [PowerShell commands](../alerts/action-groups.md#secure-webhook-powershell-script).

+After your application is registered with Azure AD, you can create work items in your ITSM tool based on Azure alerts by using the Secure Webhook action in action groups.

+Action groups provide a modular and reusable way of triggering actions for Azure alerts. You can use action groups with metric alerts, activity log alerts, and Log Analytics alerts in the Azure portal.

+1. Select **Alerts** > **Manage actions**.

+1. Select [Add action group](../alerts/action-groups.md#create-an-action-group-by-using-the-azure-portal) and fill in the fields.

+1. Enter a name in the **Action group name** box and enter a name in the **Short name** box. The short name is used in place of a full action group name when notifications are sent by using this group.

+1. Select **Secure Webhook**.

+1. Select these details:

+ 1. Select the object ID of the Azure AD instance that you registered.

+ 1. For the URI, paste in the webhook URL that you copied from the [ITSM tool environment](#configure-the-itsm-tool-environment).

+ 1. Set **Enable the common Alert Schema** to **Yes**.

+ * [ServiceNow](./itsmc-secure-webhook-connections-servicenow.md)

+ * [BMC Helix](./itsmc-secure-webhook-connections-bmc.md)

+1. Get the URI for the Secure Webhook definition.

+1. Create definitions based on ITSM tool flow.

+* [ServiceNow Secure Webhook configuration](./itsmc-secure-webhook-connections-servicenow.md)

+* [BMC Secure Webhook configuration](./itsmc-secure-webhook-connections-bmc.md)

+ 1. [Define a service principal](./itsm-connector-secure-webhook-connections-azure-configuration.md#define-a-service-principal).

+ Title: 'IT Service Management Connector: Secure Webhook in Azure Monitor - Configuration with BMC'

+description: This article shows you how to connect your ITSM products or services with BMC on Secure Webhook in Azure Monitor.

+* Azure Active Directory is registered.

+1. Use the following procedure in the BMC Helix environment to get the URI for the Secure Webhook:

+ 1. Sign in to Integration Studio.

+ 1. Copy the webhook URL.

+ 

+1. Follow the instructions according to the version:

+ * [Enabling prebuilt integration with Azure Monitor for version 20.02](https://docs.bmc.com/docs/multicloud/enabling-prebuilt-integration-with-azure-monitor-879728195.html)

+ * [Enabling prebuilt integration with Azure Monitor for version 19.11](https://docs.bmc.com/docs/multicloudprevious/enabling-prebuilt-integration-with-azure-monitor-904157623.html)

+1. As a part of the configuration of the connection in BMC Helix, go into your integration BMC instance and follow these instructions:

+ 1. Select **Azure alerts**.

+ 1. Select **connectors**.

+ 1. Select **configuration**.

+ 1. Select the **add new connection** configuration.

+ 1. Fill in the information for the configuration section:

+ 

+description: This article provides an overview of data synced from your ITSM product to LA Workspace.

+Incidents and change requests are synced from [ServiceNow](./itsmc-connections-servicenow.md) to your Log Analytics workspace based on the connection's configuration by using the **Sync Data** field.

+This section shows some examples of data gathered by ITSM Connector.

+The fields in **ServiceDesk_CL** vary depending on the work item type that you import into Log Analytics. Here are fields for two work item types:

+**Work item:** **Incidents**

+| ClosedDate_t| Closed|

+| Computer | Configuration item |

+[Troubleshooting problems in ITSM Connector](./itsmc-resync-servicenow.md)

+ Title: 'Smart detection rule settings: Application Insights'

+description: Automate management and configuration of Application Insights smart detection rules with Azure Resource Manager templates.

+# Manage Application Insights smart detection rules by using Azure Resource Manager templates

+>You can migrate your Application Insight resources to alerts-based smart detection (preview). The migration creates alert rules for the different smart detection modules. After you create the rules, you can manage and configure them like any other Azure Monitor alert rules. You can also configure action groups for these rules to enable multiple methods of taking actions or triggering notification on new detections.

+> For more information on the migration process and the behavior of smart detection after the migration, see [Smart detection alerts migration](./alerts-smart-detections-migration.md).

+>

+ You can manage and configure smart detection rules in Application Insights by using [Azure Resource Manager templates](../../azure-resource-manager/templates/syntax.md).

+You can use this method when you deploy new Application Insights resources with Resource Manager automation or when you modify the settings of existing resources.

+- If the rule is enabled. (The default is **true**.)

+- If emails should be sent to users associated to the subscription's [Monitoring Reader](../../role-based-access-control/built-in-roles.md#monitoring-reader) and [Monitoring Contributor](../../role-based-access-control/built-in-roles.md#monitoring-contributor) roles when a detection is found. (The default is **true**.)

+- Any other email recipients who should get a notification when a detection is found.

+ - Email configuration isn't available for smart detection rules marked as _preview_.

+To allow configuring the rule settings via Resource Manager, the smart detection rule configuration is available as an inner resource within the Application Insights resource. It's named **ProactiveDetectionConfigs**.

+For maximal flexibility, you can configure each smart detection rule with unique notification settings.

+The following examples show how to configure the settings of smart detection rules by using Resource Manager templates.

+All samples refer to an Application Insights resource named _"myApplication"_. They also refer to the "long dependency duration smart detection rule." It's internally named _"longdependencyduration"_.

+Make sure to replace the Application Insights resource name and to specify the relevant smart detection rule internal name. Check the following table for a list of the corresponding internal Resource Manager names for each smart detection rule.

+### Add more email recipients for a smart detection rule

+The following table shows smart detection rule names as they appear in the portal. The table also shows their internal names to use in the Resource Manager template.

+> Smart detection rules marked as _preview_ don't support email notifications. You can only set the _enabled_ property for these rules.

+This Resource Manager template demonstrates how to configure a Failure Anomalies alert rule with a severity of 2.

+> Failure Anomalies is a global service, so rule location is created on the global location.

+> This Resource Manager template is unique to the Failure Anomalies alert rule and is different from the other classic smart detection rules described in this article. If you want to manage Failure Anomalies manually, use Azure Monitor alerts. All other smart detection rules are managed in the **Smart Detection** pane of the UI.

+## Next steps

+- [Memory leaks](./proactive-potential-memory-leak.md)

+ Title: 'Detect memory leak: Application Insights smart detection'

+description: Monitor applications with Application Insights for potential memory leaks.

+>You can migrate your Application Insight resources to alerts-based smart detection (preview). The migration creates alert rules for the different smart detection modules. After you create the rules, you can manage and configure them like any other Azure Monitor alert rules. You can also configure action groups for these rules to enable multiple methods of taking actions or triggering notification on new detections.

+> For more information, see [Smart detection alerts migration](./alerts-smart-detections-migration.md).

+Smart detection automatically analyzes the memory consumption of each process in your application. It can warn you about potential memory leaks or increased memory consumption.

+This feature requires no special setup other than [configuring performance counters](../app/performance-counters.md) for your app. It's active when your app generates enough memory performance counters telemetry (for example, Private Bytes).

+A typical notification follows a consistent increase:

+- In memory consumption over a long period of time.

+- In one or more processes or machines that are part of your application.

+Machine learning algorithms are used to detect increased memory consumption that matches the pattern of a memory leak.

+A notification doesn't mean that your app definitely has a problem. Although memory leak patterns might indicate an application issue, these patterns might be typical to your specific process. Memory leak patterns might also have a natural business justification. In such cases, you can ignore the notification.

+1. **Triage:** The notification shows you the amount of memory increase (in GB) and the time range in which the memory has increased. This information can help you assign a priority to the problem.

+1. **Scope:** How many machines exhibited the memory leak pattern? How many exceptions were triggered during the potential memory leak? You can obtain this information from the notification.

+1. **Diagnose:** The detection contains the memory leak pattern and shows memory consumption of the process over time. You can also use the related items and reports linking to supporting information to help you further diagnose the issue.

+For more information on correlation, see [Telemetry correlation in Application Insights](distributed-tracing-telemetry-correlation.md).

+Application Insights supports [distributed tracing](distributed-tracing-telemetry-correlation.md), which is also known as distributed component correlation. This feature allows [searching for](diagnostic-search.md) and [visualizing](transaction-diagnostics.md) an end-to-end flow of a specific execution or transaction. The ability to trace activity from end to end is important for applications that were built as distributed components or [microservices](/azure/architecture/guide/architecture-styles/microservices).

+* To learn more about how correlation works in Application Insights, see [Telemetry correlation](distributed-tracing-telemetry-correlation.md).

+An operation is a logical piece of work run by an application. It has a name, start time, duration, result, and a context of execution like user name, properties, and result. If operation A was initiated by operation B, then operation B is set as a parent for A. An operation can have only one parent, but it can have many child operations. For more information on operations and telemetry correlation, see [Application Insights telemetry correlation](distributed-tracing-telemetry-correlation.md).

+- Learn the basics of [telemetry correlation](distributed-tracing-telemetry-correlation.md) in Application Insights.

+ An *operation* is made up of the threads of execution that process a request. You can also [write code](./api-custom-events-metrics.md#trackrequest) to monitor other types of operation, such as a "wake up" in a web job or function that periodically processes data. Each operation has an ID. The ID can be used to [group](distributed-tracing-telemetry-correlation.md) all telemetry generated while your app is processing the request. Each operation either succeeds or fails and has a duration of time.

+The Application Insights telemetry model defines a way to [correlate](distributed-tracing-telemetry-correlation.md) telemetry to the operation of which it's a part. For example, a request can make a SQL Database call and record diagnostics information. You can set the correlation context for those telemetry items that tie it back to the request telemetry.

+ID is the identifier of a request call instance. It's used for correlation between the request and other telemetry items. The ID should be globally unique. For more information, see [Telemetry correlation in Application Insights](distributed-tracing-telemetry-correlation.md).

+Source is the source of the request. Examples are the instrumentation key of the caller or the IP address of the caller. For more information, see [Telemetry correlation in Application Insights](distributed-tracing-telemetry-correlation.md).

+ID is the identifier of a dependency call instance. It's used for correlation with the request telemetry item that corresponds to this dependency call. For more information, see [Telemetry correlation in Application Insights](distributed-tracing-telemetry-correlation.md).

+This field is the target site of a dependency call. Examples are server name and host address. For more information, see [Telemetry correlation in Application Insights](distributed-tracing-telemetry-correlation.md).

+This field is the unique identifier of the root operation. This identifier allows grouping telemetry across multiple components. For more information, see [Telemetry correlation](distributed-tracing-telemetry-correlation.md). Either a request or a page view creates the operation ID. All other telemetry sets this field to the value for the containing request or page view.

+This field is the unique identifier of the telemetry item's immediate parent. For more information, see [Telemetry correlation](distributed-tracing-telemetry-correlation.md).

+Update-AzApplicationInsights -Name "aiName" -ResourceGroupName "rgName" -DisableIPMasking:$true

+* Get an overview of [distributed tracing](distributed-tracing-telemetry-correlation.md) and see what [Application Map](./app-map.md?tabs=net) can do for your business.

+* Get an overview of [distributed tracing](distributed-tracing-telemetry-correlation.md).

+For information on how to enrich your logs with trace context data, see OpenCensus Python [logs integration](distributed-tracing-telemetry-correlation.md#log-correlation).

+For more information on telemetry correlation in your trace data, see OpenCensus Python [telemetry correlation](distributed-tracing-telemetry-correlation.md#telemetry-correlation-in-opencensus-python).

+ The target rate of [logical operations](distributed-tracing-telemetry-correlation.md#data-model-for-telemetry-correlation) that the adaptive algorithm aims to collect **on each server host**. If your web app runs on many hosts, reduce this value so as to remain within your target rate of traffic at the Application Insights portal.

+# [.NET 5.0+](#tab/dotnet5)

+1. Set the instrumentation key in the `appsettings.json` file:

+ ```json

+ {

+ "ApplicationInsights": {

+ "InstrumentationKey" : "InstrumentationKey=00000000-0000-0000-0000-000000000000;"

+ }

+ }

+ ```

+2. Retrieve the instrumentation key in `Program.cs` when registering the `ApplicationInsightsTelemetry` service:

+ ```csharp

+ var options = new ApplicationInsightsServiceOptions { ConnectionString = app.Configuration["ApplicationInsights:InstrumentationKey"] };

+ builder.Services.AddApplicationInsightsTelemetry(options: options);

+ ```

+> [!NOTE]

+> When deploying applications to Azure in production scenarios, consider placing instrumentation keys or other configuration secrets in secure locations such as App Service configuration settings or Azure Key Vault. Avoid including secrets in your application code or checking them into source control where they might be exposed or misused. The preceding code example will also work if the instrumentation key is stored in App Service configuration settings. Learn more about [configuring App Service settings](/azure/app-service/configure-common).

+# [.NET Framework](#tab/dotnet-framework)

+Explicitly set the instrumentation key in code:

+Set the instrumentation key using a configuration file:

+The transaction diagnostics experience shows all telemetry in a [single operation](distributed-tracing-telemetry-correlation.md#data-model-for-telemetry-correlation) that shares an [Operation ID](data-model-complete.md#operation-id). By default, the Application Insights SDK for JavaScript creates a new operation for each unique page view. In a single-page application (SPA), only one page view event will be generated and a single Operation ID will be used for all telemetry generated. As a result, many events might be correlated to the same operation.

+This error indicates that the browser was unable to call into a required API or the API returned a failure response. To troubleshoot the behavior, open a browser [InPrivate window](https://support.microsoft.com/microsoft-edge/browse-inprivate-in-microsoft-edge-cd2c9a48-0bc4-b98e-5e46-ac40c84e27e2) and [disable any browser extensions](https://support.microsoft.com/microsoft-edge/add-turn-off-or-remove-extensions-in-microsoft-edge-9c0ec68c-2fbc-2f2c-9ff0-bdc76f46b026) that are running, then identify if you can still reproduce the portal behavior. If the portal error still occurs, try testing with other browsers, or other machines, investigate DNS or other network related issues from the client machine where the API calls are failing. If the portal error persists and requires further investigations, then [collect a browser network trace](../../azure-portal/capture-browser-trace.md#capture-a-browser-trace-for-troubleshooting) while you reproduce the unexpected portal behavior and open a support case from the Azure portal.

+This custom operation of `RequestTelemetry` can be thought of as the equivalent of an incoming web request in a typical web application. It isn't necessary to use an operation, but it fits best with the [Application Insights correlation data model](distributed-tracing-telemetry-correlation.md). `RequestTelemetry` acts as the parent operation and every telemetry generated inside the worker iteration is treated as logically belonging to the same operation.

+As you expand the objects in the hierarchy, the properties pane updates based on the object selected. From the pane, you also can view Kubernetes container logs (stdout/stderror), events, and pod metrics by selecting the **Live Events** tab at the top of the pane. For more information about the configuration required to grant and control access to view this data, see [Set up the Live Data](container-insights-livedata-setup.md).

+Azure Network Policy Manager includes informative Prometheus metrics that you can use to monitor and better understand your network configurations. It provides built-in visualizations in either the Azure portal or Grafana Labs. For more information, see [Monitor and visualize network configurations with Azure npm](../../virtual-network/kubernetes-network-policies.md#monitor-and-visualize-network-configurations-with-azure-npm).

+With Container insights Live Data, you can visualize metrics about node and pod state in a cluster in real time. The feature emulates direct access to the `kubectl top nodes`, `kubectl get pods --all-namespaces`, and `kubectl get nodes` commands to call, parse, and visualize the data in performance charts that are included with this insight.

+For help with setting up or troubleshooting the Live Data feature, review the [setup guide](container-insights-livedata-setup.md).

+The Live Data feature directly accesses the Kubernetes API. For more information about the authentication model, see [The Kubernetes API](https://kubernetes.io/docs/concepts/overview/kubernetes-api/).

+This performance chart maps to an equivalent of invoking `kubectl get pods --all-namespaces` and maps the **STATUS** column the chart grouped by status types.

+> [!NOTE]

+> AKS uses [Kubernetes cluster-level logging architectures](https://kubernetes.io/docs/concepts/cluster-administration/logging/#cluster-level-logging-architectures). You can use tools such as Fluentd or Fluent Bit to collect logs.

+To view the live logs for pods, deployments, replica sets, stateful sets, daemon sets, and jobs with or without Container insights from the AKS resource view:

+1. Select a pod, deployment, replica set, stateful set, daemon set, or job from the respective tab.

+ :::image type="content" source="./media/container-insights-livedata-overview/live-data-deployment.png" alt-text="Screenshot that shows the deployment of live logs." lightbox="./media/container-insights-livedata-overview/live-data-deployment.png":::

+1. Select an object from the performance grid. In the **Properties** pane on the right side, select the **Live Logs** tab. If the AKS cluster is configured with single sign-on by using Azure Active Directory (Azure AD), you're prompted to authenticate on first use during that browser session. Select your account and finish authentication with Azure.

+ >To view the data from your Log Analytics workspace, select **View in Log analytics** in the **Properties** pane. The log search results potentially show **Nodes**, **Daemon Sets**, **Replica Sets**, **Stateful Sets**, **Jobs**, **Cron Jobs**, **Pods**, and **Containers**. These logs might no longer exist. The log search results for **Stateful Sets** shows the data for the pods in a stateful set. Attempting to search logs for a container that isn't available in `kubectl` will also fail here. To learn more about viewing historical logs, events, and metrics, see [How to query logs from Container insights](container-insights-log-query.md).

+After successful authentication, if data can be retrieved, it begins streaming to the Live Logs tab. You can view log data here in a continuous stream.

+You can view real-time event data as it's generated by the container engine on the **Nodes**, **Controllers**, **Containers**, or **Deployments** view when a container, pod, node, ReplicaSet, StatefulSet, DaemonSet, job, CronJob, or Deployment is selected. To view events:

+1. Select an object from the performance grid. In the **Properties** pane on the right side, select the **Live Events** tab. If the AKS cluster is configured with single sign-on by using Azure AD, you're prompted to authenticate on first use during that browser session. Select your account and finish authentication with Azure.

+ >To view the data from your Log Analytics workspace, select **View in Log Analytics** in the **Properties** pane. The log search results potentially show **Nodes**, **Daemon Sets**, **Replica Sets**, **Stateful Sets**, **Jobs**, **Cron Jobs**, **Pods**, and **Containers**. These logs might no longer exist. The log search results for **Stateful Sets** shows the data for the pods in a stateful set. Attempting to search logs for a container that isn't available in `kubectl` will also fail here. To learn more about viewing historical logs, events, and metrics, see [How to query logs from Container insights](container-insights-log-query.md).

+After successful authentication, if data can be retrieved, it begins streaming to the Live Events tab.

+While you view events, you can also limit the results by using the **Filter** pill found below the search bar. Depending on the resource you select, the pill lists a node, pod, namespace, or cluster to choose from.

+1. Select a **Pod** object from the performance grid. In the **Properties** pane on the right side, select the **Live Metrics** tab. If the AKS cluster is configured with single sign-on by using Azure AD, you're prompted to authenticate on first use during that browser session. Select your account and finish authentication with Azure.

+ >To view the data from your Log Analytics workspace, select the **View in Log Analytics** option in the **Properties** pane. The log search results potentially show **Nodes**, **Daemon Sets**, **Replica Sets**, **Stateful Sets**, **Jobs**, **Cron Jobs**, **Pods**, and **Containers**. These logs might no longer exist. The log search results for **Stateful Sets** shows the data for the pods in a stateful set. Attempting to search logs for a container that isn't available in `kubectl` will also fail here. To learn more about viewing historical logs, events, and metrics, see [How to query logs from Container insights](container-insights-log-query.md).

+After successful authentication, metric data is retrieved and begins streaming to the Live Metrics tab for presentation in the two charts.

+The Live Data feature includes search functionality. In the **Search** box, you can filter results by entering a keyword or term. Any matching results are highlighted to allow quick review. While you view the events, you can also limit the results by using the **Filter** feature below the search bar. Depending on what resource you've selected, you can choose from a node, pod, namespace, or cluster.

+To suspend autoscroll and control the behavior of the tab so that you can manually scroll through the new data read, select the **Scroll** option. To re-enable autoscroll, select **Scroll** again. You can also pause retrieval of log or event data by selecting the **Pause** option. When you're ready to resume, select **Play**.

+## Migrate from metric rules to Prometheus rules (preview)

+1. Follow the steps at [Enable Prometheus alert rules](#enable-prometheus-alert-rules) to configure Prometheus recommended alert rules (preview).

+2. Follow the steps at [Disable metric alert rules](#disable-metric-alert-rules) to remove metric alert rules from your clusters.

+| Failed Pod Counts | Failed Pod Counts | Calculates number of pods in failed state. | 0 |

+[Prometheus](https://aka.ms/azureprometheus-promio) is a popular open-source metric monitoring solution and is the most common monitoring tool used to monitor Kubernetes clusters. Container insights uses its containerized agent to collect much of the same data that Prometheus typically collects from the cluster without requiring a Prometheus server. This data is presented in Container insights views and available to other Azure Monitor features such as [log queries](container-insights-log-query.md) and [log alerts](container-insights-log-alerts.md).

+[Azure Monitor managed service for Prometheus](../essentials/prometheus-metrics-overview.md) is a fully managed Prometheus-compatible service that supports industry standard features such as PromQL, Grafana dashboards, and Prometheus alerts. This service requires configuring the *metrics addon* for the Azure Monitor agent, which sends data to Prometheus.

+Use the following procedure to add Prometheus collection to your cluster that's already using Container insights.

+You may want to collect more data in addition to the predefined set of data collected by Container insights. This data isn't used by Container insights views but is available for log queries and alerts like the other data it collects. This requires configuring the *monitoring addon* for the Azure Monitor agent, which is the one currently used by Container insights to send data to a Log Analytics workspace.

+| | `monitor_kubernetes_pods` | Boolean | true or false | When set to `true` in the cluster-wide settings, the Container insights agent scrapes Kubernetes pods across the entire cluster for the following Prometheus annotations:<br> `prometheus.io/scrape:`<br> `prometheus.io/scheme:`<br> `prometheus.io/path:`<br> `prometheus.io/port:` |

+| | `prometheus.io/port` | String | 9102 | Specify a port to scrape from. If the port isn't set, it defaults to 9102. |

+If there are configuration errors from the Azure Monitor Agent pods, the output shows errors similar to the following example:

+- From Live Data. Live Data logs show errors similar to the following example:

+- From the **KubeMonAgentEvents** table in your Log Analytics workspace. Data is sent every hour with *Warning* severity for scrape errors and *Error* severity for configuration errors. If there are no errors, the entry in the table has data with severity *Info*, which reports no errors. The **Tags** property contains more information about the pod and container ID on which the error occurred and also the first occurrence, last occurrence, and count in the last hour.

+# [Ubuntu, Debian](#tab/ubuntu)

+Add the repository:

+sudo echo "deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/influxdb.list

+sudo curl -fsSL https://repos.influxdata.com/influxdata-archive_compat.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/influxdata-archive_compat.gpg add

+Instal the package:

+```bash

+ apt-get update

+ apt-get install telegraf

+```

+# [RHEL, CentOS, Oracle Linux](#tab/redhat)

+Add the repository:

+```bash

+cat <<EOF | sudo tee /etc/yum.repos.d/influxdb.repo

+[influxdb]

+name = InfluxDB Repository - RHEL $releasever

+baseurl = https://repos.influxdata.com/rhel/$releasever/$basearch/stable

+enabled = 1

+gpgcheck = 1

+gpgkey = https://repos.influxdata.com/influxdata-archive_compat.key

+EOF

+```

+Instal the package:

+```bash

+ sudo yum -y install telegraf

+```

+# start and enable the telegraf agent on the VM to ensure it picks up the latest configuration

+sudo systemctl enable --now telegraf

+## [Terraform](#tab/terraform)

+### Prerequisites

+- Register the `AKS-PrometheusAddonPreview` feature flag in the Azure Kubernetes clusters subscription with the following command in Azure CLI: `az feature register --namespace Microsoft.ContainerService --name AKS-PrometheusAddonPreview`.

+- If the Azure Managed Grafana instance is in a subscription other than the Azure Monitor Workspaces subscription, register the Azure Monitor Workspace subscription with the `Microsoft.Dashboard` resource provider by following [this documentation](../../azure-resource-manager/management/resource-providers-and-types.md#register-resource-provider).

+- The Azure Monitor workspace and Azure Managed Grafana workspace must already be created.

+- The template needs to be deployed in the same resource group as the Azure Managed Grafana workspace.

+- Users with the User Access Administrator role in the subscription of the AKS cluster can enable the Monitoring Data Reader role directly by deploying the template.

+### Retrieve required values for a Grafana resource

+On the **Overview** page for the Azure Managed Grafana instance in the Azure portal, select **JSON view**.

+If you're using an existing Azure Managed Grafana instance that's already linked to an Azure Monitor workspace, you need the list of Grafana integrations. Copy the value of the `azureMonitorWorkspaceIntegrations` field. If it doesn't exist, the instance hasn't been linked with any Azure Monitor workspace. Update the azure_monitor_workspace_integrations block(shown below) in main.tf with the list of grafana integrations.

+```.tf

+ azure_monitor_workspace_integrations {

+ resource_id = var.monitor_workspace_id[var.monitor_workspace_id1, var.monitor_workspace_id2]

+ }

+```

+### Download and edit the templates

+If you are deploying a new AKS cluster using Terraform with managed Prometheus addon enabled, follow the steps below.

+1. Please download all files under [AddonTerraformTemplate](https://aka.ms/AAkm357).

+2. Edit the variables in variables.tf file with the correct parameter values.

+3. Run `terraform init -upgrade` to initialize the Terraform deployment.

+4. Run `terraform plan -out main.tfplan` to initialize the Terraform deployment.

+5. Run `terraform apply main.tfplan` to apply the execution plan to your cloud infrastructure.

+Note: Pass the variables for `annotations_allowed` and `labels_allowed` keys in main.tf only when those values exist. These are optional blocks.

+**NOTE**

+- Please edit the main.tf file appropriately before running the terraform template

+- Please add in any existing azure_monitor_workspace_integrations values to the grafana resource before running the template otherwise the older values will get deleted and replaced with what is there in the template at the time of deployment

+- Users with 'User Access Administrator' role in the subscription of the AKS cluster can be able to enable 'Monitoring Data Reader' role directly by deploying the template.

+- Please edit the grafanaSku parameter if you are using a non standard SKU.

+- Please run this template in the Grafana Resources RG.

+ Title: Enable Profiler for ASP.NET Core web apps hosted in Linux on App Service | Microsoft Docs

+description: Learn how to enable Profiler on your ASP.NET Core web application hosted in Linux on Azure App Service.

+# Enable Profiler for ASP.NET Core web apps hosted in Linux on App Service

+By using Profiler, you can track how much time is spent in each method of your live ASP.NET Core web apps that are hosted in Linux on Azure App Service. This article focuses on web apps hosted in Linux. You can also experiment by using Linux, Windows, and Mac development environments.

+In this article, you:

+- Install the [latest .NET Core SDK](https://dotnet.microsoft.com/download/dotnet).

+- Install Git by following the instructions at [Getting started: Installing Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git).

+ - [Application Insights Profiler for Worker Service example](https://github.com/microsoft/ApplicationInsights-Profiler-AspNetCore/tree/main/examples/ServiceProfilerInWorkerNet6)

+1. Open a command prompt window on your machine.

+1. In the Azure portal, create a web app environment by using App Service on Linux.

+ :::image type="content" source="./media/profiler-aspnetcore-linux/create-web-app.png" alt-text="Screenshot that shows creating the Linux web app.":::

+1. Go to your new web app resource and select **Deployment Center** > **FTPS credentials** to create the deployment credentials. Make a note of your credentials to use later.

+ :::image type="content" source="./media/profiler-aspnetcore-linux/credentials.png" alt-text="Screenshot that shows creating the deployment credentials.":::

+1. Select **Save**.

+1. Select the **Settings** tab.

+1. In the dropdown, select **Local Git** to set up a local Git repository in the web app.

+ :::image type="content" source="./media/profiler-aspnetcore-linux/deployment-options.png" alt-text="Screenshot that shows view deployment options in a dropdown.":::

+1. Select **Save** to create a Git repository with a Git clone URI.

+ :::image type="content" source="./media/profiler-aspnetcore-linux/local-git-repo.png" alt-text="Screenshot that shows setting up the local Git repository.":::

+ For more deployment options, see the [App Service documentation](../../app-service/deploy-best-practices.md).

+1. In your command prompt window, browse to the root folder for your project. Add a Git remote repository to point to the repository on App Service:

+1. Deploy the project by pushing the changes to Azure:

+You have three options to add Application Insights to your web app:

+- By using the **Application Insights** pane in the Azure portal.

+- By using the **Configuration** pane in the Azure portal.

+- By manually adding to your web app settings.

+1. In your web app on the Azure portal, select **Application Insights** on the left pane.

+1. Select **Turn on Application Insights**.

+ :::image type="content" source="./media/profiler-aspnetcore-linux/turn-on-app-insights.png" alt-text="Screenshot that shows turning on Application Insights.":::

+ :::image type="content" source="./media/profiler-aspnetcore-linux/enable-app-insights.png" alt-text="Screenshot that shows enabling Application Insights.":::

+1. Under **Link to an Application Insights resource**, either create a new resource or select an existing resource. For this example, we create a new resource.

+ :::image type="content" source="./media/profiler-aspnetcore-linux/link-app-insights.png" alt-text="Screenshot that shows linking Application Insights to a new or existing resource.":::

+1. Select **Apply** > **Yes** to apply and confirm.

+1. [Create an Application Insights resource](../app/create-workspace-resource.md) in the same Azure subscription as your App Service instance.

+1. Go to the Application Insights resource.

+1. In your web app in the Azure portal, select **Configuration** on the left pane.

+1. Select **New application setting**.

+ :::image type="content" source="./media/profiler-aspnetcore-linux/new-setting-configuration.png" alt-text="Screenshot that shows adding a new application setting in the Configuration pane.":::

+1. Add the following settings in the **Add/Edit application setting** pane by using your saved iKey:

+ :::image type="content" source="./media/profiler-aspnetcore-linux/add-ikey-settings.png" alt-text="Screenshot that shows adding the iKey to the Settings pane.":::

+1. Select **OK**.

+ :::image type="content" source="./media/profiler-aspnetcore-linux/save-app-insights-key.png" alt-text="Screenshot that shows saving the Application Insights key settings.":::

+1. Select **Save**.

+1. [Create an Application Insights resource](../app/create-workspace-resource.md) in the same Azure subscription as your App Service instance.

+1. Go to the Application Insights resource.

+1. In your preferred code editor, go to your ASP.NET Core project's `appsettings.json` file.

+1. Add the following code and insert your copied iKey:

+ Title: Configure BYOS for Profiler and Snapshot Debugger

+description: Configure Bring Your Own Storage (BYOS) for Profiler and Snapshot Debugger.

+# Configure BYOS for Application Insights Profiler and Snapshot Debugger

+This article shows you how to configure Bring Your Own Storage (BYOS) for Application Insights Profiler and Snapshot Debugger.

+## What is BYOS and why might I need it?

+When you use Application Insights Profiler or Snapshot Debugger, artifacts generated by your application are uploaded into Azure Storage accounts over the public internet. For these artifacts and storage accounts, Microsoft controls and covers the cost for:

+When you configure BYOS, artifacts are uploaded into a storage account that you control. That means you control and are responsible for the cost of:

+> BYOS is required if you're enabling Azure Private Link or customer-managed keys.

+>

+> * [Learn more about customer-managed keys for Application Insights](../logs/customer-managed-keys.md).

+## How is my storage account accessed?

+1. Agents running in your virtual machines or Azure App Service upload artifacts (profiles, snapshots, and symbols) to blob containers in your account.

+ This process involves contacting Profiler or Snapshot Debugger to obtain a shared access signature token to a new blob in your storage account.

+1. Profiler or Snapshot Debugger will:

+ - Analyze the incoming blob.

+ - Write back the analysis results and log files into blob storage.

+ Depending on available compute capacity, this process might occur anytime after upload.

+1. When you view Profiler traces or Snapshot Debugger analysis, the service fetches the analysis results from blob storage.

+* Create your storage account in the same location as your Application Insights resource.

+ For example, if your Application Insights resource is in West US 2, your storage account must also be in West US 2.

+* Grant the `Storage Blob Data Contributor` role to the Azure Active Directory (Azure AD) application named `Diagnostic Services Trusted Storage Access` via the [Access Control (IAM)](../../role-based-access-control/role-assignments-portal.md) page in your storage account.

+This section shows you how to enable BYOS.

+### Grant access to Diagnostic Services to your storage account

+A BYOS storage account is linked to an Application Insights resource. There might be only one storage account per Application Insights resource and both must be in the same location. You might use the same storage account with more than one Application Insights resource.

+First, Application Insights Profiler and Snapshot Debugger must be granted access to the storage account. To grant access, add the role `Storage Blob Data Contributor` to the Azure AD application named `Diagnostic Services Trusted Storage Access` via the **Access Control (IAM)** page in your storage account.

+1. Select **Add** > **Add role assignment** to open the **Add role assignment** page.

+1. Assign the following role. For more information, see [Assign Azure roles by using the Azure portal](../../role-based-access-control/role-assignments-portal.md).

+ :::image type="content" source="media/profiler-bring-your-own-storage/add-role-assignment-page.png" alt-text="Screenshot that shows the Add role assignment page in the Azure portal.":::

+

+ After you add the role, it appears under the **Role assignments** section.

+ :::image type="content" source="media/profiler-bring-your-own-storage/figure-11.png" alt-text="Screenshot that shows the IAM screen after Role assignments.":::

+

+If you're also using Private Link, one more configuration is required to allow connection to our Trusted Microsoft Service from your virtual network. For more information, see [Storage network security documentation](../../storage/common/storage-network-security.md#trusted-microsoft-services).

+### Link your storage account with your Application Insights resource

+To configure BYOS for code-level diagnostics (Profiler/Snapshot Debugger), there are three options:

+* Use Azure PowerShell cmdlets.

+* Use the Azure CLI.

+* Use Azure Resource Manager templates.

+1. Make sure you've installed Az PowerShell 4.2.0 or greater.

+ To install Azure PowerShell, see the [Azure PowerShell documentation](/powershell/azure/install-az-ps).

+ For more information on how to sign in, see the [Connect-AzAccount documentation](/powershell/module/az.accounts/connect-azaccount).

+1. Remove any previous storage account linked to your Application Insights resource.

+1. Connect your storage account with your Application Insights resource.

+1. Make sure you've installed the Azure CLI.

+ To install the Azure CLI, see the [Azure CLI documentation](/cli/azure/install-azure-cli).

+1. Connect your storage account with your Application Insights resource.

+ > For performing updates on the linked storage accounts to your Application Insights resource, see the [Application Insights CLI documentation](/cli/azure/monitor/app-insights/component/linked-storage).

+#### [Resource Manager template](#tab/azure-resource-manager)

+1. Run the following PowerShell command to deploy the preceding template:

+1. Provide the following parameters when you're prompted in the PowerShell console:

+ | `storage_account_name` | The name of the storage account resource that you'll use as your BYOS. |

+1. Enable code-level diagnostics (Profiler/Snapshot Debugger) on the workload of interest through the Azure portal. In this example, it's **App Service** > **Application Insights**.

+ :::image type="content" source="media/profiler-bring-your-own-storage/figure-20.png" alt-text="Screenshot that shows the code-level diagnostics in the Azure portal.":::

+## Troubleshooting

+This section offers troubleshooting tips for common issues.

+* Make sure that the `$schema` property of the template is valid. It must follow this pattern:

+`https://schema.management.azure.com/schemas/{schema_version}/deploymentTemplate.json#`.

+

+

+### Storage account location should match AI component location

+* Make sure that the location of the Application Insights resource is the same as the storage account.

+

+For general Profiler troubleshooting, see the [Profiler troubleshooting documentation](profiler-troubleshooting.md).

+For general Snapshot Debugger troubleshooting, see the [Snapshot Debugger troubleshooting documentation](/troubleshoot/azure/azure-monitor/app-insights/snapshot-debugger-troubleshoot).

+This section provides answers to common questions.

+### If I've enabled Profiler/Snapshot Debugger and BYOS, will my data be migrated into my storage account?

+ No, it won't.

+### Will BYOS work with encryption-at-rest and customer-managed keys?

+ Yes. To be precise, BYOS is a requirement to have Profiler/Snapshot Debugger enabled with customer-manager keys.

+### Will BYOS work in an environment isolated from the internet?

+ Yes. BYOS is a requirement for isolated network scenarios.

+### Will BYOS work with both customer-managed keys and Private Link enabled?

+ Yes, it's possible.

+### If I've enabled BYOS, can I go back to using Diagnostic Services storage accounts to store my collected data?

+ Yes, you can, but we don't currently support data migration from your BYOS.

+### After I enable BYOS, will I take over all the related costs of storage and networking?

+ Yes.

+Receive performance traces for your instance of [Azure Cloud Services](../../cloud-services-extended-support/overview.md) by enabling the Application Insights Profiler. Profiler is installed on your instance of Azure Cloud Services via the [Azure Diagnostics extension](../agents/diagnostics-extension-overview.md).

+In this article, you:

+- Enable your instance of Azure Cloud Services to send diagnostics data to Application Insights.

+- Deploy your service and generate traffic to view Profiler traces.

+## Prerequisites

+- Make sure you've [set up diagnostics for your instance of Azure Cloud Services](/visualstudio/azure/vs-azure-tools-diagnostics-for-cloud-services-and-virtual-machines).

+- Use [.NET Framework 4.6.1](/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed) or newer.

+ - If you're using [OS Family 4](../../cloud-services/cloud-services-guestos-update-matrix.md#family-4-releases), install .NET Framework 4.6.1 or newer with a [startup task](../../cloud-services/cloud-services-dotnet-install-dotnet.md).

+ - [OS Family 5](../../cloud-services/cloud-services-guestos-update-matrix.md#family-5-releases) includes a compatible version of .NET Framework by default.

+When you publish your instance of Azure Cloud Services to the Azure portal, add the [Application Insights SDK to Azure Cloud Services](../app/azure-web-apps-net-core.md).

+After you've added the SDK and published your instance of Azure Cloud Services to the Azure portal, track requests by using Application Insights:

+- **For ASP.NET web roles**: Application Insights tracks the requests automatically.

+- **For worker roles**: You need to [add code manually to your application to track requests](profiler-trackrequests.md).

+Locate the Azure Diagnostics *diagnostics.wadcfgx* file for your application role.

+Add the following `SinksConfig` section as a child element of `WadCfg`:

+> The instrumentation keys that are used by the application and the `ApplicationInsightsProfiler` sink must match each other.

+Deploy your service with the new Diagnostics configuration. Application Insights Profiler is now configured to run on your instance of Azure Cloud Services.

+ Title: Profile Azure containers with Application Insights Profiler

+description: Enable Application Insights Profiler for Azure containers.

+You can enable the Application Insights Profiler for ASP.NET Core application running in your container almost without code. To enable the Application Insights Profiler on your container instance, you need to:

+In this article, you learn about the various ways that you can:

+- Install the NuGet package in the project.

+- Set the environment variable via the orchestrator (like Kubernetes).

+- Learn security considerations around production deployment, like protecting your Application Insights instrumentation key.

+## Prerequisites

+- [Docker Desktop](https://www.docker.com/products/docker-desktop/) to build Docker images.

+1. Go to the Container App example:

+1. This example is a barebones project created by calling the following CLI command:

+1. Enable Application Insights and Profiler.

+1. Go to the .NET Core 6.0 example directory:

+1. Pull the latest ASP.NET Core images:

+> Find the official images for the Docker [SDK](https://hub.docker.com/_/microsoft-dotnet-sdk) and [runtime](https://hub.docker.com/_/microsoft-dotnet-aspnet).

+ :::image type="content" source="./media/profiler-containerinstances/application-insights-key.png" alt-text="Screenshot that shows finding the instrumentation key in the Azure portal.":::

+1. Review the Docker file.

+To hit the endpoint, you have two options:

+- Visit `http://localhost:8080/weatherforecast` in your browser.

+1. Wait for 2 to 5 minutes so that the events can be aggregated to Application Insights.

+1. Open the **Performance** pane in your Application Insights resource.

+1. After the trace process is finished, the **Profiler Traces** button appears.

+ :::image type="content" source="./media/profiler-containerinstances/profiler-traces.png" alt-text="Screenshot that shows the Profiler traces button in the Performance pane.":::

+## Next steps

+description: Profile live Azure Service Fabric apps with Application Insights.

+Application Insights Profiler is included with Azure Diagnostics. You can install the Azure Diagnostics extension by using an Azure Resource Manager template (ARM template) for your Azure Service Fabric cluster. Get a [template that installs Azure Diagnostics on a Service Fabric cluster](https://github.com/Azure/azure-docs-json-samples/blob/master/application-insights/ServiceFabricCluster.json).

+In this article, you:

+- Add the Application Insights Profiler property to your ARM template.

+## Create a deployment template

+1. In your Service Fabric managed cluster, go to where you implemented the [ARM template](https://github.com/Azure/azure-docs-json-samples/blob/master/application-insights/ServiceFabricCluster.json).

+1. Add the following `SinksConfig` section as a child element of `WadCfg`. Replace the `ApplicationInsightsProfiler` property value with your own Application Insights instrumentation key:

+

+ ```json

+ "settings": {

+ "WadCfg": {

+ "SinksConfig": {

+ "Sink": [

+ {

+ "name": "MyApplicationInsightsProfilerSinkVMSS",

+ "ApplicationInsightsProfiler": "YOUR_APPLICATION_INSIGHTS_INSTRUMENTATION_KEY"

+ }

+ ]

+ },

+ }

+ ```

+ For information about how to add the Diagnostics extension to your deployment template, see [Use monitoring and diagnostics with a Windows VM and Azure Resource Manager templates](../../virtual-machines/extensions/diagnostics-template.md).

+After you update `WadCfg` with your instrumentation key, deploy your Service Fabric cluster.

+Application Insights Profiler is installed and enabled when the Azure Diagnostics extension is installed.

+For Profiler to collect profiles for your requests, your application must be tracking operations with Application Insights.

+- **For stateless APIs**: See the instructions for [tracking requests for profiling](./profiler-trackrequests.md).

+- **For tracking custom operations in other kinds of apps**: See [Track custom operations with Application Insights .NET SDK](../app/custom-operations-tracking.md).

+After you enable Application Insights, redeploy your application.

+1. Launch an [availability test](/previous-versions/azure/azure-monitor/app/monitor-web-app-availability) to generate traffic to your application.

+1. View the [Profiler traces](./profiler-overview.md) via the Application Insights instance in the Azure portal.

+ Title: Troubleshoot Application Insights Profiler

+description: Walk through troubleshooting steps and information to enable and use Application Insights Profiler.

+# Troubleshoot Application Insights Profiler

+This article presents troubleshooting steps and information to enable you to use Application Insights Profiler.

+## Are you using the appropriate Profiler endpoint?

+|App setting | US Government Cloud | China Cloud |

+## Is your app running on the right version?

+## Are you using the right Azure service plan?

+## Are you searching for Profiler data within the right time frame?

+If the data you're trying to view is older than two weeks, try limiting your time filter and try again. Traces are deleted after seven days.

+## Can you access the gateway?

+Check that a firewall or proxies aren't blocking your access to [this webpage](https://gateway.azureserviceprofiler.net).

+## Is Profiler running?

+Profiling data is uploaded only when it can be attached to a request that happened while Profiler was running. Profiler collects data for two minutes each hour. You can also trigger Profiler by [starting a profiling session](./profiler-settings.md#profile-now).

+Search for trace messages and custom events sent by Profiler to your Application Insights resource.

+1. In your Application Insights resource, select **Search**.

+ :::image type="content" source="./media/profiler-troubleshooting/search-trace-messages.png" alt-text="Screenshot that shows selecting the Search button from the Application Insights resource.":::

+ :::image type="content" source="./media/profiler-troubleshooting/search-results.png" alt-text="Screenshot that shows the search results from aforementioned search string.":::

+ The preceding search results include two examples of searches from two AI resources:

+ - If the application isn't receiving requests while Profiler is running, the message explains that the upload was canceled because of no activity.

+ If no records are displayed, Profiler isn't running. Make sure you've [enabled Profiler on your Azure service](./profiler.md).

+When two or more parallel threads are associated with a request, the total time metric in the stack viewer might be more than the duration of the request. In that case, the total thread time is more than the actual elapsed time.

+For example, one thread might be waiting on the other to be completed. The viewer tries to detect this situation and omits the uninteresting wait. In doing so, it errs on the side of displaying too much information rather than omitting what might be critical information.

+When you see parallel threads in your traces, determine which threads are waiting so that you can identify the hot path for the request. Usually, the thread that quickly goes into a wait state is waiting on the other threads. Concentrate on the other threads and ignore the time in the waiting threads.

+The following sections walk you through troubleshooting steps for using Profiler on Azure App Service or Azure Cloud Services.

+- Your web app has [Application Insights enabled](./profiler.md) with the [right settings](./profiler.md#for-application-insights-and-app-service-in-different-subscriptions).

+ 1. Go to [Kudu](https://github.com/projectkudu/kudu/wiki/Accessing-the-kudu-service). In the Azure portal:

+ 1. In your App Service instance, select **Advanced Tools** on the left pane.

+ 1. On the top menu, select **Tools** > **WebJobs dashboard**.

+ The **WebJobs** pane opens.

+ :::image type="content" source="./media/profiler-troubleshooting/profiler-web-job.png" alt-text="Screenshot that shows the WebJobs pane, which displays the name, status, and last runtime of jobs.":::

+ 1. To view the details of the WebJob, including the log, select the **ApplicationInsightsProfiler3** link.

+ :::image type="content" source="./media/profiler-troubleshooting/profiler-web-job-log.png" alt-text="Screenshot that shows the Continuous WebJob Details pane.":::

+If Profiler still isn't working for you, download the log and [submit an Azure support ticket](https://azure.microsoft.com/support/).

+#### Check the Diagnostic Services site extension status page

+If Profiler was enabled through the [Application Insights pane](profiler.md) in the portal, it was enabled by the Diagnostic Services site extension. You can check the status page of this extension by going to

+`https://{site-name}.scm.azurewebsites.net/DiagnosticServices`.

+> The domain of the status page link varies depending on the cloud. This domain is the same as the Kudu management site for App Service.

+The status page shows the installation state of the Profiler and [Snapshot Debugger](../snapshot-debugger/snapshot-debugger.md) agents. If there was an unexpected error, it appears along with steps on how to fix it.

+You can use the Kudu management site for App Service to get the base URL of this status page:

+1. Select **Advanced Tools**.

+1. Select **Go**.

+1. On the Kudu management site:

+ 1. Select Enter.

+It ends like `https://<kudu-url>/DiagnosticServices`.

+A status page appears similar to the following example.

+

+> Codeless installation of Application Insights Profiler follows the .NET Core support policy. For more information about supported runtimes, see [.NET Core support policy](https://dotnet.microsoft.com/platform/support/policy/dotnet-core).

+When you configure Profiler, updates are made to the web app's settings. If necessary, you can [apply the updates manually](./profiler.md#verify-the-always-on-setting-is-enabled).

+You can enable Profiler on a maximum of four web apps that are running in the same service plan. If you have more than four, Profiler might throw the following error:

+`Microsoft.ServiceProfiler.Exceptions.TooManyETWSessionException`

+"Directory Not Empty 'D:\\home\\site\\wwwroot\\App_Data\\jobs'"

+This error occurs if you run Web Deploy from scripts or from Azure Pipelines. Resolve it by adding the following deployment parameters to the Web Deploy task:

+#### Is Application Insights Profiler running?

+Profiler runs as a continuous WebJob in the web app. You can open the web app resource in the [Azure portal](https://portal.azure.com). In the **WebJobs** pane, check the status of **ApplicationInsightsProfiler**. If it isn't running, open **Logs** to get more information.

+### VMs and Azure Cloud Services

+1. Verify that the content of the Azure Diagnostics configuration deployed is what you expect.

+1. Make sure Azure Diagnostics passes the proper iKey on the Profiler command line.

+1. Check the Profiler log file to see whether Profiler ran but returned an error.

+1. Open the log file at this location. The plug-in version might be newer on your machine.

+ For Azure Cloud

+1. Check the command line that's used to start Profiler. The arguments that are used to launch Profiler are in the following file (the drive could be `c:` or `d:` and the directory might be hidden):

+ For Azure Cloud

+1. Make sure that the iKey on the Profiler command line is correct.

+1. By using the path found in the preceding *config.json* file, check the Profiler log file, called `BootstrapN.log`. It displays:

+ - The debug information that indicates the settings that Profiler is using.

+ - Status and error messages from Profiler.

+ For Azure Cloud

+1. If Profiler is running while your application is receiving requests, the following message appears: "Activity detected from iKey."

+1. When the trace is being uploaded, the following message appears: "Start to upload trace."

+If your application connects to the internet via a proxy or a firewall, you might need to update the rules to communicate with Profiler.

+The IPs used by Application Insights Profiler are included in the Azure Monitor service tag. For more information, see [Service tags documentation](../../virtual-network/service-tags-overview.md).

+## Support

+If you still need help, submit a support ticket in the Azure portal. Include the correlation ID from the error message.

+ "level": "warning",

+ "maxAllowedAgeInDays": 730

+> [!WARNING]

+> To utilize the experimental features, it's necessary to have the latest version of [Azure CLI](./install.md#azure-cli).

+The rule includes a configuration property named `maxAllowedAgeInDays`, with a default value of **730** days (equivalent to 2 years). A value of **0** indicates that the apiVersion must be the latest non-preview version available or the latest preview version if only previews are available.

+ Decorators may be used on properties. `*` may be used to make all values require a constrant. Additional properties may still be defined when using `*`. This example creates an object that requires a key of type int named `id`, and that all other entries in the object must be a string value at least 10 characters long.

+ ```bicep

+ type obj = {

+ @description('The object ID')

+ id: int

+ @description('Additional properties')

+ @minLength(10)

+ *: string

+ }

+ ```

+ "name": "$return"

+ ```python

+ ```

+- **Basic**: Indexes and extract insights by using audio only (ignoring video) and provides the following insights: transcription, translation, formatting of output captions and subtitles (closed captions).

+- **Standard**: Indexes and extract insights by using audio only (ignoring video) and provides the following insights: transcription, translation, formatting of output captions and subtitles (closed captions), automatic language detection, emotions, keywords, named entities (brands, locations, people), sentiments, speakers, topic extraction, and textual content moderation.

+- **Advanced**: Indexes and extract insights by using audio only (ignoring video) and provides the following insights: transcription, translation, formatting of output captions and subtitles (closed captions), automatic language detection, audio event detection, emotions, keywords, named entities (brands, locations, people), sentiments, speakers, topic extraction, and textual content moderation.

+- **Standard**: Indexes and extract insights by using video only (ignoring audio) and provides the following insights: labels (OCR), named entities (OCR - brands, locations, people), OCR, people, scenes (keyframes and shots), black frames, visual content moderation, and topic extraction (OCR).

+- **Advanced**: Indexes and extract insights by using video only (ignoring audio) and provides the following insights: labels (OCR), matched person (preview), named entities (OCR - brands, locations, people), OCR, observed people (preview), people, scenes (keyframes and shots), clapperboard detection, digital pattern detection, featured clothing insight, textless slate detection, textual logo detection, black frames, visual content moderation, and topic extraction (OCR).

+- **Standard**: Indexes and extract insights by using audio and video and provides the following insights: transcription, translation, formatting of output captions and subtitles (closed captions), automatic language detection, emotions, keywords, named entities (brands, locations, people), OCR, scenes (keyframes and shots), black frames, visual content moderation, people, sentiments, speakers, topic extraction, and textual content moderation.

+- **Advanced**: Indexes and extract insights by using audio and video and provides the following insights: transcription, translation, formatting of output captions and subtitles (closed captions), automatic language detection, textual content moderation, audio event detection, emotions, keywords, matched person, named entities (brands, locations, people), OCR, observed people (preview), people, clapperboard detection, digital pattern detection, featured clothing insight, textless slate detection, sentiments, speakers, scenes (keyframes and shots), textual logo detection, black frames, visual content moderation, and topic extraction.

+- [Indexing and configuration guide](indexing-configuration-guide.md)

+|Features |Basic network features |

+|Connectivity from UVMs on NC2 nodes to Azure resources|Yes|

+|Connectivity to [private endpoints](../../../private-link/private-endpoint-overview.md) from resources on Azure-delegated subnets|No|

+* West Europe

+| [H16r, H16mr, A8, A9](../virtual-machines/sizes-hpc.md)<br/>[NC24r, NC24rs_v2, NC24rs_v3, ND24rs^*](../virtual-machines/linux/n-series-driver-setup.md#rdma-network-connectivity) | RDMA | Ubuntu 22.04 LTS, or<br/>CentOS-based HPC<br/>(Azure Marketplace) | Intel MPI 5<br/><br/>Linux RDMA drivers | Enable inter-node communication, disable concurrent task execution |

+| [NC, NCv2, NCv3, NDv2 series](../virtual-machines/linux/n-series-driver-setup.md) | NVIDIA Tesla GPU (varies by series) | Ubuntu 22.04 LTS, or<br/>CentOS 7.3 or 7.4<br/>(Azure Marketplace) | NVIDIA CUDA or CUDA Toolkit drivers | N/A |

+| [NV, NVv2 series](../virtual-machines/linux/n-series-driver-setup.md) | NVIDIA Tesla M60 GPU | Ubuntu 22.04 LTS, or<br/>CentOS 7.3<br/>(Azure Marketplace) | NVIDIA GRID drivers | N/A |

+> [!Important]

+> This document references a release version of Linux that is nearing or at, End of Life(EOL). Please consider updating to a more current version.

+1. Deploy an Azure NC-series VM running Ubuntu 22.04 LTS. For example, create the VM in the US South Central region.

+| **Node agent SKU** | batch.node.ubuntu 22.04 |

+| Rel 23-04 | [5025228] | Latest Cumulative Update(LCU) | [5.80] | Apr 11, 2023 |

+| Rel 23-04 | [5022835] | IE Cumulative Updates | [2.136], [3.124], [4.116] | Feb 14, 2023 |

+| Rel 23-04 | [5025230] | Latest Cumulative Update(LCU) | [7.24] | Apr 11, 2023 |

+| Rel 23-04 | [5025229] | Latest Cumulative Update(LCU) | [6.56] | Apr 11, 2023 |

+| Rel 23-04 | [5022523] | .NET Framework 3.5 Security and Quality Rollup LKG  | [2.136] | Feb 14, 2023 |

+| Rel 23-04 | [5022515] | .NET Framework 4.6.2 Security and Quality Rollup LKG  | [2.136] | Feb 14, 2023 |

+| Rel 23-04 | [5022525] | .NET Framework 3.5 Security and Quality Rollup LKG  | [4.116] | Feb 14, 2023 |

+| Rel 23-04 | [5022513] | .NET Framework 4.6.2 Security and Quality Rollup LKG  | [4.116] | Feb 14, 2023 |

+| Rel 23-04 | [5022574] | .NET Framework 3.5 Security       and Quality Rollup LKG  | [3.124] | Feb 14, 2023 |

+| Rel 23-04 | [5022512] | .NET Framework 4.6.2 Security and Quality Rollup LKG  | [3.124] | Feb 14, 2023 |

+| Rel 23-04 | [5022511] | . NET Framework 4.7.2 Cumulative Update LKG  | [6.56] | Feb 14, 2023 |

+| Rel 23-04 | [5022507] | .NET Framework 4.8 Security and Quality Rollup LKG  | [7.24] | Feb 14, 2023 |

+| Rel 23-04 | [5025279] | Monthly Rollup  | [2.136] | Apr 11, 2023 |

+| Rel 23-04 | [5025287] | Monthly Rollup  | [3.124] | Apr 11, 2023 |

+| Rel 23-04 | [5025285] | Monthly Rollup  | [4.116] | Apr 11, 2023 |

+| Rel 23-04 | [5023791] | Servicing Stack Update LKG  | [3.124] | Mar 14, 2023 |

+| Rel 23-04 | [5023790] | Servicing Stack Update LKG  | [4.116] | Mar 14, 2022 |

+| Rel 23-04 | [4578013] | OOB Standalone Security Update  | [4.116] | Aug 19, 2020 |

+| Rel 23-04 | [5023788] | Servicing Stack Update LKG  | [5.80] | Mar 14, 2023 |

+| Rel 23-04 | [5017397] | Servicing Stack Update LKG  | [2.136] | Sep 13, 2022 |

+| Rel 23-04 | [4494175] | Microcode  | [5.80] | Sep 1, 2020 |

+| Rel 23-04 | [4494174] | Microcode  | [6.56] | Sep 1, 2020 |

+| Rel 23-04 | 5025314 | Servicing Stack Update  | [7.24] | |

+[2.136]: ./cloud-services-guestos-update-matrix.md#family-2-releases

+[3.124]: ./cloud-services-guestos-update-matrix.md#family-3-releases

+[4.116]: ./cloud-services-guestos-update-matrix.md#family-4-releases

+[5.80]: ./cloud-services-guestos-update-matrix.md#family-5-releases

+[6.56]: ./cloud-services-guestos-update-matrix.md#family-6-releases

+[7.24]: ./cloud-services-guestos-update-matrix.md#family-7-releases

+###### **April 27, 2023**

+The April Guest OS has released.

+| WA-GUEST-OS-7.24_202304-01 | April 27, 2023 | Post 7.26 |

+|~~WA-GUEST-OS-7.22_202302-01~~| March 1, 2023 | April 27, 2023 |

+| WA-GUEST-OS-6.56_202304-01 | April 27, 2023 | Post 6.58 |

+|~~WA-GUEST-OS-6.54_202302-01~~| March 1, 2023 | April 27, 2023 |

+| WA-GUEST-OS-5.80_202304-01 | April 27, 2023 | Post 5.82 |

+|~~WA-GUEST-OS-5.78_202302-01~~| March 1, 2023 | April 27, 2023 |

+| WA-GUEST-OS-4.116_202304-01 | April 27, 2023 | Post 4.118 |

+|~~WA-GUEST-OS-4.114_202302-01~~| March 1, 2023 | April 27, 2023 |

+| WA-GUEST-OS-3.124_202304-02 | April 27, 2023 | Post 3.126 |

+| WA-GUEST-OS-3.122_202303-01 | March 28, 2023 | Post 3.125 |

+|~~WA-GUEST-OS-3.121_202302-01~~| March 1, 2023 | April 27, 2023 |

+| WA-GUEST-OS-2.136_202304-01 | April 27, 2023 | Post 2.138 |

+|~~WA-GUEST-OS-2.134_202302-01~~| March 1, 2023 | April 27, 2023 |

+ ```output

+# Language identification

+> Language Identification APIs are simplified with the Speech SDK version 1.25 and later. The

+To learn how to secure the callback event delivery, refer to [this guide](../../how-tos/call-automation/secure-webhook-endpoint.md).

+ Title: Azure Communication Services Call Automation how-to for securing webhook endpoint

+description: Provides a how-to guide on securing deliver the delivery of incoming call and callback event

+# How to secure webhook endpoint

+Securing the delivery of messages from end to end is crucial for ensuring the confidentiality, integrity, and trustworthiness of sensitive information transmitted between systems. Your ability and willingness to trust information received from a remote system relies on the sender providing their identity. Call Automation has two ways of communicating events that can be secured; the shared IncomingCall event sent by Azure Event Grid, and all other mid-call events sent by the Call Automation platform via webhook.

+## Incoming Call Event

+Azure Communication Services relies on Azure Event Grid subscriptions to deliver the [IncomingCall event](../../concepts/call-automation/incoming-call-notification.md). You can refer to the Azure Event Grid team for their [documentation about how to secure a webhook subscription](../../../event-grid/secure-webhook-delivery.md).

+## Call Automation webhook events

+[Call Automation events](../../concepts/call-automation/call-automation.md#call-automation-webhook-events) are sent to the webhook callback URI specified when you answer a call, or place a new outbound call. Your callback URI must be a public endpoint with a valid HTTPS certificate, DNS name, and IP address with the correct firewall ports open to enable Call Automation to reach it. This anonymous public webserver could create a security risk if you don't take the necessary steps to secure it from unauthorized access.

+A common way you can improve this security is by implementing an API KEY mechanism. Your webserver can generate the key at runtime and provide it in the callback URI as a query parameter when you answer or create a call. Your webserver can verify the key in the webhook callback from Call Automation before allowing access. Some customers require more security measures. In these cases, a perimeter network device may verify the inbound webhook, separate from the webserver or application itself. The API key mechanism alone may not be sufficient.

+## Improving Call Automation webhook callback security

+Each mid-call webhook callback sent by Call Automation uses a signed JSON Web Token (JWT) in the Authentication header of the inbound HTTPS request. You can use standard Open ID Connect (OIDC) JWT validation techniques to ensure the integrity of the token as follows. The lifetime of the JWT is five (5) minutes and a new token is created for every event sent to the callback URI.

+1. Obtain the Open ID configuration URL: https://acscallautomation.communication.azure.com/calling/.well-known/acsopenidconfiguration

+2. Install the [Microsoft.AspNetCore.Authentication.JwtBearer NuGet](https://www.nuget.org/packages/Microsoft.AspNetCore.Authentication.JwtBearer) package.

+3. Configure your application to validate the JWT using the NuGet package and the configuration of your ACS resource. You need the `audience` values as it is present in the JWT payload.

+4. Validate the issuer, audience and the JWT token.

+ - The audience is your ACS resource ID you used to setup your Call Automation client. Refer [here](../../quickstarts/voice-video-calling/get-resource-id.md) about how to get it.

+ - The JSON Web Key Set (JWKS) endpoint in the OpenId configuration contains the keys used to validate the JWT token. When the signature is valid and the token hasn't expired (within 5 minutes of generation), the client can use the token for authorization.

+This sample code demonstrates how to use `Microsoft.IdentityModel.Protocols.OpenIdConnect` to validate webhook payload

+## [csharp](#tab/csharp)

+```csharp

+using Microsoft.AspNetCore.Authentication.JwtBearer;

+using Microsoft.IdentityModel.Protocols;

+using Microsoft.IdentityModel.Protocols.OpenIdConnect;

+using Microsoft.IdentityModel.Tokens;

+var builder = WebApplication.CreateBuilder(args);

+builder.Services.AddEndpointsApiExplorer();

+builder.Services.AddSwaggerGen();

+// Add ACS CallAutomation OpenID configuration

+var configurationManager = new ConfigurationManager<OpenIdConnectConfiguration>(

+ builder.Configuration["OpenIdConfigUrl"],

+ new OpenIdConnectConfigurationRetriever());

+var configuration = configurationManager.GetConfigurationAsync().Result;

+builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)

+ .AddJwtBearer(options =>

+ {

+ options.Configuration = configuration;

+ options.TokenValidationParameters = new TokenValidationParameters

+ {

+ ValidAudience = builder.Configuration["AllowedAudience"]

+ };

+ });

+builder.Services.AddAuthorization();

+var app = builder.Build();

+// Configure the HTTP request pipeline.

+if (app.Environment.IsDevelopment())

+{

+ app.UseSwagger();

+ app.UseSwaggerUI();

+}

+app.UseHttpsRedirection();

+app.MapPost("/api/callback", (CloudEvent[] events) =>

+{

+ // Your implemenation on the callback event

+ return Results.Ok();

+})

+.RequireAuthorization()

+.WithOpenApi();

+app.UseAuthentication();

+app.UseAuthorization();

+app.Run();

+```

+## Next steps

+- Learn more about [How to control and steer calls with Call Automation](../call-automation/actions-for-call-control.md).

+zone_pivot_groups: acs-plat-web-android-windows

+

+

+Many countries have strict privacy laws about gathering and using data on peopleΓÇÖs presence and movements inside buildings. This may include data that is directly personally identifiable data from CCTV or security badge scans. Or, indirectly identifiable where different sets of sensor data could be considered personally identifiable when grouped together.

+[](media/use-cases-scenarios/iot-sensors.jpg#lightbox)

+## Legal or jurisdictional requirements

+Commonly applicable to FSI and healthcare where there are legal or regulatory requirements that limit where certain workloads can be processed and be stored at-rest.

+In this use-case we use a combination of Azure Confidential Compute technologies with Azure Policy, Network Security Groups (NSGs) and Azure Active Directory Conditional Access to ensure that the following protection goals are met for the ΓÇÿlift & shiftΓÇÖ of an existing application:

+- Application is protected from the cloud operator whilst in-use using Confidential Compute

+- Application resources can only be deployed in the West Europe Azure region

+- Consumers of the application authenticating with modern authentication protocols can be mapped to the sovereign region they're connecting from, and denied access unless they are in an allowed region.

+- Access using administrative protocols (RDP, SSH etc.) is limited to access from the Azure Bastion service that is integrated with Privileged Identity Management (PIM). The PIM policy requires a Conditional Access Policy that validates which sovereign region the administrator is accessing from.

+- All services log actions to Azure Monitor.

+[](media/use-cases-scenarios/restricted-workload.jpg#lightbox)

+## Manufacturing ΓÇô IP Protection

+Manufacturing organizations protect the IP around their manufacturing processes and technologies, often manufacturing is outsourced to third parties who deal with the physical production processes, which could be considered ΓÇÿhostileΓÇÖ environments where there are active threats to steal that IP.

+In this example Tailspin Toys are developing a new toy-line, the specific dimensions and innovative designs of their toys are company proprietary and they want to keep them safe, whilst being flexible over which company they choose to physically produce their prototypes.

+Contoso, a high-quality 3D printing and testing company provide the systems that physically print prototypes at large-scale and run them through safety tests required for safety approvals.

+Contoso deploy customer managed containerized applications and data within the Contoso tenant, which uses their 3D printing machinery via an IoT-type API.

+Contoso use the telemetry from the physical manufacturing systems to drive their billing, scheduling and materials ordering systems whilst Tailspin Toys use telemetry from their application suite to determine how successfully their toys can be manufactured and defect rates.

+Contoso operators are able to load the Tailspin Toys application suite into the Contoso tenant using the provided container images over the Internet.

+Tailspin Toys configuration policy mandates deployment on Confidential Compute enabled hardware so that all Tailspin application servers and databases are protected whilst in-use from Contoso administrators even though they are running in the Contoso tenant.

+If, for example a rogue admin at Contoso tries moving the Tailspin Toys provided containers to general x86 compute hardware that isn't able to provide a Trusted Execution Environment, it could mean potential exposure of confidential IP.

+In this case, the Azure Container Instance policy engine would refuse to release the decryption keys or start containers if the attestation call reveals that the policy requirements aren't able to be met, ensuring Tailspin Toys IP is protected in-use and at-rest.

+The Tailspin Toys application itself is coded to periodically make a call to the attestation service and report the results back to Tailspin Toys over the Internet to ensure there's a continual heartbeat of security status.

+The attestation service returns cryptographically signed details from the hardware supporting the Contoso tenant to validate that the workload is running inside a confidential enclave as expected, the attestation is outside the control of the Contoso administrators and is based on the hardware root of trust that Confidential Compute provides.

+[](media/use-cases-scenarios/manufacturing-ip-protection.jpg#lightbox)

+In Government and public agencies, Azure confidential computing is a solution to raise the degree of trust towards the ability to protect data sovereignty in the public cloud. Moreover, thanks to the increasing adoption of confidential computing capabilities into PaaS services in Azure, a higher degree of trust can be achieved with a reduced impact to the innovation ability provided by public cloud services. This combination of protecting data sovereignty with a reduced impact to the innovation ability makes Azure confidential computing a very effective response to the needs of sovereignty and digital transformation of Government services.

+In addition to the previous step, it's also required to verify that the signing node certificate is endorsed (that is, signed) by the current ledger certificate. This step doesn't depend on the other three previous steps and can be carried out independently from the others.

+### Verify application claims digest

+As an optional step, in case application claims are attached to a receipt, it's possible to compute the claims digest from the exposed claims (following a specific algorithm) and verify that the digest matches the `claimsDigest` contained in the receipt payload. To compute the digest from the exposed claim objects, it's required to iterate through each application claim object in the list and checks its `kind` field.

+If the claim object is of kind `LedgerEntry`, the ledger collection ID (`collectionId`) and contents (`contents`) of the claim should be extracted and used to compute their HMAC digests using the secret key (`secretKey`) specified in the claim object. These two digests are then concatenated and the SHA-256 hash of the concatenation is computed. The protocol (`protocol`) and the resulting claim data digest are then concatenated and another SHA-256 hash of the concatenation is computed to get the final digest.

+If the claim object is of kind `ClaimDigest`, the claim digest (`value`) should be extracted, concatenated with the protocol (`protocol`), and the SHA-256 hash of the concatenation is computed to get the final digest.

+After computing each single claim digest, it's necessary to concatenate all the computed digests from each application claim object (in the same order they're presented in the receipt). The concatenation should then be prepended with the number of claims processed. The SHA-256 hash of the previous concatenation produces the final claims digest, which should match the `claimsDigest` present in the receipt object.

+* [Application Claims](https://microsoft.github.io/CCF/main/use_apps/verify_tx.html#application-claims)

+* [User-Defined Claims in Receipts](https://microsoft.github.io/CCF/main/build_apps/example_cpp.html#user-defined-claims-in-receipts)

+### Receipt verification utilities

+The [Azure Confidential Ledger client library for Python](https://github.com/Azure/azure-sdk-for-python/tree/main/sdk/confidentialledger/azure-confidentialledger) provides utility functions to verify write transaction receipts and compute the claims digest from a list of application claims. For more information on how to use the Data Plane SDK and the receipt-specific utilities, see [this section](https://github.com/Azure/azure-sdk-for-python/tree/main/sdk/confidentialledger/azure-confidentialledger#verify-write-transaction-receipts) and [this sample code](https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/confidentialledger/azure-confidentialledger/samples/get_and_verify_receipt.py).

+### Setup and prerequisites

+For reference purposes, we provide sample code in Python to fully verify Azure Confidential Ledger write transaction receipts following the steps outlined in the previous section.

+The following code can be used to initialize the required objects and run the receipt verification algorithm. A separate utility (`verify_receipt`) is used to run the full verification algorithm, and accepts the content of the `receipt` field in a `GET_RECEIPT` response as a dictionary and the service certificate as a simple string. The function throws an exception if the receipt isn't valid or if any error was encountered during the processing.

+As detailed previously, we compute the digest of `commitEvidence` (using the SHA-256 `hashlib` function). Then, we convert both `writeSetDigest` and `claimsDigest` into arrays of bytes. Finally, we concatenate the three arrays, and we digest the result using the SHA256 function.

+Likewise, we can use the CCF utility `check_endorsements` to validate that the service identity endorses the signing node. The certificate chain could be composed of previous service certificates, so we should validate that the endorsement is applied transitively if `serviceEndorsements` isn't an empty list.

+The full sample code used in the code walkthrough is provided.

+### Setup and prerequisites

+The full sample code used in the code walkthrough is provided.

+ * `Loading`: The receipt isn't yet available to be retrieved and the request have to be retried

+* **cert**: String with the [PEM](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) public key certificate of the CCF node that signed the write transaction. The service identity certificate should always endorse the certificate of the signing node. See also more details about how transactions get regularly signed and how the signature transactions are appended to the ledger in CCF at the following [link](https://microsoft.github.io/CCF/main/architecture/merkle_tree.html).

+## Application claims

+Azure Confidential Ledger applications can attach arbitrary data, called [application claims](https://microsoft.github.io/CCF/main/use_apps/verify_tx.html#application-claims), to write transactions. These claims represent the actions executed during a write operation. When attached to a transaction, the SHA-256 digest of the claims object is included in the ledger and committed as part of the write transaction. The inclusion of the claim in the write transaction guarantees that the claim digest is signed in place and can't be tampered with.

+Later, application claims can be revealed in their plain format in the receipt payload corresponding to the same transaction where they were added. The exposed claims allow users to recompute the same claims digest that was attached and signed in place by the ledger during the transaction. The claims digest can be used as part of the write transaction receipt verification process, providing an offline way for users to fully verify the authenticity of the recorded claims.

+Application claims are currently supported in the preview API version `2023-01-18-preview`.

+### Write transaction receipt content with application claims

+Here's an example of a JSON response payload returned by an Azure Confidential Ledger instance that recorded application claims, when calling the `GET_RECEIPT` endpoint.

+```json

+{

+ "applicationClaims": [

+ {

+ "kind": "LedgerEntry",

+ "ledgerEntry": {

+ "collectionId": "subledger:0",

+ "contents": "Hello world",

+ "protocol": "LedgerEntryV1",

+ "secretKey": "Jde/VvaIfyrjQ/B19P+UJCBwmcrgN7sERStoyHnYO0M="

+ }

+ }

+ ],

+ "receipt": {

+ "cert": "--BEGIN CERTIFICATE--\nMIIBxTCCAUygAwIBAgIRAMR89lUNeIghDUfpyHi3QzIwCgYIKoZIzj0EAwMwFjEU\nMBIGA1UEAwwLQ0NGIE5ldHdvcmswHhcNMjMwNDI1MTgxNDE5WhcNMjMwNzI0MTgx\nNDE4WjATMREwDwYDVQQDDAhDQ0YgTm9kZTB2MBAGByqGSM49AgEGBSuBBAAiA2IA\nBB1DiBUBr9/qapmvAIPm1o3o3LRViSOkfFVI4oPrw3SodLlousHrLz+HIe+BqHoj\n4nBjt0KAS2C0Av6Q+Xg5Po6GCu99GQSoSfajGqmjy3j3bwjsGJi5wHh1pNbPmMm/\nTqNhMF8wDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUCPaDohOGjVgQ2Lb8Pmubg7Y5\nDJAwHwYDVR0jBBgwFoAU25KejcEmXDNnKvSLUwW/CQZIVq4wDwYDVR0RBAgwBocE\nfwAAATAKBggqhkjOPQQDAwNnADBkAjA8Ci9myzieoLoIy+7mUswVEjUG3wrEXtxA\nDRmt2PK9bTDo2m3aJ4nCQJtCWQRUlN0CMCMOsXL4NnfsSxaG5CwAVkDwLBUPv7Zy\nLfSh2oZ3Wn4FTxL0UfnJeFOz/CkDUtJI1A==\n--END CERTIFICATE--\n",

+ "leafComponents": {

+ "claimsDigest": "d08d8764437d09b2d4d07d52293cddaf40f44a3ea2176a0528819a80002df9f6",

+ "commitEvidence": "ce:2.13:850a25da46643fa41392750b6ca03c7c7d117c27ae14e3322873de6322aa7cd3",

+ "writeSetDigest": "6637eddb8741ab54cc8a44725be67fd9be390e605f0537e5a278703860ace035"

+ },

+ "nodeId": "0db9a22e9301d1167a2a81596fa234642ad24bc742451a415b8d653af056795c",

+ "proof": [

+ {

+ "left": "bcce25aa51854bd15257cfb0c81edc568a5a5fa3b81e7106c125649db93ff599"

+ },

+ {

+ "left": "cc82daa27e76b7525a1f37ed7379bb80f6aab99f2b36e2e06c750dd9393cd51b"

+ },

+ {

+ "left": "c53a15cbcc97e30ce748c0f44516ac3440e3e9cc19db0852f3aa3a3d5554dfae"

+ }

+ ],

+ "signature": "MGYCMQClZXVAFn+vflIIikwMz64YZGoH71DKnfMr3LXkQ0lhljSsvDrmtmi/oWwOsqy28PsCMQCMe4n9aXXK4R+vY0SIfRWSCCfaADD6teclFCkVNK4317ep+5ENM/5T/vDJf3V4IvI="

+ },

+ "state": "Ready",

+ "transactionId": "2.13"

+}

+```

+Compared to the receipt example shown in the previous section, the JSON response contains another `applicationClaims` field that represents the list of application claims recorded by the ledger during the write transaction. Each object inside the `applicationClaims` list contains the following fields.

+* **kind**: It represents the kind of the application claim. The value indicates how to parse the application claim object for the provided type.

+* **ledgerEntry**: It represents an application claim derived from ledger entry data. The claim would contain the data recorded by the application during a write transaction (for example, the collection ID and the contents provided by the user) and the required information to compute the digest corresponding to the single claim object.

+* **digest**: It represents an application claim in digested form. This claim object would contain the precomputed digest by the application and the protocol used for the computation.

+The `ledgerEntry` field contains the following fields.

+* **protocol**: It represents the protocol to be used to compute the digest of a claim from the given claim data.

+* **collectionId**: The identifier of the collection written during the corresponding write transaction.

+* **contents**: The contents of the ledger written during the corresponding write transaction.

+* **secretKey**: A base64-encoded secret key. This key is to be used in the HMAC algorithm with the values provided in the application claim to obtain the claim digest.

+The `digest` field contains the following fields.

+* **protocol**: It represents the protocol used to compute the digest of the given claim.

+* **value**: The digest of the application claim, in hexadecimal form. This value would have to be hashed with the `protocol` value to compute the complete digest of the application claim.

+* [Application Claims](https://microsoft.github.io/CCF/main/use_apps/verify_tx.html#application-claims)

+* [User-Defined Claims in Receipts](https://microsoft.github.io/CCF/main/build_apps/example_cpp.html#user-defined-claims-in-receipts)

+> [!NOTE]

+> If you're using [UDR With Azure Firewall](./networking.md#user-defined-routes-udrpreview), you will need to add the `AzureKeyVault` service tag and the *login.microsoft.com* FQDN to the allow list for your firewall. To learn more, see [configuring UDR with Azure Firewall](./networking.md#configuring-udr-with-azure-firewallpreview).

+> [!NOTE]

+> When using UDR with Azure Firewall in Azure Container Apps, you will need to add certain FQDN's and service tags to the allowlist for the firewall. To learn more, see [configuring UDR with Azure Firewall](./networking.md#configuring-udr-with-azure-firewallpreview).

+You can use UDR on the workload profiles architecture to restrict outbound traffic from your container app through Azure Firewall or other network appliances. Configuring UDR is done outside of the Container Apps environment scope. UDR isn't supported for external environments.

+Azure creates a default route table for your virtual networks upon create. By implementing a user-defined route table, you can control how traffic is routed within your virtual network. For example, you can create a UDR that routes all traffic to the firewall.

+#### Configuring UDR with Azure Firewall - preview:

+UDR is only supported on the workload profiles architecture. For a guide on how to setup UDR with Container Apps to restrict outbound traffic with Azure Firewall, visit the [how to for Container Apps and Azure Firewall](./user-defined-routes.md).

+The following FQDNs and service tags must be added to the allowlist for your firewall depending on which resources you are using:

+- For all scenarios, you need to allow the `MicrosoftContainerRegistry` and its dependency `AzureFrontDoor.FirstParty` service tags through your Azure Firewall. Alternatively, you can add the following FQDNs: *mcr.microsoft.com* and **.data.mcr.microsoft.com*.

+> [!NOTE]

+> When using UDR with Azure Firewall in Azure Container Apps, you will need to add certain FQDN's and service tags to the allowlist for the firewall. For example, the FQDNs *mcr.microsoft.com* and **.data.mcr.microsoft.com* are required for all scenarios. To learn more, see [configuring UDR with Azure Firewall](./networking.md#configuring-udr-with-azure-firewallpreview).

+ - Azure Functions < 4.0.0

+- Azure Functions < 4.0.0

+You can centrally manage your Azure Hybrid Benefit for SQL Server across the scope of an entire Azure subscription or overall billing account. To quickly learn how it works, watch the following video.

+>[!VIDEO https://www.youtube.com/embed/ReoLB9N76Lo]

+ The variable $HklmSoftwarePath should be defined

+ $HklmSoftwarePath = 'HKLM:\SOFTWARE'

+[Connect to Azure Resource Manager](./azure-stack-edge-gpu-connect-resource-manager.md)

+ 1. Supply a unique number from 1-4096 as your **VLAN ID**. You must specify a valid VLAN that's configured on the network.

+ 1. Enter a **VLAN ID** as a unique number in 1-4094 range. You must specify a valid VLAN that's configured on the network.

+description: Learn how to add a catalog in your dev center to provide environment templates for your developers. Catalogs are repositories stored in GitHub or Azure DevOps.

+description: Learn how to configure administrative access for dev team leads by using the DevCenter Project Admin built-in role.

+# Provide access for dev team leads to Deployment Environments projects

+You can assign the DevCenter Project Admin role to a dev team lead at either the project level or the environment type level.

+## Assign permissions to dev team leads for a project

+## Assign permissions to dev team leads for an environment type

+description: Learn how to configure a dev center in Deployment Environments. You'll create a dev center, attach an identity, attach a catalog, and create environment types.

+ Title: 'Tutorial: Deploy environments in CI/CD with GitHub'

+description: Learn how to integrate Azure Deployment Environments into your CI/CD pipeline by using GitHub Actions.

+# Tutorial: Deploy environments in CI/CD with GitHub

+Continuous integration and continuous delivery (CI/CD) is a software development approach that helps teams to automate the process of building, testing, and deploying software changes. CI/CD enables you to release software changes more frequently and with greater confidence.

+In this tutorial, you'll Learn how to integrate Azure Deployment Environments into your CI/CD pipeline by using GitHub Actions. You use a workflow that features three branches: main, dev, and test.

+- The *main* branch is always considered production.

+- You create feature branches from the *main* branch.

+- You create pull requests to merge feature branches into *main*.

+This workflow is a small example for the purposes of this tutorial. Real world workflows may be more complex.

+In this tutorial, you learn how to:

+> [!div class="checklist"]

+> * Create and configure a dev center

+> * Create a key vault

+> * Create and configure a GitHub repository

+> * Connect the catalog to your dev center

+> * Configure deployment identities

+> * Configure GitHub environments

+> * Test the CI/CD pipeline

+## Prerequisites

+- An Azure account with an active subscription.

+ - [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

+- Owner permissions on the Azure subscription.

+- A GitHub account.

+ - If you don't have one, sign up for [free](https://github.com/join).

+- Install [Git](https://github.com/git-guides/install-git).

+- Install the [Azure CLI](/cli/azure/install-azure-cli).

+## 1. Create and configure a dev center

+In this section, you create a dev center and project with three environment types; Dev, Test and Prod

+- The Prod environment type contains the single production environment

+- A new environment is created in Dev for each feature branch

+- A new environment is created in Test for each pull request

+### 1.1 Setup the Azure CLI

+To begin, sign in to Azure. Run the following command, and follow the prompts to complete the authentication process.

+```azurecli

+az login

+```

+Next, install the Azure Dev Center extension for the CLI.

+```azurecli

+az extension add --name devcenter --upgrade

+```

+Now that the current extension is installed, register the `Microsoft.DevCenter` namespace.

+```azurecli

+az provider register --namespace Microsoft.DevCenter

+```

+> [!TIP]

+> Throughout this tutorial, you'll save several values as environment variables to use later. You may also want to record these value elsewhere to ensure they are available when needed.

+Get your user's ID and set it to an environment variable for later:

+```azurecli

+MY_AZURE_ID=$(az ad signed-in-user show --query id -o tsv)

+```

+Retrieve the subscription ID for your current subscription.

+```azurecli

+AZURE_SUBSCRIPTION_ID=$(az account show --query id --output tsv)

+```

+Retrieve the tenant ID for your current tenant.

+```azurecli

+AZURE_TENANT_ID=$(az account show --query tenantId --output tsv)

+```

+Set the following environment variables:

+```azurecli

+LOCATION="eastus"

+AZURE_RESOURCE_GROUP="my-dev-center-rg"

+AZURE_DEVCENTER="my-dev-center"

+AZURE_PROJECT="my-project"

+AZURE_KEYVAULT="myuniquekeyvaultname"

+```

+### 1.2 Create a dev center

+A dev center is a collection of projects and environments that have similar settings. Dev centers provide access to a catalog of templates and artifacts that can be used to create environments. Dev centers also provide a way to manage access to environments and projects.

+Create a Resource Group

+```azurecli

+az group create \

+ --name $AZURE_RESOURCE_GROUP \

+ --location $LOCATION

+```

+Create a new Dev Center

+```azurecli

+az devcenter admin devcenter create \

+ --name $AZURE_DEVCENTER \

+ --identity-type SystemAssigned \

+ --resource-group $AZURE_RESOURCE_GROUP \

+ --location $LOCATION

+```

+The previous command outputs JSON. Save the values for `id` and `identity.principalId` as environment variables to use later.

+```azurecli

+AZURE_DEVCENTER_ID=<id>

+AZURE_DEVCENTER_PRINCIPAL_ID=<identity.principalId>

+```

+### 1.3 Assign dev center identity owner role on subscription

+A dev center needs permissions to assign roles on subscriptions associated with environment types.

+To reduce unnecessary complexity, in this tutorial, you use a single subscription for the dev center and all environment types. In practice, the dev center and target deployment subscriptions would likely be separate subscriptions with different policies applied.

+```azurecli

+az role assignment create \

+ --scope /subscriptions/$AZURE_SUBSCRIPTION_ID \

+ --role Owner \

+ --assignee-object-id $AZURE_DEVCENTER_PRINCIPAL_ID \

+ --assignee-principal-type ServicePrincipal

+```

+### 1.4 Create the environment types

+ At the dev center level, environment types define the environments that development teams can create, like dev, test, sandbox, preproduction, or production.

+Create three new Environment types: **Dev**, **Test**, and **Prod**.

+```azurecli

+az devcenter admin environment-type create \

+ --name Dev \

+ --resource-group $AZURE_RESOURCE_GROUP \

+ --dev-center $AZURE_DEVCENTER

+```

+```azurecli

+az devcenter admin environment-type create \

+ --name Test \

+ --resource-group $AZURE_RESOURCE_GROUP \

+ --dev-center $AZURE_DEVCENTER

+```

+```azurecli

+az devcenter admin environment-type create \

+ --name Prod \

+ --resource-group $AZURE_RESOURCE_GROUP \

+ --dev-center $AZURE_DEVCENTER

+```

+### 1.5 Create a project

+A project is the point of access for the development team. Each project is associated with a dev center.

+Create a new Project

+```azurecli

+az devcenter admin project create \

+ --name $AZURE_PROJECT \

+ --resource-group $AZURE_RESOURCE_GROUP \

+ --location $LOCATION \

+ --dev-center-id $AZURE_DEVCENTER_ID

+```

+The previous command outputs JSON. Save the `id` value as an environment variable to use later.

+```azurecli

+AZURE_PROJECT_ID=<id>

+```

+Assign yourself the "DevCenter Project Admin" role on the project

+```azurecli

+az role assignment create \

+ --scope "$AZURE_PROJECT_ID" \

+ --role "DevCenter Project Admin" \

+ --assignee-object-id $MY_AZURE_ID \

+ --assignee-principal-type User

+```

+### 1.6 Create project environment types

+At the project level, dev infra admins specify which environment types are appropriate for the development team.

+Create a new Project Environment Type for each of the Environment Types we created on the dev center

+```azurecli

+az devcenter admin project-environment-type create \

+ --name Dev \

+ --roles "{\"b24988ac-6180-42a0-ab88-20f7382dd24c\":{}}" \

+ --deployment-target-id /subscriptions/$AZURE_SUBSCRIPTION_ID \

+ --resource-group $AZURE_RESOURCE_GROUP \

+ --location $LOCATION \

+ --project $AZURE_PROJECT \

+ --identity-type SystemAssigned \

+ --status Enabled

+```

+```azurecli

+az devcenter admin project-environment-type create \

+ --name Test \

+ --roles "{\"b24988ac-6180-42a0-ab88-20f7382dd24c\":{}}" \

+ --deployment-target-id /subscriptions/$AZURE_SUBSCRIPTION_ID \

+ --resource-group $AZURE_RESOURCE_GROUP \

+ --location $LOCATION \

+ --project $AZURE_PROJECT \

+ --identity-type SystemAssigned \

+ --status Enabled

+```

+```azurecli

+az devcenter admin project-environment-type create \

+ --name Prod \

+ --roles "{\"b24988ac-6180-42a0-ab88-20f7382dd24c\":{}}" \

+ --deployment-target-id /subscriptions/$AZURE_SUBSCRIPTION_ID \

+ --resource-group $AZURE_RESOURCE_GROUP \

+ --location $LOCATION \

+ --project $AZURE_PROJECT \

+ --identity-type SystemAssigned \

+ --status Enabled

+```

+## 2. Create a key vault

+In this section, you create a new key vault. You use this key vault later in the tutorial to save a [personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token#fine-grained-personal-access-tokens) from GitHub.

+```azurecli

+az keyvault create \

+ --name $AZURE_KEYVAULT \

+ --resource-group $AZURE_RESOURCE_GROUP \

+ --location $LOCATION \

+ --enable-rbac-authorization true

+```

+Again, save the `id` from the previous command's JSON output as an environment variable.

+```azurecli

+AZURE_KEYVAULT_ID=<id>

+```

+Give yourself the "Key Vault Administrator" role on the new key vault.

+```azurecli

+az role assignment create \

+ --scope $AZURE_KEYVAULT_ID \

+ --role "Key Vault Administrator" \

+ --assignee-object-id $MY_AZURE_ID \

+ --assignee-principal-type User

+```

+Assign the dev center's identity the role of "Key Vault Secrets User"

+```azurecli

+az role assignment create \

+ --scope $AZURE_KEYVAULT_ID \

+ --role "Key Vault Secrets User" \

+ --assignee-object-id $AZURE_DEVCENTER_PRINCIPAL_ID \

+ --assignee-principal-type ServicePrincipal

+```

+## 3. Create and configure a GitHub repository

+In this section, you create a new GitHub repository to store a catalog. Azure Deployment Environments supports both GitHub and Azure DevOps repositories. In this tutorial, you use GitHub.

+### 3.1 Create a new GitHub repository

+In this step, you create a new repository in your GitHub account that has a predefined directory structure, branches, and files. These items are generated from a sample template repository.

+1. Use this link to generate a new GitHub repository from the [sample template](https://github.com/Azure-Samples/deployment-environments-cicd-tutorial/generate).

+

+ :::image type="content" source="media/tutorial-deploy-environments-in-cicd-github/github-generate-from-template.png" alt-text="Screenshot showing the GitHub create repository from template page.":::

+1. If you don't have a paid GitHub account, set your repository to **Public**.

+1. Select **Create repository from template**.

+1. On the **Actions** tab, notice that the Create Environment action fails. This behavior is expected, you can proceed with the next step.

+### 3.2 Protect the repository's *main* branch

+You can protect important branches by setting branch protection rules. Protection rules define whether collaborators can delete or force push to the branch. They also set requirements for any pushes to the branch, such as passing status checks or a linear commit history.

+> [!NOTE]

+> Protected branches are available in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see "[GitHubΓÇÖs products](https://docs.github.com/en/get-started/learning-about-github/githubs-products)".

+1. If it's not already open, navigate to the main page of your repository.

+1. Under your repository name, select **Settings**. If you can't see the "Settings" tab, select the **...** dropdown menu, then select **Settings**.

+

+ :::image type="content" source="media/tutorial-deploy-environments-in-cicd-github/github-repo-settings.png" alt-text="Screenshot showing the GitHub repository page with settings highlighted.":::

+1. In the **Code and automation** section of the sidebar, select **Branches**.

+ :::image type="content" source="media/tutorial-deploy-environments-in-cicd-github/github-branches-protect.png" alt-text="Screenshot showing the settings page, with branches highlighted.":::

+1. Under **Branch protection rules**, select **Add branch protection rule**.

+

+ :::image type="content" source="media/tutorial-deploy-environments-in-cicd-github/github-protect-rule.png" alt-text="Screenshot showing the branch protection rule page, with Add branch protection rule highlighted. ":::

+1. Under **Branch name pattern**, enter <*main*>.

+

+ :::image type="content" source="media/tutorial-deploy-environments-in-cicd-github/github-branch-name-pattern.png" alt-text="Screenshot showing the branch name pattern text box, with main highlighted.":::

+

+1. Under **Protect matching branches**, select **Require a pull request before merging**.

+ :::image type="content" source="media/tutorial-deploy-environments-in-cicd-github/github-require-pull-request.png" alt-text="Screenshot showing protect matching branches with Require a pull request before merging selected and highlighted.":::

+1. Optionally, you can enable [more protection rules](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule#creating-a-branch-protection-rule).

+1. Select **Create**.

+### 3.3 Configure repository variables

+> [!NOTE]

+> Configuration variables for GitHub Actions are in beta and subject to change.

+1. In the **Security** section of the sidebar, select **Secrets and variables**, then select **Actions**.

+1. Select the **Variables** tab.

+

+ :::image type="content" source="media/tutorial-deploy-environments-in-cicd-github/github-security-menu.png" alt-text="Screenshot showing the Security section of the sidebar with Actions highlighted.":::

+1. For each item in the table:

+ 1. Select **New repository variable**.

+ 2. In the **Name** field, enter the variable name.

+ 3. In the **Value** field, enter the value described in the table.

+ 4. Select **Add variable**.

+ | Variable name | Variable value |

+ | | - |

+ | AZURE_DEVCENTER | Dev center name |

+ | AZURE_PROJECT | Project name |

+ | AZURE_CATALOG | Set to: _Environments_ |

+ | AZURE_CATALOG_ITEM | Set to: _FunctionApp_ |

+ | AZURE_SUBSCRIPTION_ID | Azure subscription ID (GUID) |

+ | AZURE_TENANT_ID | Azure tenant ID (GUID) |

+ :::image type="content" source="media/tutorial-deploy-environments-in-cicd-github/github-variables.png" alt-text="Screenshot showing the variables page with the variables table.":::

+### 3.4 Create a GitHub personal access token

+Next, create a [fine-grained personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token#fine-grained-personal-access-tokens) to enable your dev center to connect to your repository and consume the environment catalog.

+> [!NOTE]

+> Fine-grained personal access token are currently in beta and subject to change. To leave feedback, see the [feedback discussion](https://github.com/community/community/discussions/36441).

+1. In the upper-right corner of any page on GitHub.com, select your profile photo, then select **Settings**.

+1. In the left sidebar, select **Developer settings**.

+1. In the left sidebar, under **Personal access tokens**, select **Fine-grained tokens**, and then select **Generate new token**.

+

+ :::image type="content" source="media/tutorial-deploy-environments-in-cicd-github/github-fine-grained-personal-access-token.png" alt-text="Screenshot showing the GitHub personal access token options, with Fine-grained tokens and Generate new token highlighted.":::

+1. On the New fine-grained personal access token page, under **Token name**, enter a name for the token.

+1. Under **Expiration**, select an expiration for the token.

+1. Select your GitHub user under **Resource owner**.

+1. Under **Repository access**, select **Only select repositories** then in the **Selected repositories** dropdown, search and select the repository you created.

+

+ :::image type="content" source="media/tutorial-deploy-environments-in-cicd-github/github-repo-access.png" alt-text="Screenshot showing GitHub repository access options, with Only select repositories highlighted.":::

+1. Under **Permissions**, select **Repository permissions**, and change **Contents** to **Read-only**.

+ :::image type="content" source="media/tutorial-deploy-environments-in-cicd-github/github-repo-permissions.png" alt-text="Screenshot showing GitHub repository permissions with Contents highlighted.":::

+1. Select **Generate token**.

+

+1. Copy your personal access token now. You cannot view it again.

+### 3.5 Save personal access token to key vault

+Next, save the PAT token as a key vault secret named _pat_.

+```azurecli

+az keyvault secret set \

+ --name pat \

+ --vault-name $AZURE_KEYVAULT \

+ --value "github_pat_..."

+```

+## 4. Connect the catalog to your dev center

+A catalog is a repository that contains a set of catalog items. Catalog items consist of an IaC template and a manifest file. The template defines the environment, and the manifest provides metadata about the template. Development teams use catalog items from the catalog to create environments.

+The template you used to create your GitHub repository contains a catalog in the _Environments_ folder.

+#### Add the catalog to your dev center

+In the following command, replace `< Organization/Repository >` with your GitHub organization and repository name.

+```azurecli

+az devcenter admin catalog create \

+ --name Environments \

+ --resource-group $AZURE_RESOURCE_GROUP \

+ --dev-center $AZURE_DEVCENTER \

+ --git-hub path="/Environments" branch="main" secret-identifier="https://$AZURE_KEYVAULT.vault.azure.net/secrets/pat" uri="https://github.com/< Organization/Repository >.git"

+```

+## 5. Configure deployment identities

+[OpenID Connect with GitHub Actions](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect) is an authentication method that uses short-lived tokens to offer hardened security. It's the recommended way to authenticate GitHub Actions to Azure.

+You can also authenticate a service principal directly using a secret, but that is out of scope for this tutorial.

+### 5.1 Generate deployment identities

+1. Register [new Active Directory applications and service principals](../active-directory/develop/howto-create-service-principal-portal.md) for each of the three environment types.

+ Create the Active Directory application for **Dev**.

+ ```azurecli

+ az ad app create --display-name "$AZURE_PROJECT-Dev"

+ ```

+ This command outputs JSON with an `id` that you use when creating federated credentials with Graph API, and an `appId` (also called client ID).

+ Set the following environment variables:

+ ```azurecli

+ DEV_AZURE_CLIENT_ID=<appId>

+ DEV_APPLICATION_ID=<id>

+ ```

+ Repeat for **Test**:

+ ```azurecli

+ az ad app create --display-name "$AZURE_PROJECT-Test"

+ ```

+ ```azurecli

+ TEST_AZURE_CLIENT_ID=<appId>

+ TEST_APPLICATION_ID=<id>

+ ```

+ And **Prod**:

+ ```azurecli

+ az ad app create --display-name "$AZURE_PROJECT-Prod"

+ ```

+ ```azurecli

+ PROD_AZURE_CLIENT_ID=<appId>

+ PROD_APPLICATION_ID=<id>

+ ```

+2. Create a service principal for each application.

+ Run the following command to create a new service principal for **Dev**.

+ ```azurecli

+ az ad sp create --id $DEV_AZURE_CLIENT_ID

+ ```

+ This command generates JSON output with a different `id` and will be used in the next step.

+ Set the following environment variables:

+ ```azurecli

+ DEV_SERVICE_PRINCIPAL_ID=<id>

+ ```

+ Repeat for **Test**:

+ ```azurecli

+ az ad sp create --id $TEST_AZURE_CLIENT_ID

+ ```

+ ```azurecli

+ TEST_SERVICE_PRINCIPAL_ID=<id>

+ ```

+ And **Prod**:

+ ```azurecli

+ az ad sp create --id $PROD_AZURE_CLIENT_ID

+ ```

+ ```azurecli

+ PROD_SERVICE_PRINCIPAL_ID=<id>

+ ```

+3. Run the following commands to [create a new federated identity credentials](/graph/api/application-post-federatedidentitycredentials?view=graph-rest-beta&preserve-view=true) for each active directory application.

+ In each of the three following commands, replace `< Organization/Repository >` with your GitHub organization and repository name.

+ Create the federated identity credential for **Dev**:

+ ```azurecli

+ az rest --method POST \

+ --uri "https://graph.microsoft.com/beta/applications/$DEV_APPLICATION_ID/federatedIdentityCredentials" \

+ --body '{"name":"ADEDev","issuer":"https://token.actions.githubusercontent.com","subject":"repo:< Organization/Repository >:environment:Dev","description":"Dev","audiences":["api://AzureADTokenExchange"]}'

+ ```

+ For **Test**:

+ ```azurecli

+ az rest --method POST \

+ --uri "https://graph.microsoft.com/beta/applications/$TEST_APPLICATION_ID/federatedIdentityCredentials" \

+ --body '{"name":"ADETest","issuer":"https://token.actions.githubusercontent.com","subject":"repo:< Organization/Repository >:environment:Test","description":"Test","audiences":["api://AzureADTokenExchange"]}'

+ ```

+ And **Prod**:

+ ```azurecli

+ az rest --method POST \

+ --uri "https://graph.microsoft.com/beta/applications/$PROD_APPLICATION_ID/federatedIdentityCredentials" \

+ --body '{"name":"ADEProd","issuer":"https://token.actions.githubusercontent.com","subject":"repo:< Organization/Repository >:environment:Prod","description":"Prod","audiences":["api://AzureADTokenExchange"]}'

+ ```

+### 5.2 Assign roles to deployment identities

+1. Assign each deployment identity the Reader role on the project.

+ ```azurecli

+ az role assignment create \

+ --scope "$AZURE_PROJECT_ID" \

+ --role Reader \

+ --assignee-object-id $DEV_SERVICE_PRINCIPAL_ID \

+ --assignee-principal-type ServicePrincipal

+ ```

+ ```azurecli

+ az role assignment create \

+ --scope "$AZURE_PROJECT_ID" \

+ --role Reader \

+ --assignee-object-id $TEST_SERVICE_PRINCIPAL_ID \

+ --assignee-principal-type ServicePrincipal

+ ```

+ ```azurecli

+ az role assignment create \

+ --scope "$AZURE_PROJECT_ID" \

+ --role Reader \

+ --assignee-object-id $PROD_SERVICE_PRINCIPAL_ID \

+ --assignee-principal-type ServicePrincipal

+ ```

+1. Assign each deployment identity the "Deployment Environments User" role to it's corresponding environment type

+ ```azurecli

+ az role assignment create \

+ --scope "$AZURE_PROJECT_ID/environmentTypes/Dev" \

+ --role "Deployment Environments User" \

+ --assignee-object-id $DEV_SERVICE_PRINCIPAL_ID \

+ --assignee-principal-type ServicePrincipal

+ ```

+ ```azurecli

+ az role assignment create \

+ --scope "$AZURE_PROJECT_ID/environmentTypes/Test" \

+ --role "Deployment Environments User" \

+ --assignee-object-id $TEST_SERVICE_PRINCIPAL_ID \

+ --assignee-principal-type ServicePrincipal

+ ```

+ ```azurecli

+ az role assignment create \

+ --scope "$AZURE_PROJECT_ID/environmentTypes/Prod" \

+ --role "Deployment Environments User" \

+ --assignee-object-id $PROD_SERVICE_PRINCIPAL_ID \

+ --assignee-principal-type ServicePrincipal

+ ```

+## 6. Configure GitHub environments

+With GitHub environments, you can configure environments with protection rules and secrets. A workflow job that references an environment must follow any protection rules for the environment before running or accessing the environment's secrets.

+Create three environments: Dev, Test, and Prod to map to the project's environment types.

+> [!NOTE]

+> Environments, environment secrets, and environment protection rules are available in public repositories for all products. For access to environments, environment secrets, and deployment branches in **private** or **internal** repositories, you must use GitHub Pro, GitHub Team, or GitHub Enterprise. For access to other environment protection rules in **private** or **internal** repositories, you must use GitHub Enterprise. For more information, see "[GitHubΓÇÖs products.](https://docs.github.com/en/get-started/learning-about-github/githubs-products)"

+### 6.1 Create the Dev environment

+1. On GitHub.com, navigate to the main page of your repository.

+1. Under your repository name, select **Settings**. If you can't see the "Settings" tab, select the **...** dropdown menu, then select **Settings**.

+1. In the left sidebar, select **Environments**.

+

+1. Select **New environment** and enter _Dev_ for the environment name, then select **Configure environment**.

+

+ :::image type="content" source="media/tutorial-deploy-environments-in-cicd-github/github-create-environment.png" alt-text="Screenshot showing the Environments Add pane, with the environment name Dev, and Configure Environment highlighted. ":::

+1. Under **Environment secrets**, select **Add Secret** and enter _AZURE_CLIENT_ID_ for **Name**.

+ :::image type="content" source="media/tutorial-deploy-environments-in-cicd-github/github-secret.png" alt-text="Screenshot showing the Environment Configure Dev pane, with Add secret highlighted.":::

+1. For **Value**, enter the client ID (`appId`) for the **Dev** Azure AD app you created earlier (saved as the `$DEV_AZURE_CLIENT_ID` environment variable).

+

+ :::image type="content" source="media/tutorial-deploy-environments-in-cicd-github/github-add-secret.png" alt-text="Screenshot of the Add secret box with the name AZURE CLIENT ID, the value set to an ID number, and add secret highlighted.":::

+1. Select **Add secret**.

+### 6.2 Create the Test environment

+Return to the main environments page by selecting **Environments** in the left sidebar.

+1. Select **New environment** and enter _Test_ for the environment name, then select **Configure environment**.

+2. Under **Environment secrets**, select **Add Secret** and enter _AZURE_CLIENT_ID_ for **Name**.

+3. For **Value**, enter the client ID (`appId`) for the **Test** Azure AD app you created earlier (saved as the `$TEST_AZURE_CLIENT_ID` environment variable).

+4. Select **Add secret**.

+### 6.3 Create the Prod environment

+Once more, return to the main environments page by selecting **Environments** in the left sidebar

+1. Select **New environment** and enter _Prod_ for the environment name, then select **Configure environment**.

+2. Under **Environment secrets**, select **Add Secret** and enter _AZURE_CLIENT_ID_ for **Name**.

+3. For **Value**, enter the client ID (`appId`) for the **Prod** Azure AD app you created earlier (saved as the `$PROD_AZURE_CLIENT_ID` environment variable).

+4. Select **Add secret**.

+Next, set yourself as a [required reviewer](https://docs.github.com/en/actions/managing-workflow-runs/reviewing-deployments) for this environment. When attempting to deploy to Prod, the GitHub Actions wait for an approval before starting. While a job is awaiting approval, it has a status of "Waiting". If a job isn't approved within 30 days, it automatically fails.

+For more information about environments and required approvals, see "[Using environments for deployment](https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment)."

+1. Select **Required reviewers**.

+2. Search for and select your GitHub user. You may enter up to six people or teams. Only one of the required reviewers needs to approve the job for it to proceed.

+3. Select **Save protection rules**.

+Finally configure *main* as the deployment branch:

+1. In the **Deployment branches dropdown**, choose **Selected branches**.

+2. Select **Add deployment branch rule** and enter *main* for the **Branch name pattern**.

+3. Select **Add rule**.

+## 7. Test the CI/CD pipeline

+In this section, you make some changes to the repository and test the CI/CD pipeline.

+### 7.1 Clone the repository

+1. In your terminal, cd into a folder where you'd like to clone your repository locally.

+2. Clone the repository. Be sure to replace `< Organization/Repository >` in the following command with your GitHub organization and repository name.

+ ```azurecli

+ git clone https://github.com/< Organization/Repository >.git

+ ```

+3. Navigate into the cloned directory.

+ ```azurecli

+ cd Repository

+ ```

+4. Next, create a new branch and publish it remotely.

+ ```azurecli

+ git checkout -b feature1

+ ```

+ ```azurecli

+ git push -u origin feature1

+ ```

+ A new environment is created in Azure specific to this branch.

+5. Go to [GitHub](https://github.com) and navigate to the main page of your newly created repository.

+6. Under your repository name, select **Actions**.

+ You should see a new Create Environment workflow running.

+### 7.2 Make a change to the code

+1. Open the locally cloned repo in VS Code.

+1. In the ADE.Tutorial folder, make a change to a file.

+1. Save your change.

+### 7.3 Push your changes to update the environment

+1. Stage your changes and push to the `feature1` branch.

+ ``` azurecli

+ git add .

+ git commit -m '<commit message>'

+ git push

+ ```

+1. On your repository's **Actions** page, you see a new Update Environment workflow running.

+### 7.4 Create a pull request

+1. Create a pull request on GitHub.com `main <- feature1`.

+1. On your repository's **Actions** page, you see a new workflow is started to create an environment specific to the PR using the Test environment type.

+### 7.5 Merge the PR

+1. On [GitHub](https://github.com), navigate to the pull request you created.

+1. Merge the PR.

+ Your changes are published into the production environment, and delete the branch and pull request environments.

+## Clean up resources

+## Next steps

+- Learn more about managing your environments by using the CLI in [Create and access an environment by using the Azure CLI](how-to-create-access-environments.md).

+- For complete command listings, refer to the [Microsoft Deployment Environments and Azure Deployment Environments Azure CLI documentation](https://aka.ms/CLI-reference).

+In this article, you learn how to create your first reverse lookup DNS zone and record by using the Azure portal, Azure PowerShell, Azure classic CLI, and Azure CLI.

+ | **Location** | Select the location for the resource group. The location is already be selected if you're using a previously created resource group. |

+> For example, for the IP range of 192.0.2.128/26, use `128-26.2.0.192.in-addr.arpa` as the zone name instead of `128/26.2.0.192.in-addr.arpa`.

+For forward lookup zones, the process of delegating a DNS zone is described in [Delegate your domain to Azure DNS](dns-delegate-domain-azure-dns.md). Delegation for reverse lookup zones works the same way. The only difference is that you need to configure the name servers with the ISP. The ISP manages your IP range, that's why they need to update the name servers instead of domain name registrar.

+1. The name of the record set for a PTR record is the rest of the IPv4 address in reverse order.

+ In this example, the first three octets are already populated as part of the zone name `.2.0.192`. That's why only the last octet is needed in the **Name** box. For example, give your record set the name of **15** for a resource whose IP address is `192.0.2.15`.

+1. The name of the record set for a PTR record is the rest of the IPv6 address in reverse order. It must not include any zero compression.

+ In this example, the first 64 bits of the IPv6 gets populated as part of the zone name (0.0.0.0.c.d.b.a.8.b.d.0.1.0.0.2.ip6.arpa). That's why only the last 64 bits are supplied in the **Name** box. The last 64 bits of the IP address gets entered in reverse order, with a period as the delimiter between each hexadecimal number. Name your record set **e.5.0.4.9.f.a.1.c.b.0.1.4.2.5.f** if you have a resource whose IP address is 2001:0db8:abdc:0000:f524:10bc:1af9:405e.

+The **DNS zone** page shows the IPv4 PTR record:

+- **Subscription**: Select an Azure subscription.

+- **Resource Group**: Give the resource group a name.

+- **Region**: Specify an Azure location. This location is where the resource group stores metadata about the resource. For compliance reasons, you may want to specify where that metadata is stored. In general, we recommend that you specify a location where most of your resources will be. Using the same location can simplify your template. The following regions are supported:

+- southcentralus

+- eastus

+- australiaeast

+- westus3

+- swedencentral

+- eastasia

+- japaneast

+- westeurope

+- northeurope

+- switzerlandnorth

+To help you meet your own compliance obligations across regulated industries and markets worldwide, Azure maintains the largest compliance portfolio in the industry both in terms of breadth (total number of offerings) and depth (number of [customer-facing services](https://azure.microsoft.com/services/) in assessment scope). For service availability, see [Products available by region](https://azure.microsoft.com/global-infrastructure/services/).

+## Azure Firewall audit scope

+Microsoft retains independent, third-party auditing firms to conduct audits of Microsoft cloud services. The resulting compliance assurances are applicable to both Azure and Azure Government cloud environments. Compliance offerings are grouped into four segments: globally applicable, US government, industry specific, and region/country specific. Azure compliance certificates and audit reports state clearly which cloud services are in scope for independent third-party audits. Different audits may have different cloud services in audit scope.

+Azure Firewall is included in many Azure compliance audits such as CSA STAR, ISO, SOC, PCI DSS, HITRUST, FedRAMP, DoD, and others. For the latest insight into Azure Firewall compliance audit scope, see [Cloud services in audit scope](/azure/compliance/offerings/cloud-services-in-audit-scope).

+For more information about Azure compliance, see the following information.

+- [Azure compliance](../compliance/index.yml)

+- [Azure and other Microsoft services compliance offerings](/azure/compliance/offerings/)

+Because of the CPU impact, enable Top flows only when you need to troubleshoot a specific issue. The recommendation is to enable Top flows no longer than one week at a time.

+Currently, the firewall logs show traffic through the firewall in the first attempt of a TCP connection, known as the *syn* packet. However, this doesn't show the full journey of the packet in the TCP handshake. As a result, it's difficult to troubleshoot if a packet is dropped, or asymmetric routing has occurred.

+Because of the disk impact, enable Flow trace only when you need to troubleshoot a specific issue. The recommendation is to enable Flow trace no longer than one week at a time.

+- SYN-ACK

+ Ack flag that indicates acknowledgment of SYN packet.

+- FIN

+ Finished flag of the original packet flow. No more data is transmitted in the TCP flow.

+- FIN-ACK

+ Ack flag that indicates acknowledgment of FIN packet.

+- RST

+ Reset flag that indicates that original sender won't receive more data.

+ Indicates packet canΓÇÖt be identified or don't have any state; TCP packet is landing on a Virtual Machine Scale Sets instance, which doesn't have any prior history to this packet.

+It can take several minutes for this to take effect. Once the feature is completely registered, consider performing an update on Azure Firewall for the change to take effect immediately.

+To check the status of the AzResourceProvider registration, you can run the Azure PowerShell command:

+`Get-AzProviderFeature -FeatureName "AFWEnableTcpConnectionLogging" -ProviderNamespace "Microsoft.Network"`

+IDPS allows you to detect attacks in all ports and protocols for nonencrypted traffic. However, when HTTPS traffic needs to be inspected, Azure Firewall can use its TLS inspection capability to decrypt the traffic and better detect malicious activities.

+You can create exceptions to your web category rules. Create a separate allow or deny rule collection with a higher priority within the rule collection group. For example, you can configure a rule collection that allows `www.linkedin.com` with priority 100, with a rule collection that denies **Social networking** with priority 200. This creates the exception for the predefined **Social networking** web category.

+### Web categories that don't support TLS termination

+Due to privacy and compliance reasons, certain web traffic that is encrypted can't be decrypted using TLS termination. For example, employee health data transmitted through web traffic over a corporate network shouldn't be TLS terminated due to privacy reasons.

+As a result, the following Web Categories don't support TLS termination:

+- Education

+- Finance

+- Government

+- Health and medicine

+As a workaround, if you want a specific URL to support TLS termination, you can manually add the URL(s) with TLS termination in application rules. For example, you can add `www.princeton.edu` to application rules to allow this website.

+> [!NOTE]

+> Ensure the **origin path** in your routing rule is configured correctly with the storage container file path so file requests can be acquired.

+>

+On secure clusters backed by Azure Data Lake (Gen1 or Gen2), when domain users sign in to the cluster services through HDI Gateway (like signing in to the Apache Ambari portal), HDI Gateway tries to obtain an OAuth token from Azure Active Directory (Azure AD) first, and then get a Kerberos ticket from Azure AD DS. Authentication can fail in either of these stages. This article is aimed at debugging some of those issues.

+When the authentication fails, you gets prompted for credentials. If you cancel this dialog, the error message is printed. Here are some of the common error messages:

+Azure AD error code 50126 means the `AllowCloudPasswordValidation` policy not set by the tenant.

+{"error":"invalid_grant","error_description":"AADSTS50034: The user account Microsoft.AzureAD.Telemetry.Diagnostics.PII doesn't exist in the 0c349e3f-1ac3-4610-8599-9db831cbaf62 directory. To sign into this application, the account must be added to the directory.\r\nTrace ID: bbb819b2-4c6f-4745-854d-0b72006d6800\r\nCorrelation ID: b009c737-ee52-43b2-83fd-706061a72b41\r\nTimestamp: 2019-04-29 15:52:16Z", "error_codes":[50034],"timestamp":"2019-04-29 15:52:16Z","trace_id":"bbb819b2-4c6f-4745-854d-0b72006d6800", "correlation_id":"b009c737-ee52-43b2-83fd-706061a72b41"}

+User name is incorrect (doesn't exist). The user isn't using the same username that is used in Azure portal.

+The conditional access policy or MFA is being applied to the user. Since interactive authentication isn't supported yet, the user or the cluster needs to be exempted from MFA / Conditional access. If you choose to exempt the cluster (IP address based exemption policy), then make sure that the AD `ServiceEndpoints` are enabled for that vnet.

+Use conditional access policy and exempt the HDInsight clusters from MFA as shown in [Configure a HDInsight cluster with Enterprise Security Package by using Azure Active Directory Domain Services](./apache-domain-joined-configure-using-azure-adds.md).

+Sign in denied.

+To get to this stage, your OAuth authentication isn't an issue, but Kerberos authentication is. If this cluster is backed by ADLS, OAuth sign in has succeeded before Kerberos auth is attempted. On WASB clusters, OAuth sign in isn't attempted. There could be many reasons for Kerberos failure - like password hashes are out of sync, user account locked out in Azure AD DS, and so on. Password hashes sync only when the user changes password. When you create the Azure AD DS instance, it will start syncing passwords that are changed after the creation. It can't retroactively sync passwords that were set before its inception.

+Try to SSH into a You need to try to authenticate (kinit) using the same user credentials, from a machine that is joined to the domain. SSH into the head / edge node with a local user and then run kinit.

+For kinit to succeed, you need to know your `sAMAccountName` (this is the short account name without the realm). `sAMAccountName` is usually the account prefix (like bob in `bob@contoso.com`). For some users, it could be different. You need the ability to browse / search the directory to learn your `sAMAccountName`.

+Check your username and password. Also check for other properties described. To enable verbose debugging, run `export KRB5_TRACE=/tmp/krb.log` from the session before trying kinit.

+The required OAuth access token wasn't found for the job / command to succeed. The ADLS / ABFS driver tries to retrieve the OAuth access token from the credential service before making storage requests. This token gets registered when you sign in to the Ambari portal using the same user.

+* Build an end-to-end application with [Analyze real-time Twitter sentiment with Apache HBase](./apache-hbase-tutorial-get-started-linux.md)

+Leave the `"parameter": []` field blank (as shown) if you don't need to tweak the compute resources allocated to the reindex job.

+If the request is successful, you will receive a **201 Created** status code in addition to a `Parameters` resource in response

+In case, there is a need to run reindex job against specific custom search parameter, use the following `POST` call with the JSON formatted `Parameters` resource in the request body:

+```json

+POST {{FHIR_URL}}/$reindex

+{

+"resourceType": "Parameters",

+"parameter": [

+ "name": "targetSearchParameterTypes",

+ "valueString": "{url of custom search parameter. In case of multiple custom search parameters, url list can be comma seperated.}"

+]

+}

+ ```

+description: Learn how to use the MedTech service and the Azure Machine Learning Service

+In this article, we explore using the MedTech service and the Azure Machine Learning Service.

+The MedTech service enables IoT devices to seamless integration with FHIR services. This reference architecture is designed to accelerate adoption of Internet of Things (IoT) projects. This solution uses Azure Databricks for the Machine Learning (ML) compute. However, Azure Machine Learning Services with Kubernetes or a partner ML solution could fit into the Machine Learning Scoring Environment.

+4. PHI IoT payload moves from Azure IoT Hub to the MedTech service. The MedTech service icon represents multiple Azure services.

+7. Azure Function (ML Input) requests Patient resource to merge with IoT payload.

+8. IoT payload with PHI is sent to an event hub for distribution to Machine Learning compute and storage.

+9. PHI IoT payload is sent to Azure Data Lake Storage Gen 2 for scoring observation over longer time windows.

+10. PHI IoT payload is sent to Azure Databricks for windowing, data fitting, and data scoring.

+13. RiskAssessment and/or Flag resource submitted to FHIR service. a. For each observation window, a RiskAssessment resource is submitted to the FHIR service. b. For observation windows where the risk assessment is outside the acceptable range a Flag resource should also be submitted to the FHIR service.

+description: Learn how to use the MedTech service and Power BI

+In this article, we explore using the MedTech service and Microsoft Power Business Intelligence (BI).

+This reference architecture shows the basic components of using the Microsoft cloud services to enable Power BI on top of Internet of Things (IoT) and FHIR data.

+description: Learn how to use the MedTech service and Teams notifications

+In this article, we explore using the MedTech service and Microsoft Teams for notifications.

+When combining the MedTech service, the FHIR service, and Teams, you can enable multiple care solutions.

+* Open an ARM template in the Azure portal.

+* Configure the ARM template for your deployment.

+* Deploy the ARM template.

+- **Owner** or **Contributor and User Access Administrator** role assignments in the Azure subscription. For more information, see [What is Azure role-based access control (Azure RBAC)?](../../role-based-access-control/overview.md)

+## Review the ARM template (Optional)

+ * **Subscription** - The Azure subscription to use for the deployment.

+ * **Resource group** - An existing resource group, or you can create a new resource group.

+ * **Region** - The Azure region of the resource group that's used for the deployment. Region autofills by using the resource group region.

+ * **Basename** - A value that's appended to the name of the Azure resources and services that are deployed.

+ * **Location** - Use the drop-down list to select a supported Azure region for the Azure Health Data Services (the value could be the same or different region than your resource group).

+ * **Device Mapping** - Don't change the default values for this quickstart.

+ * **Destination Mapping** - Don't change the default values for this quickstart.

+ > If you're going to allow access from multiple services to the event hub, it's required that each service has its own event hub consumer group.

+ > * Two MedTech services accessing the same event hub.

+ > * A MedTech service and a storage writer application accessing the same event hub.

+ * Event hub consumer group. In this deployment, the consumer group is named *$Default*.

+ * **Azure Event Hubs Data Sender** role. In this deployment, the sender role is named *devicedatasender* and can be used to provide access to the device event hub using a shared access signature (SAS). To learn more about authorizing access using a SAS, see [Authorizing access to Event Hubs resources using Shared Access Signatures](../../event-hubs/authorize-access-shared-access-signature.md).

+* Health Data Services workspace.

+* Health Data Services Fast Healthcare Interoperability Resources FHIR service.

+* Health Data Services MedTech service with the required [system-assigned managed identity](../../active-directory/managed-identities-azure-resources/overview.md) roles:

+ * For the event hub, the **Azure Event Hubs Data Receiver** role is assigned in the [Access control section (IAM)](../../role-based-access-control/overview.md) of the event hub.

+ * For the FHIR service, the **FHIR Data Writer** role is assigned in the [Access control section (IAM)](../../role-based-access-control/overview.md) of the FHIR service.

+> To learn about the MedTech service resolution types **Create** and **Lookup**, see [Configure the Destination tab](deploy-manual-portal.md#configure-the-destination-tab).

+description: Learn how to deploy the MedTech service using a Bicep file and Azure PowerShell or the Azure CLI.

+In this quickstart, learn how to use Azure PowerShell or the Azure CLI to deploy an instance of the MedTech service using a Bicep file.

+* An active Azure subscription account. If you don't have an Azure subscription, see [Subscription decision guide](/azure/cloud-adoption-framework/decision-guides/subscriptions/).

+* **Owner** or **Contributor and User Access Administrator** role assignments in the Azure subscription. For more information, see [What is Azure role-based access control (Azure RBAC)?](../../role-based-access-control/overview.md)

+* The Microsoft.HealthcareApis and Microsoft.EventHub resource providers registered with your Azure subscription. To learn more about registering resource providers, see [Azure resource providers and types](../../azure-resource-manager/management/resource-providers-and-types.md).

+* [Azure PowerShell](/powershell/azure/install-az-ps) and/or the [Azure CLI](/cli/azure/install-azure-cli) installed locally.

+ * For Azure PowerShell, install the [Bicep CLI](../../azure-resource-manager/bicep/install.md#windows) to deploy the Bicep file used in this quickstart.

+## Review the Bicep file (Optional)

+Save the Bicep file locally as *main.bicep*. You need to have the working directory of your Azure PowerShell or the Azure CLI console pointing to the location where this file is saved.

+ > If you're going to allow access from multiple services to the event hub, it is highly recommended that each service has its own event hub consumer group.

+ > * Two MedTech services accessing the same event hub.

+ > * A MedTech service and a storage writer application accessing the same event hub.

+ > * Two MedTech services accessing the same event hub.

+ > * A MedTech service and a storage writer application accessing the same event hub.

+* Azure Event Hubs namespace and device message event hub. In this deployment, the device message event hub is named *devicedata*.

+ * Event hub consumer group. In this deployment, the consumer group is named *$Default*.

+ * **Azure Event Hubs Data Sender** role. In this deployment, the sender role is named *devicedatasender* and can be used to provide access to the device event hub using a shared access signature (SAS). To learn more about authorizing access using a SAS, see [Authorizing access to Event Hubs resources using Shared Access Signatures](../../event-hubs/authorize-access-shared-access-signature.md).

+* Health Data Services workspace.

+* Health Data Services FHIR service.

+* Health Data Services MedTech service with the required [system-assigned managed identity](../../active-directory/managed-identities-azure-resources/overview.md) roles:

+ * For the event hub, the **Azure Events Hubs Data Receiver** role is assigned in the [Access control section (IAM)](../../role-based-access-control/overview.md) of the device message event hub.

+ * For the FHIR service, the **FHIR Data Writer** role is assigned in the [Access control section (IAM)](../../role-based-access-control/overview.md) of the FHIR service.

+> To learn more about the MedTech service resolution types **Create** and **Lookup**, see [Configure the Destination tab](deploy-manual-portal.md#configure-the-destination-tab).

+After you have successfully deployed an instance of the MedTech service, you'll still need to provide conforming and valid device and FHIR destination mappings.

+* To learn about the device mapping, see [Overview of the device mapping](overview-of-device-mapping.md).

+* To learn about the FHIR destination mapping, see [Overview of the FHIR destination mapping](overview-of-fhir-destination-mapping.md).

+> [Choose a deployment method for the MedTech service](deploy-choose-method.md)

+description: Learn about the different methods for deploying the MedTech service.

+* ARM template using the **Deploy to Azure** button

+* ARM template using Azure PowerShell or the Azure CLI

+* Bicep file using Azure PowerShell or the Azure CLI

+* Azure portal

+## Azure portal

+Using the Azure portal allows you to see the details of each deployment step. The Azure portal deployment has many steps, but it provides valuable technical information that may be useful for customizing and troubleshooting your MedTech service.

+To learn more about deploying the MedTech service using the Azure portal, see [Deploy the MedTech service using the Azure portal](deploy-manual-portal.md).

+> If you're going to allow access from multiple services to the event hub, it is highly recommended that each service has its own event hub consumer group.

+> * Two MedTech services accessing the same event hub.

+> * A MedTech service and a storage writer application accessing the same event hub.

+description: Learn how to deploy the MedTech service using an Azure Resource Manager template and Azure PowerShell or the Azure CLI.

+In this quickstart, learn how to use Azure PowerShell or the Azure CLI to deploy an instance of the MedTech service using an Azure Resource Manager template (ARM template).

+* An active Azure subscription account. If you don't have an Azure subscription, see [Subscription decision guide](/azure/cloud-adoption-framework/decision-guides/subscriptions/).

+* **Owner** or **Contributor and User Access Administrator** role assignments in the Azure subscription. For more information, see [What is Azure role-based access control (Azure RBAC)?](../../role-based-access-control/overview.md)

+* The Microsoft.HealthcareApis and Microsoft.EventHub resource providers registered with your Azure subscription. To learn more about registering resource providers, see [Azure resource providers and types](../../azure-resource-manager/management/resource-providers-and-types.md).

+* [Azure PowerShell](/powershell/azure/install-az-ps) and/or the [Azure CLI](/cli/azure/install-azure-cli) installed locally.

+## Review the ARM template (Optional)

+ > If you're going to allow access from multiple services to the event hub, it is highly recommended that each service has its own event hub consumer group.

+ > * Two MedTech services accessing the same event hub.

+ > * A MedTech service and a storage writer application accessing the same event hub.

+ > If you're going to allow access from multiple services to the event hub, it is highly recommended that each service has its own event hub consumer group.

+ > * Two MedTech services accessing the same event hub.

+ > * A MedTech service and a storage writer application accessing the same event hub.

+* Azure Event Hubs namespace and device message event hub. In this deployment, the device message event hub is named *devicedata*.

+ * Event hub consumer group. In this deployment, the consumer group is named *$Default*.

+ * **Azure Event Hubs Data Sender** role. In this deployment, the sender role is named *devicedatasender* and can be used to provide access to the event hub using a shared access signature (SAS). To learn more about authorizing access using a SAS, see [Authorizing access to Event Hubs resources using Shared Access Signatures](../../event-hubs/authorize-access-shared-access-signature.md).

+* Health Data Services workspace.

+* Health Data Services FHIR service.

+* Health Data Services MedTech service with the required [system-assigned managed identity](../../active-directory/managed-identities-azure-resources/overview.md) roles:

+ * For the event hub, the **Azure Events Hubs Data Receiver** role is assigned in the [Access control section (IAM)](../../role-based-access-control/overview.md) of the event hub.

+ * For the FHIR service, the **FHIR Data Writer** role is assigned in the [Access control section (IAM)](../../role-based-access-control/overview.md) of the FHIR service.

+> To learn more about the MedTech service resolution types **Create** and **Lookup**, see [Configure the Destination tab](deploy-manual-portal.md#configure-the-destination-tab).

+After you have successfully deployed an instance of the MedTech service, you'll still need to provide conforming and valid device and FHIR destination mappings.

+ * To learn about the device mapping, see [Overview of the MedTech service device mapping](overview-of-device-mapping.md).

+ * To learn about the FHIR destination mapping, see [Overview of the FHIR destination mapping](overview-of-fhir-destination-mapping.md).

+> [Choose a deployment method for the MedTech service](deploy-choose-method.md)

+ Title: Deploy the MedTech service using the Azure portal - Azure Health Data Services

+description: Learn how to deploy the MedTech service using the Azure portal.

+# Quickstart: Deploy the MedTech service using the Azure portal

+> [!NOTE]

+> [Fast Healthcare Interoperability Resources (FHIR&#174;)](https://www.hl7.org/fhir/) is an open healthcare specification.

+You may prefer to deploy the MedTech service using the Azure portal if you:

+* Need to track every step of the provisioning process.

+* Want to customize or troubleshoot your deployment.

+In this quickstart, the MedTech service deployment using the Azure portal is divided into the following three sections:

+* [Deploy prerequisite resources](#deploy-prerequisite-resources)

+* [Configure and deploy the MedTech service](#configure-and-deploy-the-medtech-service)

+* [Post-deployment](#post-deployment)

+As a prerequisite, you need an Azure subscription and have been granted the proper permissions to deploy Azure resource groups and resources. You can follow all the steps, or skip some if you have an existing environment. Also, you can combine all the steps and complete them in Azure PowerShell, Azure CLI, and REST API scripts.

+> [!TIP]

+> See the MedTech service article, [Choose a deployment method for the MedTech service](deploy-choose-method.md), for a description of the different deployment methods that can help to simply and automate the deployment of the MedTech service.

+## Deploy prerequisite resources

+The first step is to deploy the MedTech service prerequisite resources:

+* Azure resource group.

+* Azure Event Hubs namespace and event hub.

+* Azure Health Data services workspace.

+* Azure Health Data Services FHIR service.

+Once the prerequisite resources are available, deploy:

+

+* Azure Health Data Services MedTech service.

+### Deploy a resource group

+Deploy a [resource group](../../azure-resource-manager/management/manage-resource-groups-portal.md) to contain the prerequisite resources and the MedTech service.

+### Deploy an Event Hubs namespace and event hub

+Deploy an Event Hubs namespace into the resource group. Event Hubs namespaces are logical containers for event hubs. Once the namespace is deployed, you can deploy an event hub, which the MedTech service reads from. For information about deploying Event Hubs namespaces and event hubs, see [Create an event hub using Azure portal](../../event-hubs/event-hubs-create.md).

+### Deploy a workspace

+Deploy a [workspace](../workspace-overview.md) into the resource group. After you create a workspace using the [Azure portal](../healthcare-apis-quickstart.md), a FHIR service and MedTech service can be deployed from the workspace.

+### Deploy a FHIR service

+Deploy a [FHIR service](../fhir/fhir-portal-quickstart.md) into your resource group using your workspace. The MedTech service persists transformed device data into the FHIR service.

+## Configure and deploy the MedTech service

+If you have successfully deployed the prerequisite resources, you're now ready to deploy the MedTech service.

+Before you can deploy the MedTech service, you must complete the following steps:

+### Set up the MedTech service configuration

+Start with these three steps to begin configuring the MedTech service:

+1. Start by going to your Azure Health Data services workspace and select the **Create MedTech service** box.

+2. This step takes you to the **Add MedTech service** button. Select the button.

+3. This step takes you to the **Create MedTech service** page. This page has five tabs you need to fill out:

+* Basics

+* Device mapping

+* Destination mapping

+* Tags (Optional)

+* Review + create

+### Configure the Basics tab

+Follow these four steps to fill in the **Basics** tab configuration:

+1. Enter the **MedTech service name**.

+ The **MedTech service name** is a friendly, unique name for your MedTech service. For this example, we have named the MedTech service *mt-azuredocsdemo*.

+2. Select the **Event Hubs Namespace**.

+ The **Event Hubs Namespace** is the name of the *Event Hubs namespace* that you previously deployed. For this example, we're using *eh-azuredocsdemo* for our MedTech service device messages.

+3. Select the **Events Hubs name**.

+ The **Event Hubs name** is the name of the event hub that you previously deployed within the Event Hubs Namespace. For this example, we're using *devicedata* for our MedTech service device messages.

+4. Select the **Consumer group**.

+ By default, a consumer group named *$Default* is created during the deployment of an event hub. Use this consumer group for your MedTech service deployment.

+ > [!IMPORTANT]

+ > If you're going to allow access from multiple services to the event hub, it is highly recommended that each service has its own event hub consumer group.

+ >

+ > Consumer groups enable multiple consuming applications to have a separate view of the event stream, and to read the stream independently at their own pace and with their own offsets. For more information, see [Consumer groups](../../event-hubs/event-hubs-features.md#consumer-groups).

+ >

+ > Examples:

+ >

+ > * Two MedTech services accessing the same event hub.

+ >

+ > * A MedTech service and a storage writer application accessing the same event hub.

+The **Basics** tab should now look something like this after you've filled it out:

+### Configure the Device mapping tab

+For the purposes of this quickstart, accept the default **Device mapping** and move to the **Destination** tab. The device mapping is addressed in the [Post-deployment](#post-deployment) section of this quickstart.

+### Configure the Destination tab

+Under the **Destination** tab, use these values to enter the destination properties for your MedTech service instance:

+* First, select the name of your **FHIR server**.

+* Next, enter the **Destination name**.

+ The **Destination name** is a friendly name for the destination. Enter a unique name for your destination. In this example, the **Destination name** is

+ *fs-azuredocsdemo*.

+* Next, select the **Resolution type**.

+ **Resolution type** specifies how MedTech service associates device data with FHIR Device resources and FHIR Patient resources. MedTech reads device and patient resources from the FHIR service using [device identifiers](https://www.hl7.org/fhir/device-definitions.html#Device.identifier) and [patient identifiers](https://www.hl7.org/fhir/patient-definitions.html#Patient.identifier).

+ Device and Patient resources can be resolved by choosing a **Resolution type** of **Create** and **Lookup**:

+ - **Create**

+ If **Create** was selected, and device or patient resources are missing when you're reading data, new resources are created using the identifiers included in the device message.

+ - **Lookup**

+

+ If **Lookup** was selected, and device or patient resources are missing, an error occurs, and the data isn't processed. The errors **DeviceNotFoundException** and/or a **PatientNotFoundException** error is generated, depending on the type of resource not found.

+ * For the **Destination mapping** field, accept the default **Destination mapping**. The FHIR destination mapping is addressed in the [Post-deployment](#post-deployment) section of this quickstart.

+The **Destination** tab should now look something like this after you've filled it out:

+### Configure the Tags tab (Optional)

+Before you complete your configuration in the **Review + create** tab, you may want to configure tags. You can do this step by selecting the **Next: Tags >** tab.

+Tags are name and value pairs used for categorizing resources and are an optional step. For more information about tags, see [Use tags to organize your Azure resources and management hierarchy](../../azure-resource-manager/management/tag-resources.md).

+### Validate your deployment

+To begin the validation process of your MedTech service deployment, select the **Review + create** tab. There's a short delay and then you should see a screen that displays a **Validation success** message.

+Your validation screen should look something like this:

+If your deployment didn't validate, review the validation failure message(s), and troubleshoot the issue(s). Check all properties under each MedTech service tab that you've configured and then try the validation process again.

+### Create deployment

+1. Select the **Create** button to begin the deployment.

+2. The deployment process may take several minutes. The screen displays a message saying that your deployment is in progress.

+3. When Azure has finishes deploying, a "Your Deployment is complete" message appears and also displays the following information:

+* Deployment name

+* Subscription

+* Resource group

+* Deployment details

+Your screen should look something like this:

+## Post-deployment

+### Grant resource access to the MedTech service system-managed identity

+There are two post-deployment access steps you must perform or the MedTech service can't read data from the event hub or write data to the FHIR service.

+These steps are:

+* Grant the MedTech service system-managed identity **Azure Event Hubs Data Receiver** access to the [event hub](../../event-hubs/authorize-access-azure-active-directory.md).

+* Grant the MedTech service system-managed identity **FHIR Data Writer** access to the [FHIR service](../configure-azure-rbac.md).

+These two steps are needed because MedTech service uses [Azure role-based access control (Azure RBAC)](../../role-based-access-control/overview.md) and a [system-assigned managed identity](../../active-directory/managed-identities-azure-resources/overview.md) for extra security and access control of your Azure resources.

+### Provide device and FHIR destination mappings

+Valid and conforming device and FHIR destination mappings have to be provided to your MedTech service for it to be fully functional. For an overview and sample device and FHIR destination mappings, see:

+* [Overview of the MedTech service device mapping](overview-of-device-mapping.md).

+* [Overview of the MedTech service FHIR destination mapping](overview-of-fhir-destination-mapping.md).

+> [!TIP]

+> You can use the MedTech service [Mapping debugger](how-to-use-mapping-debugger.md) for assistance creating, updating, and troubleshooting the MedTech service device and FHIR destination mappings. The Mapping debugger enables you to easily view and make inline adjustments in real-time, without ever having to leave the Azure portal. The Mapping debugger can also be used for uploading test device messages to see how they'll look after being processed into normalized messages and transformed into FHIR Observations.

+## Next steps

+This article described the deployment steps needed to get started using the MedTech service.

+To learn about other methods of deploying the MedTech service, see

+> [!div class="nextstepaction"]

+> [Choose a deployment method for the MedTech service](deploy-new-choose.md)

+For an overview of the MedTech service device data processing stages, see

+> [!div class="nextstepaction"]

+> [Overview of the MedTech service device data processing stages](overview-of-device-data-processing-stages.md)

+For frequently asked questions (FAQs) about the MedTech service, see

+> [!div class="nextstepaction"]

+> [Frequently asked questions about the MedTech service](frequently-asked-questions.md)

+description: Learn how to deploy Azure IoT Hub with message routing to send device messages to the MedTech service. The tutorial uses an Azure Resource Manager template and Visual Studio Code with the Azure IoT Hub extension.

+- **Owner** or **Contributor and User Access Administrator** role assignments in the Azure subscription. For more information, see [What is Azure role-based access control (Azure RBAC)?](../../role-based-access-control/overview.md)

+- The Microsoft.HealthcareApis, Microsoft.EventHub, and Microsoft.Devices resource providers registered with your Azure subscription. To learn more, see [Azure resource providers and types](../../azure-resource-manager/management/resource-providers-and-types.md).

+ > If you're going to allow access from multiple services to the event hub, it's required that each service has its own event hub consumer group.

+ > * Two MedTech services accessing the same event hub.

+ > * A MedTech service and a storage writer application accessing the same event hub.

+* Event Hubs namespace and event hub. In this deployment, the event hub is named *devicedata*.

+ * Event hub consumer group. In this deployment, the consumer group is named *$Default*.

+ * **Azure Event Hubs Data Sender** role. In this deployment, the sender role is named *devicedatasender* and can be used to provide access to the event hub using a shared access signature (SAS). To learn more about authorizing access using a SAS, see [Authorizing access to Event Hubs resources using Shared Access Signatures](../../event-hubs/authorize-access-shared-access-signature.md). The **Azure Event Hubs Data Sender** role isn't used in this tutorial.

+* IoT hub with [message routing](../../iot-hub/iot-hub-devguide-messages-d2c.md) configured to send device messages to the event hub.

+* [User-assigned managed identity](../../active-directory/managed-identities-azure-resources/overview.md), which provides send access from the IoT hub to the event hub. The managed identity has the **Azure Event Hubs Data Sender** role in the [Access control section (IAM)](../../role-based-access-control/overview.md) of the event hub.

+* Health Data Services workspace.

+* Health Data Services FHIR service.

+* Health Data Services MedTech service with the required [system-assigned managed identity](../../active-directory/managed-identities-azure-resources/overview.md) roles:

+ * For the event hub, the **Azure Event Hubs Data Receiver** role is assigned in the [Access control section (IAM)](../../role-based-access-control/overview.md) of the event hub.

+ * For the FHIR service, the **FHIR Data Writer** role is assigned in the [Access control section (IAM)](../../role-based-access-control/overview.md) of the FHIR service.

+* Conforming and valid MedTech service [device](overview-of-device-mapping.md) and [FHIR destination mappings](overview-of-fhir-destination-mapping.md). **Resolution type** is set to **Create**.

+> To learn about the MedTech service resolution types **Create** and **Lookup**, see [Configure the Destination tab](deploy-manual-portal.md#configure-the-destination-tab).

+ > `patientIdExpression` is only required for MedTech services in the **Create** mode, however, if **Lookup** is being used, a Device resource with a matching Device Identifier must exist in the FHIR service. This example assumes your MedTech service is in a **Create** mode. The **Resolution type** for this tutorial set to **Create**. For more information on the **Destination properties**: **Create** and **Lookup**, see [Configure the Destination tab](deploy-manual-portal.md#configure-the-destination-tab).

+After you obtain the required subscription prerequisites, the first step is to deploy the MedTech service prerequisite resources:

+If you have successfully deployed the prerequisite resources, you're now ready to deploy the [MedTech service](deploy-manual-prerequisites.md) using your workspace.

+This article described the basic steps needed to get started deploying the MedTech service.

+> The `values[].valueName, values[].valueExpression`, and `values[].required` elements are only required if you have a value entry in the array. It's valid to have no values mapped. These elements are used when the telemetry being sent is an event.

+The FHIR destination mapping controls how the normalized data extracted from a device message is mapped into a FHIR Observation.

+* Should an observation be created for a point in time or over a period of an hour?

+* What codes should be added to the observation?

+* Should the value be represented as [SampledData](https://www.hl7.org/fhir/datatypes.html#SampledData) or a [Quantity](https://www.hl7.org/fhir/datatypes.html#Quantity)?

+CodeValueFhir is currently the only template supported in FHIR destination mapping. It allows you to define codes, the effective period, and the value of the observation. Multiple value types are supported: [SampledData](https://www.hl7.org/fhir/datatypes.html#SampledData), [CodeableConcept](https://www.hl7.org/fhir/datatypes.html#CodeableConcept), [Quantity](https://www.hl7.org/fhir/datatypes.html#Quantity), and [string](https://www.hl7.org/fhir/datatypes.html#string). Along with these configurable values, the identifier for the Observation resource and linking to the proper Device and Patient resources are handled automatically.

+|Element|Description|Required|

+|:|:-|:-|

+|**typeName**| The type of measurement this template should bind to. There should be at least one device mapping template that has this same `typeName`.|TBD|

+|**periodInterval**|The period of time the observation created should represent. Supported values are 0 (an instance), 60 (an hour), 1440 (a day).|TBD Note: `periodInterval` is required when the Observation type is "SampledData" and is ignored for any other Observation types.|

+|**category**|Any number of [CodeableConcepts](http://hl7.org/fhir/datatypes-definitions.html#codeableconcept) to classify the type of observation created.|TBD|

+|**codes**|One or more [Codings](http://hl7.org/fhir/datatypes-definitions.html#coding) to apply to the observation created.|TBD|

+|**codes[].code**|The code for a [Coding](http://hl7.org/fhir/datatypes-definitions.html#coding) in the `codes` property.|TBD|

+|**codes[].system**|The system for the [Coding](http://hl7.org/fhir/datatypes-definitions.html#coding).|TBD|

+|**codes[].display**|The display for the [Coding](http://hl7.org/fhir/datatypes-definitions.html#coding).|TBD|

+|**value**|The value to extract and represent in the observation. For more information, see [Value types](#value-types).|TBD|

+|**components**|*Optional:* One or more components to create on the observation.|TBD|

+|**components[].codes**|One or more [Codings](http://hl7.org/fhir/datatypes-definitions.html#coding) to apply to the component.|TBD|

+|**components[].value**|The value to extract and represent in the component. For more information, see [Value types](#value-types).|TBD|

+### Value types

+All CodeValueFhir templates' `value` element contains these elements:

+|Element|Description|Required|

+|:|:-|:-|

+|**valueType**|Type of the value. This value would be "SampledData", "Quantity", "CodeableConcept", or "string" depending on the value type.|TBD|

+|**valueName**|Name of the value.|TBD|

+These value types are supported in the MedTech service FHIR destination mapping:

+#### SampledData

+Represents the [SampledData](http://hl7.org/fhir/datatypes.html#SampledData) FHIR data type. Observation measurements are written to a value stream starting at a point in time and incrementing forward using the period defined. If no value is present, an `E` is written into the data stream. If the period is such that two or more values occupy the same position in the data stream, the latest value is used. The same logic is applied when an observation using the SampledData is updated. For a CodeValueFhir template with the SampleData value type, the template's `value` element contains the following elements:

+|Element|Description|Required|

+|:|:-|:-|

+|**defaultPeriod**|The default period in milliseconds to use.|TBD|

+|**unit**|The unit to set on the origin of the SampledData. |TBD|

+#### Quantity

+Represents the [Quantity](http://hl7.org/fhir/datatypes.html#Quantity) FHIR data type. This type creates a single, point in time, Observation. If a new value arrives that contains the same device identifier, measurement type, and timestamp, the previous Observation is updated to the new value. For a CodeValueFhir template with the Quantity value type, the template's `value` element contains the following elements:

+|Element|Description|Required|

+|:|:-|:-|

+|**unit**|Unit representation.|TBD|

+|**code**|Coded form of the unit.|TBD|

+|**system**|System that defines the coded unit form.|TBD|

+#### CodeableConcept

+Represents the [CodeableConcept](http://hl7.org/fhir/datatypes.html#CodeableConcept) FHIR data type. The value in the normalized data model isn't used, and instead when this type of data is received, an Observation is created with a specific code representing that an observation was recorded at a specific point in time. For a CodeValueFhir template with the CodeableConcept value type, the template's `value` element contains the following elements:

+|Element|Description|Required|

+|:|:-|:-|

+|**text**|Plain text representation.|TBD|

+|**codes**|One or more [Codings](http://hl7.org/fhir/datatypes-definitions.html#coding) to apply to the observation created.|TBD|

+|**codes[].code**|The code for a [Coding](http://hl7.org/fhir/datatypes-definitions.html#coding) in the `codes` property.|TBD|

+|**codes[].system**|The system for a [Coding](http://hl7.org/fhir/datatypes-definitions.html#coding) in the `codes` property.|TBD|

+|**codes[].display**|The display for a [Coding](http://hl7.org/fhir/datatypes-definitions.html#coding) in the `codes` property.|TBD|

+#### String

+Represents the [string](https://www.hl7.org/fhir/datatypes.html#string) FHIR data type. This type creates a single, point in time, Observation. If new a value arrives that contains the same device identifier, measurement type, and timestamp, the previous Observation is updated to the new value. No other elements are defined.

+This article shows how to get started quickly with Azure IoT device development. As a prerequisite, see the introductory articles [What is Azure IoT device and application development?](about-iot-develop.md) and [Overview of Azure IoT Device SDKs](about-iot-sdks.md). These articles summarize key development options, tools, and SDKs available to device developers.

+In this article, you can select from a set of device quickstarts to get started with hands-on development.

+See the following articles to start using the Azure IoT device SDKs to connect general, microprocessor unit (MPU) devices to Azure IoT. Examples of general MPU devices with larger compute and memory resources include PCs, servers, Raspberry Pi devices, and smartphones. The following quickstarts all provide device simulators and don't require you to have a physical device.

+See the following articles to start using the Azure IoT embedded device SDKs to connect embedded, resource-constrained microcontroller unit (MCU) devices to Azure IoT. Examples of constrained MCU devices with compute and memory limitations, include sensors, and special purpose hardware modules or boards. The following quickstarts require you to have the listed MCU devices.

+Azure IoT is a collection of managed and platform services that connect, monitor, and control your IoT devices. Azure IoT offers developers a comprehensive set of options. Your options include device platforms, supporting cloud services, SDKs, MQTT support, and tools for building device-enabled cloud applications.

+* **Embedded device development:** Describes development targeting resource constrained devices. Often you use a resource-constrained device to reduce per unit costs, power consumption, or device size. These devices have direct control over the hardware platform they execute on.

+Rather than develop constrained devices at scale, device application developers focus on enabling a specific IoT scenario required by their cloud solution. Some developers also work on constrained devices for their cloud solution. For developers working with resource constrained devices, see the [Embedded Device Development](#embedded-device-development) path.

+The current embedded SDKs target the **C** language. The embedded SDKs provide either no operating system, or Azure RTOS support. They're designed with embedded targets in mind. The design considerations include the need for a minimal footprint, and a nonmemory allocating design.

+As an Azure IoT device developer, you have a diverse set of SDKs, protocols and tools to help build device-enabled cloud applications.

+There are two main options to connect devices and communicate with IoT Hub:

+- **Use the Azure IoT SDKs**. In most cases, we recommend that you use the Azure IoT SDKs versus using MQTT directly. The SDKs streamline your development effort and simplify the complexity of connecting and managing devices. IoT Hub supports the [MQTT v3.1.1](https://mqtt.org/) protocol, and the IoT SDKs simplify the process of using MQTT to communicate with IoT Hub.

+- **Use the MQTT protocol directly**. There are some advantages of building an IoT Hub solution to use MQTT directly. For example, a solution that uses MQTT directly without the SDKs can be built on the open MQTT standard. A standards-based approach makes the solution more portable, and gives you more control over how devices connect and communicate. However, IoT Hub isn't a full-featured MQTT broker and doesn't support all behaviors specified in the MQTT v3.1.1 standard. The partial support for MQTT v3.1.1 adds development cost and complexity. Device developers should weigh the trade-offs of using the IoT device SDKs versus using MQTT directly. For more information, see [Communicate with an IoT hub using the MQTT protocol](../iot/iot-mqtt-connect-to-iot-hub.md).

+- [Azure IoT Hub](../iot-hub/about-iot-hub.md). Use Iot Hub to host IoT applications and connect devices. IoT Hub is a platform-as-a-service (PaaS) application that acts as a central message hub for bi-directional communication between IoT applications and connected devices. IoT Hub can scale to support millions of devices. Compared to other Azure IoT services, IoT Hub offers the greatest control and customization over your application design. It also offers the most developer tool options for working with the service, at the cost of some increase in development and management complexity.

+> [!NOTE]

+> [Standard support for Ubuntu 18.04 LTS ends on May 31st, 2023](https://ubuntu.com/blog/18-04-end-of-standard-support). Beginning June 2023, Ubuntu 18.04 LTS won't be an IoT Edge *tier 1* supported platform. Ubuntu 18.04 LTS IoT Edge packages are available until Nov 30th, 2023. IoT Edge system modules Edge Agent and Edge Hub aren't impacted. If you take no action, Ubuntu 18.04 LTS based IoT Edge devices continue to work but ongoing security patches and bug fixes in the host packages for Ubuntu 18.04 won't be available after Nov 30th, 2023. To continue to receive support and security updates, we recommend that you update your host OS to a *tier 1* supported platform. For more information, see the [Update your IoT Edge devices on Ubuntu 18.04 LTS announcement](https://azure.microsoft.com/updates/update-ubuntu-1804/).

+| [RHEL 7](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7) |  |  |  |

+If your goal is to store configuration for an ASP.NET Core app in an Azure Key Vault, see [Azure Key Vault configuration provider in ASP.NET Core](/aspnet/core/security/key-vault-configuration).

+ Title: Debug pipeline reuse issues in Azure Machine Learning

+description: Learn how reuse works in pipeline and how to debug reuse issues