-> API connectors used in this step are in preview. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-|token_endpoint_auth_method| No | Specifies how Azure AD B2C sends the authentication header to the token endpoint. Possible values: `client_secret_post` (default), and `client_secret_basic` (public preview), `private_key_jwt` (public preview). For more information, see [OpenID Connect client authentication section](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication). |

- ```XML

- <ValidationTechnicalProfiles>

- ....

- <ValidationTechnicalProfile ReferenceId="REST-AcquireAccessToken" />

- ....

- </ValidationTechnicalProfiles>

- ```

-

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

-> API-driven inbound provisioning is currently in public preview and is governed by [Preview Terms of Use](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-> API-driven inbound provisioning is currently in public preview and is governed by [Preview Terms of Use](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

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

-The [Azure AD Exporter](https://github.com/microsoft/azureadexporter) can provide most of the documentation you need:

-> Settings in the legacy multifactor authentication portal for Application Proxy and federation settings might not be exported with the Azure AD Exporter, or with the Microsoft Graph API.

-

-In some rare instances where the relevant Google or Apple service responsible for push notifications is down, users may not receive their push notifications. In these cases users should manually navigate to the Microsoft Authenticator app (or relevant companion app like Outlook), refresh by either pulling down or hitting the refresh button, and approve the request.

-> [!NOTE]

-> If your organization has staff working in or traveling to China, the *Notification through mobile app* method on Android devices doesn't work in that country/region as Google play services(including push notifications) are blocked in the region. However iOS notification do work. For Android devices ,alternate authentication methods should be made available for those users.

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

-Without any session lifetime settings, there are no persistent cookies in the browser session. Every time a user closes and open the browser, they get a prompt for reauthentication. In Office clients, the default time period is a rolling window of 90 days. With this default Office configuration, if the user has reset their password or there has been inactivity of over 90 days, the user is required to reauthenticate with all required factors (first and second factor).

-Under each sign-in log, go to the **Authentication Details** tab and explore **Session Lifetime Policies Applied**. For more information, see [Authentication details](../reports-monitoring/concept-sign-ins.md#authentication-details).

-| Firefox | &#10060; | &#10060; | &#10060; |

- Click **Authentication details** for [details about the MFA requirements](../reports-monitoring/concept-sign-ins.md#authentication-details).

->This is an important security enhancement for users authenticating via telecom transports. On June 26, the Microsoft managed value of this feature changed from ΓÇÿdisabledΓÇÖ to ΓÇÿenabledΓÇÖ. If you no longer wish for this feature to be enabled, move the state from 'default' toΓÇÿdisabledΓÇÖ or set users to include and exclude groups.

-By default, Authenticator Lite is [Microsoft managed](concept-authentication-default-enablement.md#microsoft-managed-settings). On June 26, the Microsoft managed value of this feature changed from ΓÇÿdisabledΓÇÖ to ΓÇÿenabledΓÇÖ

- 2. On the Enable and Target tab, click Yes and All users to enable the Authenticator policy for everyone or add selected users and groups. Set the Authentication mode for these users/groups to Any or Push.

- Only users who are enabled for Microsoft Authenticator here can be enabled to use Authenticator Lite for sign-in, or excluded from it. Users who aren't enabled for Microsoft Authenticator can't see the feature. Users who have Microsoft Authenticator downloaded on the same device Outlook is downloaded on will not be prompted to register for Authenticator Lite in Outlook. Android users utilizing a personal and work profile on their device may be prompted to register if Authenticator is present on a different profile from the Outlook application.

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

-**Phase 3** requires moving all clients that authenticate to the on-premises MFA Server (VPNs, password managers, and so on) to Azure AD federation via SAML/OAUTH. If modern authentication standards arenΓÇÖt supported, you're required to stand up NPS server(s) with the Azure AD MFA extension installed. Once dependencies are migrated, users should no longer use the User portal on the MFA Server, but rather should manage their authentication methods in Azure AD ([aka.ms/mfasetup](https://aka.ms/mfasetup)). Once users begin managing their authentication data in Azure AD, those methods won't be synced back to MFA Server. If you roll back to the on-premises MFA Server after users have made changes to their Authentication Methods in Azure AD, those changes will be lost. After user migrations are complete, change the [federatedIdpMfaBehavior](/graph/api/resources/internaldomainfederation?view=graph-rest-1.0#federatedidpmfabehavior-values&preserve-view=true) domain federation setting. The change tells Azure AD to no longer perform MFA on-premises and to perform _all_ MFA requests with Azure AD MFA, regardless of group membership.

-^*When a PIN is used to provide proof-of-presence functionality, the functional equivalent is provided above. PINs that arenΓÇÖt cryptographically tied to a device don't sufficiently protect against scenarios where a device has been compromised. To protect against these scenarios, including [SIM swap attacks](https://wikipedia.org/wiki/SIM_swap_scam), move users to more secure methods according to Microsoft authentication methods [best practices](concept-authentication-methods.md).

-|**Passed Sessions tab**|All authentication method registration flows are managed by Azure AD and donΓÇÖt require configuration|

-For RADIUS deployments that canΓÇÖt be upgraded, youΓÇÖll need to deploy an NPS Server and install the [Azure AD MFA NPS extension](howto-mfa-nps-extension.md).

-For LDAP deployments that canΓÇÖt be upgraded or moved to RADIUS, [determine if Azure Active Directory Domain Services can be used](../architecture/auth-ldap.md). In most cases, LDAP was deployed to support in-line password changes for end users. Once migrated, end users can manage their passwords by using [self-service password reset in Azure AD](tutorial-enable-sspr.md).

-If you enabled the [MFA Server Authentication provider in AD FS 2.0](./howto-mfaserver-adfs-windows-server.md#secure-windows-server-ad-fs-with-azure-multi-factor-authentication-server) on any relying party trusts except for the Office 365 relying party trust, youΓÇÖll need to upgrade to [AD FS 3.0](/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server) or federate those relying parties directly to Azure AD if they support modern authentication methods. Determine the best plan of action for each of the dependencies.

- - If the Windows API doesnΓÇÖt find the user or the SID isnΓÇÖt found in the MFA Server, then it will use the configured Active Directory attribute to find the user in the on-premises Active Directory, and then use the SID to search the MFA Server user list.

-1. You can migrate users even if they are unchanged. By default, the utility is set to **Only migrate users that have changed**. Click **Migrate all users** to re-migrate previously migrated users that are unchanged. Migrating unchanged users can be useful during testing if an administrator needs to reset a userΓÇÖs Azure MFA settings and wants to re-migrate them.

-MFA Methods will be updated based on what was migrated and the default method will be set. MFA Server will track the last migration timestamp and only migrate the user again if the userΓÇÖs MFA settings change or an admin modifies what to migrate in the **Settings** dialog.

-Ensure users know what to expect when they're moved to Azure MFA, including new authentication flows. You may also wish to instruct users to use the Azure AD Combined Registration portal ([aka.ms/mfasetup](https://aka.ms/mfasetup)) to manage their authentication methods rather than the User portal once migrations are complete. Any changes made to authentication methods in Azure AD won't propagate back to your on-premises environment. In a situation where you had to roll back to MFA Server, any changes users have made in Azure AD wonΓÇÖt be available in the MFA Server User portal.

-If you use third-party solutions that depend on Azure MFA Server for authentication (see [Authentication services](#authentication-services)), youΓÇÖll want users to continue to make changes to their MFA methods in the User portal. These changes will be synced to Azure AD automatically. Once you've migrated these third party solutions, you can move users to the Azure AD combined registration page.

-Once you've completed user migrations, and moved all of your [Authentication services](#authentication-services) off of MFA Server, itΓÇÖs time to update your domain federation settings. After the update, Azure AD no longer sends MFA request to your on-premises federation server.

-Users will no longer be redirected to your on-premises federation server for MFA, whether theyΓÇÖre targeted by the Staged Rollout tool or not. Note this can take up to 24 hours to take effect.

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

-## What types of identities are supported by Permissions Management?

-Permissions Management allows users to right-size excessive permissions and automate least privilege policy enforcement with just a few clicks. The solution continuously analyzes historical permission usage data for each identity and gives customers the ability to right-size permissions of that identity to only the permissions that are being used for day-to-day operations. All unused and other risky permissions can be automatically removed.

-## What is the data destruction/decommission process?

-If a customer initiates a free Permissions Management 45-day trial, but does not follow up and convert to a paid license within 45 days of the free trial expiration, we will delete all collected data on or just before 45 days.

-If a customer decides to discontinue licensing the service, we will also delete all previously collected data within 45 days of license termination.

-We also have the ability to remove, export or modify specific data should the Global Administrator using the Entra Permissions Management service file an official Data Subject Request. This can be initiated by opening a ticket in the Azure portal [New support request - Microsoft Entra admin center](https://entra.microsoft.com/#blade/Microsoft_Azure_Support/NewSupportRequestV3Blade/callerName/ActiveDirectory/issueType/technical), or alternately contacting your local Microsoft representative.

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

-1. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-> Microsoft Admin Poratls (preview) is not currently supported in Government clouds.

-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. Browse to **Azure Active Directory** > **Sign-ins**.

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

-1. Browse to **Azure Active Directory** > **Sign-in logs** > **Service Principal Sign-ins**. You can use filters to ease the debugging process.

-Customers who have configured CAE settings under Security before have to migrate settings to a new Conditional Access policy. Use the steps that follow to migrate your CAE settings to a Conditional Access policy.

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

-1. Browse to **Azure Active Directory** > **Security** > **Continuous access evaluation**.

-1. You have the option to **Migrate** your policy. This action is the only one that you have access to at this point.

-1. Browse to **Conditional Access** and you find a new policy named **Conditional Access policy created from CAE settings** with your settings configured. Administrators can choose to customize this policy or create their own to replace it.

-> Filter for applications is currently in 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/).

- 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. Browse to **Azure Active Directory** > **Security** > **Conditional Access**.

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

-1. Browse to **Azure Active Directory** > **Enterprise applications**.

-> Token protection is currently in 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/).

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

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

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

-1. Browse to **Azure Active Directory** > **Sign-in logs**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

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

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Insights and reporting**.

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

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

-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. Browse to **Azure Active Directory** > **Log Analytics**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-> 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. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access** > **Named locations**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

- > 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. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

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

-1. Browse to **Azure Active Directory** > **Sign-in logs**.

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

-1. Browse to **Azure Active Directory** > **Workbooks**.

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

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Named locations**. Here you can create or update trusted IP locations.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Named locations**.

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

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

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-description: Learn how Conditional Access is at the heart of the new identity-driven control plane.

-Microsoft is providing Conditional Access templates to organizations in report-only mode starting in January of 2023. We may add more policies as new threats emerge.

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

-Conditional Access policies at their simplest are if-then statements, if a user wants to access a resource, then they must complete an action. Example: A payroll manager wants to access the payroll application and is required to do multifactor authentication to access it.

- - Users attempting to access specific applications can trigger different Conditional Access policies.

- - Signals integration with [Azure AD Identity Protection](../identity-protection/overview-identity-protection.md) allows Conditional Access policies to identify and remediate risky users and sign-in behavior.

-Administrators with the [Conditional Access Administrator](../roles/permissions-reference.md#conditional-access-administrator) role can manage policies in Azure AD.

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

-Risk-based policies require access to [Identity Protection](../identity-protection/overview-identity-protection.md), which is an Azure AD P2 feature.

-> 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 your test user.

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

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Terms of use**.

- :::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. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Terms of use**.

-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. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Terms of use**.

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

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Terms of use**.

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

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Terms of use**.

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

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Terms of use**.

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

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Terms of use**.

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

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Terms of use**.

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

-1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Terms of use**.

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

-1. Browse to **Azure Active Directory** > **Sign-ins**.

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

-1. Browse to **Azure Active Directory** > **Audit logs**.

-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. Browse to **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

-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 **Microsoft Entra ID (Azure AD)** > **Protection** > **Conditional Access**.

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

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

-1. In the left pane, select **Azure Active Directory**.

-1. Select **Enterprise applications**, and then select **All applications**.

- :::image type="content" source="media/enterprise-app-role-management/record-objectid.png" alt-text="Screenshot that shows how to locate and record the object identifier for the application.":::

-1. Locate the application in the Azure portal, and then select **Single sign-on** in the left menu.

- :::image type="content" source="media/enterprise-app-role-management/attributes-summary.png" alt-text="Screenshot that shows a display of the list of attributes and claims defined for the application.":::

-1. In the Azure portal, locate the application to which the role was added.

- :::image type="content" source="media/enterprise-app-role-management/assign-role.png" alt-text="Screenshot that shows how to assign a role to a user of an application.":::

-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

-To view or edit the claims issued in the JWT to the application, open the application in Azure portal. Then select **Single sign-on** blade in the left-hand menu and open the **Attributes & Claims** section.

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

-1. In the **Attributes & Claims** section, Select **Edit** to edit the claims.

-1. Select the required claim that you want to modify.

- :::image type="content" source="./media/jwt-claims-customization/sso-saml-multiple-claims-transformation.png" alt-text="Screenshot of claims transformation.":::

-| **EndWith()** | Outputs an attribute or constant if the input ends with the specified value. Otherwise, you can specify another output if there's no match.<br/>For example, if you want to emit a claim where the value is the user's employee ID if the employee ID ends with "000", otherwise you want to output an extension attribute. To perform this function, you configure the following values:<br/>*Parameter 1(input)*: user.employeeid<br/>*Value*: "000"<br/>Parameter 2 (output): user.employeeid<br/>Parameter 3 (output if there's no match): user.extensionattribute1 |

-| **StartWith()** | Outputs an attribute or constant if the input starts with the specified value. Otherwise, you can specify another output if there's no match.<br/>For example, if you want to emit a claim where the value is the user's employee ID if the country/region starts with "US", otherwise you want to output an extension attribute. To perform this function, you configure the following values:<br/>*Parameter 1(input)*: user.country<br/>*Value*: "US"<br/>Parameter 2 (output): user.employeeid<br/>Parameter 3 (output if there's no match): user.extensionattribute1 |

-Applications that receive tokens rely on claim values that are authoritatively issued by Azure AD and can't be tampered with. When you modify the token contents through claims customization, these assumptions may no longer be correct. Applications must explicitly acknowledge that tokens have been modified by the creator of the customization to protect themselves from customizations created by malicious actors. This can be done in one the following ways:

-For multi-tenant apps, a custom signing key should be used. Don't set `acceptMappedClaims` in the app manifest. when setting up an app in the Azure portal, you get an app registration object and a service principal in your tenant. That app is using the Azure global sign-in key, which can't be used for customizing claims in tokens. To get custom claims in tokens, create a custom sign-in key from a certificate and add it to service principal. For testing purposes, you can use a self-signed certificate. After configuring the custom signing key, your application code needs to validate the token signing key.

-The following example shows the format of the HTTP PATCH request to add a custom signing key to a service principal. The "key" value in the `keyCredentials` property is shortened for readability. The value is base-64 encoded. For the private key, the property usage is "Sign". For the public key, the property usage is "Verify".

-Use PowerShell to [instantiate an MSAL Public Client Application](msal-net-initializing-client-applications.md#initializing-a-public-client-application-from-code) and use the [Authorization Code Grant](v2-oauth2-auth-code-flow.md) flow to obtain a delegated permission access token for Microsoft Graph. Use the access token to call Microsoft Graph and configure a custom signing key for the service principal. After configuring the custom signing key, your application code needs to [validate the token signing key](#validate-token-signing-key).

-To run this script you need:

-For single tenant apps, you can set the `acceptMappedClaims` property to `true` in the [application manifest](reference-app-manifest.md). As documented on the [apiApplication resource type](/graph/api/resources/apiapplication?view=graph-rest-1.0&preserve-view=true#properties), this allows an application to use claims mapping without specifying a custom signing key.

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

-The methods for pop-up experience (`loginPopup`, `acquireTokenPopup`) return promises, so you can use the promise pattern (.then and .catch) to handle them as shown:

-> Public preview is provided without a service-level agreement and isn't recommended for production workloads. Some features might be unsupported or have constrained capabilities. For more information, see [Supplemental terms of use for Microsoft Azure previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

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

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations**.

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

-1. After you've authenticated, choose your tenant by selecting it from the top-right corner of the page.

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations**.

-1. Select the application you want to configure optional claims for in the list.

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

-1. After you've authenticated, choose your Azure AD tenant by selecting it from the top-right corner of the page.

-1. Search for and select **Azure Active Directory**.

-1. Select the application you want to configure optional claims for in the list.

- - idToken for the OIDC ID token

- - accessToken for the OAuth access token

- - Saml2Token for SAML tokens.

- The Saml2Token type applies to both SAML1.1 and SAML2.0 format tokens.

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

-1. After you've authenticated, choose your tenant by selecting it from the top-right corner of the page.

-1. Search for and select **Azure Active Directory**.

-1. Under **Manage**, select **App registrations**.

-1. Find the application you want to configure optional claims for in the list and select it.

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

-1. After you've authenticated, choose your tenant by selecting it from the top-right corner of the page.

-1. Search for and select **Azure Active Directory**.

-1. Find the application you want to configure optional claims for in the list and select it.

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

-[preview-tos]: https://azure.microsoft.com/support/legal/preview-supplemental-terms/

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

-1. Browse to **Azure Active Directory** > **Devices** > **Device settings**.

-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. Browse to **Azure Active Directory** > **Devices** > **Enterprise State Roaming**.

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

-1. Browse to **Azure Active Directory** > **Users** > **All users**.

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

-> See the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

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

-1. Browse to **Azure Active Directory** > **Devices** > **Device settings**

- 

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

-1. Browse to **Azure Active Directory** > **Enterprise applications**.

-> If a device object with the same displayMame as the hostname of a VM where an extension is installed exists, the VM fails to join Azure AD with a hostname duplication error. Avoid duplication by [modifying the hostname](../../virtual-network/virtual-networks-viewing-and-modifying-hostnames.md#modify-a-hostname).

- 

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

-1. Browse to **Azure Active Directory** > **Enterprise applications**.

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

-2. Go to **Azure Active Directory** > **Devices** > **All devices**.

-3. Select the **Preview features** button.

-4. Turn on the toggle that says **Enhanced devices list experience**. Select **Apply**.

-5. Refresh your browser.

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

-1. Browse to **Azure Active Directory** > **Devices** > **Diagnose and solve problems**.

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

-Microsoft 365 group writeback is a public preview feature of Azure Active Directory (Azure AD) and is available with any paid Azure AD license plan. For some legal information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-> See the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

-The updated experience for creating new users covered in this article is available as an Azure AD preview feature. This feature is enabled by default, but you can opt out by going to **Azure AD** > **Preview features** and disabling the **Create user experience** feature. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-The updated experience for creating new users covered in this article is available as an Azure AD preview feature. This feature is enabled by default, but you can opt out by going to **Azure AD** > **Preview features** and disabling the **Create user experience** feature. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

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

- 

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com/), select **Azure Active Directory**.

-1. Select **Applications** > **App registrations**.

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com/), select **Azure Active Directory**.

-1. Select **Applications** > **App registrations**.

-1. Sign in to your organization's [Microsoft Entra admin center](https://entra.microsoft.com/).

-1. From the left menu, select **Azure Active Directory** > **Overview**.

-1. On the overview page, select **Manage tenants**

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/).

-1. In the search bar, type and select **Company branding**.

-1. Under **Default sign-in** select **Edit**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/).

-1.If you have access to multiple tenants, use the **Directories + subscriptions** filter :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch to the customer tenant you created earlier.

-1. In the search bar, type and select **Company branding**.

-1. Under **Default sign-in experience**, select **Edit**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/).

-1. In the search bar, type and select **Company branding**.

-1. Under **Browser language customizations**, select **Add browser language**.

- - Turkish (Turkey)

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/).

-3. In the left menu, select **Azure Active Directory** > **External Identities**.

-4. Select **User flows**.

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com/), select **Azure Active Directory**.

-1. Select **External Identities** > **Overview**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/).

-1. In the left pane, select **Azure Active Directory** > **External Identities** > **User flows**.

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com/), select **Azure Active Directory**.

-1. In the left pane, select **Azure Active Directory** > **External Identities** > **User flows**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/).

-1. In the navigation pane, select **Azure Active Directory**.

-1. Select **External Identities** > **User flows**.

- 1. Select **Protect & secure** from the sidebar under **Azure Active Directory** and then **Authentication methods** > **Policies**.

- 1. Under **Method** select **Email OTP (preview)**.

- > To find your customer tenant ID, go to the [Microsoft Entra admin center](https://entra.microsoft.com). Under **Azure Active Directory**, select **Overview**. Then select the **Overview** tab and copy the **Tenant ID**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/) as the global administrator of your customer tenant.

-1. Go to **Azure Active Directory** > **External Identities** > **All identity providers**.

-1. In your customer tenant, go to **Azure Active Directory** > **External Identities** > **User flows**.

- > To find your customer tenant ID, go to the [Microsoft Entra admin center](https://entra.microsoft.com). Under **Azure Active Directory**, select **Overview**. Then select the **Overview** tab and copy the **Tenant ID**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/) as the global administrator of your customer tenant.

-1. Go to **Azure Active Directory** > **External Identities** > **All identity providers**.

-1. In your customer tenant, go to **Azure Active Directory** > **External Identities** > **User flows**.

-1. Browse to **Azure Active Directory** > **Protect & secure** > **Security Center**.

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com), browse to **Azure Active Directory** > **Protect & secure** > **Security Center**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/) with Global Administrator or Privileged Role Administrator permissions.

-1. Make sure you're using your customer tenant. Select the **Directories + subscriptions** icon :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the toolbar.

-1. On the **Portal settings | Directories + subscriptions** page, find your customer tenant in the **Directory name** list, and then select **Switch**.

-1. Under **Azure Active Directory**, select **Users** > **All users**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/) with Global Administrator or Privileged Role Administrator permissions.

-1. Make sure you're using your customer tenant. Select the **Directories + subscriptions** icon :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the toolbar.

-1. On the **Portal settings | Directories + subscriptions** page, find your customer tenant in the **Directory name** list, and then select **Switch**.

-1. Under **Azure Active Directory**, select **Users** > **All users**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/) with Global Administrator or Privileged Role Administrator permissions.

-1. Make sure you're using your customer tenant. Select the **Directories + subscriptions** icon :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the toolbar.

-1. On the **Portal settings | Directories + subscriptions** page, find your customer tenant in the **Directory name** list, and then select **Switch**.

-1. Under **Azure Active Directory**, select **Users** > **All users**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/) with Global Administrator or Privileged Role Administrator permissions.

-1. Make sure you're using your customer tenant. Select the **Directories + subscriptions** icon :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the toolbar.

-1. On the **Portal settings | Directories + subscriptions** page, find your customer tenant in the **Directory name** list, and then select **Switch**.

-1. Under **Azure Active Directory**, select **Users** > **All users**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/) with Global Administrator or Privileged Role Administrator permissions.

-1. Make sure you're using your customer tenant. Select the **Directories + subscriptions** icon :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the toolbar.

-1. On the **Portal settings | Directories + subscriptions** page, find your customer tenant in the **Directory name** list, and then select **Switch**.

-1. Under **Azure Active Directory**, select **Roles & admins** > **Roles & admins**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/) with Global Administrator or Privileged Role Administrator permissions.

