+1. Replace all instances of `contoso` with your [Azure AD B2C tenant name](./tenant-management-read-tenant-name.md#get-your-tenant-name).

+[Azure AD Connect sync: Understanding Declarative Provisioning](../hybrid/connect/concept-azure-ad-connect-sync-declarative-provisioning.md)

+To learn more about alerts, see [Azure Monitor Log Alerts](../../azure-monitor/alerts/alerts-create-new-alert-rule.md).

+- [Install and use the log analytics views for Azure Active Directory](../../azure-monitor/visualize/workbooks-view-designer-conversion-overview.md)

+- The role attribute typically needs to be mapped using an expression, rather than a direct mapping. For more information about role mapping, see [Provisioning a role to a SCIM app](#provisioning-a-role-to-a-scim-app).

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

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

+* A user is soft-deleted in Azure AD (sent to the recycle bin / AccountEnabled property set to false). Thirty days after a user is deleted in Azure AD, they're permanently deleted from the tenant. At this point, the provisioning service sends a DELETE request to permanently delete the user in the application. At any time during the 30-day window, you can [manually delete a user permanently](../fundamentals/users-restore.md), which sends a delete request to the application.

+

+The required outbound endpoints for the provisioning agents are detailed [here](../hybrid/cloud-sync/how-to-prerequisites.md#firewall-and-proxy-requirements).

+[](./media/on-premises-application-provisioning-architecture/ecma-2.png#lightbox)

+ [](./media/on-premises-application-provisioning-architecture/user-2.png#lightbox)

+ [](./media/on-premises-application-provisioning-architecture/match-1.png#lightbox)

+On-premises app provisioning has been rolled into the provisioning agent and is available from the portal. See [installing the provisioning agent](../hybrid/cloud-sync/how-to-install.md).

+ 1. Install the AADCloudSyncTools PowerShell module as described in [AADCloudSyncTools PowerShell Module for Azure AD Connect cloud sync](../hybrid/cloud-sync/reference-powershell.md#install-the-aadcloudsynctools-powershell-module).

+When technology projects fail, it's typically because of mismatched expectations on impact, outcomes, and responsibilities. To avoid these pitfalls, [ensure you're engaging the right stakeholders](../architecture/deployment-plans.md) and that stakeholder roles in the project are well understood by documenting the stakeholders and their project input and accountabilities.

+We recommend that the initial configuration of automatic user provisioning is in a test environment with a small subset of users before scaling it to all users in production. See [best practices](../architecture/deployment-plans.md#best-practices-for-a-pilot) for running a pilot.

+- [Azure AD Connect](../hybrid/connect/whatis-azure-ad-connect.md) for synchronizing users between Active Directory and Azure AD.

+5. **Azure AD Connect** runs delta [sync](../hybrid/connect/how-to-connect-sync-whatis.md) to pull updates in Active Directory.

+When technology projects fail, they typically do so owing to mismatched expectations on impact, outcomes, and responsibilities. To avoid these pitfalls, [ensure that you're engaging the right stakeholders](../architecture/deployment-plans.md). Also make sure that stakeholder roles in the project are well understood. Document the stakeholders and their project input and accountabilities.

+Run the initial configuration in a [pilot environment](../architecture/deployment-plans.md#best-practices-for-a-pilot) before you scale it to all users in production.

+The provisioning agent configures a [Global Managed Service Account (GMSA)](../hybrid/cloud-sync/how-to-prerequisites.md#group-managed-service-accounts)

+* Use the [provisioning agent configuration wizard](../hybrid/cloud-sync/how-to-install.md#install-the-agent) to register your AD domain with your Azure AD tenant.

+* Use the [provisioning agent configuration wizard](../hybrid/cloud-sync/how-to-install.md#install-the-agent) to register all child AD domains with your Azure AD tenant.

+* Configure [referral chasing](../hybrid/cloud-sync/how-to-manage-registry-options.md#configure-referral-chasing) on the provisioning agent.

+* Use the [provisioning agent configuration wizard](../hybrid/cloud-sync/how-to-install.md#install-the-agent) to register the parent AD domain and all child AD domains with your Azure AD tenant.

+* Configure [referral chasing](../hybrid/cloud-sync/how-to-manage-registry-options.md#configure-referral-chasing) on the provisioning agent.

+* Use the [provisioning agent configuration wizard](../hybrid/cloud-sync/how-to-install.md#install-the-agent) to register the parent AD domain and all child AD domains with your Azure AD tenant.

+* If you need to resolve cross domain references within the forest, enable [referral chasing](../hybrid/cloud-sync/how-to-manage-registry-options.md#configure-referral-chasing) on the provisioning agent.

+* If you need to resolve cross domain references within the forest, enable [referral chasing](../hybrid/cloud-sync/how-to-manage-registry-options.md#configure-referral-chasing) on the provisioning agent.

+Install the [log analytics views for Azure AD activity logs](../../azure-monitor/visualize/workbooks-view-designer-conversion-overview.md) to get access to [prebuilt reports](https://github.com/AzureAD/Deployment-Plans/tree/master/Log%20Analytics%20Views) around provisioning events in your environment.

+You should already be familiar with Azure monitoring and Log Analytics. If not, jump over to learn about them and then come back to learn about application provisioning logs. To learn more about Azure monitoring, see [Azure Monitor overview](../../azure-monitor/overview.md). To learn more about Azure Monitor logs and Log Analytics, see [Overview of log queries in Azure Monitor](../../azure-monitor/logs/log-query-overview.md) and [Provisioning Logs for troubleshooting cloud sync](../hybrid/cloud-sync/how-to-troubleshoot.md).

+To learn more about alerts, see [Azure Monitor Log Alerts](../../azure-monitor/alerts/alerts-create-new-alert-rule.md).

+- [What is provisioning?](../hybrid/what-is-provisioning.md)

+- [Error codes](../hybrid/cloud-sync/reference-error-codes.md)

+> For users in on-premises Active Directory, you must sync the users to Azure AD. You can sync users and attributes using [Azure AD Connect](../hybrid/connect/whatis-azure-ad-connect.md) or [Azure AD Connect cloud sync](../hybrid/cloud-sync/what-is-cloud-sync.md). Both of these solutions automatically synchronizes certain attributes to Azure AD, but not all attributes. Furthermore, some attributes (such as SAMAccountName) that are synchronized by default might not be exposed using the Graph API. In these cases, you can [use the Azure AD Connect directory extension feature to synchronize the attribute to Azure AD](#create-an-extension-attribute-using-azure-ad-connect) or [use Azure AD Connect cloud sync](#create-an-extension-attribute-using-cloud-sync). That way, the attribute will be visible to the Graph API and the Azure AD provisioning service.

+ 1. Configure [Azure AD Connect](../hybrid/connect/whatis-azure-ad-connect.md) or Azure AD Connect cloud sync to synchronize the users with their extension attribute from Active Directory to Azure AD. Azure AD Connect automatically synchronizes certain attributes to Azure AD, but not all attributes. Furthermore, some attributes (such as `sAMAccountName`) that are synchronized by default might not be exposed using the Graph API. In these cases, you can [use the Azure AD Connect directory extension feature to synchronize the attribute to Azure AD](#create-an-extension-attribute-using-azure-ad-connect). That way, the attribute will be visible to the Graph API and the Azure AD provisioning service.

+For more information, see [Cloud Sync Custom Attribute Mapping](../hybrid/cloud-sync/custom-attribute-mapping.md)

+> If you are installing the connector for Azure Government cloud follow the [prerequisites](../hybrid/connect/reference-connect-government-cloud.md#allow-access-to-urls) and [installation steps](../hybrid/connect/reference-connect-government-cloud.md#install-the-agent-for-the-azure-government-cloud). This requires enabling access to a different set of URLs and an additional parameter to run the installation.

+> [Configure single sign-on](../manage-apps/plan-sso-deployment.md#choosing-a-single-sign-on-method)

+Learn about setting up [Single sign-on to applications in Azure Active Directory](../manage-apps/plan-sso-deployment.md#choosing-a-single-sign-on-method).

+5. First set up SAML SSO to work while on the corporate network, see the basic SAML configuration section of [Configure SAML-based single sign-on](../develop/single-sign-on-saml-protocol.md) to configure SAML-based authentication for the application.

+Application Proxy supports several [single sign-on modes](../manage-apps/plan-sso-deployment.md#choosing-a-single-sign-on-method). Password-based sign-on is intended for applications that use a username/password combination for authentication. When you configure password-based sign-on for your application, your users have to sign in to the on-premises application once. After that, Azure Active Directory stores the sign-in information and automatically provides it to the application when your users access it remotely.

+ - You may also add a **Group Header**, to send all the groups a user is part of, or the groups assigned to the application as a header. To learn more about configuring groups as a value see: [Configure group claims for applications](../hybrid/connect/how-to-connect-fed-group-claims.md#add-group-claims-to-tokens-for-saml-applications-using-sso-configuration).

+For government, use `-EnvironmentName "AzureUSGovernment"`. For more details, see [Install Agent for the Azure Government Cloud](../hybrid/connect/reference-connect-government-cloud.md#install-the-agent-for-the-azure-government-cloud).

+* Device-based Conditional Access: Ensure only enrolled, approved, and compliant devices can access corporate data with [device-based Conditional Access](../conditional-access/concept-conditional-access-grant.md).

+* Application-based Conditional Access: Work doesn't have to stop when a user isn't on the corporate network. [Secure access to corporate cloud and on-premises apps](../conditional-access/howto-policy-approved-app-or-app-protection.md) and maintain control with Conditional Access.

+- [Learn how Azure AD architecture supports high availability](../architecture/architecture.md)

+ - On-premises Active Directory users must be synchronized with Azure AD Connect, and must be configure to [sign in to Azure](../hybrid/connect/plan-connect-user-signin.md).

+- On-premises Active Directory synchronized with Azure AD Connect, through which users can [sign in to Azure](../hybrid/connect/plan-connect-user-signin.md).

+For more information, see [Azure Active Directory editions](../fundamentals/whatis.md).

+To make your application use a custom claim and include additional fields, be sure you've also [created a custom claims mapping policy and assigned it to the application](../develop/saml-claims-customization.md).

+> You can do policy definition and assignment through PowerShell or Microsoft Graph. If you're doing them in PowerShell, you may need to first use `New-AzureADPolicy` and then assign it to the application with `Add-AzureADServicePrincipalPolicy`. For more information, see [Claims mapping policy assignment](../develop/saml-claims-customization.md).

+> If you are installing the connector for Azure Government cloud review the [pre-requisites](../hybrid/connect/reference-connect-government-cloud.md#allow-access-to-urls) and [installation steps](../hybrid/connect/reference-connect-government-cloud.md#install-the-agent-for-the-azure-government-cloud). This requires enabling access to a different set of URLs and an additional parameter to run the installation.

+- Improved support for Azure Government cloud environments. For steps on how to properly install the connector for Azure Government cloud review the [pre-requisites](../hybrid/connect/reference-connect-government-cloud.md#allow-access-to-urls) and [installation steps](../hybrid/connect/reference-connect-government-cloud.md#install-the-agent-for-the-azure-government-cloud).

+Application Proxy supports single sign-on. For more information on supported methods, see [Choosing a single sign-on method](../manage-apps/plan-sso-deployment.md#choosing-a-single-sign-on-method).

+To start using Application Proxy, see [Tutorial: Add an on-premises application for remote access through Application Proxy](application-proxy-add-on-premises-application.md).

+For more information on supported methods, see [Choosing a single sign-on method](../manage-apps/plan-sso-deployment.md#choosing-a-single-sign-on-method).

+- [Integrate with Azure Active Directory Application Proxy on a Network Device Enrollment Service (NDES) server](./app-proxy-protect-ndes.md)

+To learn about new and updated content in March, see the [what's new in application management](../manage-apps/whats-new-docs.md) content page.

+Azure Active Directory (Azure AD) enables you to securely manage access to Azure services and resources for your users. Included with Azure AD is a full suite of identity management capabilities. For information about Azure AD features, see [What is Azure Active Directory?](../fundamentals/whatis.md)

+With Azure AD, you can create and manage users and groups, and enable permissions to allow and deny access to enterprise resources. For information about identity management, see [The fundamentals of Azure identity management](../fundamentals/whatis.md).

+* [OAuth 2.0 and OpenID Connect protocols on the Microsoft Identity Platform](../develop/v2-protocols.md)

+* [OAuth 2.0 and OpenID Connect protocols on the Microsoft Identity Platform](../develop/v2-protocols.md)

+* [How Azure AD uses the SAML protocol](../develop/saml-protocol-reference.md)

+1. When a group is created in Azure AD, it can be automatically synchronized to AD DS using [Azure AD Connect sync](../hybrid/connect/how-to-connect-group-writeback-v2.md).

+| 1 |Users, groups| AD DS| Azure AD| [Azure AD Connect Cloud Sync](../hybrid/cloud-sync/what-is-cloud-sync.md) |

+| 2 |Users, groups, devices| AD DS| Azure AD| [Azure AD Connect Sync](../hybrid/connect/whatis-azure-ad-connect.md) |

+| 3 |Groups| Azure AD| AD DS| [Azure AD Connect Sync](../hybrid/connect/how-to-connect-group-writeback-v2.md) |

+2. Evaluate [Azure AD Cloud Sync](../hybrid/cloud-sync/what-is-cloud-sync.md) for synchronization between AD DS and Azure AD

+3. Use the [Microsoft Identity Manager](/microsoft-identity-manager/microsoft-identity-manager-2016) for complex provisioning scenarios

+The backup authentication system doesn't currently support web applications and services that are configured as confidential clients. Protection for the [authorization code grant flow](../develop/v2-oauth2-auth-code-flow.md) and subsequent token acquisition using refresh tokens and client secrets or [certificate credentials](../develop/certificate-credentials.md) isn't currently supported. The OAuth 2.0 [on-behalf-of flow](../develop/v2-oauth2-on-behalf-of-flow.md) isn't currently supported.

+- [Resilience Defaults for Conditional Access](../conditional-access/resilience-defaults.md)

+ * See, [What is federation with Azure AD?](../hybrid/connect/whatis-fed.md)

+ * See, [Migrate from federation to cloud authentication](../hybrid/connect/migrate-from-federation-to-cloud-authentication.md)

+ * See, [Azure Active Directory SSO: Quickstart](../hybrid/connect/how-to-connect-sso-quick-start.md)

+ * See, [Azure Active Directory Seamless SSO: Technical deep dive](../hybrid/connect/how-to-connect-sso-how-it-works.md)

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

+To configure the underlying query and set alerts, complete the following steps using the sample query as the basis for your configuration. The query structure description appears at the end of this section. Learn how to create, view, and manage log alerts using Azure Monitor in [Manage log alerts](../../azure-monitor/alerts/alerts-create-new-alert-rule.md).

+SharePoint Online has its own service-specific permissions depending on whether the user (internal or external) is of type member or guest in the Azure Active Directory tenant. [Office 365 external sharing and Azure Active Directory B2B collaboration](../external-identities/what-is-b2b.md) describes how you can enable integration with SharePoint and OneDrive to share files, folders, list items, document libraries, and sites with people outside your organization, while using Azure B2B for authentication and management.

+- [B2B and Office 365 external sharing](../external-identities/what-is-b2b.md) explains the similarities and differences among sharing resources through B2B, Office 365, and SharePoint/OneDrive.

+- [Multi-tenant synchronization from Active Directory](../hybrid/connect/plan-connect-topologies.md) describes various on-premises and Azure Active Directory (Azure AD) topologies that use Azure AD Connect sync as the key integration solution.

+- [**Application-based invitations.**](../external-identities/what-is-b2b.md) Microsoft applications (such as Teams and SharePoint) can enable external user invitations. Configure B2B invitation settings in both Azure AD B2B and in the relevant applications.

+- [**MyApps.**](../manage-apps/myapps-overview.md) Users can invite and assign external users to applications using MyApps. The user account must have [application self-service sign up](../manage-apps/manage-self-service-access.md) approver permissions. Group owners can invite external users to their groups.

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

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

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

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

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

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

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

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

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

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

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

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

+- [Get data using the Azure AD Reporting API with certificates](../reports-monitoring/howto-configure-prerequisites-for-reporting-api.md)

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

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

+Microsoft recommends you have a good baseline and understanding of the issues in your on-premises environment that can result in synchronization issues to the cloud. Since automated tools such as [IdFix](/office365/enterprise/prepare-directory-attributes-for-synch-with-idfix) and [Azure AD Connect Health](../hybrid/connect/whatis-azure-ad-connect.md#why-use-azure-ad-connect-health) can generate a high volume of false positives, we recommend you identify synchronization errors that have been left unaddressed for more than 100 days by cleaning up those objects in error. Long term unresolved synchronization errors can generate support incidents. [Troubleshooting errors during synchronization](../hybrid/connect/tshoot-connect-sync-errors.md) provides an overview of different types of sync errors, some of the possible scenarios that cause those errors and potential ways to fix the errors.

+Ideally, you'll want to reach a balance between reducing the number of objects to synchronize and the complexity in the rules. Generally, a combination between OU/container [filtering](../hybrid/connect/how-to-connect-sync-configure-filtering.md) plus a simple attribute mapping to the cloudFiltered attribute is an effective filtering combination.

+Using **ms-DS-consistencyguid** as the [source anchor](../hybrid/connect/plan-connect-design-concepts.md) allows an easier migration of objects across forests and domains, which is common in AD Domain consolidation/cleanup, mergers, acquisitions, and divestitures.

+The [default delta sync](../hybrid/connect/how-to-connect-sync-feature-scheduler.md) frequency is 30 minutes. If the delta sync is taking longer than 30 minutes consistently, or there are significant discrepancies between the delta sync performance of staging and production, you should investigate and review the [factors influencing the performance of Azure AD Connect](../hybrid/connect/plan-connect-performance-factors.md).

+- [Azure AD Connect: Troubleshooting Errors during synchronization](../hybrid/connect/tshoot-connect-sync-errors.md)

+- [Azure AD Connect: Automatic upgrade](../hybrid/connect/how-to-connect-install-automatic-upgrade.md)

+Organizations should deploy [Azure AD Connect Health](../hybrid/connect/whatis-azure-ad-connect.md#what-is-azure-ad-connect-health) for monitoring and reporting of Azure AD Connect and AD FS. Azure AD Connect and AD FS are critical components that can break lifecycle management and authentication and therefore lead to outages. Azure AD Connect Health helps monitor and gain insights into your on-premises identity infrastructure thus ensuring the reliability of your environment.

+- [Azure AD Connect Health Agent Installation](../hybrid/connect/how-to-connect-health-agent-install.md)

+- [Azure AD Connect: Troubleshoot Pass-through Authentication](../hybrid/connect/tshoot-connect-pass-through-authentication.md#collecting-pass-through-authentication-agent-logs)

+- [Azure AD Pass-through Authentication - quickstart](../hybrid/connect/how-to-connect-pta-quick-start.md#step-4-ensure-high-availability)

+- [Azure AD Connect Health](../hybrid/connect/how-to-connect-health-operations.md#enable-email-notifications)

+- [Enterprise App Expiring Certificate Notifications](../manage-apps/tutorial-manage-certificates-for-federated-single-sign-on.md#add-email-notification-addresses-for-certificate-expiration)

+Using an [Active Directory forest trust](/windows-server/identity/ad-ds/plan/forest-design-models), Contoso and Litware can connect their Active Directory domains. This trust enables Litware users to authenticate Contoso's Active Directory-integrated apps. Also [Azure AD Connect](../hybrid/connect/whatis-azure-ad-connect.md) can also read from Litware's Active Directory forest so that Litware users authenticate with Contoso's Azure AD integrated apps. This deployment topology requires a network route set up between the two domains, and TCP/IP network connectivity between any Litware user and Contoso Active Directory-integrated app. It's also straightforward to set up bidirectional trusts, so that Contoso users can access Litware AD-integrated apps (if any).

+[Azure AD Connect cloud provisioning](../hybrid/cloud-sync/what-is-cloud-sync.md) removes the network connectivity requirement, but you can only have one Active Directory to Azure AD linking for a given user with cloud sync. Litware users can authenticate Contoso's Azure AD integrated apps, but not Contoso's Active Directory-integrated apps. This topology doesn't require any TCP/IP connectivity between Litware and Contoso's on-premises environments.

+- [What is Azure AD Connect cloud sync](../hybrid/cloud-sync/what-is-cloud-sync.md)

+ Provision multiple strong credentials by using Azure AD multifactor authentication. That way, access to cloud resources requires an Azure AD managed credential in addition to an on-premises password. For more information, see [Build resilience with credential management](./resilience-in-credentials.md) and [Create a resilient access control management strategy by using Azure AD](./resilience-overview.md).

+On-premises accounts synced from Active Directory are marked to never expire in Azure AD. This setting is usually mitigated by on-premises Active Directory password settings. If your instance of Active Directory is compromised and synchronization is disabled, set the [EnforceCloudPasswordPolicyForPasswordSyncedUsers](../hybrid/connect/how-to-connect-password-hash-synchronization.md) option to force password changes.

+- **Disconnected forests.** Use Azure AD cloud provisioning to connect to disconnected forests. This approach eliminates the need to establish cross-forest connectivity or trusts, which can broaden the effect of an on-premises breach. For more information, see [What is Azure AD Connect cloud sync](../hybrid/cloud-sync/what-is-cloud-sync.md).

+ For more information, see [Legacy authentication protocols](./auth-sync-overview.md#legacy-authentication-protocols). Or see specific details for [Exchange Online](/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online#how-basic-authentication-works-in-exchange-online) and [SharePoint Online](/powershell/module/sharepoint-online/set-spotenant).

+ You must deploy Azure AD Connect Health to monitor identity synchronization. See [What is Azure AD Connect](../hybrid/connect/whatis-azure-ad-connect.md).

+

+* Using a strong approval workflow for changes, for example, requiring [approval of PIM escalation of privileges](../privileged-identity-management/pim-approval-workflow.md).

+[Configure SSO](../hybrid/connect/how-to-connect-sso-quick-start.md) to be tenant-wide (default) to allow multiple applications and user flows in your tenant to share the same user session. Tenant-wide configuration provides most resiliency to fresh authentication.

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

+* [Configuring groups optional claims](../develop/optional-claims.md#configure-groups-optional-claims)

+See, [Add app roles to your application and receive them in the token](../develop/howto-add-app-roles-in-apps.md)

+* Turn on [password hash synchronization](../hybrid/connect/whatis-phs.md) for hybrid accounts that are synchronized from Windows Server Active Directory. This option can be enabled alongside federation services such as Active Directory Federation Services (AD FS) and provides a fallback in case the federation service fails.

+* [Password hash synchronization](../hybrid/connect/whatis-phs.md) (PHS) uses Azure AD Connect to sync the identity and a hash-of-the-hash of the password to Azure AD. It enables users to sign in to cloud-based resources with their password mastered on premises. PHS has on premises dependencies only for synchronization, not for authentication.

+* [Pass-through Authentication](../hybrid/connect/how-to-connect-pta.md) (PTA) redirects users to Azure AD for sign-in. Then, the username and password are validated against Active Directory on premises through an agent that is deployed in the corporate network. PTA has an on premises footprint of its Azure AD PTA agents that reside on servers on premises.

+* [Federation](../hybrid/connect/whatis-fed.md) customers deploy a federation service such as Active Directory Federation Services (ADFS). Then Azure AD validates the SAML assertion produced by the federation service. Federation has the highest dependency on on-premises infrastructure and, therefore, more failure points.

+You may be using one or more of these methods in your organization. For more information, see [Choose the right authentication method for your Azure AD hybrid identity solution](../hybrid/connect/choose-ad-authn.md). This article contains a decision tree that can help you decide on your methodology.

+The simplest and most resilient hybrid authentication option for Azure AD is [Password Hash Synchronization](../hybrid/connect/whatis-phs.md). It doesn't have any on premises identity infrastructure dependency when processing authentication requests. After identities with password hashes are synchronized to Azure AD, users can authenticate to cloud resources with no dependency on the on premises identity components.

+* [Implement password hash synchronization with Azure AD Connect](../hybrid/connect/how-to-connect-password-hash-synchronization.md)

+* [Enable password hash synchronization](../hybrid/connect/how-to-connect-password-hash-synchronization.md)

+* [How Pass-through Authentication works](../hybrid/connect/how-to-connect-pta-how-it-works.md)

+* [Pass-through Authentication security deep dive](../hybrid/connect/how-to-connect-pta-security-deep-dive.md)

+* [Install Azure AD Pass-through Authentication](../hybrid/connect/how-to-connect-pta-quick-start.md)

+* If you're using PTA, define a [highly available topology](../hybrid/connect/how-to-connect-pta-quick-start.md).

+* [What is federated authentication](../hybrid/connect/whatis-fed.md)

+* [How federation works](../hybrid/connect/how-to-connect-fed-whatis.md)

+* [Azure AD federation compatibility list](../hybrid/connect/how-to-connect-fed-compatibility.md)

+* [Enable PHS](../hybrid/connect/tutorial-phs-backup.md) along with your federation

+* [Build resilience in application access with Application Proxy](./resilience-on-premises-access.md)

+- **Alerting**: Using log analytics define [alerts](../../azure-monitor/alerts/alerts-create-new-alert-rule.md) that get triggered when there are sudden changes in the key indicators. These changes may negatively impact the SLOs. Alerts use various forms of notification methods including email, SMS, and webhooks. Start by defining a criterion that acts as a threshold against which alert will be triggered. For example:

+ - Upon receiving an alert, troubleshoot the issue using [Log Analytics](../../azure-monitor/visualize/workbooks-view-designer-conversion-overview.md), [Application Insights](../../active-directory-b2c/troubleshoot-with-application-insights.md), and [VS Code extension](https://marketplace.visualstudio.com/items?itemName=AzureADB2CTools.aadb2c) for Azure AD B2C. After you resolve the issue and deploy an updated application or policy, it continues to monitor the key indicators until they return back to normal range.

+* Establish hybrid identity synchronization between Active Directory and Azure AD by using [Azure AD Connect](../hybrid/connect/whatis-azure-ad-connect.md) or [Azure AD Connect cloud sync](../hybrid/cloud-sync/what-is-cloud-sync.md).

+* [Select authentication methods](../hybrid/connect/choose-ad-authn.md). We strongly recommend password hash synchronization.

+* [Understand the Azure AD schema and custom expressions](../hybrid/cloud-sync/concept-attributes.md)

+* [Attributes synchronized by Azure AD Connect](../hybrid/connect/reference-connect-sync-attributes-synchronized.md)

+* [Use Azure AD schema extension attributes in claims - Microsoft identity platform](../develop/schema-extensions.md)

+* [Provide optional claims to Azure AD apps - Microsoft identity platform](../develop/optional-claims.md)

+* [Deploy Azure AD-joined VMs in Azure Virtual Desktop](../../virtual-desktop/azure-ad-joined-session-hosts.md)

+* [Move application authentication to Azure Active Directory](../manage-apps/migrate-adfs-apps-stages.md)

+* [Migrate from federation to cloud authentication](../hybrid/connect/migrate-from-federation-to-cloud-authentication.md)

+* **Establish an Azure AD footprint**: Initialize your new Azure AD tenant to support the vision for your end-state deployment. Adopt a [Zero Trust](https://www.microsoft.com/security/blog/2020/04/30/zero-trust-deployment-guide-azure-active-directory/) approach and a security model that [helps protect your tenant from on-premises compromise](./protect-m365-from-on-premises-attacks.md) early in your journey.

+For general guidance on how to configure Azure Active Directory (Azure AD) tenants (isolated or not), refer to the [Azure AD feature deployment guide](../fundamentals/concept-secure-remote-workers.md).

+In addition to the guidance in the [Azure Active Directory general operations guide](./ops-guide-ops.md), we also recommend the following considerations for isolated environments.

+Cloud-only accounts are the simplest way to provision human identities in an Azure AD tenant and it's a good fit for green field environments. However, if there's an existing on-premises infrastructure that corresponds to the isolated environment (for example, pre-production or management Active Directory forest), you could consider synchronizing identities from there. This holds especially true if the on-premises infrastructure described herein is used for IaaS solutions that require server access to manage the solution data plane. For more information on this scenario, see [Protecting Microsoft 365 from on-premises attacks](./protect-m365-from-on-premises-attacks.md). Synchronizing from isolated on-premises environments might also be needed if there are specific regulatory compliance requirements such as smart-card only authentication.

+Azure AD also supports direct user assignment to third-party SaaS services (for example, Salesforce, Service Now) for single sign-on and identity provisioning. Direct assignments to resources can be natively governed from the cloud when combined with [Azure AD access reviews](../governance/access-reviews-overview.md) and [Azure AD entitlement management](./ops-guide-ops.md). Direct assignment might be a good fit for end-user facing assignment.

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

+* For specific device configuration and control, you can use device filters in Conditional Access policies to [target or exclude specific devices](../conditional-access/concept-condition-filters-for-devices.md). This enables you to restrict access to Azure management tools from a designated secure admin workstation (SAW). Other approaches you can take include using [Azure Virtual desktop](../../virtual-desktop/terminology.md), [Azure Bastion](../../bastion/bastion-overview.md), or [Cloud PC](/graph/cloudpc-concept-overview).

+Some approaches you can use for [using secure devices as part of your privileged access story](/security/compass/privileged-access-devices) include using Conditional Access policies to [target or exclude specific devices](../conditional-access/concept-condition-filters-for-devices.md), using [Azure Virtual desktop](../../virtual-desktop/terminology.md), [Azure Bastion](../../bastion/bastion-overview.md), or [Cloud PC](/graph/cloudpc-concept-overview), or creating Azure-managed workstations or privileged access workstations.

+[Azure AD Connect Health](../hybrid/connect/whatis-azure-ad-connect.md) must be deployed to monitor identity synchronization and federation (when applicable) for all environments.

+* **Emergency access accounts activity** - Any access using [emergency access accounts](./security-operations-privileged-accounts.md) should be monitored and [alerts](../roles/security-emergency-access.md) created for investigations. This monitoring must include:

+* [Azure AD fundamentals](./secure-fundamentals.md)

+These are the functional areas provided by Azure AD that are relevant to isolated environments. To learn more about the capabilities of Azure AD, see [What is Azure Active Directory?](../fundamentals/whatis.md).

+**Identity management**. Azure AD provides tools to manage the lifecycle of user, group, and device identities. [Azure AD Connect](../hybrid/connect/whatis-azure-ad-connect.md) enables organizations to extend current, on-premises identity management solution to the cloud. Azure AD Connect manages the provisioning, de-provisioning, and updates to these identities in Azure AD.

+* [Best practices](secure-best-practices.md)

+For more information on workload identities, see [What are workload identities](../workload-identities/workload-identities-overview.md).

+In a hybrid environment, identities are typically synchronized from the on-premises Active Directory environment using [Azure AD Connect](../hybrid/connect/whatis-azure-ad-connect.md).

+* [Azure AD fundamentals](./secure-fundamentals.md)

+>Azure AD Connect synchronization to multiple tenants, which might be useful when deploying a non-production environment in a separate tenant. For more information, see [Azure AD Connect: Supported topologies](../hybrid/connect/plan-connect-topologies.md).

+* [Azure AD fundamentals](./secure-fundamentals.md)

+Subscriptions that enable [delegated resource management](../../lighthouse/concepts/architecture.md) with Azure Lighthouse have attributes that indicate the tenant IDs that can manage subscriptions or resource groups, and mapping between the built-in RBAC role in the resource tenant to identities in the service provider tenant. At runtime, Azure Resource Manager will consume these attributes to authorize tokens coming from the service provider tenant.

+ To further decouple and prevent the account owner from regaining service administrator access to the subscription, the subscription's tenant can be [changed](../fundamentals/how-subscriptions-associated-directory.md) after creation. If the account owner doesn't have a user object in the Azure AD tenant the subscription is moved to, they can't regain the service owner role.

+Azure AD [Conditional Access](../conditional-access/concept-conditional-access-cloud-apps.md) can be used to manage access to Azure management endpoints. Conditional Access policies can be applied to the Microsoft Azure Management cloud app to protect the Azure resource management endpoints such as:

+* [Azure AD fundamentals](./secure-fundamentals.md)

+* [Azure AD fundamentals](./secure-fundamentals.md)

+* [Best practices](secure-best-practices.md)

+| Extranet lockout trends| High| Azure AD Connect Health| See, [Monitor AD FS using Azure AD Connect Health](../hybrid/connect/how-to-connect-health-adfs.md) for tools and techniques to help detect extranet lock-out trends. |

+| Failed sign-ins|High | Connect Health Portal| Export or download the Risky IP report and follow the guidance at [Risky IP report (public preview)](../hybrid/connect/how-to-connect-health-adfs-risky-ip.md) for next steps. |

+| In privacy compliant| Low| Azure AD Connect Health| Configure Azure AD Connect Health to disable data collections and monitoring using the [User privacy and Azure AD Connect Health](../hybrid/connect/reference-connect-health-user-privacy.md) article. |

+| Azure AD pass-through authentication errors| Medium| PowerShell script of domain controller| See the query after the table. | Use the information at [Azure AD Connect: Troubleshoot Pass-through Authentication](../hybrid/connect/tshoot-connect-pass-through-authentication.md)for guidance. |

+* [Password hash synchronization](../hybrid/connect/whatis-phs.md) - A sign-in method that synchronizes a hash of a userΓÇÖs on-premises AD password with Azure AD.

+* [Synchronization](../hybrid/connect/how-to-connect-sync-whatis.md) - Responsible for creating users, groups, and other objects. And, making sure identity information for your on-premises users and groups matches the cloud. This synchronization also includes password hashes.

+* [Health Monitoring](../hybrid/connect/whatis-azure-ad-connect.md) - Azure AD Connect Health can provide robust monitoring and provide a central location in the Azure portal to view this activity.

+* For information on configuring and using Azure AD Connect, see [What is Azure AD Connect?](../hybrid/connect/whatis-azure-ad-connect.md)

+* Information for checking and troubleshooting hash synchronization, see [Troubleshoot password hash synchronization with Azure AD Connect sync](../hybrid/connect/tshoot-connect-password-hash-synchronization.md).

+| Hash synchronization validation|See [Troubleshoot password hash synchronization with Azure AD Connect sync](../hybrid/connect/tshoot-connect-password-hash-synchronization.md) |

+| Errors associated with SSO and Kerberos validation failures|Medium | Azure AD Sign-ins log| | Single sign-on list of error codes at [Single sign-on](../hybrid/connect/tshoot-connect-sso.md). |

+* [Password hash synchronization (PHS)](../hybrid/connect/whatis-phs.md)

+* [Pass-through authentication (PTA)](../hybrid/connect/how-to-connect-pta.md)

+* [Federation (AD FS)](../hybrid/connect/whatis-fed.md)

+* **PTA Agent** - The pass-through authentication agent is used to enable pass-through authentication and is installed on-premises. See [Azure AD Pass-through Authentication agent: Version release history](../hybrid/connect/reference-connect-pta-version-history.md) for information on verifying your agent version and next steps.

+* **Azure AD Connect Health Agent** - The agent used to provide a communications link for Azure AD Connect Health. For information on installing the agent, see [Azure AD Connect Health agent installation](../hybrid/connect/how-to-connect-health-agent-install.md).

+* **Azure AD Connect Sync Engine** - The on-premises component, also called the sync engine. For information on the feature, see [Azure AD Connect sync service features](../hybrid/connect/how-to-connect-syncservice-features.md).

+* **Azure AD Connect** - Services used for an Azure AD Connect solution. For more information, see [What is Azure AD Connect](../hybrid/connect/whatis-azure-ad-connect.md).

+* **Azure AD Connect Health** - Service Health provides you with a customizable dashboard that tracks the health of your Azure services in the regions where you use them. For more information, see [Azure AD Connect Health](../hybrid/connect/whatis-azure-ad-connect.md).

+* **Device services** - Device identity management is the foundation for [device-based Conditional Access](../conditional-access/concept-conditional-access-grant.md). With device-based Conditional Access policies, you can ensure that access to resources in your environment is only possible with managed devices. For more information, see [What is a device identity](../devices/overview.md).

+For more information on discovering unused privileged accounts, see [Create an access review of Azure AD roles in Privileged Identity Management](../privileged-identity-management/pim-create-roles-and-resource-roles-review.md).

+Microsoft designed [Azure AD Connect cloud sync](../hybrid/cloud-sync/what-is-cloud-sync.md) to meet and accomplish your hybrid identity goals for synchronization of users, groups, and contacts to Azure AD. Azure AD Connect cloud sync uses the Azure AD cloud provisioning agent instead of the Azure AD Connect application.

+* [What is identity provisioning with Azure AD?](../hybrid/what-is-provisioning.md)Provisioning is the process of creating an object based on certain conditions, keeping the object up-to-date and deleting the object when conditions are no longer met. On-premises provisioning involves provisioning from on premises sources (like Active Directory) to Azure AD.

+* [Hybrid Identity: Directory integration tools comparison](../hybrid/connect/plan-hybrid-identity-design-considerations-tools-comparison.md) describes differences between Azure AD Connect sync and Azure AD Connect cloud provisioning.

+* [Azure AD Connect and Azure AD Connect Health installation roadmap](../hybrid/connect/how-to-connect-install-roadmap.md) provides detailed installation and configuration steps.

+* [Install the Azure AD Connect provisioning agent](../hybrid/cloud-sync/how-to-install.md) walks you through the installation process for the Azure Active Directory (Azure AD) Connect provisioning agent and how to initially configure it in the Azure portal.

+* [Azure AD Connect cloud sync new agent configuration](../hybrid/cloud-sync/how-to-configure.md) guides you through configuring Azure AD Connect cloud sync.

+* [Hybrid Identity: Directory integration tools comparison](../hybrid/connect/plan-hybrid-identity-design-considerations-tools-comparison.md) describes differences between Azure AD Connect sync and Azure AD Connect cloud provisioning.

+* [Azure AD Connect and Azure AD Connect Health installation roadmap](../hybrid/connect/how-to-connect-install-roadmap.md) provides detailed installation and configuration steps.

+If you want to configure certificate-based authentication in your environment, see [Get started with certificate-based authentication on Android](./certificate-based-authentication-federation-get-started.md) for instructions.

+- Assumes that you already have a [public key infrastructure (PKI)](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831740(v=ws.11)) and [AD FS](../hybrid/connect/how-to-connect-fed-whatis.md) configured.

+- [Android](./certificate-based-authentication-federation-android.md)

+- [iOS](./certificate-based-authentication-federation-ios.md)

+[Additional information about certificate-based authentication on Android devices.](./certificate-based-authentication-federation-android.md)

+[Additional information about certificate-based authentication on iOS devices.](./certificate-based-authentication-federation-ios.md)

+To configure certificate-based authentication in your environment, see [Get started with certificate-based authentication](./certificate-based-authentication-federation-get-started.md) for instructions.

+For federated domains, MFA may be enforced by Azure AD Conditional Access or by the on-premises federation provider by setting the federatedIdpMfaBehavior. If the federatedIdpMfaBehavior setting is set to enforceMfaByFederatedIdp, the user must authenticate on their federated IdP and can only satisfy the **Federated Multi-Factor** combination of the authentication strength requirement. For more information about the federation settings, see [Plan support for MFA](../hybrid/connect/migrate-from-federation-to-cloud-authentication.md#plan-support-for-mfa).

+For more information about declarative provisioning expressions, see [Azure AD Connect: Declarative Provisioning Expressions](../hybrid/connect/concept-azure-ad-connect-sync-declarative-provisioning-expressions.md).

+- [Azure AD CBA on mobile devices (Android and iOS)](./concept-certificate-based-authentication-mobile-ios.md)

+[Staged Rollout](../hybrid/connect/how-to-connect-staged-rollout.md) helps customers transition from AD FS to Azure AD by testing cloud authentication with selected groups of users before switching the entire tenant.

+1. On the **Enable Staged Rollout** feature page, click **On** for the option [Certificate-based authentication](./certificate-based-authentication-federation-get-started.md)

+For more information, see [Staged Rollout](../hybrid/connect/how-to-connect-staged-rollout.md).

+Although it's possible, Microsoft recommends privileged accounts be cloud-only accounts. Using cloud-only accounts for privileged access limits exposure in Azure AD from a compromised on-premises environment. For more information, see [Protecting Microsoft 365 from on-premises attacks](../architecture/protect-m365-from-on-premises-attacks.md).

+1. Make sure the user is either on managed authentication or using [Staged Rollout](../hybrid/connect/how-to-connect-staged-rollout.md).

+1. Azure AD checks whether CBA is enabled for the tenant. If CBA is enabled, the user sees a link to **Use a certificate or smartcard** on the password page. If the user doesn't see the sign-in link, make sure CBA is enabled on the tenant. For more information, see [How do I enable Azure AD CBA?](./certificate-based-authentication-faq.yml#how-can-an-administrator-enable-azure-ad-cba-).

+The certificate revocation process allows the admin to revoke a previously issued certificate from being used for future authentication. The certificate revocation won't revoke already issued tokens of the user. Follow the steps to manually revoke tokens at [Configure revocation](./certificate-based-authentication-federation-get-started.md#step-3-configure-revocation).

+- [Troubleshoot Azure AD CBA](./certificate-based-authentication-faq.yml)

+| [Azure AD Premium P1](../fundamentals/get-started-premium.md) | You can use [Azure AD Conditional Access](../conditional-access/howto-conditional-access-policy-all-users-mfa.md) to prompt users for multi-factor authentication during certain scenarios or events to fit your business requirements. |

+| [Azure AD Premium P2](../fundamentals/get-started-premium.md) | Provides the strongest security position and improved user experience. Adds [risk-based Conditional Access](../conditional-access/howto-conditional-access-policy-risk.md) to the Azure AD Premium P1 features that adapts to user's patterns and minimizes multi-factor authentication prompts. |

+> By default, only passwords for user accounts that aren't synchronized through Azure AD Connect can be configured to not expire. For more information about directory synchronization, see [Connect AD with Azure AD](../hybrid/connect/how-to-connect-password-hash-synchronization.md#password-expiration-policy).

+To be more resilient, your organization should [enable password hash sync](../hybrid/connect/choose-ad-authn.md), because it enables you to [switch to using password hash sync](../hybrid/connect/plan-connect-user-signin.md) if your on-premises identity systems are down.

+* Azure AD is online and is connected to your on-premises writeback client. However, it looks like the installed version of Azure AD Connect is out-of-date. Consider [Upgrading Azure AD Connect](../hybrid/connect/how-to-upgrade-previous-version.md) to ensure that you have the latest connectivity features and important bug fixes.

+* Unfortunately, we can't check your on-premises writeback client status because the installed version of Azure AD Connect is out-of-date. [Upgrade Azure AD Connect](../hybrid/connect/how-to-upgrade-previous-version.md) to be able to check your connection status.

+> By default only passwords for user accounts that aren't synchronized through Azure AD Connect can be configured to not expire. For more information about directory synchronization, see [Connect AD with Azure AD](../hybrid/connect/how-to-connect-password-hash-synchronization.md#password-expiration-policy).

+* [Password hash synchronization](../hybrid/connect/how-to-connect-password-hash-synchronization.md)

+* [Pass-through authentication](../hybrid/connect/how-to-connect-pta.md)

+* [Active Directory Federation Services](../hybrid/connect/how-to-connect-fed-management.md)

+You can deploy Azure AD Connect and cloud sync side-by-side in different domains to target different sets of users. This helps existing users continue to writeback password changes while adding the option in cases where users are in disconnected domains because of a company merger or split. Azure AD Connect and cloud sync can be configured in different domains so users from one domain can use Azure AD Connect while users in another domain use cloud sync. Cloud sync can also provide higher availability because it doesn't rely on a single instance of Azure AD Connect. For a feature comparison between the two deployment options, see [Comparison between Azure AD Connect and cloud sync](../hybrid/cloud-sync/what-is-cloud-sync.md#comparison-between-azure-ad-connect-and-cloud-sync).

+> Use of the checkbox "User must change password at next logon" in on-premises AD DS administrative tools like Active Directory Users and Computers or the Active Directory Administrative Center is supported as a preview feature of Azure AD Connect. For more information, see [Implement password hash synchronization with Azure AD Connect sync](../hybrid/connect/how-to-connect-password-hash-synchronization.md).

+ * Enable single sign-on (SSO) across applications using [managed devices](../devices/overview.md) or [Seamless SSO](../hybrid/connect/how-to-connect-sso.md).

+ * Enable single sign-on (SSO) across applications using [managed devices](../devices/overview.md) or [Seamless SSO](../hybrid/connect/how-to-connect-sso.md).

+| **SSO** | [Azure AD join](../devices/concept-directory-join.md) or [Hybrid Azure AD join](../devices/concept-hybrid-join.md), or [Seamless SSO](../hybrid/connect/how-to-connect-sso.md) for unmanaged devices. | Azure AD join<br />Hybrid Azure AD join |

+- [Azure AD CBA on mobile devices (Android and iOS)](./concept-certificate-based-authentication-mobile-ios.md)

+- The MFA Server Migration Utility copies the data from the database file onto the user objects in Azure AD. During migration, users can be targeted for Azure AD MFA for testing purposes using [Staged Rollout](../hybrid/connect/how-to-connect-staged-rollout.md). Staged migration lets you test without making any changes to your domain federation settings. Once migrations are complete, you must finalize your migration by making changes to your domain federation settings.

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

+- [Migrate to cloud authentication using Staged Rollout](../hybrid/connect/how-to-connect-staged-rollout.md)

+You can use the [MFA Server Migration Utility](how-to-mfa-server-migration-utility.md) to synchronize MFA data stored in the on-premises Azure MFA Server to Azure AD MFA and use [Staged Rollout](../hybrid/connect/how-to-connect-staged-rollout.md) to reroute users to Azure MFA. Staged Rollout helps you test without making any changes to your domain federation settings.

+Azure AD provides support for OATH hardware tokens. You can use the [MFA Server Migration Utility](how-to-mfa-server-migration-utility.md) to synchronize MFA settings between MFA Server and Azure AD MFA and use [Staged Rollout](../hybrid/connect/how-to-connect-staged-rollout.md) to test user migrations without changing domain federation settings.

+To select the best user authentication method for your organization, see [Choose the right authentication method for your Azure AD hybrid identity solution](../hybrid/connect/choose-ad-authn.md).

+Now you're ready to enable [Staged Rollout](../hybrid/connect/how-to-connect-staged-rollout.md). Staged Rollout helps you to iteratively move your users to either PHS or PTA while also migrating their on-premises MFA settings.

+* Be sure to review the [supported scenarios](../hybrid/connect/how-to-connect-staged-rollout.md#supported-scenarios).

+* First, you'll need to do either the [prework for PHS](../hybrid/connect/how-to-connect-staged-rollout.md#pre-work-for-password-hash-sync) or the [prework for PTA](../hybrid/connect/how-to-connect-staged-rollout.md#pre-work-for-pass-through-authentication). We recommend PHS.

+* Next, you'll do the [prework for seamless SSO](../hybrid/connect/how-to-connect-staged-rollout.md#pre-work-for-seamless-sso).

+* [Enable the Staged Rollout of cloud authentication](../hybrid/connect/how-to-connect-staged-rollout.md#enable-a-staged-rollout-of-a-specific-feature-on-your-tenant) for your selected authentication method.

+* **App sign-in health workbook**. See [Monitoring application sign-in health for resilience](../architecture/monitor-sign-in-health-for-resilience.md) for detailed guidance on using this workbook.

+You should now [convert your federated domains in Azure AD to managed](../hybrid/connect/migrate-from-federation-to-cloud-authentication.md#convert-domains-from-federated-to-managed) and remove the Staged Rollout configuration.

+- [Migrate applications from Windows Active Directory to Azure AD](../manage-apps/migrate-adfs-apps-phases-overview.md)

+- [Plan your cloud authentication strategy](../architecture/deployment-plans.md)

+- [Deploy password hash synchronization](../hybrid/connect/whatis-phs.md)

+- [Migrate applications to Azure AD](../manage-apps/migrate-adfs-apps-phases-overview.md)

+>User accounts that were recently deleted, also known as [soft-deleted users](../fundamentals/users-restore.md), are not listed in user registration details.

+When technology projects fail, it's typically because of mismatched expectations on impact, outcomes, and responsibilities. To avoid these pitfalls, [ensure that you're engaging the right stakeholders](../architecture/deployment-plans.md) and that stakeholder roles in the project are well understood.

+When you deploy passwordless authentication, you should first enable one or more pilot groups. You can create groups specifically for this purpose. Add the users who will participate in the pilot to the groups. Then, enable new passwordless authentication methods for the selected groups. See [best practices for a pilot](../architecture/deployment-plans.md).

+* [Deploy other identity features](../architecture/deployment-plans.md)

+[associate-azure-ad-tenant]: ../fundamentals/how-subscriptions-associated-directory.md

+| [Alternate Login ID in Azure AD Connect](../hybrid/connect/plan-connect-userprincipalname.md#alternate-login-id) | Synchronize an alternate attribute (such as Mail) as the Azure AD UPN. |

+[hybrid-auth-methods]: ../hybrid/connect/choose-ad-authn.md

+[azure-ad-connect]: ../hybrid/connect/whatis-azure-ad-connect.md

+[hybrid-overview]: ../hybrid/connect/cloud-governed-management-for-on-premises.md

+[phs-overview]: ../hybrid/connect/how-to-connect-password-hash-synchronization.md

+[pta-overview]: ../hybrid/connect/how-to-connect-pta-how-it-works.md

+- From [network locations you don't trust](../conditional-access/howto-conditional-access-policy-all-users-mfa.md)

+[Deploy other identity features](../architecture/deployment-plans.md)

+If you need to kick off a new round of synchronization, see [Azure AD Connect sync: Scheduler](../hybrid/connect/how-to-connect-sync-feature-scheduler.md#start-the-scheduler).

+To view the sign-in activity report in the [Azure portal](https://portal.azure.com), complete the following steps. You can also query data using the [reporting API](../reports-monitoring/howto-configure-prerequisites-for-reporting-api.md).

+When using [pass-through authentication](../hybrid/connect/how-to-connect-pta.md), the following considerations apply:

+* You have configured [Azure AD Connect](../hybrid/connect/how-to-connect-install-express.md) for your Azure AD tenant.

+Note: For users who have [Password hash synchronization (PHS)](../hybrid/connect/whatis-phs.md) disabled, SSPR stores the passwords in the on-prem Active Directory only.

+When technology projects fail, they typically do so due to mismatched expectations on impact, outcomes, and responsibilities. To avoid these pitfalls, [ensure that you are engaging the right stakeholders](../architecture/deployment-plans.md) and that stakeholder roles in the project are well understood by documenting the stakeholders and their project input and accountabilities.

+We recommend that the initial configuration of SSPR is in a test environment. Start with a pilot group by enabling SSPR for a subset of users in your organization. See [Best practices for a pilot](../architecture/deployment-plans.md).

+To create a group, see how to [create a group and add members in Azure Active Directory](../fundamentals/how-to-manage-groups.md).

+To ensure that your deployment works as expected, plan a set of test cases to validate the implementation. To assess the test cases, you need a non-administrator test user with a password. If you need to create a user, see [Add new users to Azure Active Directory](../fundamentals/add-users.md).

+For more information, see the [connectivity prerequisites for Azure AD Connect](../hybrid/connect/how-to-connect-install-prerequisites.md).

+| The Azure AD Connect machine event log contains error 32002 that is thrown by running PasswordResetService. <br> <br> The error reads: "Error Connecting to ServiceBus. The token provider was unable to provide a security token." | Your on-premises environment isn't able to connect to the Azure Service Bus endpoint in the cloud. This error is normally caused by a firewall rule blocking an outbound connection to a particular port or web address. See [Connectivity prerequisites](../hybrid/connect/how-to-connect-install-prerequisites.md) for more info. After you update these rules, restart the Azure AD Connect server and password writeback should start working again. |

+For more information, see [Getting started with Azure AD Connect](../hybrid/connect/how-to-connect-install-express.md).

+ * If you need to create a user, see [Quickstart: Add new users to Azure Active Directory](../fundamentals/add-users.md).

+ * If you need information about creating a user account, see [Add or delete users using Azure Active Directory](../fundamentals/add-users.md).

+ * If you need more information about creating a group, see [Create a basic group and add members using Azure Active Directory](../fundamentals/how-to-manage-groups.md).

+- An on-premises AD DS environment configured with [Azure AD Connect cloud sync version 1.1.977.0 or later](../app-provisioning/provisioning-agent-release-version-history.md). Learn how to [identify the agent's current version](../hybrid/cloud-sync/how-to-automatic-upgrade.md). If needed, configure Azure AD Connect cloud sync using [this tutorial](tutorial-enable-sspr.md).

+- For more information about cloud sync and a comparison between Azure AD Connect and cloud sync, see [What is Azure AD Connect cloud sync?](../hybrid/cloud-sync/what-is-cloud-sync.md)

+ * If needed, configure Azure AD Connect using the [Express](../hybrid/connect/how-to-connect-install-express.md) or [Custom](../hybrid/connect/how-to-connect-install-custom.md) settings.

+ * If you need to create a user, see [Quickstart: Add new users to Azure Active Directory](../fundamentals/add-users.md).

+ * If you need to create a group, see [Create a basic group and add members using Azure Active Directory](../fundamentals/how-to-manage-groups.md).

+To use WS-Federation or WIF to integrate with Azure AD, we recommend following the approach described in [Configure federated single sign-on for a non-gallery application](../develop/single-sign-on-saml-protocol.md). The article refers to configuring Azure AD for SAML-based single sign-on, but also works for configuring WS-Federation. Following this approach requires an Azure AD Premium license. This approach has two advantages:

+If you choose this approach, you need to understand [signing key rollover in Azure AD](../develop/signing-key-rollover.md). This approach uses the Azure AD global signing key to issue tokens. By default, WIF does not automatically refresh signing keys. When Azure AD rotates its global signing keys, your WIF implementation needs to be prepared to accept the changes. For more information, see [Important information about signing key rollover in Azure AD](/previous-versions/azure/dn641920(v=azure.100)).

+> Azure Active Directory Authentication Library (ADAL) has been deprecated. Please use the [Microsoft Authentication Library (MSAL)](/entr).

+> The v2.0 endpoint doesn't support all Azure AD scenarios and features. To determine whether you should use the v2.0 endpoint, read about [v2.0 limitations](./azure-ad-endpoint-comparison.md?bc=/azure/active-directory/azuread-dev/breadcrumb/toc.json&toc=/azure/active-directory/azuread-dev/toc.json).

+* **Multi-tenant application** - A multi-tenant application is intended for use in many organizations, not just one organization. These are typically software-as-a-service (SaaS) applications written by an independent software vendor (ISV). Multi-tenant applications need to be provisioned in each directory where they will be used, which requires user or administrator consent to register them. This consent process starts when an application has been registered in the directory and is given access to the Graph API or perhaps another web API. When a user or administrator from a different organization signs up to use the application, they are presented with a dialog that displays the permissions the application requires. The user or administrator can then consent to the application, which gives the application access to the stated data, and finally registers the application in their directory. For more information, see [Overview of the Consent Framework](../develop/application-consent-experience.md?toc=/azure/active-directory/azuread-dev/toc.json&bc=/azure/active-directory/azuread-dev/breadcrumb/toc.json).

+- Learn more about other Azure AD [authentication basics](v1-authentication-scenarios.md)

+With the Microsoft identity platform endpoint, you can ignore the static permissions defined in the app registration information in the Azure portal and request permissions incrementally instead, which means asking for a bare minimum set of permissions upfront and growing more over time as the customer uses additional app features. To do so, you can specify the scopes your app needs at any time by including the new scopes in the `scope` parameter when requesting an access token - without the need to pre-define them in the application registration information. If the user hasn't yet consented to new scopes added to the request, they'll be prompted to consent only to the new permissions. To learn more, see [permissions, consent, and scopes](../develop/permissions-consent-overview.md?toc=/azure/active-directory/azuread-dev/toc.json&bc=/azure/active-directory/azuread-dev/breadcrumb/toc.json).

+To learn more about OAuth 2.0, `refresh_tokens`, and `access_tokens`, check out the [Microsoft identity platform protocol reference](../develop/v2-protocols.md?toc=/azure/active-directory/azuread-dev/toc.json&bc=/azure/active-directory/azuread-dev/breadcrumb/toc.json).

+These scopes allow you to code your app in a minimal-disclosure fashion so you can only ask the user for the set of information that your app needs to do its job. For more information on these scopes, see [the Microsoft identity platform scope reference](../develop/permissions-consent-overview.md?toc=/azure/active-directory/azuread-dev/toc.json&bc=/azure/active-directory/azuread-dev/breadcrumb/toc.json).

+The Microsoft identity platform endpoint issues a smaller set of claims in its tokens by default to keep payloads small. If you have apps and services that have a dependency on a particular claim in a v1.0 token that is no longer provided by default in a Microsoft identity platform token, consider using the [optional claims](../develop/optional-claims.md?toc=/azure/active-directory/azuread-dev/toc.json&bc=/azure/active-directory/azuread-dev/breadcrumb/toc.json) feature to include that claim.

+* For platforms not covered by Microsoft libraries, you can integrate with the Microsoft identity platform endpoint by directly sending and receiving protocol messages in your application code. The OpenID Connect and OAuth protocols [are explicitly documented](../develop/v2-protocols.md?toc=/azure/active-directory/azuread-dev/toc.json&bc=/azure/active-directory/azuread-dev/breadcrumb/toc.json) to help you do such an integration.

+To better understand the scope of protocol functionality supported in the Microsoft identity platform endpoint, see [OpenID Connect and OAuth 2.0 protocol reference](../develop/v2-protocols.md?toc=/azure/active-directory/azuread-dev/toc.json&bc=/azure/active-directory/azuread-dev/breadcrumb/toc.json).

+If you've used Active Directory Authentication Library (ADAL) in Windows applications, you might have taken advantage of Windows Integrated authentication, which uses the Security Assertion Markup Language (SAML) assertion grant. With this grant, users of federated Azure AD tenants can silently authenticate with their on-premises Active Directory instance without entering credentials. While [SAML is still a supported protocol](../develop/saml-protocol-reference.md) for use with enterprise users, the v2.0 endpoint is only for use with OAuth 2.0 applications.

+Azure AD Conditional Access is a feature included in [Azure AD Premium](../fundamentals/whatis.md). You can learn more about licensing requirements in the [unlicensed usage report](../reports-monitoring/overview-reports.md). Developers can join the [Microsoft Developer Network](/), which includes a free subscription to the Enterprise Mobility Suite, which includes Azure AD Premium.

+* To learn more about multi-tenant scenarios, see [How to sign in users using the multi-tenant pattern](../develop/howto-convert-app-to-be-multi-tenant.md?toc=/azure/active-directory/azuread-dev/toc.json&bc=/azure/active-directory/azuread-dev/breadcrumb/toc.json).

+> Support for Active Directory Authentication Library (ADAL) will end in December, 2022. Apps using ADAL on existing OS versions will continue to work, but technical support and security updates will end. Without continued security updates, apps using ADAL will become increasingly vulnerable to the latest security attack patterns. For more information, see [Migrate apps to MSAL](../develop/msal-migration.md).

+| client_assertion |required | An assertion (a JSON Web Token) that you need to create and sign with the certificate you registered as credentials for your application. Read about [certificate credentials](../develop/certificate-credentials.md?toc=/azure/active-directory/azuread-dev/toc.json&bc=/azure/active-directory/azuread-dev/breadcrumb/toc.json) to learn how to register your certificate and the format of the assertion.|

+| client_assertion |required | A JSON Web Token that you create and sign with the certificate you registered as credentials for your application. See [certificate credentials](../develop/certificate-credentials.md?toc=/azure/active-directory/azuread-dev/toc.json&bc=/azure/active-directory/azuread-dev/breadcrumb/toc.json) to learn about assertion format and about how to register your certificate.|

+* [OAuth 2.0 in Azure AD](v1-protocols-oauth-code.md)

+* **Application permissions** - Are used by apps that run without a signed-in user present; for example, apps that run as background services or daemons. Application permissions can only be [consented to by administrators](../develop/permissions-consent-overview.md) because they are typically powerful and allow access to data across user-boundaries, or data that would otherwise be restricted to administrators. Users who are defined as owners of the resource application (i.e. the API which publishes the permissions) are also allowed to grant application permissions for the APIs they own.

+* **Dynamic user consent** - Is a feature of the v2 Azure AD app model. In this scenario, your app requests a set of permissions that it needs in the [OAuth 2.0 authorize flow for v2 apps](../develop/permissions-consent-overview.md#requesting-individual-user-consent). If the user has not consented already, they will be prompted to consent at this time. [Learn more about dynamic consent](./azure-ad-endpoint-comparison.md#incremental-and-dynamic-consent).

+* **Admin consent** - Is required when your app needs access to certain high-privilege permissions. Admin consent ensures that administrators have some additional controls before authorizing apps or users to access highly privileged data from the organization. [Learn more about how to grant admin consent](../develop/permissions-consent-overview.md).

+ - Mail.ReadWrite.All - Allows an administrator or user to access all mail in the organization.

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

+The required commands to run in Google Cloud Shell are listed in the Manage Authorization screen for each scope of a project, folder or organization. This is also configured in the GCP console.

+You have the ability to specify only certain GCP member projects to manage and monitor with Permissions Management (up to 100 per collector). Follow the steps to configure these GCP member projects to be monitored:

+The required commands to run in Google Cloud Shell are listed in the Manage Authorization screen for each scope of a project, folder or organization. This is also configured in the GCP console.

+- To view an inventory of created resources and licensing information for your authorization system, see [Display an inventory of created resources and licenses for your authorization system](./product-data-billable-resources.md)

+- [Requiring approved client apps with Conditional Access](./howto-policy-approved-app-or-app-protection.md)

+- [Require approved client app](./howto-policy-approved-app-or-app-protection.md)

+- [Require app protection policy](./howto-policy-approved-app-or-app-protection.md)

+See [Require approved client apps for cloud app access with Conditional Access](./howto-policy-approved-app-or-app-protection.md) for configuration examples.

+See [Require app protection policy and an approved client app for cloud app access with Conditional Access](./howto-policy-approved-app-or-app-protection.md) for configuration examples.

+[Create a Conditional Access policy](../authentication/tutorial-enable-azure-mfa.md?bc=/azure/active-directory/conditional-access/breadcrumb/toc.json&toc=/azure/active-directory/conditional-access/toc.json#create-a-conditional-access-policy)

+Continuous access evaluation (CAE) for [workload identities](../workload-identities/workload-identities-overview.md) provides security benefits to your organization. It enables real-time enforcement of Conditional Access location and risk policies along with instant enforcement of token revocation events for workload identities.

+The Azure AD default for browser session persistence allows users on personal devices to choose whether to persist the session by showing a ΓÇ£Stay signed in?ΓÇ¥ prompt after successful authentication. If browser persistence is configured in AD FS using the guidance in the article [AD FS single sign-on settings](/windows-server/identity/ad-fs/operations/ad-fs-single-sign-on-settings#enable-psso-for-office-365-users-to-access-sharepoint-online), we'll comply with that policy and persist the Azure AD session as well. You can also configure whether users in your tenant see the ΓÇ£Stay signed in?ΓÇ¥ prompt by changing the appropriate setting in the [company branding pane](../fundamentals/how-to-customize-branding.md).

+* A test user (non-administrator) that allows you to verify policies work as expected before deploying to real users. If you need to create a user, see [Quickstart: Add new users to Azure Active Directory](../fundamentals/add-users.md).

+* A group that the non-administrator user is a member of. If you need to create a group, see [Create a group and add members in Azure Active Directory](../fundamentals/how-to-manage-groups.md).

+| [Device management](./concept-conditional-access-grant.md) | Authorized user attempts to sign in from an authorized device | Access granted |

+| [Device management](./concept-conditional-access-grant.md) | Authorized user attempts to sign in from an unauthorized device | Access blocked |

+- A test account to sign-in with - If you don't know how to create a test account, see [Add cloud-based users](../fundamentals/add-users.md#add-a-new-user).

+- If you don't know how to delete an Azure AD user, see [Delete users from Azure AD](../fundamentals/add-users.md#delete-a-user).

+With Conditional Access policies, you can specify access requirements to websites and services. For example, your access requirements can include requiring multifactor authentication (MFA) or [managed devices](./concept-conditional-access-grant.md).

+If the information in the event isn't enough to understand the sign-in results, or adjust the policy to get desired results, the sign-in diagnostic tool can be used. The sign-in diagnostic can be found under **Basic info** > **Troubleshoot Event**. For more information about the sign-in diagnostic, see the article [What is the sign-in diagnostic in Azure AD](../reports-monitoring/howto-use-sign-in-diagnostics.md). You can also [use the What If tool to troubleshoot Conditional Access policies](what-if-tool.md).

+- [Install and use the log analytics views for Azure Active Directory](../../azure-monitor/visualize/workbooks-view-designer-conversion-overview.md)

+The v1.0 tokens include the following claims if applicable, but not v2.0 tokens by default. To use these claims for v2.0, the application requests them using [optional claims](./optional-claims.md).

+### Validate the issuer

+[OpenID Connect Core](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation) says "The Issuer Identifier \[...\] MUST exactly match the value of the iss (issuer) Claim." For applications which use a tenant-specific metadata endpoint (like [https://login.microsoftonline.com/8eaef023-2b34-4da1-9baa-8bc8c9d6a490/v2.0/.well-known/openid-configuration](https://login.microsoftonline.com/8eaef023-2b34-4da1-9baa-8bc8c9d6a490/v2.0/.well-known/openid-configuration) or [https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration](https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration)), this is all that is needed.

+Azure AD makes available a tenant-independent version of the document at [https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration](https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration). This endpoint returns an issuer value `https://login.microsoftonline.com/{tenantid}/v2.0`. Applications may use this tenant-independent endpoint to validate tokens from every tenant with the following modifications:

+ 1. Instead of expecting the issuer claim in the token to exactly match the issuer value from metadata, the application should replace the `{tenantid}` value in the issuer metadata with the tenantid that is the target of the current request, and then check the exact match.

+ 2. The application should use the `issuer` property returned from the keys endpoint to restrict the scope of keys.

+ - Keys that have an issuer value like `https://login.microsoftonline.com/{tenantid}/v2.0` may be used with any matching token issuer.

+ - Keys that have an issuer value like `https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0` should only be used with exact match.

+ Azure AD's tenant-independent key endpoint ([https://login.microsoftonline.com/common/discovery/v2.0/keys](https://login.microsoftonline.com/common/discovery/v2.0/keys)) returns a document like:

+ ```

+ {

+ "keys":[

+ {"kty":"RSA","use":"sig","kid":"jS1Xo1OWDj_52vbwGNgvQO2VzMc","x5t":"jS1Xo1OWDj_52vbwGNgvQO2VzMc","n":"spv...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},

+ {"kty":"RSA","use":"sig","kid":"2ZQpJ3UpbjAYXYGaXEJl8lV0TOI","x5t":"2ZQpJ3UpbjAYXYGaXEJl8lV0TOI","n":"wEM...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},

+ {"kty":"RSA","use":"sig","kid":"yreX2PsLi-qkbR8QDOmB_ySxp8Q","x5t":"yreX2PsLi-qkbR8QDOmB_ySxp8Q","n":"rv0...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0"}

+ ]

+ }

+ ```

+ 3. Applications that use Azure AD's tenantid (`tid`) claim as a trust boundary instead of the standard issuer claim should ensure that the tenant-id claim is a guid and that the issuer and tenantid match.

+Using tenant-independent metadata is more efficient for applications which accept tokens from many tenants.

+> [!NOTE]

+> With Azure AD tenant-independent metadata, claims should be interpreted within the tenant, just as under standard OpenID Connect, claims are interpreted within the issuer. That is, `{"sub":"ABC123","iss":"https://login.microsoftonline.com/8eaef023-2b34-4da1-9baa-8bc8c9d6a490/v2.0","tid":"8eaef023-2b34-4da1-9baa-8bc8c9d6a490"}` and `{"sub":"ABC123","iss":"https://login.microsoftonline.com/82229342-1101-4ab6-817b-70c0747630f3/v2.0","tid":"82229342-1101-4ab6-817b-70c0747630f3"}` describe different users, even though the `sub` is the same, because claims like `sub` are interpreted within the context of the issuer/tenant.

+If the application has custom signing keys as a result of using the [claims-mapping](./saml-claims-customization.md) feature, append an `appid` query parameter that contains the application ID. For validation, use `jwks_uri` that points to the signing key information of the application. For example: `https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391e` contains a `jwks_uri` of `https://login.microsoftonline.com/{tenant}/discovery/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391e`.

+> To include additional claims in your id_token, refer to the optional claims documentation in [How to: Provide optional claims to your Azure AD app](./optional-claims.md)

+```

+Any changes that you make to your application object are also reflected in its service principal object in the application's home tenant only (the tenant where it was registered). This means that deleting an application object will also delete its home tenant service principal object. However, restoring that application object through the app registrations UI won't restore its corresponding service principal. For more information on deletion and recovery of applications and their service principal objects, see [delete and recover applications and service principal objects](../manage-apps/delete-recover-faq.yml).

+If you're building a service on Azure AD that exposes APIs for other clients to call, you may wish to support automated access with app roles (app-only permissions). You can define the app roles for your application in the **App roles** section of your app registration in Azure AD portal. For more information on how to create app roles, see [Declare roles for an application](./howto-add-app-roles-in-apps.md#declare-roles-for-an-application).

+- [Learn how to create and assign app roles in Azure AD](./howto-add-app-roles-in-apps.md)

+The actual user experience of granting consent will differ depending on policies set on the user's tenant, the user's scope of authority (or role), and the type of [permissions](./permissions-consent-overview.md) being requested by the client application. This means that application developers and tenant admins have some control over the consent experience. Admins have the flexibility of setting and disabling policies on a tenant or app to control the consent experience in their tenant. Application developers can dictate what types of permissions are being requested and if they want to guide users through the user consent flow or the admin consent flow.

+- Learn [how to configure the app's publisher domain](howto-configure-publisher-domain.md).

+The Microsoft identity platform supports authentication for different kinds of modern application architectures. All of the architectures are based on the industry-standard protocols [OAuth 2.0 and OpenID Connect](./v2-protocols.md). By using the [authentication libraries for the Microsoft identity platform](reference-v2-libraries.md), applications authenticate identities and acquire tokens to access protected APIs.

+Scenarios that involve acquiring tokens also map to OAuth 2.0 authentication flows. For more information, see [OAuth 2.0 and OpenID Connect protocols on the Microsoft identity platform](./v2-protocols.md).

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

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

+* **OAuth versus OpenID Connect**: The platform uses OAuth for authorization and OpenID Connect (OIDC) for authentication. OpenID Connect is built on top of OAuth 2.0, so the terminology and flow are similar between the two. You can even both authenticate a user (through OpenID Connect) and get authorization to access a protected resource that the user owns (through OAuth 2.0) in one request. For more information, see [OAuth 2.0 and OpenID Connect protocols](./v2-protocols.md) and [OpenID Connect protocol](v2-protocols-oidc.md).

+In advanced RBAC implementations, roles may be mapped to collections of permissions, where a permission describes a granular action or activity that can be performed. Roles are then configured as combinations of permissions. Compute the overall permission set for an entity by combining the permissions granted to the various roles the entity is assigned. A good example of this approach is the RBAC implementation that governs access to resources in Azure subscriptions.

+If you're interested in using a JWT issued by another identity provider as a credential for your application, please see [workload identity federation](../workload-identities/workload-identity-federation.md) for how to set up a federation policy.

+The **xms_cc** claim with a value of "cp1" in the access token is the authoritative way to identify a client application is capable of handling a claims challenge. **xms_cc** is an optional claim that will not always be issued in the access token, even if the client sends a claims request with "xms_cc". In order for an access token to contain the **xms_cc** claim, the resource application (that is, the API implementer) must request xms_cc as an [optional claim](./optional-claims.md) in its application manifest. When requested as an optional claim, **xms_cc** will be added to the access token only if the client application sends **xms_cc** in the claims request. The value of the **xms_cc** claim request will be included as the value of the **xms_cc** claim in the access token, if it is a known value. The only currently known value is **cp1**.

+This is how the app's manifest looks like after the **xms_cc** [optional claim](./optional-claims.md) has been requested

+- To learn more about how to configure this policy see [Customize app SAML token claims](./saml-claims-customization.md)

+In an [OpenID Connect or OAuth 2.0](./v2-protocols.md) authorization request, an application can request the permissions it needs by using the `scope` query parameter. For example, when a user signs in to an app, the application sends a request like the following example. (Line breaks are added for legibility).

+To sign the user in, follow the [Microsoft identity platform protocol tutorials](./v2-protocols.md).

+For more information about the OAuth 2.0 protocol and how to get access tokens, see the [Microsoft identity platform endpoint protocol reference](./v2-protocols.md).

+- [Access tokens](access-tokens.md)

+- **Integration with other data stores that can't be synced to the directory** - You may have third-party systems, or your own systems that store user data. Ideally this information could be consolidated, either through [synchronization](../hybrid/cloud-sync/what-is-cloud-sync.md) or direct migration, in the Azure AD directory. However, that isn't always feasible. The restriction may be because of data residency, regulations, or other requirements.

+- To learn how to customize the claims emitted in tokens for a specific application in their tenant using PowerShell, see [How to: Customize claims emitted in tokens for a specific app in a tenant](./saml-claims-customization.md)

+- To learn how to customize claims issued in the SAML token through the Azure portal, see [How to: Customize claims issued in the SAML token for enterprise applications](./saml-claims-customization.md)

+- To learn more about extension attributes, see [Using directory extension attributes in claims](./schema-extensions.md).

+Role-based access control (RBAC) allows certain users or groups to have specific permissions to access and manage resources. Application RBAC differs from [Azure role-based access control](../../role-based-access-control/overview.md) and [Azure AD role-based access control](../roles/custom-overview.md#understand-azure-ad-role-based-access-control). Azure custom roles and built-in roles are both part of Azure RBAC, which is used to help manage Azure resources. Azure AD RBAC is used to manage Azure AD resources. This article explains application-specific RBAC. For information about implementing application-specific RBAC, see [How to add app roles to your application and receive them in the token](./howto-add-app-roles-in-apps.md).

+- Determine the application behavior based on the roles assigned to the current user.

+Azure AD allows you to [define app roles](./howto-add-app-roles-in-apps.md) for your application and assign those roles to users and other applications. The roles you assign to a user or application define their level of access to the resources and operations in your application.

+Developers can also use [Azure AD groups](../fundamentals/concept-learn-about-groups.md) to implement RBAC in their applications, where the memberships of the user in specific groups are interpreted as their role memberships. When an organization uses groups, the token includes a [groups claim](./access-token-claims-reference.md#payload-claims). The group claim specifies the identifiers of all of the assigned groups of the user within the tenant.

+See [consent framework](./application-consent-experience.md) for more information.

+An identity used by a software workload like an application, service, script, or container to authenticate and access other services and resources. In Azure AD, workload identities are apps, service principals, and managed identities. For more information, see [workload identity overview](../workload-identities/workload-identities-overview.md).

+Allows you to securely access Azure AD protected resources from external apps and services without needing to manage secrets (for supported scenarios). For more information, see [workload identity federation](../workload-identities/workload-identity-federation.md).

+- [OAuth 2.0 and OpenID Connect (OIDC) in the Microsoft identity platform](./v2-protocols.md)

+[AAD-Auth-Scenarios]:./authentication-vs-authorization.md

+[AAD-Dev-Guide]:../develop.md

+[AAD-How-Subscriptions-Assoc]:../fundamentals/how-subscriptions-associated-directory.md

+[AAD-How-To-Integrate]: ./how-to-integrate.md

+[AAD-Integrating-Apps]:./quickstart-register-app.md

+[AAD-Security-Token-Claims]: ./authentication-vs-authorization.md#claims-in-azure-ad-security-tokens

+> This article explains how to create, update, or delete application roles on the service principal using APIs. To use the new user interface for App Roles, see [Add app roles to your application and receive them in the token](./howto-add-app-roles-in-apps.md).

+- Directory schema extension attributes - [Extend the schema of service principal and user objects](./schema-extensions.md) to store additional data in Azure AD

+**Industry standard protocols.** Microsoft is committed to supporting industry standards. The Microsoft identity platform supports the industry-standard OAuth 2.0 and OpenID Connect 1.0 protocols. Learn more about the [Microsoft identity platform authentication protocols](./v2-protocols.md).

+[AAD-App-Manifest]:./reference-app-manifest.md

+[AAD-Auth-Scenarios]:./authentication-vs-authorization.md

+[AAD-Consent-Overview]:./application-consent-experience.md

+[AAD-Integrating-Apps]:./quickstart-register-app.md

+[AAD-Why-To-Integrate]: ./how-to-integrate.md

+[AAD-App-Manifest]:./reference-app-manifest.md

+[AAD-Auth-Scenarios]:./authentication-vs-authorization.md

+[AAD-Integrating-Apps]:./quickstart-register-app.md

+[AAD-Dev-Guide]:../develop.md

+[AAD-How-To-Integrate]: ./how-to-integrate.md

+[AAD-Security-Token-Claims]: ./authentication-vs-authorization.md#claims-in-azure-ad-security-tokens

+[Manage certificates for federated single sign-on in Azure Active Directory](../manage-apps/tutorial-manage-certificates-for-federated-single-sign-on.md)

+Azure Active Directory Authentication Library (ADAL) has been deprecated. While existing apps that use ADAL continue to work, Microsoft will no longer release security fixes on ADAL. Use the [Microsoft Authentication Library (MSAL)](/entr). This article provides guidance on how to use Azure Monitor workbooks to obtain a list of all apps that use ADAL in your tenant.

+- **App Roles** ΓÇô using the [App Roles feature in an application](./howto-add-app-roles-in-apps.md#declare-roles-for-an-application) using logic within the application to interpret incoming app role assignments.

+The first step for implementing RBAC for an application is to define the app roles for it and assign users or groups to it. This process is outlined in [How to: Add app roles to your application and receive them in the token](./howto-add-app-roles-in-apps.md). After defining the app roles and assigning users or groups to them, access the role assignments in the tokens coming into the application and act on them accordingly.

+- Read more on [permissions and consent in the Microsoft identity platform](./permissions-consent-overview.md).

+- [How to: Add app roles in your application](./howto-add-app-roles-in-apps.md)

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

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

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

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

+ to store and regularly rotate your credentials.

+. Only use application permissions if necessary; use delegated permissions where possible. For a full list of Microsoft Graph permissions, see this [permissions reference](/graph/permissions-reference).

+* [Microsoft identity platform protocols reference](./v2-protocols.md)

+* [Permissions and consent in the Microsoft identity platform](./permissions-consent-overview.md)

+Without this, Azure AD returns an [AADSTS50146 error code](./reference-error-codes.md#aadsts-error-codes).

+[Permissions and consent in the Microsoft identity platform](./permissions-consent-overview.md) and the [Scopes for a Web API accepting v1.0 tokens](./msal-v1-app-scopes.md) articles.

+You can read more information about using the "/.default" scope [here](./permissions-consent-overview.md).

+Learn more about [Authentication flows and application scenarios](authentication-flows-app-scenarios.md)

+For more details about the different types of scopes, refer to [Permissions and consent in the Microsoft identity platform](./permissions-consent-overview.md) and the [Scopes for a Web API accepting v1.0 tokens](./msal-v1-app-scopes.md) articles.

+Azure Active Directory Authentication Library (ADAL) has been deprecated. Please use the [Microsoft Authentication Library (MSAL)](/entr).

+[Scopes](./permissions-consent-overview.md) are the permissions that a web API exposes that client applications can request access to. Client applications request the user's consent for these scopes when making authentication requests to get tokens to access the web APIs. MSAL allows you to get tokens to access Azure AD for developers (v1.0) and the Microsoft identity platform APIs. v2.0 protocol uses scopes instead of resource in the requests. Based on the web API's configuration of the token version it accepts, the v2.0 endpoint returns the access token to MSAL.

+ - For information about ROPC in MSAL.NET and Azure AD B2C, see [Using ROPC with Azure AD B2C](./msal-net-b2c-considerations.md#resource-owner-password-credentials-ropc).

+For more information on consent, see [Permissions and consent](./permissions-consent-overview.md#consent).

+- Users **cannot** obtain tokens for Microsoft APIs (for example, MS Graph API) using [delegated permissions](./permissions-consent-overview.md#permission-types).

+- Users with administrator privileges **can** obtain tokens for Microsoft APIs (for example, MS Graph API) using [delegated permissions](./permissions-consent-overview.md#permission-types).

+To use a session ID, add `sid` as an [optional claim](./optional-claims.md) to your app's ID tokens. The `sid` claim allows an application to identify a user's Azure AD session independent of their account name or username. To learn how to add optional claims like `sid`, see [Provide optional claims to your app](./optional-claims.md). Use the session ID (SID) in silent authentication requests you make with `ssoSilent` in MSAL.js.

+- [Optional token claims](./optional-claims.md)

+MSAL is designed to enable a secure solution without developers having to worry about the implementation details. It simplifies and manages acquiring, managing, caching, and refreshing tokens, and uses best practices for resilience. We recommend you use MSAL to [increase the resilience of authentication and authorization in client applications that you develop](../architecture/resilience-client-app.md?tabs=csharp#use-the-microsoft-authentication-library-msal).

+- [How to: Get a complete list of apps using ADAL in your tenant](./howto-get-list-of-all-auth-library-apps.md)

+The [claims expected by Azure AD](./certificate-credentials.md) in the signed assertion are:

+| N/A | `getAuthCodeUrl` | A new method that abstracts [authorize endpoint](./v2-protocols.md#endpoints) URL construction |

+| `xms_edov` | Boolean value indicating whether the user's email domain owner has been verified. | JWT | | An email is considered to be domain verified if it belongs to the tenant where the user account resides and the tenant admin has done verification of the domain. Also, the email must be from a Microsoft account (MSA), a Google account, or used for authentication using the one-time passcode (OTP) flow. Facebook and SAML/WS-Fed accounts **do not** have verified domains. For this claim to be returned in the token, the presence of the `email` claim is required. |

+| `xms_pdl` | Preferred data location | JWT | | For Multi-Geo tenants, the preferred data location is the three-letter code showing the geographic region the user is in. For more information, see the [Azure AD Connect documentation about preferred data location](../hybrid/connect/how-to-connect-sync-feature-preferreddatalocation.md). |

+> The number of groups emitted in a token are limited to 150 for SAML assertions and 200 for JWT, including nested groups. For more information about group limits and important caveats for group claims from on-premises attributes, see [Configure group claims for applications](../hybrid/connect/how-to-connect-fed-group-claims.md).

+<a id ='requesting-consent-for-an-entire-tenant'></a>

+<a id ='using-the-admin-consent-endpoint'></a>

+<a id ='openid-connect-scopes'></a>

+<a id ='admin-restricted-permissions'></a>

+<a id ='the-default-scope'></a>

+<a id ='scopes-and-permissions'></a>

+App-only access uses app roles instead of delegated scopes. When granted through consent, app roles may also be called applications permissions. For app-only access, the client app must be granted appropriate app roles of the resource app it's calling in order to access the requested data. For more information about assigning app roles to client applications, see [Assigning app roles to applications](./howto-add-app-roles-in-apps.md#assign-app-roles-to-applications).

+<a id='permission-types'></a>

+<a id='requesting-individual-user-consent'></a>

+Depending on the permissions they require, some applications might require an administrator to be the one who grants consent. For example, application permissions and many high-privilege delegated permissions can only be consented to by an administrator. Administrators can grant consent for themselves or for the entire organization. For more information about user and admin consent, see [user and admin consent overview](../manage-apps/user-admin-consent-overview.md).

+- [User and admin consent overview](../manage-apps/user-admin-consent-overview.md)

+Publisher verification primarily is for developers who build multitenant apps that use [OAuth 2.0 and OpenID Connect](./v2-protocols.md) with the [Microsoft identity platform](v2-overview.md). These types of apps can sign in a user by using OpenID Connect, or they can use OAuth 2.0 to request access to data by using APIs like [Microsoft Graph](https://developer.microsoft.com/graph/).

+ Using a plaintext secret in the source code poses an increased security risk for your application. Although the sample in this quickstart uses a plaintext client secret, it's only for simplicity. We recommend using [certificate credentials](./certificate-credentials.md) instead of client secrets in your confidential client applications, especially those apps you intend to deploy to production.

+If you don't already have an Azure AD tenant or if you want to create a new one for development, see [Create a new tenant in Azure AD](../fundamentals/create-new-tenant.md) or use the [directory creation experience](https://portal.azure.com/#create/Microsoft.AzureActiveDirectory) in the Azure portal. If you want to create a tenant for app testing, see [build a test environment](test-setup-environment.md).

+> [Tutorial: Sign in users and call Microsoft Graph](./single-page-app-tutorial-01-register-app.md)

+> 1. If access to multiple tenants is available, 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 tenant in which to register the application.

+> 

+> > [Add sign-in to an ASP.NET web app](./web-app-tutorial-01-register-application.md)

+> > [Tutorial: Sign in users and call Microsoft Graph](./single-page-app-tutorial-01-register-app.md)

+> 

+> > This quickstart application uses a client secret to identify itself as confidential client. Because the client secret is added as a plain-text to your project files, for security reasons, it is recommended that you use a certificate instead of a client secret before considering the application as production application. For more information on how to use a certificate, see [these instructions](./certificate-credentials.md).

+> [Add sign-in to an ASP.NET web app](./web-app-tutorial-01-register-application.md)

+> This quickstart application uses a client secret to identify itself as a confidential client. Because the client secret is added as plain text to your project files, for security reasons we recommend that you use a certificate instead of a client secret before using the application in a production environment. For more information on how to use a certificate, see [Certificate credentials for application authentication](./certificate-credentials.md).

+> [Scenario: Web app that signs in users](scenario-web-app-sign-user-overview.md?tabs=java)

+ [!INCLUDE [Virtual environment setup](../../app-service/includes/quickstart-python/virtual-environment-setup.md)]

+ > This quickstart application uses a client secret to identify itself as confidential client. Because the client secret is added as a plain-text to your project files, for security reasons, it is recommended that you use a certificate instead of a client secret before considering the application as production application. For more information on how to use a certificate, see [these instructions](./certificate-credentials.md).

+As documented on the [apiApplication resource type](/graph/api/resources/apiapplication#properties), this allows an application to use [claims mapping](./saml-claims-customization.md) without specifying a custom signing key. Applications that receive tokens rely on the fact that the claim values are authoritatively issued by Azure AD and cannot be tampered with. However, when you modify the token contents through claims-mapping policies, these assumptions may no longer be correct. Applications must explicitly acknowledge that tokens have been modified by the creator of the claims-mapping policy to protect themselves from claims-mapping policies created by malicious actors.

+Specifies the collection of roles that an app may declare. These roles can be assigned to users, groups, or service principals. For more examples and info, see [Add app roles in your application and receive them in the token](./howto-add-app-roles-in-apps.md).

+At this time, apps that support both personal accounts and Azure AD (registered through the app registration portal) cannot use optional claims. However, apps registered for just Azure AD using the v2.0 endpoint can get the optional claims they requested in the manifest. For more info, see [Optional claims](./optional-claims.md).

+[ADD-UPD-RMV-APP]:./quickstart-register-app.md

+[IMPLICIT-GRANT]:./v2-oauth2-implicit-grant-flow.md

+**Protocol impacted**: All flows using [dynamic consent](./permissions-consent-overview.md#requesting-individual-user-consent)

+- Any [optional claims](./optional-claims.md) that the application has chosen to receive.

+| AADSTS50000 | TokenIssuanceError - There's an issue with the sign-in service. [Open a support ticket](../fundamentals/how-to-get-support.md) to resolve this issue. |

+| AADSTS50007 | PartnerEncryptionCertificateMissing - The partner encryption certificate was not found for this app. [Open a support ticket](../fundamentals/how-to-get-support.md) with Microsoft to get this fixed. |

+| AADSTS50055 | InvalidPasswordExpiredPassword - The password is expired. The user's password is expired, and therefore their login or session was ended. They will be offered the opportunity to reset it, or may ask an admin to reset it via [Reset a user's password using Azure Active Directory](../fundamentals/users-reset-password-azure-portal.md). |

+| AADSTS50140 | KmsiInterrupt - This error occurred due to "Keep me signed in" interrupt when the user was signing-in. This is an expected part of the login flow, where a user is asked if they want to remain signed into their current browser to make further logins easier. For more information, see [The new Azure AD sign-in and ΓÇ£Keep me signed inΓÇ¥ experiences rolling out now!](https://techcommunity.microsoft.com/t5/azure-active-directory-identity/the-new-azure-ad-sign-in-and-keep-me-signed-in-experiences/m-p/128267). You can [open a support ticket](../fundamentals/how-to-get-support.md) with Correlation ID, Request ID, and Error code to get more details.|

+| AADSTS50143 | Session mismatch - Session is invalid because user tenant doesn't match the domain hint due to different resource. [Open a support ticket](../fundamentals/how-to-get-support.md) with Correlation ID, Request ID, and Error code to get more details. |

+| AADSTS70012 | MsaServerError - A server error occurred while authenticating an MSA (consumer) user. Try again. If it continues to fail, [open a support ticket](../fundamentals/how-to-get-support.md) |

+| AADSTS80005 | OnPremisePasswordValidatorUnpredictableWebException - An unknown error occurred while processing the response from the Authentication Agent. Retry the request. If it continues to fail, [open a support ticket](../fundamentals/how-to-get-support.md) to get more details on the error. |

+| AADSTS90036 | MsodsServiceUnretryableFailure - An unexpected, non-retryable error from the WCF service hosted by MSODS has occurred. [Open a support ticket](../fundamentals/how-to-get-support.md) to get more details on the error. |

+| AADSTS7000222 | InvalidClientSecretExpiredKeysProvided - The provided client secret keys are expired. Visit the Azure portal to create new keys for your app, or consider using certificate credentials for added security: [https://aka.ms/certCreds](./certificate-credentials.md) |

+* Add [custom and optional claims](./optional-claims.md) to the tokens for your application.

+If you choose to hand-code your own protocol-level implementation of [OAuth 2.0 or OpenID Connect 1.0](./v2-protocols.md), pay close attention to the security considerations in each standard's specification and follow secure software design and development practices like those in the [Microsoft SDL][Microsoft-SDL].

+- [Invalidate refresh token](/powershell/module/microsoft.graph.beta.users.actions/invoke-mgbetainvalidateuserrefreshtoken?view=graph-powershell-beta)

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

+| `Directory extensions` | The directory extensions [synced from on-premises Active Directory using Azure AD Connect Sync](../hybrid/connect/how-to-connect-sync-feature-directory-extensions.md). |

+The `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn` claim is part of the [SAML restricted claim set](reference-claims-mapping-policy-type.md), so you can't add it in the **Attributes & Claims** section. As a workaround, you can add it as an [optional claim](./optional-claims.md) through **App registrations** in the Azure portal.

+* [Configure single sign-on for applications that aren't in the Azure AD application gallery](./single-sign-on-saml-protocol.md)

+If your daemon app calls your own web API and you weren't able to add an app permission to the daemon's app registration, you need to [Add app roles to the web API's app registration](./howto-add-app-roles-in-apps.md).

+You'll need to explain to your customers how to perform these operations. For more info, see [Requesting consent for an entire tenant](./permissions-consent-overview.md#requesting-consent-for-an-entire-tenant).

+ - Or, you've provided a way for users to consent to the application. For more information, see [Requesting individual user consent](./permissions-consent-overview.md#requesting-individual-user-consent).

+ - Or, you've provided a way for the tenant admin to consent to the application. For more information, see [Admin consent](./permissions-consent-overview.md#requesting-consent-for-an-entire-tenant).

+For more information on consent, see the [Microsoft identity platform permissions and consent](./permissions-consent-overview.md).

+To expose application permissions, follow the steps in [Add app roles to your app](./howto-add-app-roles-in-apps.md).

+Users can also use roles claims in user assignment patterns, as shown in [How to add app roles in your application and receive them in the token](./howto-add-app-roles-in-apps.md). If the roles are assignable to both, checking roles will let apps sign in as users and users sign in as apps. We recommend that you declare different roles for users and apps to prevent this confusion.

+To learn more, see [Optional claims](./optional-claims.md).

+SAML and OpenID Connect (OIDC) / OAuth are popular protocols used to implement single sign-on (SSO). Some apps might only implement SAML and others might only implement OIDC/OAuth. Both protocols use tokens to communicate secrets. To learn more about SAML, see [single sign-on SAML protocol](single-sign-on-saml-protocol.md). To learn more about OIDC/OAuth, see [OAuth 2.0 and OpenID Connect protocols on Microsoft identity platform](./v2-protocols.md).

+- Configure Azure AD Connect to create them and to sync data into them from on-premises. See [Azure AD Connect Sync Directory Extensions](../hybrid/connect/how-to-connect-sync-feature-directory-extensions.md).

+If an application needs to send claims with data from an extension attribute that's registered on a different application, a [claims mapping policy](./saml-claims-customization.md) must be used to map the extension attribute to the claim.

+- Learn how to [customize claims emitted in tokens for a specific app](./saml-claims-customization.md).

+The Microsoft identity platform implements the [OAuth 2.0](./v2-protocols.md) authorization protocol. OAuth 2.0 is a method through which a third-party app can access web-hosted resources on behalf of a user. Any web-hosted resource that integrates with the Microsoft identity platform has a resource identifier, or *application ID URI*.

+If an app signs in by using [OpenID Connect](./v2-protocols.md), it must request the `openid` scope. The `openid` scope appears on the work account consent page as the **Sign you in** permission.

+On the Microsoft identity platform (requests made to the v2.0 endpoint), your app must explicitly request the `offline_access` scope, to receive refresh tokens. So when you redeem an authorization code in the [OAuth 2.0 authorization code flow](./v2-protocols.md), you'll receive only an access token from the `/token` endpoint.

+For more information about how to get and use refresh tokens, see the [Microsoft identity platform protocol reference](./v2-protocols.md).

+To define app roles (application permissions) for a web API, see [Add app roles in your application](./howto-add-app-roles-in-apps.md).

+While developing an application, authorize access with the groups claim. To learn more, see how to [configure group claims for applications with Azure AD](../hybrid/connect/how-to-connect-fed-group-claims.md).

+- [Manage app and resource access using Azure Active Directory groups](../fundamentals/concept-learn-about-groups.md)

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

+- Always use [certificate credentials](./certificate-credentials.md) whenever possible and don't use password credentials, also known as *secrets*. While it's convenient to use password secrets as a credential, when possible use x509 certificates as the only credential type for getting tokens for an application.

+* [OAuth 2.0](./v2-protocols.md)

+* Applications added from Azure AD Application Gallery (including Custom) have separate guidance with regard to signing keys. [More information.](../manage-apps/tutorial-manage-certificates-for-federated-single-sign-on.md)

+- Provide appropriate names and descriptions for any permissions you expose as part of your app. This helps users and admins know what they're agreeing to when they attempt to use your app's APIs. For more information, see the best practices section in the [permissions guide](./permissions-consent-overview.md).

+> > [Tutorial: Sign in users and call Microsoft Graph from a React single-page app](./single-page-app-tutorial-01-register-app.md)

+> * ROPC is not supported in [hybrid identity federation](../hybrid/connect/whatis-fed.md) scenarios (for example, Azure AD and Active Directory Federation Services (AD FS) used to authenticate on-premises accounts). If users are full-page redirected to an on-premises identity provider, Azure AD is not able to test the username and password against that identity provider. [Pass-through authentication](../hybrid/connect/how-to-connect-pta.md) is supported with ROPC, however.

+Because the app is a multi-tenant app for Microsoft business customers, it must provide a way for customers to "sign up" or "connect" the application to their company data. During the connection flow, a Global Administrator first grants *application permissions* directly to the app so that it can access company data in a non-interactive fashion, without the presence of a signed-in user. The majority of the logic in this sample shows how to achieve this connection flow by using the identity platform's [admin consent](./permissions-consent-overview.md#using-the-admin-consent-endpoint) endpoint.

+> Any plaintext secret in source code poses an increased security risk. This article uses a plaintext client secret for simplicity only. Use [certificate credentials](./certificate-credentials.md) instead of client secrets in your confidential client applications, especially those apps you intend to deploy to production.

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

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

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

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

+For web apps (.NET, PHP, Java, Ruby, Python, Node) that the user accesses through a browser, you can use [OpenID Connect](./v2-protocols.md) for user sign-in. In OpenID Connect, the web app receives an ID token. An ID token is a security token that verifies the user's identity and provides information about the user in the form of claims:

+A web API can give users the power to opt in or opt out of specific functionality or data by exposing permissions, also known as [scopes](./permissions-consent-overview.md). For a calling app to acquire permission to a scope, the user must consent to the scope during a flow. The Microsoft identity platform asks the user for permission, and then records permissions in all access tokens that the web API receives. The web API validates the access tokens it receives on each call and performs authorization checks.

+Now that you're familiar with the types of applications supported by the Microsoft identity platform, learn more about [OAuth 2.0 and OpenID Connect](./v2-protocols.md) to gain an understanding of the protocol components used by the different scenarios.

+Azure AD Conditional Access is a feature included in [Azure AD Premium](../fundamentals/whatis.md). Customers with [Microsoft 365 Business licenses](/office365/servicedescriptions/office-365-service-descriptions-technet-library) also have access to Conditional Access features.

+> * ROPC is not supported in [hybrid identity federation](../hybrid/connect/whatis-fed.md) scenarios (for example, Azure AD and ADFS used to authenticate on-premises accounts). If users are full-page redirected to an on-premises identity provider, Azure AD is not able to test the username and password against that identity provider. [Pass-through authentication](../hybrid/connect/how-to-connect-pta.md) is supported with ROPC, however.

+| `scope` | Recommended | A space-separated list of [scopes](./permissions-consent-overview.md), or permissions, that the app requires. In an interactive flow, the admin or the user must consent to these scopes ahead of time. |

+| `client_assertion` | Sometimes required | A different form of `client_secret`, generated using a certificate. For more information, see [certificate credentials](./certificate-credentials.md). |

+| `access_token`| Opaque string | Issued for the [scopes](./permissions-consent-overview.md) that were requested. |

+Some permissions are admin-restricted, for example, writing data to an organization's directory by using `Directory.ReadWrite.All`. If your application requests access to one of these permissions from an organizational user, the user receives an error message that says they're not authorized to consent to your app's permissions. To request access to admin-restricted scopes, you should request them directly from a Global Administrator. For more information, see [Admin-restricted permissions](./permissions-consent-overview.md#admin-restricted-permissions).

+| `tenant` | required | The `{tenant}` value in the path of the request can be used to control who can sign into the application. Valid values are `common`, `organizations`, `consumers`, and tenant identifiers. For guest scenarios where you sign a user from one tenant into another tenant, you *must* provide the tenant identifier to sign them into the resource tenant. For more information, see [Endpoints](./v2-protocols.md#endpoints). |

+| `scope` | required | A space-separated list of [scopes](./permissions-consent-overview.md) that you want the user to consent to. For the `/authorize` leg of the request, this parameter can cover multiple resources. This value allows your app to get consent for multiple web APIs you want to call. |

+| `login_hint` | optional | You can use this parameter to pre-fill the username and email address field of the sign-in page for the user. Apps can use this parameter during reauthentication, after already extracting the `login_hint` [optional claim](./optional-claims.md) from an earlier sign-in. |

+At this point, the user is asked to enter their credentials and complete the authentication. The Microsoft identity platform also ensures that the user has consented to the permissions indicated in the `scope` query parameter. If the user hasn't consented to any of those permissions, it asks the user to consent to the required permissions. For more information, see [Permissions and consent in the Microsoft identity platform](./permissions-consent-overview.md).

+All confidential clients have a choice of using client secrets or certificate credentials. Symmetric shared secrets are generated by the Microsoft identity platform. Certificate credentials are asymmetric keys uploaded by the developer. For more information, see [Microsoft identity platform application authentication certificate credentials](./certificate-credentials.md).

+| `tenant` | required | The `{tenant}` value in the path of the request can be used to control who can sign into the application. Valid values are `common`, `organizations`, `consumers`, and tenant identifiers. For more information, see [Endpoints](./v2-protocols.md#endpoints). |

+| `scope` | optional | A space-separated list of scopes. The scopes must all be from a single resource, along with OIDC scopes (`profile`, `openid`, `email`). For more information, see [Permissions and consent in the Microsoft identity platform](./permissions-consent-overview.md). This parameter is a Microsoft extension to the authorization code flow, intended to allow apps to declare the resource they want the token for during token redemption.|

+| `tenant` | required | The `{tenant}` value in the path of the request can be used to control who can sign into the application. Valid values are `common`, `organizations`, `consumers`, and tenant identifiers. For more detail, see [Endpoints](./v2-protocols.md#endpoints). |

+| `scope` | optional | A space-separated list of scopes. The scopes must all be from a single resource, along with OIDC scopes (`profile`, `openid`, `email`). For more information, see [permissions, consent, and scopes](./permissions-consent-overview.md). This parameter is a Microsoft extension to the authorization code flow. This extension allows apps to declare the resource they want the token for during token redemption.|

+| `client_assertion` | required for confidential web apps | An assertion, which is a JSON web token (JWT), that you need to create and sign with the certificate you registered as credentials for your application. Read about [certificate credentials](./certificate-credentials.md) to learn how to register your certificate and the format of the assertion.|

+| `tenant` | required | The `{tenant}` value in the path of the request can be used to control who can sign into the application. Valid values are `common`, `organizations`, `consumers`, and tenant identifiers. For more information, see [Endpoints](./v2-protocols.md#endpoints). |

+| `scope` | optional | A space-separated list of scopes. The scopes requested in this leg must be equivalent to or a subset of the scopes requested in the original `authorization_code` request leg. If the scopes specified in this request span multiple resource server, then the Microsoft identity platform returns a token for the resource specified in the first scope. For more information, see [Permissions and consent in the Microsoft identity platform](./permissions-consent-overview.md). |

+To use app roles (application permissions) with your own API (as opposed to Microsoft Graph), you must first [expose the app roles](./howto-add-app-roles-in-apps.md) in the API's app registration in the Azure portal. Then, [configure the required app roles](./howto-add-app-roles-in-apps.md#assign-app-roles-to-applications) by selecting those permissions in your client application's app registration. If you haven't exposed any app roles in your API's app registration, you won't be able to specify application permissions to that API in your client application's app registration in the Azure portal.

+For more information about application permissions, see [Permissions and consent](./permissions-consent-overview.md#permission-types).

+If you sign the user into your app, you can identify the organization to which the user belongs to before you ask the user to approve the application permissions. Although not strictly necessary, it can help you create a more intuitive experience for your users. To sign the user in, follow the [Microsoft identity platform protocol tutorials](./v2-protocols.md).

+| `scope` | Required | The value passed for the `scope` parameter in this request should be the resource identifier (application ID URI) of the resource you want, affixed with the `.default` suffix. All scopes included must be for a single resource. Including scopes for multiple resources will result in an error. <br/>For the Microsoft Graph example, the value is `https://graph.microsoft.com/.default`. This value tells the Microsoft identity platform that of all the direct application permissions you have configured for your app, the endpoint should issue a token for the ones associated with the resource you want to use. To learn more about the `/.default` scope, see the [consent documentation](./permissions-consent-overview.md#the-default-scope). |

+| `scope` | Required | The value passed for the `scope` parameter in this request should be the resource identifier (application ID URI) of the resource you want, affixed with the `.default` suffix. All scopes included must be for a single resource. Including scopes for multiple resources will result in an error. <br/>For the Microsoft Graph example, the value is `https://graph.microsoft.com/.default`. This value tells the Microsoft identity platform that of all the direct application permissions you have configured for your app, the endpoint should issue a token for the ones associated with the resource you want to use. To learn more about the `/.default` scope, see the [consent documentation](./permissions-consent-overview.md#the-default-scope). |

+| `client_assertion` | Required | An assertion (a JSON web token) that you need to create and sign with the certificate you registered as credentials for your application. Read about [certificate credentials](./certificate-credentials.md) to learn how to register your certificate and the format of the assertion.|

+| `client_assertion` | Required | An assertion (a JWT, or JSON web token) that your application gets from another identity provider outside of Microsoft identity platform, like Kubernetes. The specifics of this JWT must be registered on your application as a [federated identity credential](../workload-identities/workload-identity-federation-create-trust.md). Read about [workload identity federation](../workload-identities/workload-identity-federation.md) to learn how to setup and use assertions generated from other identity providers.|

+Everything in the request is the same as the certificate-based flow, with the crucial exception of the source of the `client_assertion`. In this flow, your application does not create the JWT assertion itself. Instead, your app uses a JWT created by another identity provider. This is called *[workload identity federation](../workload-identities/workload-identity-federation.md)*, where your apps identity in another identity platform is used to acquire tokens inside the Microsoft identity platform. This is best suited for cross-cloud scenarios, such as hosting your compute outside Azure but accessing APIs protected by Microsoft identity platform. For information about the required format of JWTs created by other identity providers, read about the [assertion format](./certificate-credentials.md#assertion-format).

+| `scope` | Required | A space-separated list of [scopes](./permissions-consent-overview.md) that you want the user to consent to. |

+| `access_token`| Opaque string | Issued for the [scopes](./permissions-consent-overview.md) that were requested. |

+| `tenant` | required |The `{tenant}` value in the path of the request can be used to control who can sign into the application. The allowed values are `common`, `organizations`, `consumers`, and tenant identifiers. For more detail, see [protocol basics](./v2-protocols.md#endpoints).Critically, for guest scenarios where you sign a user from one tenant into another tenant, you *must* provide the tenant identifier to correctly sign them into the resource tenant.|

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

+| `login_hint` | optional | You can use this parameter to pre-fill the username and email address field of the sign-in page for the user, if you know the username ahead of time. Often, apps use this parameter during reauthentication, after already extracting the `login_hint` [optional claim](./optional-claims.md) from an earlier sign-in. |

+At this point, the user will be asked to enter their credentials and complete the authentication. The Microsoft identity platform will also ensure that the user has consented to the permissions indicated in the `scope` query parameter. If the user has consented to **none** of those permissions, it will ask the user to consent to the required permissions. For more info, see [permissions, consent, and multi-tenant apps](./permissions-consent-overview.md).

+| `tenant` |required |The `{tenant}` value in the path of the request can be used to control who can sign into the application. The allowed values are `common`, `organizations`, `consumers`, and tenant identifiers. For more detail, see [protocol basics](./v2-protocols.md#endpoints). |

+| `scope` | Required | A space separated list of scopes for the token request. For more information, see [scopes](./permissions-consent-overview.md). |

+| `client_assertion` | Required | An assertion (a JSON web token) that you need to create and sign with the certificate you registered as credentials for your application. To learn how to register your certificate and the format of the assertion, see [certificate credentials](./certificate-credentials.md). |

+| `scope` | Required | A space-separated list of scopes for the token request. For more information, see [scopes](./permissions-consent-overview.md).|

+| scope |required | A space-separated list of scopes for the token request. For more information, see [scopes](./permissions-consent-overview.md). SAML itself doesn't have a concept of scopes, but is used to identify the target SAML application for which you want to receive a token. For this OBO flow, the scope value must always be the SAML Entity ID with `/.default` appended. For example, in case the SAML application's Entity ID is `https://testapp.contoso.com`, then the requested scope should be `https://testapp.contoso.com/.default`. In case the Entity ID doesn't start with a URI scheme such as `https:`, Azure AD prefixes the Entity ID with `spn:`. In that case you must request the scope `spn:<EntityID>/.default`, for example `spn:testapp/.default` in case the Entity ID is `testapp`. The scope value you request here determines the resulting `Audience` element in the SAML token, which may be important to the SAML application receiving the token. |

+The middle tier application adds the client to the [known client applications list](reference-app-manifest.md#knownclientapplications-attribute) (`knownClientApplications`) in its manifest. If a consent prompt is triggered by the client, the consent flow will be both for itself and the middle tier application. On the Microsoft identity platform, this is done using the [`.default` scope](./permissions-consent-overview.md#the-default-scope). The `.default` scope is a special scope that is used to request consent to access all the scopes that the application has permissions for. This is useful when the application needs to access multiple resources, but the user should only be prompted for consent once.

+A tenant admin can guarantee that applications have permission to call their required APIs by providing admin consent for the middle tier application. To do this, the admin can find the middle tier application in their tenant, open the required permissions page, and choose to give permission for the app. To learn more about admin consent, see the [consent and permissions documentation](./permissions-consent-overview.md).

+* [Using the `/.default` scope](./permissions-consent-overview.md#the-default-scope)

+- [Permissions and consent](./permissions-consent-overview.md)

+| `tenant` | Required | You can use the `{tenant}` value in the path of the request to control who can sign in to the application. The allowed values are `common`, `organizations`, `consumers`, and tenant identifiers. For more information, see [protocol basics](./v2-protocols.md#endpoints). Critically, for guest scenarios where you sign a user from one tenant into another tenant, you *must* provide the tenant identifier to correctly sign them into the resource tenant.|

+| `login_hint` | Optional | You can use this parameter to pre-fill the username and email address field of the sign-in page for the user, if you know the username ahead of time. Often, apps use this parameter during reauthentication, after already extracting the `login_hint` [optional claim](./optional-claims.md) from an earlier sign-in. |

+At this point, the user is prompted to enter their credentials and complete the authentication. The Microsoft identity platform verifies that the user has consented to the permissions indicated in the `scope` query parameter. If the user hasn't consented to any of those permissions, the Microsoft identity platform prompts the user to consent to the required permissions. You can read more about [permissions, consent, and multi-tenant apps](./permissions-consent-overview.md).

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

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

+* [Populate claim values in a token](./saml-claims-customization.md) with data from on-premises systems.

+* [Include your own claims in tokens](./optional-claims.md).

+> > [Add sign-in to an ASP.NET web app](./web-app-tutorial-01-register-application.md)

+> > This quickstart application uses a client secret to identify itself as confidential client. Because the client secret is added as a plain-text to your project files, for security reasons, it is recommended that you use a certificate instead of a client secret before considering the application as production application. For more information on how to use a certificate, see [these instructions](./certificate-credentials.md).

+> > [Scenario: Web app that signs in users](scenario-web-app-sign-user-overview.md)

+| Use the [Microsoft Authentication Libraries](./reference-v2-libraries.md) (MSAL). | MSAL is a set of Microsoft Authentication Libraries for developers. With MSAL, users and applications can be authenticated, and tokens can be acquired to access corporate resources using just a few lines of code. MSAL uses modern protocols ([OpenID Connect and OAuth 2.0](./v2-protocols.md)) that remove the need for applications to ever handle a user's credentials directly. This handling of credentials vastly improves the security for both users and applications as the identity provider becomes the security perimeter. Also, these protocols continuously evolve to address new paradigms, opportunities, and challenges in identity security. |

+- When designing APIs, provide granular permissions to allow least-privileged access. Start with dividing the functionality and data access into sections that can be controlled by using [scopes](./permissions-consent-overview.md#scopes-and-permissions) and [App roles](./howto-add-app-roles-in-apps.md). Don't add APIs to existing permissions in a way that changes the semantics of the permission.

+- [Assign a user to administrator roles in Azure Active Directory](../fundamentals/how-subscriptions-associated-directory.md)

+A managed environment can be deployed either through [Password Hash Sync](../hybrid/connect/how-to-connect-password-hash-synchronization.md) or [Pass Through Authentication](../hybrid/connect/how-to-connect-pta-quick-start.md) with Seamless Single Sign On.

+- **On-premises Active Directory**, you need to synchronize them to Azure AD using [Azure AD Connect](../hybrid/connect/how-to-connect-sync-whatis.md).

+You can use this implementation to [require managed devices for cloud app access with Conditional Access](../conditional-access/concept-conditional-access-grant.md).

+- [Azure AD Connect: Device options](../hybrid/connect/how-to-connect-device-options.md)

+- Azure AD Connect or Azure AD Connect cloud sync: To synchronize default user attributes like SAM Account Name, Domain Name, and UPN. For more information, see the article [Attributes synchronized by Azure AD Connect](../hybrid/connect/reference-connect-sync-attributes-synchronized.md#windows-10).

+- You may have to adjust your [domain-based filtering](../hybrid/connect/how-to-connect-sync-configure-filtering.md#domain-based-filtering) in Azure AD Connect to ensure that the data about the required domains is synchronized if you have multiple domains.

+For an overview, see [enterprise State Roaming overview](./enterprise-state-roaming-enable.md).

+For an overview, see [enterprise state roaming overview](./enterprise-state-roaming-enable.md).

+For an overview, see [enterprise state roaming overview](./enterprise-state-roaming-enable.md).

+ - Don't exclude the default device attributes from your Azure AD Connect sync configuration. To learn more about default device attributes synced to Azure AD, see [Attributes synchronized by Azure AD Connect](../hybrid/connect/reference-connect-sync-attributes-synchronized.md#windows-10).

+ - If the computer objects of the devices you want to be hybrid Azure AD joined belong to specific organizational units (OUs), configure the correct OUs to sync in Azure AD Connect. To learn more about how to sync computer objects by using Azure AD Connect, see [Organizational unitΓÇôbased filtering](../hybrid/connect/how-to-connect-sync-configure-filtering.md#organizational-unitbased-filtering).

+We think most organizations will deploy hybrid Azure AD join with managed domains. Managed domains use [password hash sync (PHS)](../hybrid/connect/whatis-phs.md) or [pass-through authentication (PTA)](../hybrid/connect/how-to-connect-pta.md) with [seamless single sign-on](../hybrid/connect/how-to-connect-sso.md). Managed domain scenarios don't require configuring a federation server.

+⁴ A **Managed** identity infrastructure environment represents an environment with Azure AD as the identity provider deployed with either [password hash sync (PHS)](../hybrid/connect/whatis-phs.md) or [pass-through authentication (PTA)](../hybrid/connect/how-to-connect-pta.md) with [seamless single sign-on](../hybrid/connect/how-to-connect-sso.md).

+- [Configure hybrid Azure Active Directory join for federated environment](./how-to-hybrid-join.md)

+- [Configure hybrid Azure Active Directory join for managed environment](./how-to-hybrid-join.md)

+[Configuring hybrid Azure Active Directory join for federated environment](./how-to-hybrid-join.md)

+For more information about Azure AD, see [What is Azure Active Directory?](../fundamentals/whatis.md).

+1. You may also need to [customize synchronization options](../hybrid/connect/how-to-connect-post-installation.md#additional-tasks-available-in-azure-ad-connect) in Azure AD Connect to enable device synchronization.

+After you verify that everything works as expected, you can automatically register the rest of your Windows current and down-level devices with Azure AD. Automate hybrid Azure AD join by [configuring the SCP using Azure AD Connect](./how-to-hybrid-join.md#configure-hybrid-azure-ad-join).

+ - To get device registration sync join to succeed, as part of the device registration configuration, don't exclude the default device attributes from your Azure AD Connect sync configuration. To learn more about default device attributes synced to Azure AD, see [Attributes synchronized by Azure AD Connect](../hybrid/connect/reference-connect-sync-attributes-synchronized.md#windows-10).

+ - If the computer objects of the devices you want to be hybrid Azure AD joined belong to specific organizational units (OUs), configure the correct OUs to sync in Azure AD Connect. To learn more about how to sync computer objects by using Azure AD Connect, see [Organizational unitΓÇôbased filtering](../hybrid/connect/how-to-connect-sync-configure-filtering.md#organizational-unitbased-filtering).

+- [Device writeback](../hybrid/connect/how-to-connect-device-writeback.md) won't work. This configuration affects [Device based Conditional Access for on-premises apps that are federated using ADFS](/windows-server/identity/ad-fs/operations/configure-device-based-conditional-access-on-premises). This configuration also affects [Windows Hello for Business deployment when using the Hybrid Cert Trust model](/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust).

+- [Groups writeback](../hybrid/connect/how-to-connect-group-writeback-v2.md) won't work. This configuration affects writeback of Office 365 Groups to a forest with Exchange installed.

+- [Seamless SSO](../hybrid/connect/how-to-connect-sso.md) won't work. This configuration affects SSO scenarios that organizations may be using on cross OS or browser platforms, for example iOS or Linux with Firefox, Safari, or Chrome without the Windows 10 extension.

+- [Hybrid Azure AD join for Windows down-level devices in managed environment](./how-to-hybrid-join-downlevel.md) won't work. For example, hybrid Azure AD join on Windows Server 2012 R2 in a managed environment requires Seamless SSO and since Seamless SSO won't work, hybrid Azure AD join for such a setup won't work.

+A managed environment can be deployed either through [Password Hash Sync (PHS)](../hybrid/connect/whatis-phs.md) or [Pass Through Authentication (PTA)](../hybrid/connect/how-to-connect-pta.md) with [Seamless Single Sign On](../hybrid/connect/how-to-connect-sso.md).

+> [Cloud authentication using Staged rollout](../hybrid/connect/how-to-connect-staged-rollout.md) is only supported starting at the Windows 10 1903 update.

+Sometimes, on-premises AD users UPNs are different from your Azure AD UPNs. In these cases, Windows 10 or newer hybrid Azure AD join provides limited support for on-premises AD UPNs based on the [authentication method](../hybrid/connect/choose-ad-authn.md), domain type, and Windows version. There are two types of on-premises AD UPNs that can exist in your environment:

+- **Enterprise State Roaming**: For information about this setting, see [the overview article](./enterprise-state-roaming-enable.md).

+- A Conditional Access policies requiring [managed devices](../conditional-access/concept-conditional-access-grant.md) or [approved client apps](../conditional-access/howto-policy-approved-app-or-app-protection.md) has been triggered.

+Device identities are a prerequisite for scenarios like [device-based Conditional Access policies](../conditional-access/concept-conditional-access-grant.md) and [Mobile Device Management with the Microsoft Intune family of products](/mem/endpoint-manager-overview).

+- To learn more about device-based Conditional Access, see [Configure Azure Active Directory device-based Conditional Access policies](../conditional-access/concept-conditional-access-grant.md).

+* Improve user experience ΓÇô Provide your users with easy access to your organizationΓÇÖs cloud-based resources from both personal and corporate devices. Administrators can enable [Enterprise State Roaming](./enterprise-state-roaming-enable.md) for a unified experience across all Windows devices.

+When technology projects fail, they typically do because of mismatched expectations on impact, outcomes, and responsibilities. To avoid these pitfalls, [ensure that you're engaging the right stakeholders,](../architecture/deployment-plans.md) and that stakeholder roles in the project are well understood.

+We recommend that the initial configuration of your integration method is in a test environment, or with a small group of test devices. See [Best practices for a pilot](../architecture/deployment-plans.md).

+Azure AD registered devices provide support for Bring Your Own Devices (BYOD) and corporate owned devices to SSO to cloud resources. Access to resources is based on the Azure AD [Conditional Access policies](../conditional-access/concept-conditional-access-grant.md) applied to the device and the user.

+- [Enterprise state roaming](./enterprise-state-roaming-enable.md)

+ - For more information, see the "Configure a service connection point" section of [Tutorial: Configure hybrid Azure Active Directory join for federated domains](./how-to-hybrid-join.md#configure-hybrid-azure-ad-join).

+| **DSREG_AUTOJOIN_DISC_WAIT_TIMEOUT** (0x801c001f/-2145648609) | Operation timed out while performing discovery. | Ensure that `https://enterpriseregistration.windows.net` is accessible in the system context. For more information, see the [Network connectivity requirements](./how-to-hybrid-join.md#prerequisites) section. |

+| **WININET_E_CANNOT_CONNECT** (0x80072efd/-2147012867) | Connection with the server couldn't be established. | Ensure network connectivity to the required Microsoft resources. For more information, see [Network connectivity requirements](./how-to-hybrid-join.md#prerequisites). |

+| **WININET_E_TIMEOUT** (0x80072ee2/-2147012894) | General network timeout. | Ensure network connectivity to the required Microsoft resources. For more information, see [Network connectivity requirements](./how-to-hybrid-join.md#prerequisites). |

+| **ERROR_ADAL_INTERNET_TIMEOUT** (0xcaa82ee2/-894947614) | General network timeout. | Ensure that `https://login.microsoftonline.com` is accessible in the system context. Ensure that the on-premises identity provider is accessible in the system context. For more information, see [Network connectivity requirements](./how-to-hybrid-join.md#prerequisites). |

+[hybrid-azure-ad-join-plan]: ./hybrid-join-plan.md

+This article introduces and administrator for Azure Active Directory (Azure AD), part of Microsoft Entra, to the relationship between top [identity management](../fundamentals/whatis.md?context=azure/active-directory/users-groups-roles/context/ugr-context) tasks for users in terms of their groups, licenses, deployed enterprise apps, and administrator roles. As your organization grows, you can use Azure AD groups and administrator roles to:

+Managing user license assignments individually is time consuming and error prone. If you [assign licenses to groups](../fundamentals/license-users-groups.md?context=azure/active-directory/users-groups-roles/context/ugr-context) instead, you experience easier large-scale license management.

+You can use Azure AD to assign group access to [enterprise apps deployed in your Azure AD organization](../manage-apps/assign-user-or-group-access-portal.md?context=azure/active-directory/users-groups-roles/context/ugr-context). If you combine dynamic groups with group assignment to apps, you can automate user app access assignments as your organization grows. You'll need an Azure Active Directory Premium P1 or Premium P2 license to assign access to enterprise apps.

+Or you can start [creating groups](../fundamentals/how-to-manage-groups.md?context=azure/active-directory/users-groups-roles/context/ugr-context), [assigning licenses](../fundamentals/license-users-groups.md?context=azure/active-directory/users-groups-roles/context/ugr-context), [assigning app access](../manage-apps/assign-user-or-group-access-portal.md?context=azure/active-directory/users-groups-roles/context/ugr-context) or [assigning administrator roles](../roles/permissions-reference.md).

+* [How Azure subscriptions are associated with Azure AD](../fundamentals/how-subscriptions-associated-directory.md)

+- [Edit your group settings](../fundamentals/how-to-manage-groups.md)

+* [See existing groups](../fundamentals/groups-view-azure-portal.md)

+* [Create a new group and adding members](../fundamentals/how-to-manage-groups.md)

+* [Manage settings of a group](../fundamentals/how-to-manage-groups.md)

+* [Manage memberships of a group](../fundamentals/how-to-manage-groups.md)

+- [See existing groups](../fundamentals/groups-view-azure-portal.md)

+- [Create a new group and adding members](../fundamentals/how-to-manage-groups.md)

+- [Manage settings of a group](../fundamentals/how-to-manage-groups.md)

+- [Manage memberships of a group](../fundamentals/how-to-manage-groups.md)

+[Custom extension properties](../hybrid/connect/how-to-connect-sync-feature-directory-extensions.md) can be synced from on-premises Windows Server Active Directory, from a connected SaaS application, or created using Microsoft Graph, and are of the format of `user.extension_[GUID]_[Attribute]`, where:

+For more information, see [Use the attributes in dynamic groups](../hybrid/connect/how-to-connect-sync-feature-directory-extensions.md#use-the-attributes-in-dynamic-groups) in the article [Azure AD Connect sync: Directory extensions](../hybrid/connect/how-to-connect-sync-feature-directory-extensions.md).

+- [See existing groups](../fundamentals/groups-view-azure-portal.md)

+- [Create a new group and adding members](../fundamentals/how-to-manage-groups.md)

+- [Manage settings of a group](../fundamentals/how-to-manage-groups.md)

+- [Manage memberships of a group](../fundamentals/how-to-manage-groups.md)

+> [Group licensing basics](../fundamentals/licensing-whatis-azure-portal.md)

+- [See existing groups](../fundamentals/groups-view-azure-portal.md)

+- [Manage settings of a group](../fundamentals/how-to-manage-groups.md)

+- [Manage members of a group](../fundamentals/how-to-manage-groups.md)

+- [Manage memberships of a group](../fundamentals/how-to-manage-groups.md)

+- [View your groups and members](../fundamentals/groups-view-azure-portal.md)

+- [Manage group membership](../fundamentals/how-to-manage-groups.md)

+- [Edit your group settings](../fundamentals/how-to-manage-groups.md)

+- [Manage access to resources using groups](../fundamentals/concept-learn-about-groups.md)

+- [Add an Azure subscription to Azure Active Directory](../fundamentals/how-subscriptions-associated-directory.md)

+- [See existing groups](../fundamentals/groups-view-azure-portal.md)

+- [Manage settings of a group](../fundamentals/how-to-manage-groups.md)

+- [Manage members of a group](../fundamentals/how-to-manage-groups.md)

+- [Manage memberships of a group](../fundamentals/how-to-manage-groups.md)

+* [See existing groups](../fundamentals/groups-view-azure-portal.md)

+* [Manage settings of a group](../fundamentals/how-to-manage-groups.md)

+* [Manage members of a group](../fundamentals/how-to-manage-groups.md)

+* [Manage memberships of a group](../fundamentals/how-to-manage-groups.md)

+* [Managing access to resources with Azure Active Directory groups](../fundamentals/concept-learn-about-groups.md)

+* [What is Azure Active Directory?](../fundamentals/whatis.md)

+* [Manage access to resources with Azure Active Directory groups](../fundamentals/concept-learn-about-groups.md)

+* [What is Azure Active Directory?](../fundamentals/whatis.md)

+* [Managing access to resources with Azure Active Directory groups](../fundamentals/concept-learn-about-groups.md)

+> - [Azure portal](../fundamentals/how-to-manage-groups.md?context=azure/active-directory/users-groups-roles/context/ugr-context)

+For more details, please refer to documentation for the [Azure AD Connect sync service](../hybrid/connect/how-to-connect-syncservice-features.md).

+* [Managing access to resources with Azure Active Directory groups](../fundamentals/concept-learn-about-groups.md?context=azure/active-directory/users-groups-roles/context/ugr-context)

+* [Managing access to resources with Azure Active Directory groups](../fundamentals/concept-learn-about-groups.md)

+* [What is Azure Active Directory?](../fundamentals/whatis.md)

+Group writeback is a valuable tool for administrators of Azure Active Directory (Azure AD) tenants being synced with on-premises Active Directory groups. Microsoft is now previewing new capabilities for group writeback for tenants with an Azure AD Premium license and Azure AD Connect version 2021 December release or later. In this preview, once you have [enabled Azure AD Connect group writeback](../hybrid/connect/how-to-connect-group-writeback-v2.md), you can specify in the Azure portal which groups you want to write back and what youΓÇÖd like each group to write back as. You can write Microsoft 365 groups back to on-premises Active Directory as Distribution, Mail-enabled Security, or Security groups, and write Security groups back as Security groups. Groups are written back with a scope of universalΓÇï.

+```json

+ "isEnabled": true,

+ ...

+}

+- For more about group writeback operations, see [Azure AD Connect group writeback](../hybrid/connect/how-to-connect-group-writeback-v2.md).

+- [What is group-based licensing in Azure Active Directory?](../fundamentals/licensing-whatis-azure-portal.md?context=azure/active-directory/users-groups-roles/context/ugr-context)

+You can configure each Azure AD organization independently to get data synchronized from different AD forests, using the Azure AD Connect tool. See [topologies for Azure AD Connect](../hybrid/connect/plan-connect-topologies.md) for more information on supported topologies when there are multiple Azure AD tenants.

+> Unlike other Azure resources, your Azure AD organizations are not child resources of an Azure subscription. If your Azure subscription is canceled or expired, you can still access your Azure AD organization's data using Azure PowerShell, the Microsoft Graph API, or the Microsoft 365 admin center. You can also [associate another subscription with the organization](../fundamentals/how-subscriptions-associated-directory.md).

+For Azure AD licensing considerations and best practices, see [What is Azure Active Directory licensing?](../fundamentals/licensing-whatis-azure-portal.md).

+> Group license assignment will never modify an existing usage location value on a user. We recommend that you always set usage location as part of your user creation flow in Azure AD (for example, via [Azure AD Connect](../hybrid/connect/whatis-azure-ad-connect.md) configuration). Following such a process ensures the result of license assignment is always correct, and users do not receive services in locations that are not allowed.

+* [What is group-based licensing in Azure Active Directory?](../fundamentals/licensing-whatis-azure-portal.md)

+- [What is group-based licensing in Azure Active Directory?](../fundamentals/licensing-whatis-azure-portal.md?context=azure/active-directory/users-groups-roles/context/ugr-context)

+- [What is group-based licensing in Azure Active Directory?](../fundamentals/licensing-whatis-azure-portal.md)

+* [What is group-based licensing in Azure Active Directory?](../fundamentals/licensing-whatis-azure-portal.md)

+[Group based licensing](../fundamentals/licensing-whatis-azure-portal.md) provides a convenient way to manage license assignment. You can assign one or more product licenses to a group and those licenses are assigned to all members of the group.

+* [What is group-based licensing in Azure Active Directory?](../fundamentals/licensing-whatis-azure-portal.md)

+* [What is group-based licensing in Azure Active Directory?](../fundamentals/licensing-whatis-azure-portal.md)

+* [What is group-based licensing in Azure Active Directory?](../fundamentals/licensing-whatis-azure-portal.md)

+- [Add or update user profile information](../fundamentals/how-to-manage-user-profile-info.md)

+- [Add or change profile information](../fundamentals/how-to-manage-user-profile-info.md)

+- [Add or delete users](../fundamentals/add-users.md)

+* [Password single sign-on](../manage-apps/plan-sso-deployment.md#single-sign-on-options)

+* [Self-service group management/SSAA](groups-self-service-management.md)

+> You should follow the steps in [How-to: Add your organization's privacy info in Azure Active Directory](../fundamentals/properties-area.md) to add the URL of your organization's privacy statement. As part of the first time invitation redemption process, an invited user must consent to your privacy terms to continue.

+Instructions for the legacy create user process can be found in the [Add or delete users](../fundamentals/add-users.md) article.

+6. Under **Manage**, select **Self-service**, and set up self-service app access. (For details, see [how to use self-service app access](../manage-apps/manage-self-service-access.md).)

+We strongly recommend you add both your global privacy contact and your organization's privacy statement so your internal employees and external guests can review your policies. Follow the steps to [add your organization's privacy info](../fundamentals/properties-area.md).

+| Consult Azure AD guidance for securing your collaboration with external partners | Learn how to take a holistic governance approach to your organization's collaboration with external partners by following the recommendations in [Securing external collaboration in Azure Active Directory and Microsoft 365](../architecture/secure-external-access-resources.md). |

+| Add company branding to your sign-in page | You can customize your sign-in page so it's more intuitive for your B2B guest users. See how to [add company branding to sign in and Access Panel pages](../fundamentals/how-to-customize-branding.md). |

+| Add your privacy statement to the B2B guest user redemption experience | You can add the URL of your organization's privacy statement to the first time invitation redemption process so that an invited user must consent to your privacy terms to continue. See [How-to: Add your organization's privacy info in Azure Active Directory](../fundamentals/properties-area.md). |

+[Manage B2B sharing](external-collaboration-settings-configure.md)

+Instructions for the legacy create user process can be found in the [Add or delete users](../fundamentals/add-users.md) article.

+2. The application requires the NameIdentifier claim to be something other than the user principal name [(UPN)](../hybrid/connect/plan-connect-userprincipalname.md#what-is-userprincipalname) that's stored in Azure AD.

+For information about how to add and edit claims, see [Customizing claims issued in the SAML token for enterprise applications in Azure Active Directory](../develop/saml-claims-customization.md).

+1. Sign in to the [Azure portal](https://portal.azure.com) using a Global administrator, Security administrator, or an account with a [custom role](cross-tenant-access-overview.md#custom-roles-for-managing-cross-tenant-access-settings) you've created. Then open the **Azure Active Directory** service.

+- To configure cross-tenant access settings in the Azure portal, you'll need an account with a Global administrator, Security administrator, or a [custom role](#custom-roles-for-managing-cross-tenant-access-settings) you've defined.

+## Custom roles for managing cross-tenant access settings

+Cross-tenant access settings can be managed with custom roles defined by your organization. This enables you to [define your own finely-scoped roles](../roles/custom-create.md) to manage cross-tenant access settings instead of using one of the built-in roles for management.

+Your organization can define custom roles to manage cross-tenant access settings. This allows you to create [your own finely-scoped roles](../roles/custom-create.md) to manage cross-tenant access settings instead of using built-in roles for management.

+### Recommended custom roles

+#### Cross-tenant access administrator

+This role can manage everything in cross-tenant access settings, including default and organizational based settings. This role should be assigned to users who need to manage all settings in cross-tenant access settings.

+Please find the list of recommended actions for this role below.

+| Actions |

+| - |

+| microsoft.directory.tenantRelationships/standard/read |

+| microsoft.directory/crossTenantAccessPolicy/standard/read |

+| microsoft.directory/crossTenantAccessPolicy/allowedCloudEndpoints/update |

+| microsoft.directory/crossTenantAccessPolicy/basic/update |

+| microsoft.directory/crossTenantAccessPolicy/default/b2bCollaboration/update |

+| microsoft.directory/crossTenantAccessPolicy/default/b2bDirectConnect/update |

+| microsoft.directory/crossTenantAccessPolicy/default/crossCloudMeetings/update |

+| microsoft.directory/crossTenantAccessPolicy/default/standard/read |

+| microsoft.directory/crossTenantAccessPolicy/default/tenantRestrictions/update |

+| microsoft.directory/crossTenantAccessPolicy/partners/b2bCollaboration/update |

+| microsoft.directory/crossTenantAccessPolicy/partners/b2bDirectConnect/update |

+| microsoft.directory/crossTenantAccessPolicy/partners/create |

+| microsoft.directory/crossTenantAccessPolicy/partners/crossCloudMeetings/update |

+| microsoft.directory/crossTenantAccessPolicy/partners/delete |

+| microsoft.directory/crossTenantAccessPolicy/partners/identitySynchronization/basic/update |

+| microsoft.directory/crossTenantAccessPolicy/partners/identitySynchronization/create |

+| microsoft.directory/crossTenantAccessPolicy/partners/identitySynchronization/standard/read |

+| microsoft.directory/crossTenantAccessPolicy/partners/standard/read |

+| microsoft.directory/crossTenantAccessPolicy/partners/tenantRestrictions/update |

+#### Cross-tenant access reader

+This role can read everything in cross-tenant access settings, including default and organizational based settings. This role should be assigned to users who only need to review settings in cross-tenant access settings, but not manage them.

+Please find the list of recommended actions for this role below.

+| Actions |

+| - |

+| microsoft.directory.tenantRelationships/standard/read |

+| microsoft.directory/crossTenantAccessPolicy/standard/read |

+| microsoft.directory/crossTenantAccessPolicy/default/standard/read |

+| microsoft.directory/crossTenantAccessPolicy/partners/identitySynchronization/standard/read |

+| microsoft.directory/crossTenantAccessPolicy/partners/standard/read |

+#### Cross-tenant access partner administrator

+This role can manage everything relating to partners and read the default settings. This role should be assigned to users who need to manage organizational based settings but not be able to change default settings.

+Please find the list of recommended actions for this role below.

+| Actions |

+| - |

+| microsoft.directory.tenantRelationships/standard/read |

+| microsoft.directory/crossTenantAccessPolicy/standard/read |

+| microsoft.directory/crossTenantAccessPolicy/basic/update |

+| microsoft.directory/crossTenantAccessPolicy/default/standard/read |

+| microsoft.directory/crossTenantAccessPolicy/partners/b2bCollaboration/update |

+| microsoft.directory/crossTenantAccessPolicy/partners/b2bDirectConnect/update |

+| microsoft.directory/crossTenantAccessPolicy/partners/create |

+| microsoft.directory/crossTenantAccessPolicy/partners/crossCloudMeetings/update |

+| microsoft.directory/crossTenantAccessPolicy/partners/delete |

+| microsoft.directory/crossTenantAccessPolicy/partners/identitySynchronization/basic/update |

+| microsoft.directory/crossTenantAccessPolicy/partners/identitySynchronization/create |

+| microsoft.directory/crossTenantAccessPolicy/partners/identitySynchronization/standard/read |

+| microsoft.directory/crossTenantAccessPolicy/partners/standard/read |

+| microsoft.directory/crossTenantAccessPolicy/partners/tenantRestrictions/update |

+## Protect cross-tenant access administrative actions

+Any actions that modify cross-tenant access settings are considered protected actions and can be additionally protected with Conditional Access policies. For more information and configuration steps see [protected actions](../roles/protected-actions-overview.md).

+1. Sign in to the [Azure portal](https://portal.azure.com) using a Global administrator, Security administrator, or an account with a [custom role](cross-tenant-access-overview.md#custom-roles-for-managing-cross-tenant-access-settings) you've created. Then open the **Azure Active Directory** service.

+1. Sign in to the [Azure portal](https://portal.azure.com) using a Global administrator, Security administrator, or an account with a [custom role](cross-tenant-access-overview.md#custom-roles-for-managing-cross-tenant-access-settings) you've created. Then open the **Azure Active Directory** service.

+| **Groups** | [Groups](../../fundamentals/how-to-manage-groups.md) can be used to manage administrative and user accounts.| Groups can be used to manage administrative accounts. Support for Azure AD groups and [application roles](how-to-use-app-roles-customers.md) is being phased into customer tenants. For the latest updates, see [Groups and application roles support](reference-group-app-roles-support.md). |

+| **Roles and administrators**| [Roles and administrators](../../fundamentals/how-subscriptions-associated-directory.md) are fully supported for administrative and user accounts. | Roles aren't supported with customer accounts. Customer accounts don't have access to tenant resources.|

+If you want to run a sample Node.js browserless application rather than building it from scratch, complete the steps in [Sign in users in a sample Node.js browserless application by using the Device Code flow](./sample-browserless-app-node-sign-in.md)

+1. Use the steps in [Run and test the browserless app](./sample-browserless-app-node-sign-in.md#run-and-test-sample-browserless-app) article to test your browserless app.

+The user is deleted and no longer appears on the **All users** page. The user can be seen on the **Deleted users** page for the next 30 days and can be restored during that time. For more information about restoring a user, see [Restore or remove a recently deleted user using Azure AD](../../fundamentals/users-restore.md).

+For details about restoring a user within the first 30 days after deletion, or for permanently deleting a user, see [Restore or remove a recently deleted user using Azure Active Directory](../../fundamentals/users-restore.md).

+- [Sign in users in a sample vanilla JavaScript single-page app](./sample-single-page-app-vanillajs-sign-in.md)

+- [Sign in users in a sample Node.js web app](./sample-web-app-node-sign-in.md)

+- Learn more how to manage [Azure Active Directory for customers resources with Microsoft Graph](microsoft-graph-operations.md)

+1. Use the steps in [Run and test sample web app and API](./sample-web-app-node-sign-in-call-api.md#run-and-test-sample-web-app-and-api) to demonstrate how the client app calls the web API.

+If you want to run a sample Node.js web application that calls a sample web API to get a feel of how things work, complete the steps in [Sign in users and call an API in sample Node.js web application](./sample-web-app-node-sign-in-call-api.md).

+ - You set this route as Redirect URI for the web app in the Microsoft Entra admin center earlier in [Register the web app](./sample-web-app-node-sign-in-call-api.md#register-the-web-app).

+This how-to guide uses a sample ASP.NET web application to show the fundamentals of modern authentication using the [Microsoft Authentication Library for .NET](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet) and [Microsoft Identity Web](https://github.com/AzureAD/microsoft-identity-web/) for ASP.NET to handle authentication.

+ :::image type="content" source="media/tutorial-web-app-dotnet-sign-in-sign-in-out/display-aspnet-welcome.png" alt-text="Screenshot of sign in into a ASP.NET web app.":::

+- [Sign in users in your own ASP.NET web application by using an Azure AD for customers tenant](tutorial-web-app-dotnet-sign-in-prepare-app.md)

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

+> | JavaScript, Angular | &#8226; [Sign in users](./sample-single-page-app-angular-sign-in.md) | |

+> | JavaScript, React | &#8226; [Sign in users](./sample-single-page-app-react-sign-in.md) | &#8226; [Sign in users](./tutorial-single-page-app-react-sign-in-prepare-tenant.md) |

+> | JavaScript, Node.js (Express) | &#8226; [Sign in users](./sample-web-app-node-sign-in.md)<br/> &#8226; [Sign in users and call an API](./sample-web-app-node-sign-in-call-api.md) | &#8226; [Sign in users](tutorial-web-app-node-sign-in-prepare-tenant.md)<br/> &#8226; [Sign in users and call an API](how-to-web-app-node-sign-in-call-api-overview.md) |

+> | ASP.NET Core | &#8226; [Sign in users](./sample-web-app-dotnet-sign-in.md) | &#8226; [Sign in users](tutorial-web-app-dotnet-sign-in-prepare-tenant.md) |

+> | JavaScript, Node | &#8226; [Sign in users](./sample-browserless-app-node-sign-in.md) | &#8226; [Sign in users](how-to-browserless-app-node-sign-in-overview.md ) |

+> | .NET | &#8226; [Sign in users](./sample-browserless-app-dotnet-sign-in.md) | &#8226; [Sign in users](./tutorial-browserless-app-dotnet-sign-in-prepare-tenant.md) |

+> | Node.js | &#8226; [Call an API](./sample-daemon-node-call-api.md) | &#8226; [Call an API](tutorial-daemon-node-call-api-prepare-tenant.md) |

+> | Browserless | &#8226; [Sign in users](./sample-browserless-app-dotnet-sign-in.md) | &#8226; [Sign in users](./tutorial-browserless-app-dotnet-sign-in-prepare-tenant.md) |

+> | Web app | &#8226; [Sign in users](sample-web-app-dotnet-sign-in.md) | &#8226; [Sign in users](tutorial-web-app-dotnet-sign-in-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) |

+> | Single-page application | &#8226; [Sign in users](./sample-single-page-app-angular-sign-in.md) | |

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

+> | Browserless | &#8226; [Sign in users](./sample-browserless-app-node-sign-in.md) | &#8226; [Sign in users](how-to-browserless-app-node-sign-in-overview.md ) |

+> | Daemon | &#8226; [Call an API](./sample-daemon-node-call-api.md) | &#8226; [Call an API](./tutorial-daemon-node-call-api-prepare-tenant.md) |

+> | Web app |&#8226; [Sign in users](./sample-web-app-node-sign-in.md)<br/> &#8226; [Sign in users and call an API](./sample-web-app-node-sign-in-call-api.md) | &#8226; [Sign in users](tutorial-web-app-node-sign-in-prepare-tenant.md)<br/> &#8226; [Sign in users and call an API](how-to-web-app-node-sign-in-call-api-overview.md) |

+1. Use the steps you learned in [Secure an ASP.NET web API](./tutorial-protect-web-api-dotnet-core-build-app.md) tutorial to start your web API. Your web API is now ready to serve client requests. If you don't run your web API on port `44351` as specified in the *authConfig.js* file, make sure you update the *authConfig.js* file to use the correct web API's port number.

+Learn how to [Use client certificate instead of a secret for authentication in your Node.js confidential app](how-to-web-app-node-use-certificate.md).

+ Title: Tutorial - Prepare an ASP.NET web app for authentication in a customer tenant

+description: Learn how to prepare an ASP.NET web app for authentication with your Azure Active Directory (Azure AD) for customers tenant.

+#Customer intent: As a dev, devops, I want to learn about how to enable authentication in my own ASP.NET web app with Azure Active Directory (Azure AD) for customers tenant.

+# Tutorial: Prepare an ASP.NET web app for authentication in a customer tenant

+In the [previous article](./tutorial-web-app-dotnet-sign-in-prepare-tenant.md), you registered an application and configured user flows in your Azure Active Directory (Azure AD) for customers tenant.

+In this tutorial you'll;

+> [!div class="checklist"]

+> * Create an ASP.NET project in Visual Studio Code

+> * Add the required NuGet packages

+> * Configure the settings for the application

+> * Add code to implement authentication

+## Prerequisites

+* Completion of the prerequisites and steps in [Prepare your customer tenant for building an ASP.NET web app](./tutorial-web-app-dotnet-sign-in-prepare-tenant.md).

+* Although any integrated development environment (IDE) that supports ASP.NET applications can be used, this tutorial uses **Visual Studio Code**. You can download it [here](https://visualstudio.microsoft.com/downloads/).

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

+## Create an ASP.NET project

+1. Open Visual Studio Code, select **File** > **Open Folder...**. Navigate to and select the location in which to create your project.

+1. Open a new terminal by selecting **Terminal** > **New Terminal**.

+1. Enter the following command to make a Model View Controller (MVC) ASP.NET project.

+ ```powershell

+ dotnet new mvc -n aspnet_webapp

+ ```

+## Install identity packages

+Identity related NuGet packages must be installed in the project to authenticate users.

+1. Enter the following commands to change into the *aspnet_webapp* folder and install the relevant NuGet package:

+ ```powershell

+ cd aspnet_webapp

+ dotnet add package Microsoft.Identity.Web.UI

+ ```

+## Configure the application for authentication

+1. Open the *appsettings.json* file and replace the existing code with the following snippet.

+ ```json

+ {

+ "AzureAd": {

+ "Authority": "https://Enter_the_Tenant_Subdomain_Here.ciamlogin.com/",

+ "ClientId": "Enter_the_Application_Id_Here",

+ "ClientCredentials": [

+ {

+ "SourceType": "ClientSecret",

+ "ClientSecret": "Enter_the_Client_Secret_Here"

+ }

+ ],

+ "CallbackPath": "/signin-oidc",

+ "SignedOutCallbackPath": "/signout-callback-oidc"

+ },

+ "Logging": {

+ "LogLevel": {

+ "Default": "Information",

+ "Microsoft.AspNetCore": "Warning"

+ }

+ },

+ "AllowedHosts": "*"

+ }

+ ```

+ * `Authority` - The identity provider instance and sign-in audience for the app. Replace `Enter_the_Tenant_Subdomain_Here` with the sub-domain of your customer tenant. To find this, select **Overview** in the sidebar menu, then switch to the **Overview tab**. Find the **Primary domain**, in the form *caseyjensen.onmicrosoft.com*. The sub-domain is *caseyjensen*.

+ * `ClientId` - The identifier of the application, also referred to as the client. Replace the text in quotes with the **Application (client) ID** value that was recorded earlier from the overview page of the registered application.

+ * `ClientSecret` - The value of the client secret you created in [Prepare your tenant](./tutorial-web-app-dotnet-sign-in-prepare-tenant.md). Replace the text in quotes with the client secret **value** in the Microsoft Entra admin center.

+ * `CallbackPath` - Is an identifier to help the server redirect a response to the appropriate application.

+

+1. Save changes to the file.

+1. Open the *Properties/launchSettings.json* file.

+1. In the `https` section of `profiles`, change the `https` URL in `applicationUrl` so that it reads `https://localhost:7274`. You used this URL to define the **Redirect URI**.

+1. Save the changes to your file.

+## Add authorization to *HomeController.cs*

+The *HomeController.cs* file contains the code for the home page of the application and needs to have the capability to authorize the user. The `Microsoft.AspNetCore.Authorization` namespace provides the classes and interfaces to implement authorization to the web app, and the `[Authorize]` attribute is used to specify that only authenticated users can use the web app.

+1. In your code editor, open *Controllers\HomeController.cs* file.

+1. Authorization needs to be added to the controller, add `Microsoft.AspNetCore.Authorization` so that the top of the file is identical to the following snippet:

+ ```cshtml

+ using System.Diagnostics;

+ using Microsoft.AspNetCore.Authorization;

+ using Microsoft.AspNetCore.Mvc;

+ using aspnet_webapp.Models;

+ ```

+1. Additionally, add the `[Authorize]` attribute directly above the `HomeController` class definition.

+ ```csharp

+ [Authorize]

+ ```

+## Add authentication and authorization to *Program.cs*

+The *Program.cs* needs to be modified to add authentication and authorization to the web app. This includes adding namespaces for authentication and authorization, and being able to sign in users with the Microsoft identity platform.

+1. To add the required namespaces, open *Program.cs* and add the following snippet to the top of the file:

+ ```csharp

+ using Microsoft.AspNetCore.Authentication.OpenIdConnect;

+ using Microsoft.AspNetCore.Authorization;

+ using Microsoft.AspNetCore.Mvc.Authorization;

+ using Microsoft.Identity.Web;

+ using Microsoft.Identity.Web.UI;

+ using System.IdentityModel.Tokens.Jwt;

+ ```

+1. Next, add the authentication services to the application which will enable the web app to sign in users with the Microsoft identity platform. You can replace the rest of the code in *Program.cs* with the following snippet:

+ ```csharp

+ var builder = WebApplication.CreateBuilder(args);

+ // Add services to the container.

+ builder.Services.AddControllersWithViews();

+ // This is required to be instantiated before the OpenIdConnectOptions starts getting configured.

+ // By default, the claims mapping will map claim names in the old format to accommodate older SAML applications.

+ // For instance, 'http://schemas.microsoft.com/ws/2008/06/identity/claims/role' instead of 'roles' claim.

+ // This flag ensures that the ClaimsIdentity claims collection will be built from the claims in the token

+ JwtSecurityTokenHandler.DefaultMapInboundClaims = false;

+ // Sign-in users with the Microsoft identity platform

+ builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)

+ .AddMicrosoftIdentityWebApp(builder.Configuration)

+ .EnableTokenAcquisitionToCallDownstreamApi()

+ .AddInMemoryTokenCaches();

+ builder.Services.AddControllersWithViews(options =>

+ {

+ var policy = new AuthorizationPolicyBuilder()

+ .RequireAuthenticatedUser()

+ .Build();

+ options.Filters.Add(new AuthorizeFilter(policy));

+ }).AddMicrosoftIdentityUI();

+ var app = builder.Build();

+ // Configure the HTTP request pipeline.

+ if (!app.Environment.IsDevelopment())

+ {

+ app.UseExceptionHandler("/Home/Error");

+ // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.

+ app.UseHsts();

+ }

+ app.UseHttpsRedirection();

+ app.UseStaticFiles();

+ app.UseRouting();

+ app.UseAuthorization();

+ app.MapControllerRoute(

+ name: "default",

+ pattern: "{controller=Home}/{action=Index}/{id?}");

+ app.Run();

+ ```

+## Next steps

+> [!div class="nextstepaction"]

+> [Sign in and sign out](tutorial-web-app-dotnet-sign-in-sign-out.md)

+ Title: Tutorial - Prepare your customer tenant to authenticate users in an ASP.NET web app

+description: Learn how to configure your Azure Active Directory (Azure AD) for customers tenant for authentication with an ASP.NET web application

+#Customer intent: As a dev, devops, I want to learn about how to enable authentication in my own ASP.NET web app with Azure Active Directory (Azure AD) for customers tenant

+# Tutorial: Prepare your customer tenant to authenticate users in an ASP.NET web app

+This tutorial series demonstrates how to build an ASP.NET web application from scratch and prepare it for authentication using the Microsoft Entra admin center. You'll use the [Microsoft Authentication Library for .NET](/entra/msal/dotnet) and [Microsoft Identity Web](/dotnet/api/microsoft-authentication-library-dotnet/confidentialclient) libraries to authenticate your app with your Azure Active Directory (Azure AD) for customers tenant. Finally, you'll run the application and test the sign-in and sign-out experiences.

+In this tutorial, you'll;

+> [!div class="checklist"]

+> * Register a web application in the Microsoft Entra admin center, and record its identifiers

+> * Create a client secret for the web application

+> * Define the platform and URLs

+> * Grant permissions to the web application to access the Microsoft Graph API

+> * Create a sign in and sign out user flow in the Microsoft Entra admin center

+> * Associate your web application with the user flow

+## Prerequisites

+- An Azure subscription. If you don't have one, [create a free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

+- This Azure account must have permissions to manage applications. Any of the following Azure AD roles include the required permissions:

+ * Application administrator

+ * Application developer

+ * Cloud application administrator

+- An Azure AD for customers tenant. If you haven't already, [create one now](https://aka.ms/ciam-free-trial?wt.mc_id=ciamcustomertenantfreetrial_linkclick_content_cnl). You can use an existing customer tenant if you have one.

+## Register the web app and record identifiers

+## Add a platform redirect URL

+## Add app client secret

+## Grant API permissions

+## Create a user flow

+## Associate the web application with the user flow

+## Next steps

+> [!div class="nextstepaction"]

+> [Prepare ASP.NET web app](tutorial-web-app-dotnet-sign-in-prepare-app.md)

+ Title: Tutorial - Add sign-in and sign-out to an ASP.NET web application for a customer tenant

+description: Learn how to configure an ASP.NET web application to sign in and sign out users with your Azure Active Directory (Azure AD) for customers tenant.

+#Customer intent: As a dev, devops, I want to learn about how to enable authentication in my own ASP.NET web app with Azure Active Directory (Azure AD) for customers tenant.

+# Tutorial: Add sign-in and sign-out to an ASP.NET web application for a customer tenant

+In the [previous article](./tutorial-web-app-dotnet-sign-in-prepare-app.md), you created an ASP.NET project in Visual Studio Code and configured it for authentication.

+In this tutorial you'll:

+> [!div class="checklist"]

+> * Add sign-in and sign-out experiences

+> * Add code to view ID token claims

+> * Sign-in and sign-out of the application using the user flow

+## Prerequisites

+- Completion of the prerequisites and steps in [Prepare an ASP.NET web app for authentication in a customer tenant](./tutorial-web-app-dotnet-sign-in-prepare-app.md).

+## Add the sign-in and sign out experience

+After installing the NuGet packages and adding necessary code for authentication, we need to add the sign-in and sign out experiences. The code reads the ID token claims to check that the user is authenticated and uses `User.Claims` to extract ID token claims.

+1. In your IDE, navigate to *Views/Shared*, and create a new file called *_LoginPartial.cshtml*.

+1. Open *_LoginPartial.cshtml* and add the following code for adding the sign in and sign out experience.

+ ```csharp

+ @using System.Security.Principal

+ <ul class="navbar-nav">

+ @if (User.Identity is not null && User.Identity.IsAuthenticated)

+ {

+ <li class="nav-item">

+ <span class="nav-link text-dark">Hello @User.Claims.First(c => c.Type == "preferred_username").Value!</span>

+ </li>

+ <li class="nav-item">

+ <a class="nav-link text-dark" asp-area="MicrosoftIdentity" asp-controller="Account" asp-action="SignOut">Sign out</a>

+ </li>

+ }

+ else

+ {

+ <li class="nav-item">

+ <a class="nav-link text-dark" asp-area="MicrosoftIdentity" asp-controller="Account" asp-action="SignIn">Sign in</a>

+ </li>

+ }

+ </ul>

+ ```

+1. Next, add a reference to `_LoginPartial` in the *Layout.cshtml* file, which is located in the same folder. It's recommended to place this after the `navbar-collapse` class as shown in the following snippet:

+ ```html

+ <div class="navbar-collapse collapse d-sm-inline-flex flex-sm-row-reverse">

+ <partial name="_LoginPartial" />

+ </div>

+ ```

+## View ID token claims

+The web app is now configured to sign in users with the Microsoft identity platform. The next step is to add code that allows us to view the ID token claims. The app will check that the user is authenticated using `User.Identity.IsAuthenticated`, and lists out the ID token claims by looping through each item in `User.Claims`, returning their `Type` and `Value`.

+1. Open *Views/Home/Index.cshtml* and replace the contents of the file with the following snippet:

+ ```csharp

+ @{

+ ViewData["Title"] = "Home Page";

+ }

+

+ <style>

+ table {

+ border-collapse: collapse;

+ width: 100%;

+ }

+ th, td {

+ text-align: justify;

+ padding: 8px;

+ border-bottom: 1px solid #ddd;

+ border-top: 1px solid #ddd;

+ }

+ </style>

+

+ <div class="text-center">

+ <h1 class="display-4">Welcome</h1>

+

+ @if (@User.Identity is not null && @User.Identity.IsAuthenticated)

+ {

+ <p>You are signed in! Below are the claims in your ID token. For more information, visit: <a href="https://learn.microsoft.com/azure/active-directory/develop/id-tokens">Microsoft identity platform ID tokens</a></p>

+ <table>

+ <tbody>

+

+ @foreach (var item in @User.Claims)

+ {

+ <tr>

+ <td>@item.Type</td>

+ <td>@item.Value</td>

+ </tr>

+ }

+ </tbody>

+ </table>

+ }

+

+ <br />

+ <p>Learn about <a href="https://learn.microsoft.com/azure/active-directory/develop/v2-overview">building web apps with Microsoft identity platform</a>.</p>

+ </div>

+ ```

+## Sign-in to the application

+1. Start the application by typing the following in the terminal to launch the `https` profile in the *launchSettings.json* file.

+ ```powershell

+ dotnet run --launch-profile https

+ ```

+1. Open a new private browser, and enter the application URI into the browser, in this case `https://localhost:7274`.

+1. To test the sign-up user flow you configured earlier, select **No account? Create one**.

+1. In the **Create account** window, enter the email address registered to your customer tenant, which will start 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 ASP.NET Welcome page appears in your browser as depicted in the following screenshot:

+ :::image type="content" source="media/tutorial-web-app-dotnet-sign-in-sign-in-out/display-aspnet-welcome.png" alt-text="Screenshot of sign in into an ASP.NET web app.":::

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

+> [!div class="nextstepaction"]

+> [Enable self-service password reset](./how-to-enable-password-reset-customers.md)

+- [Tutorial: Handle authentication flows in a React single-page app](./tutorial-single-page-app-react-sign-in-configure-authentication.md)

+- [Tutorial: Prepare a React single-page app (SPA) for authentication in a customer tenant](./tutorial-single-page-app-react-sign-in-prepare-app.md) - JavaScript tutorial edits, code sample updates and fixed SPA aligning content styling

+- [Tutorial: Add sign-in and sign-out to a React single-page app (SPA) for a customer tenant](./tutorial-single-page-app-react-sign-in-sign-out.md) - JavaScript tutorial edits and fixed SPA aligning content styling

+- [Tutorial: Prepare your customer tenant to authenticate users in a React single-page app (SPA)](tutorial-single-page-app-react-sign-in-prepare-tenant.md) - Fixed SPA aligning content styling

+- [Tutorial: Prepare an ASP.NET web app for authentication in a customer tenant](tutorial-web-app-dotnet-sign-in-prepare-app.md) - ASP.NET web app fixes

+- [Tutorial: Prepare your customer tenant to authenticate users in an ASP.NET web app](tutorial-web-app-dotnet-sign-in-prepare-tenant.md) - ASP.NET web app fixes

+- [Tutorial: Add sign-in and sign-out to an ASP.NET web application for a customer tenant](tutorial-web-app-dotnet-sign-in-sign-out.md) - ASP.NET web app fixes

+Azure AD B2B can be configured to federate with IdPs that use the SAML protocol with specific requirements listed in this section. For more information about setting up a trust between your SAML IdP and Azure AD, see [Use a SAML 2.0 Identity Provider (IdP) for SSO](../hybrid/connect/how-to-connect-fed-saml-idp.md).

+ > You can configure **External user leave settings** only if you have [added your privacy information](../fundamentals/properties-area.md) to your Azure AD tenant. Otherwise, this setting will be unavailable.

+- A subscription exists, but it hasn't been associated with your directory yet. You can [associate an existing subscription to your tenant](../fundamentals/how-subscriptions-associated-directory.md) and then repeat the steps for [linking it to your tenant](#link-your-azure-ad-tenant-to-a-subscription).

+For the latest pricing information, see [Azure Active Directory pricing](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing).

+- [Apps using ADAL](../develop/howto-get-list-of-all-auth-library-apps.md)

+If you create accounts for your external partners in your on-premises directory (for example, you create an account with a sign-in name of "msullivan" for an external user named Maria Sullivan in your partners.contoso.com domain), you can now sync these accounts to the cloud. Specifically, you can use [Azure AD Connect](../hybrid/connect/whatis-azure-ad-connect.md) to sync the partner accounts to the cloud, which creates a user account with UserType = Guest. This enables your partner users to access cloud resources using the same credentials as their local accounts, without giving them more access than they need.

+For detailed attribute requirements, see [Enable synchronization of UserType](../hybrid/connect/how-to-connect-sync-change-the-configuration.md#enable-synchronization-of-usertype).

+For implementation instructions, see [Enable synchronization of UserType](../hybrid/connect/how-to-connect-sync-change-the-configuration.md#enable-synchronization-of-usertype).

+The footer contains more information about the invitation being sent. There's always an option for the invitee to block future invitations. If the organization has [set a privacy statement](../fundamentals/properties-area.md), the link to the statement is displayed here. Otherwise, a note indicates the organization hasn't set a privacy statement.

+> In Azure AD Connect sync, thereΓÇÖs a default rule that writes the onPremisesUserPrincipalName attribute to the user object. Because the presence of this attribute can prevent a user from signing in using external credentials, we block internal-to-external conversions for user objects with this attribute. If youΓÇÖre using Azure AD Connect and you want to be able to invite internal users to B2B collaboration, you'll need to [modify the default rule](../hybrid/connect/how-to-connect-sync-change-the-configuration.md) so the onPremisesUserPrincipalName attribute isnΓÇÖt written to the user object.

+> You can configure **External user leave settings** only if you have [added your privacy information](../fundamentals/properties-area.md) to your Azure AD tenant. Otherwise, this setting will be unavailable. We recommend adding your privacy information to allow external users to review your policies and email your privacy contact when necessary.

+1. Azure AD performs user-based discovery to determine if the user already exists in a managed Azure AD tenant. (Unmanaged Azure AD accounts can no longer be used for the redemption flow.) If the userΓÇÖs User Principal Name ([UPN](../hybrid/connect/plan-connect-userprincipalname.md#what-is-userprincipalname)) matches both an existing Azure AD account and a personal MSA, the user is prompted to choose which account they want to redeem with.

+ > For information about how you as a tenant administrator can link to your organization's privacy statement, see [How-to: Add your organization's privacy info in Azure Active Directory](../fundamentals/properties-area.md).

+- [Get support for B2B collaboration](../fundamentals/how-to-get-support.md)

+A dynamic group is a dynamic configuration of security group membership for Azure Active Directory (Azure AD) available in the [Azure portal](https://portal.azure.com). Administrators can set rules to populate groups that are created in Azure AD based on user attributes (such as [userType](user-properties.md), department, or country/region). Members can be automatically added to or removed from a security group based on their attributes. These groups can provide access to applications or cloud resources (SharePoint sites, documents) and to assign licenses to members. Learn more about [dedicated groups in Azure Active Directory](../fundamentals/how-to-manage-groups.md).

+Create your new directory by following the steps in [Create a new tenant for your organization](./create-new-tenant.md#create-a-new-tenant-for-your-organization).

+> You also need to register the same domain name you select for federating with your on-premises directory in the **Azure AD Domain** step in the wizard. To see what that setup looks like, see [Verify the Azure AD domain selected for federation](../hybrid/connect/how-to-connect-install-custom.md#verify-the-azure-ad-domain-selected-for-federation). If you don't have the Azure AD Connect tool, you can [download it here](https://go.microsoft.com/fwlink/?LinkId=615771).

+- Add another Global administrator to your directory. For more information, see [How to assign roles and administrators](./how-subscriptions-associated-directory.md).

+- Add users to your domain. For more information, see [How to add or delete users](./add-users.md).

+ - **Job info**: Optional. Add the user's job title, department, company name, and manager. These details can be updated at any time. For more information about adding other user info, see [How to manage user profile information](./how-to-manage-user-profile-info.md).

+The process for inviting a guest is the same as [adding a new user](./add-users.md#add-a-new-user), with two exceptions. The email address won't follow the same domain rules as users from your organization. You can also include a personal message.

+The user is deleted and no longer appears on the **Users - All users** page. The user can be seen on the **Deleted users** page for the next 30 days and can be restored during that time. For more information about restoring a user, see [Restore or remove a recently deleted user using Azure Active Directory](./users-restore.md).

+- [Add or change profile information](./how-to-manage-user-profile-info.md)

+- [Assign roles to users](./how-subscriptions-associated-directory.md)

+- [Create a basic group and add members](./how-to-manage-groups.md)

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

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

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

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

+For example, you can create a security group so that all group members have the same set of security permissions. Members of a security group can include users, devices, other groups, and [service principals](../architecture/service-accounts-principal.md), which define access policy and permissions. Owners of a security group can include users and service principals.

+- [Learn about group-based licensing in Azure AD](./licensing-whatis-azure-portal.md)

+- [Learn about Privileged Identity Management for Azure AD roles](../privileged-identity-management/pim-create-roles-and-resource-roles-review.md)

+This guide assumes that your cloud only or hybrid identities have been established in Azure AD already. For help with choosing your identity type see the article, [Choose the right authentication method for your Azure Active Directory hybrid identity solution](../hybrid/connect/choose-ad-authn.md)

+| [Enable Password Hash Sync](../hybrid/connect/how-to-connect-password-hash-synchronization.md) (if using hybrid identities) | Provide redundancy for authentication and improve security (including Smart Lockout, IP Lockout, and the ability to discover leaked credentials.) |

+| [Enable Password Hash Sync](../hybrid/connect/how-to-connect-password-hash-synchronization.md) (if using hybrid identities) | Provide redundancy for authentication and improve security (including Smart Lockout, IP Lockout, and the ability to discover leaked credentials.) |

+| [Enable Conditional Access ΓÇô Device based](../conditional-access/concept-conditional-access-grant.md) | Improve security and user experiences with device-based Conditional Access. This step ensures users can only access from devices that meet your standards for security and compliance. These devices are also known as managed devices. Managed devices can be Intune compliant or Hybrid Azure AD joined devices. |

+| [Enable Password Hash Sync](../hybrid/connect/how-to-connect-password-hash-synchronization.md) (if using hybrid identities) | Provide redundancy for authentication and improve security (including Smart Lockout, IP Lockout, and the ability to discover leaked credentials.) |

+| [Enable Conditional Access ΓÇô Device based](../conditional-access/concept-conditional-access-grant.md) | Improve security and user experiences with device-based Conditional Access. This step ensures users can only access from devices that meet your standards for security and compliance. These devices are also known as managed devices. Managed devices can be Intune compliant or Hybrid Azure AD joined devices. |

+| [Complete an access review for Azure AD directory roles in PIM](../privileged-identity-management/pim-create-roles-and-resource-roles-review.md) | Work with your security and leadership teams to create an access review policy to review administrative access based on your organization's policies. |

+- For detailed deployment guidance for individual features of Azure AD, review the [Azure AD project deployment plans](../architecture/deployment-plans.md).

+- Add users, see [Add or delete a new user](./add-users.md)

+- Add groups and members, see [Create a basic group and add members](./how-to-manage-groups.md)

+- Learn about Azure AD, including [basic licensing information, terminology, and associated features](./whatis.md).

+|Pass-through authentication user credential flow|RSA 2048-Public/Private key pair </br> Learn more: [Azure Active Directory Pass-through Authentication security deep dive](../hybrid/connect/how-to-connect-pta-security-deep-dive.md)|

+|[Seamless single sign-on (SSO)](../hybrid/connect/how-to-connect-sso-how-it-works.md) service account password</br>SaaS application provisioning credentials|AES-CBC 128-bit |

+* [Recover from deletions in Azure Active Directory](../architecture/recover-from-deletions.md)

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

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

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

+Now that you have Azure AD Premium, you can [customize your domain](add-custom-domain.md), add your [corporate branding](./how-to-customize-branding.md), [create a tenant](create-new-tenant.md), and [add groups](./how-to-manage-groups.md) and [users](./add-users.md).

+- Create an Azure Active Directory tenant. For more information, see [Access the Azure portal and create a new tenant](./create-new-tenant.md).

+Create a new group, named _MDM policy - West_. For more information about creating a group, see [How to create a basic group and add members](./how-to-manage-groups.md).

+A user must exist before being added as a group member, so you'll need to create a new user. For this quickstart, we've added a user named _Alain Charon_. Check the "Custom domain names" tab first to get the verified domain name in which to create users. For more information about creating a user, see [How to add or delete users](./add-users.md).

+> [Associate an Azure subscription](./how-subscriptions-associated-directory.md)

+- To create a new Azure AD tenant, see [Quickstart: Create a new tenant in Azure Active Directory](./create-new-tenant.md).

+- To learn more about how to assign roles in Azure AD, see [Assign administrator and non-administrator roles to users with Azure Active Directory](./how-subscriptions-associated-directory.md).

+Instructions for the legacy create user process can be found in the [Add or delete users](./add-users.md) article.

+The user is deleted and no longer appears on the **Users - All users** page. The user can be seen on the **Deleted users** page for the next 30 days and can be restored during that time. For more information about restoring a user, see [Restore or remove a recently deleted user using Azure Active Directory](./users-restore.md).

+For more information about licensing and editions, see the [Sign up for Azure AD Premium](./get-started-premium.md) article.

+- To create a new Azure AD tenant, see [Quickstart: Create a new tenant in Azure Active Directory](./create-new-tenant.md).

+- To learn how to associate or add a subscription to a tenant, see [Associate or add an Azure subscription to your Azure Active Directory tenant](./how-subscriptions-associated-directory.md).

+> If you're using Azure AD B2C, open a support ticket by first switching to an Azure AD tenant that has an Azure subscription associated with it. Typically, this is your employee tenant or the default tenant created for you when you signed up for an Azure subscription. To learn more, see [how an Azure subscription is related to Azure AD](./how-subscriptions-associated-directory.md).

+- [Associate or add an Azure subscription to Azure Active Directory](./how-subscriptions-associated-directory.md)

+This article covers how to add user profile information, such as a profile picture and job-specific information. You can also choose to allow users to connect their LinkedIn accounts or restrict access to the Azure AD administration portal. Some settings may be managed in more than one area of Azure AD. For more information about adding new users, see [How to add or delete users in Azure Active Directory](./add-users.md).

+- [Add or delete users](./add-users.md)

+- [Assign roles to users](./how-subscriptions-associated-directory.md)

+- [Create a basic group and add members](./how-to-manage-groups.md)

+To learn about the basic terms and concepts, see [Identity fundamentals](./whatis.md).

+For specific information about each license plan and the associated licensing details, see [What license do I need?](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing). To sign up for Azure AD premium license plans see [here](./get-started-premium.md).