+- [Secure an Azure API Management API with Azure AD B2C](secure-api-management.md)

+- Learn how to [customize and enhance the Azure AD B2C authentication experience for your web app](enable-authentication-in-node-web-app-options.md)

+[Connect-AzureAD]: /powershell/module/azuread/connect-azuread

+Create an Azure AD service principal using the [New-AzureADServicePrincipal][New-AzureADServicePrincipal] cmdlet for Azure AD DS to communicate and authenticate itself. A specific application ID is used named *Domain Controller Services* with an ID of *2565bd9d-da50-47d4-8b85-4c97f669dc36* for Azure Global. For other Azure clouds, search for AppId value *6ba9a5d4-8456-4118-b521-9c5ca10cdf84*.

+New-AzureADServicePrincipal -AppId "2565bd9d-da50-47d4-8b85-4c97f669dc36"

+During preview, you currently need *Global Administrator* permissions to enable sign-in with email as an alternate login ID. You can use either Azure portal or Graph PowerShell to set up the feature.

+You need *Global Administrator* privileges to complete the following steps:

+ The **Conditional Access** tab of the event details shows you which policy triggered the MFA prompt.

+### Manage methods using PowerShell

+Authentication methods can also be managed using Microsoft Graph APIs. For more information, see [Authentication and authorization basics](/graph/auth/auth-concepts).

+ |`https://autoupdate.msappproxaxy.net` | Azure AD Password Protection auto-upgrade functionality |

+* If necessary, you can remove the proxy service by using **Add or remove programs**. No manual cleanup of the state that the proxy service maintains is needed.

+> To see a list of claims available from the account object, refer to the [ID token claims reference](./id-token-claims-reference.md).

+ Title: ID token claims reference

+description: Learn the details of the claims included in ID tokens issued by the Microsoft identity platform.

+# ID token claims reference