-1. Make sure you're using your customer tenant. Select the **Directories + subscriptions** icon :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the toolbar.

-1. On the **Portal settings | Directories + subscriptions** page, find your customer tenant in the **Directory name** list, and then select **Switch**.

-1. Under **Azure Active Directory**, select **Users** > **All users**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/) with Global Administrator or Privileged Role Administrator permissions.

-1. Make sure you're using your customer tenant. Select the **Directories + subscriptions** icon :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the toolbar.

-1. On the **Portal settings | Directories + subscriptions** page, find your customer tenant in the **Directory name** list, and then select **Switch**.

-1. Under **Azure Active Directory**, select **Users** > **All users**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/) with Global Administrator or Privileged Role Administrator permissions.

-1. Make sure you're using your customer tenant. Select the **Directories + subscriptions** icon :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the toolbar.

-1. On the **Portal settings | Directories + subscriptions** page, find your customer tenant in the **Directory name** list, and then select **Switch**.

-1. Under **Azure Active Directory**, select **Users** > **All users**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/) with Global Administrator or Privileged Role Administrator permissions.

-1. Make sure you're using your customer tenant. Select the **Directories + subscriptions** icon :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the toolbar.

-1. On the **Portal settings | Directories + subscriptions** page, find your customer tenant in the **Directory name** list, and then select **Switch**.

