- "total": 300000

-You can request to increase the quota size by [contacting support](find-help-open-support-ticket.md)

-[powershell-gallery]: https://www.powershellgallery.com/

-<!-- EXTERNAL LINKS -->

-[naming-prefix]: /windows-server/identity/ad-ds/plan/selecting-the-forest-root-domain#selecting-a-prefix

-> When a directory extension attribute in Azure AD doesn't show up automatically in your attribute mapping drop-down, you can manually add it to the "Azure AD attribute list". When manually adding Azure AD directory extension attributes to your provisioning app, note that directory extension attribute names are case-sensitive. For example: If you have a directory extension attribute named `extension_53c9e2c0exxxxxxxxxxxxxxxx_acmeCostCenter`, make sure you enter it in the same format as defined in the directory.

-1. Log in to the [Microsoft Entra portal](<https://entra.microsoft.com>).

-1. Log in to [Microsoft Entra portal](https://entra.microsoft.com) with *global administrator* or *application administrator* login credentials.

-1. Log in to Microsoft Entra portal with application administrator role.

-> If you'd like to add only a few additional attributes to the provisioning app, use Microsoft Entra Portal to extend the schema. If you'd like to add more custom attributes (let's say 20+ attributes), then we recommend using the [`UpdateSchema` mode of the CSV2SCIM PowerShell script](inbound-provisioning-api-powershell.md#extending-provisioning-job-schema) which automates the above manual process.

-1. Log in to Microsoft Entra portal (https://entra.microsoft.com) with global administrator or application administrator login credentials.

-You can verify the processing either from the Microsoft Entra portal or using Graph Explorer.

-### Verify processing from Microsoft Entra portal

-1. Log in to [Microsoft Entra portal](https://entra.microsoft.com) with *global administrator* or *application administrator* login credentials.

-You can verify the processing either from the Microsoft Entra portal or using Postman.

-### Verify processing from Microsoft Entra portal

-1. Log in to [Microsoft Entra portal](https://entra.microsoft.com) with *global administrator* or *application administrator* login credentials.

-1. Log in to your Entra portal as *Application Administrator* or *Global Administrator*.

-1. To associate this certificate with a valid service principal, log in to your Entra portal as *Application Administrator*.

-It doesn't refer to the attribute mappings that you perform in the Entra portal provisioning app between source SCIM schema elements and target Azure AD/on-premises AD attributes.

-Azure AD also supports provisioning users into applications hosted on-premises or in a virtual machine, without having to open up any firewalls. Your application must support [SCIM](https://aka.ms/scimoverview). Or, you must build a SCIM gateway to connect to your legacy application. If so, you can use the Azure AD Provisioning agent to [directly connect](./on-premises-scim-provisioning.md) with your application and automate provisioning and deprovisioning. If you have legacy applications that don't support SCIM and rely on an [LDAP](./on-premises-ldap-connector-configure.md) user store or a [SQL](./tutorial-ecma-sql-connector.md) database, Azure AD can support these applications as well.

-App provisioning lets you:

-Your users wonΓÇÖt notice anything different when they sign in to use your corporate applications. They can still work from anywhere on any device. The Application Proxy connectors direct remote traffic to all apps without regard to their authentication type, so theyΓÇÖll still balance loads automatically.

-This article is for people to publish an application with this scenario for the first time. Besides detailing the publishing steps, it guides you in getting started with both Application Proxy and PingAccess. If youΓÇÖve already configured both services but want a refresher on the publishing steps, skip to the [Add your application to Azure AD with Application Proxy](#add-your-application-to-azure-ad-with-application-proxy) section.

- 1. **Internal URL**: Normally you provide the URL that takes you to the appΓÇÖs sign-in page when youΓÇÖre on the corporate network. For this scenario, the connector needs to treat the PingAccess proxy as the front page of the application. Use this format: `https://<host name of your PingAccess server>:<port>`. The port is 3000 by default, but you can configure it in PingAccess.

- > If this is your first application, use port 3000 to start and come back to update this setting if you change your PingAccess configuration. For subsequent applications, the port will need to match the Listener youΓÇÖve configured in PingAccess. Learn more about [listeners in PingAccess](https://docs.pingidentity.com/access/sources/dita/topic?category=pingaccess&Releasestatus_ce=Current&resourceid=pa_assigning_key_pairs_to_https_listeners).

-1. From the **App registrations** sidebar for your application, select **API permissions** > **Add a permission** > **Microsoft APIs** > **Microsoft Graph**. The **Request API permissions** page for **Microsoft Graph** appears, which contains the APIs for Windows Azure Active Directory.

-OATH hardware tokens are supported as part of a public preview. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-| 239 | Sao Tome and Principe |

-It might sound alarming to not ask for a user to sign back in, though any violation of IT policies revokes the session. Some examples include a password change, an incompliant device, or an account disable operation. You can also explicitly [revoke users' sessions using PowerShell](/powershell/module/azuread/revoke-azureaduserallrefreshtoken).

-<img width="1112" alt="Entra portal Authenticator settings" src="https://user-images.githubusercontent.com/108090297/228603771-52c5933c-f95e-4f19-82db-eda2ba640b94.png">

-> Sign-in to Azure AD with email as an alternate login ID is a public preview feature of Azure Active Directory. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-To enable **Report suspicious activity** from the Authentication Methods Settings:

-1. Set **Report suspicious activity** to **Enabled**.

-OATH hardware tokens are supported as part of a public preview. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms).

-| Turkey | +90 8505404893 |

-1. Sign in to the [Entra portal](https://entra.microsoft.com/#home).

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

-1. Navigate to the **Azure portal** > **Azure Active Directory** > **Sign-in logs**.

-Filter for devices is an option when creating a Conditional Access policy in the Azure portal or using the Microsoft Graph API.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-Authentication contexts are managed in the Azure portal under **Azure Active Directory** > **Security** > **Conditional Access** > **Authentication context**.

-

-Create new authentication context definitions by selecting **New authentication context** in the Azure portal. Organizations are limited to a total of 25 authentication context definitions. Configure the following attributes:

-Find these templates in the **[Microsoft Entra admin center](https://entra.microsoft.com)** > **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access** > **Create new policy from templates**. Select **Show more** to see all policy templates in each category.

-> Conditional Access template policies will exclude only the user creating the policy from the template. If your organization needs to [exclude other accounts](../roles/security-emergency-access.md), you will be able to modify the policy once they are created. Simply navigate to **Microsoft Entra admin center** > **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access** > **Policies**, select the policy to open the editor and modify the excluded users and groups to select accounts you want to exclude.

-If you do find yourself locked out, see [What to do if you're locked out of the Azure portal?](troubleshoot-conditional-access.md#what-to-do-if-youre-locked-out-of-the-azure-portal)

-1. Sign in to the **Azure portal** as at least a Global Reader.

-1. Sign into the Azure portal as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

- For detailed steps, see [Assign Azure roles using the Azure portal](../../role-based-access-control/role-assignments-portal.md).

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **Azure portal**.

-1. Sign into the **Azure portal** as a Conditional Access Administrator, security administrator, or Global Administrator.

-In order to access the workbook, you need the proper Azure AD permissions and Log Analytics workspace permissions. To test whether you have the proper workspace permissions by running a sample log analytics query:

-1. Sign in to the **Azure portal**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **Azure portal** as a global administrator, security administrator, or Conditional Access administrator.

-1. Browse to **Azure Active Directory** > **Security** > **Authentication methods** > **Authentication strengths**.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-> Misconfiguration of a block policy can lead to organizations being locked out of the Azure portal.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

- > Persistent Browser Session configuration in Azure AD Conditional Access overrides the ΓÇ£Stay signed in?ΓÇ¥ setting in the company branding pane in the Azure portal for the same user if you have configured both policies.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-Locations exist in the Azure portal under **Azure Active Directory** > **Security** > **Conditional Access** > **Named locations**. These named network locations may include locations like an organization's headquarters network ranges, VPN network ranges, or ranges that you wish to block. Named locations are defined by IPv4 and IPv6 address ranges or by countries/regions.

-

-

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-Conditional Access is found in the Azure portal under **Azure Active Directory** > **Security** > **Conditional Access**.

-> Be very careful in using block and all apps in a single policy. This could lock admins out of the Azure portal, and exclusions cannot be configured for important endpoints such as Microsoft Graph.

-This article shows how to migrate a classic policy that requires **multifactor authentication** for a cloud app. Although it isn't a prerequisite, we recommend that you read [Migrate classic policies in the Azure portal](policy-migration.md) before you start migrating your classic policies.

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

-1. Navigate to **Azure Active Directory** > **Security** > **Conditional Access**.

-For examples of common policies and their configuration in the Azure portal, see the article [Common Conditional Access policies](concept-conditional-access-policy-common.md).

-1. Sign in to the [Azure portal](https://portal.azure.com) as a Conditional Access Administrator, Security Administrator, or a Global Administrator.

- :::image type="content" source="media/require-tou/terms-of-use-azure-ad-conditional-access.png" alt-text="Screenshot of terms of use shown in the Azure portal highlighting the new terms button." lightbox="media/require-tou/terms-of-use-azure-ad-conditional-access.png":::

- :::image type="content" source="media/require-tou/new-terms-of-use-creation.png" alt-text="Screenshot that shows creating a new terms of use policy in the Azure portal." lightbox="media/require-tou/new-terms-of-use-creation.png":::

-1. Navigate to the **Azure portal** > **Security** > **Conditional Access**

-1. Sign in to the **Azure portal** as a Conditional Access Administrator or Security Administrator.

-1. In the **Name** box, enter a name for the terms of use policy used in the Azure portal.

-1. Sign in to Azure and navigate to **Terms of use** at [https://aka.ms/catou](https://aka.ms/catou).

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Sign in to the **Azure portal** as a Global Administrator, Security Administrator, or Global Reader.

-## What to do if you're locked out of the Azure portal?

-If you're locked out of the Azure portal due to an incorrect setting in a Conditional Access policy:

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-You can find the **What If** tool in the Azure portal under **Azure Active Directory** > **Security** > **Conditional Access** > **What If**.

-Conditional Access policies have historically applied only to users when they access apps and services like SharePoint online or the Azure portal. We're now extending support for Conditional Access policies to be applied to service principals owned by the organization. We call this capability Conditional Access for workload identities.

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Sign in to the **[Microsoft Entra admin center](https://entra.microsoft.com)** as a [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator).

-1. Browse to **Azure Active Directory** > **Sign-in logs** > **Service principal sign-ins**.

-1. Browse to the **Azure portal** > **Azure Active Directory** > **Enterprise Applications**, find the application you registered.

-description: How to configure the permissions you need to access a particular API in your custom developed Azure AD application

-# How to find a specific API needed for a custom-developed application

-Access to APIs require configuration of access scopes and roles. If you want to expose your resource application web APIs to client applications, configure access scopes and roles for the API. If you want a client application to access a web API, configure permissions to access the API in the app registration.

-## Configuring a resource application to expose web APIs

-When you expose your web API, the API be displayed in the **Select an API** list when adding permissions to an app registration. To add access scopes, follow the steps outlined in [Configure an application to expose web APIs](quickstart-configure-app-expose-web-apis.md).

-## Configuring a client application to access web APIs

-When you add permissions to your app registration, you can **add API access** to exposed web APIs. To access web APIs, follow the steps outlined in [Configure a client application to access web APIs](quickstart-configure-app-access-web-apis.md).

-## Next steps

-#Customer intent: As an app developer, I want to learn about authentication flows and application scenarios so I can create applications protected by the Microsoft identity platform.

-# Authentication flows and application scenarios

-Tokens can be acquired from several types of applications, including:

-## Application scenarios

-Applications running on a device without a browser can still call an API on behalf of a user. To authenticate, the user must sign in on another device that has a web browser. This scenario requires that you use the [device code flow](https://aka.ms/msal-net-device-code-flow).

-Some scenarios, like those that involve Conditional Access related to a device ID or a device enrollment, require a broker to be installed on the device. Examples of brokers are Microsoft Company Portal on Android and Microsoft Authenticator on Android and iOS. MSAL can now interact with brokers. For more information about brokers, see [Leveraging brokers on Android and iOS](https://github.com/AzureAD/azure-activedirectory-library-for-dotnet/wiki/leveraging-brokers-on-Android-and-iOS).

-description: An overview of the authentication protocols supported by the Microsoft identity platform

-# Microsoft identity platform authentication protocols

-The Microsoft identity platform supports several of the most widely used authentication and authorization protocols. The topics in this section describe the supported protocols and their implementation in Microsoft identity platform. The topics included a review of supported claim types, an introduction to the use of federation metadata, detailed OAuth 2.0. and SAML 2.0 protocol reference documentation, and a troubleshooting section.

-## Authentication protocols articles and reference

-* [Important Information About Signing Key Rollover in Microsoft identity platform](./signing-key-rollover.md) ΓÇô Learn about Microsoft identity platformΓÇÖs signing key rollover cadence, changes you can make to update the key automatically, and discussion for how to update the most common application scenarios.

-* [Supported Token and Claim Types](id-tokens.md) - Learn about the claims in the tokens that the Microsoft identity platform issues.

-* [OAuth 2.0 in Microsoft identity platform](v2-oauth2-auth-code-flow.md) - Learn about the implementation of OAuth 2.0 in Microsoft identity platform.

-* [OpenID Connect 1.0](v2-protocols-oidc.md) - Learn how to use OAuth 2.0, an authorization protocol, for authentication.

-* [Service to Service Calls with Client Credentials](v2-oauth2-client-creds-grant-flow.md) - Learn how to use OAuth 2.0 client credentials grant flow for service to service calls.

-* [Service to Service Calls with On-Behalf-Of Flow](v2-oauth2-on-behalf-of-flow.md) - Learn how to use OAuth 2.0 On-Behalf-Of flow for service to service calls.

-* [SAML Protocol Reference](./saml-protocol-reference.md) - Learn about the Single Sign-On and Single Sign-out SAML profiles of Microsoft identity platform.

-## See also

-* [Microsoft identity platform overview](v2-overview.md)

-* [Active Directory Code Samples](sample-v2-code.md)

-description: Learn more about how the Azure AD consent framework works to see how you can use it when developing applications on Azure AD

-# How application consent works

-This article is to help you learn more about how the Azure AD consent framework works so you can develop applications more effectively.

-## Recommended documents

-## Next steps

-[AzureAD Microsoft Q&A](/answers/topics/azure-active-directory.html)

-This article describes how to configure and setup a custom claims provider with the [token issuance start event](custom-claims-provider-overview.md#token-issuance-start-event-listener) type. This event is triggered right before the token is issued, and allows you to call a REST API to add claims to the token.

-Create an Application Registration to authenticate your custom authentication extension to your Azure Function.

-1. Sign in to the [Microsoft Graph Explorer](https://aka.ms/ge) using an account whose home tenant is the tenant you wish to manage your custom authentication extension in.

-1. Set the HTTP method to **POST**.

-1. Paste the URL: `https://graph.microsoft.com/v1.0/applications`

-1. Select **Request Body** and paste the following JSON:

- ```json

- "displayName": "authenticationeventsAPI"

-1. Select **Run Query** to submit the request.

-1. Copy the **Application ID** value (*appId*) from the response. You need this value later, which is referred to as the `{authenticationeventsAPI_AppId}`. Also get the object ID of the app (*ID*), which is referred to as `{authenticationeventsAPI_ObjectId}` from the response.

-Create a service principal in the tenant for the authenticationeventsAPI app registration:

-1. Set the HTTP method to **POST**.

-1. Paste the URL: `https://graph.microsoft.com/v1.0/servicePrincipals`

-1. Select **Request Body** and paste the following JSON:

- ```json

- {

- "appId": "{authenticationeventsAPI_AppId}"

- }

- ```

-1. Select **Run Query** to submit the request.

-1. Set the HTTP method to **PATCH**.

-1. Paste the URL: `https://graph.microsoft.com/v1.0/applications/{authenticationeventsAPI_ObjectId}`

-1. Select **Request Body** and paste the following JSON:

- Set the application ID URI value in the *identifierUris* property. Replace `{Function_Url_Hostname}` with the hostname of the `{Function_Url}` you recorded earlier.

-

- Set the `{authenticationeventsAPI_AppId}` value with the App ID generated from the app registration created in the previous step.

-

- An example value would be `api://authenticationeventsAPI.azurewebsites.net/f4a70782-3191-45b4-b7e5-dd415885dd80`. Take note of this value as it is used in following steps and is referenced as `{functionApp_IdentifierUri}`.

-

- ```json

- "identifierUris": [

- "api://{Function_Url_Hostname}/{authenticationeventsAPI_AppId}"

- ],

- "api": {

- "requestedAccessTokenVersion": 2,

- "acceptMappedClaims": null,

- "knownClientApplications": [],

- "oauth2PermissionScopes": [],

- "preAuthorizedApplications": []

- },

- "requiredResourceAccess": [

- "resourceAppId": "00000003-0000-0000-c000-000000000000",

- "resourceAccess": [

- {

- "id": "214e810f-fda8-4fd7-a475-29461495eb00",

- "type": "Role"

- }

- ]

- ```

-1. Select **Run Query** to submit the request.

-Next, you register the custom authentication extension. You register the custom authentication extension by associating it with the App Registration for the Azure Function, and your Azure Function endpoint `{Function_Url}`.

-1. Set the HTTP method to **POST**.

-1. Paste the URL: `https://graph.microsoft.com/beta/identity/customAuthenticationExtensions`

-1. Select **Request Body** and paste the following JSON:

- Replace `{Function_Url}` with the hostname of your Azure Function app. Replace `{functionApp_IdentifierUri}` with the identifierUri used in the previous step.

- ```json

-1. Select **Run Query** to submit the request.

-Record the ID value of the created custom claims provider object. The ID is needed in a later step and is referred to as the `{customExtensionObjectId}`.

-After your custom authentication extension is created, you'll be taken to the **Overview** tab of the new custom authentication extension.

-In your app registration, under **Overview**, copy the **Application (client) ID**. The app ID is referred to as the `{App_to_enrich_ID}` in later steps.

-First create an event listener to trigger a custom authentication extension using the token issuance start event:

-1. Sign in to the [Microsoft Graph Explorer](https://aka.ms/ge) using an account whose home tenant is the tenant you wish to manage your custom authentication extension in.

-1. Set the HTTP method to **POST**.

-1. Paste the URL: `https://graph.microsoft.com/beta/identity/authenticationEventListeners`

-1. Select **Request Body** and paste the following JSON:

- Replace `{App_to_enrich_ID}` with the app ID of *My Test application* recorded earlier. Replace `{customExtensionObjectId}` with the custom authentication extension ID recorded earlier.

- ```json

-1. Select **Run Query** to submit the request.

-Next, create the claims mapping policy, which describes which claims can be issued to an application from a custom claims provider:

-1. Set the HTTP method to **POST**.

-1. Paste the URL: `https://graph.microsoft.com/v1.0/policies/claimsmappingpolicies`

-1. Select **Request Body** and paste the following JSON:

- ```json

-1. Record the `ID` generated in the response, later it's referred to as `{claims_mapping_policy_ID}`.

-1. Select **Run Query** to submit the request.

-Get the `servicePrincipal` objectId:

-1. Set the HTTP method to **GET**.

-1. Paste the URL: `https://graph.microsoft.com/v1.0/servicePrincipals(appId='{App_to_enrich_ID}')/claimsMappingPolicies/$ref`. Replace `{App_to_enrich_ID}` with *My Test Application* App ID.

-1. Record the `id` value, later it's referred to as `{test_App_Service_Principal_ObjectId}`.

-Assign the claims mapping policy to the `servicePrincipal` of *My Test Application*:

-1. Set the HTTP method to **POST**.

-1. Paste the URL: `https://graph.microsoft.com/v1.0/servicePrincipals/{test_App_Service_Principal_ObjectId}/claimsMappingPolicies/$ref`

-1. Select **Request Body** and paste the following JSON:

- ```json

-1. Select **Run Query** to submit the request.

-description: Learn about delegated and application permissions, how they are used by clients and exposed by resources for applications you are developing with Azure AD

-# How to recognize differences between delegated and application permissions

-## Recommended documents

-## Next steps

-[AzureAD Microsoft Q&A](/answers/topics/azure-active-directory.html)

-In an elevated PowerShell prompt, run the following command and leave the PowerShell console session open. Replace `{certificateName}` with the name that you wish to give to your certificate.

-[auth-fund-01-img]: ./media/identity-videos/aad-auth-fund-01.jpg

-[auth-fund-02-img]: ./media/identity-videos/aad-auth-fund-02.jpg

-[auth-fund-03-img]: ./media/identity-videos/aad-auth-fund-03.jpg

-[auth-fund-04-img]: ./media/identity-videos/aad-auth-fund-04.jpg

-[auth-fund-05-img]: ./media/identity-videos/aad-auth-fund-05.jpg

-[auth-fund-06-img]: ./media/identity-videos/aad-auth-fund-06.jpg

-description: Describes how to mark an app as publisher verified. When an application is marked as publisher verified, it means that the publisher (application developer) has verified the authenticity of their organization using a Microsoft Partner Network (MPN) account that has completed the verification process and has associated this MPN account with that application registration.

-When an app registration has a verified publisher, it means that the publisher of the app has [verified](/partner-center/verification-responses) their identity using their Microsoft Partner Network (MPN) account and has associated this MPN account with their app registration. This article describes how to complete the [publisher verification](publisher-verification-overview.md) process.

-If you are already enrolled in the Microsoft Partner Network (MPN) and have met the [pre-requisites](publisher-verification-overview.md#requirements), you can get started right away:

-1. Click **Add MPN ID to verify publisher** and review the listed requirements.

-1. Enter your MPN ID and click **Verify and save**.

-1. Sign in using [multi-factor authentication](../fundamentals/concept-fundamentals-mfa-get-started.md) to an organizational (Azure AD) account authorized to make changes to the app you want to mark as Publisher Verified and on the MPN Account in Partner Center.

- - The user in Partner Center must have the following [roles](/partner-center/permissions-overview): MPN Admin, Accounts Admin, or a Global Administrator (a shared role mastered in Azure AD).

-1. Ensure that either the publisher domain or a DNS-verified [custom domain](../fundamentals/add-custom-domain.md) on the tenant matches the domain of the email address used during the verification process for your MPN account.

-1. Click **Add MPN ID to verify publisher** near the bottom of the page.

-1. Enter the **MPN ID** for:

- - A valid Microsoft Partner Network account that has completed the verification process.

-For more iOS details, see [Migrate iOS applications that use Microsoft Authenticator from ADAL.NET to MSAL.NET](msal-net-migration-ios-broker.md) and [Leveraging the broker on iOS](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/Leveraging-the-broker-on-iOS).

-## Next steps

-description: Learn about how permissions requests work for client and resource applications for applications you are developing

-# How to select permissions for a given API

-## Recommended documents

-## Next steps

-[AzureAD Microsoft Q&A](/answers/topics/azure-active-directory.html)

-When an app has a verified publisher, this means that the organization that publishes the app has been verified as authentic by Microsoft. Verifying an app includes using a Microsoft Cloud Partner Program (MCPP), formerly known as Microsoft Partner Network (MPN), account that's been [verified](/partner-center/verification-responses) and associating the verified PartnerID with an app registration.

- > The MPN account you use for publisher verification can't be your partner location MPN ID. Currently, location MPN IDs aren't supported for the publisher verification process.

- - In Partner Center, this user must have one of the following [roles](/partner-center/permissions-overview): MPN Partner Admin, Account Admin, or Global Administrator (a shared role that's mastered in Azure AD).

-description: How to find the authentication endpoints for a custom application you're developing or registering with Azure AD.

-# How to discover endpoints

-You can find the authentication endpoints for your application in the [Azure portal](https://portal.azure.com).

-1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.

-1. Select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations**, and then select **Endpoints** in the top menu.

- The **Endpoints** page is displayed, showing the authentication endpoints for your tenant.

-

- Use the endpoint that matches the authentication protocol you're using in conjunction with the **Application (client) ID** to craft the authentication request specific to your application.

-**National clouds** (for example Azure AD China, Germany, and US Government) have their own app registration portal and Azure AD authentication endpoints. Learn more in the [National clouds overview](authentication-national-cloud.md).

-## Next steps

-For more information about endpoints in the different Azure environments, see the [National clouds overview](authentication-national-cloud.md).

-description: Guidance for registering a custom developed application with Azure AD

-# Azure portal registration fields for custom-developed apps

-This article gives you a brief description of all the available fields in the application registration form in the [Azure portal](https://portal.azure.com).

-## Register a new application

-## Fields in the application registration form

-| Field | Description |

-|||

-| Name | The name of the application. It should have a minimum of four characters. |

-| Supported account types| Select which accounts you would like your application to support: accounts in this organizational directory only, accounts in any organizational directory, or accounts in any organizational directory and personal Microsoft accounts. |

-| Redirect URI (optional) | Select the type of app you're building, **Web** or **Public client (mobile & desktop)**, and then enter the redirect URI (or reply URL) for your application. For web applications, provide the base URL of your app. For example, http://localhost:31544 might be the URL for a web app running on your local machine. Users would use this URL to sign in to a web client application. For public client applications, provide the URI used by Azure AD to return token responses. Enter a value specific to your application, such as myapp://auth. To see specific examples for web applications or native applications, check out our [quickstarts](./index.yml).|

-Once you have filled the above fields, the application is registered in the Azure portal, and you are redirected to the application overview page. The settings pages in the left pane under **Manage** have more fields for you to customize your application. The tables below describe all the fields. You would only see a subset of these fields, depending on whether you created a web application or a public client application.

-### Overview

-| Field | Description |

-|--|--|

-| Application ID | When you register an application, Azure AD assigns your application an Application ID. The application ID can be used to uniquely identify your application in authentication requests to Azure AD, as well as to access resources like the Graph API. |

-| App ID URI | This should be a unique URI, usually of the form **https://&lt;tenant\_name&gt;/&lt;application\_name&gt;.** This is used during the authorization grant flow, as a unique identifier to specify the resource that the token should be issued for. It also becomes the 'aud' claim in the issued access token. |

-### Branding

-| Field | Description |

-|--|--|

-| Upload new logo | You can use this to upload a logo for your application. The logo must be in .bmp, .jpg or .png format, and the file size should be less than 100 KB. The dimensions for the image should be 215x215 pixels, with central image dimensions of 94x94 pixels.|

-| Home page URL | This is the sign-on URL specified during application registration.|

-### Authentication

-| Field | Description |

-|--|--|

-| Front-channel logout URL | This is the single sign-out logout URL. Azure AD sends a logout request to this URL when the user clears their session with Azure AD using any other registered application.|

-| Supported account types | This switch specifies whether the application can be used by multiple tenants. Typically, this means that external organizations can use your application by registering it in their tenant and granting access to their organization's data.|

-| Redirect URLs | The redirect, or reply, URLs are the endpoints where Azure AD returns any tokens that your application requests. For native applications, this is where the user is sent after successful authorization. Azure AD checks that the redirect URI your application supplies in the OAuth 2.0 request matches one of the registered values in the portal.|

-### Certificates and secrets

-| Field | Description |

-|--|--|

-| Client secrets | You can create client secrets, or keys, to programmatically access web APIs secured by Azure AD without any user interaction. From the **New client secret** page, enter a key description and the expiration date and save to generate the key. Make sure to save it somewhere secure, as you won't be able to access it later. |

-## Next steps

-[Managing Applications with Azure Active Directory](../manage-apps/what-is-application-management.md)

-description: How to configure single sign-on for a custom application you are developing and registering with Azure AD.

-# How to configure single sign-on for an application

-Enabling federated single sign-on (SSO) in your app is automatically enabled when federating through Azure AD for OpenID Connect, SAML 2.0, or WS-Fed. If your end users are having to sign in despite already having an existing session with Azure AD, itΓÇÖs likely your app may be misconfigured.

-* If youΓÇÖre using Microsoft Authentication Library (MSAL), make sure you have **PromptBehavior** set to **Auto** rather than **Always**.

-* If youΓÇÖre building a mobile app, you may need additional configurations to enable brokered or non-brokered SSO.

-For Android, see [Enabling Cross App SSO in Android](msal-android-single-sign-on.md).

-For iOS, see [Enabling Cross App SSO in iOS](single-sign-on-macos-ios.md).

-## Next steps

-[Azure AD SSO](../manage-apps/what-is-single-sign-on.md)<br>

-[Enabling Cross App SSO in Android](msal-android-single-sign-on.md)<br>

-[Enabling Cross App SSO in iOS](single-sign-on-macos-ios.md)<br>

-[Integrating Apps to AzureAD](./quickstart-register-app.md)<br>

-[Permissions and consent in the Microsoft identity platform](./permissions-consent-overview.md)<br>

-[AzureAD Microsoft Q&A](/answers/topics/azure-active-directory.html)

-*Microsoft.Identity.Web* adds extension methods to the Controller that provide convenience services to call Microsoft Graph or a downstream web API, or to get an authorization header, or even a token. The methods used to call an API directly are explained in detail in [A web app that calls web APIs: Call an API](scenario-web-app-call-api-call-api.md). With these helper methods, you don't need to manually acquire a token.

-If, however, you do want to manually acquire a token or build an authorization header, the following code shows how to use *Microsoft.Identity.Web* to do so in a controller. It calls an API (Microsoft Graph) using the REST API instead of the Microsoft Graph SDK.

-The controller methods are protected by an `[Authorize]` attribute that ensures only authenticated users can use the web app.

-In the Java sample, the code that calls an API is in the getUsersFromGraph method in [AuthPageController.java#L62](https://github.com/Azure-Samples/ms-identity-java-webapp/blob/d55ee4ac0ce2c43378f2c99fd6e6856d41bdf144/src/main/java/com/microsoft/azure/msalwebsample/AuthPageController.java#L62).

-In the Node.js sample, the code that acquires a token is in the *acquireToken* method of the **AuthProvider** class.

-In the Python sample, the code that calls the API is in `app.py`.

-description: Learn how to configure an application as multi-tenant, and how multi-tenant applications work

-# How to configure a new multi-tenant application

-Here is a list of recommended topics to learn more about multi-tenant applications:

-## Next steps

-[AzureAD Microsoft Q&A](/answers/topics/azure-active-directory.html)

-| ID | Required | Azure AD uses this attribute to populate the `InResponseTo` attribute of the returned response. ID must not begin with a number, so a common strategy is to prepend a string like "ID" to the string representation of a GUID. For example, `id6c1c178c166d486687be4aaf5e482730` is a valid ID. |

-| Version | Required | This parameter should be set to **2.0**. |

-| IssueInstant | Required | This is a DateTime string with a UTC value and [round-trip format ("o")](/dotnet/standard/base-types/standard-date-and-time-format-strings). Azure AD expects a DateTime value of this type, but doesn't evaluate or use the value. |

-| AssertionConsumerServiceURL | Optional | If provided, this parameter must match the `RedirectUri` of the cloud service in Azure AD. |

-| ForceAuthn | Optional | This is a boolean value. If true, it means that the user will be forced to re-authenticate, even if they have a valid session with Azure AD. |

-| IsPassive | Optional | This is a boolean value that specifies whether Azure AD should authenticate the user silently, without user interaction, using the session cookie if one exists. If this is true, Azure AD will attempt to authenticate the user using the session cookie. |

-All other `AuthnRequest` attributes, such as Consent, Destination, AssertionConsumerServiceIndex, AttributeConsumerServiceIndex, and ProviderName are **ignored**.

- 1. Navigate to the [MPN enrollment page](https://partner.microsoft.com/dashboard/account/v3/enrollment/joinnow/basicpartnernetwork/new).

- 3. If an MPN account already exists, this is recognized and you are added to the account.

- 4. Navigate to the [partner profile page](https://partner.microsoft.com/pcv/accountsettings/connectedpartnerprofile) where the MPN ID and primary account contact will be listed.

- Go to the [MPN User Management page](https://partner.microsoft.com/pcv/users) and filter the user list to see what users are in various admin roles.

-> *verifiedPublisherID* is your MPN ID.

-The MPN ID you provided (`MPNID`) doesn't exist, or you don't have access to it. Provide a valid MPN ID and try again.

-Most commonly caused by the signed-in user not being a member of the proper role for the MPN account in Partner Center- see [requirements](publisher-verification-overview.md#requirements) for a list of eligible roles and see [common issues](#common-issues) for more information. Can also be caused by the tenant the app is registered in not being added to the MPN account, or an invalid MPN ID.

- - The MPN ID is correct.

-2. Go to the [MPN tenant management page](https://partner.microsoft.com/dashboard/account/v3/tenantmanagement) and confirm that the tenant the app is registered in and that you're signing with a user account from is on the list of associated tenants. To add another tenant, follow the [multi-tenant-account instructions](/partner-center/multi-tenant-account). All Global Admins of any tenant you add will be granted Global Administrator privileges on your Partner Center account.

-3. Go to the [MPN User Management page](https://partner.microsoft.com/pcv/users) and confirm the user you're signing in as is either a Global Administrator, MPN Admin, or Accounts Admin. To add a user to a role in Partner Center, follow the instructions for [creating user accounts and setting permissions](/partner-center/create-user-accounts-and-set-permissions).

-The MPN ID you provided (`MPNID`) isn't valid. Provide a valid MPN ID and try again.

-Most commonly caused when an MPN ID is provided which corresponds to a Partner Location Account (PLA). Only Partner Global Accounts are supported. See [Partner Center account structure](/partner-center/account-structure) for more details.

-The MPN ID you provided (`MPNID`) isn't valid. Provide a valid MPN ID and try again.

-Most commonly caused by the wrong MPN ID being provided.

-The MPN ID (`MPNID`) you provided hasn't completed the vetting process. Complete this process in Partner Center and try again.

-Most commonly caused by when the MPN account hasn't completed the [verification](/partner-center/verification-responses) process.

-The MPN ID you provided (`MPNID`) isn't valid. Provide a valid MPN ID and try again.

-Most commonly caused by the wrong MPN ID being provided.

-The MPN ID you provided (`MPNID`) isn't valid. Provide a valid MPN ID and try again.

-Most commonly caused by the wrong MPN ID being provided.

-Most commonly caused by the signed-in user not being a member of the proper role for the MPN account in Azure AD- see [requirements](publisher-verification-overview.md#requirements) for a list of eligible roles and see [common issues](#common-issues) for more information.

-The MPN ID wasn't provided in the request body or the request content type wasn't "application/json".

-Most commonly caused when the verification is being performed via Graph API, and the MPN ID wasnΓÇÖt provided in the request.

-The Microsoft identity platform supports authentication for various modern app architectures, all of them based on industry-standard protocols [OAuth 2.0 or OpenID Connect](./v2-protocols.md). This article describes the types of apps that you can build by using Microsoft identity platform, regardless of your preferred language or platform. The information is designed to help you understand high-level scenarios before you start working with the code in the [application scenarios](authentication-flows-app-scenarios.md#application-scenarios).

-# Microsoft identity platform and implicit grant flow

-> To successfully request an ID token and/or an access token, the app registration in the [Azure portal - App registrations](https://go.microsoft.com/fwlink/?linkid=2083908) page must have the corresponding implicit grant flow enabled, by selecting **ID tokens** and **access tokens** in the **Implicit grant and hybrid flows** section. If it's not enabled, an `unsupported_response` error will be returned: `The provided value for the input parameter 'response_type' is not allowed for this client. Expected value is 'code'`

-| `response_type` | required |Must include `id_token` for OpenID Connect sign-in. It may also include the response_type `token`. Using `token` here will allow your app to receive an access token immediately from the authorize endpoint without having to make a second request to the authorize endpoint. If you use the `token` response_type, the `scope` parameter must contain a scope indicating which resource to issue the token for (for example, user.read on Microsoft Graph). It can also contain `code` in place of `token` to provide an authorization code, for use in the [authorization code flow](v2-oauth2-auth-code-flow.md). This id_token+code response is sometimes called the hybrid flow. |

-| `redirect_uri` | recommended |The redirect_uri of your app, where authentication responses can be sent and received by your app. It must exactly match one of the redirect_uris you registered in the portal, except it must be URL-encoded. |

-| `scope` | required |A space-separated list of [scopes](./permissions-consent-overview.md). For OpenID Connect (id_tokens), it must include the scope `openid`, which translates to the "Sign you in" permission in the consent UI. Optionally you may also want to include the `email` and `profile` scopes for gaining access to additional user data. You may also include other scopes in this request for requesting consent to various resources, if an access token is requested. |

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

-| `prompt` | optional |Indicates the type of user interaction that is required. The only valid values at this time are 'login', 'none', 'select_account', and 'consent'. `prompt=login` will force the user to enter their credentials on that request, negating single-sign on. `prompt=none` is the opposite - it will ensure that the user isn't presented with any interactive prompt whatsoever. If the request can't be completed silently via single-sign on, the Microsoft identity platform will return an error. `prompt=select_account` sends the user to an account picker where all of the accounts remembered in the session will appear. `prompt=consent` will trigger the OAuth consent dialog after the user signs in, asking the user to grant permissions to the app. |

-| `token_type` |Included if `response_type` includes `token`. Will always be `Bearer`. |

-| `id_token` | A signed JSON Web Token (JWT). The app can decode the segments of this token to request information about the user who signed in. The app can cache the values and display them, but it shouldn't rely on them for any authorization or security boundaries. For more information about id_tokens, see the [`id_token reference`](id-tokens.md). <br> **Note:** Only provided if `openid` scope was requested and `response_type` included `id_tokens`. |

->`https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=6731de76-14a6-49ae-97bc-6eba6914391e&response_type=token&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F&scope=https%3A%2F%2Fgraph.microsoft.com%2Fuser.read&response_mode=fragment&state=12345&nonce=678910&prompt=none&login_hint={your-username}`

-| `token_type` | Will always be `Bearer`. |

-| `scope` | Indicates the scope(s) for which the access_token will be valid. May not include all of the scopes requested, if they weren't applicable to the user (in the case of Azure AD-only scopes being requested when a personal account is used to log in). |

-The implicit grant does not provide refresh tokens. Both `id_token`s and `access_token`s will expire after a short period of time, so your app must be prepared to refresh these tokens periodically. To refresh either type of token, you can perform the same hidden iframe request from above using the `prompt=none` parameter to control the identity platform's behavior. If you want to receive a new `id_token`, be sure to use `id_token` in the `response_type` and `scope=openid`, as well as a `nonce` parameter.

-By adding Azure AD roles to the local administrators group, you can update the users that can manage a device anytime in Azure AD without modifying anything on the device. Azure AD also adds the Azure AD joined device local administrator role to the local administrators group to support the principle of least privilege (PoLP). In addition to the global administrators, you can also enable users that have been *only* assigned the device administrator role to manage a device.

-## Manage the global administrators role

-To view and update the membership of the Global Administrator role, see:

-## Manage the device administrator role

-In the Azure portal, you can manage the device administrator role from **Device settings**.

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

-To modify the device administrator role, configure **Additional local administrators on all Azure AD joined devices**.

-Device administrators are assigned to all Azure AD joined devices. You canΓÇÖt scope device administrators to a specific set of devices. Updating the device administrator role doesn't necessarily have an immediate impact on the affected users. On devices where a user is already signed into, the privilege elevation takes place when *both* the below actions happen:

-Users won't be listed in the local administrator group, the permissions are received through the Primary Refresh Token.

-Starting with Windows 10 version 20H2, you can use Azure AD groups to manage administrator privileges on Azure AD joined devices with the [Local Users and Groups](/windows/client-management/mdm/policy-csp-localusersandgroups) MDM policy. This policy allows you to assign individual users or Azure AD groups to the local administrators group on an Azure AD joined device, providing you the granularity to configure distinct administrators for different groups of devices.

- 1. Windows registers the device in the organizationΓÇÖs directory in Azure AD and enrolls it in mobile device management, if applicable.

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

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

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

-1. Go to the devices page using a [direct link](https://portal.azure.com/#blade/Microsoft_AAD_IAM/DevicesMenuBlade/Devices).

-2. Information on how to locate a device can be found in [How to manage device identities using the Azure portal](./manage-device-identities.md).

-3. If the **Registered** column says **Pending**, then hybrid Azure AD join hasn't completed. In federated environments, this state happens only if it failed to register and Azure AD Connect is configured to sync the devices. Wait for Azure AD Connect to complete a sync cycle.

-4. If the **Registered** column contains a **date/time**, then hybrid Azure AD join has completed.

-1. Sign in to the **Azure portal** as a [Cloud Device Administrator](../roles/permissions-reference.md#cloud-device-administrator).

- 

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

- 

- > Replace `<TenantID>` with the Azure AD tenant ID that's associated with the Azure subscription. If you need to find the tenant ID, you can hover over your account name or select **Azure Active Directory** > **Properties** > **Directory ID** in the Azure portal.

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

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

-[](./media/manage-device-identities/devices-azure-portal.png#lightbox)

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

-[](./media/manage-device-identities/all-devices-azure-portal.png#lightbox)

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

-You must be assigned one of the following roles to view device settings in the Azure portal:

-You must be assigned one of the following roles to manage device settings in the Azure portal:

-#Customer intent: As an IT admin, I want to understand how I can get rid of stale devices, so that I can I can cleanup my device registration data.

- :::image type="content" source="./media/manage-stale-devices/01.png" alt-text="Screenshot of a page in the Azure portal listing the name, owner, and other information on devices. One column lists the activity time stamp." border="false":::

-To get an overview of how to manage device in the Azure portal, see [managing devices using the Azure portal](manage-device-identities.md)

-1. Sign in to the **Azure portal**.

-| **AADSTS50155: Device authentication failed** | <li>Azure AD is unable to authenticate the device to issue a PRT.<li>Confirm that the device hasn't been deleted or disabled in the Azure portal. For more information about this issue, see [Azure Active Directory device management FAQ](faq.yml#why-do-my-users-see-an-error-message-saying--your-organization-has-deleted-the-device--or--your-organization-has-disabled-the-device--on-their-windows-10-11-devices). | Follow the instructions for this issue in [Azure Active Directory device management FAQ](faq.yml#i-disabled-or-deleted-my-device-in-the-azure-portal-or-by-using-windows-powershell--but-the-local-state-on-the-device-says-it-s-still-registered--what-should-i-do) to re-register the device based on the device join type. |

-Re-register the device based on the device join type. For instructions, see [I disabled or deleted my device in the Azure portal or by using Windows PowerShell. But the local state on the device says it's still registered. What should I do?](./faq.yml#i-disabled-or-deleted-my-device-in-the-azure-portal-or-by-using-windows-powershell--but-the-local-state-on-the-device-says-it-s-still-registered--what-should-i-do).

-# Customer intent: As a tenant administrator, I want to send B2B invitations to multiple external users at the same time so that I can avoid having to send individual invitations to each user.

- - Turkish (Turkey)

-description: Learn how to configure a Vanilla JavaScript single-page app (SPA) to sign in and sign out users with your Azure Active Directory (AD) for customers tenant.

-#Customer intent: As a developer, I want to learn how to configure Vanilla JavaScript single-page app (SPA) to sign in and sign out users with my Azure Active Directory (AD) for customers tenant.

-# Tutorial: Add sign-in and sign-out to a vanilla JavaScript single-page app for a customer tenant

-In the [previous article](how-to-single-page-app-vanillajs-configure-authentication.md), you edited the popup and redirection files that handle the sign-in page response. This tutorial demonstrates how to build a responsive user interface (UI) that contains a **Sign-In** and **Sign-Out** button and run the project to test the sign-in and sign-out functionality.

-In this tutorial;

-> [!div class="checklist"]

-> * Add code to the *https://docsupdatetracker.net/index.html* file to create the user interface

-> * Add code to the *signout.html* file to create the sign-out page

-> * Sign in and sign out of the application

-## Prerequisites

-* Completion of the prerequisites and steps in [Create components for authentication and authorization](how-to-single-page-app-vanillajs-configure-authentication.md).

-## Add code to the *https://docsupdatetracker.net/index.html* file

-The main page of the SPA, *https://docsupdatetracker.net/index.html*, is the first page that is loaded when the application is started. It's also the page that is loaded when the user selects the **Sign-Out** button.

-1. Open *public/https://docsupdatetracker.net/index.html* and add the following code snippet:

- ```html

- <!DOCTYPE html>

- <html lang="en">

-

- <head>

- <meta charset="UTF-8">

- <meta name="viewport" content="width=device-width, initial-scale=1.0, shrink-to-fit=no">

- <title>Microsoft identity platform</title>

- <link rel="SHORTCUT ICON" href="./favicon.svg" type="image/x-icon">

- <link rel="stylesheet" href="./styles.css">

-

- <!-- adding Bootstrap 5 for UI components -->

- <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.2.2/dist/css/bootstrap.min.css" rel="stylesheet"

- integrity="sha384-Zenh87qX5JnK2Jl0vWa8Ck2rdkQ2Bzep5IDxbcnCeuOxjzrPF/et3URy9Bv1WTRi" crossorigin="anonymous">

-

- <!-- msal.min.js can be used in the place of msal-browser.js -->

- <script src="/msal-browser.min.js"></script>

- </head>

-

- <body>

- <nav class="navbar navbar-expand-sm navbar-dark bg-primary navbarStyle">

- <a class="navbar-brand" href="/">Microsoft identity platform</a>

- <div class="navbar-collapse justify-content-end">

- <button type="button" id="signIn" class="btn btn-secondary" onclick="signIn()">Sign-in</button>

- <button type="button" id="signOut" class="btn btn-success d-none" onclick="signOut()">Sign-out</button>

- </div>

- </nav>

- <br>

- <h5 id="title-div" class="card-header text-center">Vanilla JavaScript single-page application secured with MSAL.js

- </h5>

- <h5 id="welcome-div" class="card-header text-center d-none"></h5>

- <br>

- <div class="table-responsive-ms" id="table">

- <table id="table-div" class="table table-striped d-none">

- <thead id="table-head-div">

- <tr>

- <th>Claim Type</th>

- <th>Value</th>

- <th>Description</th>

- </tr>

- </thead>

- <tbody id="table-body-div">

- </tbody>

- </table>

- </div>

- <!-- importing bootstrap.js and supporting js libraries -->

- <script src="https://code.jquery.com/jquery-3.3.1.slim.min.js"

- integrity="sha384-q8i/X+965DzO0rT7abK41JStQIAqVgRVzpbzo5smXKp4YfRvH+8abtTE1Pi6jizo" crossorigin="anonymous">

- </script>

- <script src="https://cdn.jsdelivr.net/npm/@popperjs/core@2.11.6/dist/umd/popper.min.js"

- integrity="sha384-oBqDVmMz9ATKxIep9tiCxS/Z9fNfEXiDAYTujMAeBAsjFuCZSmKbSSUnQlmh/jp3"

- crossorigin="anonymous"></script>

- <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.2.2/dist/js/bootstrap.bundle.min.js"

- integrity="sha384-OERcA2EqjJCMA+/3y+gxIOqMEjwtxJY7qPCqsdltbNJuaOe923+mo//f6V8Qbsw3"

- crossorigin="anonymous"></script>

-

- <!-- importing app scripts (load order is important) -->

- <script type="text/javascript" src="./authConfig.js"></script>

- <script type="text/javascript" src="./ui.js"></script>

- <script type="text/javascript" src="./claimUtils.js"></script>

- <!-- <script type="text/javascript" src="./authRedirect.js"></script> -->

- <!-- uncomment the above line and comment the line below if you would like to use the redirect flow -->

- <script type="text/javascript" src="./authPopup.js"></script>

- </body>

-

- </html>

- ```

-1. Save the file.

-## Add code to the *signout.html* file

-1. Open *public/signout.html* and add the following code snippet:

- ```html

- <!DOCTYPE html>

- <html lang="en">

- <head>

- <meta charset="UTF-8">

- <meta name="viewport" content="width=device-width, initial-scale=1.0">

- <title>Azure AD | Vanilla JavaScript SPA</title>

- <link rel="SHORTCUT ICON" href="./favicon.svg" type="image/x-icon">

-

- <!-- adding Bootstrap 4 for UI components -->

- <link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.4.1/css/bootstrap.min.css" integrity="sha384-Vkoo8x4CGsO3+Hhxv8T/Q5PaXtkKtu6ug5TOeNV6gBiFeWPGFN9MuhOf23Q9Ifjh" crossorigin="anonymous">

- </head>

- <body>

- <div class="jumbotron" style="margin: 10%">

- <h1>Goodbye!</h1>

- <p>You have signed out and your cache has been cleared.</p>

- <a class="btn btn-primary" href="/" role="button">Take me back</a>

- </div>

- </body>

- </html>

- ```

-1. Save the file.

-## Add code to the *ui.js* file

-When authorization has been configured, the user interface can be created to allow users to sign in and sign out when the project is run. To build the user interface (UI) for the application, [Bootstrap](https://getbootstrap.com/) is used to create a responsive UI that contains a **Sign-In** and **Sign-Out** button.

-1. Open *public/ui.js* and add the following code snippet:

- ```javascript

- // Select DOM elements to work with

- const signInButton = document.getElementById('signIn');

- const signOutButton = document.getElementById('signOut');

- const titleDiv = document.getElementById('title-div');

- const welcomeDiv = document.getElementById('welcome-div');

- const tableDiv = document.getElementById('table-div');

- const tableBody = document.getElementById('table-body-div');

-

- function welcomeUser(username) {

- signInButton.classList.add('d-none');

- signOutButton.classList.remove('d-none');

- titleDiv.classList.add('d-none');

- welcomeDiv.classList.remove('d-none');

- welcomeDiv.innerHTML = `Welcome ${username}!`;

- };

-

- function updateTable(account) {

- tableDiv.classList.remove('d-none');

-

- const tokenClaims = createClaimsTable(account.idTokenClaims);

-

- Object.keys(tokenClaims).forEach((key) => {

- let row = tableBody.insertRow(0);

- let cell1 = row.insertCell(0);

- let cell2 = row.insertCell(1);

- let cell3 = row.insertCell(2);

- cell1.innerHTML = tokenClaims[key][0];

- cell2.innerHTML = tokenClaims[key][1];

- cell3.innerHTML = tokenClaims[key][2];

- });

- };

- ```

-1. Save the file.

-## Add code to the *styles.css* file

-1. Open *public/styles.css* and add the following code snippet:

- ```css

- .navbarStyle {

- padding: .5rem 1rem !important;

- }

-

- .table-responsive-ms {

- max-height: 39rem !important;

- padding-left: 10%;

- padding-right: 10%;

- }

- ```

-1. Save the file.

-## Run your project and sign in

-Now that all the required code snippets have been added, the application can be called and tested in a web browser.

-1. Open a new terminal and run the following command to start your express web server.

- ```powershell

- npm start

- ```

-1. Open a new private browser, and enter the application URI into the browser, `http://localhost:3000/`.

-1. Select **No account? Create one**, which starts the sign-up flow.

-1. In the **Create account** window, enter the email address registered to your Azure Active Directory (AD) for customers tenant, which starts the sign-up flow as a user for your application.

-1. After entering a one-time passcode from the customer tenant, enter a new password and more account details, this sign-up flow is completed.

- 1. If a window appears prompting you to **Stay signed in**, choose either **Yes** or **No**.

-1. The SPA will now display a button saying **Request Profile Information**. Select it to display profile data.

- :::image type="content" source="media/how-to-spa-vanillajs-sign-in-sign-in-out/display-vanillajs-welcome.png" alt-text="Screenshot of sign in into a vanilla JS SPA." lightbox="media/how-to-spa-vanillajs-sign-in-sign-in-out/display-vanillajs-welcome.png":::

-## Sign out of the application

-1. To sign out of the application, select **Sign out** in the navigation bar.

-1. A window appears asking which account to sign out of.

-1. Upon successful sign out, a final window appears advising you to close all browser windows.

-## Next steps

-description: Learn how to configure a sample JavaSCript single-page application (SPA) to sign in and sign out users.

-1. Select **No account? Create one**, which starts the sign-up flow.

-1. In the **Create account** window, enter the email address registered to your customer tenant, which starts the sign-up flow as a user for your application.

-1. After entering a one-time passcode from the customer tenant, enter a new password and more account details, this sign-up flow is completed.

-1. If a window appears prompting you to **Stay signed in**, choose either **Yes** or **No**.

-> | JavaScript, Vanilla | &#8226; [Sign in users](./sample-single-page-app-vanillajs-sign-in.md) | &#8226; [Sign in users](how-to-single-page-app-vanillajs-prepare-tenant.md) |

-> | Single-page application | &#8226; [Sign in users](./sample-single-page-app-vanillajs-sign-in.md) | &#8226; [Sign in users](how-to-single-page-app-vanillajs-prepare-tenant.md) |

-# Customer intent: As a tenant administrator, I want to customize the invitation process with the API.

-# Customer intent: As a tenant administrator, I want to set up Facebook as an identity provider for guest user login.

-# Customer intent: As a tenant administrator, I want to learn about B2B collaboration guest user properties and states before and after invitation redemption.

-* **Reason for customer data egress** - Some forms of communication rely on a network that is operated by global providers, such as phone calls and SMS. Device vendor-specific services such Apple Push Notifications, may be outside of Europe.

-To unify the [Microsoft Entra](/entra) product family, reflect the progression to modern multicloud identity security, and simplify secure access experiences for all, we're renaming Azure Active Directory (Azure AD) to Microsoft Entra ID.

-## No action is required from you

-## Only the name is changing

-## Identity developer and devops experiences aren't impacted by the rename

-To make the transition seamless, all existing login URLs, APIs, PowerShell cmdlets, and Microsoft Authentication Libraries (MSAL) stay the same, as do developer experiences and tooling.

-Microsoft identity platform encompasses all our identity and access developer assets. It will continue to provide the resources to help you build applications that your users and customers can sign in to using their Microsoft identities or social accounts.

-Naming is also not changing for:

-The name change will start appearing across Microsoft experiences after a 30-day notification period, which started July 11, 2023. Display names for SKUs and service plans will change on October 1, 2023. We expect most naming text string changes in Microsoft experiences to be completed by the end of 2023.

-All features and capabilities remain unchanged aside from the name. Customers can continue to use all features without any interruption.

-### How and when are customers being notified?

-The name changes are publicly announced as of July 11, 2023.

-Banners, alerts, and message center posts will notify users of the name change. These will be displayed on the tenant overview page, portals including Azure, Microsoft 365, and Microsoft Entra admin center, and Microsoft Learn.

-### What if I use the Azure AD name in my content or app?

-We'd like your help spreading the word about the name change and implementing it in your own experiences. If you're a content creator, author of internal documentation for IT or identity security admins, developer of Azure ADΓÇôenabled apps, independent software vendor, or Microsoft partner, we hope you use the naming guidance outlined in the following section ([Azure AD name changes and exceptions](#azure-ad-name-changes-and-exceptions)) to make the name change in your content and product experiences by the end of 2023.

-## Azure AD name changes and exceptions

-We encourage content creators, organizations with internal documentation for IT or identity security admins, developers of Azure AD-enabled apps, independent software vendors, or partners of Microsoft to stay current with the new naming guidance by updating copy by the end of 2023. We recommend changing the name in customer-facing experiences, prioritizing highly visible surfaces.

-### Product name

-Replace the product name "Azure Active Directory" or "Azure AD" or "AAD" with Microsoft Entra ID.

-*Microsoft Entra* is the correct name for the family of identity and network access solutions, one of which is *Microsoft Entra ID.*

-### Logo/icon

-Azure AD is becoming Microsoft Entra ID, and the product icon is also being updated. Work with your Microsoft partner organization to obtain the new product icon.

-### Feature names

-Capabilities or services formerly known as "Azure Active Directory &lt;feature name&gt;" or "Azure AD &lt;feature name&gt;" will be branded as Microsoft Entra product family features. For example:

-### Exceptions to Azure AD name change

-Products or features that are being deprecated aren't being renamed. These products or features include:

-Names that don't have "Azure AD" also aren't changing. These products or features include Active Directory Federation Services (AD FS), Microsoft identity platform, and Windows Server Active Directory Domain Services (AD DS).

-End users shouldn't be exposed to the Azure AD or Microsoft Entra ID name. For sign-ins and account user experiences, follow guidance for work and school accounts in [Sign in with Microsoft branding guidelines](../develop/howto-add-branding-in-apps.md).

-| [CF](https://www.cloudfoundry.org/) | Cloud Foundry. Cloud Foundry is the environment on which SAP built their multi-cloud offering for BTP (AWS, Azure, GCP, Alibaba). |

-This feature analyzes uploaded client-side logs, also known as diagnostic logs, from a Windows 10+ device that is having an issue(s) and suggests remediation steps to resolve the issue(s). Admins can work with end user to collect client-side logs, and then upload them to this troubleshooter in the Entra Portal. For more information, see: [Troubleshooting Windows devices in Azure AD](../devices/troubleshoot-device-windows-joined.md).

-We have consolidated relevant app launcher settings in a new App launchers section in the Azure and Entra portals. The entry point can be found under Enterprise applications, where Collections used to be. You can find the Collections option by selecting App launchers. In addition, we've added a new App launchers Settings option. This option has some settings you may already be familiar with like the Microsoft 365 settings. The new Settings options also have controls for previews. As an admin, you can choose to try out new app launcher features while they are in preview. Enabling a preview feature means that the feature turns on for your organization. This enabled feature reflects in the My Apps portal, and other app launchers for all of your users. To learn more about the preview settings, see: [End-user experiences for applications](../manage-apps/end-user-experiences.md).

-With this feature, IT administrators can now allow or restrict external identities to leave an organization by Microsoft provided self-service controls via Azure Active Directory in the Microsoft Entra portal. In order to restrict users to leave an organization, customers need to include "Global privacy contact" and "Privacy statement URL" under tenant properties.

-We have consolidated relevant app launcher settings in a new App launchers section in the Azure and Entra portals. The entry point can be found under Enterprise applications, where Collections used to be. You can find the Collections option by selecting App launchers. In addition, we've added a new App launchers Settings option. This option has some settings you may already be familiar with like the Microsoft 365 settings. The new Settings options also have controls for previews. As an admin, you can choose to try out new app launcher features while they are in preview. Enabling a preview feature means that the feature turns on for your organization. This enabled feature reflects in the My Apps portal, and other app launchers for all of your users. To learn more about the preview settings, see: [End-user experiences for applications](../manage-apps/end-user-experiences.md).

-Each access package must have one or more access package assignment policies, before a user can be assigned access. When an access package is created in the Entra portal, the Entra portal automatically creates the first access package assignment policy for that access package. The policy determines who can request access, and who if anyone must approve access.

-1. Navigate To Entra portal [Identity Governance - Microsoft Entra admin center](https://entra.microsoft.com/#view/Microsoft_AAD_ERM/DashboardBlade/~/elmEntitlement)

-1. Depending on the lifecycle of external users settings, when the external user no longer has any access package assignments, the external user is blocked from signing in and the guest user account is removed from your directory.

-You can select what happens when an external user, who was invited to your directory through making an access package request, no longer has any access package assignments. This can happen if the user relinquishes all their access package assignments, or their last access package assignment expires. By default, when an external user no longer has any access package assignments, they're blocked from signing in to your directory. After 30 days, their guest user account is removed from your directory.

- > If a user is blocked from signing in to this directory, then the user will be unable to re-request the access package or request additional access in this directory. Do not configure blocking them from signing in if they will subsequently need to request access to other access packages.

- > Entitlement management only removes accounts that were invited through entitlement management. Also, note that a user will be blocked from signing in and removed from this directory even if that user was added to resources in this directory that were not access package assignments. If the guest was present in this directory prior to receiving access package assignments, they will remain. However, if the guest was invited through an access package assignment, and after being invited was also assigned to a OneDrive for Business or SharePoint Online site, they will still be removed.

-1. If you want to remove the guest user account in this directory, you can set the number of days before it's removed. If you want to remove the guest user account as soon as they lose their last assignment to any access packages, set **Number of days before removing external user from this directory** to **0**.

-1. Navigate To Entra portal [Identity Governance - Microsoft Entra admin center](https://entra.microsoft.com/#view/Microsoft_AAD_ERM/DashboardBlade/~/elmEntitlement)

-1. Navigate to the Entra portal [Identity Governance - Microsoft Entra admin center](https://entra.microsoft.com/#view/Microsoft_AAD_ERM/DashboardBlade/~/elmEntitlement)

-Once scheduling is enabled, the workflow is evaluated every three hours to determine whether or not it should run based on the execution conditions.

-## Enable password writeback in Azure AD Connect cloud sync

- - Global Administrator

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

-Identity Protection provides organizations with two reports they can use to investigate workload identity risk. These reports are the risky workload identities, and risk detections for workload identities. All reports allow for downloading of events in .CSV format for further analysis outside of the Azure portal.

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

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.

-To **Dismiss user risk**, search for and select **Azure AD Risky users** in the Azure portal or the Entra portal, select the affected user, and select **Dismiss user(s) risk**.

-2. Enter the credentials of the account you want to generate an atypical travel risk detection for.

-3. Change your user agent. You can change user agent in Microsoft Edge from Developer Tools (F12).

-4. Change your IP address. You can change your IP address by using a VPN, a Tor add-on, or creating a new virtual machine in Azure in a different data center.

-5. Sign-in to [https://myapps.microsoft.com](https://myapps.microsoft.com) using the same credentials as before and within a few minutes after the previous sign-in.

-**To simulate Leaked Credentials in GitHub for Workload Identities, perform the following steps**:

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

-2. Browse to **Azure Active Directory** > **App registrations**.

-3. Select **New registration** to register a new application or reuse an existing stale application.

-4. Select **Certificates & Secrets** > **New client Secret** , add a description of your client secret and set an expiration for the secret or specify a custom lifetime and select **Add**. Record the secret's value for later use for your GitHub Commit.

-5. Get the TenantID and Application(Client)ID in the **Overview** page.

-6. Ensure you disable the application via **Azure Active Directory** > **Enterprise Application** > **Properties** > Set **Enabled for users to sign-in** to **No**.

-7. Create a **public** GitHub Repository, add the following config and commit the change as a file with the .txt extension.

-7. In about 8 hours, you'll be able to view a leaked credential detection under **Azure Active Directory** > **Security** > **Risk Detection** > **Workload identity detections** where the additional info will contain the URL of your GitHub commit.

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

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

-The AD FS application activity report in the [Entra portal](https://entra.microsoft.com) lets you quickly identify which of your applications are capable of being migrated to Azure AD. It assesses all AD FS applications for compatibility with Azure AD, checks for any issues, and gives guidance on preparing individual applications for migration. With the AD FS application activity report, you can:

-The AD FS application activity report is available in the [Entra portal](https://entra.microsoft.com) under Azure AD **Usage & insights** reporting. The AD FS application activity report analyzes each AD FS application to determine if it can be migrated as-is, or if additional review is needed.

-1. Sign in to the [Entra portal](https://entra.microsoft.com) with an admin role that has access to AD FS application activity data (global administrator, reports reader, security reader, application administrator, or cloud application administrator).

-Line-of-business apps that use OAuth 2.0, OpenID Connect, or WS-Federation can be integrated with Azure AD as [app registrations](../develop/quickstart-register-app.md). Integrate custom apps that use SAML 2.0 or WS-Federation as [non-gallery applications](add-application-portal.md) on the enterprise applications page in the [Entra portal](https://entra.microsoft.com/#home).

-1. In the [Entra portal](https://entra.microsoft.com/#home), [create a user group](../fundamentals/how-to-manage-groups.md) that corresponds to the group of users from AD FS.

-* In the [Entra portal](https://entra.microsoft.com/#home), add a user to the app through the Add Assignment tab of the app as shown below:

-1. In the [Entra portal](https://entra.microsoft.com/#home), select **Enterprise Applications** and then **Single sign-on** to view the SAML-based sign-on configuration:

-Here's an example of how to configure the Exclude option for trusted locations in the Entra portal:

- - [Add Azure Active Directory B2B collaboration users in the Entra portal](../external-identities/add-users-administrator.md). You can proactively send B2B collaboration invitations from the Azure AD administrative portal to the partner organization for individual members to continue using the apps and assets they're used to.

-* Apps with multiple Reply URL endpoints. You configure them in Azure AD using PowerShell or the Entra portal interface.

-* Azure ADΓÇöThe setting is configured within [Entra portal](https://entra.microsoft.com/#home) in each application's SSO properties.

-> The configuration values for Azure AD follows the pattern where your Azure Tenant ID replaces {tenant-id} and the Application ID replaces {application-id}. You find this information in the [Entra portal](https://entra.microsoft.com/#home) under **Azure Active Directory > Properties**:

-| **Token signing certificate**<p>The IdP uses the private key of the certificate to sign issued tokens. It verifies that the token came from the same IdP that the app is configured to trust.| Find the AD FS token signing certificate in AD FS Management under **Certificates**.| Find it in the Entra portal in the application's **Single sign-on properties** under the header **SAML Signing Certificate**. There, you can download the certificate for upload to the app. <p>ΓÇÄIf the application has more than one certificate, you can find all certificates in the federation metadata XML file. |

-> - For information about delays activating the Azure AD Joined Device Local Administrator role, see [How to manage the local administrators group on Azure AD joined devices](../devices/assign-local-admin.md#manage-the-device-administrator-role).

-description: Learn how to choose the right method for accessing the activity logs in Azure AD.

-# How To: Access activity logs in Azure AD

-The data in your Azure Active Directory (Azure AD) logs enables you to assess many aspects of your Azure AD tenant. To cover a broad range of scenarios, Azure AD provides you with various options to access your activity log data. As an IT administrator, you need to understand the intended uses cases for these options, so that you can select the right access method for your scenario.

-The required roles and licenses may vary based on the report. Global Administrator can access all reports, but we recommend using a role with least privilege access to align with the [Zero Trust guidance](/security/zero-trust/zero-trust-overview).

-*The level of access and capabilities for Identity Protection varies with the role and license. For more information, see the [license requirements for Identity Protection](../identity-protection/overview-identity-protection.md#license-requirements).

-The Microsoft Graph API provides a unified programmability model that you can use to access data for your Azure AD Premium tenants. It doesn't require an administrator or developer to set up extra infrastructure to support your script or app. The Microsoft Graph API is **not** designed for pulling large amounts of activity data. Pulling large amounts of activity data using the API may lead to issues with pagination and performance.

-### Archive activity logs to a storage account

-The Azure Active Directory (Azure AD) [reporting APIs](/graph/api/resources/azure-ad-auditlog-overview) provide you with programmatic access to the data through a set of REST APIs. You can call these APIs from many programming languages and tools. The reporting API uses [OAuth](../../api-management/api-management-howto-protect-backend-with-aad.md) to authorize access to the web APIs.

-In order to access the sign-in reports for a tenant, an Azure AD tenant must have associated Azure AD Premium P1 or P2 license. Alternatively if the directory type is Azure AD B2C, the sign-in reports are accessible through the API without any additional license requirement.

-# How to: Download logs in Azure Active Directory

-description: Learn how to integrate Azure Active Directory logs with ArcSight using Azure Monitor

-# Integrate Azure Active Directory logs with ArcSight using Azure Monitor

-[Micro Focus ArcSight](https://software.microfocus.com/products/siem-security-information-event-management/overview) is a security information and event management (SIEM) solution that helps you detect and respond to security threats in your platform. You can now route Azure Active Directory (Azure AD) logs to ArcSight using Azure Monitor using the ArcSight connector for Azure AD. This feature allows you to monitor your tenant for security compromise using ArcSight.

-In this article, you learn how to route Azure AD logs to ArcSight using Azure Monitor.

-## Prerequisites

-To use this feature, you need:

-* An Azure event hub that contains Azure AD activity logs. Learn how to [stream your activity logs to an event hub](./tutorial-azure-monitor-stream-logs-to-event-hub.md).

-* A configured instance of ArcSight Syslog NG Daemon SmartConnector (SmartConnector) or ArcSight Load Balancer. If the events are sent to ArcSight Load Balancer, they're sent to the SmartConnector by the Load Balancer.

-Download and open the [configuration guide for ArcSight SmartConnector for Azure Monitor Event Hubs](https://community.microfocus.com/t5/ArcSight-Connectors/SmartConnector-for-Microsoft-Azure-Monitor-Event-Hub/ta-p/1671292). This guide contains the steps you need to install and configure the ArcSight SmartConnector for Azure Monitor.

-## Integrate Azure AD logs with ArcSight

-1. First, complete the steps in the **Prerequisites** section of the configuration guide. This section includes the following steps:

- * Set user permissions in Azure, to ensure there's a user with the **owner** role to deploy and configure the connector.

- * Open ports on the server with Syslog NG Daemon SmartConnector, so it's accessible from Azure.

- * The deployment runs a Windows PowerShell script, so you must enable PowerShell to run scripts on the machine where you want to deploy the connector.

-2. Follow the steps in the **Deploying the Connector** section of configuration guide to deploy the connector. This section walks you through how to download and extract the connector, configure application properties and run the deployment script from the extracted folder.

-3. Use the steps in the **Verifying the Deployment in Azure** to make sure the connector is set up and functions correctly. Verify the following prerequisites:

- * The requisite Azure functions are created in your Azure subscription.

- * The Azure AD logs are streamed to the correct destination.

- * The application settings from your deployment are persisted in the Application Settings in Azure Function Apps.

- * A new resource group for ArcSight is created in Azure, with an Azure AD application for the ArcSight connector and storage accounts containing the mapped files in CEF format.

-4. Finally, complete the post-deployment steps in the **Post-Deployment Configurations** of the configuration guide. This section explains how to perform another configuration if you are on an App Service Plan to prevent the function apps from going idle after a timeout period, configure streaming of resource logs from the event hub, and update the SysLog NG Daemon SmartConnector keystore certificate to associate it with the newly created storage account.

-5. The configuration guide also explains how to customize the connector properties in Azure, and how to upgrade and uninstall the connector. There's also a section on performance improvements, including upgrading to an [Azure Consumption plan](https://azure.microsoft.com/pricing/details/functions) and configuring an ArcSight Load Balancer if the event load is greater than what a single Syslog NG Daemon SmartConnector can handle.

-## Next steps

-[Configuration guide for ArcSight SmartConnector for Azure Monitor Event Hubs](https://community.microfocus.com/t5/ArcSight-Connectors/SmartConnector-for-Microsoft-Azure-Monitor-Event-Hub/ta-p/1671292)

-description: Learn how to integrate Azure Active Directory logs with Azure Monitor

-# How to integrate Azure AD logs with Azure Monitor logs

-Using **Diagnostic settings** in Azure Active Directory (Azure AD), you can integrate logs with Azure Monitor so sign-in activity and the audit trail of changes within your tenant can be analyzed along with other Azure data. Integrating Azure AD logs with Azure Monitor logs enables rich visualizations, monitoring, and alerting on the connected data.

-This article provides the steps to integrate Azure Active Directory (Azure AD) logs with Azure Monitor Logs.

-## Roles and licenses

-To integrate Azure AD logs with Azure Monitor, you need the following roles and licenses:

-* **An Azure subscription:** If you don't have an Azure subscription, you can [sign up for a free trial](https://azure.microsoft.com/free/).

-* **An Azure AD Premium P1 or P2 tenant:** You can find the license type of your tenant on the [Overview](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview) page in Azure AD.

-* **Security Administrator access for the Azure AD tenant:** This role is required to set up the Diagnostics settings.

-* **Permission to access data in a Log Analytics workspace:** See [Manage access to log data and workspaces in Azure Monitor](../../azure-monitor/logs/manage-access.md) for information on the different permission options and how to configure permissions.

-## Integrate logs with Azure Monitor logs

-To send Azure AD logs to Azure Monitor Logs you must first have a [Log Analytics workspace](../../azure-monitor/logs/log-analytics-overview.md). Then you can set up the Diagnostics settings in Azure AD to send your activity logs to that workspace.

-### Create a Log Analytics workspace

-A Log Analytics workspace allows you to collect data based on a variety or requirements, such as geographic location of the data, subscription boundaries, or access to resources. Learn how to [create a Log Analytics workspace](../../azure-monitor/logs/quick-create-workspace.md).

-Looking for how to set up a Log Analytics workspace for Azure resources outside of Azure AD? Check out the [Collect and view resource logs for Azure Monitor](../../azure-monitor/essentials/diagnostic-settings.md) article.

-### Set up Diagnostics settings

-Once you have a Log Analytics workspace created, follow the steps below to send logs from Azure Active Directory to that workspace.

-Follow the steps below to send logs from Azure Active Directory to Azure Monitor. Looking for how to set up Log Analytics workspace for Azure resources outside of Azure AD? Check out the [Collect and view resource logs for Azure Monitor](../../azure-monitor/essentials/diagnostic-settings.md) article.

-1. Sign in to the [Azure portal](https://portal.azure.com) as a **Security Administrator**.

-1. Go to **Azure Active Directory** > **Diagnostic settings**. You can also select **Export Settings** from the Audit logs or Sign-in logs.

-1. Select **+ Add diagnostic setting** to create a new integration or select **Edit setting** to change an existing integration.

-1. Enter a **Diagnostic setting name**. If you're editing an existing integration, you can't change the name.

-1. Any or all of the following logs can be sent to the Log Analytics workspace. Some logs may be in public preview but still visible in the portal.

- * `AuditLogs`

- * `SignInLogs`

- * `NonInteractiveUserSignInLogs`

- * `ServicePrincipalSignInLogs`

- * `ManagedIdentitySignInLogs`

- * `ProvisioningLogs`

- * `ADFSSignInLogs` Active Directory Federation Services (ADFS)

- * `RiskyServicePrincipals`

- * `RiskyUsers`

- * `ServicePrincipalRiskEvents`

- * `UserRiskEvents`

-1. The following logs are in preview but still visible in Azure AD. At this time, selecting these options will not add new logs to your workspace unless your organization was included in the preview.

- * `EnrichedOffice365AuditLogs`

- * `MicrosoftGraphActivityLogs`

- * `NetworkAccessTrafficLogs`

-1. In the **Destination details**, select **Send to Log Analytics workspace** and choose the appropriate details from the menus that appear.

- * You can also send logs to any or all of the following destinations. Additional fields appear, depending on your selection.

- * **Archive to a storage account:** Provide the number of days you'd like to retain the data in the **Retention days** boxes that appear next to the log categories. Select the appropriate details from the menus that appear.

- * **Stream to an event hub:** Select the appropriate details from the menus that appear.

- * **Send to partner solution:** Select the appropriate details from the menus that appear.

-1. Select **Save** to save the setting.

- 

-If you do not see logs appearing in the selected destination after 15 minutes, sign out and back into Azure to refresh the logs.

-> [!NOTE]

-> Integrating Azure Active Directory logs with Azure Monitor will automatically enable the Azure Active Directory data connector within Microsoft Sentinel.

-## Next steps

-* [Analyze Azure AD activity logs with Azure Monitor logs](howto-analyze-activity-logs-log-analytics.md)

-* [Learn about the data sources you can analyze with Azure Monitor](../../azure-monitor/data-sources.md)

-* [Automate creating diagnostic settings with Azure Policy](../../azure-monitor/essentials/diagnostic-settings-policy.md)

-description: Learn how to integrate Azure Active Directory logs with Splunk using Azure Monitor.

-# How to: Integrate Azure Active Directory logs with Splunk using Azure Monitor

-In this article, you learn how to integrate Azure Active Directory (Azure AD) logs with Splunk by using Azure Monitor. You first route the logs to an Azure event hub, and then you integrate the event hub with Splunk.

-## Prerequisites

-To use this feature, you need:

-## Integrate Azure Active Directory logs

-1. Open your Splunk instance, and select **Data Summary**.

- 

-2. Select the **Sourcetypes** tab, and then select **mscs:azure:eventhub**

- 

-Append **body.records.category=AuditLogs** to the search. The Azure AD activity logs are shown in the following figure:

- 

-> [!NOTE]

-> If you cannot install an add-on in your Splunk instance (for example, if you're using a proxy or running on Splunk Cloud), you can forward these events to the Splunk HTTP Event Collector. To do so, use this [Azure function](https://github.com/splunk/azure-functions-splunk), which is triggered by new messages in the event hub.

->

-## Next steps

-* [Interpret audit logs schema in Azure Monitor](./overview-reports.md)

-* [Interpret sign-in logs schema in Azure Monitor](reference-azure-monitor-sign-ins-log-schema.md)

-description: Learn how to integrate Azure Active Directory logs with SumoLogic using Azure Monitor.

-# Integrate Azure Active Directory logs with SumoLogic using Azure Monitor

-In this article, you learn how to integrate Azure Active Directory (Azure AD) logs with SumoLogic using Azure Monitor. You first route the logs to an Azure event hub, and then you integrate the event hub with SumoLogic.

-## Prerequisites

-To use this feature, you need:

-* An Azure event hub that contains Azure AD activity logs. Learn how to [stream your activity logs to an event hub](./tutorial-azure-monitor-stream-logs-to-event-hub.md).

-* A SumoLogic single sign-on enabled subscription.

-## Steps to integrate Azure AD logs with SumoLogic

-1. First, [stream the Azure AD logs to an Azure event hub](./tutorial-azure-monitor-stream-logs-to-event-hub.md).

-2. Configure your SumoLogic instance to [collect logs for Azure Active Directory](https://help.sumologic.com/docs/integrations/microsoft-azure/active-directory-azure#collecting-logs-for-azure-active-directory).

-3. [Install the Azure AD SumoLogic app](https://help.sumologic.com/docs/integrations/microsoft-azure/active-directory-azure#viewing-azure-active-directory-dashboards) to use the pre-configured dashboards that provide real-time analysis of your environment.

- 

-## Next steps

-* [Interpret audit logs schema in Azure Monitor](./overview-reports.md)

-* [Interpret sign-in logs schema in Azure Monitor](reference-azure-monitor-sign-ins-log-schema.md)

-# How to: Use Azure AD recommendations

-description: Provides a general overview of Azure Active Directory monitoring.

-# Customer intent: As an Azure AD administrator, I want to understand what monitoring solutions are available for Azure AD activity data and how they can help me manage my tenant.

-# What is Azure Active Directory monitoring?

-With Azure Active Directory (Azure AD) monitoring, you can now route your Azure AD activity logs to different endpoints. You can then either retain it for long-term use or integrate it with third-party Security Information and Event Management (SIEM) tools to gain insights into your environment.

-Currently, you can route the logs to:

-**Prerequisite role**: Global Administrator

-> [!VIDEO https://www.youtube.com/embed/syT-9KNfug8]

-## Licensing and prerequisites for Azure AD reporting and monitoring

-You'll need an Azure AD premium license to access the Azure AD sign-in logs.

-For detailed feature and licensing information in the [Azure Active Directory pricing guide](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing).

-To deploy Azure AD monitoring and reporting you'll need a user who is a global administrator or security administrator for the Azure AD tenant.

-Depending on the final destination of your log data, you'll need one of the following:

-* An Azure storage account that you have ListKeys permissions for. We recommend that you use a general storage account and not a Blob storage account. For storage pricing information, see the [Azure Storage pricing calculator](https://azure.microsoft.com/pricing/calculator/?service=storage).

-* An Azure Event Hubs namespace to integrate with third-party SIEM solutions.

-* An Azure Log Analytics workspace to send logs to Azure Monitor logs.

-## Diagnostic settings configuration

-To configure monitoring settings for Azure AD activity logs, first sign in to the [Azure portal](https://portal.azure.com), then select **Azure Active Directory**. From here, you can access the diagnostic settings configuration page in two ways:

-* Select **Diagnostic settings** from the **Monitoring** section.

- 

-

-* Select **Audit Logs** or **Sign-ins**, then select **Export settings**.

- 

-## Route logs to storage account

-By routing logs to an Azure storage account, you can retain it for longer than the default retention period outlined in our [retention policies](reference-reports-data-retention.md). Learn how to [route data to your storage account](quickstart-azure-monitor-route-logs-to-storage-account.md).

-## Stream logs to event hub

-Routing logs to an Azure event hub allows you to integrate with third-party SIEM tools like Sumologic and Splunk. This integration allows you to combine Azure AD activity log data with other data managed by your SIEM, to provide richer insights into your environment. Learn how to [stream logs to an event hub](tutorial-azure-monitor-stream-logs-to-event-hub.md).

-## Send logs to Azure Monitor logs

-[Azure Monitor logs](../../azure-monitor/logs/log-query-overview.md) is a solution that consolidates monitoring data from different sources and provides a query language and analytics engine that gives you insights into the operation of your applications and resources. By sending Azure AD activity logs to Azure Monitor logs, you can quickly retrieve, monitor and alert on collected data. Learn how to [send data to Azure Monitor logs](howto-integrate-activity-logs-with-log-analytics.md).

-You can also install the pre-built views for Azure AD activity logs to monitor common scenarios involving sign-ins and audit events. Learn how to [install and use log analytics views for Azure AD activity logs](../../azure-monitor/visualize/workbooks-view-designer-conversion-overview.md).

-## Next steps

-* [Activity logs in Azure Monitor](concept-activity-logs-azure-monitor.md)

-* [Stream logs to event hub](tutorial-azure-monitor-stream-logs-to-event-hub.md)

-* [Send logs to Azure Monitor logs](howto-integrate-activity-logs-with-log-analytics.md)

-description: Provides a general overview of Azure Active Directory reports.

-# Customer intent: As an Azure AD administrator, I want to understand what Azure AD reports are available and how I can use them to gain insights into my environment.

-# What are Azure Active Directory reports?

-Azure Active Directory (Azure AD) reports provide a comprehensive view of activity in your environment. The provided data enables you to:

-## Activity reports

-Activity reports help you understand the behavior of users in your organization. There are two types of activity reports in Azure AD:

-> [!VIDEO https://www.youtube.com/embed/ACVpH6C_NL8]

-### Audit logs report

-The [audit logs report](concept-audit-logs.md) provides you with records of system activities for compliance. This data enables you to address common scenarios such as:

-#### What Azure AD license do you need to access the audit logs report?

-The audit logs report is available for features for which you have licenses. If you have a license for a specific feature, you also have access to the audit log information for it. A detailed feature comparison as per [different types of licenses](../fundamentals/whatis.md#what-are-the-azure-ad-licenses) can be seen on the [Azure Active Directory pricing page](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing). For more information, see [Azure Active Directory features and capabilities](../fundamentals/whatis.md#which-features-work-in-azure-ad).

-### Sign-ins report

-The [sign-ins report](concept-sign-ins.md) enables you to find answers to questions such as:

-#### What Azure AD license do you need to access the sign-ins activity report?

-To access the sign-ins activity report, your tenant must have an Azure AD Premium license associated with it.

-## Programmatic access

-In addition to the user interface, Azure AD also provides you with [programmatic access](./howto-configure-prerequisites-for-reporting-api.md) to the reports data, through a set of REST-based APIs. You can call these APIs from various programming languages and tools.

-## Next steps

-description: Learn how Service Health notifications provide you with a customizable dashboard that tracks the health of your Azure services in the regions where you use them.

-# What are Service Health notifications in Azure Active Directory?

-Azure Service Health has been updated to provide notifications to tenant admins within the Azure portal when there are Service Health events for Azure Active Directory services. Due to the criticality of these events, an alert card in the Azure AD overview page will also be provided to support the discovery of these notifications.

-## How it works

-When there happens to be a Service Health notification for an Azure Active Directory service, it will be posted to the Service Health page within the Azure portal. Previously these were subscription events that were posted to all the subscription owners/readers of subscriptions within the tenant that had an issue. To improve the targeting of these notifications, they'll now be available as tenant events to the tenant admins of the impacted tenant. For a transition period, these service events will be available as both tenant events and subscription events.

-Now that they're available as tenant events, they appear on the Azure AD overview page as alert cards. Any Service Health notification that has been updated within the last three days will be shown in one of the cards.

-

-

-Each card:

-

-

-

-For more information on the new Azure Service Health tenant events, see [Azure Service Health portal updates](../../service-health/service-health-portal-update.md)

-## Who will see the notifications

-Most of the built-in admin roles will have access to see these notifications. For the complete list of all authorized roles, see [Azure Service Health Tenant Admin authorized roles](../../service-health/admin-access-reference.md). Currently custom roles aren't supported.

-## What you should know

-Service Health events allow the addition of alerts and notifications to be applied to subscription events. This feature isn't yet supported with tenant events, but will be coming soon.

-

-## Next steps

-description: Learn how to route Azure Active Directory logs to a storage account

-# Customer intent: As an IT administrator, I want to learn how to route Azure AD logs to an Azure storage account so I can retain it for longer than the default retention period.

-# Tutorial: Archive Azure AD logs to an Azure storage account

-In this tutorial, you learn how to set up Azure Monitor diagnostics settings to route Azure Active Directory (Azure AD) logs to an Azure storage account.

-## Prerequisites

-To use this feature, you need:

-* An Azure subscription with an Azure storage account. If you don't have an Azure subscription, you can [sign up for a free trial](https://azure.microsoft.com/free/).

-* An Azure AD tenant.

-* A user who's a *Global Administrator* or *Security Administrator* for the Azure AD tenant.

-* To export sign-in data, you must have an Azure AD P1 or P2 license.

-## Archive logs to an Azure storage account

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

-1. Select **Azure Active Directory** > **Monitoring** > **Audit logs**.

-1. Select **Export Data Settings**.

-1. You can either create a new setting (up to three settings are allowed) or edit an existing setting.

- - To change existing setting, select **Edit setting** next to the diagnostic setting you want to update.

- - To add new settings, select **Add diagnostic setting**.

- 

-1. Once in the **Diagnostic setting** pane if you're creating a new setting, enter a name for the setting to remind you of its purpose (for example, *Send to Azure storage account*). You can't change the name of an existing setting.

-1. Under **Destination Details** select the **Archive to a storage account** check box. Text fields for the retention period appear next to each log category.

-1. Select the Azure subscription and storage account for you want to route the logs.

-1. Select all the relevant categories in under **Category details**:

- 

-1. In the **Retention days** field, enter the number of days of retention you need of your log data. By default, this value is *0*, which means that logs are retained in the storage account indefinitely. If you set a different value, events older than the number of days selected are automatically cleaned up.

-

-1. Select **Save**.

-1. After the categories have been selected, in the **Retention days** field, type in the number of days of retention you need of your log data. By default, this value is *0*, which means that logs are retained in the storage account indefinitely. If you set a different value, events older than the number of days selected are automatically cleaned up.

- > [!NOTE]

- > The Diagnostic settings storage retention feature is being deprecated. For details on this change, see [**Migrate from diagnostic settings storage retention to Azure Storage lifecycle management**](../../azure-monitor/essentials/migrate-to-azure-storage-lifecycle-policy.md).

-1. Select **Save** to save the setting.

-1. Close the window to return to the Diagnostic settings pane.

-## Next steps

-* [Tutorial: Configure a log analytics workspace](tutorial-log-analytics-wizard.md)

-* [Interpret audit logs schema in Azure Monitor](./overview-reports.md)

-* [Interpret sign-in logs schema in Azure Monitor](reference-azure-monitor-sign-ins-log-schema.md)

-The first step to migrating your apps from ADAL to MSAL is to identify all applications in your tenant that are currently using ADAL. You can identify your apps in the Azure portal or programmatically with the Microsoft Graph API or the Microsoft Graph PowerShell SDK.

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

-There are four steps to identifying and updating your apps in the Azure portal. The following steps are covered in detail in the [List all apps using ADAL](../develop/howto-get-list-of-all-auth-library-apps.md) article.

-1. Send Azure AD sign-in event to Azure Monitor.

-1. [Access the sign-ins workbook in Azure AD.](../develop/howto-get-list-of-all-auth-library-apps.md)

-1. Identify the apps that use ADAL.

-1. Update your code.

- - The steps to update your code vary depending on the type of application.

- - For example, the steps for .NET and Python applications have separate instructions.

- - For a full list of instructions for each scenario, see [How to migrate to MSAL](../develop/msal-migration.md#how-to-migrate-to-msal).

-Run the following query in Microsoft Graph, replacing the `<TENANT_ID>` placeholder with your tenant ID. This query returns a list of the impacted resources in your tenant.

-The [Azure AD sign-ins workbook](../develop/howto-get-list-of-all-auth-library-apps.md) is an alternative method to identify these apps. The workbook is still available to you, but using the workbook requires streaming sign-in logs to Azure Monitor first. The ADAL to MSAL recommendation works out of the box. Plus, the sign-ins workbook does not capture Service Principal sign-ins, while the recommendation does.

-1. Perform the following step, if you wish to configure the application in **SP** initiated mode:

- In the **Sign on URL** textbox, type the URL using one of the following patterns:

-Alternatively, you can also use the [Enterprise App Configuration Wizard](https://portal.office.com/AdminPortal/home?Q=Docs#/azureadappintegration). In this wizard, you can add an application to your tenant, add users/groups to the app, assign roles, as well as walk through the SSO configuration as well. You can learn more about O365 wizards [here](/microsoft-365/admin/misc/azure-ad-setup-guides?view=o365-worldwide&preserve-view=true).

-1. Click on the **User Profile** and click **Your workspace**.

-1. Click **Auth** and perform the following steps:

- 

-You can also use Microsoft My Apps to test the application in any mode. When you click the Hive tile in the My Apps, if configured in SP mode you would be redirected to the application sign on page for initiating the login flow and if configured in IDP mode, you should be automatically signed in to the Hive for which you set up the SSO. For more information about the My Apps, see [Introduction to the My Apps](https://support.microsoft.com/account-billing/sign-in-and-start-apps-from-the-my-apps-portal-2f3b1bae-0e5a-4a86-a33e-876fbd2a4510).

- `https://sso.hornbill.com/<INSTANCE_NAME>/<SUBDOMAIN>`

- b. In the **Sign on URL** text box, type a URL using the following pattern:

- `https://<SUBDOMAIN>.hornbill.com/<INSTANCE_NAME>/`

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

-5. On the **Set up Single Sign-On with SAML** page, In the **SAML Signing Certificate** section, click copy button to copy **App Federation Metadata Url** and save it on your computer.

-description: Learn how to configure Microsoft Entra ID to automatically provision and de-provision user accounts to SAP Cloud Identity Services.

-The objective of this tutorial is to demonstrate the steps to be performed in SAP Cloud Identity Services and Microsoft Entra ID (Azure AD) to configure Microsoft Entra ID to automatically provision and de-provision users to SAP Cloud Identity Services.

-* It is recommended that a single Microsoft Entra ID user is assigned to SAP Cloud Identity Services to test the automatic user provisioning configuration. Additional users may be assigned later.

-1. You will receive an email to activate your account and set a password for **SAP Cloud Identity Services Service**.

-1. Copy the **User ID** and **Password**. These values will be entered in the Admin Username and Admin Password fields respectively in the Provisioning tab of your SAP Cloud Identity Services application in the Azure portal.

- 

-1. When you are ready to provision, click **Save**.

-## Additional resources

-Contact Tailscale support to configure Tailscale to support provisioning with Azure AD.

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

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

-Contact Vbrick Rev Cloud support to configure Vbrick Rev Cloud to support provisioning with Azure AD.

-Microsoft Entra Verified ID implements the [W3C StatusList2021](https://github.com/w3c-ccg/vc-status-list-2021/tree/343b8b59cddba4525e1ef355356ae760fc75904e). When presentation to the Request Service API happens, the API will do the revocation check for you. The revocation check happens over an anonymous API call to Identity Hub and does not contain any data who is checking if the verifiable credential is still valid or revoked. With the **statusList2021**, Microsoft Entra Verified ID just keeps a flag by the hashed value of the indexed claim to keep track of the revocation status.

-1. Go to [Microsoft Entra portal -> Verified ID](https://entra.microsoft.com/#view/Microsoft_AAD_DecentralizedIdentity/ResourceOverviewBlade).

-1. Go to [Microsoft Entra portal -> Verified ID](https://entra.microsoft.com/#view/Microsoft_AAD_DecentralizedIdentity/ResourceOverviewBlade).

-1. Go to Microsoft Entra portal - [**Verified ID**](https://entra.microsoft.com/#view/Microsoft_AAD_DecentralizedIdentity/ResourceOverviewBlade)

- 

-Azure AI services provides a layered security model. This model enables you to secure your Azure AI services accounts to a specific subset of networksΓÇï. When network rules are configured, only applications requesting data over the specified set of networks can access the account. You can limit access to your resources with request filtering. Allowing only requests originating from specified IP addresses, IP ranges or from a list of subnets in [Azure Virtual Networks](../virtual-network/virtual-networks-overview.md).

-> Turning on firewall rules for your Azure AI services account blocks incoming requests for data by default. In order to allow requests through, one of the following conditions needs to be met:

-> * The request should originate from a service operating within an Azure Virtual Network (VNet) on the allowed subnet list of the target Azure AI services account. The endpoint in requests originated from VNet needs to be set as the [custom subdomain](cognitive-services-custom-subdomains.md) of your Azure AI services account.

-> * Or the request should originate from an allowed list of IP addresses.

-> Requests that are blocked include those from other Azure services, from the Azure portal, from logging and metrics services, and so on.

-To secure your Azure AI services resource, you should first configure a rule to deny access to traffic from all networks (including internet traffic) by default. Then, you should configure rules that grant access to traffic from specific VNets. This configuration enables you to build a secure network boundary for your applications. You can also configure rules to grant access to traffic from select public internet IP address ranges, enabling connections from specific internet or on-premises clients.

-Network rules are enforced on all network protocols to Azure AI services, including REST and WebSocket. To access data using tools such as the Azure test consoles, explicit network rules must be configured. You can apply network rules to existing Azure AI services resources, or when you create new Azure AI services resources. Once network rules are applied, they're enforced for all requests.

-Virtual networks (VNETs) are supported in [regions where Azure AI services are available](https://azure.microsoft.com/global-infrastructure/services/). Azure AI services supports service tags for network rules configuration. The services listed below are included in the **CognitiveServicesManagement** service tag.

-> * Anomaly Detector

-> * Azure OpenAI

-> * Azure AI Vision

-> * Content Moderator

-> * Custom Vision

-> * Face

-> * Language Understanding (LUIS)

-> * Personalizer

-> * Speech service

-> * Language service

-> * QnA Maker

-> * Translator Text

-> If you're using, Azure OpenAI, LUIS, Speech Services, or Language services, the **CognitiveServicesManagement** tag only enables you use the service using the SDK or REST API. To access and use Azure OpenAI Studio, LUIS portal , Speech Studio or Language Studio from a virtual network, you will need to use the following tags:

-> * **AzureActiveDirectory**

-> * **AzureFrontDoor.Frontend**

-> * **AzureResourceManager**

-> * **CognitiveServicesManagement**

-> * **CognitiveServicesFrontEnd**

-> Making changes to network rules can impact your applications' ability to connect to Azure AI services. Setting the default network rule to **deny** blocks all access to the data unless specific network rules that **grant** access are also applied. Be sure to grant access to any allowed networks using network rules before you change the default rule to deny access. If you are allow listing IP addresses for your on-premises network, be sure to add all possible outgoing public IP addresses from your on-premises network.

-### Managing default network access rules

-1. Select the **RESOURCE MANAGEMENT** menu called **Virtual network**.

- 

-1. To deny access by default, choose to allow access from **Selected networks**. With the **Selected networks** setting alone, unaccompanied by configured **Virtual networks** or **Address ranges** - all access is effectively denied. When all access is denied, requests attempting to consume the Azure AI services resource aren't permitted. The Azure portal, Azure PowerShell or, Azure CLI can still be used to configure the Azure AI services resource.

-1. To allow traffic from all networks, choose to allow access from **All networks**.

- 

-1. Install the [Azure PowerShell](/powershell/azure/install-azure-powershell) and [sign in](/powershell/azure/authenticate-azureps), or select **Try it**.

- ```azurepowershell-interactive

- $parameters = @{

- "ResourceGroupName"= "myresourcegroup"

- "Name"= "myaccount"

-}

- (Get-AzCognitiveServicesAccountNetworkRuleSet @parameters).DefaultAction

- ```

-1. Set the default rule to deny network access by default.

- -ResourceGroupName "myresourcegroup"

- -Name "myaccount"

- -DefaultAction Deny

-1. Set the default rule to allow network access by default.

- -ResourceGroupName "myresourcegroup"

- -Name "myaccount"

- -DefaultAction Allow

-1. Install the [Azure CLI](/cli/azure/install-azure-cli) and [sign in](/cli/azure/authenticate-azure-cli), or select **Try it**.

- -g "myresourcegroup" -n "myaccount" \

- --query networkRuleSet.defaultAction

- --ids {resourceId} \

- --ids {resourceId} \

-You can configure Azure AI services resources to allow access only from specific subnets. The allowed subnets may belong to a VNet in the same subscription, or in a different subscription, including subscriptions belonging to a different Azure Active Directory tenant.

-Enable a [service endpoint](../virtual-network/virtual-network-service-endpoints-overview.md) for Azure AI services within the VNet. The service endpoint routes traffic from the VNet through an optimal path to the Azure AI services service. The identities of the subnet and the virtual network are also transmitted with each request. Administrators can then configure network rules for the Azure AI services resource that allow requests to be received from specific subnets in a VNet. Clients granted access via these network rules must continue to meet the authorization requirements of the Azure AI services resource to access the data.

-Each Azure AI services resource supports up to 100 virtual network rules, which may be combined with [IP network rules](#grant-access-from-an-internet-ip-range).

-### Required permissions

-To apply a virtual network rule to an Azure AI services resource, the user must have the appropriate permissions for the subnets being added. The required permission is the default *Contributor* role, or the *Cognitive Services Contributor* role. Required permissions can also be added to custom role definitions.

-Azure AI services resource and the virtual networks granted access may be in different subscriptions, including subscriptions that are a part of a different Azure AD tenant.

-> Configuration of rules that grant access to subnets in virtual networks that are a part of a different Azure Active Directory tenant are currently only supported through PowerShell, CLI and REST APIs. Such rules cannot be configured through the Azure portal, though they may be viewed in the portal.

-### Managing virtual network rules

-1. Select the **RESOURCE MANAGEMENT** menu called **Virtual network**.

-1. Check that you've selected to allow access from **Selected networks**.

-1. To grant access to a virtual network with an existing network rule, under **Virtual networks**, select **Add existing virtual network**.

- 

- 

-1. To create a new virtual network and grant it access, select **Add new virtual network**.

- 

- 

- > [!NOTE]

- > If a service endpoint for Azure AI services wasn't previously configured for the selected virtual network and subnets, you can configure it as part of this operation.

- >

- > Presently, only virtual networks belonging to the same Azure Active Directory tenant are shown for selection during rule creation. To grant access to a subnet in a virtual network belonging to another tenant, please use PowerShell, CLI or REST APIs.

-1. To remove a virtual network or subnet rule, select **...** to open the context menu for the virtual network or subnet, and select **Remove**.

- 

-1. Install the [Azure PowerShell](/powershell/azure/install-azure-powershell) and [sign in](/powershell/azure/authenticate-azureps), or select **Try it**.

-1. List virtual network rules.

- $parameters = @{

- "ResourceGroupName"= "myresourcegroup"

- "Name"= "myaccount"

-}

-1. Enable service endpoint for Azure AI services on an existing virtual network and subnet.

- -AddressPrefix "10.0.0.0/24" `

- -ResourceGroupName "myresourcegroup"

- -Name "myvnet"

- > To add a network rule for a subnet in a VNet belonging to another Azure AD tenant, use a fully-qualified **VirtualNetworkResourceId** parameter in the form "/subscriptions/subscription-ID/resourceGroups/resourceGroup-Name/providers/Microsoft.Network/virtualNetworks/vNet-name/subnets/subnet-name".

- -ResourceGroupName "myresourcegroup"

- -Name "myvnet"

- -ResourceGroupName "myresourcegroup"

- -Name "myaccount"

- -VirtualNetworkResourceId $subnet.Id

-1. Install the [Azure CLI](/cli/azure/install-azure-cli) and [sign in](/cli/azure/authenticate-azure-cli), or select **Try it**.

-1. List virtual network rules.

- -g "myresourcegroup" -n "myaccount" \

-1. Enable service endpoint for Azure AI services on an existing virtual network and subnet.

- az network vnet subnet update -g "myresourcegroup" -n "mysubnet" \

- $subnetid=(az network vnet subnet show \

- -g "myresourcegroup" -n "mysubnet" --vnet-name "myvnet" \

- -g "myresourcegroup" -n "myaccount" \

- > To add a rule for a subnet in a VNet belonging to another Azure AD tenant, use a fully-qualified subnet ID in the form "/subscriptions/subscription-ID/resourceGroups/resourceGroup-Name/providers/Microsoft.Network/virtualNetworks/vNet-name/subnets/subnet-name".

- > You can use the **subscription** parameter to retrieve the subnet ID for a VNet belonging to another Azure AD tenant.

- -g "myresourcegroup" -n "mysubnet" --vnet-name "myvnet" \

- -g "myresourcegroup" -n "myaccount" \

-> Be sure to [set the default rule](#change-the-default-network-access-rule) to **deny**, or network rules have no effect.

-You can configure Azure AI services resources to allow access from specific public internet IP address ranges. This configuration grants access to specific services and on-premises networks, effectively blocking general internet traffic.

-Provide allowed internet address ranges using [CIDR notation](https://tools.ietf.org/html/rfc4632) in the form `16.17.18.0/24` or as individual IP addresses like `16.17.18.19`.

- > Small address ranges using "/31" or "/32" prefix sizes are not supported. These ranges should be configured using individual IP address rules.

-IP network rules are only allowed for **public internet** IP addresses. IP address ranges reserved for private networks (as defined in [RFC 1918](https://tools.ietf.org/html/rfc1918#section-3)) aren't allowed in IP rules. Private networks include addresses that start with `10.*`, `172.16.*` - `172.31.*`, and `192.168.*`.

-Only IPV4 addresses are supported at this time. Each Azure AI services resource supports up to 100 IP network rules, which may be combined with [Virtual network rules](#grant-access-from-a-virtual-network).

-### Configuring access from on-premises networks

-To grant access from your on-premises networks to your Azure AI services resource with an IP network rule, you must identify the internet facing IP addresses used by your network. Contact your network administrator for help.

-If you're using [ExpressRoute](../expressroute/expressroute-introduction.md) on-premises for public peering or Microsoft peering, you need to identify the NAT IP addresses. For public peering, each ExpressRoute circuit by default uses two NAT IP addresses. Each is applied to Azure service traffic when the traffic enters the Microsoft Azure network backbone. For Microsoft peering, the NAT IP addresses that are used are either customer provided or are provided by the service provider. To allow access to your service resources, you must allow these public IP addresses in the resource IP firewall setting. To find your public peering ExpressRoute circuit IP addresses, [open a support ticket with ExpressRoute](https://portal.azure.com/#blade/Microsoft_Azure_Support/HelpAndSupportBlade/overview) via the Azure portal. Learn more about [NAT for ExpressRoute public and Microsoft peering.](../expressroute/expressroute-nat.md#nat-requirements-for-azure-public-peering)

-1. Select the **RESOURCE MANAGEMENT** menu called **Virtual network**.

-1. Check that you've selected to allow access from **Selected networks**.

-1. To grant access to an internet IP range, enter the IP address or address range (in [CIDR format](https://tools.ietf.org/html/rfc4632)) under **Firewall** > **Address Range**. Only valid public IP (non-reserved) addresses are accepted.