+ID tokens are [JSON web tokens (JWT)](https://wikipedia.org/wiki/JSON_Web_Token). The v1.0 and v2.0 ID tokens have differences in the information they carry. The version is based on the endpoint from where it was requested. While existing applications likely use the Azure AD v1.0 endpoint, new applications should use the v2.0 endpoint.

+* v1.0: `https://login.microsoftonline.com/common/oauth2/authorize`

+* v2.0: `https://login.microsoftonline.com/common/oauth2/v2.0/authorize`

+All JWT claims listed in the following sections appear in both v1.0 and v2.0 tokens unless stated otherwise. ID tokens consist of a header, payload, and signature. The header and signature are used to verify the authenticity of the token, while the payload contains the information about the user requested by your client.

+## Header claims

+The following table shows header claims present in ID tokens.

+|Claim | Format | Description |

+||--|-|

+| `typ` | String - always "JWT" | Indicates that the token is a JWT token. |

+| `alg` | String | Indicates the algorithm that was used to sign the token. For example: "RS256" |

+| `kid` | String | Specifies the thumbprint for the public key that can be used to validate the token's signature. Emitted in both v1.0 and v2.0 ID tokens. |

+| `x5t` | String | Functions the same (in use and value) as `kid`. `x5t` is a legacy claim emitted only in v1.0 ID tokens for compatibility purposes. |

+## Payload claims

+The following table shows the claims that are in most ID tokens by default (except where noted). However, your app can use [optional claims](active-directory-optional-claims.md) to request more claims in the ID token. Optional claims can range from the `groups` claim to information about the user's name.

+| Claim | Format | Description |

+|-|--|-|

+|`aud` | String, an App ID GUID | Identifies the intended recipient of the token. In `id_tokens`, the audience is your app's Application ID, assigned to your app in the Azure portal. This value should be validated. The token should be rejected if it fails to match your app's Application ID. |

+|`iss` | String, an issuer URI | Identifies the issuer, or "authorization server" that constructs and returns the token. It also identifies the tenant for which the user was authenticated. If the token was issued by the v2.0 endpoint, the URI ends in `/v2.0`. The GUID that indicates that the user is a consumer user from a Microsoft account is `9188040d-6c67-4c5b-b112-36a304b66dad`. Your app should use the GUID portion of the claim to restrict the set of tenants that can sign in to the app, if applicable. |

+|`iat` | int, a Unix timestamp | Indicates when the authentication for the token occurred. |

+|`idp`| String, usually an STS URI | Records the identity provider that authenticated the subject of the token. This value is identical to the value of the issuer claim unless the user account isn't in the same tenant as the issuer - guests, for instance. If the claim isn't present, it means that the value of `iss` can be used instead. For personal accounts being used in an organizational context (for instance, a personal account invited to a tenant), the `idp` claim may be 'live.com' or an STS URI containing the Microsoft account tenant `9188040d-6c67-4c5b-b112-36a304b66dad`. |

+|`nbf` | int, a Unix timestamp | Identifies the time before which the JWT can't be accepted for processing. |

+|`exp` | int, a Unix timestamp | Identifies the expiration time on or after which the JWT can't be accepted for processing. In certain circumstances, a resource may reject the token before this time. For example, if a change in authentication is required or a token revocation has been detected. |

+| `c_hash`| String | The code hash is included in ID tokens only when the ID token is issued with an OAuth 2.0 authorization code. It can be used to validate the authenticity of an authorization code. To understand how to do this validation, see the [OpenID Connect specification](https://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken). |

+| `at_hash` | String | The access token hash is included in ID tokens only when the ID token is issued from the `/authorize` endpoint with an OAuth 2.0 access token. It can be used to validate the authenticity of an access token. To understand how to do this validation, see the [OpenID Connect specification](https://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken). This claim isn't returned on ID tokens from the `/token` endpoint. |

+| `aio` | Opaque String | An internal claim that's used to record data for token reuse. Should be ignored. |

+| `preferred_username` | String | The primary username that represents the user. It could be an email address, phone number, or a generic username without a specified format. Its value is mutable and might change over time. Since it's mutable, this value can't be used to make authorization decisions. It can be used for username hints and in human-readable UI as a username. The `profile` scope is required to receive this claim. Present only in v2.0 tokens. |

+| `email` | String | Present by default for guest accounts that have an email address. Your app can request the email claim for managed users (from the same tenant as the resource) using the `email` [optional claim](active-directory-optional-claims.md). This value isn't guaranteed to be correct and is mutable over time. Never use it for authorization or to save data for a user. If you require an addressable email address in your app, request this data from the user directly by using this claim as a suggestion or prefill in your UX. On the v2.0 endpoint, your app can also request the `email` OpenID Connect scope - you don't need to request both the optional claim and the scope to get the claim. |

+| `name` | String | The `name` claim provides a human-readable value that identifies the subject of the token. The value isn't guaranteed to be unique, it can be changed, and should be used only for display purposes. The `profile` scope is required to receive this claim. |

+| `nonce` | String | The nonce matches the parameter included in the original authorize request to the IDP. If it doesn't match, your application should reject the token. |

+| `oid` | String, a GUID | The immutable identifier for an object, in this case, a user account. This ID uniquely identifies the user across applications - two different applications signing in the same user receives the same value in the `oid` claim. Microsoft Graph returns this ID as the `id` property for a user account. Because the `oid` allows multiple apps to correlate users, the `profile` scope is required to receive this claim. If a single user exists in multiple tenants, the user contains a different object ID in each tenant - they're considered different accounts, even though the user logs into each account with the same credentials. The `oid` claim is a GUID and can't be reused. |

+| `roles` | Array of strings | The set of roles that were assigned to the user who is logging in. |

+| `rh` | Opaque String | An internal claim used to revalidate tokens. Should be ignored. |

+| `sub` | String | The subject of the information in the token. For example, the user of an app. This value is immutable and can't be reassigned or reused. The subject is a pairwise identifier and is unique to an application ID. If a single user signs into two different apps using two different client IDs, those apps receive two different values for the subject claim. You may or may not want two values depending on your architecture and privacy requirements. |

+| `tid` | String, a GUID | Represents the tenant that the user is signing in to. For work and school accounts, the GUID is the immutable tenant ID of the organization that the user is signing in to. For sign-ins to the personal Microsoft account tenant (services like Xbox, Teams for Life, or Outlook), the value is `9188040d-6c67-4c5b-b112-36a304b66dad`.|

+| `unique_name` | String | Only present in v1.0 tokens. Provides a human readable value that identifies the subject of the token. This value isn't guaranteed to be unique within a tenant and should be used only for display purposes. |

+| `uti` | String | Token identifier claim, equivalent to `jti` in the JWT specification. Unique, per-token identifier that is case-sensitive. |

+| `ver` | String, either 1.0 or 2.0 | Indicates the version of the ID token. |

+| `hasgroups` | Boolean | If present, always true, denoting the user is in at least one group. Used in place of the groups claim for JWTs in implicit grant flows when the full groups claim extends the URI fragment beyond the URL length limits (currently six or more groups). Indicates that the client should use the Microsoft Graph API to determine the user's groups (`https://graph.microsoft.com/v1.0/users/{userID}/getMemberObjects`). |

+| `groups:src1` | JSON object | For token requests that aren't limited in length (see `hasgroups`) but still too large for the token, a link to the full groups list for the user is included. For JWTs as a distributed claim, for SAML as a new claim in place of the `groups` claim. <br><br>**Example JWT Value**: <br> `"groups":"src1"` <br> `"_claim_sources`: `"src1" : { "endpoint" : "https://graph.microsoft.com/v1.0/users/{userID}/getMemberObjects" }`<br><br> For more info, see [Groups overage claim](#groups-overage-claim).|

+## Use claims to reliably identify a user

+When identifying a user, it's critical to use information that remains constant and unique across time. Legacy applications sometimes use fields like the email address, phone number, or UPN. All of these fields can change over time, and can also be reused over time. For example, when an employee changes their name, or an employee is given an email address that matches that of a previous, no longer present employee. Your application mustn't use human-readable data to identify a user - human readable generally means someone can read it, and want to change it. Instead, use the claims provided by the OIDC standard, or the extension claims provided by Microsoft - the `sub` and `oid` claims.

+To correctly store information per-user, use `sub` or `oid` alone (which as GUIDs are unique), with `tid` used for routing or sharding if needed. If you need to share data across services, `oid` and `tid` is best as all apps get the same `oid` and `tid` claims for a user acting in a tenant. The `sub` claim is a pair-wise value that's unique. The value is based on a combination of the token recipient, tenant, and user. Two apps that request ID tokens for a user receive different `sub` claims, but the same `oid` claims for that user.

+>[!NOTE]

+> Don't use the `idp` claim to store information about a user in an attempt to correlate users across tenants. It doesn't work, as the `oid` and `sub` claims for a user change across tenants, by design, to ensure that applications can't track users across tenants.

+Guest scenarios, where a user is homed in one tenant, and authenticates in another, should treat the user as if they're a brand new user to the service. Your documents and privileges in one tenant shouldn't apply in another tenant. This restriction is important to prevent accidental data leakage across tenants, and enforcement of data lifecycles. Evicting a guest from a tenant should also remove their access to the data they created in that tenant.

+## Groups overage claim

+To ensure that the token size doesn't exceed HTTP header size limits, the number of object IDs that it includes in the `groups` claim is limited. If a user is a member of more groups than the overage limit (150 for SAML tokens, 200 for JWT tokens), the groups claim isn't included in the token. Instead, it includes an overage claim in the token that indicates to the application to query the Microsoft Graph API to retrieve the user's group membership.

+```json

+{

+ ...

+ "_claim_names": {

+ "groups": "src1"

+ },

+ {

+ "_claim_sources": {

+ "src1": {

+ "endpoint":"[Url to get this user's group membership from]"

+ }

+ }

+ }

+ ...

+}

+```

+## Next steps

+- Learn more about the [ID tokens used in Azure AD](id-tokens.md).

+ Title: ID tokens in the Microsoft identity platform

+description: Learn about ID tokens used in the Microsoft identity platform.

+# ID tokens in the Microsoft identity platform

+The authorization server issues ID tokens that contain claims that carry information about the user. They can be sent alongside or instead of an access token. Information in ID tokens enables the client to verify that a user is who they claim to be.

+Third-party applications are intended to understand ID tokens. ID tokens shouldn't be used for authorization purposes. Access tokens are used for authorization. The claims provided by ID tokens can be used for UX inside your application, as keys in a database, and providing access to the client application. For more information about the claims used in an ID token, see the [ID token claims reference](id-token-claims-reference.md).

+## Token formats

+There are two versions of ID tokens available in the Microsoft identity platform: v1.0 and v2.0. These versions determine the claims that are in the token. The v1.0 and v2.0 ID tokens have differences in the information they carry. The version is based on the endpoint from where it was requested. New applications should use the v2.0.

+* v1.0: `https://login.microsoftonline.com/common/oauth2/authorize`

+* v2.0: `https://login.microsoftonline.com/common/oauth2/v2.0/authorize`

+## Token lifetime

+You can adjust the lifetime of an ID token to control how often the client application expires the application session, and how often it requires the user to authenticate again either silently or interactively. For more information, read [Configurable token lifetimes](configurable-token-lifetimes.md).

+## Validate tokens

+To validate an ID token, your client can check whether the token has been tampered with. It can also validate the issuer to ensure that the correct issuer has sent back the token. Because ID tokens are always a JWT token, many libraries exist to validate these tokens - you should use one of these libraries rather than doing it yourself. Only confidential clients should validate ID tokens. For more information, see [Secure applications and APIs by validating claims](claims-validation.md).

+Public applications (code running entirely on a device or network you don't control such as a user's browser or their home network) don't benefit from validating the ID token. In this instance, a malicious user can intercept and edit the keys used for validation of the token.

+The following JWT claims should be validated in the ID token after validating the signature on the token. Your token validation library may also validate the following claims:

+* Nonce: the `nonce` claim in the payload must match the nonce parameter passed into the `/authorize` endpoint during the initial request.

+## See also

+* [ID token claims reference](id-token-claims-reference.md)

+* [OAuth 2.0 and OpenID Connect protocols](active-directory-v2-protocols.md)

+* [Optional claims](active-directory-optional-claims.md)

+* Review the [OpenID Connect](v2-protocols-oidc.md) flow, which defines the protocols that emit an ID token.

+For the federated case, see [Configure Azure Active Directory sign in behavior for an application by using a Home Realm Discovery policy](../manage-apps/configure-authentication-for-federated-users-portal.md)

+Learn more about [building a single-page application (SPA)](scenario-spa-overview.md) using MSAL.js.

+For more code samples, refer to [Microsoft identity platform code samples](sample-v2-code.md).

+For more code samples, refer to [Microsoft identity platform code samples](sample-v2-code.md).

+For more code samples, refer to [Microsoft identity platform code samples](sample-v2-code.md).

+For the federated case, see [Configure Azure Active Directory sign in behavior for an application by using a Home Realm Discovery policy](../manage-apps/configure-authentication-for-federated-users-portal.md)

+- [token cache serialization in MSAL.NET](msal-net-token-cache-serialization.md)

+For more information and code examples, see [Choosing between an embedded web browser and a system browser on Xamarin Android](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/MSAL.NET-uses-web-browser#choosing-between-embedded-web-browser-or-system-browser-on-xamarinandroid) and [Embedded versus system web UI](msal-net-web-browsers.md#embedded-vs-system-web-ui).

+[Acquire a token for the desktop app](scenario-desktop-acquire-token.md).

+[Web app that calls web APIs](scenario-web-app-call-api-overview.md).

+>

+- [.NET 7 SDK](https://dotnet.microsoft.com/download/dotnet/7.0)

+- [.NET Framework 4.8](https://dotnet.microsoft.com/download/dotnet-framework/net48)

+1. In the **Project name** box, enter a name like _Win-App-calling-MsGraph_.

+> [!div class="nextstepaction"]

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

+In addition to validating ID token's signature, you should validate several of its claims as described in [Validating an ID token](id-tokens.md#validate-tokens). Also see [Important information about signing key-rollover](active-directory-signing-key-rollover.md).

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

+When you have an authorization code and an ID token, you can sign the user in and get access tokens on their behalf. To sign the user in, you must validate the ID token as described in the [validate tokens](id-tokens.md#validate-tokens). To get access tokens, follow the steps described in [OAuth code flow documentation](v2-oauth2-auth-code-flow.md#redeem-a-code-for-an-access-token).

+>

+>

+## May 2023

+### New articles

+- [Access token claims reference](access-token-claims-reference.md)

+- [Directory extension attributes in claims](schema-extensions.md)

+- [Provide optional claims to your app](optional-claims.md)

+### Updated articles

+- [Application and service principal objects in Azure Active Directory](app-objects-and-service-principals.md)

+- [What's new for authentication?](reference-breaking-changes.md)

+- [A web app that calls web APIs: Acquire a token for the app](scenario-web-app-call-api-acquire-token.md)

+- [A web app that calls web APIs: Code configuration](scenario-web-app-call-api-app-configuration.md)

+- [A web app that calls web APIs: Call a web API](scenario-web-app-call-api-call-api.md)

+- [A web API that calls web APIs: Acquire a token for the app](scenario-web-api-call-api-acquire-token.md)

+- [A web API that calls web APIs: Code configuration](scenario-web-api-call-api-app-configuration.md)

+- [A web API that calls web APIs: Call an API](scenario-web-api-call-api-call-api.md)

+- [Confidential client assertions](msal-net-client-assertions.md)

+- [Customize claims issued in the JSON web token (JWT) for enterprise applications (Preview)](jwt-claims-customization.md)

+- [Customize claims issued in the SAML token for enterprise applications](saml-claims-customization.md)

+- [Desktop app that calls web APIs: Acquire a token by using WAM](scenario-desktop-acquire-token-wam.md)

+- [Desktop app that calls web APIs: Acquire a token interactively](scenario-desktop-acquire-token-interactive.md)

+- [Handle errors and exceptions in MSAL for Python](msal-error-handling-python.md)

+- [Protected web API: Code configuration](scenario-protected-web-api-app-configuration.md)

+- [Shared device mode for iOS devices](msal-ios-shared-devices.md)

+- [Tutorial: Sign in users and call the Microsoft Graph API from an Android application](tutorial-v2-android.md)

+- [Tutorial: Sign in users and call the Microsoft Graph API from an Angular single-page application (SPA) using auth code flow](tutorial-v2-angular-auth-code.md)

+- [Web app that signs in users: Code configuration](scenario-web-app-sign-user-app-configuration.md)

+| **Authentication methods and identity providers** | - Azure AD accounts </br>- Microsoft accounts </br>- Email one-time passcode </br>- Google federation</br>- Facebook federation</br>- SAML/WS-Fed federation | - Local account (Email and password) </br>- Email one-time passcode </br>- Google federation</br>- Facebook federation|

+

+

+

+Get started with the [Authentication management checks and actions](ops-guide-auth.md).

+- **[Authentication management](ops-guide-auth.md)** - ability to manage credentials, define authentication experience, delegate assignment, measure usage, and define access policies based on enterprise security posture.

+- **[Governance](ops-guide-govern.md)** - ability to assess and attest the access granted non-privileged and privileged identities, audit, and control changes to the environment.

+

+

+The Active Directory administrative tier model was designed to protect identity systems using a set of buffer zones between full control of the Environment (Tier 0) and the high-risk workstation assets that attackers frequently compromise.

+

+To learn the differences between Active Directory and Azure Active Directory, see [Compare Active Directory to Azure Active Directory](compare.md). You can also refer [Microsoft Cloud for Enterprise Architects Series](/microsoft-365/solutions/cloud-architecture-models) posters to better understand the core identity services in Azure like Azure AD and Microsoft-365.

+ Title: Compare Active Directory to Azure Active Directory

+description: This document compares Active Directory Domain Services (ADDS) to Azure Active Directory (AD). It outlines key concepts in both identity solutions and explains how it's different or similar.

+tags: azuread

+# Compare Active Directory to Azure Active Directory

+Azure Active Directory is the next evolution of identity and access management solutions for the cloud. Microsoft introduced Active Directory Domain Services in Windows 2000 to give organizations the ability to manage multiple on-premises infrastructure components and systems using a single identity per user.

+Azure AD takes this approach to the next level by providing organizations with an Identity as a Service (IDaaS) solution for all their apps across cloud and on-premises.

+Most IT administrators are familiar with Active Directory Domain Services concepts. The following table outlines the differences and similarities between Active Directory concepts and Azure Active Directory.

+|Concept|Active Directory (AD)|Azure Active Directory |

+|:-|:-|:-|

+|**Users**|||

+|Provisioning: users | Organizations create internal users manually or use an in-house or automated provisioning system, such as the Microsoft Identity Manager, to integrate with an HR system.|Existing AD organizations use [Azure AD Connect](../hybrid/how-to-connect-sync-whatis.md) to sync identities to the cloud.</br> Azure AD adds support to automatically create users from [cloud HR systems](../app-provisioning/what-is-hr-driven-provisioning.md). </br>Azure AD can provision identities in [SCIM enabled](../app-provisioning/use-scim-to-provision-users-and-groups.md) SaaS apps to automatically provide apps with the necessary details to allow access for users. |

+|Provisioning: external identities| Organizations create external users manually as regular users in a dedicated external AD forest, resulting in administration overhead to manage the lifecycle of external identities (guest users)| Azure AD provides a special class of identity to support external identities. [Azure AD B2B](/azure/active-directory/b2b/) will manage the link to the external user identity to make sure they are valid. |

+| Entitlement management and groups| Administrators make users members of groups. App and resource owners then give groups access to apps or resources.| [Groups](./active-directory-groups-create-azure-portal.md) are also available in Azure AD and administrators can also use groups to grant permissions to resources. In Azure AD, administrators can assign membership to groups manually or use a query to dynamically include users to a group. </br> Administrators can use [Entitlement management](../governance/entitlement-management-overview.md) in Azure AD to give users access to a collection of apps and resources using workflows and, if necessary, time-based criteria. |

+| Admin management|Organizations will use a combination of domains, organizational units, and groups in AD to delegate administrative rights to manage the directory and resources it controls.| Azure AD provides [built-in roles](./active-directory-users-assign-role-azure-portal.md) with its Azure AD role-based access control (Azure AD RBAC) system, with limited support for [creating custom roles](../roles/custom-overview.md) to delegate privileged access to the identity system, the apps, and resources it controls.</br>Managing roles can be enhanced with [Privileged Identity Management (PIM)](../privileged-identity-management/pim-configure.md) to provide just-in-time, time-restricted, or workflow-based access to privileged roles. |

+| Credential management| Credentials in Active Directory are based on passwords, certificate authentication, and smartcard authentication. Passwords are managed using password policies that are based on password length, expiry, and complexity.|Azure AD uses intelligent [password protection](../authentication/concept-password-ban-bad.md) for cloud and on-premises. Protection includes smart lockout plus blocking common and custom password phrases and substitutions. </br>Azure AD significantly boosts security [through Multi-factor authentication](../authentication/concept-mfa-howitworks.md) and [passwordless](../authentication/concept-authentication-passwordless.md) technologies, like FIDO2. </br>Azure AD reduces support costs by providing users a [self-service password reset](../authentication/concept-sspr-howitworks.md) system. |

+| **Apps**|||

+| Infrastructure apps|Active Directory forms the basis for many infrastructure on-premises components, for example, DNS, DHCP, IPSec, WiFi, NPS, and VPN access|In a new cloud world, Azure AD, is the new control plane for accessing apps versus relying on networking controls. When users authenticate, [Conditional access (CA)](../conditional-access/overview.md) controls which users have access to which apps under required conditions.|

+| Traditional and legacy apps| Most on-premises apps use LDAP, Windows-Integrated Authentication (NTLM and Kerberos), or Header-based authentication to control access to users.| Azure AD can provide access to these types of on-premises apps using [Azure AD application proxy](../app-proxy/application-proxy.md) agents running on-premises. Using this method Azure AD can authenticate Active Directory users on-premises using Kerberos while you migrate or need to coexist with legacy apps. |

+| SaaS apps|Active Directory doesn't support SaaS apps natively and requires federation system, such as AD FS.|SaaS apps supporting OAuth2, SAML, and WS-\* authentication can be integrated to use Azure AD for authentication. |

+| Line of business (LOB) apps with modern authentication|Organizations can use AD FS with Active Directory to support LOB apps requiring modern authentication.| LOB apps requiring modern authentication can be configured to use Azure AD for authentication. |

+| Mid-tier/Daemon services|Services running in on-premises environments normally use AD service accounts or group Managed Service Accounts (gMSA) to run. These apps will then inherit the permissions of the service account.| Azure AD provides [managed identities](../managed-identities-azure-resources/index.yml) to run other workloads in the cloud. The lifecycle of these identities is managed by Azure AD and is tied to the resource provider and it can't be used for other purposes to gain backdoor access.|

+| **Devices**|||

+| Mobile|Active Directory doesn't natively support mobile devices without third-party solutions.| MicrosoftΓÇÖs mobile device management solution, Microsoft Intune, is integrated with Azure AD. Microsoft Intune provides device state information to the identity system to evaluate during authentication. |

+| Windows desktops|Active Directory provides the ability to domain join Windows devices to manage them using Group Policy, System Center Configuration Manager, or other third-party solutions.|Windows devices can be [joined to Azure AD](../devices/index.yml). Conditional access can check if a device is Azure AD joined as part of the authentication process. Windows devices can also be managed with [Microsoft Intune](/intune/what-is-intune). In this case, conditional access, will consider whether a device is compliant (for example, up-to-date security patches and virus signatures) before allowing access to the apps.|

+| Windows servers| Active Directory provides strong management capabilities for on-premises Windows servers using Group Policy or other management solutions.| Windows servers virtual machines in Azure can be managed with [Azure AD Domain Services](../../active-directory-domain-services/index.yml). [Managed identities](../managed-identities-azure-resources/index.yml) can be used when VMs need access to the identity system directory or resources.|

+| Linux/Unix workloads|Active Directory doesn't natively support non-Windows without third-party solutions, although Linux machines can be configured to authenticate with Active Directory as a Kerberos realm.|Linux/Unix VMs can use [managed identities](../managed-identities-azure-resources/index.yml) to access the identity system or resources. Some organizations, migrate these workloads to cloud container technologies, which can also use managed identities.|

+## Next steps

+- [What is Azure Active Directory?](./active-directory-whatis.md)

+- [Compare self-managed Active Directory Domain Services, Azure Active Directory, and managed Azure Active Directory Domain Services](../../active-directory-domain-services/compare-identity-solutions.md)

+- [Frequently asked questions about Azure Active Directory](./active-directory-faq.yml)

+- [What's new in Azure Active Directory?](./whats-new.md)

+* [Azure Active Directory and data residency](data-residency.md)

+* [Azure Active Directory and data residency](data-residency.md)

+ Title: Azure AD and data residency

+description: Use residency data to manage access, achieve mobility scenarios, and secure your organization.

+# Azure Active Directory and data residency

+Azure AD is an Identity as a Service (IDaaS) solution that stores and manages identity and access data in the cloud. You can use the data to enable and manage access to cloud services, achieve mobility scenarios, and secure your organization. An instance of the Azure AD service, called a [tenant](../develop/developer-glossary.md#tenant), is an isolated set of directory object data that the customer provisions and owns.

+## Core Store

+The Core Store is made up of tenants stored in scale units, each of which contains multiple tenants. Update or retrieval data operations in the Azure AD Core Store relate to a single tenant, based on the user's security token, which achieves tenant isolation. Scale units are assigned to a geo-location. Each geo-location uses two or more Azure regions to store the data. In each Azure region, a scale unit data is replicated in the physical data centers for resiliency and performance.

+Learn more: [Azure Active Directory Core Store Scale Units](https://www.youtube.com/watch?v=OcKO44GtHh8)

+Azure AD is available in the following clouds

+* Public

+* China

+* US government

+In the public cloud, you're prompted to select a location at the time of tenant creation (for example, signing up for Office 365 or Azure, or creating more Azure AD instances through the Azure portal). Azure AD maps the selection to a geo-location and a single scale unit in it. Tenant location can't be changed after it's set.

+The location selected during tenant creation will map to one of the following geo-locations:

+* Australia

+* Asia/Pacific

+* Europe, Middle East, and Africa (EMEA)

+* Japan

+* North America

+* Worldwide

+Azure AD handles Core Store data based on usability, performance, residency and/or other requirements based on geo-location. Azure AD replicates each tenant through its scale unit, across data centers, based on the following criteria:

+* Azure AD Core Store data, stored in data centers closest to the tenant-residency location, to reduce latency and provide fast user sign-in times

+* Azure AD Core Store data stored in geographically isolated data centers to assure availability during unforeseen single-datacenter, catastrophic events

+* Compliance with data residency, or other requirements, for specific customers and geo-locations

+## Azure AD cloud solution models

+Use the following table to see Azure AD cloud solution models based on infrastructure, data location, and operational sovereignty.

+|Model|Locations|Data location|Operations personnel|Put a tenant in this model|

+||||||

+|Public geo located|North America, EMEA, Japan, Asia/Pacific|At rest, in the target location. Exceptions by service or feature|Operated by Microsoft. Microsoft datacenter personnel must pass a background check.|Create the tenant in the sign-up experience. Choose the location for data residency.|

+|Public worldwide|Worldwide|All locations|Operated by Microsoft. Microsoft datacenter personnel must pass a background check.|Tenant creation available via official support channel and subject to Microsoft discretion.|

+|Sovereign or national clouds|US government, China|At rest, in the target location. No exceptions.|Operated by a data custodian (1). Personnel are screened according to requirements.|Each national cloud instance has a sign-up experience.|

+**Table references**:

+(1) **Data custodians**: Data centers in the US government cloud are operated by Microsoft. In China, Azure AD is operated through a partnership with [21Vianet](/microsoft-365/admin/services-in-china/services-in-china?redirectSourcePath=%252fen-us%252farticle%252fLearn-about-Office-365-operated-by-21Vianet-a8ab5061-3346-4da0-bb7c-5260822b53ae&view=o365-21vianet&viewFallbackFrom=o365-worldwide&preserve-view=true).

+Learn more:

+* [Customer data storage and processing for European customers in Azure AD](./active-directory-data-storage-eu.md)

+* Power BI: [Azure Active Directory ΓÇô Where is your data located?](https://aka.ms/aaddatamap)

+* [What is the Azure Active Directory architecture?](https://aka.ms/aadarch)

+* [Find the Azure geography that meets your needs](https://azure.microsoft.com/overview/datacenters/how-to-choose/)

+* [Microsoft Trust Center](https://www.microsoft.com/trustcenter/cloudservices/nationalcloud)

+## Data residency across Azure AD components

+Learn more: [Azure Active Directory, Product overview](https://www.microsoft.com/cloud-platform/azure-active-directory-features)

+> [!NOTE]

+> To understand service data location, such as Exchange Online, or Skype for Business, refer to the corresponding service documentation.

+### Azure AD components and data storage location

+|Azure AD component|Description|Data storage location|

+||||

+|Azure AD Authentication Service|This service is stateless. The data for authentication is in the Azure AD Core Store. It has no directory data. Azure AD Authentication Service generates log data in Azure storage, and in the data center where the service instance runs. When users attempt to authenticate using Azure AD, they're routed to an instance in the geographically nearest data center that is part of its Azure AD logical region. |In geo location|

+|Azure AD Identity and Access Management (IAM) Services|**User and management experiences**: The Azure AD management experience is stateless and has no directory data. It generates log and usage data stored in Azure Tables storage. The user experience is like the Azure portal. <br>**Identity management business logic and reporting services**: These services have locally cached data storage for groups and users. The services generate log and usage data that goes to Azure Tables storage, Azure SQL, and in Microsoft Elastic Search reporting services. |In geo location|

+|Azure AD Multi-Factor Authentication (MFA)|For details about MFA-operations data storage and retention, see [Data residency and customer data for Azure AD multifactor authentication](../authentication/concept-mfa-data-residency.md). Azure AD MFA logs the User Principal Name (UPN), voice-call telephone numbers, and SMS challenges. For challenges to mobile app modes, the service logs the UPN and a unique device token. Data centers in the North America region store Azure AD MFA, and the logs it creates.|North America|

+|Azure AD Domain Services|See regions where Azure AD Domain Services is published on [Products available by region](https://azure.microsoft.com/regions/services/). The service holds system metadata globally in Azure Tables, and it contains no personal data.|In geo location|

+|Azure AD Connect Health|Azure AD Connect Health generates alerts and reports in Azure Tables storage and blob storage.|In geo location|

+|Azure AD dynamic membership for groups, Azure AD self-service group management|Azure Tables storage holds dynamic membership rule definitions.|In geo location|

+|Azure AD Application Proxy|Azure AD Application Proxy stores metadata about the tenant, connector machines, and configuration data in Azure SQL.|In geo location|

+|Azure AD password writeback in Azure AD Connect|During initial configuration, Azure AD Connect generates an asymmetric keypair, using the RivestΓÇôShamirΓÇôAdleman (RSA) cryptosystem. It then sends the public key to the self-service password reset (SSPR) cloud service, which performs two operations: </br></br>1. Creates two Azure Service Bus relays for the Azure AD Connect on-premises service to communicate securely with the SSPR service </br> 2. Generates an Advanced Encryption Standard (AES) key, K1 </br></br> The Azure Service Bus relay locations, corresponding listener keys, and a copy of the AES key (K1) goes to Azure AD Connect in the response. Future communications between SSPR and Azure AD Connect occur over the new ServiceBus channel and are encrypted using SSL. </br> New password resets, submitted during operation, are encrypted with the RSA public key generated by the client during onboarding. The private key on the Azure AD Connect machine decrypts them, which prevents pipeline subsystems from accessing the plaintext password. </br> The AES key encrypts the message payload (encrypted passwords, more data, and metadata), which prevents malicious ServiceBus attackers from tampering with the payload, even with full access to the internal ServiceBus channel. </br> For password writeback, Azure AD Connect need keys and data: </br></br> - The AES key (K1) that encrypts the reset payload, or change requests from the SSPR service to Azure AD Connect, via the ServiceBus pipeline </br> - The private key, from the asymmetric key pair that decrypts the passwords, in reset or change request payloads </br> - The ServiceBus listener keys </br></br> The AES key (K1) and the asymmetric keypair rotate a minimum of every 180 days, a duration you can change during certain onboarding or offboarding configuration events. An example is a customer disables and re-enables password writeback, which might occur during component upgrade during service and maintenance. </br> The writeback keys and data stored in the Azure AD Connect database are encrypted by data protection application programming interfaces (DPAPI) (CALG_AES_256). The result is the master ADSync encryption key stored in the Windows Credential Vault in the context of the ADSync on-premises service account. The Windows Credential Vault supplies automatic secret re-encryption as the password for the service account changes. To reset the service account password invalidates secrets in the Windows Credential Vault for the service account. Manual changes to a new service account might invalidate the stored secrets.</br> By default, the ADSync service runs in the context of a virtual service account. The account might be customized during installation to a least-privileged domain service account, a managed service account (MSA), or a group managed service account (gMSA). While virtual and managed service accounts have automatic password rotation, customers manage password rotation for a custom provisioned domain account. As noted, to reset the password causes loss of stored secrets. |In geo location|

+|Azure AD Device Registration Service |Azure AD Device Registration Service has computer and device lifecycle management in the directory, which enable scenarios such as device-state conditional access, and mobile device management.|In geo location|

+|Azure AD provisioning|Azure AD provisioning creates, removes, and updates users in systems, such as software as service (SaaS) applications. It manages user creation in Azure AD and on-premises AD from cloud HR sources, like Workday. The service stores its configuration in an Azure Cosmos DB, which stores the group membership data for the user directory it keeps. Cosmos DB replicates the database to multiple datacenters in the same region as the tenant, which isolates the data, according to the Azure AD cloud solution model. Replication creates high availability and multiple reading and writing endpoints. Cosmos DB has encryption on the database information, and the encryption keys are stored in the secrets storage for Microsoft.|In geo location|

+|Azure AD business-to-business (B2B) collaboration|Azure AD B2B collaboration has no directory data. Users and other directory objects in a B2B relationship, with another tenant, result in user data copied in other tenants, which might have data residency implications.|In geo location|

+|Azure AD Identity Protection|Azure AD Identity Protection uses real-time user log-in data, with multiple signals from company and industry sources, to feed its machine-learning systems that detect anomalous logins. Personal data is scrubbed from real-time log-in data before it's passed to the machine learning system. The remaining log-in data identifies potentially risky usernames and logins. After analysis, the data goes to Microsoft reporting systems. Risky logins and usernames appear in reporting for Administrators.|In geo location|

+|Azure AD managed identities for Azure resources|Azure AD managed identities for Azure resources with managed identities systems can authenticate to Azure services, without storing credentials. Rather than use username and password, managed identities authenticate to Azure services with certificates. The service writes certificates it issues in Azure Cosmos DB in the East US region, which fail over to another region, as needed. Azure Cosmos DB geo-redundancy occurs by global data replication. Database replication puts a read-only copy in each region that Azure AD managed identities runs. To learn more, see [Azure services that can use managed identities to access other services](../managed-identities-azure-resources/managed-identities-status.md). Microsoft isolates each Cosmos DB instance in an Azure AD cloud solution model. </br> The resource provider, such as the virtual machine (VM) host, stores the certificate for authentication, and identity flows, with other Azure services. The service stores its master key to access Azure Cosmos DB in a datacenter secrets management service. Azure Key Vault stores the master encryption keys.|In geo location|

+|Azure Active Directory B2C |[Azure AD B2C](../../active-directory-b2c/data-residency.md) is an identity management service to customize and manage how customers sign up, sign in, and manage their profiles when using applications. B2C uses the Core Store to keep user identity information. The Core Store database follows known storage, replication, deletion, and data-residency rules. B2C uses an Azure Cosmos DB system to store service policies and secrets. Cosmos DB has encryption and replication services on database information. Its encryption key is stored in the secrets storage for Microsoft. Microsoft isolates Cosmos DB instances in an Azure AD cloud solution model.|Customer-selectable geo location|

+## Related resources

+For more information on data residency in Microsoft Cloud offerings, see the following articles:

+* [Azure Active Directory ΓÇô Where is your data located?](https://aka.ms/aaddatamap)

+* [Data Residency in Azure | Microsoft Azure](https://azure.microsoft.com/explore/global-infrastructure/data-residency/#overview)

+* [Microsoft 365 data locations - Microsoft 365 Enterprise](/microsoft-365/enterprise/o365-data-locations?view=o365-worldwide&preserve-view=true)

+* [Microsoft Privacy - Where is Your Data Located?](https://www.microsoft.com/trust-center/privacy/data-location?rtc=1)

+* Download PDF: [Privacy considerations in the cloud](https://go.microsoft.com/fwlink/p/?LinkID=2051117&clcid=0x409&culture=en-us&country=US)

+## Next steps

+* [Azure Active Directory and data residency](data-residency.md) (You're here)

+* [Data operational considerations](data-operational-considerations.md)

+* [Data protection considerations](data-protection-considerations.md)

+ Title: Five steps to integrate your apps with Azure Active Directory

+description: Learn to integrate your applications with Azure AD by adding apps, discovery, and integration methods.

+# Five steps to integrate your apps with Azure Active Directory

+Learn to integrate your applications with Azure Active Directory (Azure AD), which is a cloud-based identity and access management service. Organizations use Azure AD for secure authentication and authorization so customers, partners, and employees can access applications. With Azure AD, features such as Conditional Access, Azure AD Multi-Factor Authentication (MFA), single sign-on, and application provisioning make identity and access management easier to manage and more secure.

+Learn more:

+* [What is Conditional Access?](../conditional-access/overview.md)

+* [How it works: Azure AD Multi-Factor Authentication](../authentication/concept-mfa-howitworks.md)

+* [Azure AD seamless single sign-on](../hybrid/how-to-connect-sso.md)

+* [What is app provisioning in Azure AD?](../app-provisioning/user-provisioning.md)

+If your company has a Microsoft 365 subscription, you likely use Azure AD. However, you can use Azure AD for applications. If you centralize application management, identity management features, tools, and policies for your app portfolio. The benefit is a unified solution that improves security, reduces costs, increases productivity, and enables compliance. In addition, there's remote access to on-premises apps.

+Learn more:

+* [Deploy your identity infrastructure for Microsoft 365](/microsoft-365/enterprise/deploy-identity-solution-overview?view=o365-worldwide&preserve-view=true)

+* [What is application management in Azure AD?](../manage-apps/what-is-application-management.md)

+## Azure AD for new applications

+When your business acquires new applications, add them to the Azure AD tenant. Establish a company policy of adding new apps to Azure AD.

+See, [Quickstart: Add an enterprise application](../manage-apps/add-application-portal.md)

+Azure AD has a gallery of integrated applications to make it easy to get started. Add a gallery app to your Azure AD organization (see, previous link) and learn about integrating software as a service (SaaS) tutorials.

+See, [Tutorials for integrating SaaS applications with Azure AD](../saas-apps/tutorial-list.md)

+### Integration tutorials

+Use the following tutorials to learn to integrate common tools with Azure AD single sign-on (SSO).

+* [Tutorial: Azure AD SSO integration with ServiceNow](../saas-apps/servicenow-tutorial.md)

+* [Tutorial: Azure AD SSO integration with Workday](../saas-apps/workday-tutorial.md)

+* [Tutorial: Azure AD SSO integration with Salesforce](../saas-apps/salesforce-tutorial.md)

+* [Tutorial: Azure AD SSO integration with AWS Single-Account Access](../saas-apps/amazon-web-service-tutorial.md)

+* [Tutorial: Azure AD SSO integration with Slack](../saas-apps/slack-tutorial.md)

+### Apps not in the gallery

+You can integrate applications that don't appear in the gallery, including applications in your organization, or third-party application from vendors. Submit a request to publish your app in the gallery. To learn about integrating apps you develop in-house, see **Integrate apps your developers build**.

+Learn more:

+* [Quickstart: View enterprise applications](../manage-apps/view-applications-portal.md)

+* [Submit a request to publish your application in Azure AD application gallery](../manage-apps/v2-howto-app-gallery-listing.md)

+## Determine application usage and prioritize integration

+Discover the applications employees use, and prioritize integrating the apps with Azure AD. Use the Microsoft Defender for Cloud Apps Cloud Discovery tools to discover and manage apps not managed by your IT team. Microsoft Defender for Endpoint (formerly known as Microsoft Defender Advanced Threat Protection) simplifies and extends the discovery process.

+Learn more:

+* [Set up Cloud Discovery](/defender-cloud-apps/set-up-cloud-discovery)

+* [Microsoft Defender for Endpoint](/microsoft-365/security/defender-endpoint/microsoft-defender-endpoint?view=o365-worldwide&preserve-view=true)

+In addition, use the Active Directory Federation Services (AD FS) in the Azure portal to discover AD FS apps in your organization. Discover unique users that signed in to the apps, and see information about integration compatibility.

+See, [Review the application activity report](../manage-apps/migrate-adfs-application-activity.md)

+### Application migration

+After you discover apps in your environment, prioritize the apps to migrate and integrate. Consider the following parameters:

+- Apps used most frequently

+- Riskiest apps

+- Apps to be decommissioned, therefore not in migration

+- Apps that stay on-premises

+See, [Resources for migrating applications to Azure AD](../manage-apps/migration-resources.md)

+## Integrate apps and identity providers

+During discovery, there might be applications not tracked by the IT team, which can create vulnerabilities. Some applications use alternative identity solutions, including AD FS, or other identity providers (IdPs). We recommend you consolidate identity and access management. Benefits include:

+* Reduce on-premises user set-up, authentication, and IdP licensing fees

+* Lower administrative overhead with streamlined identity and access management process

+* Enable single sign-on (SSO) access to applications in the My Apps portal

+ * See, [Create collections on the My Apps portal](../manage-apps/access-panel-collections.md)

+* Use Identity Protection and Conditional Access to increase data from app usage, and extend benefits to recently added apps

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

+ * [What is Conditional Access?](../conditional-access/overview.md)

+### App owner awareness

+To help manage app integration with Azure AD, use the following material for application owner awareness and interest. Modify the material with your branding.

+You can download:

+* Zip file, [Editable Azure AD App Integration One-Pager](https://aka.ms/AppOnePager)

+* Microsoft PowerPoint presentation, [Azure AD application integration guidelines](https://aka.ms/AppGuideline)

+### Active Directory Federation Services

+Evaluate use of AD FS for authentication with SaaS apps, line-of-business apps, also Microsoft 365 and Azure AD apps.

+ 

+Improve the configuration illustrated in the previous diagram by moving application authentication to Azure AD. Enable sign-on for apps and ease application discovery with the My Apps portal.

+Learn more:

+* [Move application authentication to Azure AD](../manage-apps/migrate-adfs-apps-to-azure.md)

+* [Sign in and start apps from the My Apps portal](https://support.microsoft.com/account-billing/sign-in-and-start-apps-from-the-my-apps-portal-2f3b1bae-0e5a-4a86-a33e-876fbd2a4510)

+See the following diagram of app authentication simplified by Azure AD.

+ 

+After Azure AD is the central IdP, you might be able to discontinue ADFS.

+ 

+You can migrate apps that use a different cloud-based IdP. Your organization might have multiple Identity Access Management (IAM) solutions. Migrating to one Azure AD infrastructure can reduce dependencies on IAM licenses and infrastructure costs. If you paid for Azure AD with Microsoft 365 licenses, likely you don't have to purchase another IAM solution.

+## Integrate on-premises applications

+Traditionally, application security enabled access during a connection to a corporate network. However, organization grant access to apps for customers, partners, and/or employees, regardless of location. Application Proxy Service in Azure AD connects on-premises apps to Azure AD and doesn't require edge servers or more infrastructure.

+See, [Using Azure AD Application Proxy to publish on-premises apps for remote users](../app-proxy/what-is-application-proxy.md)

+The following diagram illustrates Application Proxy Service processing a user request.

+ 

+See, [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure AD](../app-proxy/application-proxy-add-on-premises-application.md)

+In addition, integrate application delivery controllers like F5 BIG-IP APM, or Zscaler Private Access, with Azure AD. Benefits are modern authentication and identity management, traffic management, and security features. We call this solution secure hybrid access.

+See, [Secure hybrid access: Protect legacy apps with Azure AD](../manage-apps/secure-hybrid-access.md)

+For the following services, there are Azure AD integration tutorials.

+* [Tutorial: Azure AD SSO integration with Akamai](../saas-apps/akamai-tutorial.md)

+* [Tutorial: Azure AD SSO integration with Citrix ADC SAML Connector for Azure AD (Kerberos-based authentication)](../saas-apps/citrix-netscaler-tutorial.md)

+ * Formerly known as Citrix Netscaler

+* [Integrate F5 BIG-IP with Azure AD](../manage-apps/f5-aad-integration.md)

+* [Tutorial: Integrate Zscaler Private Access (ZPA) with Azure AD](../saas-apps/zscalerprivateaccess-tutorial.md)

+## Integrate apps your developers build

+For your developers' apps, use the Microsoft identity platform for authentication and authorization. Integrated applications are registered and managed like other apps in your portfolio.

+Learn more:

+* [Microsoft identity platform documentation](../develop/index.yml)

+* [Quickstart: Register an application with the Microsoft identity platform](../develop/quickstart-register-app.md)

+Developers can use the platform for internal and customer-facing apps. For instance, use Microsoft Authentication Libraries (MSAL) to enable multi-factor authentication and security to access apps.

+Learn more:

+* [Overview of the Microsoft Authentication Library (MSAL)](../develop/msal-overview.md)

+* [Microsoft identity platform code samples](../develop/sample-v2-code.md)

+* Video: [Overview of the Microsoft identity platform for developers](https://www.youtube.com/watch?v=zjezqZPPOfc&amp;list=PLLasX02E8BPBxGouWlJV-u-XZWOc2RkiX) (33:54)

+## Next step

+[Resources for migrating applications to Azure AD](../manage-apps/migration-resources.md)

+ Title: Governing Azure Active Directory service accounts

+description: Principles and procedures for managing the lifecycle of service accounts in Azure Active Directory.

+# Governing Azure Active Directory service accounts

+There are three types of service accounts in Azure Active Directory (Azure AD): managed identities, service principals, and user accounts employed as service accounts. When you create service accounts for automated use, they're granted permissions to access resources in Azure and Azure AD. Resources can include Microsoft 365 services, software as a service (SaaS) applications, custom applications, databases, HR systems, and so on. Governing Azure AD service account is managing creation, permissions, and lifecycle to ensure security and continuity.

+Learn more:

+* [Securing managed identities](service-accounts-managed-identities.md)

+* [Securing service principals](service-accounts-principal.md)

+> [!NOTE]

+> We do not recommend user accounts as service accounts because they are less secure. This includes on-premises service accounts synced to Azure AD, because they aren't converted to service principals. Instead, we recommend managed identities, or service principals, and the use of Conditional Access.

+Lear more: [What is Conditional Access?](../conditional-access/overview.md)

+## Plan your service account

+Before creating a service account, or registering an application, document the service account key information. Use the information to monitor and govern the account. We recommend collecting the following data and tracking it in your centralized Configuration Management Database (CMDB).

+| Data| Description| Details |

+| - | - | - |

+| Owner| User or group accountable for managing and monitoring the service account| Grant the owner permissions to monitor the account and implement a way to mitigate issues. Issue mitigation is done by the owner, or by request to an IT team. |

+| Purpose| How the account is used| Map the service account to a service, application, or script. Avoid creating multi-use service accounts. |

+| Permissions (Scopes)| Anticipated set of permissions| Document the resources it accesses and permissions for those resources |

+| CMDB Link| Link to the accessed resources, and scripts in which the service account is used| Document the resource and script owners to communicate the effects of change |

+| Risk assessment| Risk and business effect, if the account is compromised|Use the information to narrow the scope of permissions and determine access to information |

+| Period for review| The cadence of service account reviews, by the owner| Review communications and reviews. Document what happens if a review is performed after the scheduled review period. |

+| Lifetime| Anticipated maximum account lifetime| Use this measurement to schedule communications to the owner, disable, and then delete the accounts. Set an expiration date for credentials that prevents them from rolling over automatically. |

+| Name| Standardized account name| Create a naming convention for service accounts to search, sort, and filter them |

+## Principle of least privileges

+Grant the service account permissions needed to perform tasks, and no more. If a service account needs high-level permissions, for example a Global Administrator, evaluate why and try to reduce permissions.

+We recommend the following practices for service account privileges.

+### Permissions

+* Don't assign built-in roles to service accounts

+ * See, [oAuth2PermissionGrant resource type](/graph/api/resources/oauth2permissiongrant)

+* The service principal is assigned a privileged role

+ * [Create and assign a custom role in Azure Active Directory](../roles/custom-create.md)

+* Don't include service accounts as members of any groups with elevated permissions

+ * See, [Get-AzureADDirectoryRoleMember](/powershell/module/azuread/get-azureaddirectoryrolemember):

+

+>`Get-AzureADDirectoryRoleMember`, and filter for objectType "Service Principal", or use</br>

+>`Get-AzureADServicePrincipal | % { Get-AzureADServiceAppRoleAssignment -ObjectId $_ }`

+* See, [Introduction to permissions and consent](../develop/v2-permissions-and-consent.md) to limit the functionality a service account can access on a resource

+* Service principals and managed identities can use OAuth 2.0 scopes in a delegated context impersonating a signed-on user, or as service account in the application context. In the application context, no one is signed in.

+* Confirm the scopes service accounts request for resources

+ * If an account requests Files.ReadWrite.All, evaluate if it needs File.Read.All

+ * [Microsoft Graph permissions reference](/graph/permissions-reference)

+* Ensure you trust the application developer, or API, with the requested access

+### Duration

+* Limit service account credentials (client secret, certificate) to an anticipated usage period

+* Schedule periodic reviews of service account usage and purpose

+ * Ensure reviews occur prior to account expiration

+After you understand the purpose, scope, and permissions, create your service account, use the instructions in the following articles.

+* [How to use managed identities for App Service and Azure Functions](../../app-service/overview-managed-identity.md?tabs=dotnet)

+* [Create an Azure Active Directory application and service principal that can access resources](../develop/howto-create-service-principal-portal.md)

+Use a managed identity when possible. If you can't use a managed identity, use a service principal. If you can't use a service principal, then use an Azure AD user account.

+## Build a lifecycle process

+A service account lifecycle starts with planning, and ends with permanent deletion. The following sections cover how you monitor, review permissions, determine continued account usage, and ultimately deprovision the account.

+### Monitor service accounts

+Monitor your service accounts to ensure usage patterns are correct, and that the service account is used.

+#### Collect and monitor service account sign-ins

+Use one of the following monitoring methods:

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

+* Export the Azure AD Sign-In Logs to

+ * [Azure Storage documentation](../../storage/index.yml)

+ * [Azure Event Hubs documentation](../../event-hubs/index.yml), or

+ * [Azure Monitor Logs overview](../../azure-monitor/logs/data-platform-logs.md)

+Use the following screenshot to see service principal sign-ins.

+

+#### Sign-in log details

+Look for the following details in sign-in logs.

+* Service accounts not signed in to the tenant

+* Changes in sign-in service account patterns

+We recommend you export Azure AD sign-in logs, and then import them into a security information and event management (SIEM) tool, such as Microsoft Sentinel. Use the SIEM tool to build alerts and dashboards.

+### Review service account permissions

+Regularly review service account permissions and accessed scopes to see if they can be reduced or eliminated.

+* See, [Get-AzureADServicePrincipalOAuth2PermissionGrant](/powershell/module/azuread/get-azureadserviceprincipaloauth2permissiongrant)

+ * [Script to list all delegated permissions and application permissions in Azure AD](https://gist.github.com/psignoret/41793f8c6211d2df5051d77ca3728c09) scopes for service account

+* See, [Azure AD/AzureADAssessment](https://github.com/AzureAD/AzureADAssessment) and confirm validity

+* Don't set service principal credentials to **Never expire**

+* Use certificates or credentials stored in Azure Key Vault, when possible

+ * [What is Azure Key Vault?](../../key-vault/general/basic-concepts.md)

+The free PowerShell sample collects service principal OAuth2 grants and credential information, records them in a comma-separated values (CSV) file, and a Power BI sample dashboard. For more information, see [Azure AD/AzureADAssessment](https://github.com/AzureAD/AzureADAssessment).

+### Recertify service account use

+Establish a regular review process to ensure service accounts are regularly reviewed by owners, security team, or IT team.

+The process includes:

+* Determine service account review cycle, and document it in your CMDB

+* Communications to owner, security team, IT team, before a review

+* Determine warning communications, and their timing, if the review is missed

+* Instructions if owners fail to review or respond

+ * Disable, but don't delete, the account until the review is complete

+* Instructions to determine dependencies. Notify resource owners of effects

+The review includes the owner and an IT partner, and they certify:

+* Account is necessary

+* Permissions to the account are adequate and necessary, or a change is requested

+* Access to the account, and its credentials, are controlled

+* Account credentials are accurate: credential type and lifetime

+* Account risk score hasn't changed since the previous recertification

+* Update the expected account lifetime, and the next recertification date

+### Deprovision service accounts

+Deprovision service accounts under the following circumstances:

+* Account script or application is retired

+* Account script or application function is retired. For example, access to a resource.

+* Service account is replaced by another service account

+* Credentials expired, or the account is non-functional, and there aren't complaints

+Deprovisioning includes the following tasks:

+After the associated application or script is deprovisioned:

+* [Sign-in logs in Azure AD](../reports-monitoring/concept-sign-ins.md) and resource access by the service account

+ * If the account is active, determine how it's being used before continuing

+* For a managed service identity, disable service account sign-in, but don't remove it from the directory

+* Revoke service account role assignments and OAuth2 consent grants

+* After a defined period, and warning to owners, delete the service account from the directory

+## Next steps

+* [Securing cloud-based service accounts](secure-service-accounts.md)

+* [Securing managed identities](service-accounts-managed-identities.md)

+* [Securing service principal](service-accounts-principal.md)

+ Title: Azure Active Directory Authentication management operations reference guide

+description: This operations reference guide describes the checks and actions you should take to secure authentication management

+tags: azuread

+# Azure Active Directory Authentication management operations reference guide

+This section of the [Azure AD operations reference guide](active-directory-ops-guide-intro.md) describes the checks and actions you should take to secure and manage credentials, define authentication experience, delegate assignment, measure usage, and define access policies based on enterprise security posture.

+> [!NOTE]

+> These recommendations are current as of the date of publishing but can change over time. Organizations should continuously evaluate their identity practices as Microsoft products and services evolve over time.

+## Key operational processes

+### Assign owners to key tasks

+Managing Azure Active Directory requires the continuous execution of key operational tasks and processes, which may not be part of a rollout project. It's still important you set up these tasks to optimize your environment. The key tasks and their recommended owners include:

+| Task | Owner |

+| :- | :- |

+| Manage lifecycle of single sign-on (SSO) configuration in Azure AD | IAM Operations Team |

+| Design conditional access policies for Azure AD applications | InfoSec Architecture Team |

+| Archive sign-in activity in a SIEM system | InfoSec Operations Team |

+| Archive risk events in a SIEM system | InfoSec Operations Team |

+| Triage and investigate security reports | InfoSec Operations Team |

+| Triage and investigate risk events | InfoSec Operations Team |

+| Triage and investigate users flagged for risk and vulnerability reports from Azure AD Identity Protection | InfoSec Operations Team |

+> [!NOTE]

+> Azure AD Identity Protection requires an Azure AD Premium P2 license. To find the right license for your requirements, see [Comparing generally available features of the Azure AD Free and Azure AD Premium editions](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing).

+As you review your list, you may find you need to either assign an owner for tasks that are missing an owner or adjust ownership for tasks with owners that aren't aligned with the recommendations above.

+#### Owner recommended reading

+- [Assigning administrator roles in Azure Active Directory](../roles/permissions-reference.md)

+## Credentials management

+### Password policies

+Managing passwords securely is one of the most critical parts of identity and access management and often the biggest target of attacks. Azure AD supports several features that can help prevent an attack from being successful.

+Use the table below to find the recommended solution for mitigating the issue that needs to be addressed:

+| Issue | Recommendation |

+| :- | :- |

+| No mechanism to protect against weak passwords | Enable Azure AD [self-service password reset (SSPR)](../authentication/concept-sspr-howitworks.md) and [password protection](../authentication/concept-password-ban-bad-on-premises.md) |

+| No mechanism to detect leaked passwords | Enable [password hash sync](../hybrid/how-to-connect-password-hash-synchronization.md) (PHS) to gain insights |

+| Using AD FS and unable to move to managed authentication | Enable [AD FS Extranet Smart Lockout](/windows-server/identity/ad-fs/operations/configure-ad-fs-extranet-smart-lockout-protection) and / or [Azure AD Smart Lockout](../authentication/howto-password-smart-lockout.md) |

+| Password policy uses complexity-based rules such as length, multiple character sets, or expiration | Reconsider in favor of [Microsoft Recommended Practices](https://www.microsoft.com/research/publication/password-guidance/?from=http%3A%2F%2Fresearch.microsoft.com%2Fpubs%2F265143%2Fmicrosoft_password_guidance.pdf) and switch your approach to password management and deploy [Azure AD password protection](../authentication/concept-password-ban-bad.md). |

+| Users aren't registered to use multi-factor authentication (MFA) | [Register all user's security information](../identity-protection/howto-identity-protection-configure-mfa-policy.md) so it can be used as a mechanism to verify the user's identity along with their password |

+| There is no revocation of passwords based on user risk | Deploy Azure AD [Identity Protection user risk policies](../identity-protection/howto-identity-protection-configure-risk-policies.md) to force password changes on leaked credentials using SSPR |

+| There's no smart lockout mechanism to protect malicious authentication from bad actors coming from identified IP addresses | Deploy cloud-managed authentication with either password hash sync or [pass-through authentication](../hybrid/how-to-connect-pta-quick-start.md) (PTA) |

+#### Password policies recommended reading

+- [Azure AD and AD FS best practices: Defending against password spray attacks - Enterprise Mobility + Security](https://cloudblogs.microsoft.com/enterprisemobility/2018/03/05/azure-ad-and-adfs-best-practices-defending-against-password-spray-attacks/)

+### Enable self-service password reset and password protection

+Users needing to change or reset their passwords is one of the biggest sources of volume and cost of help desk calls. In addition to cost, changing the password as a tool to mitigate a user risk is a fundamental step in improving the security posture of your organization.

+At a minimum, it's recommended you deploy Azure AD [self-service password reset](../authentication/concept-sspr-howitworks.md) (SSPR) and on-premises [password protection](../authentication/howto-password-ban-bad-on-premises-deploy.md) to accomplish:

+- Deflect help desk calls.

+- Replace the use of temporary passwords.

+- Replace any existing self-service password management solution that relies on an on-premises solution.

+- [Eliminate weak passwords](../authentication/concept-password-ban-bad.md) in your organization.

+> [!NOTE]

+> For organizations with an Azure AD Premium P2 subscription, it is recommended to deploy SSPR and use it as part of an [Identity Protection User Risk Policy](../identity-protection/howto-identity-protection-configure-risk-policies.md).

+### Strong credential management

+Passwords by themselves aren't secure enough to prevent bad actors from gaining access to your environment. At a minimum, any user with a privileged account must be enabled for multi-factor authentication (MFA). Ideally, you should enable [combined registration](../authentication/concept-registration-mfa-sspr-combined.md) and require all users to register for MFA and SSPR using the [combined registration experience](https://support.microsoft.com/account-billing/set-up-your-security-info-from-a-sign-in-prompt-28180870-c256-4ebf-8bd7-5335571bf9a8). Eventually, we recommend you adopt a strategy to [provide resilience](../authentication/concept-resilient-controls.md) to reduce the risk of lockout due to unforeseen circumstances.

+

+### On-premises outage authentication resiliency

+In addition to the benefits of simplicity and enabling leaked credential detection, Azure AD Password Hash Sync (PHS) and Azure AD MFA allow users to access SaaS applications and Microsoft 365 in spite of on-premises outages due to cyberattacks such as [NotPetya](https://www.microsoft.com/security/blog/2018/02/05/overview-of-petya-a-rapid-cyberattack/). It's also possible to enable PHS while in conjunction with federation. Enabling PHS allows a fallback of authentication when federation services aren't available.

+If your on-premises organization is lacking an outage resiliency strategy or has one that isn't integrated with Azure AD, you should deploy Azure AD PHS and define a disaster recovery plan that includes PHS. Enabling Azure AD PHS will allow users to authenticate against Azure AD should your on-premises Active Directory be unavailable.

+

+To better understand your authentication options, see [Choose the right authentication method for your Azure Active Directory hybrid identity solution](../hybrid/choose-ad-authn.md).

+### Programmatic usage of credentials

+Azure AD scripts using PowerShell or applications using the Microsoft Graph API require secure authentication. Poor credential management executing those scripts and tools increase the risk of credential theft. If you're using scripts or applications that rely on hard-coded passwords or password prompts you should first review passwords in config files or source code, then replace those dependencies and use Azure Managed Identities, Integrated-Windows Authentication, or [certificates](../reports-monitoring/tutorial-access-api-with-certificates.md) whenever possible. For applications where the previous solutions aren't possible, consider using [Azure Key Vault](https://azure.microsoft.com/services/key-vault/).

+If you determine that there are service principals with password credentials and you're unsure how those password credentials are secured by scripts or applications, contact the owner of the application to better understand usage patterns.

+Microsoft also recommends you contact application owners to understand usage patterns if there are service principals with password credentials.

+## Authentication experience

+### On-premises authentication

+Federated Authentication with integrated Windows authentication (IWA) or Seamless Single Sign-On (SSO) managed authentication with password hash sync or pass-through authentication is the best user experience when inside the corporate network with line-of-sight to on-premises domain controllers. It minimizes credential prompt fatigue and reduces the risk of users falling prey to phishing attacks. If you're already using cloud-managed authentication with PHS or PTA, but users still need to type in their password when authenticating on-premises, then you should immediately [deploy Seamless SSO](../hybrid/how-to-connect-sso.md). On the other hand, if you're currently federated with plans to eventually migrate to cloud-managed authentication, then you should implement Seamless SSO as part of the migration project.

+### Device trust access policies

+Like a user in your organization, a device is a core identity you want to protect. You can use a device's identity to protect your resources at any time and from any location. Authenticating the device and accounting for its trust type improves your security posture and usability by:

+- Avoiding friction, for example, with MFA, when the device is trusted

+- Blocking access from untrusted devices

+- For Windows 10 devices, provide [single sign-on to on-premises resources seamlessly](../devices/azuread-join-sso.md).

+You can carry out this goal by bringing device identities and managing them in Azure AD by using one of the following methods:

+- Organizations can use [Microsoft Intune](/intune/what-is-intune) to manage the device and enforce compliance policies, attest device health, and set conditional access policies based on whether the device is compliant. Microsoft Intune can manage iOS devices, Mac desktops (Via JAMF integration), Windows desktops (natively using Mobile Device Management for Windows 10, and co-management with Microsoft Configuration Manager) and Android mobile devices.

+- [Hybrid Azure AD join](../devices/hybrid-azuread-join-managed-domains.md) provides management with Group Policies or Microsoft Configuration Manager in an environment with Active Directory domain-joined computers devices. Organizations can deploy a managed environment either through PHS or PTA with Seamless SSO. Bringing your devices to Azure AD maximizes user productivity through SSO across your cloud and on-premises resources while enabling you to secure access to your cloud and on-premises resources with [Conditional Access](../conditional-access/overview.md) at the same time.

+If you have domain-joined Windows devices that aren't registered in the cloud, or domain-joined Windows devices that are registered in the cloud but without conditional access policies, then you should register the unregistered devices and, in either case, [use Hybrid Azure AD join as a control](../conditional-access/require-managed-devices.md) in your conditional access policies.

+

+If you're managing devices with MDM or Microsoft Intune, but not using device controls in your conditional access policies, then we recommend using [Require device to be marked as compliant](../conditional-access/require-managed-devices.md#require-device-to-be-marked-as-compliant) as a control in those policies.

+

+#### Device trust access policies recommended reading

+- [How To: Plan your hybrid Azure Active Directory join implementation](../devices/hybrid-azuread-join-plan.md)

+- [Identity and device access configurations](/microsoft-365/enterprise/microsoft-365-policies-configurations)

+### Windows Hello for Business

+In Windows 10, [Windows Hello for Business](/windows/security/identity-protection/hello-for-business/hello-identity-verification) replaces passwords with strong two-factor authentication on PCs. Windows Hello for Business enables a more streamlined MFA experience for users and reduces your dependency on passwords. If you haven't begun rolling out Windows 10 devices, or have only partially deployed them, we recommend you upgrade to Windows 10 and [enable Windows Hello for Business](/windows/security/identity-protection/hello-for-business/hello-manage-in-organization) on all devices.

+If you would like to learn more about passwordless authentication, see [A world without passwords with Azure Active Directory](../authentication/concept-authentication-passwordless.md).

+## Application authentication and assignment

+### Single sign-on for apps

+Providing a standardized single sign-on mechanism to the entire enterprise is crucial for best user experience, reduction of risk, ability to report, and governance. If you're using applications that support SSO with Azure AD but are currently configured to use local accounts, you should reconfigure those applications to use SSO with Azure AD. Likewise, if you're using any applications that support SSO with Azure AD but are using another Identity Provider, you should reconfigure those applications to use SSO with Azure AD as well. For applications that don't support federation protocols but do support forms-based authentication, we recommend you configure the application to use [password vaulting](../app-proxy/application-proxy-configure-single-sign-on-password-vaulting.md) with Azure AD Application Proxy.

+

+> [!NOTE]

+> If you don't have a mechanism to discover unmanaged applications in your organization, we recommend implementing a discovery process using a cloud access security broker solution (CASB) such as [Microsoft Defender for Cloud Apps](https://www.microsoft.com/enterprise-mobility-security/cloud-app-security).

+Finally, if you have an Azure AD app gallery and use applications that support SSO with Azure AD, we recommend [listing the application in the app gallery](../manage-apps/v2-howto-app-gallery-listing.md).

+#### Single sign-on recommended reading

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

+### Migration of AD FS applications to Azure AD

+[Migrating apps from AD FS to Azure AD](../manage-apps/migrate-adfs-apps-to-azure.md) enables additional capabilities on security, more consistent manageability, and a better collaboration experience. If you have applications configured in AD FS that support SSO with Azure AD, then you should reconfigure those applications to use SSO with Azure AD. If you have applications configured in AD FS with uncommon configurations unsupported by Azure AD, you should contact the app owners to understand if the special configuration is an absolute requirement of the application. If it isn't required, then you should reconfigure the application to use SSO with Azure AD.

+

+> [!NOTE]

+> [Azure AD Connect Health for ADFS](../hybrid/how-to-connect-health-adfs.md) can be used to collect configuration details about each application that can potentially be migrated to Azure AD.

+### Assign users to applications

+[Assigning users to applications](../manage-apps/assign-user-or-group-access-portal.md) is best mapped by using groups because they allow greater flexibility and ability to manage at scale. The benefits of using groups include [attribute-based dynamic group membership](../enterprise-users/groups-dynamic-membership.md) and [delegation to app owners](../fundamentals/active-directory-accessmanagement-managing-group-owners.md). Therefore, if you're already using and managing groups, we recommend you take the following actions to improve management at scale:

+- Delegate group management and governance to application owners.

+- Allow self-service access to the application.

+- Define dynamic groups if user attributes can consistently determine access to applications.

+- Implement attestation to groups used for application access using [Azure AD access reviews](../governance/access-reviews-overview.md).

+On the other hand, if you find applications that have assignment to individual users, be sure to implement [governance](../governance/index.yml) around those applications.

+#### Assign users to applications recommended reading

+- [Assign users and groups to an application in Azure Active Directory](../manage-apps/assign-user-or-group-access-portal.md)

+- [Delegate app registration permissions in Azure Active Directory](../roles/delegate-app-roles.md)

+- [Dynamic membership rules for groups in Azure Active Directory](../enterprise-users/groups-dynamic-membership.md)

+## Access policies

+### Named locations

+With [named locations](../conditional-access/location-condition.md) in Azure AD, you can label trusted IP address ranges in your organization. Azure AD uses named locations to:

+- Prevent false positives in risk events. Signing in from a trusted network location lowers a user's sign-in risk.

+- Configure [location-based Conditional Access](../conditional-access/location-condition.md).

+

+Based on priority, use the table below to find the recommended solution that best meets your organization's needs:

+| **Priority** | **Scenario** | **Recommendation** |

+| | -- | -- |

+| 1 | If you use PHS or PTA and named locations haven't been defined | Define named locations to improve detection of risk events |

+| 2 | If you're federated and don't use "insideCorporateNetwork" claim and named locations haven't been defined | Define named locations to improve detection of risk events |

+| 3 | If you don't use named locations in conditional access policies and there's no risk or device controls in conditional access policies | Configure the conditional access policy to include named locations |

+| 4 | If you're federated and do use "insideCorporateNetwork" claim and named locations haven't been defined | Define named locations to improve detection of risk events |

+| 5 | If you're using trusted IP addresses with MFA rather than named locations and marking them as trusted | Define named locations and mark them as trusted to improve detection of risk events |

+### Risk-based access policies

+Azure AD can calculate the risk for every sign-in and every user. Using risk as a criterion in access policies can provide a better user experience, for example, fewer authentication prompts, and better security, for example, only prompt users when they're needed, and automate the response and remediation.

+

+If you already own Azure AD Premium P2 licenses that support using risk in access policies, but they aren't being used, we highly recommend adding risk to your security posture.

+#### Risk-based access policies recommended reading

+- [How To: Configure the sign-in risk policy](../identity-protection/howto-identity-protection-configure-risk-policies.md)

+- [How To: Configure the user risk policy](../identity-protection/howto-identity-protection-configure-risk-policies.md)

+### Client application access policies

+Microsoft Intune Application Management (MAM) provides the ability to push data protection controls such as storage encryption, PIN, remote storage cleanup, etc. to compatible client mobile applications such as Outlook Mobile. In addition, conditional access policies can be created to [restrict access](../conditional-access/app-based-conditional-access.md) to cloud services such as Exchange Online from approved or compatible apps.

+If your employees install MAM-capable applications such as Office mobile apps to access corporate resources such as Exchange Online or SharePoint Online, and you also support BYOD (bring your own device), we recommend you deploy application MAM policies to manage the application configuration in personally owned devices without MDM enrollment and then update your conditional access policies to only allow access from MAM-capable clients.

+

+Should employees install MAM-capable applications against corporate resources and access is restricted on Intune Managed devices, then you should consider deploying application MAM policies to manage the application configuration for personal devices, and update Conditional Access policies to only allow access from MAM capable clients.

+### Conditional Access implementation

+Conditional Access is an essential tool for improving the security posture of your organization. Therefore, it is important you follow these best practices:

+- Ensure that all SaaS applications have at least one policy applied

+- Avoid combining the **All apps** filter with the **block** control to avoid lockout risk

+- Avoid using the **All users** as a filter and inadvertently adding **Guests**

+- **Migrate all "legacy" policies to the Azure portal**

+- Catch all criteria for users, devices, and applications

+- Use Conditional Access policies to [implement MFA](../conditional-access/plan-conditional-access.md), rather than using a **per-user MFA**

+- Have a small set of core policies that can apply to multiple applications

+- Define empty exception groups and add them to the policies to have an exception strategy

+- Plan for [break glass](../roles/security-planning.md#break-glass-what-to-do-in-an-emergency) accounts without MFA controls

+- Ensure a consistent experience across Microsoft 365 client applications, for example, Teams, OneDrive, Outlook, etc.) by implementing the same set of controls for services such as Exchange Online and SharePoint Online

+- Assignment to policies should be implemented through groups, not individuals

+- Do regular reviews of the exception groups used in policies to limit the time users are out of the security posture. If you own Azure AD Premium P2, then you can use access reviews to automate the process

+#### Conditional Access recommended reading

+- [Best practices for Conditional Access in Azure Active Directory](../conditional-access/overview.md)

+- [Identity and device access configurations](/microsoft-365/enterprise/microsoft-365-policies-configurations)

+- [Azure Active Directory Conditional Access settings reference](../conditional-access/concept-conditional-access-conditions.md)

+- [Common Conditional Access policies](../conditional-access/concept-conditional-access-policy-common.md)

+## Access surface area

+### Legacy authentication

+Strong credentials such as MFA cannot protect apps using legacy authentication protocols, which make it the preferred attack vector by malicious actors. Locking down legacy authentication is crucial to improve the access security posture.

+Legacy authentication is a term that refers to authentication protocols used by apps like:

+- Older Office clients that don't use modern authentication (for example, Office 2010 client)

+- Clients that use mail protocols such as IMAP/SMTP/POP

+Attackers strongly prefer these protocols - in fact, nearly [100% of password spray attacks](https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Your-Pa-word-doesn-t-matter/ba-p/731984) use legacy authentication protocols! Hackers use legacy authentication protocols, because they don't support interactive sign-in, which is needed for additional security challenges like multi-factor authentication and device authentication.

+If legacy authentication is widely used in your environment, you should plan to migrate legacy clients to clients that support [modern authentication](/office365/enterprise/modern-auth-for-office-2013-and-2016) as soon as possible. In the same token, if you have some users already using modern authentication but others that still use legacy authentication, you should take the following steps to lock down legacy authentication clients:

+1. Use [Sign-In Activity reports](../reports-monitoring/concept-sign-ins.md) to identify users who are still using legacy authentication and plan remediation:

+ a. Upgrade to modern authentication capable clients to affected users.

+

+ b. Plan a cutover timeframe to lock down per steps below.

+

+ c. Identify what legacy applications have a hard dependency on legacy authentication. See step 3 below.

+2. Disable legacy protocols at the source (for example Exchange Mailbox) for users who aren't using legacy auth to avoid more exposure.

+3. For the remaining accounts (ideally non-human identities such as service accounts), use [conditional access to restrict legacy protocols](https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Azure-AD-Conditional-Access-support-for-blocking-legacy-auth-is/ba-p/245417) post-authentication.

+#### Legacy authentication recommended reading

+- [Enable or disable POP3 or IMAP4 access to mailboxes in Exchange Server](/exchange/clients/pop3-and-imap4/configure-mailbox-access)

+### Consent grants

+In an illicit consent grant attack, the attacker creates an Azure AD-registered application that requests access to data such as contact information, email, or documents. Users might be granting consent to malicious applications via phishing attacks when landing on malicious websites.

+Below are a list of apps with permissions you might want to scrutinize for Microsoft cloud

+- Apps with app or delegated \*.ReadWrite Permissions

+- Apps with delegated permissions can read, send, or manage email on behalf of the user

+- Apps that are granted the using the following permissions:

+| Resource | Permission |

+| :- | :- |

+| Exchange Online | EAS.AccessAsUser.All |

+| | EWS.AccessAsUser.All |

+| | Mail.Read |

+| Microsoft Graph API | Mail.Read |

+| | Mail.Read.Shared |

+| | Mail.ReadWrite |

+- Apps granted full user impersonation of the signed-in user. For example:

+|Resource | Permission |

+| :- | :- |

+| Microsoft Graph API| Directory.AccessAsUser.All |

+| Azure REST API | user_impersonation |

+To avoid this scenario, you should refer to [detect and remediate illicit consent grants in Office 365](/office365/securitycompliance/detect-and-remediate-illicit-consent-grants) to identify and fix any applications with illicit grants or applications that have more grants than are necessary. Next, [remove self-service altogether](../manage-apps/configure-user-consent.md) and [establish governance procedures](../manage-apps/configure-admin-consent-workflow.md). Finally, schedule regular reviews of app permissions and remove them when they are not needed.

+#### Consent grants recommended reading

+- [Overview of Microsoft Graph permissions](/graph/permissions-overview)

+- [Microsoft Graph API permissions](/graph/permissions-reference)

+### User and group settings

+Below are the user and group settings that can be locked down if there isn't an explicit business need:

+#### User settings

+- **External Users** - external collaboration can happen organically in the enterprise with services like Teams, Power BI, SharePoint Online, and Azure Information Protection. If you have explicit constraints to control user-initiated external collaboration, it is recommended you enable external users by using [Azure AD Entitlement management](../governance/entitlement-management-overview.md) or a controlled operation such as through your help desk. If you don't want to allow organic external collaboration for services, you can [block members from inviting external users completely](../external-identities/external-collaboration-settings-configure.md). Alternatively, you can also [allow or block specific domains](../external-identities/allow-deny-list.md) in external user invitations.

+- **App Registrations** - when App registrations are enabled, end users can onboard applications themselves and grant access to their data. A typical example of App registration is users enabling Outlook plug-ins, or voice assistants such as Alexa and Siri to read their email and calendar or send emails on their behalf. If the customer decides to turn off App registration, the InfoSec and IAM teams must be involved in the management of exceptions (app registrations that are needed based on business requirements), as they would need to register the applications with an admin account, and most likely require designing a process to operationalize the process.

+- **Administration Portal** - organizations can lock down the Azure AD blade in the Azure portal so that non-administrators can't access Azure AD management in the Azure portal and get confused. Go to the user settings in the Azure AD management portal to restrict access:

+

+> [!NOTE]

+> Non-administrators can still access to the Azure AD management interfaces via command-line and other programmatic interfaces.

+#### Group settings

+**Self-Service Group Management / Users can create Security groups / Microsoft 365 groups.** If there's no current self-service initiative for groups in the cloud, customers might decide to turn it off until they're ready to use this capability.

+#### Groups recommended reading

+- [What is Azure Active Directory B2B collaboration?](../external-identities/what-is-b2b.md)

+- [Integrating Applications with Azure Active Directory](../develop/quickstart-register-app.md)

+- [Apps, permissions, and consent in Azure Active Directory.](../develop/quickstart-register-app.md)

+- [Use groups to manage access to resources in Azure Active Directory](./active-directory-manage-groups.md)

+- [Setting up self-service application access management in Azure Active Directory](../enterprise-users/groups-self-service-management.md)

+### Traffic from unexpected locations

+Attackers originate from various parts of the world. Manage this risk by using conditional access policies with location as the condition. The [location condition](../conditional-access/location-condition.md) of a Conditional Access policy enables you to block access for locations from where there's no business reason to sign in from.

+

+If available, use a security information and event management (SIEM) solution to analyze and find patterns of access across regions. If you don't use a SIEM product, or it isn't ingesting authentication information from Azure AD, we recommend you use [Azure Monitor](../../azure-monitor/overview.md) to identify patterns of access across regions.

+## Access usage

+### Azure AD logs archived and integrated with incident response plans

+Having access to sign-in activity, audits and risk events for Azure AD is crucial for troubleshooting, usage analytics, and forensics investigations. Azure AD provides access to these sources through REST APIs that have a limited retention period. A security information and event management (SIEM) system, or equivalent archival technology, is key for long-term storage of audits and supportability. To enable long-term storage of Azure AD Logs, you must either add them to your existing SIEM solution or use [Azure Monitor](../reports-monitoring/concept-activity-logs-azure-monitor.md). Archive logs that can be used as part of your incident response plans and investigations.

+#### Logs recommended reading

+- [Azure Active Directory audit API reference](/graph/api/resources/directoryaudit)

+- [Azure Active Directory sign-in activity report API reference](/graph/api/resources/signin)

+- [Get data using the Azure AD Reporting API with certificates](../reports-monitoring/tutorial-access-api-with-certificates.md)

+- [Microsoft Graph for Azure Active Directory Identity Protection](../identity-protection/howto-identity-protection-graph-api.md)

+- [Office 365 Management Activity API reference](/office/office-365-management-api/office-365-management-activity-api-reference)

+- [How to use the Azure Active Directory Power BI Content Pack](../reports-monitoring/howto-use-azure-monitor-workbooks.md)

+## Summary

+There are 12 aspects to a secure Identity infrastructure. This list will help you further secure and manage credentials, define authentication experience, delegate assignment, measure usage, and define access policies based on enterprise security posture.

+- Assign owners to key tasks.

+- Implement solutions to detect weak or leaked passwords, improve password management and protection, and further secure user access to resources.

+- Manage the identity of devices to protect your resources at any time and from any location.

+- Implement passwordless authentication.

+- Provide a standardized single sign-on mechanism across the organization.

+- Migrate apps from AD FS to Azure AD to enable better security and more consistent manageability.

+- Assign users to applications by using groups to allow greater flexibility and ability to manage at scale.

+- Configure risk-based access policies.

+- Lock down legacy authentication protocols.

+- Detect and remediate illicit consent grants.

+- Lock down user and group settings.

+- Enable long-term storage of Azure AD logs for troubleshooting, usage analytics, and forensics investigations.

+## Next steps

+Get started with the [Identity governance operational checks and actions](ops-guide-govern.md).

+ Title: Azure Active Directory governance operations reference guide

+description: This operations reference guide describes the checks and actions you should take to secure governance management

+tags: azuread

+# Azure Active Directory governance operations reference guide

+This section of the [Azure AD operations reference guide](active-directory-ops-guide-intro.md) describes the checks and actions you should take to assess and attest the access granted nonprivileged and privileged identities, audit, and control changes to the environment.

+> [!NOTE]

+> These recommendations are current as of the date of publishing but can change over time. Organizations should continuously evaluate their governance practices as Microsoft products and services evolve over time.

+## Key operational processes

+### Assign owners to key tasks

+Managing Azure Active Directory requires the continuous execution of key operational tasks and processes, which may not be part of a rollout project. It's still important you set up these tasks to optimize your environment. The key tasks and their recommended owners include:

+| Task | Owner |

+| :- | :- |

+| Archive Azure AD audit logs in SIEM system | InfoSec Operations Team |

+| Discover applications that are managed out of compliance | IAM Operations Team |

+| Regularly review access to applications | InfoSec Architecture Team |

+| Regularly review access to external identities | InfoSec Architecture Team |

+| Regularly review who has privileged roles | InfoSec Architecture Team |

+| Define security gates to activate privileged roles | InfoSec Architecture Team |

+| Regularly review consent grants | InfoSec Architecture Team |

+| Design Catalogs and Access Packages for applications and resources based for employees in the organization | App Owners |

+| Define Security Policies to assign users to access packages | InfoSec team + App Owners |

+| If policies include approval workflows, regularly review workflow approvals | App Owners |

+| Review exceptions in security policies, such as conditional access policies, using access reviews | InfoSec Operations Team |

+As you review your list, you may find you need to either assign an owner for tasks that are missing an owner or adjust ownership for tasks with owners that aren't aligned with the recommendations above.

+#### Owner recommended reading

+- [Assigning administrator roles in Azure Active Directory](../roles/permissions-reference.md)

+### Configuration changes testing

+There are changes that require special considerations when testing, from simple techniques such as rolling out a target subset of users to deploying a change in a parallel test tenant. If you haven't implemented a testing strategy, you should define a test approach based on the guidelines in the table below:

+| Scenario| Recommendation |

+|-|-|

+|Changing the authentication type from federated to PHS/PTA or vice-versa| Use [staged rollout](../hybrid/how-to-connect-staged-rollout.md) to test the impact of changing the authentication type.|

+|Rolling out a new conditional access (CA) policy or Identity Protection Policy|Create a new Conditional Access policy and assign to test users.|

+|Onboarding a test environment of an application|Add the application to a production environment, hide it from the MyApps panel, and assign it to test users during the quality assurance (QA) phase.|

+|Changing of sync rules|Perform the changes in a test Azure AD Connect with the same configuration that is currently in production, also known as staging mode, and analyze CSExport Results. If satisfied, swap to production when ready.|

+|Changing of branding|Test in a separate test tenant.|

+|Rolling out a new feature|If the feature supports roll out to a target set of users, identify pilot users and build out. For example, self-service password reset and multi-factor authentication can target specific users or groups.|

+|Cutover an application from an on-premises Identity provider (IdP), for example, Active Directory, to Azure AD|If the application supports multiple IdP configurations, for example, Salesforce, configure both and test Azure AD during a change window (in case the application introduces HRD page). If the application doesn't support multiple IdPs, schedule the testing during a change control window and program downtime.|

+|Update dynamic group rules|Create a parallel dynamic group with the new rule. Compare against the calculated outcome, for example, run PowerShell with the same condition.<br>If test pass, swap the places where the old group was used (if feasible).|

+|Migrate product licenses|Refer to [Change the license for a single user in a licensed group in Azure Active Directory](../enterprise-users/licensing-groups-change-licenses.md).|

+|Change AD FS rules such as Authorization, Issuance, MFA|Use group claim to target subset of users.|

+|Change AD FS authentication experience or similar farm-wide changes|Create a parallel farm with same host name, implement config changes, test from clients using HOSTS file, NLB routing rules, or similar routing.<br>If the target platform doesn't support HOSTS files (for example mobile devices), control change.|

+## Access reviews

+### Access reviews to applications

+Over time, users may accumulate access to resources as they move throughout different teams and positions. It's important that resource owners review the access to applications on a regular basis and remove privileges that are no longer needed throughout the lifecycle of users. Azure AD [access reviews](../governance/access-reviews-overview.md) enable organizations to efficiently manage group memberships, access to enterprise applications, and role assignments. Resource owners should review users' access on a regular basis to make sure only the right people have continued access. Ideally, you should consider using Azure AD access reviews for this task.

+

+> [!NOTE]

+> Each user who interacts with access reviews must have a paid Azure AD Premium P2 license.

+### Access reviews to external identities

+It's crucial to keep access to external identities constrained only to resources that are needed, during the time that is needed. Establish a regular automated access review process for all external identities and application access using Azure AD [access reviews](../governance/access-reviews-overview.md). If a process already exists on-premises, consider using Azure AD access reviews. Once an application is retired or no longer used, remove all the external identities that had access to the application.

+> [!NOTE]

+> Each user who interacts with access reviews must have a paid Azure AD Premium P2 license.

+## Privileged account management

+### Privileged account usage

+Hackers often target admin accounts and other elements of privileged access to rapidly gain access to sensitive data and systems. Since users with privileged roles tend to accumulate over time, it's important to review and manage admin access on a regular basis and provide just-in-time privileged access to Azure AD and Azure resources.

+If no process exists in your organization to manage privileged accounts, or you currently have admins who use their regular user accounts to manage services and resources, you should immediately begin using separate accounts, for example one for regular day-to-day activities; the other for privileged access and configured with MFA. Better yet, if your organization has an Azure AD Premium P2 subscription, then you should immediately deploy [Azure AD Privileged Identity Management](../privileged-identity-management/pim-configure.md#license-requirements) (PIM). In the same token, you should also review those privileged accounts and [assign less privileged roles](../roles/security-planning.md) if applicable.

+Another aspect of privileged account management that should be implemented is in defining [access reviews](../governance/access-reviews-overview.md) for those accounts, either manually or [automated through PIM](../privileged-identity-management/pim-perform-azure-ad-roles-and-resource-roles-review.md).

+#### Privileged account management recommended reading

+- [Roles in Azure AD Privileged Identity Management](../privileged-identity-management/pim-roles.md)

+### Emergency access accounts

+Organizations must create [emergency accounts](../roles/security-emergency-access.md) to be prepared to manage Azure AD for cases such as authentication outages like:

+- Outage components of authentication infrastructures (AD FS, On-premises AD, MFA service)

+- Administrative staff turnover

+To prevent being inadvertently locked out of your tenant because you can't sign in or activate an existing individual user's account as an administrator, you should create two or more emergency accounts and ensure they're implemented and aligned with [Microsoft's best practices](../roles/security-planning.md) and [break glass procedures](../roles/security-planning.md#break-glass-what-to-do-in-an-emergency).

+### Privileged access to Azure EA portal

+The [Azure Enterprise Agreement (Azure EA) portal](https://azure.microsoft.com/blog/create-enterprise-subscription-experience-in-azure-portal-public-preview/) enables you to create Azure subscriptions against a master Enterprise Agreement, which is a powerful role within the enterprise. It's common to bootstrap the creation of this portal before even getting Azure AD in place, so it's necessary to use Azure AD identities to lock it down, remove personal accounts from the portal, ensure that proper delegation is in place, and mitigate the risk of lockout.

+To be clear, if the EA portal authorization level is currently set to "mixed mode", you must remove any [Microsoft accounts](https://support.skype.com/en/faq/FA12059/what-is-a-microsoft-account) from all privileged access in the EA portal and configure the EA portal to use Azure AD accounts only. If the EA portal delegated roles aren't configured, you should also find and implement delegated roles for departments and accounts.

+#### Privileged access recommended reading

+- [Administrator role permissions in Azure Active Directory](../roles/permissions-reference.md)

+## Entitlement management

+[Entitlement management (EM)](../governance/entitlement-management-overview.md) allows app owners to bundle resources and assign them to specific personas in the organization (both internal and external). EM allows self-service sign up and delegation to business owners while keeping governance policies to grant access, set access durations, and allow approval workflows.

+> [!NOTE]

+> Azure AD Entitlement Management requires Azure AD Premium P2 licenses.

+## Summary

+There are eight aspects to a secure Identity governance. This list will help you identify the actions you should take to assess and attest the access granted to nonprivileged and privileged identities, audit, and control changes to the environment.

+- Assign owners to key tasks.

+- Implement a testing strategy.

+- Use Azure AD Access Reviews to efficiently manage group memberships, access to enterprise applications, and role assignments.

+- Establish a regular, automated access review process for all types of external identities and application access.

+- Establish an access review process to review and manage admin access on a regular basis and provide just-in-time privileged access to Azure AD and Azure resources.

+- Provision emergency accounts to be prepared to manage Azure AD for unexpected outages.

+- Lock down access to the Azure EA portal.

+- Implement Entitlement Management to provide governed access to a collection of resources.

+## Next steps

+Get started with the [Azure AD operational checks and actions](active-directory-ops-guide-ops.md).

+- [Integrate all your apps with Azure AD](five-steps-to-full-application-integration.md)

+ Title: Introduction to securing Azure Active Directory service accounts

+description: Explanation of the types of service accounts available in Azure Active Directory.

+# Securing cloud-based service accounts

+There are three types of service accounts native to Azure Active Directory: Managed identities, service principals, and user-based service accounts. Service accounts are a special type of account that is intended to represent a non-human entity such as an application, API, or other service. These entities operate within the security context provided by the service account.

+## Types of Azure Active Directory service accounts

+For services hosted in Azure, we recommend using a managed identity if possible, and a service principal if not. Managed identities can't be used for services hosted outside of Azure. In that case, we recommend a service principal. If you can use a managed identity or a service principal, do so. We recommend that you not use an Azure Active Directory user account as a service account. See the following table for a summary.

+| Service hosting| Managed identity| Service principal| Azure user account |

+| - | - | - | - |

+|Service is hosted in Azure.| Yes. <br>Recommended if the service <br>supports a Managed Identity.| Yes.| Not recommended. |

+| Service is not hosted in Azure.| No| Yes. Recommended.| Not recommended. |

+| Service is multi-tenant| No| Yes. Recommended.| No. |

+## Managed identities

+Managed identities are secure Azure Active Directory (Azure AD) identities created to provide identities for Azure resources. There are [two types of managed identities](../managed-identities-azure-resources/overview.md#managed-identity-types):

+

+* System-assigned managed identities can be assigned directly to an instance of a service.

+* User-assigned managed identities can be created as a standalone resource.

+For more information, see [Securing managed identities](service-accounts-managed-identities.md). For general information about managed identities, see [What are managed identities for Azure resources?](../managed-identities-azure-resources/overview.md)

+## Service principals

+If you can't use a managed identity to represent your application, use a service principal. Service principals can be used with both single tenant and multi-tenant applications.

+A service principal is the local representation of an application object in a single Azure AD tenant. It functions as the identity of the application instance, defines who can access the application, and what resources the application can access. A service principal is created in (local to) each tenant where the application is used and references the globally unique application object. The tenant secures the service principal's sign-in and access to resources.

+There are two mechanisms for authentication using service principalsΓÇöclient certificates and client secrets. Certificates are more secure: use client certificates if possible. Unlike client secrets, client certificates cannot accidentally be embedded in code.

+For information on securing service principals, see [Securing service principals](service-accounts-principal.md).

+

+## Next steps

+For more information on securing Azure service accounts, see:

+[Securing managed identities](service-accounts-managed-identities.md)

+[Securing service principals](service-accounts-principal.md)

+[Governing Azure service accounts](govern-service-accounts.md)

+Below are some specific recommendations for Azure solutions. For general guidance on Conditional Access policies for individual environments, check the [CA Best practices](../conditional-access/overview.md), [Azure AD Operations Guide](../fundamentals/ops-guide-auth.md), and [Conditional Access for Zero Trust](/azure/architecture/guide/security/conditional-access-zero-trust):

+ 

+

+ 

+* [Securing cloud-based service accounts](secure-service-accounts.md)

+* [Governing Azure AD service accounts](govern-service-accounts.md)

+

+

+* [Securing cloud-based service accounts](secure-service-accounts.md)

+* [Governing Azure AD service accounts](govern-service-accounts.md)

+ 

+ Title: What's deprecated in Azure Active Directory?

+description: Learn about features being deprecated in Azure Active Directory

+# What's deprecated in Azure Active Directory?

+The lifecycle of functionality, features, and services are governed by policy, support timelines, data, also leadership and engineering team decisions. Lifecycle information allows customers to predictably plan long-term deployment aspects, transition from outdated to new technology, and help improve business outcomes. Use the definitions below to understand the following table with change information about Azure Active Directory (Azure AD) features, services, and functionality.

+Get notified about when to revisit this page for updates by copying and pasting this URL: `https://learn.microsoft.com/api/search/rss?search=%22What's+deprecated+in+Azure+Active+Directory%22&locale=en-us` into your  feed reader.

+## Upcoming changes

+Use the following table to learn about changes including deprecations, retirements, breaking changes and rebranding. Also find key dates and recommendations.

+ > [!NOTE]

+ > Dates and times are United States Pacific Standard Time, and are subject to change.

+|Functionality, feature, or service|Change|Change date |

+|||:|

+|[My Groups experience](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-march-2023-train/ba-p/2967448)|Feature change|May 2023|

+|[My Apps browser extension](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-march-2023-train/ba-p/2967448)|Feature change|May 2023|

+|[Microsoft Authenticator Lite for Outlook mobile](../../active-directory/authentication/how-to-mfa-authenticator-lite.md)|Feature change|Jun 9, 2023|

+|[System-preferred authentication methods](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-march-2023-train/ba-p/2967448)|Feature change|Sometime after GA|

+|[Azure AD Authentication Library (ADAL)](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-march-2023-train/ba-p/2967448)|Retirement|Jun 30, 2023|

+|[Azure AD Graph API](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-march-2023-train/ba-p/2967448)|Deprecation|Jun 30, 2023|

+|[Azure AD PowerShell and MSOnline PowerShell](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-march-2023-train/ba-p/2967448)|Deprecation|Jun 30, 2023|

+|[My Apps improvements](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-march-2023-train/ba-p/2967448)|Feature change|Jun 30, 2023|

+|[Terms of Use experience](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-march-2023-train/ba-p/2967448)|Feature change|Jul 2023|

+|[Azure AD MFA Server](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-march-2023-train/ba-p/2967448)|Retirement|Sep 30, 2024|

+|[Legacy MFA & SSPR policy](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-march-2023-train/ba-p/2967448)|Retirement|Sep 30, 2024|

+|['Require approved client app' Conditional Access Grant](https://aka.ms/RetireApprovedClientApp)|Retirement|Mar 31, 2026|

+## Past changes

+|Functionality, feature, or service|Change|Change date |

+|||:|

+|Microsoft Authenticator app [Number matching](../authentication/how-to-mfa-number-match.md)|Feature change|May 8, 2023|

+|[Azure AD Domain Services virtual network deployments](../../active-directory-domain-services/overview.md)|Retirement|Mar 1, 2023|

+|[License management API, PowerShell](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/migrate-your-apps-to-access-the-license-managements-apis-from/ba-p/2464366)|Retirement|*Mar 31, 2023|

+\* The legacy license management API and PowerShell cmdlets won't work for **new tenants** created after Nov 1, 2022.

+ > [!IMPORTANT]

+ > Later versions of functionality, features, and services might not meet current security requirements. Microsoft may be unable to provide security updates for older products.

+See the following two sections for definitions of categories, change state, etc.

+## Deprecation, retirement, breaking change, feature change, and rebranding

+Use the definitions in this section help clarify the state, availability, and support of features, services, and functionality.

+|Category|Definition|Communication schedule|

+||||

+|Retirement|Signals retirement of a feature, capability, or product in a specified period. Customers can't adopt the service or feature, and engineering investments are reduced. Later, the feature reaches end-of-life and is unavailable to any customer.|Two times per year: March and September|

+|Breaking change|A change that might break the customer or partner experience if action isn't taken, or a change made, for continued operation.|Four times per year: March, June, September, and December|

+|Feature change|Change to an existing Identity feature that requires no customer action, but is noticeable to them. Typically, these changes are in the user interface/user experperience (UI/UX).|Four times per year: March, June, September, and December|

+### Terminology

+* **End-of-life** - engineering investments have ended, and the feature is unavailable to any customer

+## Next steps

+[What's new in Azure Active Directory?](../../active-directory/fundamentals/whats-new.md)

+## Resources

+* [Microsoft Entra Change Announcement blog](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-november-2022-train/ba-p/2967452)

+* Devices: [End-of-life management and recycling](https://www.microsoft.com/legal/compliance/recycling)

+### General Availability - Devices Self-Help Capability for Pending Devices

+The offset determines how many days before or after the time-based attribute the workflow should be triggered. For example, if the attribute is employeeHireDate and offsetInDays is 7, then the workflow should trigger one week(7 days) before the employee hire date. The offsetInDays value can be as far ahead, or behind, as 180.

+> [!NOTE]

+> The offsetInDays value in the Azure portal is shown as *Days from event*. When you schedule a workflow to run, this value is used as the baseline for who a workflow will run. Currently there is a 3 day window in processing scheduled workflows. For example, if you schedule a workflow to run for users who joined 7 days ago, a user who meets the execution conditions for the workflow, but joined between 7 to 10 days ago would have the workflow ran for them.

+>Classic VPNs remain network orientated, often providing little to no fine-grained access to corporate applications. We encourage a more identity-centric approach to achieve Zero Trust. Learn more: [Five steps for integrating all your apps with Azure AD](../fundamentals/five-steps-to-full-application-integration.md).

+- [Five steps to full application integration with Azure AD](../fundamentals/five-steps-to-full-application-integration.md)

+Listing an **SAML 2.0 or WS-Fed application** in the gallery takes 7 to 10 business days.

+Listing an **OpenID Connect application** in the gallery takes 2 to 5 business days.

+Listing an **SCIM provisioning application** in the gallery varies, depending on numerous factors.

+#### Deprovisioning

+Does cross-tenant synchronization support deprovisioning users?

+- Yes, when the below actions occur in the source tenant, the user will be [soft deleted](../fundamentals/recover-from-deletions.md#soft-deletions) in the target tenant.

+ - Delete the user in the source tenant

+ - Unassign the user from the cross-tenant synchronization configuration

+ - Remove the user from a group that is assigned to the cross-tenant synchronization configuration

+ - An attribute on the user changes such that they do not meet the scoping filter conditions defined on the cross-tenant synchronization configuration anymore

+- Currently only regular users, Helpdesk Admins and User Account Admins can be deleted. Users with other Azure AD roles such as directory reader currently cannot be deleted by cross-tenant synchronization. This is subject to change in the future.

+- If the user is blocked from sign-in in the source tenant (accountEnabled = false) they will be blocked from sign-in in the target. This is not a deletion, but an updated to the accountEnabled property.

+Does cross-tenant synchronization support restoring users?

+- If the user in the source tenant is restored, reassigned to the app, meets the scoping condition again within 30 days of soft deletion, it will be restored in the target tenant.

+- IT admins can also manually [restore](/azure/active-directory/fundamentals/active-directory-users-restore

+../fundamentals/active-directory-users-restore.md) the user directly in the target tenant.

+How can I deprovision all the users that are currently in scope of cross-tenant synchronization?

+- Unassign all users and / or groups from the cross-tenant synchronization configuration. This will trigger all the users that were unassigned, either directly or through group membership, to be deprovisioned in subsequent sync cycles. Please note that the target tenant will need to keep the inbound policy for sync enabled until deprovisioning is complete. If the scope is set to **Sync all users and groups**, you will also need to change it to **Sync only assigned users and groups**. The users will be automatically soft deleted by cross-tenant synchronization. The users will be automatically hard deleted after 30 days or you can choose to hard delete the users directly from the target tenant. You can choose to hard delete the users directly in the target tenant or wait 30 days for the users to be automatically hard deleted.

+If the sync relationship is severed, are external users previously managed by cross-tenant synchronization deleted in the target tenant?

+- No. No changes are made to the external users previously managed by cross-tenant synchronization if the relationship is severed (for example, if the cross-tenant synchronization policy is deleted).

+ - To ensure you have the right access, review the Azure workspace permissions in the [Manage access to Log Analytics workspaces](../../azure-monitor/logs/manage-access.md?tabs=tabs=portal#azure-rbac) article.

+ - **Public Templates**: Prebuilt workbooks for common or high priority scenarios

+Using administrative units requires an Azure AD Premium P1 license for each administrative unit administrator who is assigned directory roles over the scope of the administrative unit, and an Azure AD Free license for each administrative unit member. Creating administrative units is available with an Azure AD Free license. If you are using dynamic membership rules for administrative units, each administrative unit member requires an Azure AD Premium P1 license. To find the right license for your requirements, see [Comparing generally available features of the Free and Premium editions](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing).

+> | [Disable per-user MFA](../authentication/howto-mfa-userstates.md) | [Authentication Administrator](permissions-reference.md#authentication-administrator) | [Privileged Authentication Administrator](permissions-reference.md#privileged-authentication-administrator) |

+> | [Enable per-user MFA](../authentication/howto-mfa-userstates.md) | [Authentication Administrator](permissions-reference.md#authentication-administrator) | [Privileged Authentication Administrator](permissions-reference.md#privileged-authentication-administrator) |

+ Title: 'Tutorial: Configure Funnel Leasing for automatic user provisioning with Azure Active Directory'

+description: Learn how to automatically provision and de-provision user accounts from Azure AD to Funnel Leasing.

+writer: twimmers

+ms.assetid: 320d5135-3833-4a65-9fc5-7e50709dd6ff

+# Tutorial: Configure Funnel Leasing for automatic user provisioning

+This tutorial describes the steps you need to perform in both Funnel Leasing and Azure Active Directory (Azure AD) to configure automatic user provisioning. When configured, Azure AD automatically provisions and de-provisions users to [Funnel Leasing](https://funnelleasing.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).

+## Supported capabilities

+> [!div class="checklist"]

+> * Create users in Funnel Leasing.

+> * Remove users in Funnel Leasing when they do not require access anymore.

+> * Keep user attributes synchronized between Azure AD and Funnel Leasing.

+> * [Single sign-on](../manage-apps/add-application-portal-setup-oidc-sso.md) to Funnel Leasing (recommended).

+## Prerequisites

+The scenario outlined in this tutorial assumes that you already have the following prerequisites:

+* [An Azure AD tenant](../develop/quickstart-create-new-tenant.md)

+* A user account in Azure AD with [permission](../roles/permissions-reference.md) to configure provisioning (for example, Application Administrator, Cloud Application administrator, Application Owner, or Global Administrator).

+* A user account in Funnel Leasing with Admin permissions.

+## Step 1. Plan your provisioning deployment

+1. Learn about [how the provisioning service works](../app-provisioning/user-provisioning.md).

+1. Determine who will be in [scope for provisioning](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

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

+## Step 2. Configure Funnel Leasing to support provisioning with Azure AD

+Contact Funnel Leasing support to configure Funnel Leasing to support provisioning with Azure AD.

+## Step 3. Add Funnel Leasing from the Azure AD application gallery

+Add Funnel Leasing from the Azure AD application gallery to start managing provisioning to Funnel Leasing. If you have previously setup Funnel Leasing for SSO you can use the same application. However it's recommended that you create a separate app when testing out the integration initially. Learn more about adding an application from the gallery [here](../manage-apps/add-application-portal.md).

+## Step 4. Define who will be in scope for provisioning

+The Azure AD provisioning service allows you to scope who will be provisioned based on assignment to the application and or based on attributes of the user. If you choose to scope who will be provisioned to your app based on assignment, you can use the following [steps](../manage-apps/assign-user-or-group-access-portal.md) to assign users to the application. If you choose to scope who will be provisioned based solely on attributes of the user, you can use a scoping filter as described [here](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+* Start small. Test with a small set of users before rolling out to everyone. When scope for provisioning is set to assigned users, you can control this by assigning one or two users to the app. When scope is set to all users, you can specify an [attribute based scoping filter](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+* If you need more roles, you can [update the application manifest](../develop/howto-add-app-roles-in-azure-ad-apps.md) to add new roles.

+## Step 5. Configure automatic user provisioning to Funnel Leasing

+This section guides you through the steps to configure the Azure AD provisioning service to create, update, and disable users in TestApp based on user assignments in Azure AD.

+### To configure automatic user provisioning for Funnel Leasing in Azure AD:

+1. Sign in to the [Azure portal](https://portal.azure.com). Select **Enterprise Applications**, then select **All applications**.

+ 

+1. In the applications list, select **Funnel Leasing**.

+ 

+1. Select the **Provisioning** tab.

+ 

+1. Set the **Provisioning Mode** to **Automatic**.

+ 

+1. Under the **Admin Credentials** section, input your Funnel Leasing Tenant URL and Secret Token. Click **Test Connection** to ensure Azure AD can connect to Funnel Leasing. If the connection fails, ensure your Funnel Leasing account has Admin permissions and try again.

+ 

+1. In the **Notification Email** field, enter the email address of a person who should receive the provisioning error notifications and select the **Send an email notification when a failure occurs** check box.

+ 

+1. Select **Save**.

+1. Under the **Mappings** section, select **Synchronize Azure Active Directory Users to Funnel Leasing**.

+1. Review the user attributes that are synchronized from Azure AD to Funnel Leasing in the **Attribute-Mapping** section. The attributes selected as **Matching** properties are used to match the user accounts in Funnel Leasing for update operations. If you choose to change the [matching target attribute](../app-provisioning/customize-application-attributes.md), you'll need to ensure that the Funnel Leasing API supports filtering users based on that attribute. Select the **Save** button to commit any changes.

+ |Attribute|Type|Supported for filtering|Required by Funnel Leasing|

+ |||||

+ |userName|String|&check;|&check;

+ |active|Boolean||&check;

+ |title|String||

+ |emails[type eq "work"].value|String||&check;

+ |name.givenName|String||&check;

+ |name.familyName|String||&check;

+ |phoneNumbers[type eq "work"].value|String||

+ |phoneNumbers[type eq "mobile"].value|String||

+ |externalId|String||

+1. To configure scoping filters, refer to the following instructions provided in the [Scoping filter tutorial](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+1. To enable the Azure AD provisioning service for Funnel Leasing, change the **Provisioning Status** to **On** in the **Settings** section.

+ 

+1. Define the users that you would like to provision to Funnel Leasing by choosing the desired values in **Scope** in the **Settings** section.

+ 

+1. When you're ready to provision, click **Save**.

+ 

+This operation starts the initial synchronization cycle of all users defined in **Scope** in the **Settings** section. The initial cycle takes longer to perform than subsequent cycles, which occur approximately every 40 minutes as long as the Azure AD provisioning service is running.

+## Step 6. Monitor your deployment

+Once you've configured provisioning, use the following resources to monitor your deployment:

+* Use the [provisioning logs](../reports-monitoring/concept-provisioning-logs.md) to determine which users have been provisioned successfully or unsuccessfully

+* Check the [progress bar](../app-provisioning/application-provisioning-when-will-provisioning-finish-specific-user.md) to see the status of the provisioning cycle and how close it's to completion

+* If the provisioning configuration seems to be in an unhealthy state, the application goes into quarantine. Learn more about quarantine states [here](../app-provisioning/application-provisioning-quarantine-status.md).

+## More resources

+* [Managing user account provisioning for Enterprise Apps](../app-provisioning/configure-automatic-user-provisioning-portal.md)

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

+## Next steps

+* [Learn how to review logs and get reports on provisioning activity](../app-provisioning/check-status-user-account-provisioning.md)

+> [GitHub Enterprise Managed User (EMU)](https://docs.github.com/enterprise-cloud@latest/admin/authentication/managing-your-enterprise-users-with-your-identity-provider/about-enterprise-managed-users) is a different type of [GitHub Enteprise Account](https://docs.github.com/enterprise-cloud@latest/admin/overview/about-enterprise-accounts). If you haven't specifically requested EMU instance, you have a standard GitHub Enterprise Account. In that case, please refer to [the documentation](./github-provisioning-tutorial.md) to configure user provisioning in your non-EMU organisation. User provisioning is not supported for [standard GitHub Enteprise Accounts](https://docs.github.com/enterprise-cloud@latest/admin/overview/about-enterprise-accounts), but is supported for organisations under standard GitHub Enterprise Account.

+ Title: 'Tutorial: Configure Humbol for automatic user provisioning with Azure Active Directory'

+description: Learn how to automatically provision and de-provision user accounts from Azure AD to Humbol.

+writer: twimmers

+ms.assetid: a34b8778-3a56-4a39-835d-54044079350d

+# Tutorial: Configure Humbol for automatic user provisioning

+This tutorial describes the steps you need to perform in both Humbol and Azure Active Directory (Azure AD) to configure automatic user provisioning. When configured, Azure AD automatically provisions and de-provisions users to [Humbol](https://www.humbol.app/en/product/) 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).

+## Supported capabilities

+> [!div class="checklist"]

+> * Create users in Humbol.

+> * Remove users in Humbol when they do not require access anymore.

+> * Keep user attributes synchronized between Azure AD and Humbol.

+> * [Single sign-on](../manage-apps/add-application-portal-setup-oidc-sso.md) to Humbol (recommended).

+## Prerequisites

+The scenario outlined in this tutorial assumes that you already have the following prerequisites:

+* [An Azure AD tenant](../develop/quickstart-create-new-tenant.md)

+* A user account in Azure AD with [permission](../roles/permissions-reference.md) to configure provisioning (for example, Application Administrator, Cloud Application administrator, Application Owner, or Global Administrator).

+* A user account in Humbol with Admin permissions.

+## Step 1. Plan your provisioning deployment

+1. Learn about [how the provisioning service works](../app-provisioning/user-provisioning.md).

+1. Determine who will be in [scope for provisioning](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

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

+## Step 2. Configure Humbol to support provisioning with Azure AD

+Contact Humbol support to configure Humbol to support provisioning with Azure AD.

+## Step 3. Add Humbol from the Azure AD application gallery

+Add Humbol from the Azure AD application gallery to start managing provisioning to Humbol. If you have previously setup Humbol for SSO you can use the same application. However it's recommended that you create a separate app when testing out the integration initially. Learn more about adding an application from the gallery [here](../manage-apps/add-application-portal.md).

+## Step 4. Define who will be in scope for provisioning

+The Azure AD provisioning service allows you to scope who will be provisioned based on assignment to the application and or based on attributes of the user. If you choose to scope who will be provisioned to your app based on assignment, you can use the following [steps](../manage-apps/assign-user-or-group-access-portal.md) to assign users to the application. If you choose to scope who will be provisioned based solely on attributes of the user, you can use a scoping filter as described [here](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+* Start small. Test with a small set of users before rolling out to everyone. When scope for provisioning is set to assigned users, you can control this by assigning one or two users to the app. When scope is set to all users, you can specify an [attribute based scoping filter](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+* If you need more roles, you can [update the application manifest](../develop/howto-add-app-roles-in-azure-ad-apps.md) to add new roles.

+## Step 5. Configure automatic user provisioning to Humbol

+This section guides you through the steps to configure the Azure AD provisioning service to create, update, and disable users in TestApp based on user assignments in Azure AD.

+### To configure automatic user provisioning for Humbol in Azure AD:

+1. Sign in to the [Azure portal](https://portal.azure.com). Select **Enterprise Applications**, then select **All applications**.

+ 

+1. In the applications list, select **Humbol**.

+ 

+1. Select the **Provisioning** tab.

+ 

+1. Set the **Provisioning Mode** to **Automatic**.

+ 

+1. Under the **Admin Credentials** section, input your Humbol Tenant URL and Secret Token. Click **Test Connection** to ensure Azure AD can connect to Humbol. If the connection fails, ensure your Humbol account has Admin permissions and try again.

+ 

+1. In the **Notification Email** field, enter the email address of a person who should receive the provisioning error notifications and select the **Send an email notification when a failure occurs** check box.

+ 

+1. Select **Save**.

+1. Under the **Mappings** section, select **Synchronize Azure Active Directory Users to Humbol**.

+1. Review the user attributes that are synchronized from Azure AD to Humbol in the **Attribute-Mapping** section. The attributes selected as **Matching** properties are used to match the user accounts in Humbol for update operations. If you choose to change the [matching target attribute](../app-provisioning/customize-application-attributes.md), you'll need to ensure that the Humbol API supports filtering users based on that attribute. Select the **Save** button to commit any changes.

+ |Attribute|Type|Supported for filtering|Required by Humbol|

+ |||||

+ |userName|String|&check;|&check;

+ |active|Boolean||&check;

+ |title|String||

+ |emails[type eq "work"].value|String||&check;

+ |preferredLanguage|String||

+ |name.givenName|String||&check;

+ |name.familyName|String||&check;

+ |addresses[type eq "work"].locality|String||&check;

+ |addresses[type eq "work"].region|String||&check;

+ |addresses[type eq "work"].country|String||&check;

+ |roles[primary eq "True"].value|String||&check;

+ |urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department|String||&check;

+ |urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager|String||&check;

+1. To configure scoping filters, refer to the following instructions provided in the [Scoping filter tutorial](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+1. To enable the Azure AD provisioning service for Humbol, change the **Provisioning Status** to **On** in the **Settings** section.

+ 

+1. Define the users that you would like to provision to Humbol by choosing the desired values in **Scope** in the **Settings** section.

+ 

+1. When you're ready to provision, click **Save**.

+ 

+This operation starts the initial synchronization cycle of all users defined in **Scope** in the **Settings** section. The initial cycle takes longer to perform than subsequent cycles, which occur approximately every 40 minutes as long as the Azure AD provisioning service is running.

+## Step 6. Monitor your deployment

+Once you've configured provisioning, use the following resources to monitor your deployment:

+* Use the [provisioning logs](../reports-monitoring/concept-provisioning-logs.md) to determine which users have been provisioned successfully or unsuccessfully

+* Check the [progress bar](../app-provisioning/application-provisioning-when-will-provisioning-finish-specific-user.md) to see the status of the provisioning cycle and how close it's to completion

+* If the provisioning configuration seems to be in an unhealthy state, the application goes into quarantine. Learn more about quarantine states [here](../app-provisioning/application-provisioning-quarantine-status.md).

+## More resources

+* [Managing user account provisioning for Enterprise Apps](../app-provisioning/configure-automatic-user-provisioning-portal.md)

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

+## Next steps

+* [Learn how to review logs and get reports on provisioning activity](../app-provisioning/check-status-user-account-provisioning.md)

+ Title: 'Tutorial: Configure Markit Procurement Service for automatic user provisioning with Azure Active Directory'

+description: Learn how to automatically provision and deprovision user accounts from Azure AD to Markit Procurement Service.

+writer: twimmers

+ms.assetid: 4ed2955b-3060-4530-b8c1-9e355dedf13e

+# Tutorial: Configure Markit Procurement Service for automatic user provisioning

+This tutorial describes the steps you need to perform in both Markit Procurement Service and Azure Active Directory (Azure AD) to configure automatic user provisioning. When configured, Azure AD automatically provisions and deprovisions users to [Markit Procurement Service](https://www.markit.eu) 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).

+## Supported capabilities

+> [!div class="checklist"]

+> * Create users in Markit Procurement Service.

+> * Remove users in Markit Procurement Service when they do not require access anymore.

+> * Keep user attributes synchronized between Azure AD and Markit Procurement Service.

+> * [Single sign-on](../manage-apps/add-application-portal-setup-oidc-sso.md) to Markit Procurement Service (recommended).

+## Prerequisites

+The scenario outlined in this tutorial assumes that you already have the following prerequisites:

+* [An Azure AD tenant](../develop/quickstart-create-new-tenant.md)

+* A user account in Azure AD with [permission](../roles/permissions-reference.md) to configure provisioning (for example, Application Administrator, Cloud Application administrator, Application Owner, or Global Administrator).

+* A user account in Markit Procurement Service with Admin permissions.

+## Step 1. Plan your provisioning deployment

+1. Learn about [how the provisioning service works](../app-provisioning/user-provisioning.md).

+1. Determine who will be in [scope for provisioning](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

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

+## Step 2. Configure Markit Procurement Service to support provisioning with Azure AD

+Contact Markit Procurement Service support to configure Markit Procurement Service to support provisioning with Azure AD.

+## Step 3. Add Markit Procurement Service from the Azure AD application gallery

+Add Markit Procurement Service from the Azure AD application gallery to start managing provisioning to Markit Procurement Service. If you have previously setup Markit Procurement Service for SSO, you can use the same application. However it's recommended that you create a separate app when testing out the integration initially. Learn more about adding an application from the gallery [here](../manage-apps/add-application-portal.md).

+## Step 4. Define who will be in scope for provisioning

+The Azure AD provisioning service allows you to scope who will be provisioned based on assignment to the application and or based on attributes of the user. If you choose to scope who will be provisioned to your app based on assignment, you can use the following [steps](../manage-apps/assign-user-or-group-access-portal.md) to assign users to the application. If you choose to scope who will be provisioned based solely on attributes of the user, you can use a scoping filter as described [here](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+* Start small. Test with a small set of users before rolling out to everyone. When scope for provisioning is set to assigned users, you can control this by assigning one or two users to the app. When scope is set to all users, you can specify an [attribute based scoping filter](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+* If you need more roles, you can [update the application manifest](../develop/howto-add-app-roles-in-azure-ad-apps.md) to add new roles.

+## Step 5. Configure automatic user provisioning to Markit Procurement Service

+This section guides you through the steps to configure the Azure AD provisioning service to create, update, and disable users in TestApp based on user assignments in Azure AD.

+### To configure automatic user provisioning for Markit Procurement Service in Azure AD:

+1. Sign in to the [Azure portal](https://portal.azure.com). Select **Enterprise Applications**, then select **All applications**.

+ 

+1. In the applications list, select **Markit Procurement Service**.

+ 

+1. Select the **Provisioning** tab.

+ 

+1. Set the **Provisioning Mode** to **Automatic**.

+ 

+1. Under the **Admin Credentials** section, input your Markit Procurement Service Tenant URL and Secret Token. Click **Test Connection** to ensure Azure AD can connect to Markit Procurement Service. If the connection fails, ensure your Markit Procurement Service account has Admin permissions and try again.

+ 

+1. In the **Notification Email** field, enter the email address of a person who should receive the provisioning error notifications and select the **Send an email notification when a failure occurs** check box.

+ 

+1. Select **Save**.

+1. Under the **Mappings** section, select **Synchronize Azure Active Directory Users to Markit Procurement Service**.

+1. Review the user attributes that are synchronized from Azure AD to Markit Procurement Service in the **Attribute-Mapping** section. The attributes selected as **Matching** properties are used to match the user accounts in Markit Procurement Service for update operations. If you choose to change the [matching target attribute](../app-provisioning/customize-application-attributes.md), you need to ensure that the Markit Procurement Service API supports filtering users based on that attribute. Select the **Save** button to commit any changes.

+ |Attribute|Type|Supported for filtering|Required by Markit Procurement Service|

+ |||||

+ |userName|String|&check;|&check;

+ |active|Boolean||

+ |name.givenName|String||&check;

+ |name.familyName|String||&check;

+ |externalId|String||&check;

+

+1. To configure scoping filters, refer to the following instructions provided in the [Scoping filter tutorial](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+1. To enable the Azure AD provisioning service for Markit Procurement Service, change the **Provisioning Status** to **On** in the **Settings** section.

+ 

+1. Define the users that you would like to provision to Markit Procurement Service by choosing the desired values in **Scope** in the **Settings** section.

+ 

+1. When you're ready to provision, click **Save**.

+ 

+This operation starts the initial synchronization cycle of all users defined in **Scope** in the **Settings** section. The initial cycle takes longer to perform than subsequent cycles, which occur approximately every 40 minutes as long as the Azure AD provisioning service is running.

+## Step 6. Monitor your deployment

+Once you've configured provisioning, use the following resources to monitor your deployment:

+* Use the [provisioning logs](../reports-monitoring/concept-provisioning-logs.md) to determine which users have been provisioned successfully or unsuccessfully

+* Check the [progress bar](../app-provisioning/application-provisioning-when-will-provisioning-finish-specific-user.md) to see the status of the provisioning cycle and how close it's to completion

+* If the provisioning configuration seems to be in an unhealthy state, the application goes into quarantine. Learn more about quarantine states [here](../app-provisioning/application-provisioning-quarantine-status.md).

+## More resources

+* [Managing user account provisioning for Enterprise Apps](../app-provisioning/configure-automatic-user-provisioning-portal.md)

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

+## Next steps

+* [Learn how to review logs and get reports on provisioning activity](../app-provisioning/check-status-user-account-provisioning.md)

+ Title: 'Tutorial: Configure Recnice for automatic user provisioning with Azure Active Directory'

+description: Learn how to automatically provision and de-provision user accounts from Azure AD to Recnice.

+writer: twimmers

+ms.assetid: 72e7a106-4187-4e40-9c63-77527fe9aeae

+# Tutorial: Configure Recnice for automatic user provisioning

+This tutorial describes the steps you need to perform in both Recnice and Azure Active Directory (Azure AD) to configure automatic user provisioning. When configured, Azure AD automatically provisions and de-provisions users and groups to [Recnice](https://recnice.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).

+## Supported capabilities

+> [!div class="checklist"]

+> * Create users in Recnice.

+> * Remove users in Recnice when they do not require access anymore.

+> * Keep user attributes synchronized between Azure AD and Recnice.

+> * Provision groups and group memberships in Recnice.

+> * [Single sign-on](../manage-apps/add-application-portal-setup-oidc-sso.md) to Recnice (recommended).

+## Prerequisites

+The scenario outlined in this tutorial assumes that you already have the following prerequisites:

+* [An Azure AD tenant](../develop/quickstart-create-new-tenant.md)

+* A user account in Azure AD with [permission](../roles/permissions-reference.md) to configure provisioning (for example, Application Administrator, Cloud Application administrator, Application Owner, or Global Administrator).

+* A user account in Recnice with Admin permissions.

+## Step 1. Plan your provisioning deployment

+1. Learn about [how the provisioning service works](../app-provisioning/user-provisioning.md).

+1. Determine who will be in [scope for provisioning](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

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

+## Step 2. Configure Recnice to support provisioning with Azure AD

+Contact Recnice support to configure Recnice to support provisioning with Azure AD.

+## Step 3. Add Recnice from the Azure AD application gallery

+Add Recnice from the Azure AD application gallery to start managing provisioning to Recnice. If you have previously setup Recnice for SSO you can use the same application. However it's recommended that you create a separate app when testing out the integration initially. Learn more about adding an application from the gallery [here](../manage-apps/add-application-portal.md).

+## Step 4. Define who will be in scope for provisioning

+The Azure AD provisioning service allows you to scope who will be provisioned based on assignment to the application and or based on attributes of the user / group. If you choose to scope who will be provisioned to your app based on assignment, you can use the following [steps](../manage-apps/assign-user-or-group-access-portal.md) to assign users and groups to the application. If you choose to scope who will be provisioned based solely on attributes of the user or group, you can use a scoping filter as described [here](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+* Start small. Test with a small set of users and groups before rolling out to everyone. When scope for provisioning is set to assigned users and groups, you can control this by assigning one or two users or groups to the app. When scope is set to all users and groups, you can specify an [attribute based scoping filter](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+* If you need more roles, you can [update the application manifest](../develop/howto-add-app-roles-in-azure-ad-apps.md) to add new roles.

+## Step 5. Configure automatic user provisioning to Recnice

+This section guides you through the steps to configure the Azure AD provisioning service to create, update, and disable users and/or groups in TestApp based on user and/or group assignments in Azure AD.

+### To configure automatic user provisioning for Recnice in Azure AD:

+1. Sign in to the [Azure portal](https://portal.azure.com). Select **Enterprise Applications**, then select **All applications**.

+ 

+1. In the applications list, select **Recnice**.

+ 

+1. Select the **Provisioning** tab.

+ 

+1. Set the **Provisioning Mode** to **Automatic**.

+ 

+1. Under the **Admin Credentials** section, input your Recnice Tenant URL and Secret Token. Click **Test Connection** to ensure Azure AD can connect to Recnice. If the connection fails, ensure your Recnice account has Admin permissions and try again.

+ 

+1. In the **Notification Email** field, enter the email address of a person or group who should receive the provisioning error notifications and select the **Send an email notification when a failure occurs** check box.

+ 

+1. Select **Save**.

+1. Under the **Mappings** section, select **Synchronize Azure Active Directory Users to Recnice**.

+1. Review the user attributes that are synchronized from Azure AD to Recnice in the **Attribute-Mapping** section. The attributes selected as **Matching** properties are used to match the user accounts in Recnice for update operations. If you choose to change the [matching target attribute](../app-provisioning/customize-application-attributes.md), you'll need to ensure that the Recnice API supports filtering users based on that attribute. Select the **Save** button to commit any changes.

+ |Attribute|Type|Supported for filtering|Required by Recnice|

+ |||||

+ |userName|String|&check;|&check;

+ |active|Boolean||&check;

+ |displayName|String||&check;

+ |title|String||&check;

+ |emails[type eq "work"].value|String||&check;

+ |preferredLanguage|String||&check;

+ |name.givenName|String||&check;

+ |name.familyName|String||&check;

+ |name.formatted|String||&check;

+ |addresses[type eq "work"].formatted|String||&check;

+ |addresses[type eq "work"].streetAddress|String||&check;

+ |addresses[type eq "work"].locality|String||&check;

+ |addresses[type eq "work"].region|String||&check;

+ |addresses[type eq "work"].postalCode|String||&check;

+ |addresses[type eq "work"].country|String||&check;

+ |externalId|String||&check;

+ |roles|String||&check;

+ |urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department|String||&check;

+1. Under the **Mappings** section, select **Synchronize Azure Active Directory Groups to Recnice**.

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

+ |Attribute|Type|Supported for filtering|Required by Recnice|

+ |||||

+ |displayName|String|&check;|&check;

+ |externalId|String||

+ |members|Reference||

+

+1. To configure scoping filters, refer to the following instructions provided in the [Scoping filter tutorial](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+1. To enable the Azure AD provisioning service for Recnice, change the **Provisioning Status** to **On** in the **Settings** section.

+ 

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

+ 

+1. When you're ready to provision, click **Save**.

+ 

+This operation starts the initial synchronization cycle of all users and groups defined in **Scope** in the **Settings** section. The initial cycle takes longer to perform than subsequent cycles, which occur approximately every 40 minutes as long as the Azure AD provisioning service is running.

+## Step 6. Monitor your deployment

+Once you've configured provisioning, use the following resources to monitor your deployment:

+* Use the [provisioning logs](../reports-monitoring/concept-provisioning-logs.md) to determine which users have been provisioned successfully or unsuccessfully

+* Check the [progress bar](../app-provisioning/application-provisioning-when-will-provisioning-finish-specific-user.md) to see the status of the provisioning cycle and how close it's to completion

+* If the provisioning configuration seems to be in an unhealthy state, the application goes into quarantine. Learn more about quarantine states [here](../app-provisioning/application-provisioning-quarantine-status.md).

+## More resources

+* [Managing user account provisioning for Enterprise Apps](../app-provisioning/configure-automatic-user-provisioning-portal.md)

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

+## Next steps

+* [Learn how to review logs and get reports on provisioning activity](../app-provisioning/check-status-user-account-provisioning.md)

+ Title: 'Tutorial: Configure Uni-tel A/S for automatic user provisioning with Azure Active Directory'

+description: Learn how to automatically provision and de-provision user accounts from Azure AD to Uni-tel A/S.

+writer: twimmers

+ms.assetid: 37c67e85-fc17-4285-b658-52af669f4046

+# Tutorial: Configure Uni-tel A/S for automatic user provisioning

+This tutorial describes the steps you need to perform in both Uni-tel ).

+## Supported capabilities

+> [!div class="checklist"]

+> * Create users in Uni-tel A/S.

+> * Remove users in Uni-tel A/S when they do not require access anymore.

+> * Keep user attributes synchronized between Azure AD and Uni-tel A/S.

+> * [Single sign-on](../manage-apps/add-application-portal-setup-oidc-sso.md) to Uni-tel A/S (recommended).

+## Prerequisites

+The scenario outlined in this tutorial assumes that you already have the following prerequisites:

+* [An Azure AD tenant](../develop/quickstart-create-new-tenant.md)

+* A user account in Azure AD with [permission](../roles/permissions-reference.md) to configure provisioning (for example, Application Administrator, Cloud Application administrator, Application Owner, or Global Administrator).

+* A user account in Uni-tel A/S with Admin permissions.

+## Step 1. Plan your provisioning deployment

+1. Learn about [how the provisioning service works](../app-provisioning/user-provisioning.md).

+1. Determine who will be in [scope for provisioning](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+1. Determine what data to [map between Azure AD and Uni-tel ).

+## Step 2. Configure Uni-tel A/S to support provisioning with Azure AD

+Contact Uni-tel A/S support to configure Uni-tel A/S to support provisioning with Azure AD.

+## Step 3. Add Uni-tel A/S from the Azure AD application gallery

+Add Uni-tel ).

+## Step 4. Define who will be in scope for provisioning

+The Azure AD provisioning service allows you to scope who will be provisioned based on assignment to the application and or based on attributes of the user. If you choose to scope who will be provisioned to your app based on assignment, you can use the following [steps](../manage-apps/assign-user-or-group-access-portal.md) to assign users to the application. If you choose to scope who will be provisioned based solely on attributes of the user, you can use a scoping filter as described [here](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+* Start small. Test with a small set of users before rolling out to everyone. When scope for provisioning is set to assigned users, you can control this by assigning one or two users to the app. When scope is set to all users, you can specify an [attribute based scoping filter](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+* If you need more roles, you can [update the application manifest](../develop/howto-add-app-roles-in-azure-ad-apps.md) to add new roles.

+## Step 5. Configure automatic user provisioning to Uni-tel A/S

+This section guides you through the steps to configure the Azure AD provisioning service to create, update, and disable users in TestApp based on user assignments in Azure AD.

+### To configure automatic user provisioning for Uni-tel A/S in Azure AD:

+1. Sign in to the [Azure portal](https://portal.azure.com). Select **Enterprise Applications**, then select **All applications**.

+ 

+1. In the applications list, select **Uni-tel A/S**.

+ 

+1. Select the **Provisioning** tab.

+ 

+1. Set the **Provisioning Mode** to **Automatic**.

+ 

+1. Under the **Admin Credentials** section, input your Uni-tel A/S Tenant URL and Secret Token. Click **Test Connection** to ensure Azure AD can connect to Uni-tel A/S. If the connection fails, ensure your Uni-tel A/S account has Admin permissions and try again.

+ 

+1. In the **Notification Email** field, enter the email address of a person who should receive the provisioning error notifications and select the **Send an email notification when a failure occurs** check box.

+ 

+1. Select **Save**.

+1. Under the **Mappings** section, select **Synchronize Azure Active Directory Users to Uni-tel A/S**.

+1. Review the user attributes that are synchronized from Azure AD to Uni-tel ), you'll need to ensure that the Uni-tel A/S API supports filtering users based on that attribute. Select the **Save** button to commit any changes.

+ |Attribute|Type|Supported for filtering|Required by Uni-tel A/S|

+ |||||

+ |userName|String|&check;|&check;

+ |active|Boolean||

+ |displayName|String||

+ |name.givenName|String||

+ |name.familyName|String||

+

+1. To configure scoping filters, refer to the following instructions provided in the [Scoping filter tutorial](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+1. To enable the Azure AD provisioning service for Uni-tel A/S, change the **Provisioning Status** to **On** in the **Settings** section.

+ 

+1. Define the users that you would like to provision to Uni-tel A/S by choosing the desired values in **Scope** in the **Settings** section.

+ 

+1. When you're ready to provision, click **Save**.

+ 

+This operation starts the initial synchronization cycle of all users defined in **Scope** in the **Settings** section. The initial cycle takes longer to perform than subsequent cycles, which occur approximately every 40 minutes as long as the Azure AD provisioning service is running.

+## Step 6. Monitor your deployment

+Once you've configured provisioning, use the following resources to monitor your deployment:

+* Use the [provisioning logs](../reports-monitoring/concept-provisioning-logs.md) to determine which users have been provisioned successfully or unsuccessfully

+* Check the [progress bar](../app-provisioning/application-provisioning-when-will-provisioning-finish-specific-user.md) to see the status of the provisioning cycle and how close it's to completion

+* If the provisioning configuration seems to be in an unhealthy state, the application goes into quarantine. Learn more about quarantine states [here](../app-provisioning/application-provisioning-quarantine-status.md).

+## More resources

+* [Managing user account provisioning for Enterprise Apps](../app-provisioning/configure-automatic-user-provisioning-portal.md)

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

+## Next steps

+* [Learn how to review logs and get reports on provisioning activity](../app-provisioning/check-status-user-account-provisioning.md)

+ Title: 'Tutorial: Configure WATS for automatic user provisioning with Azure Active Directory'

+description: Learn how to automatically provision and de-provision user accounts from Azure AD to WATS.

+writer: twimmers

+ms.assetid: e1cc1c4d-7504-4c78-9999-1d5301bf933c

+# Tutorial: Configure WATS for automatic user provisioning

+This tutorial describes the steps you need to perform in both WATS and Azure Active Directory (Azure AD) to configure automatic user provisioning. When configured, Azure AD automatically provisions and de-provisions users to [WATS](https://wats.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).

+## Supported capabilities

+> [!div class="checklist"]

+> * Create users in WATS.

+> * Remove users in WATS when they do not require access anymore.

+> * Keep user attributes synchronized between Azure AD and WATS.

+> * [Single sign-on](../manage-apps/add-application-portal-setup-oidc-sso.md) to WATS (recommended).

+## Prerequisites

+The scenario outlined in this tutorial assumes that you already have the following prerequisites:

+* [An Azure AD tenant](../develop/quickstart-create-new-tenant.md)

+* A user account in Azure AD with [permission](../roles/permissions-reference.md) to configure provisioning (for example, Application Administrator, Cloud Application administrator, Application Owner, or Global Administrator).

+* A user account in WATS with Admin permissions.

+## Step 1. Plan your provisioning deployment

+1. Learn about [how the provisioning service works](../app-provisioning/user-provisioning.md).

+1. Determine who will be in [scope for provisioning](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

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

+## Step 2. Configure WATS to support provisioning with Azure AD

+Contact WATS support to configure WATS to support provisioning with Azure AD.

+## Step 3. Add WATS from the Azure AD application gallery

+Add WATS from the Azure AD application gallery to start managing provisioning to WATS. If you have previously setup WATS for SSO you can use the same application. However it's recommended that you create a separate app when testing out the integration initially. Learn more about adding an application from the gallery [here](../manage-apps/add-application-portal.md).

+## Step 4. Define who will be in scope for provisioning

+The Azure AD provisioning service allows you to scope who will be provisioned based on assignment to the application and or based on attributes of the user. If you choose to scope who will be provisioned to your app based on assignment, you can use the following [steps](../manage-apps/assign-user-or-group-access-portal.md) to assign users to the application. If you choose to scope who will be provisioned based solely on attributes of the user, you can use a scoping filter as described [here](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+* Start small. Test with a small set of users before rolling out to everyone. When scope for provisioning is set to assigned users, you can control this by assigning one or two users to the app. When scope is set to all users, you can specify an [attribute based scoping filter](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+* If you need more roles, you can [update the application manifest](../develop/howto-add-app-roles-in-azure-ad-apps.md) to add new roles.

+## Step 5. Configure automatic user provisioning to WATS

+This section guides you through the steps to configure the Azure AD provisioning service to create, update, and disable users in TestApp based on user assignments in Azure AD.

+### To configure automatic user provisioning for WATS in Azure AD:

+1. Sign in to the [Azure portal](https://portal.azure.com). Select **Enterprise Applications**, then select **All applications**.

+ 

+1. In the applications list, select **WATS**.

+ 

+1. Select the **Provisioning** tab.

+ 

+1. Set the **Provisioning Mode** to **Automatic**.

+ 

+1. Under the **Admin Credentials** section, input your WATS Tenant URL and Secret Token. Click **Test Connection** to ensure Azure AD can connect to WATS. If the connection fails, ensure your WATS account has Admin permissions and try again.

+ 

+1. In the **Notification Email** field, enter the email address of a person who should receive the provisioning error notifications and select the **Send an email notification when a failure occurs** check box.

+ 

+1. Select **Save**.

+1. Under the **Mappings** section, select **Synchronize Azure Active Directory Users to WATS**.

+1. Review the user attributes that are synchronized from Azure AD to WATS in the **Attribute-Mapping** section. The attributes selected as **Matching** properties are used to match the user accounts in WATS for update operations. If you choose to change the [matching target attribute](../app-provisioning/customize-application-attributes.md), you'll need to ensure that the WATS API supports filtering users based on that attribute. Select the **Save** button to commit any changes.

+ |Attribute|Type|Supported for filtering|Required by WATS|

+ |||||

+ |userName|String|&check;|&check;

+ |active|Boolean||

+ |emails[type eq "work"].value|String||&check;

+ |name.givenName|String||&check;

+ |name.familyName|String||&check;

+ |roles[primary eq "True"].value|String||

+1. To configure scoping filters, refer to the following instructions provided in the [Scoping filter tutorial](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+1. To enable the Azure AD provisioning service for WATS, change the **Provisioning Status** to **On** in the **Settings** section.

+ 

+1. Define the users that you would like to provision to WATS by choosing the desired values in **Scope** in the **Settings** section.

+ 

+1. When you're ready to provision, click **Save**.

+ 

+This operation starts the initial synchronization cycle of all users defined in **Scope** in the **Settings** section. The initial cycle takes longer to perform than subsequent cycles, which occur approximately every 40 minutes as long as the Azure AD provisioning service is running.

+## Step 6. Monitor your deployment

+Once you've configured provisioning, use the following resources to monitor your deployment:

+* Use the [provisioning logs](../reports-monitoring/concept-provisioning-logs.md) to determine which users have been provisioned successfully or unsuccessfully

+* Check the [progress bar](../app-provisioning/application-provisioning-when-will-provisioning-finish-specific-user.md) to see the status of the provisioning cycle and how close it's to completion

+* If the provisioning configuration seems to be in an unhealthy state, the application goes into quarantine. Learn more about quarantine states [here](../app-provisioning/application-provisioning-quarantine-status.md).

+## More resources

+* [Managing user account provisioning for Enterprise Apps](../app-provisioning/configure-automatic-user-provisioning-portal.md)

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

+## Next steps

+* [Learn how to review logs and get reports on provisioning activity](../app-provisioning/check-status-user-account-provisioning.md)

+Learn more: [Azure AD and data residency](../fundamentals/data-residency.md)

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

+|**7.2.5.1** All access by application and system accounts and related access privileges are reviewed as follows: </br> Periodically (at the frequency defined in the entityΓÇÖs targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1). </br> The application/system access remains appropriate for the function being performed. </br> Any inappropriate access is addressed. </br> Management acknowledges that access remains appropriate.|Best practices when reviewing service accounts permissions. [Governing Azure AD service accounts](../fundamentals/govern-service-accounts.md) </br> [Govern on-premises service accounts](../fundamentals/service-accounts-govern-on-premises.md)|

+|**8.6.1** If accounts used by systems or applications can be used for interactive login, they're managed as follows: </br> Interactive use is prevented unless needed for an exceptional circumstance. </br> Interactive use is limited to the time needed for the exceptional circumstance. </br> Business justification for interactive use is documented. </br> Interactive use is explicitly approved by management. </br> Individual user identity is confirmed before access to account is granted. </br> Every action taken is attributable to an individual user.|For CDE applications with modern authentication, and for CDE resources deployed in Azure that use modern authentication, Azure AD has two service account types for applications: Managed Identities and service principals. </br> Learn about Azure AD service account governance: planning, provisioning, lifecycle, monitoring, access reviews, etc. [Governing Azure AD service accounts](../fundamentals/govern-service-accounts.md) </br> To secure Azure AD service accounts. [Securing managed identities in Azure AD](../fundamentals/service-accounts-managed-identities.md) </br> [Securing service principals in Azure AD](../fundamentals/service-accounts-principal.md) </br> For CDEs with resources outside Azure that require access, configure workload identity federations without managing secrets or interactive sign in. [Workload identity federation](../develop/workload-identity-federation.md) </br> To enable approval and tracking processes to fulfill requirements, orchestrate workflows using IT Service Management (ITSM) and configuration management databases (CMDB) These tools use MS Graph API to interact with Azure AD and manage the service account. </br> For CDEs that require service accounts compatible with on-premises Active Directory, use Group Managed Service Accounts (GMSAs), and standalone managed service accounts (sMSA), computer accounts, or user accounts. [Securing on-premises service accounts](../fundamentals/service-accounts-on-premises.md)|

+> It is recommended to delete the corresponding PersistentVolumeClaim object instead of the PersistentVolume object when deleting a CSI volume. The external provisioner in the CSI driver will react to the deletion of the PersistentVolumeClaim and based on its reclamation policy, it issues the DeleteVolume call against the CSI volume driver commands to delete the volume. The PersistentVolume object is then deleted.

+## Disk encryption supported scenarios

+CSI storage drivers support the following scenarios:

+* [Encrypted managed disks with customer-managed keys][encrypt-managed-disks-customer-managed-keys] using Azure Key Vaults stored in a different Azure Active Directory (Azure AD) tenant.

+* Encrypt your Azure Storage disks hosting AKS OS and application data with [customer-managed keys][azure-disk-customer-managed-keys].

+[azure-policy-aks-definition]: ../governance/policy/samples/built-in-policies.md#kubernetes

+[encrypt-managed-disks-customer-managed-keys]: ../virtual-machines/disks-cross-tenant-customer-managed-keys.md

+[azure-disk-customer-managed-keys]: azure-disk-customer-managed-keys.md

+[istio-deploy-addon]: istio-deploy-addon.md

+For [use a pre-created kubelet managed identity][use-a-pre-created-kubelet-managed-identity], you need Azure CLI version 2.26.0 or later installed.

+For [update control plane identity on an existing cluster][update-control-plane-identity-on-an-existing-cluster], you need Azure CLI version 2.49.0 or later installed.

+> AKS creates a user-assigned kubelet identity in the node resource group if you don't [specify your own kubelet managed identity][Use a pre-created kubelet managed identity].

+If you're not using the Azure CLI, but you're using your own VNet, attached Azure disk, static IP address, route table, or user-assigned kubelet identity that's outside of the worker node resource group, we recommend using [user-assigned control plane identity][bring-your-own-control-plane-managed-identity]. For system-assigned control plane identity, we can't get the identity ID before creating cluster, which delays the role assignment from taking effect.

+For a user-assigned kubelet identity outside the default worker node resource group, you need to assign the [Managed Identity Operator][managed-identity-operator] role on the kubelet identity for control plane identity.

+ az role assignment create --assignee <control-plane-identity-principal-id> --role "Managed Identity Operator" --scope "<kubelet-identity-resource-id>"

+### Create a cluster using user-assigned control plane identity

+> AKS creates a user-assigned kubelet identity in the node resource group if you don't [specify your own kubelet managed identity][Use a pre-created kubelet managed identity].

+> [!NOTE]

+> It may take up to 60 minutes for the permissions granted to your cluster's managed identity to populate.

+* Before creating the cluster, [add the role assignment for control plane identity][add-role-assignment-for-control-plane-identity] using the [`az role assignment create`][az-role-assignment-create] command.

+* Create the cluster with user-assigned control plane identity.

+### Update control plane identity on an existing cluster

+* If you don't have a managed identity, create one using the [`az identity create`][az-identity-create] command.

+ ```azurecli-interactive

+ az identity create --name myIdentity --resource-group myResourceGroup

+ ```

+ Your output should resemble the following example output:

+ ```output

+ {

+ "clientId": "<client-id>",

+ "clientSecretUrl": "<clientSecretUrl>",

+ "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity",

+ "location": "westus2",

+ "name": "myIdentity",

+ "principalId": "<principal-id>",

+ "resourceGroup": "myResourceGroup",

+ "tags": {},

+ "tenantId": "<tenant-id>",

+ "type": "Microsoft.ManagedIdentity/userAssignedIdentities"

+ }

+ ```

+

+* After creating the identity, [add the role assignment for control plane identity][add-role-assignment-for-control-plane-identity] using the [`az role assignment create`][az-role-assignment-create] command.

+* Update your cluster with your existing identities using the [`az aks update`][az-aks-update] command. Make sure you provide the control plane identity resource ID for `assign-identity`.

+ ```azurecli-interactive

+ az aks update \

+ --resource-group myResourceGroup \

+ --name myManagedCluster \

+ --enable-managed-identity \

+ --assign-identity <identity-resource-id>

+ ```

+ Your output for a successful cluster update using your own kubelet managed identity should resemble the following example output:

+ ```output

+ "identity": {

+ "principalId": null,

+ "tenantId": null,

+ "type": "UserAssigned",

+ "userAssignedIdentities": {

+ "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity": {

+ "clientId": "<client-id>",

+ "principalId": "<principal-id>"

+ }

+ }

+ },

+ ```

+## Use a pre-created kubelet managed identity

+A kubelet identity enables access to the existing identity prior to cluster creation. This feature enables scenarios such as connection to ACR with a pre-created managed identity.

+[bring-your-own-control-plane-managed-identity]: use-managed-identity.md#bring-your-own-control-plane-managed-identity

+[use-a-pre-created-kubelet-managed-identity]: use-managed-identity.md#use-a-pre-created-kubelet-managed-identity

+[update-control-plane-identity-on-an-existing-cluster]: use-managed-identity.md#update-control-plane-identity-on-an-existing-cluster

+[add-role-assignment-for-control-plane-identity]: use-managed-identity.md#add-role-assignment-for-control-plane-identity

+[managed-identity-operator]: ../role-based-access-control/built-in-roles.md#managed-identity-operator

+* Self-hosted gateway container image version 2.2 or later

+[helm-install]: https://helm.sh/docs/intro/install/

+| observability.opentelemetry.system-metrics.enabled | Enable sending system metrics to the OpenTelemetry collector such as CPU, memory, garbage collection, etc. | No | `false` | v2.3+ |

+#Customer intent: As an application developer, I want to learn how to access data in Microsoft Graph for a signed-in user.

+#Customer intent: As an application developer, I want to learn how to access Azure Storage for an app by using managed identities.

+#Customer intent: As an application developer, I want to learn how to access data in Microsoft Graph for a signed-in user.

+#Customer intent: As an application developer, I want to learn how to access Azure Storage for an app by using managed identities.

+* [Deploy a Node.js + MongoDB web app to Azure](tutorial-nodejs-mongodb-app.md)

+Total Costs = $179.58 + $116.8 + $2,944 = $3,240.38

+* Explore the [Immersive Reader SDK Reference](reference.md)

+* Explore the [Immersive Reader SDK](https://github.com/microsoft/immersive-reader-sdk) and the [Immersive Reader SDK Reference](../reference.md)

+* Explore the [Immersive Reader SDK](https://github.com/microsoft/immersive-reader-sdk) and the [Immersive Reader SDK Reference](../reference.md)

+* For a PowerShell cmdlet reference, see [Az.Automation](/powershell/module/az.automation/#automation).

+* For a list of Azure services that support the managed identities for Azure resources feature, see [Services that support managed identities for Azure resources](../active-directory/managed-identities-azure-resources/services-support-managed-identities.md).

+To enable the feature on VMs in your environment, see [Enable Start/Stop VMs during off-hours](automation-solution-vm-management-enable.md).

+* File an Azure support incident. Go to the [Azure support site](https://azure.microsoft.com/support/options/), and select **Get Support**.

+> [Managed identity integration](./howto-integrate-azure-managed-service-identity.md)

+### [Spring Boot 3](#tab/spring-boot-3)

+```xml

+<dependency>

+ <groupId>com.azure.spring</groupId>

+ <artifactId>spring-cloud-azure-appconfiguration-config-web</artifactId>

+ <version>5.2.0</version>

+</dependency>

+```

+### [Spring Boot 2](#tab/spring-boot-2)

+ <version>4.8.0</version>

+ ### [Spring Boot 3](#tab/spring-boot-3)

+ ```xml

+ <dependency>

+ <groupId>com.azure.spring</groupId>

+ <artifactId>spring-cloud-azure-appconfiguration-config-web</artifactId>

+ <version>5.2.0</version>

+ </dependency>

+ <!-- Adds the Ability to Push Refresh -->

+ <dependency>

+ <groupId>org.springframework.boot</groupId>

+ <artifactId>spring-boot-starter-actuator</artifactId>

+ </dependency>

+ ```

+ ### [Spring Boot 2](#tab/spring-boot-2)

+ ```xml

+ <dependency>

+ <groupId>com.azure.spring</groupId>

+ <artifactId>spring-cloud-azure-appconfiguration-config-web</artifactId>

+ <version>4.8.0</version>

+ </dependency>

+ <!-- Adds the Ability to Push Refresh -->

+ <dependency>

+ <groupId>org.springframework.boot</groupId>

+ <artifactId>spring-boot-starter-actuator</artifactId>

+ </dependency>

+ ```

+

+### [Spring Boot 3](#tab/spring-boot-3)

+```xml

+<dependency>

+ <groupId>com.azure.spring</groupId>

+ <artifactId>spring-cloud-azure-appconfiguration-config</artifactId>

+ <version>5.2.0</version>

+</dependency>

+<dependency>

+ <groupId>com.azure.spring</groupId>

+ <artifactId>spring-cloud-azure-appconfiguration-config-web</artifactId>

+ <version>5.2.0</version>

+</dependency>

+<dependency>

+ <groupId>com.azure.spring</groupId>

+ <artifactId>spring-cloud-azure-feature-management</artifactId>

+ <version>5.2.0</version>

+</dependency>

+<dependency>

+ <groupId>com.azure.spring</groupId>

+ <artifactId>spring-cloud-azure-feature-management-web</artifactId>

+ <version>5.2.0</version>

+</dependency>

+```

+### [Spring Boot 2](#tab/spring-boot-2)

+ <version>4.8.0</version>

+ <version>4.8.0</version>

+ <version>4.8.0</version>

+ <version>4.8.0</version>

+```xml

+```

+### [Spring Boot 3](#tab/spring-boot-3)

+```xml

+<dependency>

+ <groupId>com.azure.spring</groupId>

+ <artifactId>spring-cloud-azure-dependencies</artifactId>

+ <version>5.2.0</version>

+ <type>pom</type>

+</dependency>

+```

+### [Spring Boot 2](#tab/spring-boot-2)

+ <version>4.8.0</version>

+### [Spring Boot 3](#tab/spring-boot-3)

+```xml

+<dependency>

+ <groupId>com.azure.spring</groupId>

+ <artifactId>spring-cloud-azure-appconfiguration-config-web</artifactId>

+ <version>5.2.0</version>

+</dependency>

+```

+### [Spring Boot 2](#tab/spring-boot-2)

+ <artifactId>spring-cloud-azure-appconfiguration-config-web</artifactId>

+ <version>4.8.0</version>

+### [Spring Boot 3](#tab/spring-boot-3)

+ <version>5.2.0</version>

+### [Spring Boot 2](#tab/spring-boot-2)

+```xml

+<dependency>

+ <groupId>com.azure.spring</groupId>

+ <artifactId>spring-cloud-azure-feature-management-web</artifactId>

+ <version>4.8.0</version>

+</dependency>

+```

+* [Manage feature flags](./manage-feature-flags.md)

+Learn more about [connecting machines using Ansible playbooks](onboard-ansible-playbooks.md).

+- [Best Practices Development](cache-best-practices-development.md)

+- _RDB persistence_ - When you use RDB persistence, Azure Cache for Redis persists a snapshot of your cache in a binary format. The snapshot is saved in an Azure Storage account. The configurable backup frequency determines how often to persist the snapshot. If a catastrophic event occurs that disables both the primary and replica cache, the cache is reconstructed automatically using the most recent snapshot. Learn more about the [advantages](https://redis.io/topics/persistence#rdb-advantages) and [disadvantages](https://redis.io/topics/persistence#rdb-disadvantages) of RDB persistence.

+- _AOF persistence_ - When you use AOF persistence, Azure Cache for Redis saves every write operation to a log. The log is saved at least once per second in an Azure Storage account. If a catastrophic event occurs that disables both the primary and replica caches, the cache is reconstructed automatically using the stored write operations. Learn more about the [advantages](https://redis.io/topics/persistence#aof-advantages) and [disadvantages](https://redis.io/topics/persistence#aof-disadvantages) of AOF persistence.

+Azure Cache for Redis persistence features are intended to be used to restore data automatically to the same cache after data loss. The RDB/AOF persisted data files can't be imported to a new cache. To move data across caches, use the _Import and Export_ feature. For more information, see [Import and Export data in Azure Cache for Redis](cache-how-to-import-export-data.md).

+You have used [Visual Studio Code](functions-develop-vs-code.md?tabs=csharp) to create a function app with a simple HTTP-triggered function. In the next article, you expand that function by connecting to either Azure Cosmos DB or Azure Queue Storage. To learn more about connecting to other Azure services, see [Add bindings to an existing function in Azure Functions](add-bindings-existing-function.md?tabs=csharp).

+> [Run the monitor sample](durable-functions-monitor.md)

+## Durable Functions troubleshooting guide

+To troubleshoot common problem symptoms such as orchestrations being stuck, failing to start, running slowly, etc., refer to this [troubleshooting guide](durable-functions-troubleshooting-guide.md).

+For more information about the Durable Task MSSQL backend architecture, configuration, and workload behavior, see the [MSSQL storage provider documentation](https://microsoft.github.io/durabletask-mssql/).

+An [`IReadOnlyList<T>`](/dotnet/api/system.collections.generic.ireadonlylist-1) is used as the Azure Cosmos DB trigger binding parameter in the following example:

+This example requires the following `using` statements:

+[Azure Tools extension]: https://marketplace.visualstudio.com/items?itemName=ms-vscode.vscode-node-azure-pack

+> * Create a function that responds to HTTP requests.

+1. In **Configure your new project**, enter a **Project name** for your project, and then select **Next**. The function app name must be valid as a C# namespace, so don't use underscores, hyphens, or any other nonalphanumeric characters.

+1. In the `HttpTrigger` method named `Run`, rename the `FunctionName` method attribute to `HttpExample`.

+Visual Studio integrates with Azure Functions Core Tools so that you can test your functions locally using the full Azure Functions runtime.

+Visual Studio can publish your local project to Azure. Before you can publish your project, you must have a function app in your Azure subscription. If you don't already have a function app in Azure, Visual Studio publishing creates one for you the first time you publish your project. In this article, you create a function app and related Azure resources.

+1. Right-click the function app and choose **Open in Browser**. This opens the root of your function app in your default web browser and displays the page that indicates your function app is running.

+*Resources* in Azure refer to function apps, functions, storage accounts, and so forth. They're grouped into *resource groups*, and you can delete everything in a group by deleting the group.

+In this quickstart, you used Visual Studio to create and publish a C# function app in Azure with a simple HTTP trigger function.

+ Title: Configure Project Health Insights containers

+description: Project Health Insights containers use a common configuration framework, so that you can easily configure and manage storage, logging and telemetry, and security settings for your containers.

+# Configure Project Health Insights docker containers

+Project Health Insights provides each container with a common configuration framework, so that you can easily configure and manage storage, logging and telemetry, and security settings for your containers. Several [example docker run commands](use-containers.md#run-the-container-with-docker-run) are also available.

+## Configuration settings

+The container has the following configuration settings:

+|Required|Setting|Purpose|

+|--|--|--|

+|Yes|[ApiKey](#apikey-configuration-setting)|Tracks billing information.|

+|Yes|[Billing](#billing-configuration-setting)|Specifies the endpoint URI of the service resource on Azure.|

+|Yes|[Eula](#eula-setting)| Indicates that you've accepted the license for the container.|

+|No|[ApplicationInsights__InstrumentationKey ](#applicationinsights-setting)|Enables adding [Azure Application Insights](/azure/application-insights) telemetry support to your container.|

+|Yes|[RAI_Terms](#rai-terms-setting)| Indicates acceptance of Responsible AI terms.|

+> [!IMPORTANT]

+> The [`ApiKey`](#apikey-configuration-setting), [`Billing`](#billing-configuration-setting), and [`Eula`](#eula-setting) settings are used together, and you must provide valid values for all three of them; otherwise your container won't start. For more information about using these configuration settings to instantiate a container, see [Billing](use-containers.md#billing).

+## ApiKey configuration setting

+The `ApiKey` setting specifies the Azure resource key used to track billing information for the container. You must specify a value for the ApiKey and the value must be a valid key for the _Health Insights_ resource specified for the [`Billing`](#billing-configuration-setting) configuration setting.

+This setting can be found in the following place:

+* Azure portal: **Health Insights** resource management, under **Keys and endpoint**

+## ApplicationInsights setting

+The `ApplicationInsights` setting allows you to add [Azure Application Insights](/azure/application-insights) telemetry support to your container. Application Insights provides in-depth monitoring of your container. You can easily monitor your container for availability, performance, and usage. You can also quickly identify and diagnose errors in your container.

+The following table describes the configuration settings supported under the `ApplicationInsights` section.

+|Required| Name | Data type | Description |

+|--||--|-|

+|No| `InstrumentationKey` | String | The instrumentation key of the Application Insights instance to which telemetry data for the container is sent.

+## Billing configuration setting

+The `Billing` setting specifies the endpoint URI of the resource on Azure used to meter billing information for the container. You must specify a value for this configuration setting, and the value must be a valid endpoint URI for a resource on Azure. The container reports usage about every 10 to 15 minutes.

+This setting can be found in the following place:

+* Azure portal: **Health Insights** Overview, labeled `Endpoint`

+|Required| Name | Data type | Description |

+|--||--|-|

+|Yes| `Billing` | String | Billing endpoint URI. For more information on obtaining the billing URI, see [gather required parameters](use-containers.md).

+## Eula setting

+The `Eula` setting indicates that you've accepted the license for the container. You must specify a value for this configuration setting, and the value must be set to `accept`.

+|Required| Name | Data type | Description |

+|--||--|-|

+|Yes| `Eula` | String | License acceptance **Example:** `Eula=accept` |

+Project Health Insights containers are licensed under [your agreement](https://go.microsoft.com/fwlink/?linkid=2018657) governing your use of Azure. If you don't have an existing agreement governing your use of Azure, you agree that your agreement use of Azure is the [Microsoft Online Subscription Agreement](https://go.microsoft.com/fwlink/?linkid=2018755), which incorporates the [Online Services Terms](https://go.microsoft.com/fwlink/?linkid=2018760). For previews, you also agree to the [Supplemental Terms of Use for Microsoft Azure Previews](https://go.microsoft.com/fwlink/?linkid=2018815). By using the container, you agree to these terms.

+## RAI-Terms setting

+The `RAI_Terms` setting indicates acceptance of Responsible AI terms. You must specify a value for this configuration setting, and this value must be set to 'accept'.

+|Required| Name | Data type | Description |

+|--||--|-|

+|Yes| `RAI_Terms` | String | Responsible AI terms acceptance **Example:** `RAI_Terms=accept` |

+## Logging settings

+

+The `Logging` settings manage logging support for your container. You can use the same configuration settings and values for your container that you use for an ASP.NET Core applications.

+The following logging providers are supported by the container:

+|Provider|Purpose|

+|--|--|

+|[Console](/aspnet/core/fundamentals/logging/#console-provider)|The ASP.NET Core `Console` logging provider. All of the ASP.NET Core configuration settings and default values for this logging provider are supported.|

+|[Debug](/aspnet/core/fundamentals/logging/#debug-provider)|The ASP.NET Core `Debug` logging provider. All of the ASP.NET Core configuration settings and default values for this logging provider are supported.|

+|[Disk](#disk-logging)|The JSON logging provider. This logging provider writes log data to the output mount.|

+This container command stores logging information in the JSON format to the output mount:

+```bash

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

+--memory 2g --cpus 1 \

+--mount type=bind,src=/home/azureuser/output,target=/output \

+<registry-location>/<image-name> \

+Eula=accept \

+Billing=<endpoint> \

+ApiKey=<api-key> \

+Logging:Disk:Format=json \

+Mounts:Output=/output

+```

+This container command shows debugging information, prefixed with `debug`, while the container is running:

+```bash

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

+--memory 2g --cpus 1 \

+<registry-location>/<image-name> \

+Eula=accept \

+Billing=<endpoint> \

+ApiKey=<api-key> \

+Logging:Console:LogLevel:Default=Debug

+```

+### Disk logging

+The `Disk` logging provider supports the following configuration settings:

+| Name | Data type | Description |

+||--|-|

+|`Format` | String | The output format for log files. Note: This value must be set to `json` to enable the logging provider. If this value is specified without also specifying an output mount while instantiating a container, an error occurs. |

+| `MaxFileSize` | Integer | The maximum size, in megabytes (MB), of a log file. When the size of the current log file meets or exceeds this value, a new log file is started by the logging provider. If -1 is specified, the size of the log file is limited only by the maximum file size, if any, for the output mount. The default value is 1. |

+ Title: How to use Project Health Insights containers

+description: Learn how to use Project Health Insight models on premises using Docker containers.

+# Use Project Health Insights containers

+These services enable you to host Project Health Insights API on your own infrastructure. If you have security or data governance requirements that can't be fulfilled by calling Project Health Insights remotely, then on-premises Project Health Insights services might be a good solution.

+## Prerequisites

+You must meet the following prerequisites before using Project Health Insights containers.

+* If you don't have an Azure subscription, create a [free account](https://azure.microsoft.com/free/cognitive-services/) before you begin.

+* [Docker](https://docs.docker.com/) installed on a host computer. Docker must be configured to allow the containers to connect with and send billing data to Azure.

+ * On Windows, Docker must also be configured to support Linux containers.

+ * You should have a basic understanding of [Docker concepts](https://docs.docker.com/get-started/overview/).

+* A [Health Insights resource](https://ms.portal.azure.com/#create/Microsoft.CognitiveServicesHealthInsights)

+## Host computer requirements and recommendations

+The host that runs the Docker container on your premises, should be an x64-based computer. It can also be a Docker hosting service in Azure, such as:

+* [Azure Kubernetes Service](../../articles/aks/index.yml).

+* [Azure Container Instances](../../articles/container-instances/index.yml).

+* A [Kubernetes](https://kubernetes.io/) cluster deployed to [Azure Stack](/azure-stack/operator). For more information, see [Deploy Kubernetes to Azure Stack](/azure-stack/user/azure-stack-solution-template-kubernetes-deploy).

+The following table describes the minimum and recommended specifications for the different Health Insights containers.

+| Model | Minimum cpu | Maximum cpu | Minimum memory | Maximum memory| |

+|-|--|--|--|--|--|

+| Trial Matcher | 4000m |4000m |5G | 7G |

+| OncoPhenotype | 4000m |8000m |2G | 12G |

+CPU core and memory correspond to the `--cpus` and `--memory` settings, which are used as part of the `docker run` command.

+## Get the container images with `docker pull`

+Project Health Insights container images can be found on the `mcr.microsoft.com` container registry syndicate. They reside within the `azure-cognitive-services/health-insights/` repository and can be found by their model name.

+- Clinical Trial Matcher: The fully qualified container image name is `mcr.microsoft.com/azure-cognitive-services/health-insights/clinical-matching`

+- Onco-Phenotype: The fully qualified container image name is `mcr.microsoft.com/azure-cognitive-services/health-insights/cancer-profiling`

+To use the latest version of the container, you can use the `latest` tag. You can find a full list of tags on the MCR via `https://mcr.microsoft.com/v2/azure-cognitive-services/health-insights/clinical-matching/tags/list` and `https://mcr.microsoft.com/v2/azure-cognitive-services/health-insights/cancer-profiling/tags/list`.

+- Use the [`docker pull`](https://docs.docker.com/engine/reference/commandline/pull/) command to download this container image from the Microsoft public container registry. You can find the featured tags on the [dockerhub clinical matching page](https://hub.docker.com/_/microsoft-azure-cognitive-services-health-insights-clinical-matching) and [dockerhub cancer profiling page](https://hub.docker.com/_/microsoft-azure-cognitive-services-health-insights-cancer-profiling)

+```

+docker pull mcr.microsoft.com/azure-cognitive-services/health-insights/<model-name>:<tag-name>

+```

+- For Clinical Trial Matcher, use the [`docker pull`](https://docs.docker.com/engine/reference/commandline/pull/) command to download textanalytics healthcare container image from the Microsoft public container registry. You can find the featured tags on the [dockerhub](https://hub.docker.com/_/microsoft-azure-cognitive-services-textanalytics-healthcare)

+```

+docker pull mcr.microsoft.com/azure-cognitive-services/textanalytics/healthcare:<tag-name>

+```

+> [!TIP]

+> You can use the [docker images](https://docs.docker.com/engine/reference/commandline/images/) command to list your downloaded container images. For example, the following command lists the ID, repository, and tag of each downloaded container image, formatted as a table:

+>

+> ```

+> docker images --format "table {{.ID}}\t{{.Repository}}\t{{.Tag}}"

+>

+> IMAGE ID REPOSITORY TAG

+> <image-id> <repository-path/name> <tag-name>

+> ```

+## Run the container with `docker run`

+Once the container is on the host computer, use the [docker run](https://docs.docker.com/engine/reference/commandline/run/) command to run the containers. The container continues to run until you stop it.

+container-

+> [!IMPORTANT]

+> * The docker commands in the following sections use the back slash, `\`, as a line continuation character. Replace or remove this based on your host operating system's requirements.

+> * The `Eula`, `Billing`, and `ApiKey` options must be specified to run the container; otherwise, the container won't start. For more information, see [Billing](#billing).

+> * The responsible AI '`RAI_Terms` acknowledgment must also be present with a value of `accept`.

+There are multiple ways you can install and run Project Health Insights containers.

+- Use the Azure portal to create a Project Health Insights resource, and use Docker to get your container.

+- Use an Azure VM with Docker to run the container.

+- Use PowerShell and Azure CLI scripts to automate resource deployment and container configuration.

+When you use Project Health Insights container, the data contained in your API requests and responses isn't visible to Microsoft, and is not used for training the model applied to your data.

+### Run the container locally

+> [!IMPORTANT]

+> The docker run command can only be used of the cancer-profiling model, to use the clinical-matching model, you should use the docker compose command. see Example Docker compose file.

+To run the container in your own environment after downloading the container image, execute the following `docker run` command. Replace the placeholders below with your own values:

+| Placeholder | Value | Format or example |

+|-|-||

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

+| **{ENDPOINT_URI}** | The endpoint for accessing the API. You can find it on your resource's **Key and endpoint** page, on the Azure portal. | `https://<your-custom-subdomain>.cognitiveservices.azure.com` |

+```bash

+docker run --rm -it -p 5000:5000 --cpus 6 --memory 12g \

+mcr.microsoft.com/azure-cognitive-services/health-insights/<model-name>:<tag-name> \

+Eula=accept \

+rai_terms=accept \

+Billing={ENDPOINT_URI} \

+ApiKey={API_KEY}

+```

+For Clinical Trials, add this value:

+TrialMatcher__TA4HConfiguration__Host = `https://<text-analytics-container-endpoint>:5000`

+This command:

+- Runs Project Health Insights container from the container image

+- Allocates 6 CPU core and 12 gigabytes (GB) of memory

+- Exposes TCP port 5000 and allocates a pseudo-TTY for the container

+- Accepts the end user license agreement (EULA) and responsible AI (RAI) terms

+- Automatically removes the container after it exits. The container image is still available on the host computer.

+### Submit a query to the container

+Use the example cURL request as a reference how to submit a query to the container you have deployed replacing the `serverURL` variable with the appropriate value.

+```bash

+curl -X POST 'http://<serverURL>:5000/health-insights/<model>/' --header 'Content-Type: application/json' --header 'accept: application/json' --data-binary @example.json

+```

+#### Example docker compose file

+The below example shows how a [docker compose](https://docs.docker.com/compose/reference/overview) file can be created to deploy the health-insights containers.

+```yaml

+version: "3"

+ azure-cognitive-service-health-insights-clinical-matching:

+ container_name: azure-cognitive-service-health-insights-clinical-matching

+ image: {TRIAL_MATCHER_IMAGE_ID}

+ environment:

+ - EULA=accept

+ - RAI_TERMS=accept

+ - billing={AHI_ENDPOINT_URI}

+ - ApiKey={AHI_API_KEY}

+ - TrialMatcher__TA4HConfiguration__Host={http://<text-analytics container endpoint>:5000}

+ ports:

+ - 5000:5000/tcp

+ networks:

+ - hivnet

+ azure-cognitive-service-ta4h:

+ container_name: azure-cognitive-service-ta4h

+ image: {TA4H_IMAGE_ID}

+ environment:

+ - EULA=accept

+ - RAI_TERMS=accept

+ - billing={TA4H_ENDPOINT_URI}

+ - ApiKey={TA4H_API_KEY}

+ networks:

+ - hivnet

+networks:

+ ds4hvnet:

+ driver: bridge

+```

+To initiate this Docker compose file, execute the following command from a console at the root level of the file:

+```bash

+docker-compose up

+```

+### Run multiple containers on the same host

+If you intend to run multiple containers with exposed ports, make sure to run each container with a different exposed port. For example, run the first container on port 5000 and the second container on port 5001.

+You can have this container and a different Project Health Insights container running on the HOST together. You also can have multiple containers of the same Project Health Insights container running.

+## Query the container's prediction endpoint

+The container provides REST-based query prediction endpoint APIs.

+Use the host, `http://localhost:5000`, for container APIs.

+### Validate that a container is running

+There are several ways to validate that the container is running. Locate the *External IP* address and exposed port of the container in question, and open your favorite web browser. Use the various request URLs that follow to validate the container is running. The example request URLs listed here are `http://localhost:5000`, but your specific container might vary. Make sure to rely on your container's *External IP* address and exposed port.

+| Request URL | Purpose |

+|--|--|

+| `http://localhost:5000/` | The container provides a home page. |

+| `http://localhost:5000/ready` | Requested with GET, this URL provides a verification that the container is ready to accept a query against the model. This request can be used for Kubernetes [liveness and readiness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/). |

+| `http://localhost:5000/status` | Also requested with GET, this URL verifies if the api-key used to start the container is valid without causing an endpoint query. This request can be used for Kubernetes [liveness and readiness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/). |

+## Stop the container

+To shut down the container, in the command-line environment where the container is running, select `Ctrl+C`.

+## Troubleshooting

+If you run the container with an output mount and logging enabled, the container generates log files. The log files are helpful to troubleshoot issues that happen while starting or running the container.

+## Billing

+Project Health Insights containers send billing information to Azure, using a _Language_ resource on your Azure account.

+Queries to the container are billed at the pricing tier of the Azure resource that's used for the `ApiKey` parameter.

+Project Health Insights containers aren't licensed to run without being connected to the metering or billing endpoint. You must enable the containers to communicate billing information with the billing endpoint always. Project Health Insights containers don't send customer data, such as the image or text that's being analyzed, to Microsoft.

+### Connect to Azure

+The container needs the billing argument values to run. These values allow the container to connect to the billing endpoint. The container reports usage about every **10 to 15 minutes**. If the container doesn't connect to Azure within the allowed time window, the container continues to run but doesn't serve queries until the billing endpoint is restored. The connection is attempted 10 times at the same time interval of 10 to 15 minutes. If it can't connect to the billing endpoint within the 10 tries, the container stops serving requests.

+### Billing arguments

+The [docker run](https://docs.docker.com/engine/reference/commandline/run/) command starts the container when all three of the following options are provided with valid values:

+| Option | Description |

+|--|-|

+| `ApiKey` | The API key of Project Health Insights resource that's used to track billing information.<br/>The value of this option must be set to an API key for the provisioned resource that's specified in `Billing`. |

+| `Billing` | The endpoint of Project Health Insights resource that's used to track billing information.<br/>The value of this option must be set to the endpoint URI of a provisioned Azure resource.|

+| `Eula` | Indicates that you accepted the license for the container.<br/>The value of this option must be set to **accept**. |

+## Summary

+In this article, you learned concepts and workflow for downloading, installing, and running Project Health Insights containers. In summary:

+* Project Health Insights provides a Linux container for Docker

+* Container images are downloaded from the Microsoft Container Registry (MCR).

+* Container images run in Docker.

+* You can use either the REST API or SDK to call operations in Project Health Insights containers by specifying the host URI of the container.

+* You must specify billing information when instantiating a container.

+> [!IMPORTANT]

+> Project Health Insights containers are not licensed to run without being connected to Azure for metering. Customers need to enable the containers to communicate billing information with the metering service at all times. Project Health Insights containers do not send customer data (e.g. text that is being analyzed) to Microsoft.

+## Next steps

+>[!div class="nextstepaction"]

+* See [Configure containers](configure-containers.md) for configuration settings.

+[Cluster aggregates]: https://samples.azuremaps.com/?search=clusters&sample=cluster-aggregates

+[Create a function access key]: ../azure-functions/functions-bindings-http-webhook-trigger.md?tabs=csharp#authorization-keys

+> [Azure Maps Samples](https://github.com/Azure-Samples/Azure-Maps-AzureAD-Samples/tree/master/src/ImplicitGrant)

+> [Drawing manager](/javascript/api/azure-maps-drawing-tools/atlas.drawing.drawingmanager)

+> [Add a polygon layer](map-add-shape.md)

+> [Add HTML Makers](map-add-bubble-layer.md)

+> [Add a polygon layer](map-add-shape.md)

+> [Azure Maps GeoJSON specification extension](extend-geojson.md#circle)

+> [Code samples](/samples/browse/?products=azure-maps)

+> [Azure Maps GeoJSON specification extension](extend-geojson.md#circle)

+> [Drawing toolbar](/javascript/api/azure-maps-drawing-tools/atlas.control.drawingtoolbar)

+> [Code sample page](https://aka.ms/AzureMapsSamples)

+> [Supported data format details](spatial-io-supported-data-format-details.md)

+> [Supported data format details](spatial-io-supported-data-format-details.md)

+[Supported data format details](spatial-io-supported-data-format-details.md)

+[Add an OGC map layer](spatial-io-add-ogc-map-layer.md)

+[routeURL]: /javascript/api/azure-maps-rest/atlas.service.routeurl

+| Category | Area | Azure Monitor Agent | Log Analytics Agent | Diagnostics extension (WAD) |

+|:|:|:|:|:|

+| Category | Area | Azure Monitor Agent | Log Analytics Agent | Diagnostics extension (LAD) | Telegraf agent |

+|:|:|:|:|:|:|

+| Windows 11 Client Enterprise<br>(including multi-session) and Pro | X², ³ | | |

+# Customer intent: As an Azure account administrator, I want to use the available Azure Monitor tools to migrate from Log Analytics Agent to Azure Monitor Agent and track the status of the migration in my account.

+ Title: Collect Firewall logs with Azure Monitor Agent

+description: Configure collection of Windows Firewall logs on virtual machines with Azure Monitor Agent.

+# Collect Firewall logs with Azure Monitor Agent (Preview)

+Windows Firewall is a Microsoft Windows application that filters information coming to your system from the Internet and blocks potentially harmful programs. It is also known as Microsoft Defender Firewall in Windows 10 version 2004 and later. You can turn it on or off by following these steps:

+- Select Start, then open Settings

+- Under Update & Security, select Windows Security, Firewall & network protection.

+- Select a network profile: domain, private, or public.

+- Under Microsoft Defender Firewall, switch the setting to On or Off.

+## Prerequisites

+To complete this procedure, you need:

+- Log Analytics workspace where you have at least [contributor rights](../logs/manage-access.md#azure-rbac).

+- [Data collection endpoint](../essentials/data-collection-endpoint-overview.md#create-a-data-collection-endpoint).

+- [Permissions to create Data Collection Rule objects](../essentials/data-collection-rule-overview.md#permissions) in the workspace.

+- A Virtual Machine, Virtual Machine Scale Set, or Arc-enabled on-premises machine that is running firewall.

+## Create a data collection rule to collect firewall logs

+The [data collection rule](../essentials/data-collection-rule-overview.md) defines:

+- Which source log files Azure Monitor Agent scans for new events.

+- How Azure Monitor transforms events during ingestion.

+- The destination Log Analytics workspace and table to which Azure Monitor sends the data.

+You can define a data collection rule to send data from multiple machines to multiple Log Analytics workspaces, including workspaces in a different region or tenant. Create the data collection rule in the *same region* as your Analytics workspace.

+> [!NOTE]

+> To send data across tenants, you must first enable [Azure Lighthouse](../../lighthouse/overview.md).

+To create the data collection rule in the Azure portal:

+1. On the **Monitor** menu, select **Data Collection Rules**.

+1. Select **Create** to create a new data collection rule and associations.

+ [  ](media/data-collection-rule-azure-monitor-agent/data-collection-rules-updated.png#lightbox)

+1. Enter a **Rule name** and specify a **Subscription**, **Resource Group**, **Region**, and **Platform Type**:

+ - **Region** specifies where the DCR will be created. The virtual machines and their associations can be in any subscription or resource group in the tenant.

+ - **Platform Type** specifies the type of resources this rule can apply to. The **Custom** option allows for both Windows and Linux types.

+ -**Data Collection End Point** select a previously created data [collection end point](../essentials/data-collection-endpoint-overview.md).

+ [  ](media/data-collection-rule-azure-monitor-agent/data-collection-rule-basics-updated.png#lightbox)

+1. On the **Resources** tab:

+ 1. Select **+ Add resources** and associate resources with the data collection rule. Resources can be Virtual Machines, Virtual Machine Scale Sets, and Azure Arc for servers. The Azure portal installs Azure Monitor Agent on resources that don't already have it installed.

+ > [!IMPORTANT]

+ > The portal enables system-assigned managed identity on the target resources, along with existing user-assigned identities, if there are any. For existing applications, unless you specify the user-assigned identity in the request, the machine defaults to using system-assigned identity instead.

+

+ If you need network isolation using private links, select existing endpoints from the same region for the respective resources or [create a new endpoint](../essentials/data-collection-endpoint-overview.md).

+ 1. Select **Enable Data Collection Endpoints**.

+ 1. Select a data collection endpoint for each of the resources associate to the data collection rule.

+ [  ](media/data-collection-rule-azure-monitor-agent/data-collection-rule-virtual-machines-with-endpoint.png#lightbox)

+1. On the **Collect and deliver** tab, select **Add data source** to add a data source and set a destination.

+1. Select **Firewall Logs**.

+ [ ](media/data-collection-rule-azure-monitor-agent/firewall-data-collection-rule.png#lightbox)

+1. On the **Destination** tab, add one or more destinations for the data source. You can select multiple destinations of the same or different types. For instance, you can select multiple Log Analytics workspaces, which is also known as multihoming.

+ [  ](media/data-collection-rule-azure-monitor-agent/data-collection-rule-destination.png#lightbox)

+1. Select **Review + create** to review the details of the data collection rule and association with the set of virtual machines.

+1. Select **Create** to create the data collection rule.

+> [!NOTE]

+> It can take up to 5 minutes for data to be sent to the destinations after you create the data collection rule.

+### Sample log queries

+- **Count the firewall log entries by URL for the host www.contoso.com.**

+

+ ```kusto

+ WindowsFirewall

+ | where csHost=="www.contoso.com"

+ | summarize count() by csUriStem

+ ```

+## Troubleshoot

+Use the following steps to troubleshoot the collection of firewall logs.

+### Run Azure Monitor Agent troubleshooter

+To test your configuration and share logs with Microsoft [use the Azure Monitor Agent Troubleshooter](use-azure-monitor-agent-troubleshooter.md)

+### Check if any firewall logs have been received

+Start by checking if any records have been collected for your firewall logs by running the following query in Log Analytics. If the query doesn't return records, check the other sections for possible causes. This query looks for entries in the last two days, but you can modify for another time range.

+``` kusto

+WindowsFirewall

+| where TimeGenerated > ago(48h)

+| order by TimeGenerated desc

+```

+### Verify that firewall logs are being created

+Look at the timestamps of the log files and open the latest to see that latest timestamps are present in the log files. The default location for firewall log files is C:\windows\system32\logfiles\firewall\pfirewall.log

+## Next steps

+Learn more about:

+- [Azure Monitor Agent](azure-monitor-agent-overview.md).

+- [Data collection rules](../essentials/data-collection-rule-overview.md).

+- [Data collection endpoints](../essentials/data-collection-endpoint-overview.md)

+* Use [Custom Fields](../logs/custom-fields.md) to parse data from syslog records into individual fields.

+> Log Analytics agent for Linux v1.1.0-217+ is required for Custom JSON Data.

+> This collection flow only works with MMA. Consider moving to the AMA agent and using the additional collection features available there

+>

+* Learn about [log queries](../logs/log-query-overview.md) to analyze the data collected from data sources and solutions.

+* Learn about [log queries](../logs/log-query-overview.md) to analyze the data collected from data sources and solutions.

+You can use the current ScheduledQueryRules API to set **Aggregate On** in [Metric measurement](alerts-unified-log.md#calculation-of-a-value) rules, which work as expected. To learn more about switching to the current ScheduledQueryRules API, see [Upgrade to the current Log Alerts API from legacy Log Analytics Alert API](./alerts-log-api-switch.md).

+ Title: Application Insights API Access with Microsoft Azure Active Directory (Azure AD) Authentication

+description: Learn how to authenticate and access the Azure Monitor Application Insights APIs using Azure AD

+# Application Insights API Access with Microsoft Azure Active Directory (Azure AD) Authentication

+You can submit a query request by using the Azure Monitor Application Insights endpoint `https://api.applicationinsights.io`. To access the endpoint, you must authenticate through Azure Active Directory (Azure AD).

+## Set up authentication

+To access the API, you register a client app with Azure AD and request a token.

+1. [Register an app in Azure AD](../logs/api/register-app-for-token.md).

+1. On the app's overview page, select **API permissions**.

+1. Select **Add a permission**.

+1. On the **APIs my organization uses** tab, search for **Application Insights** and select **Application Insights API** from the list.

+1. Select **Delegated permissions**.

+1. Select the **Data.Read** checkbox.

+1. Select **Add permissions**.

+Now that your app is registered and has permissions to use the API, grant your app access to your Application Insights resource.

+1. From your **Application Insights resource** overview page, select **Access control (IAM)**.

+1. Select **Add role assignment**.

+1. Select the **Reader** role and then select **Members**.

+1. On the **Members** tab, choose **Select members**.

+1. Enter the name of your app in the **Select** box.

+1. Select your app and choose **Select**.

+1. Select **Review + assign**.

+1. After you finish the Active Directory setup and permissions, request an authorization token.

+>[!Note]

+> For this example, we applied the Reader role. This role is one of many built-in roles and might include more permissions than you require. More granular roles and permissions can be created.

+## Request an authorization token

+Before you begin, make sure you have all the values required to make the request successfully. All requests require:

+- Your Azure AD tenant ID.

+- Your App Insights App ID - If you are currently using API Keys, this is the same app ID.

+- Your Azure AD client ID for the app.

+- An Azure AD client secret for the app.

+The Application Insights API supports Azure AD authentication with three different [Azure AD OAuth2](/azure/active-directory/develop/active-directory-protocols-oauth-code) flows:

+- Client credentials

+- Authorization code

+- Implicit

+### Client credentials flow

+In the client credentials flow, the token is used with the Application Insights endpoint. A single request is made to receive a token by using the credentials provided for your app in the previous step when you [register an app in Azure AD](../logs/api/register-app-for-token.md).

+Use the `https://api.applicationinsights.io` endpoint.

+#### Client credentials token URL (POST request)

+```http

+ POST /<your-tenant-id>/oauth2/token

+ Host: https://login.microsoftonline.com

+ Content-Type: application/x-www-form-urlencoded

+

+ grant_type=client_credentials

+ &client_id=<app-client-id>

+ &resource=https://api.applicationinsights.io

+ &client_secret=<app-client-secret>

+```

+A successful request receives an access token in the response:

+```http

+ {

+ token_type": "Bearer",

+ "expires_in": "86399",

+ "ext_expires_in": "86399",

+ "access_token": ""eyJ0eXAiOiJKV1QiLCJ.....Ax"

+ }

+```

+Use the token in requests to the Application Insights endpoint:

+```http

+ POST /v1/apps/yous_app_id/query?timespan=P1D

+ Host: https://api.applicationinsights.io

+ Content-Type: application/json

+ Authorization: bearer <your access token>

+ Body:

+ {

+ "query": "requests | take 10"

+ }

+```

+Example response:

+```{

+ "tables": [

+ {

+ "name": "PrimaryResult",

+ "columns": [

+ {

+ "name": "timestamp",

+ "type": "datetime"

+ },

+ {

+ "name": "id",

+ "type": "string"

+ },

+ {

+ "name": "source",

+ "type": "string"

+ },

+ {

+ "name": "name",

+ "type": "string"

+ },

+ {

+ "name": "url",

+ "type": "string"

+ },

+ {

+ "name": "success",

+ "type": "string"

+ },

+ {

+ "name": "resultCode",

+ "type": "string"

+ },

+ {

+ "name": "duration",

+ "type": "real"

+ },

+ {

+ "name": "performanceBucket",

+ "type": "string"

+ },

+ {

+ "name": "customDimensions",

+ "type": "dynamic"

+ },

+ {

+ "name": "customMeasurements",

+ "type": "dynamic"

+ },

+ {

+ "name": "operation_Name",

+ "type": "string"

+ },

+ {

+ "name": "operation_Id",

+ "type": "string"

+ },

+ {

+ "name": "operation_ParentId",

+ "type": "string"

+ },

+ {

+ "name": "operation_SyntheticSource",

+ "type": "string"

+ },

+ {

+ "name": "session_Id",

+ "type": "string"

+ },

+ {

+ "name": "user_Id",

+ "type": "string"

+ },

+ {

+ "name": "user_AuthenticatedId",

+ "type": "string"

+ },

+ {

+ "name": "user_AccountId",

+ "type": "string"

+ },

+ {

+ "name": "application_Version",

+ "type": "string"

+ },

+ {

+ "name": "client_Type",

+ "type": "string"

+ },

+ {

+ "name": "client_Model",

+ "type": "string"

+ },

+ {

+ "name": "client_OS",

+ "type": "string"

+ },

+ {

+ "name": "client_IP",

+ "type": "string"

+ },

+ {

+ "name": "client_City",

+ "type": "string"

+ },

+ {

+ "name": "client_StateOrProvince",

+ "type": "string"

+ },

+ {

+ "name": "client_CountryOrRegion",

+ "type": "string"

+ },

+ {

+ "name": "client_Browser",

+ "type": "string"

+ },

+ {

+ "name": "cloud_RoleName",

+ "type": "string"

+ },

+ {

+ "name": "cloud_RoleInstance",

+ "type": "string"

+ },

+ {

+ "name": "appId",

+ "type": "string"

+ },

+ {

+ "name": "appName",

+ "type": "string"

+ },

+ {

+ "name": "iKey",

+ "type": "string"

+ },

+ {

+ "name": "sdkVersion",

+ "type": "string"

+ },

+ {

+ "name": "itemId",

+ "type": "string"

+ },

+ {

+ "name": "itemType",

+ "type": "string"

+ },

+ {

+ "name": "itemCount",

+ "type": "int"

+ }

+ ],

+ "rows": [

+ [

+ "2018-02-01T17:33:09.788Z",

+ "|0qRud6jz3k0=.c32c2659_",

+ null,

+ "GET Reports/Index",

+ "http://fabrikamfiberapp.azurewebsites.net/Reports",

+ "True",

+ "200",

+ "3.3833",

+ "<250ms",

+ "{\"_MS.ProcessedByMetricExtractors\":\"(Name:'Requests', Ver:'1.0')\"}",

+ null,

+ "GET Reports/Index",

+ "0qRud6jz3k0=",

+ "0qRud6jz3k0=",

+ "Application Insights Availability Monitoring",

+ "9fc6738d-7e26-44f0-b88e-6fae8ccb6b26",

+ "us-va-ash-azr_9fc6738d-7e26-44f0-b88e-6fae8ccb6b26",

+ null,

+ null,

+ "AutoGen_49c3aea0-4641-4675-93b5-55f7a62d22d3",

+ "PC",

+ null,

+ null,

+ "52.168.8.0",

+ "Boydton",

+ "Virginia",

+ "United States",

+ null,

+ "fabrikamfiberapp",

+ "RD00155D5053D1",

+ "cf58dcfd-0683-487c-bc84-048789bca8e5",

+ "fabrikamprod",

+ "5a2e4e0c-e136-4a15-9824-90ba859b0a89",

+ "web:2.5.0-33031",

+ "051ad4ef-0776-11e8-ac6e-e30599af6943",

+ "request",

+ "1"

+ ],

+ [

+ "2018-02-01T17:33:15.786Z",

+ "|x/Ysh+M1TfU=.c32c265a_",

+ null,

+ "GET Home/Index",

+ "http://fabrikamfiberapp.azurewebsites.net/",

+ "True",

+ "200",

+ "716.2912",

+ "500ms-1sec",

+ "{\"_MS.ProcessedByMetricExtractors\":\"(Name:'Requests', Ver:'1.0')\"}",

+ null,

+ "GET Home/Index",

+ "x/Ysh+M1TfU=",

+ "x/Ysh+M1TfU=",

+ "Application Insights Availability Monitoring",

+ "58b15be6-d1e6-4d89-9919-52f63b840913",

+ "emea-se-sto-edge_58b15be6-d1e6-4d89-9919-52f63b840913",

+ null,

+ null,

+ "AutoGen_49c3aea0-4641-4675-93b5-55f7a62d22d3",

+ "PC",

+ null,

+ null,

+ "51.141.32.0",

+ "Cardiff",

+ "Cardiff",

+ "United Kingdom",

+ null,

+ "fabrikamfiberapp",

+ "RD00155D5053D1",

+ "cf58dcfd-0683-487c-bc84-048789bca8e5",

+ "fabrikamprod",

+ "5a2e4e0c-e136-4a15-9824-90ba859b0a89",

+ "web:2.5.0-33031",

+ "051ad4f0-0776-11e8-ac6e-e30599af6943",

+ "request",

+ "1"

+ ]

+ ]

+ }

+ ]

+}

+```

+### Authorization code flow

+The main OAuth2 flow supported is through [authorization codes](/azure/active-directory/develop/active-directory-protocols-oauth-code). This method requires two HTTP requests to acquire a token with which to call the Azure Monitor Application Insights API. There are two URLs, with one endpoint per request. Their formats are described in the following sections.

+#### Authorization code URL (GET request)

+```http

+ GET https://login.microsoftonline.com/YOUR_Azure AD_TENANT/oauth2/authorize?

+ client_id=<app-client-id>

+ &response_type=code

+ &redirect_uri=<app-redirect-uri>

+ &resource=https://api.applicationinsights.io

+```

+When a request is made to the authorize URL, the client\_id is the application ID from your Azure AD app, copied from the app's properties menu. The redirect\_uri is the homepage/login URL from the same Azure AD app. When a request is successful, this endpoint redirects you to the sign-in page you provided at sign-up with the authorization code appended to the URL. See the following example:

+```http

+ http://<app-client-id>/?code=AUTHORIZATION_CODE&session_state=STATE_GUID

+```

+At this point, you've obtained an authorization code, which you need now to request an access token.

+#### Authorization code token URL (POST request)

+```http

+ POST /YOUR_Azure AD_TENANT/oauth2/token HTTP/1.1

+ Host: https://login.microsoftonline.com

+ Content-Type: application/x-www-form-urlencoded

+

+ grant_type=authorization_code

+ &client_id=<app client id>

+ &code=<auth code fom GET request>

+ &redirect_uri=<app-client-id>

+ &resource=https://api.applicationinsights.io

+ &client_secret=<app-client-secret>

+```

+All values are the same as before, with some additions. The authorization code is the same code you received in the previous request after a successful redirect. The code is combined with the key obtained from the Azure AD app. If you didn't save the key, you can delete it and create a new one from the keys tab of the Azure AD app menu. The response is a JSON string that contains the token with the following schema. Types are indicated for the token values.

+Response example:

+```http

+ {

+ "access_token": "eyJ0eXAiOiJKV1QiLCJ.....Ax",

+ "expires_in": "3600",

+ "ext_expires_in": "1503641912",

+ "id_token": "not_needed_for_app_insights",

+ "not_before": "1503638012",

+ "refresh_token": "eyJ0esdfiJKV1ljhgYF.....Az",

+ "resource": "https://api.applicationinsights.io",

+ "scope": "Data.Read",

+ "token_type": "bearer"

+ }

+```

+The access token portion of this response is what you present to the Application Insights API in the `Authorization: Bearer` header. You can also use the refresh token in the future to acquire a new access\_token and refresh\_token when yours have gone stale. For this request, the format and endpoint are:

+```http

+ POST /YOUR_AAD_TENANT/oauth2/token HTTP/1.1

+ Host: https://login.microsoftonline.com

+ Content-Type: application/x-www-form-urlencoded

+

+ client_id=<app-client-id>

+ &refresh_token=<refresh-token>

+ &grant_type=refresh_token

+ &resource=https://api.applicationinsights.io

+ &client_secret=<app-client-secret>

+```

+Response example:

+```http

+ {

+ "token_type": "Bearer",

+ "expires_in": "3600",

+ "expires_on": "1460404526",

+ "resource": "https://api.applicationinsights.io",

+ "access_token": "eyJ0eXAiOiJKV1QiLCJ.....Ax",

+ "refresh_token": "eyJ0esdfiJKV1ljhgYF.....Az"

+ }

+```

+### Implicit code flow

+The Application Insights API supports the OAuth2 [implicit flow](/azure/active-directory/develop/active-directory-dev-understanding-oauth2-implicit-grant). For this flow, only a single request is required, but no refresh token can be acquired.

+#### Implicit code authorize URL

+```http

+ GET https://login.microsoftonline.com/YOUR_AAD_TENANT/oauth2/authorize?

+ client_id=<app-client-id>

+ &response_type=token

+ &redirect_uri=<app-redirect-uri>

+ &resource=https://api.applicationinsights.io

+```

+A successful request produces a redirect to your redirect URI with the token in the URL:

+```http

+ http://YOUR_REDIRECT_URI/#access_token=YOUR_ACCESS_TOKEN&token_type=Bearer&expires_in=3600&session_state=STATE_GUID

+```

+This access\_token can be used as the `Authorization: Bearer` header value when it's passed to the Application Insights API to authorize requests.

+> This document covers data ingestion into Application Insights using Azure AD. authentication. For information on querying data within Application Insights, see [Query Application Insights using Azure AD Authentication](./app-insights-azure-ad-api.md).

+* [Query Application Insights using Azure AD Authentication](./app-insights-azure-ad-api.md)

+ | Node.js | [Automatic web Instrumentation](./nodejs.md#automatic-web-instrumentationpreview) |

+- Review the [Application Insights config reference](configuration-with-applicationinsights-config.md).

+* [.NET trace logs in Application Insights](./asp-net-trace-logs.md)

+```

+```

+```

+To enable Application Insights, follow these steps.

+### 1. Add the JavaScript code

+Two methods are available to add the code to enable Application Insights via the Application Insights JavaScript SDK.

+#### [SDK Loader Script](#tab/sdkloaderscript)

+The benefits of this method are:

+

+- You never have to update the SDK because you get the latest updates automatically.

+- You have control over which pages you add the Application Insights JavaScript SDK to.

+To add the SDK Loader Script and its optional configuration, follow these steps:

+#### SDK Loader Script configuration

+#### [npm package](#tab/npmpackage)

+ connectionString: 'YOUR_CONNECTION_STRING'

+### 2. Add your connection string

+To add your connection string, follow these steps:

+ 1. Replace the placeholder `"YOUR_CONNECTION_STRING"` in the JavaScript code with your connection string copied to the clipboard.

+### 3. (Optional) Add SDK configuration

+The optional [SDK configuration](./javascript-sdk-advanced.md#sdk-configuration) is passed to the Application Insights JavaScript SDK during initialization.

+To add SDK configuration, add each configuration option directly under `connectionString`. For example:

+### 4. Confirm data is flowing

+1. Go to your Application Insights resource that you've enabled the SDK for.

+1. In the Application Insights resource menu on the left, under **Investigate**, select the **Transaction search** pane.

+1. Open the **Event types** dropdown menu and select **Select all** to clear the checkboxes in the menu.

+1. From the **Event types** dropdown menu, select **Page View**.

+ It might take a few minutes for data to show up in the portal.

+ :::image type="content" source="media/javascript-sdk/confirm-data-flowing.png" alt-text="Screenshot of the Application Insights Transaction search pane in the Azure portal with the Page View option selected. The page views are highlighted." lightbox="media/javascript-sdk/confirm-data-flowing.png":::

+- [JavaScript SDK advanced topics](javascript-sdk-advanced.md)

+#### What is collected automatically?

+When you enable the App Insights JavaScript SDK, the following data classes are collected automatically:

+- Uncaught exceptions in your app, including information on

+ - Stack trace

+ - Exception details and message accompanying the error

+ - Line & column number of error

+ - URL where error was raised

+- Network Dependency Requests made by your app XHR and Fetch (fetch collection is disabled by default) requests, include information on

+ - Url of dependency source

+ - Command & Method used to request the dependency

+ - Duration of the request

+ - Result code and success status of the request

+ - ID (if any) of user making the request

+ - Correlation context (if any) where request is made

+- User information (for example, Location, network, IP)

+- Device information (for example, Browser, OS, version, language, model)

+- Session information

+> [!Note]

+> For some applications, such as single-page applications (SPAs), the duration may not be recorded and will default to 0.

+For more information, see the following link: https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-monitor/app/data-retention-privacy.md

+* [Track page views](api-custom-events-metrics.md#page-views)

+* [JavaScript telemetry initializers](api-filtering-sampling.md#javascript-telemetry-initializers)

+When calling `StartActivity` it will default to `ActivityKind.Internal` but you can provide any other `ActivityKind`.

+`ActivityKind.Client`, `ActivityKind.Producer`, and `ActivityKind.Internal` are mapped to Application Insights `dependencies`.

+`ActivityKind.Server` and `ActivityKind.Consumer` are mapped to Application Insights `requests`.

+When calling `StartActivity` it will default to `ActivityKind.Internal` but you can provide any other `ActivityKind`.

+`ActivityKind.Client`, `ActivityKind.Producer`, and `ActivityKind.Internal` are mapped to Application Insights `dependencies`.

+`ActivityKind.Server` and `ActivityKind.Consumer` are mapped to Application Insights `requests`.

+* [SDK troubleshooting](./asp-net-troubleshoot-no-data.md)

+- Enable Application Insights for [Azure VM and Azure virtual machine scale set IIS-hosted apps](../../azure-monitor/app/azure-vm-vmss-apps.md).

+- Learn how to [troubleshoot problems in Change Analysis](change-analysis-troubleshoot.md)

+* [Azure Enterprise Policy as Code](https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/azure-enterprise-policy-as-code-a-new-approach/ba-p/3607843)

+ - *Alerts*: To list alerts, select **Alerts** on your workspace navigation pane, and then select **Manage alert rules** on the toolbar. Alerts in workspaces created after June 1, 2019, or in workspaces that were [upgraded from the Log Analytics Alert API to the scheduledQueryRules API](../alerts/alerts-log-api-switch.md) can be included in the template.

+ You can [check if the scheduledQueryRules API is used for alerts in your workspace](../alerts/alerts-log-api-switch.md#check-switching-status-of-workspace). Alternatively, you can configure alerts manually in the target workspace.

+> **Re-create alerts:** All alerts must be re-created because the permissions are based on the workspace resource ID, which changes during a workspace move or resource name change. Alerts in workspaces created after June 1, 2019, or in workspaces that were [upgraded from the legacy Log Analytics Alert API to the scheduledQueryRules API](../alerts/alerts-log-api-switch.md) can be exported in templates and deployed after the move. You can [check if the scheduledQueryRules API is used for alerts in your workspace](../alerts/alerts-log-api-switch.md#check-switching-status-of-workspace). Alternatively, you can configure alerts manually in the target workspace.

+The `withsource= SourceApp` command adds a column to the results that designates the application that sent the log. The parse operator is optional in this example and used to extract the application name from SourceApp property.

+>[Cross-resource queries](../logs/cross-workspace-query.md) in log alerts are only supported in the current [scheduledQueryRules API](/rest/api/monitor/scheduledqueryrule-2018-04-16/scheduled-query-rules). If you're using the legacy Log Analytics Alerts API, you'll need to [switch to the current API](../alerts/alerts-log-api-switch.md). [See example templates](../alerts/alerts-log-create-templates.md).

+|App setting | US Government Cloud | China Cloud |

+If your web app is an ASP.NET Core application, it must be running on the [latest supported ASP.NET Core runtime](https://dotnet.microsoft.com/download/dotnet/6.0).

+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

+ c:\logs\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics\1.11.3.12\DiagnosticsPlugin.log

+- [Virtual machine or other Azure service](./snapshot-debugger-vm.md)

+Logs|[Application Insights API Access with Microsoft Azure Active Directory (Azure AD) Authentication](app/app-insights-azure-ad-api.md)|New article that explains how to authenticate and access the Azure Monitor Application Insights APIs using Azure AD.|

+|[Upgrade legacy rules management to the current Log Alerts API from legacy Log Analytics Alert API](./alerts/alerts-log-api-switch.md)|The process of moving legacy log alert rules management from the legacy API to the current API is now supported by the government cloud.|

+| Maximum numbers of policy-based (scheduled) backups per volume | <ul><li> Daily retention count: 2 (minimum) to 1019 (maximum) </li> <li> Weekly retention count: 1 (minimum) to 1019 (maximum) </li> <li> Monthly retention count: 1 (minimum) to 1019 (maximum) </ol></li> <br> The maximum hourly, daily, weekly, and monthly backup retention counts *combined* is 1019. | N |

+- [Application resilience FAQs for Azure NetApp Files](faq-application-resilience.md)

+* [Enhanced Performance and Scalability: Azure AD-joined Session Hosts with Azure NetApp Files](https://techcommunity.microsoft.com/t5/azure-architecture-blog/enhanced-performance-and-scalability-azure-ad-joined-session/ba-p/3836576)

+* [Azure NetApp Files SMB volumes for Azure Kubernetes Services with Astra Trident on Windows](https://techcommunity.microsoft.com/t5/azure-architecture-blog/azure-netapp-files-smb-volumes-for-azure-kubernetes-services/ba-p/3052900)

+Azure NetApp Files backup supports *policy-based* (scheduled) backups and *manual* (on-demand) backups at the volume level. You can use both types of backups in the same volume. During the configuration process, you'll enable the backup feature for an Azure NetApp Files volume before policy-based backups or manual backups can be taken.

+## About policy-based backups

+Backups are long-running operations. The system schedules backups based on the primary workload (which is given a higher priority) and runs backups in the background. Depending on the size of the volume being backed up, a backup can run in background for hours. There's no option to select the start time for backups. The service performs the backups based on the internal scheduling and optimization logic.

+Assigning a policy creates a baseline snapshot that is the current state of the volume and transfers the snapshot to Azure storage. The baseline snapshot is created with a name starting with `baseline`. This baseline snapshot is deleted automatically when the first scheduled backup is complete (based on the policy). If the backup policy is attached to a volume, the backup list will be empty until the baseline snapshot is transferred. When the backup is complete, the baseline backup entry appears in the list of backups for the volume. After the baseline transfer, the list will be updated daily based on the policy. An empty list of backups indicates that the baseline backup is in progress. If a volume already has existing manual backups before you assign a backup policy, the baseline snapshot isn't created. A baseline snapshot is created only when the volume has no prior backups.

+You need to create a backup policy and associate the backup policy to the volume that you want to back up. A single backup policy can be attached to multiple volumes. Backups can be temporarily suspended either by disabling the policy or by disabling backups at the volume level. Backups can also be completely disabled at the volume level, resulting in the clean-up of all the associated data in the Azure storage. A backup policy can't be deleted if it's attached to any volumes.

+ :::image type="content" source="../media/azure-netapp-files/backup-navigate.png" alt-text="Screenshot that shows how to navigate to Backups option." lightbox="../media/azure-netapp-files/backup-navigate.png":::

+6. In the **Backup Policy** page, specify the backup policy name. Enter the number of backups that you want to keep for daily, weekly, and monthly backups. Click **Save**.

+ The minimum value for **Daily Backups to Keep** is 2.

+ :::image type="content" source="../media/azure-netapp-files/backup-policy-window-daily.png" alt-text="Screenshot that shows the Backup Policy window." lightbox="../media/azure-netapp-files/backup-policy-window-daily.png":::

+The following example configuration shows you how to configure a data protection policy on the volume. This configuration results in backing up 15 latest daily snapshots, 6 latest weekly snapshots, and 4 latest monthly snapshots.

+The following example configuration has a backup policy configured for daily backups. The daily backup policy is below the minimum of two. This configuration would back up only weekly and monthly snapshots.

+ Daily: `Daily Backups to Keep = 1`

+4. In the **Backup Policy** drop-down menu, assign the backup policy to use for the volume. Click **OK**.

+ :::image type="content" source="../media/azure-netapp-files/backup-configure-window.png" alt-text="Screenshot showing Configure Backups window." lightbox="../media/azure-netapp-files/backup-configure-window.png":::

+Azure NetApp Files backup expands the data protection capabilities of Azure NetApp Files by providing fully managed backup solution for long-term recovery, archive, and compliance. Backups created by the service are stored in Azure storage, independent of volume snapshots that are available for near-term recovery or cloning. Backups taken by the service can be restored to new Azure NetApp Files volumes within the region. Azure NetApp Files backup supports both policy-based (scheduled) backups and manual (on-demand) backups. For more information, see [How Azure NetApp Files snapshots work](snapshots-introduction.md).

+* For simplicity, assume your source volume has a constant 1% data change every day, but the total volume consumed size doesn't grow (remains at 500 GiB).

+You'll be billed at the end of month for backup at the rate of $0.05 per month for the total amount of storage consumed by the backup. That is, 650 GiB with a total monthly backup charge of `650*$0.05=$32.5`. Regular Azure NetApp Files storage capacity applies to local snapshots. For more information, see the [Azure NetApp Files Pricing](https://azure.microsoft.com/pricing/details/netapp/) page.

+If you choose to restore a backup of, for example, 600 GiB to a new volume, you'll be charged at the rate of $0.02 per GiB of backup capacity restores. In this case, it will be `600*$0.02 = $12` for the restore operation.

+After you have set up Azure NetApp Files backups using [a backup policy](backup-configure-policy-based.md), you can modify or suspend a backup policy as needed.

+* The Azure NetApp Files backup feature supports backing up the daily, weekly, and monthly local snapshots to the Azure storage. Hourly backups aren't currently supported.

+* Policy-based (scheduled) Azure NetApp Files backup is independent from [snapshot policy configuration](azure-netapp-files-manage-snapshots.md).

+* See [Restore a backup to a new volume](backup-restore-new-volume.md) for additional considerations related to restoring backups.

+* For increased security, you can select the **Disable public access** option within the network settings of your key vault. When selecting this option, you must also select **Allow trusted Microsoft services to bypass this firewall** to permit the Azure NetApp Files service to access your encryption key.

+## June 2023

+* [Customer-managed keys](configure-customer-managed-keys.md) for Azure NetApp Files now supports the option to Disable public access on the key vault that contains your encryption key. Selecting this option enhances network security by denying public configurations and allowing only connections through private endpoints.

+- Learn how to [share a dashboard by using Azure role-based access control](azure-portal-dashboard-share-access.md).

+[43]: ./media/service-bus-dotnet-hybrid-app-using-service-bus-relay/getting-started-hybrid-43.png

+- [Authenticate with managed identities](./signalr-howto-authorize-managed-identity.md)

+[Python Server SDK instruction](reference-server-sdk-python.md)

+- [Simple chatroom with AAD Auth](https://github.com/Azure/azure-webpubsub/tree/main/samples/java/chatapp-aad)

+- [Simple chatroom with AAD Auth](https://github.com/Azure/azure-webpubsub/tree/main/samples/javascript/chatapp-aad)

+- [Simple chatroom with AAD Auth](https://github.com/Azure/azure-webpubsub/tree/main/samples/python/chatapp-aad)

+- [Authenticate with managed identities](./howto-authorize-from-managed-identity.md)