-1. Under **Azure Active Directory**, select **Users** > **All users**.

-1. Make sure you're using the directory that contains your Azure AD customer tenant: Select the **Directories + subscriptions** icon :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the toolbar and find your customer tenant in the list. If it's not the current directory, select **Switch**.

-1. Browse to **Azure Active Directory** > **Protect & secure** > **Security Center**.

-1. Sign in to your customer tenant in the [Microsoft Entra admin center](https://entra.microsoft.com).

-1. Browse to **Azure Active Directory** > **Protect & secure** > **Authentication Methods**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/).

-1. If you have access to multiple tenants, make sure you use the directory that contains your Azure AD for customers tenant:

-

- 1. Select the **Directories + subscriptions** icon :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the portal toolbar.

-

- 1. On the **Portal settings | Directories + subscriptions** page, find your Azure AD for customers directory in the **Directory name** list, and then select **Switch**.

-1. On the sidebar menu, select **Azure Active Directory**.

-1. Select **Applications**, then select **App Registrations**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/).

-1. If you have access to multiple tenants, make sure you use the directory that contains your Azure AD for customers tenant:

-

- 1. Select the **Directories + subscriptions** icon :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the portal toolbar.

-

- 1. On the **Portal settings | Directories + subscriptions** page, find your Azure AD for customers directory in the **Directory name** list, and then select **Switch**.

-1. On the sidebar menu, select **Azure Active Directory**.

-1. Select **Applications**, then select **App Registrations**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/).

-1. If you have access to multiple tenants, make sure you use the directory that contains your Azure AD for customers tenant:

-

- 1. Select the **Directories + subscriptions** icon :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the portal toolbar.

-

- 1. On the **Portal settings | Directories + subscriptions** page, find your Azure AD for customers directory in the **Directory name** list, and then select **Switch**.

-1. On the sidebar menu, select **Azure Active Directory**.

-1. Select **Applications**, then select **App Registrations**.

-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

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com/), select **Azure Active Directory** > **External Identities** > **User flows**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/).

-1. If you have access to multiple tenants, use the **Directories + subscriptions** filter :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch to your customer tenant.

-1. In the left pane, select **Azure Active Directory** > **External Identities** > **User flows**.

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com/), select **Azure Active Directory**.

-1. In the left pane, select **Azure Active Directory** > **External Identities** > **User flows**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/).

-1. If you have access to multiple tenants, make sure you use the directory that contains your Azure AD for customers tenant:

- 1. Select the **Directories + subscriptions** icon :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the portal toolbar.

- 1. On the **Portal settings | Directories + subscriptions** page, find your Azure AD for customers directory in the **Directory name** list, and then select **Switch**.

-1. On the sidebar menu, select **Azure Active Directory**.

-1. Select **Applications**, then select **App Registrations**.

-1. Sign in to your organization's [Microsoft Entra admin center](https://entra.microsoft.com/).

-1. From the left menu, select **Azure Active Directory** > **Overview**.

-1. Select **Manage tenants** at the top of the page.

-1. Ensure that you're signed in to the directory that you want to delete through the **Directories + subscriptions** filter :::image type="icon" source="media/common/portal-directory-subscription-filter.png" border="false"::: in the Azure portal. Switch to the target directory if needed.

-1. From the left menu, select **Azure Active Directory** > **Overview**.

-1. Select **Manage tenants** at the top of the page.

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

-> The **Tenant restrictions** settings, which are included with cross-tenant access settings, are preview features 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/).

-| | |

-|||

- - **Select external applications**: Lets you choose the external applications you want the action under **Access status** to apply to. To select applications, choose **Add Microsoft applications** or **Add other applications**. Then search by the application name or the application ID (either the *client app ID* or the *resource app ID*) and select the app. ([See a list of IDs for commonly used Microsoft applications.](https://learn.microsoft.com/troubleshoot/azure/active-directory/verify-first-party-apps-sign-in)) If you want to add more apps, use the **Add** button. When you're done, select **Submit**.

- - In the search box, type the application name or the application ID (either the *client app ID* or the *resource app ID*). ([See a list of IDs for commonly used Microsoft applications.](https://learn.microsoft.com/troubleshoot/azure/active-directory/verify-first-party-apps-sign-in)) For our Microsoft Learn example, we enter the application ID `18fbca16-2224-45f6-85b0-f7bf2b39b3f3`.

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

-> See the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

-> See the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

-> See the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

-> See the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

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

-The updated experience for creating new users covered in this article is available as an Azure AD preview feature. This feature is enabled by default, but you can opt out by going to **Azure AD** > **Preview features** and disabling the **Create user experience** feature. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-# What is the identity secure score in Azure Active Directory?

-How secure is your Azure AD tenant? If you don't know how to answer this question, this article explains how the identity secure score helps you to monitor and improve your identity security posture.

-## What is an identity secure score?

-The identity secure score is percentage that functions as an indicator for how aligned you are with Microsoft's best practice recommendations for security. Each improvement action in identity secure score is tailored to your specific configuration.

-The score helps you to:

-The identity secure score is available in all editions of Azure AD. Organizations can access their identity secure score from the **Azure portal** > **Azure Active Directory** > **Security** > **Identity Secure Score**.

-Every 48 hours, Azure looks at your security configuration and compares your settings with the recommended best practices. Based on the outcome of this evaluation, a new score is calculated for your directory. ItΓÇÖs possible that your security configuration isnΓÇÖt fully aligned with the best practice guidance and the improvement actions are only partially met. In these scenarios, you will only be awarded a portion of the max score available for the control.

-Each recommendation is measured based on your Azure AD configuration. If you are using third-party products to enable a best practice recommendation, you can indicate this configuration in the settings of an improvement action. You also have the option to set recommendations to be ignored if they don't apply to your environment. An ignored recommendation does not contribute to the calculation of your score.

-* Global administrator

-* Security administrator

-* Exchange administrator

-* SharePoint administrator

-* Helpdesk administrator

-* User administrator

-* Service support administrator

-* Security reader

-* Security operator

-* Global reader

-Controls can be scored in two ways. Some are scored in a binary fashion - you get 100% of the score if you have the feature or setting configured based on our recommendation. Other scores are calculated as a percentage of the total configuration. For example, if the improvement recommendation states youΓÇÖll get a maximum of 10.71% if you protect all your users with MFA and you only have 5 of 100 total users protected, you would be given a partial score around 0.53% (5 protected / 100 total * 10.71% maximum = 0.53% partial score).

-Actions labeled as [Not Scored] are ones you can perform in your organization but won't be scored because they aren't hooked up in the tool (yet!). So, you can still improve your security, but you won't get credit for those actions right now.

-In addition, the recommended actions:

-* Protect all users with a user risk policy

-* Protect all users with a sign-in risk policy

-Also won't give you credits when configured using Conditional Access Policies, yet, for the same reason as above. For now, these actions give credits only when configured through Identity Protection policies.

-Head over to the [Microsoft 365 Defender portal](https://security.microsoft.com/), where youΓÇÖll find your complete Microsoft secure score. You can easily see all the changes to your secure score by reviewing the in-depth changes on the history tab.

-In short, no. The secure score does not express an absolute measure of how likely you are to get breached. It expresses the extent to which you have adopted features that can offset the risk of being breached. No service can guarantee that you will not be breached, and the secure score should not be interpreted as a guarantee in any way.

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

-Organization | <ul><li>Read all company information<li>Read all domains<li>Read configuration of certificate-based authentication<li>Read all partner contracts</li></ul> | <ul><li>Read company display name<li>Read all domains<li>Read configuration of certificate-based authentication</li></ul> | <ul><li>Read company display name<li>Read all domains</li></ul>

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

-[Albourne Castle](https://village.albourne.com/castle), [Adra by Trintech](../saas-apps/adra-by-trintech-tutorial.md), [workhub](../saas-apps/workhub-tutorial.md), [4DX](../saas-apps/4dx-tutorial.md), [Ecospend IAM V1](https://iamapi.sb.ecospend.com/account/login), [TigerGraph](../saas-apps/tigergraph-tutorial.md), [Sketch](../saas-apps/sketch-tutorial.md), [Lattice](../saas-apps/lattice-tutorial.md), [snapADDY Single Sign On](https://app.snapaddy.com/login), [RELAYTO Content Experience Platform](https://relayto.com/signin), [oVice](https://tour.ovice.in/login), [Arena](../saas-apps/arena-tutorial.md), [QReserve](../saas-apps/qreserve-tutorial.md), [Curator](../saas-apps/curator-tutorial.md), [NetMotion Mobility](../saas-apps/netmotion-mobility-tutorial.md), [HackNotice](../saas-apps/hacknotice-tutorial.md), [ERA_EHS_CORE](../saas-apps/era-ehs-core-tutorial.md), [AnyClip Teams Connector](https://videomanager.anyclip.com/login), [Wiz SSO](../saas-apps/wiz-sso-tutorial.md), [Tango Reserve by AgilQuest (EU Instance)](../saas-apps/tango-reserve-tutorial.md), [valid8Me](../saas-apps/valid8me-tutorial.md), [Ahrtemis](../saas-apps/ahrtemis-tutorial.md), [KPMG Leasing Tool](../saas-apps/kpmg-tool-tutorial.md) [Mist Cloud Admin SSO](../saas-apps/mist-cloud-admin-tutorial.md), [Work-Happy](https://live.work-happy.com/?azure=true), [Ediwin SaaS EDI](../saas-apps/ediwin-saas-edi-tutorial.md), [LUSID](../saas-apps/lusid-tutorial.md), [Next Gen Math](https://nextgenmath.com/), [Total ID](https://www.tokyo-shoseki.co.jp/ict/), [Cheetah For Benelux](../saas-apps/cheetah-for-benelux-tutorial.md), [Live Center Australia](https://au.livecenter.com/), [Shop Floor Insight](https://www.dmsiworks.com/apps/shop-floor-insight), [Warehouse Insight](https://www.dmsiworks.com/apps/warehouse-insight), [myAOS](../saas-apps/myaos-tutorial.md), [Hero](https://admin.linc-ed.com/), [FigBytes](../saas-apps/figbytes-tutorial.md), [VerosoftDesign](https://verosoft-design.vercel.app/), [ViewpointOne - UK](https://identity-uk.team.viewpoint.com/), [EyeRate Reviews](https://azure-login.eyeratereviews.com/), [Lytx DriveCam](../saas-apps/lytx-drivecam-tutorial.md)

-## February 2022

-

-

-### General Availability - France digital accessibility requirement

-**Type:** Plan for change

-**Service category:** Other

-**Product capability:** End User Experiences

-

-This change provides users who are signing into Azure Active Directory on iOS, Android, and Web UI flavors information about the accessibility of Microsoft's online services via a link on the sign-in page. This ensures that the France digital accessibility compliance requirements are met. The change will only be available for French language experiences.[Learn more](https://www.microsoft.com/fr-fr/accessibility/accessibilite/accessibility-statement)

-

-

-### General Availability - Downloadable access review history report

-**Type:** New feature

-**Service category:** Access Reviews

-**Product capability:** Identity Governance

-

-With Azure Active Directory (Azure AD) Access Reviews, you can create a downloadable review history to help your organization gain more insight. The report pulls the decisions that were taken by reviewers when a report is created. These reports can be constructed to include specific access reviews, for a specific time frame, and can be filtered to include different review types and review results.[Learn more](../governance/access-reviews-downloadable-review-history.md)

-

-

-### Public Preview of Identity Protection for Workload Identities

-**Type:** New feature

-**Service category:** Identity Protection

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

-

-Azure AD Identity Protection is extending its core capabilities of detecting, investigating, and remediating identity-based risk to workload identities. This allows organizations to better protect their applications, service principals, and managed identities. We're also extending Conditional Access so you can block at-risk workload identities. [Learn more](../identity-protection/concept-workload-identity-risk.md)

-

-

-### Public Preview - Cross-tenant access settings for B2B collaboration

-**Type:** New feature

-**Service category:** B2B

-**Product capability:** Collaboration

-

-Cross-tenant access settings enable you to control how users in your organization collaborate with members of external Azure AD organizations. Now you have granular inbound and outbound access control settings that work on a per org, user, group, and application basis. These settings also make it possible for you to trust security claims from external Azure AD organizations like multi-factor authentication (MFA), device compliance, and hybrid Azure AD joined devices. [Learn more](../external-identities/cross-tenant-access-overview.md)

-

-

-### Public preview - Create Azure AD access reviews with multiple stages of reviewers

-**Type:** New feature

-**Service category:** Access Reviews

-**Product capability:** Identity Governance

-

-Use multi-stage reviews to create Azure AD access reviews in sequential stages, each with its own set of reviewers and configurations. Supports multiple stages of reviewers to satisfy scenarios such as: independent groups of reviewers reaching quorum, escalations to other reviewers, and reducing burden by allowing for later stage reviewers to see a filtered-down list. For public preview, multi-stage reviews are only supported on reviews of groups and applications. [Learn more](../governance/create-access-review.md)

-

-

-### New Federated Apps available in Azure AD Application gallery - February 2022

-**Type:** New feature

-**Service category:** Enterprise Apps

-**Product capability:** Third Party Integration

-

-In February 2022 we added the following 20 new applications in our App gallery with Federation support:

-[Embark](../saas-apps/embark-tutorial.md), [FENCE-Mobile RemoteManager SSO](../saas-apps/fence-mobile-remotemanager-sso-tutorial.md), [カオナビ](../saas-apps/kao-navi-tutorial.md), [Adobe Identity Management (OIDC)](../saas-apps/adobe-identity-management-tutorial.md), [AppRemo](../saas-apps/appremo-tutorial.md), [Live Center](https://livecenter.norkon.net/Login), [Offishall](https://app.offishall.io/), [MoveWORK Flow](https://www.movework-flow.fm/login), [Cirros SL](https://www.cirros.net/), [ePMX Procurement Software](https://azure.epmxweb.com/admin/index.php?), [Vanta O365](https://app.vanta.com/connections), [Hubble](../saas-apps/hubble-tutorial.md), [Medigold Gateway](https://gateway.medigoldcore.com), [クラウドログ](../saas-apps/crowd-log-tutorial.md),[Amazing People Schools](../saas-apps/amazing-people-schools-tutorial.md), [XplicitTrust Network Access](https://console.xplicittrust.com/#/dashboard), [Spike Email - Mail & Team Chat](https://spikenow.com/web/), [AltheaSuite](https://planmanager.altheasuite.com/), [Balsamiq Wireframes](../saas-apps/balsamiq-wireframes-tutorial.md).

-You can also find the documentation of all the applications from here: [https://aka.ms/AppsTutorial](../saas-apps/tutorial-list.md),

-For listing your application in the Azure AD app gallery, please read the details here: [https://aka.ms/AzureADAppRequest](../manage-apps/v2-howto-app-gallery-listing.md)

-

-

-### Two new MDA detections in Identity Protection

-**Type:** New feature

-**Service category:** Identity Protection

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

-

-Identity Protection has added two new detections from Microsoft Defender for Cloud Apps, (formerly MCAS). The Mass Access to Sensitive Files detection detects anomalous user activity, and the Unusual Addition of Credentials to an OAuth app detects suspicious service principal activity.[Learn more](../identity-protection/concept-identity-protection-risks.md)

-

-

-### Public preview - New provisioning connectors in the Azure AD Application Gallery - February 2022

-**Type:** New feature

-**Service category:** App Provisioning

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

-

-You can now automate creating, updating, and deleting user accounts for these newly integrated apps:

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

-

-

-### General Availability - Privileged Identity Management (PIM) role activation for SharePoint Online enhancements

-**Type:** Changed feature

-**Service category:** Privileged Identity Management

-**Product capability:** Privileged Identity Management

-

-We've improved the Privileged Identity management (PIM) time to role activation for SharePoint Online. Now, when activating a role in PIM for SharePoint Online, you should be able to use your permissions right away in SharePoint Online. This change rolls out in stages, so you might not yet see these improvements in your organization. [Learn more](../privileged-identity-management/pim-how-to-activate-role.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).

-## February 2023

-### General Availability - Expanding Privileged Identity Management Role Activation across the Azure portal

-**Type:** New feature

-**Service category:** Privileged Identity Management

-**Product capability:** Privileged Identity Management

-Privileged Identity Management (PIM) role activation has been expanded to the Billing and AD extensions in the Azure portal. Shortcuts have been added to Subscriptions (billing) and Access Control (AD) to allow users to activate PIM roles directly from these settings. From the Subscriptions settings, select **View eligible subscriptions** in the horizontal command menu to check your eligible, active, and expired assignments. From there, you can activate an eligible assignment in the same pane. In Access control (IAM) for a resource, you can now select **View my access** to see your currently active and eligible role assignments and activate directly. By integrating PIM capabilities into different Azure portal blades, this new feature allows users to gain temporary access to view or edit subscriptions and resources more easily.

-For more information Microsoft cloud settings, see: [Activate my Azure resource roles in Privileged Identity Management](../privileged-identity-management/pim-resource-roles-activate-your-roles.md).

-### General Availability - Follow Azure AD best practices with recommendations

-**Type:** New feature

-**Service category:** Reporting

-**Product capability:** Monitoring & Reporting

-Azure AD recommendations help you improve your tenant posture by surfacing opportunities to implement best practices. On a daily basis, Azure AD analyzes the configuration of your tenant. During this analysis, Azure AD compares the data of a recommendation with the actual configuration of your tenant. If a recommendation is flagged as applicable to your tenant, the recommendation appears in the Recommendations section of the Azure AD Overview.

-This release includes our first 3 recommendations:

-For more information, see:

-### Public Preview - Azure AD PIM + Conditional Access integration

-**Type:** New feature

-**Service category:** Privileged Identity Management

-**Product capability:** Privileged Identity Management

-Now you can require users who are eligible for a role to satisfy Conditional Access policy requirements for activation: use specific authentication method enforced through Authentication Strengths, activate from Intune compliant device, comply with Terms of Use, and use 3rd party MFA and satisfy location requirements.

-For more information, see: [Configure Azure AD role settings in Privileged Identity Management](../privileged-identity-management/pim-how-to-change-default-settings.md).

-### General Availability - More information on why a sign-in was flagged as "unfamiliar"

-**Type:** Changed feature

-**Service category:** Identity Protection

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

-Unfamiliar sign-in properties risk detection now provides risk reasons as to which properties are unfamiliar for customers to better investigate that risk.

-Identity Protection now surfaces the unfamiliar properties in the Azure portal on UX and in API as *Additional Info* with a user-friendly description explaining that *the following properties are unfamiliar for this sign-in of the given user*.

-There's no additional work to enable this feature, the unfamiliar properties are shown by default. For more information, see: [Sign-in risk](../identity-protection/concept-identity-protection-risks.md).

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

-**Type:** New feature

-**Service category:** Enterprise Apps

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

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

-[PROCAS](https://accounting.procas.com/), [Tanium Cloud SSO](../saas-apps/tanium-sso-tutorial.md), [LeanDNA](../saas-apps/leandna-tutorial.md), [CalendarAnything LWC](https://silverlinecrm.com/calendaranything/), [courses.work](../saas-apps/courseswork-tutorial.md), [Udemy Business SAML](../saas-apps/udemy-business-saml-tutorial.md), [Canva](../saas-apps/canva-tutorial.md), [Kno2fy](../saas-apps/kno2fy-tutorial.md), [IT-Conductor](../saas-apps/it-conductor-tutorial.md), [ナレッジワーク(Knowledge Work)](../saas-apps/knowledge-work-tutorial.md), [Valotalive Digital Signage Microsoft 365 integration](https://store.valotalive.com/#main), [Priority Matrix HIPAA](https://hipaa.prioritymatrix.com/), [Priority Matrix Government](https://hipaa.prioritymatrix.com/), [Beable](../saas-apps/beable-tutorial.md), [Grain](https://grain.com/app?dialog=integrations&integration=microsoft+teams), [DojoNavi](../saas-apps/dojonavi-tutorial.md), [Global Validity Access Manager](https://myaccessmanager.com/), [FieldEquip](https://app.fieldequip.com/), [Peoplevine](https://control.peoplevine.com/), [Respondent](../saas-apps/respondent-tutorial.md), [WebTMA](../saas-apps/webtma-tutorial.md), [ClearIP](https://clearip.com/login), [Pennylane](../saas-apps/pennylane-tutorial.md), [VsimpleSSO](https://app.vsimple.com/login), [Compliance Genie](../saas-apps/compliance-genie-tutorial.md), [Dataminr Corporate](https://dmcorp.okta.com/), [Talon](../saas-apps/talon-tutorial.md).

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

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

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

-**Type:** New feature

-**Service category:** App Provisioning

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

-

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

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

-| [SAP ECC 7.0](../../active-directory/app-provisioning/on-premises-sap-connector-configure.md) | ΓùÅ | |

-| SAP R/3 | ΓùÅ | |

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

-1. Select **Azure Active Directory** and then select **Identity Governance**.

-1. On the left menu, select **Lifecycle Workflows**.

-1. On the Lifecycle Workflows overview page, select **Workflows**.

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

-1. Type in **Identity Governance** on the search bar near the top of the page and select it.

-1. In the left menu, select **Lifecycle workflows**.

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

-1. On the search bar near the top of the page, enter **Identity Governance** and select the result.

-1. On the left menu, select **Lifecycle workflows**.

-1. On the left menu, select **Workflows**.

-1. Select **Tasks**.

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

-1. On the search bar near the top of the page, enter **Identity Governance** and select the result.

-1. On the left menu, select **Lifecycle workflows**.

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

-1. On the search bar near the top of the page, enter **Identity Governance**. Then select **Identity Governance** in the results.

-1. On the left menu, select **Lifecycle Workflows**.

-1. Select **Workflows**.

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

-In order to make sure users are getting access to the right access packages, you can require requestors to answer custom text field or Multiple Choice questions at the time of request. There's a limit of 20 questions per policy and a limit of 25 answers for Multiple Choice questions. The questions will then be shown to approvers to help them make a decision.

-To create a policy for an access package, you need to start from the access package's policy tab. Follow these steps to create a new policy for an access package.

-1. Click **Save** to close the dynamic membership rule editor, then click **Next** to open the **Custom Extensions** tab.

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

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

-1. Type in **Identity Governance** on the search bar near the top of the page and select it.

-1. On the left menu, select **Lifecycle workflows**.

-1. On the left menu, select **Workflows**.

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

-1. Type in **Identity Governance** on the search bar near the top of the page and select it.

-1. In the left menu, select **Lifecycle workflows**.

-1. In the left menu, select **workflows**.

-1. On the left side of the screen, select **Tasks**.

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

-1. Type in **Identity Governance** on the search bar near the top of the page and select it.

-1. On the left menu, select **Lifecycle workflows**.

-1. select **Workflows**

-Customers who have yet to transition from applications such as SAP ERP Central Component (SAP ECC) to SAP S/4HANA can still rely on the Azure AD provisioning service to provision user accounts. Within SAP ECC, you expose the necessary Business Application Programming Interfaces (BAPIs) for creating, updating, and deleting users. Within Azure AD, you have two options:

-* Use the lightweight Azure AD provisioning agent and [web services connector](/azure/active-directory/app-provisioning/on-premises-web-services-connector) to [provision users into apps such as SAP ECC](/azure/active-directory/app-provisioning/on-premises-sap-connector-configure?branch=pr-en-us-243167).

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

-1. Select **Azure Active Directory** and then select **Identity Governance**.

-1. In the left menu, select **Lifecycle Workflows**.

-description: Learn how to remove users from an organization in real time on their last day of work by using lifecycle workflows in the Azure portal.

-This tutorial provides a step-by-step guide on how to execute a real-time employee termination by using lifecycle workflows in the Azure portal.

-Use the following steps to create a leaver on-demand workflow that will execute a real-time employee termination by using lifecycle workflows in the Azure portal:

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

-2. On the right, select **Azure Active Directory**.

-3. Select **Identity Governance**.

-4. Select **Lifecycle workflows**.

-5. On the **Overview** tab, select **New workflow**.

-6. From the collection of templates, choose **Select** under **Real-time employee termination**.

-7. Configure basic information about the workflow, and then select **Next: Review tasks**.

-8. Inspect the tasks if you want, but no additional configuration is needed. Select **Next: Select users** when you're finished.

-9. Choose the **Select users to run now** option. It allows you to select users for which the workflow will be executed immediately after creation. Regardless of the selection, you can run the workflow on demand later at any time, as needed.

-10. Select **Add users** to designate the users for this workflow.

-11. A panel with the list of available users appears on the right side of the window. Choose **Select** when you're done with your selection.

-12. Select **Next: Review and create** when you're satisfied with your selection of users.

-13. Verify that the information is correct, and then select **Create**.

-To run a workflow on demand for users by using the Azure portal:

-description: Tutorial for onboarding users to an organization using Lifecycle workflows with Azure portal.

-# Automate employee onboarding tasks before their first day of work with Azure portal

-This tutorial provides a step-by-step guide on how to automate prehire tasks with Lifecycle workflows using the Azure portal.

- - **Prerequisite:** Editing the attributes required for this scenario in the portal

-Use the following steps to create a pre-hire workflow that generates a TAP and send it via email to the user's manager using the Azure portal.

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

-2. On the right, select **Azure Active Directory**.

-3. Select **Identity Governance**.

-4. Select **Lifecycle workflows**.

-5. On the **Overview** page, select **New workflow**.

-6. From the templates, select **select** under **Onboard pre-hire employee**.

-7. Next, you configure the basic information about the workflow. This information includes when the workflow triggers, known as **Days from event**. So in this case, the workflow triggers two days before the employee's hire date. On the onboard pre-hire employee screen, add the following settings and then select **Next: Configure Scope**.

-8. Next, you configure the scope. The scope determines which users this workflow runs against. In this case, it is on all users in the Sales department. On the configure scope screen, under **Rule** add the following settings and then select **Next: Review tasks**. For a full list of supported user properties, see [Supported user properties and query parameters](/graph/api/resources/identitygovernance-rulebasedsubjectset?view=graph-rest-beta&preserve-view=true#supported-user-properties-and-query-parameters).

-9. On the following page, you may inspect the task if desired but no additional configuration is needed. Select **Next: Review + Create** when you're finished.

-10. On the review blade, verify the information is correct and select **Create**.

-To run a workflow on-demand, for users using the Azure portal, do the following steps:

-description: Tutorial for post off-boarding users from an organization using Lifecycle workflows with Azure portal.

-# Automate employee offboarding tasks after their last day of work with Azure portal

-This tutorial provides a step-by-step guide on how to configure off-boarding tasks for employees after their last day of work with Lifecycle workflows using the Azure portal.

-Use the following steps to create a scheduled leaver workflow that will configure off-boarding tasks for employees after their last day of work with Lifecycle workflows using the Azure portal.

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

- 2. On the right, select **Azure Active Directory**.

- 3. Select **Identity Governance**.

- 4. Select **Lifecycle workflows**.

- 5. On the **Overview** page, select **New workflow**.

- 6. From the templates, select **Select** under **Post-offboarding of an employee**.

- 7. Next, you'll configure the basic information about the workflow. This information includes when the workflow triggers, known as **Days from event**. So in this case, the workflow will trigger seven days after the employee's leave date. On the post-offboarding of an employee screen, add the following settings and then select **Next: Configure Scope**.

- 8. Next, you'll configure the scope. The scope determines which users this workflow runs against. In this case, it is on all users in the Marketing department. On the configure scope screen, under **Rule** add the following and then select **Next: Review tasks**. For a full list of supported user properties, see [Supported user properties and query parameters](/graph/api/resources/identitygovernance-rulebasedsubjectset?view=graph-rest-beta&preserve-view=true#supported-user-properties-and-query-parameters)

- 9. On the following page, you may inspect the tasks if desired but no additional configuration is needed. Select **Next: Select users** when you're finished.

-10. On the review blade, verify the information is correct and select **Create**.

-To run a workflow on-demand, for users using the Azure portal, do the following steps:

-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

-If password reset isn't an option for you from the Azure portal, you can choose to manually dismiss user risk. Dismissing user risk doesn't have any impact on the user's existing password, but this process will change the user's Risk State from At Risk to Dismissed. It's important that you change the user's password using whatever means are available to you in order to bring the identity back to a safe state.

-description: Learn how the Security overview gives you an insight into your organizationΓÇÖs security posture.

-The [Security overview](https://aka.ms/IdentityProtectionRefresh) in the Azure portal gives you an insight into your organizationΓÇÖs security posture. It helps identify potential attacks and understand the effectiveness of your policies.

-You can find the security overview page in the **Azure portal** > **Azure Active Directory** > **Security** > **Identity Protection** > **Overview**.

-## Trends

-### New risky users detected

-This chart shows the number of new risky users that were detected over the chosen time period. You can filter the view of this chart by user risk level (low, medium, high). Hover over the UTC date increments to see the number of risky users detected for that day. Selecting this chart will bring you to the ΓÇÿRisky usersΓÇÖ report. To remediate users that are at risk, consider changing their password.

-### New risky sign-ins detected

-This chart shows the number of risky sign-ins detected over the chosen time period. You can filter the view of this chart by the sign-in risk type (real-time or aggregate) and the sign-in risk level (low, medium, high). Unprotected sign-ins are successful real-time risk sign-ins that weren't MFA challenged. (Note: Sign-ins that are risky because of offline detections can't be protected in real-time by sign-in risk policies). Hover over the UTC date increments to see the number of sign-ins detected at risk for that day. Selecting this chart will bring you to the ΓÇÿRisky sign-insΓÇÖ report.

-## Tiles

-

-### High risk users

-The ΓÇÿHigh risk usersΓÇÖ tile shows the latest count of users with high probability of identity compromise. These users should be a top priority for investigation. Selecting the ΓÇÿHigh risk usersΓÇÖ tile will redirect to a filtered view of the ΓÇÿRisky usersΓÇÖ report showing only users with a risk level of high. Using this report, you can learn more and remediate these users with a password reset.

-### Medium risk users

-The ΓÇÿMedium risk usersΓÇÖ tile shows the latest count of users with medium probability of identity compromise. Selecting the ΓÇÿMedium risk usersΓÇÖ tile will take you to a view of the ΓÇÿRisky usersΓÇÖ report showing only users with a risk level of medium. Using this report, you can further investigate and remediate these users.

-### Unprotected risky sign-ins

-The ΓÇÿUnprotected risky sign-ins' tile shows the last weekΓÇÖs count of successful, real-time risky sign-ins that weren't blocked or MFA challenged by a Conditional Access policy, Identity Protection risk policy, or per-user MFA. These successful sign-ins are potentially compromised and not challenged for MFA. To protect such sign-ins in future, apply a sign-in risk policy. Selecting the ΓÇÿUnprotected risky sign-ins' tile will take you to the sign-in risk policy configuration blade where you can configure the sign-in risk policy.

-### Legacy authentication

-The ΓÇÿLegacy authenticationΓÇÖ tile shows the last weekΓÇÖs count of legacy authentications with risk present in your organization. Legacy authentication protocols don't support modern security methods such as an MFA. To prevent legacy authentication, you can apply a Conditional Access policy. Selecting the ΓÇÿLegacy authenticationΓÇÖ tile will redirect you to the ΓÇÿIdentity Secure ScoreΓÇÖ.

-### Identity Secure Score

-The Identity Secure Score measures and compares your security posture to industry patterns. If you select the **Identity Secure Score** tile, it will redirect to [Identity Secure Score](../fundamentals/identity-secure-score.md) where you can learn more about improving your security posture.

- - Global Administrator

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

-1. Browse to **Azure Active Directory** > **Security** > **Risky workload identities**.

-1. Or browse to **Azure Active Directory** > **Security** > **Risk detections**.

- 1. Select the **Workload identity detections** tab.'

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

-Organizations can choose to store data for longer periods by changing diagnostic settings in Azure AD to send **RiskyUsers**, **UserRiskEvents**, **RiskyServicePrincipals**, and **ServicePrincipalRiskEvents** data to a Log Analytics workspace, archive data to a storage account, stream data to an event hub, or send data to a partner solution. Find these options in the **Azure portal** > **Azure Active Directory**, **Diagnostic settings** > **Edit setting**. If you don't have a diagnostic setting, follow the instructions in the article [Create diagnostic settings to send platform logs and metrics to different destinations](../../azure-monitor/essentials/diagnostic-settings.md) to create one.

-Once enabled you'll find access to Log Analytics in the **Azure portal** > **Azure AD** > **Log Analytics**. The following tables are of most interest to Identity Protection administrators:

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

-1. Browse to **Azure Active Directory** > **Security** > **Identity Protection** > **MFA registration policy**.

- - Optionally you can **Add custom email here** users defined must have the appropriate permissions to view the linked reports in the Azure portal.

-Configure the users at risk email in the **Azure portal** under **Azure Active Directory** > **Security** > **Identity Protection** > **Users at risk detected alerts**.

-Configure the weekly digest email in the **Azure portal** under **Azure Active Directory** > **Security** > **Identity Protection** > **Weekly digest**.

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

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

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

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

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

- 1. Browse to **Azure Active Directory** > **Identity Protection** > Select the **User risk** or **Sign-in risk** policy.

-All three reports allow for downloading of events in .CSV format for further analysis outside of the Azure portal. The risky users and risky sign-ins reports allow for downloading the most recent 2500 entries, while the risk detections report allows for downloading the most recent 5000 records.

-The three reports are found in the **Azure portal** > **Azure Active Directory** > **Security**.

-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. Browse to **Azure Active Directory** > **Security** > **Identity Protection** > **Overview**.

-1. Select **Configure user risk policy**.

- 1. Under **Assignments**

- 1. **Users** - Choose **All users** or **Select individuals and groups** if limiting your rollout.

- 1. Optionally you can choose to exclude users from the policy.

- 1. **Conditions** - **User risk** Microsoft's recommendation is to set this option to **High**.

- 1. Under **Controls**

- 1. **Access** - Microsoft's recommendation is to **Allow access** and **Require password change**.

- 1. **Enforce Policy** - **Off**

- 1. **Save** - This action will return you to the **Overview** page.

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

-1. Browse to **Azure Active Directory** > **Security** > **Identity Protection** > **Overview**.

-1. Select **Configure sign-in risk policy**.

- 1. Under **Assignments**

- 1. **Users** - Choose **All users** or **Select individuals and groups** if limiting your rollout.

- 1. Optionally you can choose to exclude users from the policy.

- 1. **Conditions** - **Sign-in risk** Microsoft's recommendation is to set this option to **Medium and above**.

- 1. Under **Controls**

- 1. **Access** - Microsoft's recommendation is to **Allow access** and **Require multifactor authentication**.

- 1. **Enforce Policy** - **On**

- 1. **Save** - This action will return you to the **Overview** page.

-1. Browse to **Identity** > **Protection** > **Identity Protection** > **Dashboard (Preview)**.

-> See the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

-> [!WARNING]

-> Deleted app consent policies cannot be restored. If you accidentally delete a custom app consent policy, you will need to re-create the policy.

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

-description: Learn about multi-tenant organizations in Azure Active Directory.

-# What is a multi-tenant organization in Azure Active Directory?

-This article provides an overview of multi-tenant organizations.

-A *tenant* is an instance of Azure Active Directory (Azure AD) in which information about a single organization resides including organizational objects such as users, groups, and devices and also application registrations, such as Microsoft 365 and third-party applications. A tenant also contains access and compliance policies for resources, such as applications registered in the directory. The primary functions served by a tenant include identity authentication as well as resource access management.

-## B2B direct connect

-To enable users across tenants to collaborate in [Teams Connect shared channels](/microsoftteams/platform/concepts/build-and-test/shared-channels), you can use [Azure AD B2B direct connect](../external-identities/b2b-direct-connect-overview.md). B2B direct connect is a feature of External Identities that lets you set up a mutual trust relationship with another Azure AD organization for seamless collaboration in Teams. When the trust is established, the B2B direct connect user has single sign-on access using credentials from their home tenant.

-Here's the primary constraint with using B2B direct connect across multiple tenants:

-Depending on the needs of your organization, you can use any combination of cross-tenant synchronization, B2B collaboration, and B2B direct connect. The following table compares the capabilities of each feature. For more information about different external identity scenarios, see [Comparing External Identities feature sets](../external-identities/external-identities-overview.md#comparing-external-identities-feature-sets).

-| | Cross-tenant synchronization<br/>(internal) | B2B collaboration<br/>(Org-to-org external) | B2B direct connect<br/>(Org-to-org external) |

-| | | | |

-| **Purpose** | Users can seamlessly access apps/resources across the same organization, even if they're hosted in different tenants. | Users can access apps/resources hosted in external tenants, usually with limited guest privileges. Depending on automatic redemption settings, users might need to accept a consent prompt in each tenant. | Users can access Teams Connect shared channels hosted in external tenants. |

-| **Value** | Enables collaboration across organizational tenants. Administrators don't have to manually invite and synchronize users between tenants to ensure continuous access to apps/resources within the organization. | Enables external collaboration. More control and monitoring for administrators by managing the B2B collaboration users. Administrators can limit the access that these external users have to their apps/resources. | Enables external collaboration within Teams Connect shared channels only. More convenient for administrators because they don't have to manage B2B users. |

-| **Primary administrator workflow** | Configure the cross-tenant synchronization engine to synchronize users between multiple tenants as B2B collaboration users. | Add external users to resource tenant by using the B2B invitation process or build your own onboarding experience using the [B2B collaboration invitation manager](../external-identities/external-identities-overview.md#azure-ad-microsoft-graph-api-for-b2b-collaboration). | Configure cross-tenant access to provide external users inbound access to tenant the credentials for their home tenant. |

-| **Trust level** | High trust. All tenants are part of the same organization, and users are typically granted member access to all apps/resources. | Low to mid trust. User objects can be tracked easily and managed with granular controls. | Mid trust. B2B direct connect users are less easy to track, mandating a certain level of trust with the external organization. |

-| **Effect on users** | Within the same organization, users are synchronized from their home tenant to the resource tenant as B2B collaboration users. | External users are added to a tenant as B2B collaboration users. | Users access the resource tenant using the credentials for their home tenant. User objects aren't created in the resource tenant. |

-| **User type** | B2B collaboration user<br/>- External member (default)<br/>- External guest | B2B collaboration user<br/>- External member<br/>- External guest (default) | B2B direct connect user<br/>- N/A |

-The following diagram shows how cross-tenant synchronization, B2B collaboration, and B2B direct connect could be used together.

-To better understand multi-tenant organizations, you can refer back to the following list of terms.

-| multi-tenant organization | An organization that has more than one instance of Azure AD. |

-| cross-tenant access settings | Settings to manage collaboration with external Azure AD organizations. |

-> - 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: Conceptual information about sign-in logs, including new features in preview.

-# Sign-in logs in Azure Active Directory (preview)

-Reviewing sign-in errors and patterns provides valuable insight into how your users access applications and services. The sign-in logs provided by Azure Active Directory (Azure AD) are a powerful type of [activity log](overview-reports.md) that IT administrators can analyze. This article explains how to access and utilize the sign-in logs.

-Two other activity logs are also available to help monitor the health of your tenant:

-The classic sign-in logs in Azure AD provide you with an overview of interactive user sign-ins. Three more sign-in logs are now in preview:

-This article gives you an overview of the sign-in activity report with the preview of non-interactive, application, and managed identities for Azure resources sign-ins. For information about the sign-in report without the preview features, see [Sign-in logs in Azure Active Directory](concept-sign-ins.md).

-## How do you access the sign-in logs?

-You can always access your own sign-ins history at [https://mysignins.microsoft.com](https://mysignins.microsoft.com).

-To access the sign-ins log for a tenant, you must have one of the following roles:

->[!NOTE]

->To see Conditional Access data in the sign-ins log, you need to be a user in one of the following roles:

-Company Administrator, Global Reader, Security Administrator, Security Reader, Conditional Access Administrator .

-The sign-in activity report is available in [all editions of Azure AD](reference-reports-data-retention.md#how-long-does-azure-ad-store-the-data). If you have an Azure Active Directory P1 or P2 license, you can access the sign-in activity report through the Microsoft Graph API. See [Getting started with Azure Active Directory Premium](../fundamentals/get-started-premium.md) to upgrade your Azure Active Directory edition. It will take a couple of days for the data to show up in Graph after you upgrade to a premium license with no data activities before the upgrade.

-**To access the Azure AD sign-ins log preview:**

-1. Sign in to the [Azure portal](https://portal.azure.com) using the appropriate least privileged role.

-1. Go to **Azure Active Directory** > **Sign-ins log**.

-1. Select the **Try out our new sign-ins preview** link.

- 

- To toggle back to the legacy view, select the **Click here to leave the preview** link.

- 

-You can also access the sign-in logs from the following areas of Azure AD:

-On the sign-in logs page, you can switch between:

-

-## View the sign-ins log

-To more effectively view the sign-ins log, spend a few moments customizing the view for your needs. You can specify what columns to include and filter the data to narrow things down.

-### Interactive user sign-ins

-Interactive user sign-ins provide an authentication factor to Azure AD or interact directly with Azure AD or a helper app, such as the Microsoft Authenticator app. Users can provide passwords, responses to MFA challenges, biometric factors, or QR codes to Azure AD or to a helper app. This log also includes federated sign-ins from identity providers that are federated to Azure AD.

-> [!NOTE]

-> The interactive user sign-in log previously contained some non-interactive sign-ins from Microsoft Exchange clients. Although those sign-ins were non-interactive, they were included in the interactive user sign-in log for additional visibility. Once the non-interactive user sign-in log entered public preview in November 2020, those non-interactive sign-in logs were moved to the non-interactive user sign in log for increased accuracy.

-**Report size:** small </br>

-**Examples:**

-In addition to the default fields, the interactive sign-in log also shows:

-You can customize the list view by clicking **Columns** in the toolbar.

-

-#### Considerations for MFA sign-ins

-When a user signs in with MFA, several separate MFA events are actually taking place. For example, if a user enters the wrong validation code or doesn't respond in time, additional MFA events are sent to reflect the latest status of the sign-in attempt. These sign-in events appear as one line item in the Azure AD sign-in logs. That same sign-in event in Azure Monitor, however, appears as multiple line items. These events all have the same `correlationId`.

-### Non-interactive user sign-ins

-Like interactive user sign-ins, non-interactive sign-ins are done on behalf of a user. These sign-ins were performed by a client app or OS components on behalf of a user and don't require the user to provide an authentication factor. Instead, the device or client app uses a token or code to authenticate or access a resource on behalf of a user. In general, the user perceives these sign-ins as happening in the background.

-**Report size:** Large </br>

-**Examples:**

-In addition to the default fields, the non-interactive sign-in log also shows:

-You can't customize the fields shown in this report.

-

-To make it easier to digest the data, non-interactive sign-in events are grouped. Clients often create many non-interactive sign-ins on behalf of the same user in a short time period. The non-interactive sign-ins share the same characteristics except for the time the sign-in was attempted. For example, a client may get an access token once per hour on behalf of a user. If the state of the user or client doesn't change, the IP address, resource, and all other information is the same for each access token request. The only state that does change is the date and time of the sign-in.

-When Azure AD logs multiple sign-ins that are identical other than time and date, those sign-ins are from the same entity and are aggregated into a single row. A row with multiple identical sign-ins (except for date and time issued) have a value greater than 1 in the *# sign-ins* column. These aggregated sign-ins may also appear to have the same time stamps. The **Time aggregate** filter can set to 1 hour, 6 hours, or 24 hours. You can expand the row to see all the different sign-ins and their different time stamps.

-Sign-ins are aggregated in the non-interactive users when the following data matches:

-> [!NOTE]

-> The IP address of non-interactive sign-ins performed by [confidential clients](../develop/msal-client-applications.md) doesn't match the actual source IP of where the refresh token request is coming from. Instead, it shows the original IP used for the original token issuance.

-### Service principal sign-ins

-Unlike interactive and non-interactive user sign-ins, service principal sign-ins don't involve a user. Instead, they're sign-ins by any nonuser account, such as apps or service principals (except managed identity sign-in, which are in included only in the managed identity sign-in log). In these sign-ins, the app or service provides its own credential, such as a certificate or app secret to authenticate or access resources.

-**Report size:** Large </br>

-**Examples:**

-You can't customize the fields shown in this report.

-To make it easier to digest the data in the service principal sign-in logs, service principal sign-in events are grouped. Sign-ins from the same entity under the same conditions are aggregated into a single row. You can expand the row to see all the different sign-ins and their different time stamps. Sign-ins are aggregated in the service principal report when the following data matches:

-### Managed identity for Azure resources sign-ins

-Managed identities for Azure resources sign-ins are sign-ins that were performed by resources that have their secrets managed by Azure to simplify credential management. A VM with managed credentials uses Azure AD to get an Access Token.

-**Report size:** Small </br>

-**Examples:**

- You can't customize the fields shown in this report.

-To make it easier to digest the data, managed identities for Azure resources sign in logs, non-interactive sign-in events are grouped. Sign-ins from the same entity are aggregated into a single row. You can expand the row to see all the different sign-ins and their different time stamps. Sign-ins are aggregated in the managed identities report when all of the following data matches:

-Select an item in the list view to display all sign-ins that are grouped under a node. Select a grouped item to see all details of the sign-in.

-### Filter the results

-Filtering the sign-ins log is a helpful way to quickly find logs that match a specific scenario. For example, you could filter the list to only view sign-ins that occurred in a specific geographic location, from a specific operating system, or from a specific type of credential.

-Some filter options prompt you to select more options. Follow the prompts to make the selection you need for the filter. You can add multiple filters. Take note of the **Date** range in your filter to ensure that Azure AD only returns the data you need. The filter you configure for interactive sign-ins is persisted for non-interactive sign-ins and vice versa.

-Select the **Add filters** option from the top of the table to get started.

-

-There are several filter options to choose from:

- - *Not applied:* No policy applied to the user and application during sign-in.

- - *Success:* One or more Conditional Access policies applied to the user and application (but not necessarily the other conditions) during sign-in.

- - *Failure:* The sign-in satisfied the user and application condition of at least one Conditional Access policy and grant controls are either not satisfied or set to block access.

-The following table provides the options and descriptions for the **Client app** filter option.

-> [!NOTE]

-> Due to privacy commitments, Azure AD does not populate this field to the home tenant in the case of a cross-tenant scenario.

-|Name|Modern authentication|Description|

-||:-:||

-|Authenticated SMTP| |Used by POP and IMAP client's to send email messages.|

-|Autodiscover| |Used by Outlook and EAS clients to find and connect to mailboxes in Exchange Online.|

-|Exchange ActiveSync| |This filter shows all sign-in attempts where the EAS protocol has been attempted.|

-|Browser||Shows all sign-in attempts from users using web browsers|

-|Exchange ActiveSync| | Shows all sign-in attempts from users with client apps using Exchange ActiveSync to connect to Exchange Online|

-|Exchange Online PowerShell| |Used to connect to Exchange Online with remote PowerShell. If you block basic authentication for Exchange Online PowerShell, you need to use the Exchange Online PowerShell module to connect. For instructions, see [Connect to Exchange Online PowerShell using multi-factor authentication](/powershell/exchange/exchange-online/connect-to-exchange-online-powershell/mfa-connect-to-exchange-online-powershell).|

-|Exchange Web Services| |A programming interface that's used by Outlook, Outlook for Mac, and third-party apps.|

-|IMAP4| |A legacy mail client using IMAP to retrieve email.|

-|MAPI over HTTP| |Used by Outlook 2010 and later.|

-|Mobile apps and desktop clients||Shows all sign-in attempts from users using mobile apps and desktop clients.|

-|Offline Address Book| |A copy of address list collections that are downloaded and used by Outlook.|

-|Outlook Anywhere (RPC over HTTP)| |Used by Outlook 2016 and earlier.|

-|Outlook Service| |Used by the Mail and Calendar app for Windows 10.|

-|POP3| |A legacy mail client using POP3 to retrieve email.|

-|Reporting Web Services| |Used to retrieve report data in Exchange Online.|

-|Other clients| |Shows all sign-in attempts from users where the client app isn't included or unknown.|

-## Analyze the sign-in logs

-Now that your sign-in logs table is formatted appropriately, you can more effectively analyze the data. Some common scenarios are described here, but they aren't the only ways to analyze sign-in data. Further analysis and retention of sign-in data can be accomplished by exporting the logs to other tools.

-### Sign-in error code

-If a sign-in failed, you can get more information about the reason in the **Basic info** section of the related log item. The error code and associated failure reason appear in the details. Because of the complexity of some Azure AD environments, we can't document every possible error code and resolution. Some errors may require [submitting a support request](../fundamentals/how-to-get-support.md) to resolve the issue.

-

-

-For a list of error codes related to Azure AD authentication and authorization, see the [Azure AD authentication and authorization error codes](../develop/reference-error-codes.md) article. In some cases, the [sign-in error lookup tool](https://login.microsoftonline.com/error) may provide remediation steps. Enter the **Error code** provided in the sign-in log details into the tool and select the **Submit** button.

-

-### Authentication details

-The **Authentication Details** tab in the details of a sign-in log provides the following information for each authentication attempt:

-This information allows you to troubleshoot each step in a userΓÇÖs sign-in. Use these details to track:

-While viewing the sign-ins log, select a sign-in event, and then select the **Authentication Details** tab.

-

-When analyzing authentication details, take note of the following details:

- - A **satisfied by claim in the token** message is incorrectly displayed when sign-in events are initially logged.

- - The **Primary authentication** row isn't initially logged.

-## Sign-in data used by other services

-Sign-in data is used by several services in Azure to monitor risky sign-ins and provide insight into application usage.

-### Risky sign-in data in Azure AD Identity Protection

-Sign-in log data visualization that relates to risky sign-ins is available in the **Azure AD Identity Protection** overview, which uses the following data:

-For more information about the Azure AD Identity Protection tools, see the [Azure AD Identity Protection overview](../identity-protection/overview-identity-protection.md).

-

-### Azure AD application and authentication sign-in activity

-With an application-centric view of your sign-in data, you can answer questions such as:

-To view application-specific sign-in data, go to **Azure AD** and select **Usage & insights** from the Monitoring section. These reports provide a closer look at sign-ins for Azure AD application activity and AD FS application activity. For more information, see [Azure AD Usage & insights](concept-usage-insights-report.md).

-

-Azure AD Usage & insights also provides the **Authentication methods activity** report, which breaks down authentication by the method used. Use this report to see how many of your users are set up with MFA or passwordless authentication.

-

-### Microsoft 365 activity logs

-You can view Microsoft 365 activity logs from the [Microsoft 365 admin center](/office365/admin/admin-overview/about-the-admin-center). Microsoft 365 activity and Azure AD activity logs share a significant number of directory resources. Only the Microsoft 365 admin center provides a full view of the Microsoft 365 activity logs.

-You can also access the Microsoft 365 activity logs programmatically by using the [Office 365 Management APIs](/office/office-365-management-api/office-365-management-apis-overview).

-## Next steps

-description: Overview of the audit logs in Azure Active Directory.

-## What is it?

-Audit logs in Azure AD provide access to system activity records, often needed for compliance. This log is categorized by user, group, and application management.

-With a user-centric view, you can get answers to questions such as:

-With a group-centric view, you can get answers to questions such as:

-With an application-centric view, you can get answers to questions such as:

-## How do I access it?

-To access the audit log for a tenant, you must have one of the following roles:

-Sign in to the [Azure portal](https://portal.azure.com) and go to **Azure AD** and select **Audit log** from the **Monitoring** section.

-The audit activity report is available in [all editions of Azure AD](reference-reports-data-retention.md#how-long-does-azure-ad-store-the-data). If you have an Azure Active Directory P1 or P2 license, you can access the audit log through the [Microsoft Graph API](/graph/api/resources/azure-ad-auditlog-overview). See [Getting started with Azure Active Directory Premium](../fundamentals/get-started-premium.md) to upgrade your Azure Active Directory edition. It will take a couple of days for the data to show up in Graph after you upgrade to a premium license with no data activities before the upgrade.

-

-description: Overview of the provisioning logs in Azure Active Directory.

-To access the provisioning log data, you have the following options:

-When you filter your provisioning data, some filter values are dynamically populated based on your tenant. For example, if you don't have any "create" events in your tenant, there won't be a **Create** filter option.

-You can download the provisioning logs for later use by going to the logs in the Azure portal and selecting **Download**. The file will be filtered based on the filter criteria you've selected. Make the filters as specific as possible to reduce the size and time of the download.

-|TooManyRequests|The target app rejected this attempt to update the user because it's overloaded and receiving too many requests. There's nothing to do. This attempt will automatically be retired. Microsoft has also been notified of this issue.|

-|InternalServerError |The target app returned an unexpected error. A service issue with the target application might be preventing it from working. This attempt will automatically be retried in 40 minutes.|

-|WebExceptionProtocolError |An HTTP protocol error occurred in connecting to the target application. There's nothing to do. This attempt will automatically be retried in 40 minutes.|

-|InvalidAnchor|A user that was previously created or matched by the provisioning service no longer exists. Ensure that the user exists. To force a new matching of all users, use the Microsoft Graph API to [restart the job](/graph/api/synchronization-synchronizationjob-restart?tabs=http&view=graph-rest-beta&preserve-view=true). <br><br>Restarting provisioning will trigger an initial cycle, which can take time to complete. Restarting provisioning also deletes the cache that the provisioning service uses to operate. That means all users and groups in the tenant will have to be evaluated again, and certain provisioning events might be dropped.|

-|InternalError |An internal service error occurred within the Azure AD provisioning service. There's nothing to do. This attempt will automatically be retried in 40 minutes.|

-|Timeout |The operation couldn't be completed because the target application took too long to respond. There's nothing to do. This attempt will automatically be retried in 40 minutes.|

-|SystemForCrossDomainIdentity<br>ManagementMultipleEntriesInResponse| A GET request to retrieve a user or group received multiple users or groups in the response. The system expects to receive only one user or group in the response. For example, if you do a [GET Group request](../app-provisioning/use-scim-to-provision-users-and-groups.md#get-group) to retrieve a group, provide a filter to exclude members, and your System for Cross-Domain Identity Management (SCIM) endpoint returns the members, you'll get this error.|

-description: Conceptual information about Azure AD sign-in logs.

-# Sign-in logs in Azure Active Directory

-Reviewing sign-in errors and patterns provides valuable insight into how your users access applications and services. The sign-in logs provided by Azure Active Directory (Azure AD) are a powerful type of [activity log](overview-reports.md) that IT administrators can analyze. This article explains how to access and utilize the sign-in logs.

-You can use the sign-ins log to find answers to questions like:

-## How do you access the sign-in logs?

-You can always access your own sign-ins history at [https://mysignins.microsoft.com](https://mysignins.microsoft.com).

-To access the sign-ins log for a tenant, you must have one of the following roles:

-The sign-in activity report is available in [all editions of Azure AD](reference-reports-data-retention.md#how-long-does-azure-ad-store-the-data). If you have an Azure Active Directory P1 or P2 license, you can access the sign-in activity report through the Microsoft Graph API. See [Getting started with Azure Active Directory Premium](../fundamentals/get-started-premium.md) to upgrade your Azure Active Directory edition. It will take a couple of days for the data to show up in Graph after you upgrade to a premium license with no data activities before the upgrade.

-**To access the Azure AD sign-ins log:**

-1. Sign in to the [Azure portal](https://portal.azure.com) using the appropriate least privileged role.

-1. Go to **Azure Active Directory** > **Sign-ins log**.

- 

-You can also access the sign-in logs from the following areas of Azure AD:

-## View the sign-ins log

-To more effectively view the sign-ins log, spend a few moments customizing the view for your needs. You can specify what columns to include and filter the data to narrow things down.

-### Customize the layout

-The sign-ins log has a default view, but you can customize the view using over 30 column options.

-1. Select **Columns** from the menu at the top of the log.

-1. Select the columns you want to view and select the **Save** button at the bottom of the window.

-

-### Filter the results <h3 id="filter-sign-in-activities"></h3>

-Filtering the sign-ins log is a helpful way to quickly find logs that match a specific scenario. For example, you could filter the list to only view sign-ins that occurred in a specific geographic location, from a specific operating system, or from a specific type of credential.

-Some filter options prompt you to select more options. Follow the prompts to make the selection you need for the filter. You can add multiple filters.

-Select the **Add filters** option from the top of the table to get started.

-

-There are several filter options to choose from:

- - *Not applied:* No policy applied to the user and application during sign-in.

- - *Success:* One or more Conditional Access policies applied to or were evaluated for the user and application (but not necessarily the other conditions) during sign-in. Even though a Conditional Access policy might not apply, if it was evaluated, the Conditional Access status will show 'Success'.

- - *Failure:* The sign-in satisfied the user and application condition of at least one Conditional Access policy and grant controls are either not satisfied or set to block access.

-The following table provides the options and descriptions for the **Client app** filter option.

-> [!NOTE]

-> Due to privacy commitments, Azure AD does not populate this field to the home tenant in the case of a cross-tenant scenario.

-|Name|Modern authentication|Description|

-||:-:||

-|Authenticated SMTP| |Used by POP and IMAP client's to send email messages.|

-|Autodiscover| |Used by Outlook and EAS clients to find and connect to mailboxes in Exchange Online.|

-|Exchange ActiveSync| |This filter shows all sign-in attempts where the EAS protocol has been attempted.|

-|Browser||Shows all sign-in attempts from users using web browsers|

-|Exchange ActiveSync| | Shows all sign-in attempts from users with client apps using Exchange ActiveSync to connect to Exchange Online|

-|Exchange Online PowerShell| |Used to connect to Exchange Online with remote PowerShell. If you block basic authentication for Exchange Online PowerShell, you need to use the Exchange Online PowerShell module to connect. For instructions, see [Connect to Exchange Online PowerShell using multi-factor authentication](/powershell/exchange/exchange-online/connect-to-exchange-online-powershell/mfa-connect-to-exchange-online-powershell).|

-|Exchange Web Services| |A programming interface that's used by Outlook, Outlook for Mac, and third-party apps.|

-|IMAP4| |A legacy mail client using IMAP to retrieve email.|

-|MAPI over HTTP| |Used by Outlook 2010 and later.|

-|Mobile apps and desktop clients||Shows all sign-in attempts from users using mobile apps and desktop clients.|

-|Offline Address Book| |A copy of address list collections that are downloaded and used by Outlook.|

-|Outlook Anywhere (RPC over HTTP)| |Used by Outlook 2016 and earlier.|

-|Outlook Service| |Used by the Mail and Calendar app for Windows 10.|

-|POP3| |A legacy mail client using POP3 to retrieve email.|

-|Reporting Web Services| |Used to retrieve report data in Exchange Online.|

-|Other clients| |Shows all sign-in attempts from users where the client app isn't included or unknown.|

-## Analyze the sign-in logs

-Now that your sign-in logs table is formatted appropriately, you can more effectively analyze the data. Some common scenarios are described here, but they aren't the only ways to analyze sign-in data. Further analysis and retention of sign-in data can be accomplished by exporting the logs to other tools.

-### Sign-in error codes

-If a sign-in failed, you can get more information about the reason in the **Basic info** section of the related log item. The error code and associated failure reason appear in the details. Because of the complexity of some Azure AD environments, we can't document every possible error code and resolution. Some errors may require [submitting a support request](../fundamentals/how-to-get-support.md) to resolve the issue.

-

-For a list of error codes related to Azure AD authentication and authorization, see the [Azure AD authentication and authorization error codes](../develop/reference-error-codes.md) article. In some cases, the [sign-in error lookup tool](https://login.microsoftonline.com/error) may provide remediation steps. Enter the **Error code** provided in the sign-in log details into the tool and select the **Submit** button.

-

-### Authentication details

-The **Authentication Details** tab in the details of a sign-in log provides the following information for each authentication attempt:

-This information allows you to troubleshoot each step in a userΓÇÖs sign-in. Use these details to track:

-While viewing the sign-ins log, select a sign-in event, and then select the **Authentication Details** tab.

-

-When analyzing authentication details, take note of the following details:

- - A **satisfied by claim in the token** message is incorrectly displayed when sign-in events are initially logged.

- - The **Primary authentication** row isn't initially logged.

-#### Considerations for MFA sign-ins

-When a user signs in with MFA, several separate MFA events are actually taking place. For example, if a user enters the wrong validation code or doesn't respond in time, additional MFA events are sent to reflect the latest status of the sign-in attempt. These sign-in events appear as one line item in the Azure AD sign-in logs. That same sign-in event in Azure Monitor, however, appears as multiple line items. These events all have the same `correlationId`.

-Sign-in data is used by several services in Azure to monitor risky sign-ins and provide insight into application usage.

-### Risky sign-in data in Azure AD Identity Protection

- For more information about the Azure AD Identity Protection tools, see the [Azure AD Identity Protection overview](../identity-protection/overview-identity-protection.md).

-

-### Azure AD application and authentication sign-in activity

-

-Azure AD Usage & insights also provides the **Authentication methods activity** report, which breaks down authentication by the method used. Use this report to see how many of your users are set up with MFA or passwordless authentication.

-

-1. Go to **Azure Active Directory** > **Usage & insights**.

-The **AD FS application activity** report in Usage & insights lists all Active Directory Federated Services (AD FS) applications in your organization that have had an active user login to authenticate in the last 30 days. These applications have not been migrated to Azure AD for authentication.

-Looking for the status of an authentication registration or reset event of a user? Look at the **Registration and reset events** report from the side menu and then search for a name or UPN. You'll be able to see the method used to attempt to register or reset an authentication method.

-The Service principal sign-in activity (preview) report provides the last activity date for every service principal. The report provides you information on the usage of the service principal - whether it was used as a client or resource app and whether it was used in an app-only or delegated context. The report shows the last time the service principal was used.

-The following is an example of the response:

-The Application credential activity (preview) report provides the last credential activity date for every application credential. The report provides the credential type (certificate or client secret), the last used date, and the expiration date. With this report you can view the expiration dates of all your applications in one place.

-The following is an example of the response:

-1. In the **Monitoring** section, select **Sign-in logs**.

-1. Select a sign-in item from the table to open the **Activity Details: Sign-ins context** pane.

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

-1. Go to **Azure AD** > **Diagnostic settings**.

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

-1. Go to **Azure AD** > **Diagnostic settings**.

-1. Go to **Azure AD** and select **Audit logs**, **Sign-in logs**, or **Provisioning logs** from the **Monitoring** menu.

-1. Go to **Azure AD** > **Security** > **Identity Protection**.

-1. Go to **Azure AD** and select **Usage and insights** from the **Monitoring** menu.

-### Archive activity logs to a storage account

-1. Go to **Azure AD** > **Diagnostic settings**.

-1. Go to **Azure AD** and select **Audit logs**, **Sign-in logs**, or **Provisioning logs** from the **Monitoring** menu.

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

-1. Go to **Azure Active Directory** > **Log Analytics**. A default search query runs.