+> Algeria (DZ), Austria (AT), Azerbaijan (AZ), Bahrain (BH), Belarus (BY), Belgium (BE), Bulgaria (BG), Croatia (HR), Cyprus (CY), Czech Republic (CZ), Denmark (DK), Egypt (EG), Estonia (EE), Finland (Fl), France (FR), Germany (DE), Greece (GR), Hungary (HU), Iceland (IS), Ireland (IE), Israel (IL), Italy (IT), Jordan (JO), Kazakhstan (KZ), Kenya (KE), Kuwait (KW), Latvia (LV), Lebanon (LB), Liechtenstein (LI), Lithuania (LT), Luxembourg (LU), North Macedonia (ML), Malta (MT), Montenegro (ME), Morocco (MA), Netherlands (NL), Nigeria (NG), Norway (NO), Oman (OM), Pakistan (PK), Poland (PL), Portugal (PT), Qatar (QA), Romania (RO), Russia (RU), Saudi Arabia (SA), Serbia (RS), Slovakia (SK), Slovenia (ST), South Africa (ZA), Spain (ES), Sweden (SE), Switzerland (CH), Tunisia (TN), T├╝rkiye (TR), Ukraine (UA), United Arab Emirates (AE) and United Kingdom (GB)

+- [Create an Azure AD B2C tenant](tutorial-create-tenant.md).

+ Title: Determine your security posture for external access with Azure Active Directory

+description: Learn about governance of external access and assessing collaboration needs, by scenario

+# Determine your security posture for external access with Azure Active Directory

+As you consider the governance of external access, assess your organization's security and collaboration needs, by scenario. You can start with the level of control the IT team has over the day-to-day collaboration of end users. Organizations in highly regulated industries might require more IT team control. For example, defense contractors can have a requirement to positively identify and document external users, their access, and access removal: all access, scenario-based, or workloads. Consulting agencies can use certain features to allow end users to determine the external users they collaborate with.

+ 

+ > [!NOTE]

+ > A high degree of control over collaboration can lead to higher IT budgets, reduced productivity, and delayed business outcomes. When official collaboration channels are perceived as onerous, end users tend to evade official channels. An example is end users sending unsecured documents by email.

+## Before you begin

+This article is number 1 in a series of 10 articles. We recommend you review the articles in order. Go to the **Next steps** section to see the entire series.

+## Scenario-based planning

+IT teams can delegate partner access to empower employees to collaborate with partners. This delegation can occur while maintaining sufficient security to protect intellectual property.

+Compile and assess your organizations scenarios to help assess employee versus business partner access to resources. Financial institutions might have compliance standards that restrict employee access to resources such as account information. Conversely, the same institutions can enable delegated partner access for projects such as marketing campaigns.

+ 

+### Scenario considerations

+Use the following list to help measure the level of access control.

+* Information sensitivity, and associated risk of its exposure

+* Partner access to information about other end users

+* The cost of a breach versus the overhead of centralized control and end-user friction

+Organizations can start with highly managed controls to meet compliance targets, and then delegate some control to end users, over time. There can be simultaneous access-management models in an organization.

+> [!NOTE]

+> Partner-managed credentials are a method to signal the termination of access to resources, when an external user loses access to resources in their own company. Learn more: [B2B collaboration overview](../external-identities/what-is-b2b.md)

+## External-access security goals

+The goals of IT-governed and delegated access differ. The primary goals of IT-governed access are:

+* Meet governance, regulatory, and compliance (GRC) targets

+* High level of control over partner access to information about end users, groups, and other partners

+The primary goals of delegating access are:

+* Enable business owners to determine collaboration partners, with security constraints

+* Enable partners to request access, based on rules defined by business owners

+### Common goals

+#### Control access to applications, data, and content

+Levels of control can be accomplished through various methods, depending on your version of Azure AD and Microsoft 365.

+* [Azure AD plans and pricing](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing)

+* [Compare Microsoft 365 Enterprise pricing](https://www.microsoft.com/microsoft-365/compare-microsoft-365-enterprise-plans)

+#### Reduce attack surface

+* [What is Azure AD Privileged Identity Management?](../privileged-identity-management/pim-configure.md) - manage, control, and monitor access to resources in Azure AD, Azure, and other Microsoft Online Services such as Microsoft 365 or Microsoft Intune

+* [Data loss prevention in Exchange Server](/exchange/policy-and-compliance/data-loss-prevention/data-loss-prevention?view=exchserver-2019&preserve-view=true)

+#### Confirm compliance with activity and audit log reviews

+IT teams can delegate access decisions to business owners through entitlement management, while access reviews help confirm continued access. You can use automated data classification with sensitivity labels to automate the encryption of sensitive content, easing compliance for end users.

+## Next steps

+Use the following series of articles to learn about securing external access to resources. We recommend you follow the listed order.

+1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md) (You're here)

+2. [Discover the current state of external collaboration in your organization](2-secure-access-current-state.md)

+3. [Create a security plan for external access to resources](3-secure-access-plan.md)

+4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md)

+5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md)

+6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md)

+7. [Manage external access to resources with Conditional Access policies](7-secure-access-conditional-access.md)

+8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md)

+9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md)

+10. [Convert local guest accounts to Azure Active Directory B2B guest accounts](10-secure-local-guest.md)

+ Title: Convert local guest accounts to Azure AD B2B guest accounts

+description: Learn to convert local guests into Azure AD B2B guest accounts by identifying apps and local guest accounts, migration, and more.

+# Convert local guest accounts to Azure Active Directory B2B guest accounts

+With Azure Active Directory (Azure AD B2B), external users collaborate with their identities. Although organizations can issue local usernames and passwords to external users, this approach isn't recommended. Azure AD B2B has improved security, lower cost, and less complexity, compared to creating local accounts. In addition, if your organization issues local credentials that external users manage, you can use Azure AD B2B instead. Use the guidance in this document to make the transition.

+Learn more: [Plan an Azure AD B2B collaboration deployment](secure-external-access-resources.md)

+## Before you begin

+This article is number 10 in a series of 10 articles. We recommend you review the articles in order. Go to the **Next steps** section to see the entire series.

+## Identify external-facing applications

+Before migrating local accounts to Azure AD B2B, confirm the applications and workloads external users can access. For example, for applications hosted on-premises, validate the application is integrated with Azure AD. On-premises applications are a good reason to create local accounts.

+Learn more: [Grant B2B users in Azure AD access to your on-premises applications](../external-identities/hybrid-cloud-to-on-premises.md)

+We recommend that external-facing applications have single-sign on (SSO) and provisioning integrated with Azure AD for the best end user experience.

+## Identify local guest accounts

+Identify the accounts to be migrated to Azure AD B2B. External identities in Active Directory are identifiable with an attribute-value pair. For example, making ExtensionAttribute15 = `External` for external users. If these users are set up with Azure AD Connect or Cloud Sync, configure synced external users to have the `UserType` attributes set to `Guest`. If the users are set up as cloud-only accounts, you can modify user attributes. Primarily, identify users to convert to B2B.

+## Map local guest accounts to external identities

+Identify user identities or external emails. Confirm that the local account (v-lakshmi@contoso.com) is a user with the home identity and email address: lakshmi@fabrikam.com. To identify home identities:

+- The external user's sponsor provides the information

+- The external user provides the information

+- Refer to an internal database, if the information is known and stored

+After mapping external local accounts to identities, add external identities or email to the user.mail attribute on local accounts.

+## End user communications

+Notify external users about migration timing. Communicate expectations, for instance when external users must stop using a current password to enable authentication by home and corporate credentials. Communications can include email campaigns and announcements.

+## Migrate local guest accounts to Azure AD B2B

+After local accounts have user.mail attributes populated with the external identity and email, convert local accounts to Azure AD B2B by inviting the local account. You can use PowerShell or the Microsoft Graph API.

+Learn more: [Invite internal users to B2B collaboration](../external-identities/invite-internal-users.md)

+## Post-migration considerations

+If external user local accounts were synced from on-premises, reduce their on-premises footprint and use B2B guest accounts. You can:

+- Transition external user local accounts to Azure AD B2B and stop creating local accounts

+ - Invite external users in Azure AD

+- Randomize external user's local-account passwords to prevent authentication to on-premises resources

+ - This action ensures authentication and user lifecycle is connected to the external user home identity

+## Next steps

+Use the following series of articles to learn about securing external access to resources. We recommend you follow the listed order.

+1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md)

+2. [Discover the current state of external collaboration in your organization](2-secure-access-current-state.md)

+3. [Create a security plan for external access to resources](3-secure-access-plan.md)

+4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md)

+5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md)

+6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md)

+7. [Manage external access to resources with Conditional Access policies](7-secure-access-conditional-access.md)

+8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md)

+9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md) (You're here)

+10. [Convert local guest accounts to Azure Active Directory B2B guest accounts](10-secure-local-guest.md) (You're here)

+ Title: Onboard external users to Line-of-business applications using Azure Active Directory B2B

+description: Learn how to onboard external users to Line-of-business applications using Azure Active Directory B2B

+# Onboard external users to Line-of-business applications using Azure Active Directory B2B

+Application developers can use Azure Active Directory B2B (Azure AD B2B) to onboard and collaborate with external users within line-of-business (LOB) applications. Similar to the **Share** button in many Office 365 applications, application developers can create a one-click invitation experience within any LOB application that is integrated with Azure AD.

+Benefits include:

+- Simple and easy user onboarding and access to the LOB applications with users able to gain access with a few steps.

+- Enables external users to bring their own identity and perform Single sign-on (SSO).

+- Automatic provisioning of external identities to Azure AD.

+- Apply Azure AD Conditional Access and cross tenant access policies to enforce authorization policies such as requiring multi-factor authentication.

+## Integration flow

+To integrate LOB applications with Azure AD B2B, follow this pattern:

+

+| Step | Description |

+|:-|:--|

+| 1. | The end user triggers the **invitation** within the LOB application and provides the email address of the external user. The application checks if the user already exists, and if they donΓÇÖt, proceeds to [step #2](#step-2-create-and-send-invitation)|

+| 2. | The application sends a POST to the Microsoft Graph API on behalf of the user. It provides the redirect URL and external userΓÇÖs email that is defined in [step #1](#step-1-check-if-the-external-user-already-exists). |

+| 3. | Microsoft Graph API provisions the guest user in Azure AD. |

+| 4. | Microsoft Graph API returns the success/failure status of the API call. If successful, the response includes the Azure AD user object ID and the invitation link that is sent to the invited userΓÇÖs email. You can optionally suppress the Microsoft email and send your own custom email. |

+| 5. | (Optional) If you want to write more attributes to the invited user or add the invited user to a group, the application makes an extra API call to the Microsoft Graph API. |

+| 6. | (Optional) Microsoft Graph API makes the desired updates to Azure AD.|

+| 7. | (Optional) Microsoft Graph API returns the success/failure status to the application. |

+| 8. | The application provisions the user to its own database/backend user directory using the userΓÇÖs object ID attribute as the **immutable ID**. |

+| 9. | The application presents the success/failure status to the end user. |

+If assignment is required to access the LOB application, the invited guest user must also be assigned to the application with an appropriate application role. This can be done as another API call adding the invited guest to a group (steps #5-7) or by automating group membership with Azure AD dynamic groups. Using dynamic groups wouldn't require another API call by the application. However, group membership wouldn't be updated as quickly compared to adding a user to a group immediately after user invitation.

+## Step 1: Check if the external user already exists

+It's possible that the external user has previously been invited and onboarded. The LOB application should check whether the user already exists in the directory. There are many approaches, however, the simplest involves making an API call to the Microsoft Graph API and presenting the possible matches to the inviting user for them to pick from.

+For example:

+```

+Application Permission: User.read.all

+GET https://graph.microsoft.com/v1.0/users?$filter=othermails/any(id:id eq 'userEmail@contoso.com')

+```

+If you receive a userΓÇÖs details in the response, then the user already exists. You should present the users returned to the inviting user and allow them to choose which external user they want to grant access. You should proceed to make appropriate API calls or trigger other processes to grant this user access to the application rather than proceeding with the invitation step.

+## Step 2: Create and send invitation

+If the external user doesn't already exist in the directory, you can use Azure AD B2B to invite the user and onboard them to your Azure AD tenant. As an application developer, you need to determine what to include in the invitation request to Microsoft Graph API.

+At minimum, you need to:

+- Prompt the end user to provide the external userΓÇÖs email address.

+- Determine the invitation URL. This URL is where the invited user gets redirected to after they authenticate and redeem the B2B invitation. The URL can be a generic landing page for the application or dynamically determined by the LOB application based on where the end user triggered the invitation.

+More flags and attributes to consider for inclusion in the invitation request:

+- Display name of the invited user.

+- Determine whether you want to use the default Microsoft invitation email or suppress the default email to create your own.

+Once the application has collected the required information and determined any other flags or information to include, the application must POST the request to the Microsoft Graph API invitation manager. Ensure the application registration has the appropriate permissions in Azure AD.

+For example:

+```

+Delegated Permission: User.Invite.All

+POST https://graph.microsoft.com/v1.0/invitations

+Content-type: application/json

+{

+"invitedUserDisplayName": "John Doe",

+"invitedUserEmailAddress": "john.doe@contoso.com",

+"sendInvitationMessage": true,

+"inviteRedirectUrl": "https://customapp.contoso.com"

+}

+```

+>[!NOTE]

+> To see the full list of available options for the JSON body of the invitation, check out [invitation resource type - Microsoft Graph v1.0](/graph/api/resources/invitation).

+Application developers can alternatively onboard external users using Azure AD Self-service sign-up or Entitlement management access packages. You can create your **invitation** button in your LOB application that triggers a custom email containing a predefined Self-service sign-up URL or access package URL. The invited user then self-service onboard and access the application.

+## Step 3: Write other attributes to Azure AD (optional)

+>[!IMPORTANT]

+>Granting an application permission to update users in your directory is a highly privileged action. You should take steps to secure and monitor your LOB app if you grant the application these highly privileged permissions.

+Your organization or the LOB application may require to store more information for future use, such as claims emittance in tokens or granular authorization policies. Your application can make another API call to update the external user after theyΓÇÖve been invited/created in Azure AD. Doing so requires your application to have extra API permissions and would require an extra call to the Microsoft Graph API.

+To update the user, you need to use the object ID of the newly created guest user received in the response from the invitation API call. This is the **ID** value in the API response from either the existence check or invitation. You can write to any standard attribute or custom extension attributes you may have created.

+For example:

+```

+Application Permission: User.ReadWrite.All

+PATCH https://graph.microsoft.com/v1.0/users/<userΓÇÖs object ID>

+Content-type: application/json

+{

+"businessPhones": [

+ "+1 234 567 8900"

+ ],

+"givenName": "John"

+"surname": "Doe",

+"extension_cf4ff515cbf947218d468c96f9dc9021_appRole": "external"

+}

+```

+For more information, see [Update user - Microsoft Graph v1.0](/graph/api/user-update).

+## Step 4: Assign the invited user to a group

+>[!NOTE]

+>If user assignment is not required to access the application, you may skip this step.

+If user assignment is required in Azure AD for application access and/or role assignment, the user must be assigned to the application, or else the user is unable to gain access regardless of successful authentication. To achieve this, you should make another API call to add the invited external user to a specific group. The group can be assigned to the application and mapped to a specific application role.

+For example:

+Permissions: Assign the Group updater role or a custom role to the enterprise application and scope the role assignment to only the group(s) this application should be updating. Or assign the `group.readwrite.all` permission in Microsoft Graph API.

+```

+POST https://graph.microsoft.com/v1.0/groups/<insert group id>/members/$ref

+Content-type: application/json

+{

+"@odata.id": "https://graph.microsoft.com/v1.0/directoryObjects/<insert user id>"

+}

+```

+For more information, see [Add members - Microsoft Graph v1.0](/graph/api/group-post-members).

+

+Alternatively, you can use Azure AD dynamic groups, which can automatically assign users to group based on the userΓÇÖs attributes. However, if end-user access is time-sensitive this wouldn't be the recommended approach as dynamic groups can take up to 24 hours to populate.

+If you prefer to use dynamic groups, you don't need to add the users to a group explicitly with another API call. Create a dynamic group that automatically adds the user as a member of the group based on available attributes such as userType, email, or a custom attribute. For more information, see [Create or edit a dynamic group and get status](../enterprise-users/groups-create-rule.md).

+

+## Step 5: Provision the invited user to the application

+Once the invited external user has been provisioned to Azure AD, the Microsoft Graph API returns a response with the necessary user information such as object ID and email. The LOB application can then provision the user to its own directory/database. Depending on the type of application and internal directory type the application uses, the actual implementation of this provisioning varies.

+With the external user provisioned in both Azure AD and the application, the LOB application can now notify the end user who initiated the invitation that the process has been successful. The invited user can get SSO with their own identity without the inviting organization needing to onboard and issue extra credentials. Azure AD can enforce authorization policies such as Conditional Access, Azure AD Multi-Factor Authentication, and risk-based Identity Protection.

+## Other considerations

+- Ensure proper error handling is done within the LOB application. The application should validate that each API call is successful. If unsuccessful, extra attempts and/or presenting error messages to the end user would be appropriate.

+- If you need the LOB application to update external users once theyΓÇÖve been invited, consider granting a custom role that allows the application to only update users and assign the scope to a dynamic administrative unit. For example, you can create a dynamic administrative unit to contain all users where usertype = guest. Once the external user is onboarded to Azure AD, it takes some time for them to be added to the administrative unit. So, the LOB application needs to attempt to update the user after some time and it may take more than one attempt if there are delays. Despite these delays, this is the best approach available to enable the LOB application to update external users without granting it permission to update any user in the directory.

+ Title: Discover the current state of external collaboration in your organization

+description: Discover the current state of an organization's collaboration with audit logs, reporting, allowlist, blocklist, and more.

+# Discover the current state of external collaboration in your organization

+Before you learn about the current state of your external collaboration, determine a security posture. Consider centralized vs. delegated control, also governance, regulatory, and compliance targets.

+Learn more: [Determine your security posture for external access with Azure Active Directory](1-secure-access-posture.md)

+Users in your organization likely collaborate with users from other organizations. Collaboration occurs with productivity applications like Microsoft 365, by email, or sharing resources with external users. These scenarios include users:

+* Initiating external collaboration

+* Collaborating with external users and organizations

+* Granting access to external users

+## Before you begin

+This article is number 2 in a series of 10 articles. We recommend you review the articles in order. Go to the **Next steps** section to see the entire series.

+## Determine who initiates external collaboration

+Generally, users seeking external collaboration know the applications to use, and when access ends. Therefore, determine users with delegated permissions to invite external users, create access packages, and complete access reviews.

+To find collaborating users:

+* Microsoft 365 [Audit log activities](/microsoft-365/compliance/audit-log-activities?view=o365-worldwide&preserve-view=true) - search for events and discover activities audited in Microsoft 365

+* [Auditing and reporting a B2B collaboration user](../external-identities/auditing-and-reporting.md) - verify guest user access, and see records of system and user activities

+## Enumerate guest users and organizations

+External users might be Azure AD B2B users with partner-managed credentials, or external users with locally provisioned credentials. Typically, these users are the Guest UserType. To learn about inviting guests users and sharing resources, see [B2B collaboration overview](../external-identities/what-is-b2b.md).

+You can enumerate guest users with:

+* [Microsoft Graph API](/graph/api/user-list?tabs=http)

+* [PowerShell](/graph/api/user-list?tabs=http)

+* [Azure portal](../enterprise-users/users-bulk-download.md)

+Use the following tools to identify Azure AD B2B collaboration, external Azure AD tenants, and users accessing applications:

+* PowerShell module, [Get MsIdCrossTenantAccessActivity](https://github.com/AzureAD/MSIdentityTools/wiki/Get-MSIDCrossTenantAccessActivity)

+* [Cross-tenant access activity workbook](../reports-monitoring/workbook-cross-tenant-access-activity.md)

+### Discover email domains and companyName property

+You can determine external organizations with the domain names of external user email addresses. This discovery might not be possible with consumer identity providers. We recommend you write the companyName attribute to identify external organizations.

+### Use allowlist, blocklist, and entitlement management

+Use the allowlist or blocklist to enable your organization to collaborate with, or block, organizations at the tenant level. Control B2B invitations and redemptions regardless of source (such as Microsoft Teams, SharePoint, or the Azure portal).

+See, [Allow or block invitations to B2B users from specific organizations](../external-identities/allow-deny-list.md)

+If you use entitlement management, you can confine access packages to a subset of partners with the **Specific connected organizations** option, under New access packages, in Identity Governance.

+ 

+## Determine external user access

+With an inventory of external users and organizations, determine the access to grant to the users. You can use the Microsoft Graph API to determine Azure AD group membership or application assignment.

+* [Working with groups in Microsoft Graph](/graph/api/resources/groups-overview?context=graph%2Fcontext&view=graph-rest-1.0&preserve-view=true)

+* [Applications API overview](/graph/applications-concept-overview?view=graph-rest-1.0&preserve-view=true)

+### Enumerate application permissions

+Investigate access to your sensitive apps for awareness about external access. See, [Grant or revoke API permissions programmatically](/graph/permissions-grant-via-msgraph?view=graph-rest-1.0&tabs=http&pivots=grant-application-permissions&preserve-view=true).

+### Detect informal sharing

+If your email and network plans are enabled, you can investigate content sharing through email or unauthorized software as a service (SaaS) apps.

+* Identify, prevent, and monitor accidental sharing

+ * [Learn about data loss prevention](/microsoft-365/compliance/dlp-learn-about-dlp?view=o365-worldwide&preserve-view=true )

+* Identify unauthorized apps

+ * [Microsoft Defender for Cloud Apps overview](/defender-cloud-apps/what-is-defender-for-cloud-apps)

+## Next steps

+Use the following series of articles to learn about securing external access to resources. We recommend you follow the listed order.

+1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md)

+2. [Discover the current state of external collaboration in your organization](2-secure-access-current-state.md) (You're here)

+3. [Create a security plan for external access to resources](3-secure-access-plan.md)

+4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md)

+5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md)

+6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md)

+7. [Manage external access to resources with Conditional Access policies](7-secure-access-conditional-access.md)

+8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md)

+9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md)

+10. [Convert local guest accounts to Azure Active Directory B2B guest accounts](10-secure-local-guest.md)

+ Title: Create a security plan for external access to resources

+description: Plan the security for external access to your organization's resources.

+# Create a security plan for external access to resources

+Before you create an external-access security plan, review the following two articles, which add context and information for the security plan.

+* [Determine your security posture for external access with Azure AD](1-secure-access-posture.md)

+* [Discover the current state of external collaboration in your organization](2-secure-access-current-state.md)

+## Before you begin

+This article is number 3 in a series of 10 articles. We recommend you review the articles in order. Go to the **Next steps** section to see the entire series.

+## Security plan documentation

+For your security plan, document the following information:

+* Applications and resources grouped for access

+* Sign-in conditions for external users

+ * Device state, sign-in location, client application requirements, user risk, etc.

+* Policies to determine timing for reviews and access removal

+* User populations grouped for similar experiences

+To implement the security plan, you can use Microsoft identity and access management policies, or another identity provider (IdP).

+Learn more: [Identity and access management overview](/compliance/assurance/assurance-identity-and-access-management)

+## Use groups for access

+See the following links to articles about resource grouping strategies:

+* Microsoft Teams groups files, conversation threads, and other resources

+ * Formulate an external access strategy for Teams

+ * See, [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md)

+* Use entitlement management access packages to create and delegate package management of applications, groups, teams, SharePoint sites, etc.

+ * [Create a new access package in entitlement management](../governance/entitlement-management-access-package-create.md)

+* Apply Conditional Access policies to up to 250 applications, with the same access requirements

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

+* Define access for external user application groups

+ * [Overview: Cross-tenant access with Azure AD External Identities](../external-identities/cross-tenant-access-overview.md)

+Document the grouped applications. Considerations include:

+* **Risk profile** - assess the risk if a bad actor gains access to an application

+ * Identify application as High, Medium, or Low risk. We recommend you don't group High-risk with Low-risk.

+ * Document applications that can't be shared with external users

+* **Compliance frameworks** - determine compliance frameworks for apps

+ * Identify access and review requirements

+* **Applications for roles or departments** - assess applications grouped for role, or department, access

+* **Collaboration applications** - identify collaboration applications external users can access, such as Teams or SharePoint

+ * For productivity applications, external users might have licenses, or you might provide access

+Document the following information for application and resource group access by external users.

+* Descriptive group name, for example High_Risk_External_Access_Finance

+* Applications and resources in the group

+* Application and resource owners and their contact information

+* The IT team controls access, or control is delegated to a business owner

+* Prerequisites for access: background check, training, etc.

+* Compliance requirements to access resources

+* Challenges, for example multi-factor authentication (MFA) for some resources

+* Cadence for reviews, by whom, and where results are documented

+> [!TIP]

+> Use this type of governance plan for internal access.

+## Document sign-in conditions for external users

+Determine the sign-in requirements for external users who request access. Base requirements on the resource risk profile, and the user's risk assessment during sign-in. Configure sign-in conditions using Conditional Access: a condition and an outcome. For example, you can require MFA.

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

+**Resource risk-profile sign-in conditions**

+Consider the following risk-based policies to trigger MFA.

+* **Low** - MFA for some application sets

+* **Medium** - MFA when other risks are present

+* **High** - external users always use MFA

+Learn more:

+* [Tutorial: Enforce multi-factor authentication for B2B guest users](../external-identities/b2b-tutorial-require-mfa.md)

+* Trust MFA from external tenants

+ * See, [Configure cross-tenant access settings for B2B collaboration, Modify inbound access settings](../external-identities/cross-tenant-access-settings-b2b-collaboration.md#modify-inbound-access-settings)

+### User and device sign-in conditions

+Use the following table to help assess policy to address risk.

+| User or sign-in risk| Proposed policy |

+| | |

+| Device| Require compliant devices |

+| Mobile apps| Require approved apps |

+| Identity protection is High risk| Require user to change password |

+| Network location| To access confidential projects, require sign-in from an IP address range |

+To use device state as policy input, register or join the device to your tenant. To trust the device claims from the home tenant, configure cross-tenant access settings. See, [Modify inbound access settings](../external-identities/cross-tenant-access-settings-b2b-collaboration.md#modify-inbound-access-settings).

+You can use identity-protection risk policies. However, mitigate issues in the user home tenant. See, [Common Conditional Access policy: Sign-in risk-based multifactor authentication](../conditional-access/howto-conditional-access-policy-risk.md).

+For network locations, you can restrict access to IP addresses ranges that you own. Use this method if external partners access applications while at your location. See, [Conditional Access: Block access by location](../conditional-access/howto-conditional-access-policy-location.md)

+## Document access review policies

+Document policies that dictate when to review resource access, and remove account access for external users. Inputs might include:

+* Compliance frameworks requirements

+* Internal business policies and processes

+* User behavior

+Generally, organizations customize policy, however consider the following parameters:

+* **Entitlement management access reviews**:

+ * [Change lifecycle settings for an access package in entitlement management](../governance/entitlement-management-access-package-lifecycle-policy.md)

+ * [Create an access review of an access package in entitlement management](../governance/entitlement-management-access-reviews-create.md)

+ * [Add a connected organization in entitlement management](../governance/entitlement-management-organization.md): group users from a partner and schedule reviews

+* **Microsoft 365 groups**

+ * [Microsoft 365 group expiration policy](/microsoft-365/solutions/microsoft-365-groups-expiration-policy?view=o365-worldwide&preserve-view=true)

+* **Options**:

+ * If external users don't use access packages or Microsoft 365 groups, determine when accounts become inactive or deleted

+ * Remove sign-in for accounts that don't sign in for 90 days

+ * Regularly assess access for external users

+## Access control methods

+Some features, for example entitlement management, are available with an Azure AD Premium 2 (P2) license. Microsoft 365 E5 and Office 365 E5 licenses include Azure AD Premium P2 licenses. Learn more in the following entitlement management section.

+> [!NOTE]

+> Licenses are for one user. Therefore users, administrators, and business owners can have delegated access control. This scenario can occur with Azure AD Premium P2 or Microsoft 365 E5, and you don't have to enable licenses for all users. The first 50,000 external users are free. If you don't enable P2 licenses for other internal users, they can't use entitlement management.

+Other combinations of Microsoft 365, Office 365, and Azure AD have functionality to manage external users. See, [Microsoft 365 guidance for security & compliance](/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-365-security-compliance-licensing-guidance).

+## Govern access with Azure AD Premium P2 and Microsoft 365 or Office 365 E5

+Azure AD Premium P2, included in Microsoft 365 E5, has additional security and governance capabilities.

+### Provision, sign-in, review access, and deprovision access

+Entries in bold are recommended actions.

+| Feature| Provision external users| Enforce sign-in requirements| Review access| Deprovision access |

+| - | - | - | - | - |

+| Azure AD B2B collaboration| Invite via email, one-time password (OTP), self-service|N/A| **Periodic partner review**| Remove account<br>Restrict sign-in |

+| Entitlement management| **Add user by assignment or self-service access**|N/A| Access reviews|**Expiration of, or removal from, access package**|

+| Office 365 groups|N/A|N/A| Review group memberships| Group expiration or deletion<br> Removal from group |

+| Azure AD security groups|N/A| **Conditional Access policies**: Add external users to security groups as needed|N/A| N/A|

+### Resource access

+

+Entries in bold are recommended actions.

+|Feature | App and resource access| SharePoint and OneDrive access| Teams access| Email and document security |

+| - |-|-|-|-|

+| Entitlement management| **Add user by assignment or self-service access**| **Access packages**| **Access packages**| N/A|

+| Office 365 Group|N/A | Access to site(s) and group content| Access to teams and group content|N/A|

+| Sensitivity labels|N/A| **Manually and automatically classify and restrict access**| **Manually and automatically classify and restrict access**| **Manually and automatically classify and restrict access** |

+| Azure AD security groups| **Conditional Access policies for access not included in access packages**|N/A|N/A|N/A|

+### Entitlement management 

+Use entitlement management to provision and deprovision access to groups and teams, applications, and SharePoint sites. Define the connected organizations granted access, self-service requests, and approval workflows. To ensure access ends correctly, define expiration policies and access reviews for packages.

+Learn more: [Create a new access package in entitlement management](../governance/entitlement-management-access-package-create.md)

+## Manage access with Azure AD P1, Microsoft 365, Office 365 E3

+### Provision, sign-in, review access, and deprovision access

+Items in bold are recommended actions.

+|Feature | Provision external users| Enforce sign-in requirements| Review access| Deprovision access |

+| - |-|-|-|-|

+| Azure AD B2B collaboration| **Invite by email, OTP, self-service**| Direct B2B federation| **Periodic partner review**| Remove account<br>Restrict sign-in |

+| Microsoft 365 or Office 365 groups|N/A|N/A|N/A|Group expiration or deletion<br>Removal from group |

+| Security groups|N/A| **Add external users to security groups (org, team, project, etc.)**|N/A| N/A|

+| Conditional Access policies|N/A| **Sign-in Conditional Access policies for external users**|N/A|N/A|

+### Resource access

+|Feature | App and resource access| SharePoint and OneDrive access| Teams access| Email and document security |

+| - |-|-|-|-|

+| Microsoft 365 or Office 365 groups|N/A| **Access to group site(s) and associated content**|**Access to Microsoft 365 group teams and associated content**|N/A|

+| Sensitivity labels|N/A| Manually classify and restrict access| Manually classify and restrict access| Manually classify to restrict and encrypt |

+| Conditional Access policies| Conditional Access policies for access control|N/A|N/A|N/A|

+| Other methods|N/A| Restrict SharePoint site access with security groups<br>Disallow direct sharing| **Restrict external invitations from a team**|N/A|

+## Next steps

+Use the following series of articles to learn about securing external access to resources. We recommend you follow the listed order.

+1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md)

+2. [Discover the current state of external collaboration in your organization](2-secure-access-current-state.md)

+3. [Create a security plan for external access to resources](3-secure-access-plan.md) (You're here)

+4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md)

+5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md)

+6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md)

+7. [Manage external access to resources with Conditional Access policies](7-secure-access-conditional-access.md)

+8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md)

+9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md)

+10. [Convert local guest accounts to Azure Active Directory B2B guest accounts](10-secure-local-guest.md)

+ Title: Secure external access with groups in Azure Active Directory and Microsoft 365

+description: Azure Active Directory and Microsoft 365 Groups can be used to increase security when external users access your resources.

+# Secure external access with groups in Azure Active Directory and Microsoft 365

+Groups are part of an access control strategy. You can use Azure Active Directory (Azure AD) security groups and Microsoft 365 Groups as the basis for securing access to resources. Use groups for the following access-control mechanisms:

+* Conditional Access policies

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

+* Entitlement management access packages

+ * [What is entitlement management?](../governance/entitlement-management-overview.md)

+* Access to Microsoft 365 resources, Microsoft Teams, and SharePoint sites

+Groups have the following roles:

+* **Group owners** ΓÇô manage group settings and its membership

+* **Members** ΓÇô inherit permissions and access assigned to the group

+* **Guests** ΓÇô are members outside your organization

+## Before you begin

+This article is number 4 in a series of 10 articles. We recommend you review the articles in order. Go to the **Next steps** section to see the entire series.

+## Group strategy

+To develop a group strategy to secure external access to your resources, consider the security posture that you want.

+Learn more: [Determine your security posture for external access](1-secure-access-posture.md)

+### Group creation

+Determine who is granted permissions to create groups: Administrators, employees, and/or external users. Consider the following scenarios:

+* Tenant members can create Azure AD security groups

+* Internal and external users can join groups in your tenant

+* Users can create Microsoft 365 Groups

+* [Manage who can create Microsoft 365 Groups](/microsoft-365/solutions/manage-creation-of-groups?view=o365-worldwide&preserve-view=true)

+ * Use Windows PowerShell to configure this setting

+* [Restrict your Azure AD app to a set of users in an Azure AD tenant](../develop/howto-restrict-your-app-to-a-set-of-users.md)

+* [Set up self-service group management in Azure Active Directory](../enterprise-users/groups-self-service-management.md)

+* [Troubleshoot and resolve groups issues](../enterprise-users/groups-troubleshooting.md)

+### Invitations to groups

+As part of the group strategy, consider who can invite people, or add them, to groups. Group members can add other members, or group owners can add members. Decide who can be invited. By default, external users can be added to groups.

+### Assign users to groups

+Users are assigned to groups manually, based on user attributes in their user object, or users are assigned based on other criteria. Users are assigned to groups dynamically based on their attributes. For example, you can assign users to groups based on:

+* Job title or department

+* Partner organization to which they belong

+ * Manually, or through connected organizations

+* Member or guest user type

+* Participation in a project

+ * Manually

+* Location

+Dynamic groups have users or devices, but not both. To assign users to the dynamic group, add queries based on user attributes. The following screenshot has queries that add users to the group if they are finance department members.

+ 

+Learn more: [Create or update a dynamic group in Azure AD](../enterprise-users/groups-create-rule.md)

+### Use groups for one function

+When using groups, it's important they have a single function. If a group is used to grant access to resources, don't use it for another purpose. We recommend a security-group naming convention that makes the purpose clear:

+* Secure_access_finance_apps

+* Team_membership_finance_team

+* Location_finance_building

+### Group types

+You can create Azure AD security groups and Microsoft 365 Groups in the Azure portal or the Microsoft 365 Admin portal. Use either group type for securing external access.

+| Considerations |Manual and dynamic Azure AD security groups| Microsoft 365 Groups |

+| - | - | - |

+| The group contains| Users<br>Groups<br>Service principals<br>Devices| Users only |

+| Where the group is created| Azure portal<br>Microsoft 365 portal, if mail-enabled)<br>PowerShell<br>Microsoft Graph<br>End user portal| Microsoft 365 portal<br>Azure portal<br>PowerShell<br>Microsoft Graph<br>In Microsoft 365 applications |

+| Who creates, by default| Administrators <br>Users| Administrators<br>Users |

+| Who is added, by default| Internal users (tenant members) and guest users | Tenant members and guests from an organization |

+| Access is granted to| Resources to which it's assigned.| Group-related resources:<br>(Group mailbox, site, team, chats, and other Microsoft 365 resources)<br>Other resources to which group is added |

+| Can be used with| Conditional Access<br>entitlement management<br>group licensing| Conditional Access<br>entitlement management<br>sensitivity labels |

+> [!NOTE]

+> Use Microsoft 365 Groups to create and manage a set of Microsoft 365 resources, such as a Team and its associated sites and content.

+## Azure AD security groups

+Azure AD security groups can have users or devices. Use these groups to manage access to:

+* Azure resources

+ * Microsoft 365 apps

+ * Custom apps

+ * Software as a Service (SaaS) apps such as Dropbox ServiceNow

+* Azure data and subscriptions

+* Azure services

+Use Azure AD security groups to assign:

+* Licenses for services

+ * Microsoft 365

+ * Dynamics 365

+ * Enterprise mobility and security

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

+* Elevated permissions

+ * See, [Use Azure AD groups to manage role assignments](../roles/groups-concept.md)

+Learn more:

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

+* [Azure AD version 2 cmdlets for group management](../enterprise-users/groups-settings-v2-cmdlets.md).

+> [!NOTE]

+> Use security groups to assign up to 1,500 applications.

+ 

+### Mail-enabled security group

+To create a mail-enabled security group, go to the [Microsoft 365 admin center](https://admin.microsoft.com/). Enable a security group for mail during creation. You canΓÇÖt enable it later. You can't create the group in the Azure portal.

+### Hybrid organizations and Azure AD security groups

+Hybrid organizations have infrastructure for on-premises and an Azure AD. Hybrid organizations that use Active Directory can create security groups on-premises and sync them to the cloud. Therefore, only users in the on-premises environment can be added to the security groups.

+> [!IMPORTANT]

+> Protect your on-premises infrastructure from compromise. See, [Protecting Microsoft 365 from on-premises attacks](./protect-m365-from-on-premises-attacks.md).

+## Microsoft 365 Groups

+Microsoft 365 Groups is the membership service for access across Microsoft 365. They can be created from the Azure portal, or the Microsoft 365 admin center. When you create a Microsoft 365 Group, you grant access to a group of resources for collaboration.

+Learn more:

+* [Overview of Microsoft 365 Groups for administrators](/microsoft-365/admin/create-groups/office-365-groups?view=o365-worldwide&preserve-view=true)

+* [Create a group in the Microsoft 365 admin center](/microsoft-365/admin/create-groups/create-groups?view=o365-worldwide&preserve-view=true)

+* [Azure portal](https://portal.azure.com/)

+* [Microsoft 365 admin center](https://admin.microsoft.com/)

+### Microsoft 365 Groups roles

+* **Group owners**

+ * Add or remove members

+ * Delete conversations from the shared inbox

+ * Change group settings

+ * Rename the group

+ * Update the description or picture

+* **Members**

+ * Access everything in the group

+ * Can't change group settings

+ * Can invite guests to join the group

+ * [Manage guest access in Microsoft 365 groups](/microsoft-365/admin/create-groups/manage-guest-access-in-groups)

+* **Guests**

+ * Are members from outside your organization

+ * Have some limits to functionality in Teams

+### Microsoft 365 Group settings

+Select email alias, privacy, and whether to enable the group for teams.

+ 

+After setup, add members, and configure settings for email usage, etc.

+## Next steps

+Use the following series of articles to learn about securing external access to resources. We recommend you follow the listed order.

+1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md)

+2. [Discover the current state of external collaboration in your organization](2-secure-access-current-state.md)

+3. [Create a security plan for external access to resources](3-secure-access-plan.md)

+4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md) (You're here)

+5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md)

+6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md)

+7. [Manage external access to resources with Conditional Access policies](7-secure-access-conditional-access.md)

+8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md)

+9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md)

+10. [Convert local guest accounts to Azure Active Directory B2B guest accounts](10-secure-local-guest.md)

+ Title: Transition to governed collaboration with Azure Active Directory B2B collaboration

+description: Move to governed collaboration with Azure Ad B2B collaboration by using controls, tools, and settings.

+# Transition to governed collaboration with Azure Active Directory B2B collaboration

+Understanding collaboration helps secure external access to your resources. Use the information in this article to move external collaboration into Azure Active Directory B2B (Azure AD B2B) collaboration.

+* See, [B2B collaboration overview](../external-identities/what-is-b2b.md)

+* Learn about: [External Identities in Azure AD](../external-identities/external-identities-overview.md)

+## Before you begin

+This article is number 5 in a series of 10 articles. We recommend you review the articles in order. Go to the **Next steps** section to see the entire series.

+## Control collaboration

+You can limit the organizations your users collaborate with (inbound and outbound), and who in your organization can invite guests. Most organizations permit business units to decide collaboration, and delegate approval and oversight. For example, organizations in government, education, and finance often don't permit open collaboration. You can use Azure AD features to control collaboration.

+To control access your tenant, deploy one or more of the following solutions:

+- **External collaboration settings** ΓÇô restrict the email domains that invitations go to

+- **Cross tenant access settings** ΓÇô control application access by guests by user, group, or tenant (inbound). Control external Azure AD tenant and application access for users (outbound).

+- **Connected organizations** ΓÇô determine what organizations can request access packages in Entitlement Management

+### Determine collaboration partners

+Document the organizations you collaborate with, and organization users' domains, if needed. Domain-based restrictions might be impractical. One collaboration partner can have multiple domains, and a partner can add domains. For example, a partner with multiple business units, with separate domains, can add more domains as they configure synchronization.

+If your users use Azure AD B2B, you can discover the external Azure AD tenants they're collaborating with, with the sign-in logs, PowerShell, or a workbook. Learn more:

+* [Get MsIdCrossTenantAccessActivity](https://github.com/AzureAD/MSIdentityTools/wiki/Get-MSIDCrossTenantAccessActivity)

+* [Cross-tenant access activity workbook](../reports-monitoring/workbook-cross-tenant-access-activity.md)

+You can enable future collaboration with:

+- **External organizations** - most inclusive

+- **External organizations, but not denied organizations**

+- **Specific external organizations** - most restrictive

+> [!NOTE]

+> If your collaboration settings are highly restrictive, your users might go outside the collaboration framework. We recommend you enable a broad collaboration that your security requirements allow.

+Limits to one domain can prevent authorized collaboration with organizations that have other, unrelated domains. For example, the initial point of contact with Contoso might be a US-based employee with email that has a `.com` domain. However if you allow only the `.com` domain, you can omit Canadian employees who have the `.ca` domain.

+You can allow specific collaboration partners for a subset of users. For example, a university might restrict student accounts from accessing external tenants, but can allow faculty to collaborate with external organizations.

+### Allowlist and blocklist with external collaboration settings

+You can use an allowlist or blocklist for organizations. You can use an allowlist, or a blocklist, not both.

+* **Allowlist** - limit collaboration to a list of domains. Other domains are on the blocklist.

+* **Blocklist** - allow collaboration with domains not on the blocklist

+Learn more: [Allow or block invitations to B2B users from specific organizations](../external-identities/allow-deny-list.md)

+> [!IMPORTANT]

+> Allowlists and blocklists don't apply to users in your directory. By default, they don't apply to OneDrive for Business and SharePoint allowlist or blocklists; these lists are separate. However, you can enable [SharePoint-OneDrive B2B integration](/sharepoint/sharepoint-azureb2b-integration).

+Some organizations have a blocklist of bad-actor domains from a managed security provider. For example, if the organization does business with Contoso and uses a `.com` domain, an unrelated organization can use the `.org` domain, and attempt a phishing attack.

+### Cross tenant access settings

+You can control inbound and outbound access using cross tenant access settings. In addition, you can trust multi-factor authentication (MFA), a compliant device, and hybrid Azure Active Directory joined device (HAAJD) claims from external Azure AD tenants. When you configure an organizational policy, it applies to the Azure AD tenant and applies to users in that tenant, regardless of domain suffix.

+You can enable collaboration across Microsoft clouds, such as Microsoft Azure operated by 21Vianet (Azure China) or Azure Government. Determine if your collaboration partners reside in a different Microsoft cloud.

+Learn more:

+* [Microsoft Azure operated by 21Vianet](/azure/china/overview-operations)

+* [Azure Government developer guide](/azure/azure-government/documentation-government-developer-guide)

+* [Configure Microsoft cloud settings for B2B collaboration (Preview)](../external-identities/cross-cloud-settings.md).

+You can allow inbound access to specific tenants (allowlist), and set the default policy to block access. Then, create organizational policies that allow access by user, group, or application.

+You can block access to tenants (blocklist). Set the default policy to **Allow** and then create organizational policies that block access to some tenants.

+> [!NOTE]

+> Cross tenant access settings, inbound access does not prevent users from sending invitations, nor prevent them from being redeemed. However, it does control application access and whether a token is issued to the guest user. If the guest can redeem an invitation, policy blocks application access.

+To control external organizations users access, configure outbound access policies similarly to inbound access: allowlist and blocklist. Configure default and organization-specific policies.

+Learn more: [Configure cross-tenant access settings for B2B collaboration](../external-identities/cross-tenant-access-settings-b2b-collaboration.md)

+> [!NOTE]

+> Cross tenant access settings apply to Azure AD tenants. To control access for partners not using Azure AD, use external collaboration settings.

+### Entitlement management and connected organizations

+Use entitlement management to ensure automatic guest-lifecycle governance. Create access packages and publish them to external users or to connected organizations, which support Azure AD tenants and other domains. When you create an access package, restrict access to connected organizations.

+Learn more: [What is entitlement management?](../governance/entitlement-management-overview.md)

+## Control external user access

+To begin collaboration, invite or enable a partner to access resources. Users gain access by:

+* [Azure AD B2B collaboration invitation redemption](../external-identities/redemption-experience.md)

+* [Self-service sign-up](../external-identities/self-service-sign-up-overview.md)

+* [Requesting access to an access package in entitlement management](../governance/entitlement-management-request-access.md)

+When you enable Azure AD B2B, you can invite guest users with links and email invitations. Self-service sign-up, and publishing access packages to the My Access portal, require more configuration.

+> [!NOTE]

+> Self-service sign-up enforces no allowlist or blocklist in external collaboration settings. Instead, use cross tenant access settings. You can integrate allowlists and blocklists with self-service sign-up using custom API connectors. See, [Add an API connector to a user flow](../external-identities/self-service-sign-up-add-api-connector.md).

+### Guest user invitations

+Determine who can invite guest users to access resources.

+* Most restrictive: Allow only administrators and users with the Guest Inviter role

+ * See, [Configure external collaboration settings](../external-identities/external-collaboration-settings-configure.md)

+* If security requirements permit, allow all Member UserType to invite guests

+* Determine if Guest UserType can invite guests

+ * Guest is the default Azure AD B2B user account

+ 

+### External user information

+Use Azure AD entitlement management to configure questions that external users answer. The questions appear to approvers to help them make a decision. You can configure sets of questions for each access package policy, so approvers have relevant information for access they approve. For example, ask vendors for their vendor contract number.

+Learn more: [Change approval and requestor information settings for an access package in entitlement management](../governance/entitlement-management-access-package-approval-policy.md)

+If you use a self-service portal, use API connectors to collect user attributes during sign-up. Use the attributes to assign access. You can create custom attributes in the Azure portal and use them in your self-service sign-up user flows. Read and write these attributes by using the Microsoft Graph API.

+Learn more:

+* [Use API connectors to customize and extend self-service sign-up](../external-identities/api-connectors-overview.md)

+* [Manage Azure AD B2C with Microsoft Graph](../../active-directory-b2c/microsoft-graph-operations.md)

+### Troubleshoot invitation redemption to Azure AD users

+Invited guest users from a collaboration partner can have trouble redeeming an invitation. See the following list for mitigations.

+* User domain isn't on an allowlist

+* The partnerΓÇÖs home tenant restrictions prevent external collaboration

+* The user isn't in the partner Azure AD tenant. For example, users at contoso.com are in Active Directory.

+ * They can redeem invitations with the email one-time password (OTP)

+ * See, [Azure Active Directory B2B collaboration invitation redemption](../external-identities/redemption-experience.md)

+## External user access

+Generally, there are resources you can share with external users, and some you can't. You can control what external users access.

+Learn more: [Manage external access with Entitlement Management](6-secure-access-entitlement-managment.md)

+By default, guest users see information and attributes about tenant members and other partners, including group memberships. Consider limiting external user access to this information.

+ 

+We recommend the following guest-user restrictions:

+* Limit guest access to browsing groups and other properties in the directory

+ * Use external collaboration settings to restrict guests from reading groups they aren't members of

+* Block access to employee-only apps

+ * Create a Conditional Access policy to block access to Azure AD-integrated applications for non-guest users

+* Block access to the Azure portal

+ * You can make needed exceptions

+ * Create a Conditional Access policy with all guest and external users. Implement a policy to block access.

+Learn more: [Conditional Access: Cloud apps, actions, and authentication context](../conditional-access/concept-conditional-access-cloud-apps.md)

+## Remove users who don't need access

+Establish a process to review and remove users who don't need access. Include external users in your tenant as guests, and users with member accounts.

+Learn more: [Use Azure AD Identity Governance to review and remove external users who no longer have resource access](../governance/access-reviews-external-users.md)

+Some organizations add external users as members (vendors, partners, and contractors). Assign an attribute, or username:

+* **Vendors** - v-alias@contoso.com

+* **Partners** - p-alias@contoso.com

+* **Contractors** - c-alias@contoso.com

+Evaluate external users with member accounts to determine access. You might have guest users not invited through entitlement management or Azure AD B2B.

+To find these users:

+* [Use Azure AD Identity Governance to review and remove external users who no longer have resource access](../governance/access-reviews-external-users.md)

+* Use a sample PowerShell script on [access-reviews-samples/ExternalIdentityUse/](https://github.com/microsoft/access-reviews-samples/tree/master/ExternalIdentityUse)

+## Transition current external users to Azure AD B2B

+If you don't use Azure AD B2B, you likely have non-employee users in your tenant. We recommend you transition these accounts to Azure AD B2B external user accounts and then change their UserType to Guest. Use Azure AD and Microsoft 365 to handle external users.

+Include or exclude:

+* Guest users in Conditional Access policies

+* Guest users in access packages and access reviews

+* External access to Microsoft Teams, SharePoint, and other resources

+You can transition these internal users while maintaining current access, user principal name (UPN), and group memberships.

+Lear more: [Invite external users to B2B collaboration](../external-identities/invite-internal-users.md)

+## Decommission collaboration methods

+To complete the transition to governed collaboration, decommission unwanted collaboration methods. Decommissioning is based on the level of control to exert on collaboration, and the security posture. See, [Determine your security posture for external access](1-secure-access-posture.md).

+### Microsoft Teams invitation

+By default, Teams allows external access. The organization can communicate with external domains. To restrict or allow domains for Teams, use the [Teams admin center](https://admin.teams.microsoft.com/company-wide-settings/external-communications).

+### Sharing through SharePoint and OneDrive

+Sharing through SharePoint and OneDrive adds users not in the entitlement management process.

+* [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business](9-secure-access-teams-sharepoint.md)

+* [Block OneDrive use from Office](/office365/troubleshoot/group-policy/block-onedrive-use-from-office)

+### Emailed documents and sensitivity labels

+Users send documents to external users by email. You can use sensitivity labels to restrict and encrypt access to documents.

+See, [Learn about sensitivity labels](/microsoft-365/compliance/sensitivity-labels?view=o365-worldwide&preserve-view=true).

+### Unsanctioned collaboration tools

+Some users likely use Google Docs, DropBox, Slack, or Zoom. You can block use of these tools from a corporate network, at the firewall level, and with mobile application management for organization-managed devices. However, this action blocks sanctioned instances and doesn't block access from unmanaged devices. Block tools you donΓÇÖt want, and create policies for no unsanctioned usage.

+For more information on governing applications, see:

+* [Governing connected apps](/defender-cloud-apps/governance-actions)

+* [Govern discovered apps](/defender-cloud-apps/governance-discovery)

+## Next steps

+Use the following series of articles to learn about securing external access to resources. We recommend you follow the listed order.

+1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md)

+2. [Discover the current state of external collaboration in your organization](2-secure-access-current-state.md)

+3. [Create a security plan for external access to resources](3-secure-access-plan.md)

+4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md)

+5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md) (You're here)

+6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md)

+7. [Manage external access to resources with Conditional Access policies](7-secure-access-conditional-access.md)

+8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md)

+9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md)

+10. [Convert local guest accounts to Azure Active Directory B2B guest accounts](10-secure-local-guest.md)

+ Title: Manage external access with Azure Active Directory entitlement management

+description: How to use Azure AD Entitlement Management as a part of your overall external access security plan.

+# Manage external access with Azure Active Directory entitlement management

+Use the entitlement management feature to manage the identity and access lifecycle. You can automate access request workflows, access assignments, reviews, and expiration. Delegated non-admins use entitlement management to create access packages that external users, from other organizations, can request access to. One and multi-stage approval workflows are configurable to evaluate requests, and provision users for time-limited access with recurring reviews. Use entitlement management for policy-based provisioning and deprovisioning of external accounts.

+Learn more:

+* [What is entitlement management?](../governance/entitlement-management-overview.md)

+* [What are access packages and what resources can I manage with them?](../governance/entitlement-management-overview.md#what-are-access-packages-and-what-resources-can-i-manage-with-them)

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

+## Before you begin

+This article is number 6 in a series of 10 articles. We recommend you review the articles in order. Go to the **Next steps** section to see the entire series.

+## Enable entitlement management

+The following key concepts are important to understand for entitlement management.

+### Access packages

+An access package is the foundation of entitlement management: groupings of policy-governed resources for users to collaborate on a project or do other tasks. For example, an access package might include:

+* Access to SharePoint sites

+* Enterprise applications, including your custom in-house and SaaS apps, like Salesforce

+* Microsoft Teams

+* Microsoft 365 Groups

+### Catalogs

+Access packages reside in catalogs. When you want to group related resources and access packages and delegate their management, you create a catalog. First, you add resources to a catalog, and then you can add resources to access packages. For example, you can create a finance catalog, and delegate its management to a member of the finance team. That person can add resources, create access packages, and manage access approval.

+Learn more:

+* [Create and manage a catalog of resources in entitlement management](../governance/entitlement-management-catalog-create.md)

+* [Delegation and roles in entitlement management](../governance/entitlement-management-delegate.md)

+* [Add resources to a catalog](../governance/entitlement-management-catalog-create.md#add-resources-to-a-catalog)

+The following diagram shows a typical governance lifecycle of an external user gaining access to an access package, with an expiration.

+ 

+### Self-service external access

+You can make access packages available, through the Azure AD My Access portal, to enable external users to request access. Policies determine who can request an access package. See, [Request access to an access package in entitlement management](../governance/entitlement-management-request-access.md).

+You specify who is allowed to request the access package:

+* Connected organizations

+ * See, [Add a connected organization in entitlement management](../governance/entitlement-management-organization.md)

+* Configured connected organizations

+* Users from organizations

+* Member or guest users in your tenant

+### Approvals

+Access packages can include mandatory approval for access. Approvals can be single or multi-stage and are determined by policies. If internal and external users need to access the same package, you can set up access policies for categories of connected organizations, and for internal users.

+> [!IMPORTANT]

+> Implement approval processes for external users.

+### Expiration

+Access packages can include an expiration date or a number of days you set for access. When the access package expires, and access ends, the B2B guest user object representing the user can be deleted or blocked from signing in. We recommend you enforce expiration on access packages for external users. Not all access packages have expirations.

+> [!IMPORTANT]

+> For packages without expiration, perform regular access reviews.

+### Access reviews

+Access packages can require periodic access reviews, which require the package owner or a designee to attest to the continued need for usersΓÇÖ access. See, [Manage guest access with access reviews](../governance/manage-guest-access-with-access-reviews.md).

+Before you set up your review, determine the following criteria:

+* Who

+ * Criteria for continued access

+ * Reviewers

+* How often

+ * Built-in options are monthly, quarterly, bi-annually, or annually

+ * We recommend quarterly, or more frequent, reviews for packages that support external access

+> [!IMPORTANT]

+> Access package reviews examine access granted through entitlement management. Set up other processes to review access to external users, outside entitlement management.

+Learn more: [Plan a Microsoft Entra access reviews deployment](../governance/deploy-access-reviews.md).

+## Using entitlement management automation

+* [Working with the Azure AD entitlement management API](/graph/api/resources/entitlementmanagement-overview?view=graph-rest-1.0&preserve-view=true )

+* [accessPackage resource type](/graph/api/resources/accesspackage?view=graph-rest-1.0&preserve-view=true )

+* [Azure AD access reviews](/graph/api/resources/accessreviewsv2-overview?view=graph-rest-1.0&preserve-view=true )

+* [connectedOrganization resource type](/graph/api/resources/connectedorganization?view=graph-rest-1.0&preserve-view=true )

+* [entitlementManagementSettings resource type](/graph/api/resources/entitlementmanagementsettings?view=graph-rest-1.0&preserve-view=true )

+## External access governance recommendations

+### Best practices

+We recommend the following practices to govern external access with entitlement management.

+* For projects with one or more business partners, create and use access packages to onboard and provide access to resources.

+ * [Create a new access package in entitlement management](../governance/entitlement-management-access-package-create.md)

+* If you have B2B users in your directory, you can assign them to access packages.

+* You can assign access in the Azure portal or with Microsoft Graph

+ * [View, add, and remove assignments for an access package in entitlement management](../governance/entitlement-management-access-package-assignments.md)

+ * [Create a new access package in entitlement management](../governance/entitlement-management-access-package-create.md)

+### Identity Governance - Settings

+Use **Identity Governance - Settings** to remove users from your directory when their access packages expire. The following settings apply to users onboarded with entitlement management.

+ 

+### Delegate catalog and package management

+You can delegate catalog and package management to business owners, who have more information on who should access. See, [Delegation and roles in entitlement managements](../governance/entitlement-management-delegate.md)

+ 

+### Enforce access package expiration

+You can enforce access expiration for external users. See, [Change lifecycle settings for an access package in entitlement management](../governance/entitlement-management-access-package-lifecycle-policy.md).

+ 

+* For the end date of a project-based access package, use **On date** to set the date.

+ * Otherwise we recommend expiration to be no longer 365 days, unless it's a multi-year project

+* Allow users to extend access

+ * Require approval to grant the extension

+### Enforce guest-access package reviews

+You can enforce reviews of guest-access packages to avoid inappropriate access for guests. See, [Manage guest access with access reviews](../governance/manage-guest-access-with-access-reviews.md).

+ 

+* Enforce quarterly reviews

+* For compliance-related projects, set the reviewers to be reviewers, rather than self-review for external users.

+ * You can use access package managers as reviewers

+* For less sensitive projects, users self-reviewing reduces the burden to remove access from users no longer with the organization.

+Learn more: [Govern access for external users in entitlement management](../governance/entitlement-management-external-users.md)

+## Next steps

+Use the following series of articles to learn about securing external access to resources. We recommend you follow the listed order.

+1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md)

+2. [Discover the current state of external collaboration in your organization](2-secure-access-current-state.md)

+3. [Create a security plan for external access to resources](3-secure-access-plan.md)

+4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md)

+5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md)

+6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md) (You're here)

+7. [Manage external access to resources with Conditional Access policies](7-secure-access-conditional-access.md)

+8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md)

+9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md)

+10. [Convert local guest accounts to Azure Active Directory B2B guest accounts](10-secure-local-guest.md)

+

+ Title: Manage external access to resources with Conditional Access

+description: Learn to use Conditional Access policies to secure external access to resources.

+# Manage external access to resources with Conditional Access policies

+Conditional Access interprets signals, enforces policies, and determines if a user is granted access to resources. In this article, learn about applying Conditional Access policies to external users. The article assumes you might not have access to entitlement management, a feature you can use with Conditional Access.

+Learn more:

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

+* [Plan a Conditional Access deployment](../conditional-access/plan-conditional-access.md)

+* [What is entitlement management?](../governance/entitlement-management-overview.md)

+The following diagram illustrates signals to Conditional Access that trigger access processes.

+ 

+## Before you begin

+This article is number 7 in a series of 10 articles. We recommend you review the articles in order. Go to the **Next steps** section to see the entire series.

+## Align a security plan with Conditional Access policies

+In the third article, in the set of 10 articles, there's guidance on creating a security plan. Use that plan to help create Conditional Access policies for external access. Part of the security plan includes:

+* Grouped applications and resources for simplified access

+* Sign-in requirements for external users

+> [!IMPORTANT]

+> Create internal and external user test accounts to test policies before applying them.

+See article three, [Create a security plan for external access to resources](3-secure-access-plan.md)

+## Conditional Access policies for external access

+The following sections are best practices for governing external access with Conditional Access policies.

+### Entitlement management or groups

+If you canΓÇÖt use connected organizations in entitlement management, create an Azure AD security group, or Microsoft 365 Group for partner organizations. Assign users from that partner to the group. You can use the groups in Conditional Access policies.

+Learn more:

+* [What is entitlement management?](../governance/entitlement-management-overview.md)

+* [Manage Azure Active Directory groups and group membership](../fundamentals/how-to-manage-groups.md)

+* [Overview of Microsoft 365 Groups for administrators](/microsoft-365/admin/create-groups/office-365-groups?view=o365-worldwide&preserve-view=true)

+### Conditional Access policy creation

+Create as few Conditional Access policies as possible. For applications that have the same access requirements, add them to the same policy.

+Conditional Access policies apply to a maximum of 250 applications. If more than 250 applications have the same access requirement, create duplicate policies. For instance, Policy A applies to apps 1-250, Policy B applies to apps 251-500, etc.

+### Naming convention

+Use a naming convention that clarifies policy purpose. External access examples are:

+* ExternalAccess_actiontaken_AppGroup

+* ExternalAccess_Block_FinanceApps

+## Block external users from resources

+You can block external users from accessing resources with Conditional Access policies.

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

+2. Browse to **Azure Active Directory** > **Security** > **Conditional Access**.

+3. Select **New policy**.

+4. Enter a policy a name.

+5. Under **Assignments**, select **Users or workload identities**.

+6. Under **Include**, select **All guests and external users**.

+7. Under **Exclude**, select **Users and groups**.

+8. Select emergency access accounts.

+9. Select **Done**.

+10. Under **Cloud apps or actions** > **Include**, select **All cloud apps**.

+11. Under **Exclude**, select applications you want to exclude.

+12. Under **Access controls** > **Grant**, select **Block access**.

+13. Select **Select**.

+14. Select **Enable policy** to **Report-only**.

+15. Select **Create**.

+> [!NOTE]

+> You can confirm settings in **report only** mode. See, Configure a Conditional Access policy in repory-only mode, in [Conditional Access insights and reporting](../conditional-access/howto-conditional-access-insights-reporting.md).

+Learn more: [Manage emergency access accounts in Azure AD](../roles/security-emergency-access.md)

+### Allow external access to specific external users

+There are scenarios when it's necessary to allow access for a small, specific group.

+Before you begin, we recommend you create a security group, which contains external users who access resources. See, [Quickstart: Create a group with members and view all groups and members in Azure AD](../fundamentals/groups-view-azure-portal.md).

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

+2. Browse to **Azure Active Directory** > **Security** > **Conditional Access**.

+3. Select **New policy**.

+4. Enter a policy name.

+5. Under **Assignments**, select **Users or workload identities**.

+6. Under **Include**, select **All guests and external users**.

+7. Under **Exclude**, select **Users and groups**

+8. Select emergency access accounts.

+9. Select the external users security group.

+10. Select **Done**.

+11. Under **Cloud apps or actions** > **Include**, select **All cloud apps**.

+12. Under **Exclude**, select applications you want to exclude.

+13. Under **Access controls** > **Grant**, select **Block access**.

+14. Select **Select**.

+15. Select **Create**.

+> [!NOTE]

+> You can confirm settings in **report only** mode. See, Configure a Conditional Access policy in repory-only mode, in [Conditional Access insights and reporting](../conditional-access/howto-conditional-access-insights-reporting.md).

+Learn more: [Manage emergency access accounts in Azure AD](../roles/security-emergency-access.md)

+### Service provider access

+Conditional Access policies for external users might interfere with service provider access, for example granular delegated administrate privileges.

+Learn more: [Introduction to granular delegated admin privileges (GDAP)](/partner-center/gdap-introduction)

+## Conditional Access templates

+Conditional Access templates are a convenient method to deploy new policies aligned with Microsoft recommendations. These templates provide protection aligned with commonly used policies across various customer types and locations.

+Learn more: [Conditional Access templates (Preview)](../conditional-access/concept-conditional-access-policy-common.md)

+## Next steps

+Use the following series of articles to learn about securing external access to resources. We recommend you follow the listed order.

+1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md)

+2. [Discover the current state of external collaboration in your organization](2-secure-access-current-state.md)

+3. [Create a security plan for external access to resources](3-secure-access-plan.md)

+4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md)

+5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md)

+6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md)

+7. [Manage external access to resources with Conditional Access policies](7-secure-access-conditional-access.md) (You're here)

+8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md)

+9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md)

+10. [Convert local guest accounts to Azure Active Directory B2B guest accounts](10-secure-local-guest.md)

+ Title: Control external access to resources in Azure Active Directory with sensitivity labels

+description: Use sensitivity labels as a part of your overall security plan for external access

+# Control external access to resources in Azure Active Directory with sensitivity labels

+Use sensitivity labels to help control access to your content in Office 365 applications, and in containers like Microsoft Teams, Microsoft 365 Groups, and SharePoint sites. They protect content without hindering user collaboration. Use sensitivity labels to send organization-wide content across devices, apps, and services, while protecting data. Sensitivity labels help organizations meet compliance and security policies.

+

+See, [Learn about sensitivity labels](/microsoft-365/compliance/sensitivity-labels?view=o365-worldwide&preserve-view=true)

+## Before you begin

+This article is number 8 in a series of 10 articles. We recommend you review the articles in order. Go to the **Next steps** section to see the entire series.

+## Assign classification and enforce protection settings

+You can classify content without adding any protection settings. Content classification assignment stays with the content while itΓÇÖs used and shared. The classification generates usage reports with sensitive-content activity data.

+Enforce protection settings such as encryption, watermarks, and access restrictions. For example, users apply a Confidential label to a document or email. The label can encrypt the content and add a Confidential watermark. In addition, you can apply a sensitivity label to a container like a SharePoint site, and help manage external users access.

+Learn more:

+* [Restrict access to content by using sensitivity labels to apply encryption](/microsoft-365/compliance/encryption-sensitivity-labels?view=o365-worldwide&preserve-view=true)

+* [Use sensitivity labels to protect content in Microsoft Teams, Microsoft 365 Groups, and SharePoint sites](/microsoft-365/compliance/sensitivity-labels-teams-groups-sites)

+Sensitivity labels on containers can restrict access to the container, but content in the container doesn't inherit the label. For example, a user takes content from a protected site, downloads it, and then shares it without restrictions, unless the content had a sensitivity label.

+ >[!NOTE]

+>To apply sensitivity labels users sign into their Microsoft work or school account.

+## Permissions to create and manage sensitivity levels

+Team members who need to create sensitivity labels require permissions to:

+* Microsoft 365 Defender portal,

+* Microsoft Purview compliance portal, or

+* [Microsoft Purview compliance portal](/microsoft-365/compliance/microsoft-365-compliance-center?view=o365-worldwide&preserve-view=true)

+By default, tenant Global Administrators have access to admin centers and can provide access, without granting tenant Admin permissions. For this delegated limited admin access, add users to the following role groups:

+* Compliance Data Administrator,

+* Compliance Administrator, or

+* Security Administrator

+## Sensitivity label strategy

+As you plan the governance of external access to your content, consider content, containers, email, and more.

+### High, Medium, or Low Business Impact

+To define High, Medium, or Low Business Impact (HBI, MBI, LBI) for data, sites, and groups, consider the effect on your organization if the wrong content types are shared.

+* Credit card, passport, national/regional ID numbers

+ * [Apply a sensitivity label to content automatically](/microsoft-365/compliance/apply-sensitivity-label-automatically?view=o365-worldwide&preserve-view=true)

+* Content created by corporate officers: compliance, finance, executive, etc.

+* Strategic or financial data in libraries or sites.

+Consider the content categories that external users can't have access to, such as containers and encrypted content. You can use sensitivity labels, enforce encryption, or use container access restrictions.

+### Email and content

+Sensitivity labels can be applied automatically or manually to content.

+See, [Apply a sensitivity label to content automatically](/microsoft-365/compliance/apply-sensitivity-label-automatically?view=o365-worldwide&preserve-view=true)

+#### Sensitivity labels on email and content

+A sensitivity label in a document or email is customizable, clear text, and persistent.

+* **Customizable** - create labels for your organization and determine the resulting actions

+* **Clear text** - is incorporated in metadata and readable by applications and services

+* **Persistency** - ensures the label and associated protections stay with the content, and help enforce policies

+> [!NOTE]

+> Each content item can have one sensitivity label applied.

+### Containers

+Determine the access criteria if Microsoft 365 Groups, Teams, or SharePoint sites are restricted with sensitivity labels. You can label content in containers or use automatic labeling for files in SharePoint, OneDrive, etc.

+Learn more: [Get started with sensitivity labels](/microsoft-365/compliance/get-started-with-sensitivity-labels?view=o365-worldwide&preserve-view=true)

+#### Sensitivity labels on containers

+You can apply sensitivity labels to containers such as Microsoft 365 Groups, Microsoft Teams, and SharePoint sites. Sensitivity labels on a supported container apply the classification and protection settings to the connected site or group. Sensitivity labels on these containers can control:

+* **Privacy** - select the users who can see the site

+* **External user access** - determine if group owners can add guests to a group

+* **Access from unmanaged devices** - decide if and how unmanaged devices access content

+ 

+Sensitivity labels applied to a container, such as a SharePoint site, aren't applied to content in the container; they control access to content in the container. Labels can be applied automatically to the content in the container. For users to manually apply labels to content, enable sensitivity labels for Office files in SharePoint and OneDrive.

+Learn more:

+* [Enable sensitivity labels for Office files in SharePoint and OneDrive](/microsoft-365/compliance/sensitivity-labels-sharepoint-onedrive-files?view=o365-worldwide&preserve-view=true).

+* [Use sensitivity labels to protect content in Microsoft Teams, Microsoft 365 Groups, and SharePoint sites](/microsoft-365/compliance/sensitivity-labels-teams-groups-sites)

+* [Assign sensitivity labels to Microsoft 365 groups in Azure AD](../enterprise-users/groups-assign-sensitivity-labels.md)

+### Implement sensitivity labels

+After you determine use of sensitivity labels, see the following documentation for implementation.

+* [Get started with sensitivity labels](/microsoft-365/compliance/get-started-with-sensitivity-labels?view=o365-worldwide&preserve-view=true)

+* [Create and publish sensitivity labels](/microsoft-365/compliance/create-sensitivity-labels?view=o365-worldwide&preserve-view=true)

+* [Restrict access to content by using sensitivity labels to apply encryption](/microsoft-365/compliance/encryption-sensitivity-labels?view=o365-worldwide&preserve-view=true)

+## Next steps

+Use the following series of articles to learn about securing external access to resources. We recommend you follow the listed order.

+1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md)

+2. [Discover the current state of external collaboration in your organization](2-secure-access-current-state.md)

+3. [Create a security plan for external access to resources](3-secure-access-plan.md)

+4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md)

+5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md)

+6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md)

+7. [Manage external access to resources with Conditional Access policies](7-secure-access-conditional-access.md)

+8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md) (You're here)

+9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md)

+10. [Convert local guest accounts to Azure Active Directory B2B guest accounts](10-secure-local-guest.md)

+ Title: Secure external access to Microsoft Teams, SharePoint, and OneDrive with Azure Active Directory

+description: Secure access to Microsoft 365 services as a part of your external access security plan

+# Secure external access to Microsoft Teams, SharePoint, and OneDrive with Azure Active Directory

+Use this article to determine and configure your organization's external collaboration using Microsoft Teams, OneDrive for Business, and SharePoint. A common challenge is balancing security and ease of collaboration for end users and external users. If an approved collaboration method is perceived as restrictive and onerous, end users evade the approved method. End users might email unsecured content, or set up external processes and applications, such as a personal DropBox or OneDrive.

+## Before you begin

+This article is number 9 in a series of 10 articles. We recommend you review the articles in order. Go to the **Next steps** section to see the entire series.

+## External Identities settings and Azure Active Directory

+Sharing in Microsoft 365 is partially governed by the **External Identities, External collaboration settings** in Azure Active Directory (Azure AD). If external sharing is disabled or restricted in Azure AD, it overrides sharing settings configured in Microsoft 365. An exception is if Azure AD B2B integration isn't enabled. You can configure SharePoint and OneDrive to support ad-hoc sharing via one-time password (OTP). The following screenshot shows the External Identities, External collaboration settings dialog.

+Learn more:

+* [Azure portal](https://portal.azure.com/)

+* [External Identities in Azure AD](../external-identities/external-identities-overview.md)

+### Guest user access

+Guest users are invited to have access to resources.

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

+1. Browse to **Azure Active Directory** > **External Identities** > **External collaboration settings**.

+1. Find the **Guest user access** options.

+1. To prevent guest-user access to other guest-user details, and to prevent enumeration of group membership, select **Guest users have limited access to properties and memberships of directory objects**.

+### Guest invite settings

+Guest invite settings determine who invites guests and how guests are invited. The settings are enabled if the B2B integration is enabled. It's recommended that administrators and users, in the Guest Inviter role, can invite. This setting allows setup of controlled collaboration processes. For example:

+* Team owner submits a ticket requesting assignment to the Guest Inviter role:

+ * Responsible for guest invitations

+ * Agrees to not add users to SharePoint

+ * Performs regular access reviews

+ * Revokes access as needed

+* The IT team:

+ * After training is complete, the IT team grants the Guest Inviter role

+ * Ensures there are sufficient Azure AD Premium P2 licenses for the Microsoft 365 group owners who will review

+ * Creates a Microsoft 365 group access review

+ * Confirms access reviews occur

+ * Removes users added to SharePoint

+1. Select the banner for **Email one-time passcodes for guests**.

+2. For **Enable guest self-service sign up via user flows**, select **Yes**.

+### Collaboration restrictions

+For the Collaboration restrictions option, the organization's business requirements dictate the choice of invitation.

+* **Allow invitations to be sent to any domain (most inclusive)** - any user can be invited

+* **Deny invitations to the specified domains** - any user outside those domains can be invited

+* **Allow invitations only to the specified domains (most restrictive)** - any user outside those domains can't be invited

+## External users and guest users in Teams

+Teams differentiates between external users (outside your organization) and guest users (guest accounts). You can manage collaboration setting in the [Microsoft Teams admin center](https://admin.teams.microsoft.com/company-wide-settings/external-communications) under Org-wide settings. Authorized account credentials are required to sign in to the Teams Admin portal.

+* **External Access** - Teams allows external access by default. The organization can communicate with all external domains

+ * Use External Access setting to restrict or allow domains

+* **Guest Access** - manage guest access in Teams

+Learn more: [Use guest access and external access to collaborate with people outside your organization](/microsoftteams/communicate-with-users-from-other-organizations).

+The External Identities collaboration feature in Azure AD controls permissions. You can increase restrictions in Teams, but restrictions can't be lower than Azure AD settings.

+Learn more:

+* [Manage external meetings and chat in Microsoft Teams](/microsoftteams/manage-external-access)

+* [Step 1. Determine your cloud identity model](/microsoft-365/enterprise/about-microsoft-365-identity)

+* [Identity models and authentication for Microsoft Teams](/microsoftteams/identify-models-authentication)

+* [Sensitivity labels for Microsoft Teams](/microsoftteams/sensitivity-labels)

+## Govern access in SharePoint and OneDrive

+SharePoint administrators can find organization-wide settings in the SharePoint admin center. It's recommended that your organization-wide settings are the minimum security levels. Increase security on some sites, as needed. For example, for a high-risk project, restrict users to certain domains, and disable members from inviting guests.

+Learn more:

+* [SharePoint admin center](https://microsoft-admin.sharepoint.com) - access permissions are required

+* [Get started with the SharePoint admin center](/sharepoint/get-started-new-admin-center)

+* [External sharing overview](/sharepoint/external-sharing-overview)

+### Integrating SharePoint and OneDrive with Azure AD B2B

+As a part of your strategy to govern external collaboration, it's recommended you enable SharePoint and OneDrive integration with Azure AD B2B. Azure AD B2B has guest-user authentication and management. With SharePoint and OneDrive integration, use one-time passcodes for external sharing of files, folders, list items, document libraries, and sites.

+Learn more:

+* [Email one-time passcode authentication](../external-identities/one-time-passcode.md)

+* [SharePoint and OneDrive integration with Azure AD B2B](/sharepoint/sharepoint-azureb2b-integration)

+* [B2B collaboration overview](../external-identities/what-is-b2b.md)

+If you enable Azure AD B2B integration, then SharePoint and OneDrive sharing is subject to the Azure AD organizational relationships settings, such as **Members can invite** and **Guests can invite**.

+### Sharing policies in SharePoint and OneDrive

+In the Azure portal, you can use the External Sharing settings for SharePoint and OneDrive to help configure sharing policies. OneDrive restrictions can't be more permissive than SharePoint settings.

+Learn more: [External sharing overview](/sharepoint/external-sharing-overview)

+ 

+#### External sharing settings recommendations

+Use the guidance in this section when configuring external sharing.

+* **Anyone** - Not recommended. If enabled, regardless of integration status, no Azure policies are applied for this link type.

+ * Don't enable this functionality for governed collaboration

+ * Use it for restrictions on individual sites

+* **New and existing guests** - Recommended, if integration is enabled

+ * Azure AD B2B integration enabled: new and current guests have an Azure AD B2B guest account you can manage with Azure AD policies

+ * Azure AD B2B integration not enabled: new guests don't have an Azure AD B2B account, and can't be managed from Azure AD

+ * Guests have an Azure AD B2B account, depending on how the guest was created

+* **Existing guests** - Recommended, if you don't have integration enabled

+ * With this option enabled, users can share with other users in your directory

+* **Only people in your organization** - Not recommended with external user collaboration

+ * Regardless of integration status, users can share with other users in your organization

+* **Limit external sharing by domain** - By default, SharePoint allows external access. Sharing is allowed with external domains.

+ * Use this option to restrict or allow domains for SharePoint

+* **Allow only users in specific security groups to share externally** - Use this setting to restrict who shares content in SharePoint and OneDrive. The setting in Azure AD applies to all applications. Use the restriction to direct users to training about secure sharing. Completion is the signal to add them to a sharing security group. If this setting is selected, and users can't become an approved sharer, they might find unapproved ways to share.

+* **Allow guests to share items they donΓÇÖt own** - Not recommended. The guidance is to disable this feature.

+* **People who use a verification code must reauthenticate after this many days (default is 30)** - Recommended

+### Access controls

+Access controls setting affect all users in your organization. Because you might not be able to control whether external users have compliant devices, the controls won't be addressed in this article.

+* **Idle session sign-out** - Recommended

+ * Use this option to warn and sign out users on unmanaged devices, after a period of inactivity

+ * You can configure the period of inactivity and the warning

+* **Network location** - Set this control to allow access from IP addresses your organization owns.

+ * For external collaboration, set this control if your external partners access resources when in your network, or with your virtual private network (VPN).

+### File and folder links

+In the SharePoint admin center, you can set how file and folder links are shared. You can configure the setting for each site.

+ 

+With Azure AD B2B integration enabled, sharing files and folders with users outside the organization results in the creation of a B2B user.

+1. For **Choose the type of link that's selected by default when users share files and folders in SharePoint and OneDrive**, select **Only people in your organization**.

+2. For **Choose the permission that's selected by default for sharing links**, select **Edit**.

+You can customize this setting for a per-site default.

+### Anyone links

+Enabling Anyone links isn't recommended. If you enable it, set an expiration, and restrict users to view permissions. If you select View only permissions for files or folders, users can't change Anyone links to include edit privileges.

+Learn more:

+* [External sharing overview](/sharepoint/external-sharing-overview)

+* [SharePoint and OneDrive integration with Azure AD B2B](/sharepoint/sharepoint-azureb2b-integration)

+## Next steps

+Use the following series of articles to learn about securing external access to resources. We recommend you follow the listed order.

+1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md)

+2. [Discover the current state of external collaboration in your organization](2-secure-access-current-state.md)

+3. [Create a security plan for external access to resources](3-secure-access-plan.md)

+4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md)

+5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md)

+6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md)

+7. [Manage external access to resources with Conditional Access policies](7-secure-access-conditional-access.md)

+8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md)

+9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md) (You're here)

+10. [Convert local guest accounts to Azure Active Directory B2B guest accounts](10-secure-local-guest.md)

+ Title: Architecture overview

+description: Learn what an Azure Active Directory tenant is and how to manage Azure using Azure Active Directory.

+# What is the Azure Active Directory architecture?

+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/active-directory-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/active-directory-whatis.md).

+## Azure AD architecture

+Azure AD's geographically distributed architecture combines extensive monitoring, automated rerouting, failover, and recovery capabilities, which deliver company-wide availability and performance to customers.

+The following architecture elements are covered in this article:

+* Service architecture design

+* Scalability

+* Continuous availability

+* Datacenters

+### Service architecture design

+The most common way to build an accessible and usable, data-rich system is through independent building blocks or scale units. For the Azure AD data tier, scale units are called *partitions*.

+The data tier has several front-end services that provide read-write capability. The diagram below shows how the components of a single-directory partition are delivered throughout geographically distributed datacenters.

+ 

+The components of Azure AD architecture include a primary replica and secondary replicas.

+#### Primary replica

+The *primary replica* receives all *writes* for the partition it belongs to. Any write operation is immediately replicated to a secondary replica in a different datacenter before returning success to the caller, thus ensuring geo-redundant durability of writes.

+#### Secondary replicas

+All directory *reads* are serviced from *secondary replicas*, which are at datacenters that are physically located across different geographies. There are many secondary replicas, as data is replicated asynchronously. Directory reads, such as authentication requests, are serviced from datacenters that are close to customers. The secondary replicas are responsible for read scalability.

+### Scalability

+Scalability is the ability of a service to expand to meet increasing performance demands. Write scalability is achieved by partitioning the data. Read scalability is achieved by replicating data from one partition to multiple secondary replicas distributed throughout the world.

+Requests from directory applications are routed to the closest datacenter. Writes are transparently redirected to the primary replica to provide read-write consistency. Secondary replicas significantly extend the scale of partitions because the directories are typically serving reads most of the time.

+Directory applications connect to the nearest datacenters. This connection improves performance, and therefore scaling out is possible. Since a directory partition can have many secondary replicas, secondary replicas can be placed closer to the directory clients. Only internal directory service components that are write-intensive target the active primary replica directly.

+### Continuous availability

+Availability (or uptime) defines the ability of a system to perform uninterrupted. The key to Azure ADΓÇÖs high-availability is that the services can quickly shift traffic across multiple geographically distributed datacenters. Each datacenter is independent, which enables de-correlated failure modes. Through this high availability design, Azure AD requires no downtime for maintenance activities.

+Azure ADΓÇÖs partition design is simplified compared to the enterprise AD design, using a single-master design that includes a carefully orchestrated and deterministic primary replica failover process.

+#### Fault tolerance

+A system is more available if it is tolerant to hardware, network, and software failures. For each partition on the directory, a highly available master replica exists: The primary replica. Only writes to the partition are performed at this replica. This replica is being continuously and closely monitored, and writes can be immediately shifted to another replica (which becomes the new primary) if a failure is detected. During failover, there could be a loss of write availability typically of 1-2 minutes. Read availability isn't affected during this time.

+Read operations (which outnumber writes by many orders of magnitude) only go to secondary replicas. Since secondary replicas are idempotent, loss of any one replica in a given partition is easily compensated by directing the reads to another replica, usually in the same datacenter.

+#### Data durability

+A write is durably committed to at least two datacenters prior to it being acknowledged. This happens by first committing the write on the primary, and then immediately replicating the write to at least one other datacenter. This write action ensures that a potential catastrophic loss of the datacenter hosting the primary doesn't result in data loss.

+Azure AD maintains a zero [Recovery Time Objective (RTO)](https://en.wikipedia.org/wiki/Recovery_time_objective) to not lose data on failovers. This includes:

+* Token issuance and directory reads

+* Allowing only about 5 minutes RTO for directory writes

+### Datacenters

+Azure ADΓÇÖs replicas are stored in datacenters located throughout the world. For more information, see [Azure global infrastructure](https://azure.microsoft.com/global-infrastructure/).

+Azure AD operates across datacenters with the following characteristics:

+* Authentication, Graph, and other AD services reside behind the Gateway service. The Gateway manages load balancing of these services. It will fail over automatically if any unhealthy servers are detected using transactional health probes. Based on these health probes, the Gateway dynamically routes traffic to healthy datacenters.

+* For *reads*, the directory has secondary replicas and corresponding front-end services in an active-active configuration operating in multiple datacenters. If a datacenter fails, traffic is automatically routed to a different datacenter.

+* For *writes*, the directory will fail over the primary replica across datacenters via planned (new primary is synchronized to old primary) or emergency failover procedures. Data durability is achieved by replicating any commit to at least two datacenters.

+#### Data consistency

+The directory model is one of eventual consistencies. One typical problem with distributed asynchronously replicating systems is that the data returned from a ΓÇ£particularΓÇ¥ replica may not be up-to-date.

+Azure AD provides read-write consistency for applications targeting a secondary replica by routing its writes to the primary replica, and synchronously pulling the writes back to the secondary replica.

+Application writes using the Microsoft Graph API of Azure AD are abstracted from maintaining affinity to a directory replica for read-write consistency. The Microsoft Graph API service maintains a logical session, which has affinity to a secondary replica used for reads; affinity is captured in a ΓÇ£replica tokenΓÇ¥ that the service caches using a distributed cache in the secondary replica datacenter. This token is then used for subsequent operations in the same logical session. To continue using the same logical session, subsequent requests must be routed to the same Azure AD datacenter. It isn't possible to continue a logical session if the directory client requests are being routed to multiple Azure AD datacenters; if this happens then the client has multiple logical sessions that have independent read-write consistencies.

+ >[!NOTE]

+ >Writes are immediately replicated to the secondary replica to which the logical session's reads were issued.

+#### Service-level backup

+Azure AD implements daily backup of directory data and can use these backups to restore data if there is any service-wide issue.

+

+The directory also implements soft deletes instead of hard deletes for selected object types. The tenant administrator can undo any accidental deletions of these objects within 30 days. For more information, see the [API to restore deleted objects](/graph/api/directory-deleteditems-restore).

+#### Metrics and monitors

+Running a high availability service requires world-class metrics and monitoring capabilities. Azure AD continually analyzes and reports key service health metrics and success criteria for each of its services. There is also continuous development and tuning of metrics and monitoring and alerting for each scenario, within each Azure AD service and across all services.

+If any Azure AD service isn't working as expected, action is immediately taken to restore functionality as quickly as possible. The most important metric Azure AD tracks is how quickly live site issues can be detected and mitigated for customers. We invest heavily in monitoring and alerts to minimize time to detect (TTD Target: <5 minutes) and operational readiness to minimize time to mitigate (TTM Target: <30 minutes).

+#### Secure operations

+Using operational controls such as multi-factor authentication (MFA) for any operation, and auditing of all operations. In addition, using a just-in-time elevation system to grant necessary temporary access for any operational task-on-demand on an ongoing basis. For more information, see [The Trusted Cloud](https://azure.microsoft.com/support/trust-center).

+## Next steps

+[Azure Active Directory developer's guide](../develop/index.yml)

+ Title: Header-based authentication with Azure Active Directory

+description: Architectural guidance on achieving header-based authentication with Azure Active Directory.

+# Header-based authentication with Azure Active Directory

+Legacy applications commonly use Header-based authentication. In this scenario, a user (or message originator) authenticates to an intermediary identity solution. The intermediary solution authenticates the user and propagates the required Hypertext Transfer Protocol (HTTP) headers to the destination web service. Azure Active Directory (AD) supports this pattern via its Application Proxy service, and integrations with other network controller solutions.

+In our solution, Application Proxy provides remote access to the application, authenticates the user, and passes headers required by the application.

+## Use when

+Remote users need to securely single sign-on (SSO) into to on-premises applications that require header-based authentication.

+

+## Components of system

+* **User**: Accesses legacy applications served by Application Proxy.

+* **Web browser**: The component that the user interacts with to access the external URL of the application.

+* **Azure AD**: Authenticates the user.

+* **Application Proxy service**: Acts as reverse proxy to send request from the user to the on-premises application. It resides in Azure AD and can also enforce any conditional access policies.

+* **Application Proxy connector**: Installed on-premises on Windows servers to provide connectivity to the applications. It only uses outbound connections. Returns the response to Azure AD.

+* **Legacy applications**: Applications that receive user requests from Application Proxy. The legacy application receives the required HTTP headers to set up a session and return a response.

+## Implement header-based authentication with Azure AD

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

+* [Header-based authentication for single sign-on with Application Proxy and PingAccess](../app-proxy/application-proxy-configure-single-sign-on-with-headers.md)

+* [Secure legacy apps with app delivery controllers and networks](../manage-apps/secure-hybrid-access.md)

+ Title: Kerberos constrained delegation with Azure Active Directory

+description: Architectural guidance on achieving Kerberos constrained delegation with Azure Active Directory.

+# Windows authentication - Kerberos constrained delegation with Azure Active Directory

+Based on Service Principle Names, Kerberos Constrained Delegation (KCD) provides constrained delegation between resources. It requires domain administrators to create the delegations and is limited to a single domain. You can use resource-based KCD to provide Kerberos authentication for a web application that has users in multiple domains within an Active Directory forest.

+Azure Active Directory Application Proxy can provide single sign-on (SSO) and remote access to KCD-based applications that require a Kerberos ticket for access and Kerberos Constrained Delegation (KCD).

+To enable SSO to your on-premises KCD applications that use integrated Windows authentication (IWA), give Application Proxy connectors permission to impersonate users in Active Directory. The Application Proxy connector uses this permission to send and receive tokens on the users' behalf.

+## When to use KCD

+Use KCD when there's a need to provide remote access, protect with pre-authentication, and provide SSO to on-premises IWA applications.

+

+## Components of system

+* **User**: Accesses legacy application that Application Proxy serves.

+* **Web browser**: The component that the user interacts with to access the external URL of the application.

+* **Azure AD**: Authenticates the user.

+* **Application Proxy service**: Acts as reverse proxy to send requests from the user to the on-premises application. It sits in Azure AD. Application Proxy can enforce conditional access policies.

+* **Application Proxy connector**: Installed on Windows on premises servers to provide connectivity to the application. Returns the response to Azure AD. Performs KCD negotiation with Active Directory, impersonating the user to get a Kerberos token to the application.

+* **Active Directory**: Sends the Kerberos token for the application to the Application Proxy connector.

+* **Legacy applications**: Applications that receive user requests from Application Proxy. The legacy applications return the response to the Application Proxy connector.

+## Implement Windows authentication (KCD) with Azure AD

+Explore the following resources to learn more about implementing Windows authentication (KCD) with Azure AD.

+* [Kerberos-based single sign-on (SSO) in Azure Active Directory with Application Proxy](../app-proxy/application-proxy-configure-single-sign-on-with-kcd.md) describes prerequisites and configuration steps.

+* The [Tutorial - Add an on-premises app - Application Proxy in Azure Active Directory](../app-proxy/application-proxy-add-on-premises-application.md) helps you to prepare your environment for use with Application Proxy.

+## Next steps

+* [Azure Active Directory authentication and synchronization protocol overview](auth-sync-overview.md) describes integration with authentication and synchronization protocols. Authentication integrations enable you to use Azure AD and its security and management features with little or no changes to your applications that use legacy authentication methods. Synchronization integrations enable you to sync user and group data to Azure AD and then user Azure AD management capabilities. Some sync patterns enable automated provisioning.

+* [Understand single sign-on with an on-premises app using Application Proxy](../app-proxy/application-proxy-config-sso-how-to.md) describes how SSO allows your users to access an application without authenticating multiple times. SSO occurs in the cloud against Azure AD and allows the service or Connector to impersonate the user to complete authentication challenges from the application.

+* [SAML single sign-on for on-premises apps with Azure Active Directory Application Proxy](../app-proxy/application-proxy-configure-single-sign-on-on-premises-apps.md) describes how you can provide remote access to on-premises applications that are secured with SAML authentication through Application Proxy.

+ Title: LDAP authentication with Azure Active Directory

+description: Architectural guidance on achieving LDAP authentication with Azure Active Directory.

+# LDAP authentication with Azure Active Directory

+Lightweight Directory Access Protocol (LDAP) is an application protocol for working with various directory services. Directory services, such as Active Directory, [store user and account information](https://www.dnsstuff.com/active-directory-service-accounts), and security information like passwords. The service then allows the information to be shared with other devices on the network. Enterprise applications such as email, customer relationship managers (CRMs), and Human Resources (HR) software can use LDAP to authenticate, access, and find information.

+Azure Active Directory (Azure AD) supports this pattern via Azure AD Domain Services (AD DS). It allows organizations that are adopting a cloud-first strategy to modernize their environment by moving off their on-premises LDAP resources to the cloud. The immediate benefits will be:

+* Integrated with Azure AD. Additions of users and groups, or attribute changes to their objects are automatically synchronized from your Azure AD tenant to AD DS. Changes to objects in on-premises Active Directory are synchronized to Azure AD, and then to AD DS.

+* Simplify operations. Reduces the need to manually keep and patch on-premises infrastructures.

+* Reliable. You get managed, highly available services

+## Use when

+There is a need to for an application or service to use LDAP authentication.

+

+## Components of system

+* **User**: Accesses LDAP-dependent applications via a browser.

+* **Web Browser**: The interface that the user interacts with to access the external URL of the application.

+* **Virtual Network**: A private network in Azure through which the legacy application can consume LDAP services.

+* **Legacy applications**: Applications or server workloads that require LDAP deployed either in a virtual network in Azure, or which have visibility to AD DS instance IPs via networking routes.

+* **Azure AD**: Synchronizes identity information from organizationΓÇÖs on-premises directory via Azure AD Connect.

+* **Azure AD Domain Services (AD DS)**: Performs a one-way synchronization from Azure AD to provide access to a central set of users, groups, and credentials. The AD DS instance is assigned to a virtual network. Applications, services, and VMs in Azure that connect to the virtual network assigned to AD DS can use common AD DS features such as LDAP, domain join, group policy, Kerberos, and NTLM authentication.

+ > [!NOTE]

+ > In environments where the organization cannot synchronize password hashes, or users sign-in using smart cards, we recommend that you use a resource forest in AD DS.

+* **Azure AD Connect**: A tool for synchronizing on premises identity information to Microsoft Azure AD. The deployment wizard and guided experiences help you configure prerequisites and components required for the connection, including sync and sign on from Active Directory to Azure AD.

+* **Active Directory**: Directory service that stores [on-premises identity information such as user and account information](https://www.dnsstuff.com/active-directory-service-accounts), and security information like passwords.

+## Implement LDAP authentication with Azure AD

+* [Create and configure an Azure AD DS instance](../../active-directory-domain-services/tutorial-create-instance.md)

+* [Configure virtual networking for an Azure AD DS instance](../../active-directory-domain-services/tutorial-configure-networking.md)

+* [Configure Secure LDAP for an Azure AD DS managed domain](../../active-directory-domain-services/tutorial-configure-ldaps.md)

+* [Create an outbound forest trust to an on-premises domain in Azure AD DS](../../active-directory-domain-services/tutorial-create-forest-trust.md)

+ Title: OAUTH 2.0 authentication with Azure Active Directory

+description: Architectural guidance on achieving OAUTH 2.0 authentication with Azure Active Directory.

+# OAuth 2.0 authentication with Azure Active Directory

+The OAuth 2.0 is the industry protocol for authorization. It allows a user to grant limited access to its protected resources. Designed to work specifically with Hypertext Transfer Protocol (HTTP), OAuth separates the role of the client from the resource owner. The client requests access to the resources controlled by the resource owner and hosted by the resource server. The resource server issues access tokens with the approval of the resource owner. The client uses the access tokens to access the protected resources hosted by the resource server.

+OAuth 2.0 is directly related to OpenID Connect (OIDC). Since OIDC is an authentication and authorization layer built on top of OAuth 2.0, it isn't backwards compatible with OAuth 1.0. Azure Active Directory (Azure AD) supports all OAuth 2.0 flows.

+## Use for:

+Rich client and modern app scenarios and RESTful web API access.

+

+## Components of system

+* **User**: Requests a service from the web application (app). The user is typically the resource owner who owns the data and has the power to allow clients to access the data or resource.

+* **Web browser**: The web browser that the user interacts with is the OAuth client.

+* **Web app**: The web app, or resource server, is where the resource or data resides. It trusts the authorization server to securely authenticate and authorize the OAuth client.

+* **Azure AD**: Azure AD is the authorization server, also known as the Identity Provider (IdP). It securely handles anything to do with the user's information, their access, and the trust relationship. It's responsible for issuing the tokens that grant and revoke access to resources.

+## Implement OAuth 2.0 with Azure AD

+* [Integrating applications with Azure AD](../saas-apps/tutorial-list.md)

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

+* [Application types and OAuth2](../develop/v2-app-types.md)

+ Title: OpenID Connect authentication with Azure Active Directory

+description: Architectural guidance on achieving OpenID Connect authentication with Azure Active Directory.

+# OpenID Connect authentication with Azure Active Directory

+OpenID Connect (OIDC) is an authentication protocol based on the OAuth2 protocol (which is used for authorization). OIDC uses the standardized message flows from OAuth2 to provide identity services.

+The design goal of OIDC is "making simple things simple and complicated things possible". OIDC lets developers authenticate their users across websites and apps without having to own and manage password files. This provides the app builder with a secure way to verify the identity of the person currently using the browser or native app that is connected to the application.

+The authentication of the user must take place at an identity provider where the user's session or credentials will be checked. To do that, you need a trusted agent. Native apps usually launch the system browser for that purpose. Embedded views are considered not trusted since there's nothing to prevent the app from snooping on the user password.

+In addition to authentication, the user can be asked for consent. Consent is the user's explicit permission to allow an application to access protected resources. Consent is different from authentication because consent only needs to be provided once for a resource. Consent remains valid until the user or admin manually revokes the grant.

+## Use when

+There is a need for user consent and for web sign in.

+

+## Components of system

+* **User**: Requests a service from the application.

+* **Trusted agent**: The component that the user interacts with. This trusted agent is usually a web browser.

+* **Application**: The application, or Resource Server, is where the resource or data resides. It trusts the identity provider to securely authenticate and authorize the trusted agent.

+* **Azure AD**: The OIDC provider, also known as the identity provider, securely manages anything to do with the user's information, their access, and the trust relationships between parties in a flow. It authenticates the identity of the user, grants and revokes access to resources, and issues tokens.

+## Implement OIDC with Azure AD

+* [Integrating applications with Azure AD](../saas-apps/tutorial-list.md)

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

+* [Microsoft identity platform and OpenID Connect protocol](../develop/v2-protocols-oidc.md)

+* [Web sign-in with OpenID Connect in Azure Active Directory B2C](../../active-directory-b2c/openid-connect.md)

+* [Secure your application by using OpenID Connect and Azure AD](/training/modules/secure-app-with-oidc-and-azure-ad/)

+ Title: Password-based authentication with Azure Active Directory

+description: Architectural guidance on achieving password-based authentication with Azure Active Directory.

+# Password-based authentication with Azure Active Directory

+Password based Single Sign-On (SSO) uses the existing authentication process for the application. When you enable password-based SSO, Azure Active Directory (Azure AD) collects, encrypts, and securely stores user credentials in the directory. Azure AD supplies the username and password to the application when the user attempts to sign in.

+Choose password-based SSO when an application authenticates with a username and password instead of access tokens and headers. Password-based SSO supports any cloud-based application that has an HTML-based sign in page.

+## Use when

+You need to protect with pre-authentication and provide SSO through password vaulting to web apps.

+

+## Components of system

+* **User**: Accesses formed based application from either My Apps or by directly visiting the site.

+* **Web browser**: The component that the user interacts with to access the external URL of the application. The user accesses the form-based application via the MyApps extension.

+* **MyApps extension**: Identifies the configured password-based SSO application and supplies the credentials to the sign in form. The MyApps extension is installed on the web browser.

+* **Azure AD**: Authenticates the user.

+## Implement password-based SSO with Azure AD

+* [What is password based SSO](../manage-apps/what-is-single-sign-on.md)

+* [Configure password based SSO for cloud applications ](../manage-apps/configure-password-single-sign-on-non-gallery-applications.md)

+* [Configure password-based SSO for on-premises applications with Application Proxy](../app-proxy/application-proxy-configure-single-sign-on-password-vaulting.md)

+ Title: Passwordless authentication with Azure Active Directory

+description: Microsoft Azure Active Directory (Azure AD) enables integration with passwordless authentication protocols that include certificate-based authentication, passwordless security key sign-in, Windows Hello for Business, and passwordless sign-in with Microsoft Authenticator.

+# Passwordless authentication with Azure Active Directory

+Microsoft Azure Active Directory (Azure AD) enables integration with the following passwordless authentication protocols.

+- [Overview of Azure AD certificate-based authentication](../authentication/concept-certificate-based-authentication.md): Azure AD certificate-based authentication (CBA) enables customers to allow or require users to authenticate directly with X.509 certificates against their Azure AD for applications and browser sign-in. This feature enables customers to adopt phishing resistant authentication and authenticate with an X.509 certificate against their Public Key Infrastructure (PKI).

+- [Enable passwordless security key sign-in](../authentication/howto-authentication-passwordless-security-key.md): For enterprises that use passwords and have a shared PC environment, security keys provide a seamless way for workers to authenticate without entering a username or password. Security keys provide improved productivity for workers, and have better security. This article explains how to sign in to web-based applications with your Azure AD account using a FIDO2 security key.

+- [Windows Hello for Business Overview](/windows/security/identity-protection/hello-for-business/hello-overview): Windows Hello for Business replaces passwords with strong two-factor authentication on devices. This authentication consists of a type of user credential that is tied to a device and uses a biometric or PIN.

+- [Enable passwordless sign-in with Microsoft Authenticator](../authentication/howto-authentication-passwordless-phone.md): Microsoft Authenticator can be used to sign in to any Azure AD account without using a password. Microsoft Authenticator uses key-based authentication to enable a user credential that is tied to a device, where the device uses a PIN or biometric. Windows Hello for Business uses a similar technology. Microsoft Authenticator can be used on any device platform, including mobile. Microsoft Authenticator can be used with any app or website that integrates with Microsoft Authentication Libraries.

+ Title: Azure Active Directory synchronization protocol overview

+description: Architectural guidance on integrating Azure AD with legacy synchronization protocols

+# Azure Active Directory integrations with synchronization protocols

+Microsoft Azure Active Directory (Azure AD) enables integration with many synchronization protocols. The synchronization integrations enable you to sync user and group data to Azure AD, and then user Azure AD management capabilities. Some sync patterns also enable automated provisioning.

+## Synchronization patterns

+The following table presents Azure AD integration with synchronization patterns and their capabilities. Select the name of a pattern to see

+* A detailed description

+* When to use it

+* Architectural diagram

+* Explanation of system components

+* Links for how to implement the integration

+| Synchronization pattern| Directory synchronization| User provisioning |

+| - | - | - |

+| [Directory synchronization](sync-directory.md)| | |

+| [LDAP Synchronization](sync-ldap.md)| | |

+| [SCIM synchronization](sync-scim.md)| |  |

+ Title: RADIUS authentication with Azure Active Directory

+description: Architectural guidance on achieving RADIUS authentication with Azure Active Directory.

+# RADIUS authentication with Azure Active Directory

+Remote Authentication Dial-In User Service (RADIUS) is a network protocol that secures a network by enabling centralized authentication and authorization of dial-in users. Many applications still rely on the RADIUS protocol to authenticate users.

+Microsoft Windows Server has a role called the Network Policy Server (NPS), which can act as a RADIUS server and support RADIUS authentication.

+Azure Active Directory (Azure AD) enables Multi-factor authentication with RADIUS-based systems. If a customer wants to apply Azure AD Multi-Factor Authentication to any of the previously mentioned RADIUS workloads, they can install the Azure AD Multi-Factor Authentication NPS extension on their Windows NPS server.

+The Windows NPS server authenticates a userΓÇÖs credentials against Active Directory, and then sends the Multi-Factor Authentication request to Azure. The user then receives a challenge on their mobile authenticator. Once successful, the client application is allowed to connect to the service.

+## Use when: 

+You need to add Multi-Factor Authentication to applications like

+* a Virtual Private Network (VPN)

+* WiFi access

+* Remote Desktop Gateway (RDG)

+* Virtual Desktop Infrastructure (VDI)

+* Any others that depend on the RADIUS protocol to authenticate users into the service.

+> [!NOTE]

+> Rather than relying on RADIUS and the Azure AD Multi-Factor Authentication NPS extension to apply Azure AD Multi-Factor Authentication to VPN workloads, we recommend that you upgrade your VPNΓÇÖs to SAML and directly federate your VPN with Azure AD. This gives your VPN the full breadth of Azure AD protection, including Conditional Access, Multi-Factor Authentication, device compliance, and Identity Protection.

+

+## Components of the system 

+* **Client application (VPN client)**: Sends authentication request to the RADIUS client.

+* **RADIUS client**: Converts requests from client application and sends them to RADIUS server that has the NPS extension installed.

+* **RADIUS server**: Connects with Active Directory to perform the primary authentication for the RADIUS request. Upon success, passes the request to Azure AD Multi-Factor Authentication NPS extension.

+* **NPS extension**: Triggers a request to Azure AD Multi-Factor Authentication for a secondary authentication. If successful, NPS extension completes the authentication request by providing the RADIUS server with security tokens that include Multi-Factor Authentication claim, issued by AzureΓÇÖs Security Token Service.

+* **Azure AD Multi-Factor Authentication**: Communicates with Azure AD to retrieve the userΓÇÖs details and performs a secondary authentication using a verification method configured by the user.

+## Implement RADIUS with Azure AD 

+* [Provide Azure AD Multi-Factor Authentication capabilities using NPS](../authentication/howto-mfa-nps-extension.md)

+* [Configure the Azure AD Multi-Factor Authentication NPS extension](../authentication/howto-mfa-nps-extension-advanced.md)

+* [VPN with Azure AD Multi-Factor Authentication using the NPS extension](../authentication/howto-mfa-nps-extension-vpn.md)

+

+ΓÇÄ

+ Title: Remote Desktop Gateway Services with Azure Active Directory

+description: Architectural guidance on achieving Remote Desktop Gateway Services with Azure Active Directory.

+# Remote Desktop Gateway Services

+A standard Remote Desktop Services (RDS) deployment includes various [Remote Desktop role services](/windows-server/remote/remote-desktop-services/desktop-hosting-logical-architecture) running on Windows Server. The RDS deployment with Azure Active Directory (Azure AD) Application Proxy has a permanent outbound connection from the server that is running the connector service. Other deployments leave open inbound connections through a load balancer.

+This authentication pattern allows you to offer more types of applications by publishing on premises applications through Remote Desktop Services. It reduces the attack surface of their deployment by using Azure AD Application Proxy.

+## When to use Remote Desktop Gateway Services

+Use Remote Desktop Gateway Services when you need to provide remote access and protect your Remote Desktop Services deployment with pre-authentication.

+

+## System components

+* **User**: Accesses RDS served by Application Proxy.

+* **Web browser**: The component that the user interacts with to access the external URL of the application.

+* **Azure AD**: Authenticates the user.

+* **Application Proxy service**: Acts as reverse proxy to forward request from the user to RDS. Application Proxy can also enforce any Conditional Access policies.

+* **Remote Desktop Services**: Acts as a platform for individual virtualized applications, providing secure mobile and remote desktop access. It provides end users with the ability to run their applications and desktops from the cloud.

+## Implement Remote Desktop Gateway services with Azure AD

+Explore the following resources to learn more about implementing Remote Desktop Gateway services with Azure AD.

+* [Publish Remote Desktop with Azure Active Directory Application Proxy](../app-proxy/application-proxy-integrate-with-remote-desktop-services.md) describes how Remote Desktop Service and Azure AD Application Proxy work together to improve productivity of workers who are away from the corporate network.

+* The [Tutorial - Add an on-premises app - Application Proxy in Azure Active Directory](../app-proxy/application-proxy-add-on-premises-application.md) helps you to prepare your environment for use with Application Proxy.

+## Next steps

+* [Azure Active Directory authentication and synchronization protocol overview](auth-sync-overview.md) describes integration with authentication and synchronization protocols. Authentication integrations enable you to use Azure AD and its security and management features with little or no changes to your applications that use legacy authentication methods. Synchronization integrations enable you to sync user and group data to Azure AD and then user Azure AD management capabilities. Some sync patterns enable automated provisioning.

+* [Remote Desktop Services architecture](/windows-server/remote/remote-desktop-services/desktop-hosting-logical-architecture) describes configurations for deploying Remote Desktop Services to host Windows apps and desktops for end-users.

+ Title: SAML authentication with Azure Active Directory

+description: Architectural guidance on achieving SAML authentication with Azure Active Directory

+# SAML authentication with Azure Active Directory

+Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization data between an identity provider and a service provider. SAML is an XML-based markup language for security assertions, which are statements that service providers use to make access-control decisions.

+The SAML specification defines three roles:

+* The principal, generally a user

+* The identity provider (IdP)

+* The service provider (SP)

+## Use when

+There's a need to provide a single sign-on (SSO) experience for an enterprise SAML application.

+While one of most important use cases that SAML addresses is SSO, especially by extending SSO across security domains, there are other use cases (called profiles) as well.

+

+## Components of system

+* **User**: Requests a service from the application.

+* **Web browser**: The component that the user interacts with.

+* **Web app**: Enterprise application that supports SAML and uses Azure AD as IdP.

+* **Token**: A SAML assertion (also known as SAML tokens) that carries sets of claims made by the IdP about the principal (user). It contains authentication information, attributes, and authorization decision statements.

+* **Azure AD**: Enterprise cloud IdP that provides SSO and Multi-factor authentication for SAML apps. It synchronizes, maintains, and manages identity information for users while providing authentication services to relying applications.

+## Implement SAML authentication with Azure AD

+* [Tutorials for integrating SaaS applications using Azure Active Directory](../saas-apps/tutorial-list.md)

+* [Configuring SAML based single sign-on for non-gallery applications](../manage-apps/add-application-portal.md)

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

+ Title: SSH authentication with Azure Active Directory

+description: Get architectural guidance on achieving SSH integration with Azure Active Directory.

+# SSH authentication with Azure Active Directory

+Secure Shell (SSH) is a network protocol that provides encryption for operating network services securely over an unsecured network. It's commonly used in systems like Unix and Linux. SSH replaces the Telnet protocol, which doesn't provide encryption in an unsecured network.

+Azure Active Directory (Azure AD) provides a virtual machine (VM) extension for Linux-based systems that run on Azure. It also provides a client extension that integrates with the [Azure CLI](/cli/azure/) and the OpenSSH client.

+You can use SSH authentication with Active Directory when you're:

+* Working with Linux-based VMs that require remote command-line sign-in.

+* Running remote commands in Linux-based systems.

+* Securely transferring files in an unsecured network.

+## Components of the system 

+The following diagram shows the process of SSH authentication with Azure AD:

+

+The system includes the following components:

+* **User**: The user starts the Azure CLI and the SSH client to set up a connection with the Linux VMs. The user also provides credentials for authentication.

+* **Azure CLI**: The user interacts with the Azure CLI to start a session with Azure AD, request short-lived OpenSSH user certificates from Azure AD, and start the SSH session.

+* **Web browser**: The user opens a browser to authenticate the Azure CLI session. The browser communicates with the identity provider (Azure AD) to securely authenticate and authorize the user.

+* **OpenSSH client**: The Azure CLI (or the user) uses the OpenSSH client to start a connection to the Linux VM.

+* **Azure AD**: Azure AD authenticates the identity of the user and issues short-lived OpenSSH user certificates to the Azure CLI client.

+* **Linux VM**: The Linux VM accepts the OpenSSH user certificate and provides a successful connection.

+## Next steps

+* To implement SSH with Azure AD, see [Log in to a Linux VM by using Azure AD credentials](../devices/howto-vm-sign-in-azure-ad-linux.md).

+ Title: Azure Active Directory authentication and synchronization protocol overview

+description: Architectural guidance on integrating Azure AD with legacy authentication protocols and sync patterns

+# Azure Active Directory integrations with authentication protocols

+Microsoft Azure Active Directory (Azure AD) enables integration with many authentication protocols. The authentication integrations enable you to use Azure AD and its security and management features with little or no changes to your applications that use legacy authentication methods.

+## Legacy authentication protocols

+The following table presents authentication Azure AD integration with legacy authentication protocols and their capabilities. Select the name of an authentication protocol to see

+* A detailed description

+* When to use it

+* Architectural diagram

+* Explanation of system components

+* Links for how to implement the integration

+

+| Authentication protocol| Authentication| Authorization| Multi-factor Authentication| Conditional Access |

+| - |- | - | - | - |

+| [Header-based authentication](auth-header-based.md)|| | |  |

+| [LDAP authentication](auth-ldap.md)| | | | |

+| [OAuth 2.0 authentication](auth-oauth2.md)| | | |  |

+| [OIDC authentication](auth-oidc.md)| | | |  |

+| [Password based SSO authentication](auth-password-based-sso.md )| | | |  |

+| [RADIUS authentication]( auth-radius.md)| | | |  |

+| [Remote Desktop Gateway services](auth-remote-desktop-gateway.md)| | | |  |

+| [Secure Shell (SSH)](auth-ssh.md) | | | |  |

+| [SAML authentication](auth-saml.md)| | | |  |

+| [Windows Authentication - Kerberos Constrained Delegation](auth-kcd.md)| | | |  |

+ Title: Automate identity provisioning to applications introduction

+description: Learn to design solutions to automatically provision identities in hybrid environments to provide application access.

+ - it-pro

+ - seodec18

+ - kr2b-contr-experiment

+# Introduction

+The article helps architects, Microsoft partners, and IT professionals with information addressing identity [provisioning](https://www.gartner.com/en/information-technology/glossary/user-provisioning) needs in their organizations, or the organizations they're working with. The content focuses on automating user provisioning for access to applications across all systems in your organization.

+Employees in an organization rely on many applications to perform their work. These applications often require IT admins or application owners to provision accounts before an employee can start accessing them. Organizations also need to manage the lifecycle of these accounts and keep them up to date with the latest information and remove accounts when users don't require them anymore.

+The Azure AD provisioning service automates your identity lifecycle and keeps identities in sync across trusted source systems (like HR systems) and applications that users need access to. It enables you to bring users into Azure AD and provision them into the various applications that they require. The provisioning capabilities are foundational building blocks that enable rich governance and lifecycle workflows. For [hybrid](../hybrid/whatis-hybrid-identity.md) scenarios, the Azure AD agent model connects to on-premises or IaaS systems, and includes components such as the Azure AD provisioning agent, Microsoft Identity Manager (MIM), and Azure AD Connect.

+Thousands of organizations are running Azure AD cloud-hosted services, with its hybrid components delivered on-premises, for provisioning scenarios. Microsoft invests in cloud-hosted and on-premises functionality, including MIM and Azure AD Connect sync, to help organizations provision users in their connected systems and applications. This article focuses on how organizations can use Azure AD to address their provisioning needs and make clear which technology is most right for each scenario.

+

+ Use the following table to find content specific to your scenario. For example, if you want employee and contractor identities management from an HR system to Active Directory Domain Services (AD DS) or Azure Active Directory (Azure AD), follow the link to *Connect identities with your system of record*.

+| What | From | To | Read |

+| - | - | - | - |

+| Employees and contractors| HR systems| AD and Azure AD| [Connect identities with your system of record](automate-provisioning-to-applications-solutions.md) |

+| Existing AD users and groups| AD DS| Azure AD| [Synchronize identities between Azure AD and Active Directory](automate-provisioning-to-applications-solutions.md) |

+| Users, groups| Azure AD| SaaS and on-prem apps| [Automate provisioning to non-Microsoft applications](../governance/entitlement-management-organization.md) |

+| Access rights| Azure AD Identity Governance| SaaS and on-prem apps| [Entitlement management](../governance/entitlement-management-overview.md) |

+| Existing users and groups| AD, SaaS and on-prem apps| Identity governance (so I can review them)| [Azure AD Access reviews](../governance/access-reviews-overview.md) |

+| Non-employee users (with approval)| Other cloud directories| SaaS and on-prem apps| [Connected organizations](../governance/entitlement-management-organization.md) |

+| Users, groups| Azure AD| Managed AD domain| [Azure AD Domain Services](https://azure.microsoft.com/services/active-directory-ds/) |

+## Example topologies

+Organizations vary greatly in the applications and infrastructure that they rely on to run their business. Some organizations have all their infrastructure in the cloud, relying solely on SaaS applications, while others have invested deeply in on-premises infrastructure over several years. The three topologies below depict how Microsoft can meet the needs of a cloud only customer, hybrid customer with basic provisioning requirements, and a hybrid customer with advanced provisioning requirements.

+### Cloud only

+In this example, the organization has a cloud HR system such as Workday or SuccessFactors, uses Microsoft 365 for collaboration, and SaaS apps such as ServiceNow and Zoom.

+

+1. The Azure AD provisioning service imports users from the cloud HR system and creates an account in Azure AD, based on business rules that the organization defines.

+1. The user complete sets up the suitable authentication methods, such as the authenticator app, Fast Identity Online 2 (FIDO2)/Windows Hello for Business (WHfB) keys via [Temporary Access Pass](../authentication/howto-authentication-temporary-access-pass.md) and then signs into Teams. This Temporary Access Pass was automatically generated for the user through Azure AD Life Cycle Workflows.

+1. The Azure AD provisioning service creates accounts in the various applications that the user needs, such as ServiceNow and Zoom. The user is able to request the necessary devices they need and start chatting with their teams.

+### Hybrid-basic

+In this example, the organization has a mix of cloud and on-premises infrastructure. In addition to the systems mentioned above, the organization relies on SaaS applications and on-premises applications that are both AD integrated and non-AD integrated.

+

+1. The Azure AD provisioning service imports the user from Workday and creates an account in AD DS, enabling the user to access AD-integrated applications.

+2. Azure AD Connect Cloud Sync provisions the user into Azure AD, which enables the user to access SharePoint Online and their OneDrive files.

+3. The Azure AD provisioning service detects a new account was created in Azure AD. It then creates accounts in the SaaS and on-premises applications the user needs access to.

+### Hybrid-advanced

+In this example, the organization has users spread across multiple on-premises HR systems and cloud HR. They have large groups and device synchronization requirements.

+

+1. MIM imports user information from each HR stem. MIM determines which users are needed for those employees in different directories. MIM provisions those identities in AD DS.

+2. Azure AD Connect Sync then synchronizes those users and groups to Azure AD and provides users access to their resources.

+## Next steps

+* [Solutions to automate user provisioning to applications](automate-provisioning-to-applications-solutions.md)

+ Title: Solutions to automate identity provisioning to applications

+description: Learn to design solutions to automatically provision identities based on various scenarios.

+ - it-pro

+ - seodec18

+ - kr2b-contr-experiment

+# Solutions

+This article presents solutions that enable you to:

+* Connect identities with your system of record

+* Synchronize identities between Active Directory Domain Services (AD DS) and Azure Active Directory (Azure AD)

+* Automate provisioning of users into non-Microsoft applications

+## Connect identities with your system of record

+In most designs, the human resources (HR) system is the source-of-authority for newly created digital identities. The HR system is often the starting point for many provisioning processes. For example, if a new user joins a company, they have a record in the HR system. That user likely needs an account to access Microsoft 365 services such as Teams and SharePoint, or non-Microsoft applications.

+### Synchronizing identities with cloud HR

+The Azure AD provisioning service enables organizations to [bring identities from popular HR systems](../app-provisioning/what-is-hr-driven-provisioning.md) (examples: [Workday](../saas-apps/workday-inbound-tutorial.md) and [SuccessFactors](../saas-apps/sap-successfactors-inbound-provisioning-cloud-only-tutorial.md)), into Azure AD directly, or into AD DS. This provisioning capability enables new hires to access the resources they need from the first day of work.

+### On-premises HR + joining multiple data sources

+To create a full user profile for an employee identity, organizations often merge information from multiple HR systems, databases, and other user data stores. MIM provides a rich set of [connectors](/microsoft-identity-manager/supported-management-agents) and integration solutions interoperating with heterogeneous platforms both on-premises and in the cloud.

+MIM offers [rule extension](/previous-versions/windows/desktop/forefront-2010/ms698810(v=vs.100)?redirectedfrom=MSDN) and [workflow capabilities](https://microsoft.github.io/MIMWAL/) features for advanced scenarios requiring data transformation and consolidation from multiple sources. These connectors, rule extensions, and workflow capabilities enable organizations to aggregate user data in the MIM metaverse to form a single identity for each user. The identity can be [provisioned into downstream systems](/microsoft-identity-manager/microsoft-identity-manager-2016-supported-platforms) such as AD DS.

+

+## Synchronize identities between Active Directory Domain Services (AD DS) and Azure AD

+As customers move applications to the cloud, and integrate with Azure AD, users often need accounts in Azure AD, and AD to access the applications for their work. Here are five common scenarios in which objects need to be synchronized between AD and Azure AD.

+The scenarios are divided by the direction of synchronization needed, and are listed, one through five. Use the table following the scenarios to determine what technical solution provides the synchronization.

+Use the numbered sections in the next two section to cross reference the following table.

+**Synchronize identities from AD DS into Azure AD**

+1. For users in AD that need access to Office 365 or other applications that are connected to Azure AD, Azure AD Connect cloud sync is the first solution to explore. It provides a lightweight solution to create users in Azure AD, manage password rests, and synchronize groups. Configuration and management are primarily done in the cloud, minimizing your on-premises footprint. It provides high-availability and automatic failover, ensuring password resets and synchronization continue, even if there's an issue with on-premises servers.

+1. For complex, large-scale AD to Azure AD sync needs such as synchronizing groups over 50,000 and device sync, customers can use Azure AD Connect sync to meet their needs.

+**Synchronize identities from Azure AD into AD DS**

+As customers transition identity management to the cloud, more users and groups are created directly in Azure AD. However, they still need a presence on-premises in AD DS to access various resources.

+3. When an external user from a partner organization is created in Azure AD using B2B, MIM can automatically provision them [into AD DS](/microsoft-identity-manager/microsoft-identity-manager-2016-graph-b2b-scenario) and give those guests access to [on-premises Windows-Integrated Authentication or Kerberos-based applications](../external-identities/hybrid-cloud-to-on-premises.md). Alternatively, customers can user [PowerShell scripts](https://github.com/Azure-Samples/B2B-to-AD-Sync) to automate the creation of guest accounts on-premises.

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

+1. When users need access to cloud apps that still rely on legacy access protocols (for example, LDAP and Kerberos/NTLM), [Azure AD Domain Services](https://azure.microsoft.com/services/active-directory-ds/) synchronizes identities between Azure AD and a managed AD domain.

+|No.| What | From | To | Technology |

+| - | - | - | - | - |

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

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

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

+| 4 |Guest accounts| Azure AD| AD DS| [MIM](/microsoft-identity-manager/microsoft-identity-manager-2016-graph-b2b-scenario), [PowerShell](https://github.com/Azure-Samples/B2B-to-AD-Sync)|

+| 5 |Users, groups| Azure AD| Managed AD| [Azure AD Domain Services](https://azure.microsoft.com/services/active-directory-ds/) |

+The table depicts common scenarios and the recommended technology.

+## Automate provisioning users into non-Microsoft applications

+After identities are in Azure AD through HR-provisioning or Azure AD Connect cloud sync / Azure AD Connect sync, the employee can use the identity to access Teams, SharePoint, and Microsoft 365 applications. However, employees still need access to many Microsoft applications to perform their work.

+

+### Automate provisioning to apps and clouds that support the SCIM standard

+Azure AD supports the System for Cross-Domain Identity Management ([SCIM 2.0](https://aka.ms/scimoverview)) standard and integrates with hundreds of popular SaaS applications such as [Dropbox](../saas-apps/dropboxforbusiness-provisioning-tutorial.md) and [Atlassian](../saas-apps/atlassian-cloud-provisioning-tutorial.md) or other clouds such as [Amazon Web Services (AWS)](../saas-apps/aws-single-sign-on-provisioning-tutorial.md), [Google Cloud](../saas-apps/g-suite-provisioning-tutorial.md). Application developers can use the System for Cross-Domain Identity Management (SCIM) user management API to automate provisioning users and groups between Azure AD and your application.

+

+In addition to the pre-integrated gallery applications, Azure AD supports provisioning to SCIM enabled line of business applications, whether hosted [on-premises](../app-provisioning/on-premises-scim-provisioning.md) or in the cloud. The Azure AD provisioning service creates users and groups in these applications, and manages updates such as when a user is promoted or leaves the company).

+[Learn more about provisioning to SCIM enabled applications](../app-provisioning/use-scim-to-provision-users-and-groups.md)

+### Automate provisioning to SQL and LDAP based applications

+ Many applications don't support the SCIM standard, and customers have historically used connectors developed for MIM to connect to them. The Azure AD provisioning service supports reusing connectors developed for MIM and provisioning users into applications that rely on an LDAP user store or a SQL database.

+[Learn more about on-premises application provisioning](../app-provisioning/user-provisioning.md)

+### Use integrations developed by partners

+Many applications may not yet support SCIM or rely on SQL / LDAP databases. Microsoft partners have developed SCIM gateways that allow you to synchronize users between Azure AD and various systems such as mainframes, HR systems, and legacy databases. In the image below, the SCIM Gateways are built and managed by partners.

+

+[Learn more about partner driven integrations](../app-provisioning/partner-driven-integrations.md)

+### Manage local app passwords

+Many applications have a local authentication store and a UI that only checks the userΓÇÖs supplied credentials against that store. As a result, these applications can't support Multi Factor Authentication (MFA) through Azure AD and pose a security risk. Microsoft recommends enabling single sign-on and MFA for all your applications. Based on our studies, your account is more than 99.9% less likely to be compromised if you [use MFA](https://aka.ms/securitysteps). However, in cases where the application canΓÇÖt externalize authentication, customers can use MIM to sync password changes to these applications.

+

+[Learn more about the MIM password change notification service](/microsoft-identity-manager/infrastructure/mim2016-password-management)

+### Define and provision access for a user based on organizational data

+MIM enables you to import organizational data such as job codes and locations. That information can then be used to automatically set up access rights for that user.

+

+### Automate common business workflows

+After users are provisioned into Azure AD, use Lifecycle Workflows (LCW) to automate appropriate actions at key moments in a userΓÇÖs lifecycle such as joiner, mover, and leaver. These custom workflows can be triggered by Azure AD LCW automatically, or on demand to enable or disable accounts, generate Temporary Access Passes, update Teams and/or group membership, send automated emails, and trigger a Logic App. This can help organizations ensure:

+* **Joiner**: When a user joins the organization, they're ready to go on day one. They have the correct access to the information and applications they need. They have the required hardware necessary to do their job.

+* **Leaver**: When users leave the company for various reasons (termination, separation, leave of absence or retirement), have their access revoked in a timely manner.

+[Learn more about Azure AD Lifecycle Workflows](../governance/what-are-lifecycle-workflows.md)

+> [!Note]

+> For scenarios not covered by LCW, customers can leverage the extensibility of [Logic Applications](../..//logic-apps/logic-apps-overview.md).

+### Reconcile changes made directly in the target system

+Organizations often need a complete audit trail of what users have access to applications containing data subject to regulation. To provide an audit trail, any access provided to a user directly must be traceable through the system of record. MIM provides the reconciliation capabilities to detect changes made directly in a target system and roll back the changes. In addition to detecting changes in target applications, MIM can import identities from third party applications to Azure AD. These applications often augment the set of user records that originated in the HR system.

+### Next steps

+1. Automate provisioning with any of your applications that are in the [Azure AD app gallery](../saas-apps/tutorial-list.md), support [SCIM](../app-provisioning/use-scim-to-provision-users-and-groups.md), [SQL](../app-provisioning/on-premises-sql-connector-configure.md), or [LDAP](../app-provisioning/on-premises-ldap-connector-configure.md).

+2. Evaluate [Azure AD Cloud Sync](../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

+ Title: Azure Active Directory B2C deployment plans

+description: Azure Active Directory B2C deployment guide for planning, implementation, and monitoring

+# Azure Active Directory B2C deployment plans

+Azure Active Directory B2C (Azure AD B2C) is an identity and access management solution that can ease integration with your infrastructure. Use the following guidance to help understand requirements and compliance throughout an Azure AD B2C deployment.

+## Plan an Azure AD B2C deployment

+### Requirements

+- Assess the primary reason to turn off systems

+ - See, [What is Azure Active Directory B2C?](../../active-directory-b2c/overview.md)

+- For a new application, plan the design of the Customer Identity Access Management (CIAM) system

+ - See, [Planning and design](../../active-directory-b2c/best-practices.md#planning-and-design)

+- Identify customer locations and create a tenant in the corresponding datacenter

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

+- Confirm your application types and supported technologies:

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

+ - [Develop with open source languages, frameworks, databases, and tools in Azure](https://azure.microsoft.com/free/open-source/search/?OCID=AID2200277_SEM_f63bcafc4d5f1d7378bfaa2085b249f9:G:s&ef_id=f63bcafc4d5f1d7378bfaa2085b249f9:G:s&msclkid=f63bcafc4d5f1d7378bfaa2085b249f9).

+ - For back-end services, use the [client credentials](../develop/msal-authentication-flows.md#client-credentials) flow

+- To migrate from an identity provider (IdP):

+ - [Seamless migration](../../active-directory-b2c/user-migration.md#seamless-migration)

+ - Go to [azure-ad-b2c-user-migration](https://github.com/azure-ad-b2c/user-migration)

+- Select protocols

+ - If you use Kerberos, Microsoft Windows NT LAN Manager (NTLM), and Web Services Federation (WS-Fed), see the video, [Azure Active Directory: Application and identity migration to Azure AD B2C](https://www.bing.com/videos/search?q=application+migration+in+azure+ad+b2c&docid=608034225244808069&mid=E21B87D02347A8260128E21B87D02347A8260128&view=detail&FORM=VIRE)

+After migration, your applications can support modern identity protocols such as OAuth 2.0 and OpenID Connect (OIDC).

+### Stakeholders

+Technology project success depends on managing expectations, outcomes, and responsibilities.

+- Identify the application architect, technical program manager, and owner

+- Create a distribution list (DL) to communicate with the Microsoft account or engineering teams

+ - Ask questions, get answers, and receive notifications

+- Identify a partner or resource outside your organization to support you

+Learn more: [Include the right stakeholders](deployment-plans.md)

+### Communications

+Communicate proactively and regularly with your users about pending and current changes. Inform them about how the experience changes, when it changes, and provide a contact for support.

+### Timelines

+Help set realistic expectations and make contingency plans to meet key milestones:

+- Pilot date

+- Launch date

+- Dates that affect delivery

+- Dependencies

+## Implement an Azure AD B2C deployment

+* **Deploy applications and user identities** - Deploy client application and migrate user identities

+* **Client application onboarding and deliverables** - Onboard the client application and test the solution

+* **Security** - Enhance the identity solution security

+* **Compliance** - Address regulatory requirements

+* **User experience** - Enable a user-friendly service

+### Deploy authentication and authorization

+* Before your applications interact with Azure AD B2C, register them in a tenant you manage

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

+* For authorization, use the Identity Experience Framework (IEF) sample user journeys

+ * See, [Azure Active Directory B2C: Custom CIAM User Journeys](https://github.com/azure-ad-b2c/samples#local-account-policy-enhancements)

+* Use policy-based control for cloud-native environments

+ * Go to openpolicyagent.org to learn about [Open Policy Agent](https://www.openpolicyagent.org/) (OPA)

+Learn more with the Microsoft Identity PDF, [Gaining expertise with Azure AD B2C](https://aka.ms/learnaadb2c), a course for developers.

+### Checklist for personas, permissions, delegation, and calls

+* Identify the personas that access to your application

+* Define how you manage system permissions and entitlements today, and in the future

+* Confirm you have a permission store and if there are permissions to add to the directory

+* Define how you manage delegated administration

+ * For example, your customers' customers management

+* Verify your application calls an API Manager (APIM)

+ * There might be a need to call from the IdP before the application is issued a token

+### Deploy applications and user identities

+Azure AD B2C projects start with one or more client applications.

+* [The new App registrations experience for Azure Active Directory B2C](../../active-directory-b2c/app-registrations-training-guide.md)

+ * Refer to [Azure Active Directory B2C code samples](../../active-directory-b2c/integrate-with-app-code-samples.md) for implementation

+* Set up your user journey based on custom user flows

+ * [Comparing user flows and custom policies](../../active-directory-b2c/user-flow-overview.md#comparing-user-flows-and-custom-policies)

+ * [Add an identity provider to your Azure Active Directory B2C tenant](../../active-directory-b2c/add-identity-provider.md)

+ * [Migrate users to Azure AD B2C](../../active-directory-b2c/user-migration.md)

+ * [Azure Active Directory B2C: Custom CIAM User Journeys](https://github.com/azure-ad-b2c/samples) for advanced scenarios

+### Application deployment checklist

+* Applications included in the CIAM deployment

+* Applications in use

+ * For example, web applications, APIs, single-page apps (SPAs), or native mobile applications

+* Authentication in use:

+ * For example, forms federated with SAML, or federated with OIDC

+ * If OIDC, confirm the response type: code or id_token

+* Determine where front-end and back-end applications are hosted: on-premises, cloud, or hybrid-cloud

+* Confirm the platforms or languages in use:

+ * For example ASP.NET, Java, and Node.js

+ * See, [Quickstart: Set up sign in for an ASP.NET application using Azure AD B2C](../../active-directory-b2c/quickstart-web-app-dotnet.md)

+* Verify where user attributes are stored

+ * For example, Lightweight Directory Access Protocol (LDAP) or databases

+### User identity deployment checklist

+* Confirm the number of users accessing applications

+* Determine the IdP types needed:

+ * For example, Facebook, local account, and Active Directory Federation Services (AD FS)

+ * See, [Active Directory Federation Services](/windows-server/identity/active-directory-federation-services)

+* Outline the claim schema required from your application, Azure AD B2C, and IdPs if applicable

+ * See, [ClaimsSchema](../../active-directory-b2c/claimsschema.md)

+* Determine the information to collect during sign-in and sign-up

+ * [Set up a sign-up and sign-in flow in Azure Active Directory B2C](../../active-directory-b2c/add-sign-up-and-sign-in-policy.md?pivots=b2c-user-flow)

+### Client application onboarding and deliverables

+Use the following checklist for onboarding an application

+|Area|Description|

+|||

+|Application target user group | Select among end customers, business customers, or a digital service. </br>Determine a need for employee sign-in.|

+|Application business value| Understand the business need and/or goal to determine the best Azure AD B2C solution and integration with other client applications.|

+|Your identity groups| Cluster identities into groups with requirements, such as business-to-consumer (B2C), business-to-business (B2B) business-to-employee (B2E), and business-to-machine (B2M) for IoT device sign-in and service accounts.|

+|Identity provider (IdP)| See, [Select an identity provider](../../active-directory-b2c/add-identity-provider.md#select-an-identity-provider). For example, for a customer-to-customer (C2C) mobile app use an easy sign-in process. </br>B2C with digital services has compliance requirements. </br>Consider email sign-in. |

+|Regulatory constraints | Determine a need for remote profiles or privacy policies. |

+|Sign-in and sign-up flow | Confirm email verification or email verification during sign-up. </br>For check-out processes, see [How it works: Azure AD Multi-Factor Authentication](../authentication/concept-mfa-howitworks.md). </br>See the video, [Azure AD: Azure AD B2C user migration using Microsoft Graph API](https://www.youtube.com/watch?v=c8rN1ZaR7wk&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=4). |

+|Application and authentication protocol| Implement client applications such as Web application, single-page application (SPA), or native. </br>Authentication protocols for client application and Azure AD B2C: OAuth, OIDC, and SAML. </br>See the video, [Azure AD: Protecting Web APIs with Azure AD](https://www.youtube.com/watch?v=r2TIVBCm7v4&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=9).|

+| User migration | Confirm if you'll [migrate users to Azure AD B2C](../../active-directory-b2c/user-migration.md): Just-in-time (JIT) migration and bulk import/export. </br>See the video, [Azure Active Directory: Azure AD B2C user migration strategies](https://www.youtube.com/watch?v=lCWR6PGUgz0&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=2).|

+Use the following checklist for delivery.

+|Area| Description|

+|||

+|Protocol information| Gather the base path, policies, and metadata URL of both variants. </br>Specify attributes such as sample sign-in, client application ID, secrets, and redirects.|

+|Application samples | See, [Azure Active Directory B2C code samples](../../active-directory-b2c/integrate-with-app-code-samples.md).|

+|Penetration testing | Inform your operations team about pen tests, then test user flows including the OAuth implementation. </br>See, [Penetration testing](../../security/fundamentals/pen-testing.md) and [Penetration testing rules of engagement](https://www.microsoft.com/msrc/pentest-rules-of-engagement).

+| Unit testing | Unit test and generate tokens. </br>See, [Microsoft identity platform and OAuth 2.0 Resource Owner Password Credentials](../develop/v2-oauth-ropc.md). </br>If you reach the Azure AD B2C token limit, see [Azure AD B2C: File Support Requests](../../active-directory-b2c/find-help-open-support-ticket.md). </br>Reuse tokens to reduce investigation on your infrastructure. </br>[Set up a resource owner password credentials flow in Azure Active Directory B2C](../../active-directory-b2c/add-ropc-policy.md?pivots=b2c-user-flow&tabs=app-reg-ga).|

+| Load testing | Learn about [Azure AD B2C service limits and restrictions](../../active-directory-b2c/service-limits.md). </br>Calculate the expected authentications and user sign-ins per month. </br>Assess high load traffic durations and business reasons: holiday, migration, and event. </br>Determine expected peak rates for sign-up, traffic, and geographic distribution, for example per second.

+### Security

+Use the following checklist to enhance application security.

+* Authentication method, such as multi-factor authentication (MFA):

+ * MFA is recommended for users that trigger high-value transactions or other risk events. For example, banking, finance, and check-out processes.

+ * See, [What authentication and verification methods are available in Azure AD?](../authentication/concept-authentication-methods.md)

+* Confirm use of anti-bot mechanisms

+* Assess the risk of attempts to create a fraudulent account or sign-in

+ * See, [Tutorial: Configure Microsoft Dynamics 365 Fraud Protection with Azure Active Directory B2C](../../active-directory-b2c/partner-dynamics-365-fraud-protection.md)

+* Confirm needed conditional postures as part of sign-in or sign-up

+#### Conditional Access and identity protection

+* The modern security perimeter now extends beyond an organization's network. The perimeter includes user and device identity.

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

+* Enhance the security of Azure AD B2C with Azure AD identity protection

+ * See, [Identity Protection and Conditional Access in Azure AD B2C](../../active-directory-b2c/conditional-access-identity-protection-overview.md)

+### Compliance

+To help comply with regulatory requirements and enhance back-end system security you can use virtual networks (VNets), IP restrictions, Web Application Firewall (WAF), etc. Consider the following requirements:

+* Your regulatory compliance requirements

+ * For example, Payment Card Industry Data Security Standard (PCI-DSS)

+ * Go to pcisecuritystandards.org to learn more about the [PCI Security Standards Council](https://www.pcisecuritystandards.org/)

+* Data storage into a separate database store

+ * Determine if this information can't be written into the directory

+### User experience

+Use the following checklist to help define user experience requirements.

+* Identify integrations to extend CIAM capabilities and build seamless end-user experiences

+ * [Azure Active Directory B2C ISV partners](../../active-directory-b2c/partner-gallery.md)

+* Use screenshots and user stories to show the application end-user experience

+ * For example, screenshots of sign-in, sign-up, sign-up/sign-in (SUSI), profile edit, and password reset

+* Look for hints passed through by using queryString parameters in your CIAM solution

+* For high user-experience customization, consider a using front-end developer

+* In Azure AD B2C, you can customize HTML and CSS

+ * See, [Guidelines for using JavaScript](../../active-directory-b2c/javascript-and-page-layout.md?pivots=b2c-custom-policy#guidelines-for-using-javascript)

+* Implement an embedded experience by using iframe support:

+ * See, [Embedded sign-up or sign-in experience](../../active-directory-b2c/embedded-login.md?pivots=b2c-custom-policy)

+ * For a single-page application, use a second sign-in HTML page that loads into the `<iframe>` element

+## Monitoring auditing, and logging

+Use the following checklist for monitoring, auditing, and logging.

+* Monitoring

+ * [Monitor Azure AD B2C with Azure Monitor](../../active-directory-b2c/azure-monitor.md)

+ * See the video [Azure Active Directory: Monitoring and reporting Azure AD B2C using Azure Monitor](https://www.youtube.com/watch?v=Mu9GQy-CbXI&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=1)

+* Auditing and logging

+ * [Accessing Azure AD B2C audit logs](../../active-directory-b2c/view-audit-logs.md)

+## Resources

+- [Register a Microsoft Graph application](../../active-directory-b2c/microsoft-graph-get-started.md)

+- [Manage Azure AD B2C with Microsoft Graph](../../active-directory-b2c/microsoft-graph-operations.md)

+- [Deploy custom policies with Azure Pipelines](../../active-directory-b2c/deploy-custom-policies-devops.md)

+- [Manage Azure AD B2C custom policies with Azure PowerShell](../../active-directory-b2c/manage-custom-policies-powershell.md)

+## Next steps

+[Recommendations and best practices for Azure Active Directory B2C](../../active-directory-b2c/best-practices.md)

+ Title: Application requirements for the backup authentication system

+description: How to configure your application to allow for backup authentication system support.

+# Application requirements for the backup authentication system

+The Azure AD backup authentication system provides resilience to applications that use supported protocols and flows. For more information about the backup authentication system, see the article [Azure AD's backup authentication system](backup-authentication-system.md).

+## Application requirements for protection

+Applications must communicate with a supported hostname for the given Azure environment and use protocols currently supported by the backup authentication system. Use of authentication libraries, such as the [Microsoft Authentication Library (MSAL)](../develop/msal-overview.md), ensures that you're using authentication protocols supported by the backup authentication system.

+### Hostnames supported by the backup authentication system

+

+| Azure environment | Supported hostname |

+| | |

+| Azure Commercial | login.microsoftonline.com |

+| Azure Government | login.microsoftonline.us |

+### Authentication protocols supported by the backup authentication system

+#### OAuth 2.0 and OpenID Connect (OIDC)

+##### Common guidance

+All applications using the OAuth 2.0 and/or OIDC protocols should adhere to the following practices to ensure resilience:

+- Your application uses MSAL or strictly adheres to the OpenID Connect & OAuth2 specifications. Microsoft recommends using MSAL libraries appropriate to your platform and use case. Using these libraries ensures the use of APIs and call patterns are supportable by the backup authentication system.

+- Your application uses a fixed set of scopes instead of [dynamic consent](../develop/scopes-oidc.md) when acquiring access tokens.

+- Your application doesn't use the [Resource Owner Password Credentials Grant](../develop/v2-oauth-ropc.md). **This grant type won't be supported** by the backup authentication system for any client type. Microsoft strongly recommends switching to alternative grant flows for better security and resilience.

+- Your application doesn't rely upon the [UserInfo endpoint](../develop/userinfo.md). Switching to using an ID token instead reduces latency by eliminating up to two network requests, and use existing support for ID token resilience within the backup authentication system.

+##### Native applications

+Native applications are public client applications that run directly on desktop or mobile devices and not in a web browser. They're registered as public clients in their application registration on the Microsoft Entra or Azure portal.

+Native applications are protected by the backup authentication system when all the following are true:

+1. Your application persists the token cache for at least three days. Applications should use the deviceΓÇÖs token cache location or the [token cache serialization API](../develop/msal-net-token-cache-serialization.md) to persist the token cache even when the user closes the application.

+1. Your application makes use of the MSAL [AcquireTokenSilent API](../develop/msal-net-acquire-token-silently.md) to retrieve tokens using cached Refresh Tokens. The use of the [AcquireTokenInteractive API](../develop/scenario-desktop-acquire-token-interactive.md) may fail to acquire a token from the backup authentication system if user interaction is required.

+The backup authentication system doesn't currently support the [device authorization grant](../develop/v2-oauth2-device-code.md).

+##### Single-page web applications

+Single-page web applications (SPAs) have limited support in the backup authentication system. SPAs that use the [implicit grant flow](../develop/v2-oauth2-implicit-grant-flow.md) and request only OpenID Connect ID tokens are protected. Only apps that either use MSAL.js 1.x or implement the implicit grant flow directly can use this protection, as MSAL.js 2.x doesn't support the implicit flow.

+The backup authentication system doesn't currently support the [authorization code flow with Proof Key for Code Exchange](../develop/v2-oauth2-auth-code-flow.md).

+##### Web applications & services

+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/active-directory-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.

+#### SAML 2.0 single sign-on (SSO)

+The backup authentication system partially supports the SAML 2.0 SSO protocol. Flows that use the SAML 2.0 Identity Provider (IdP) Initiated flow are protected by the backup authentication system. Applications that use the [Service Provider (SP) Initiated flow](../develop/single-sign-on-saml-protocol.md), aren't currently protected by the backup authentication system.

+### Workload identity authentication protocols supported by the backup authentication system

+#### OAuth 2.0

+##### Managed identity

+Applications that use Managed Identities to acquire Azure Active Directory access tokens are protected. Microsoft recommends the use of user-assigned managed identities in most scenarios, however this protection applies to both [user and system-assigned managed identities](../managed-identities-azure-resources/overview.md).

+##### Service principal

+The backup authentication system doesn't currently support service principal-based Workload identity authentication using the [client credentials grant flow](../develop/v2-oauth2-client-creds-grant-flow.md). Microsoft recommends using the version of MSAL appropriate to your platform so your application is protected by the backup authentication system when the protection becomes available.

+## Next steps

+- [Azure AD's backup authentication system](backup-authentication-system.md)

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

+- [Introduction to the backup authentication system](https://azure.microsoft.com/blog/advancing-service-resilience-in-azure-active-directory-with-its-backup-authentication-service/)

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

+ Title: Azure AD's backup authentication system

+description: Increasing the resilience of the authentication plane with the backup authentication system.

+# Azure AD's backup authentication system

+Users and organizations around the world depend on the high availability of Azure Active Directory (Azure AD) authentication of users and services 24 hours a day, seven days a week. We promise a 99.99% Service Level availability for authentication, and we continuously seek to improve it by enhancing the resilience of our authentication service. To further improve resilience during outages, we implemented a backup system in 2021.

+The Azure AD backup authentication system is made up of multiple backup services that work together to increase authentication resilience if there's an outage. This system transparently and automatically handles authentications for supported applications and services if the primary Azure AD service is unavailable or degraded. It adds an extra layer of resilience on top of the multiple levels of existing redundancy. This resilience is described in the blog post [Advancing service resilience in Azure Active Directory with its backup authentication service](https://azure.microsoft.com/blog/advancing-service-resilience-in-azure-active-directory-with-its-backup-authentication-service/). This system syncs authentication metadata when the system is healthy and uses that to enable users to continue to access applications during outages of the primary service while still enforcing policy controls.

+During an outage of the primary service, users are able to continue working with their applications, as long as they accessed them in the last three days from the same device, and no blocking policies exist that would curtail their access:

+In addition to Microsoft applications, we support:

+- Native email clients on iOS and Android.

+- SaaS applications available in the app gallery, like ADP, Atlassian, AWS, GoToMeeting, Kronos, Marketo, SAP, Trello, Workday, and more.

+- Selected line of business applications, based on their authentication patterns.

+Service to service authentication that relies on Azure AD managed identities or are built on Azure services, like virtual machines, cloud storage, Azure AI services, and App Services, receives increased resilience from the back up authentication system.

+Microsoft is continuously expanding the number of supported scenarios.

+## Which non-Microsoft workloads are supported?

+The backup authentication system automatically provides incremental resilience to tens of thousands of supported non-Microsoft applications based on their authentication patterns. See the appendix for a list of the most [common non-Microsoft applications and their coverage status](#appendix). For an in depth explanation of which authentication patterns are supported, see the article [Understanding Application Support for the backup authentication system](backup-authentication-system-apps.md) article.

+- Native applications using the OAuth 2.0 protocol to access resource applications, such as popular non-Microsoft e-mail and IM clients like: Apple Mail, Aqua Mail, Gmail, Samsung Email, and Spark.

+- Line of business web applications configured to authenticate with OpenID Connect using only ID tokens.

+- Web applications authenticating with the SAML protocol, when configured for IDP-Initiated Single Sign On (SSO) like: ADP, Atlassian Cloud, AWS, GoToMeeting, Kronos, Marketo, Palo Alto Networks, SAP Cloud Identity Trello, Workday, and Zscaler.

+### Non-Microsoft application types that aren't protected

+The following auth patterns aren't currently supported:

+- Web applications that authenticate using Open ID Connect and request access tokens

+- Web applications that use the SAML protocol for authentication, when configured as SP-Initiated SSO

+## What makes a user supportable by the backup authentication system?

+During an outage, a user can authenticate using the backup authentication system if the following conditions are met:

+1. The user has successfully authenticated using the same app and device in the last three days.

+1. The user isn't required to authenticate interactively

+1. The user is accessing a resource as a member of their home tenant, rather than exercising a B2B or B2C scenario.

+1. The user isn't subject to Conditional Access policies that limit the backup authentication system, like disabling [resilience defaults](../conditional-access/resilience-defaults.md).

+1. The user hasn't been subject to a revocation event, such as a credential change since their last successful authentication.

+### How does interactive authentication and user activity affect resilience?

+The backup authentication system relies on metadata from a prior authentication to reauthenticate the user during an outage. For this reason, a user must have authenticated in the last three days using the same app on the same device for the backup service to be effective. Users who are inactive or haven't yet authenticated to a given app can't use the backup authentication system for that application.

+### How do Conditional Access policies affect resilience?

+Certain policies can't be evaluated in real-time by the backup authentication system and must rely on prior evaluations of these policies. Under outage conditions, the service uses a prior evaluation by default to maximize resilience. For example, access that is conditioned on a user having a particular role (like Application Administrator) continues during an outage based on the role the user had during that latest authentication. If the outage-only use of a previous evaluation needs to be restricted, tenant administrators can choose a strict evaluation of all Conditional Access policies, even under outage conditions, by disabling resilience defaults. This decision should be taken with care because disabling [resilience defaults](../conditional-access/resilience-defaults.md) for a given policy disables those users from using backup authentication. Resilience defaults must be re-enabled before an outage occurs for the backup system to provide resilience.

+Certain other types of policies don't support use of the backup authentication system. Use of the following policies reduce resilience:

+- Use of the [sign-in frequency control](../conditional-access/concept-conditional-access-session.md#sign-in-frequency) as part of a Conditional Access policy.

+- Use of the [authentication methods policy](../conditional-access/concept-conditional-access-grant.md#require-authentication-strength).

+- Use of [classic Conditional Access policies](../conditional-access/policy-migration.md).

+## Workload identity resilience in the backup authentication system

+In addition to user authentication, the backup authentication system provides resilience for [managed identities](../managed-identities-azure-resources/overview.md) and other key Azure infrastructure by offering a regionally isolated authentication service that is redundantly layered with the primary authentication service. This system enables the infrastructure authentication within an Azure region to be resilient to issues that may occur in another region or within the larger Azure Active Directory service. This system complements AzureΓÇÖs cross-region architecture. Building your own applications using MI and following AzureΓÇÖs [best practices for resilience and availability]() ensures your applications are highly resilient. In addition to MI, this regionally resilient backup system protects key Azure infrastructure and services that keep the cloud functional.

+### Summary of infrastructure authentication support

+- Your services built-on the Azure Infrastructure using managed identities are protected by the backup authentication system.

+- Azure services authenticating with each other are protected by the backup authentication system.

+- Your services built on or off Azure when the identities are registered as Service Principals and not ΓÇ£managed identitiesΓÇ¥ **aren't protected** by the backup authentication system.

+## Cloud environments that support the backup authentication system

+The backup authentication system is supported in all cloud environments except Azure China 21vianet. The types of identities supported vary by cloud, as described in the following table.

+| Azure environment | Identities protected |

+| | |

+| Azure Commercial | Users, managed identities |

+| Azure Government | Users, managed identities |

+| Azure Government Secret | managed identities |

+| Azure Government Top Secret | managed identities |

+| Azure China | Not available |

+## Appendix

+### Popular non-Microsoft native client apps and app gallery applications

+| App Name | Protected | Why Not protected? |

+| | | |

+| ABBYY FlexiCapture 12 | No | SAML SP-initiated |

+| Adobe Experience Manager | No | SAML SP-initiated |

+| Adobe Identity Management (OIDC) | No | OIDC with Access Token |

+| ADP | Yes | Protected |

+| Apple Business Manager | No | SAML SP-initiated |

+| Apple Internet Accounts | Yes | Protected |

+| Apple School Manager | No | OIDC with Access Token |

+| Aqua Mail | Yes | Protected |

+| Atlassian Cloud | Yes \* | Protected |

+| Blackboard Learn | No | SAML SP-initiated |

+| Box | No | SAML SP-initiated |

+| Brightspace by Desire2Leam | No | SAML SP-initiated |

+| Canvas | No | SAML SP-initiated |

+| Ceridian Dayforce HCM | No | SAML SP-initiated |

+| Cisco AnyConnect | No | SAML SP-initiated |

+| Cisco Webex | No | SAML SP-initiated |

+| Citrix ADC SAML Connector forAzure AD | No | SAML SP-initiated |

+| Clever | No | SAML SP-initiated |

+| Cloud Drive Mapper | Yes | Protected |

+| Cornerstone Single Sign-on | No | SAML SP-initiated |

+| Docusign | No | SAML SP-initiated |

+| Druva | No | SAML SP-initiated |

+| F5 BIG-IP ARM Azure AD integration | No | SAML SP-initiated |

+| FortiGate SSL VPN | No | SAML SP-initiated |

+| Freshworks | No | SAML SP-initiated |

+| Gmail | Yes | Protected |

+| Google Cloud / G Suite Connector by Microsoft | No | SAML SP-initiated |

+| HubSpot Sales | No | SAML SP-initiated |

+| Kronos | Yes \* | Protected |

+| Madrasati App | No | SAML SP-initiated |

+| OpenAthens | No | SAML SP-initiated |

+| Oracle Fusion ERP | No | SAML SP-initiated |

+| Palo Alto Networks - GlobalProtect | No | SAML SP-initiated |

+| Polycom - Skype for Business Certified Phone | Yes | Protected |

+| Salesforce | No | SAML SP-initiated |

+| Samsung Email | Yes | Protected |

+| SAP Cloud Platform Identity Authentication | No | SAML SP-initiated |

+| SAP Concur | Yes \* | SAML SP-initiated |

+| SAP Concur Travel and Expense | Yes \* | Protected |

+| SAP Fiori | No | SAML SP-initiated |

+| SAP NetWeaver | No | SAML SP-initiated |

+| SAP SuccessFactors | No | SAML SP-initiated |

+| Service Now | No | SAML SP-initiated |

+| Slack | No | SAML SP-initiated |

+| Smartsheet | No | SAML SP-initiated |

+| Spark | Yes | Protected |

+| UKG pro | Yes \* | Protected |

+| VMware Boxer | Yes | Protected |

+| walkMe | No | SAML SP-initiated |

+| Workday | No | SAML SP-initiated |

+| Workplace from Facebook | No | SAML SP-initiated |

+| Zoom | No | SAML SP-initiated |

+| Zscaler | Yes \* | Protected |

+| Zscaler Private Access (ZPA) | No | SAML SP-initiated |

+| Zscaler ZSCloud | No | SAML SP-initiated |

+> [!NOTE]

+> \* Apps configured to authenticate with the SAML protocol are protected when using IDP-Initiated authentication. Service Provider (SP) initiated SAML configurations aren't supported

+### Azure resources and their status

+| resource | Azure resource name | Status |

+| | | |

+| microsoft.apimanagement | API Management service in Azure Government and China regions | Protected |

+| microsoft.app | App Service | Protected |

+| microsoft.appconfiguration | Azure App Configuration | Protected |

+| microsoft.appplatform | Azure App Service | Protected |

+| microsoft.authorization | Azure Active Directory | Protected |

+| microsoft.automation | Automation Service | Protected |

+| microsoft.avs | Azure VMware Solution | Protected |

+| microsoft.batch | Azure Batch | Protected |

+| microsoft.cache | Azure Cache for Redis | Protected |

+| microsoft.cdn | Azure Content Delivery Network (CDN) | Not protected |

+| microsoft.chaos | Azure Chaos Engineering | Protected |

+| microsoft.cognitiveservices | Azure AI services APIs and Containers | Protected |

+| microsoft.communication | Azure Communication Services | Not protected |

+| microsoft.compute | Azure Virtual Machines | Protected |

+| microsoft.containerinstance | Azure Container Instances | Protected |

+| microsoft.containerregistry | Azure Container Registry | Protected |

+| microsoft.containerservice | Azure Container Service (deprecated) | Protected |

+| microsoft.dashboard | Azure Dashboards | Protected |

+| microsoft.databasewatcher | Azure SQL Database Automatic Tuning | Protected |

+| microsoft.databox | Azure Data Box | Protected |

+| microsoft.databricks | Azure Databricks | Not protected |

+| microsoft.datacollaboration | Azure Data Share | Protected |

+| microsoft.datadog | Datadog | Protected |

+| microsoft.datafactory | Azure Data Factory | Protected |

+| microsoft.datalakestore | Azure Data Lake Storage Gen1 and Gen2 | Not protected |

+| microsoft.dataprotection | Microsoft Cloud App Security Data Protection API | Protected |

+| microsoft.dbformysql | Azure Database for MySQL | Protected |

+| microsoft.dbforpostgresql | Azure Database for PostgreSQL | Protected |

+| microsoft.delegatednetwork | Delegated Network Management service | Protected |

+| microsoft.devcenter | Microsoft Store for Business and Education | Protected |

+| microsoft.devices | Azure IoT Hub and IoT Central | Not protected |

+| microsoft.deviceupdate | Windows 10 IoT Core Services Device Update | Protected |

+| microsoft.devtestlab | Azure DevTest Labs | Protected |

+| microsoft.digitaltwins | Azure Digital Twins | Protected |

+| microsoft.documentdb | Azure Cosmos DB | Protected |

+| microsoft.eventgrid | Azure Event Grid | Protected |

+| microsoft.eventhub | Azure Event Hubs | Protected |

+| microsoft.healthbot | Health Bot Service | Protected |

+| microsoft.healthcareapis | FHIR API for Azure API for FHIR and Microsoft Cloud for Healthcare solutions | Protected |

+| microsoft.hybridcontainerservice | Azure Arc enabled Kubernetes | Protected |

+| microsoft.hybridnetwork | Azure Virtual WAN | Protected |

+| microsoft.insights | Application Insights and Log Analytics | Not protected |

+| microsoft.iotcentral | IoT Central | Protected |

+| microsoft.kubernetes | Azure Kubernetes Service (AKS) | Protected |

+| microsoft.kusto | Azure Data Explorer (Kusto) | Protected |

+| microsoft.loadtestservice | Visual Studio Load Testing Service | Protected |

+| microsoft.logic | Azure Logic Apps | Protected |

+| microsoft.machinelearningservices | Machine Learning Services on Azure | Protected |

+| microsoft.managedidentity | Managed identities for Microsoft Resources | Protected |

+| microsoft.maps | Azure Maps | Protected |

+| microsoft.media | Azure Media Services | Protected |

+| microsoft.migrate | Azure Migrate | Protected |

+| microsoft.mixedreality | Mixed Reality services including Remote Rendering, Spatial Anchors, and Object Anchors | Not protected |

+| microsoft.netapp | Azure NetApp Files | Protected |

+| microsoft.network | Azure Virtual Network | Protected |

+| microsoft.openenergyplatform | Open Energy Platform (OEP) on Azure | Protected |

+| microsoft.operationalinsights | Azure Monitor Logs | Protected |

+| microsoft.powerplatform | Microsoft Power Platform | Protected |

+| microsoft.purview | Azure Purview (formerly Azure Data Catalog) | Protected |

+| microsoft.quantum | Microsoft Quantum Development Kit | Protected |

+| microsoft.recommendationsservice | Azure AI services Recommendations API | Protected |

+| microsoft.recoveryservices | Azure Site Recovery | Protected |

+| microsoft.resourceconnector | Azure Resource Connector | Protected |

+| microsoft.scom | System Center Operations Manager (SCOM) | Protected |

+| microsoft.search | Azure Cognitive Search | Not protected |

+| microsoft.security | Azure Security Center | Not protected |

+| microsoft.securitydetonation | Microsoft Defender for Endpoint Detonation Service | Protected |

+| microsoft.servicebus | Service Bus messaging service and Event Grid Domain Topics | Protected |

+| microsoft.servicefabric | Azure Service Fabric | Protected |

+| microsoft.signalrservice | Azure SignalR Service | Protected |

+| microsoft.solutions | Azure Solutions | Protected |

+| microsoft.sql | SQL Server on Virtual Machines and SQL Managed Instance on Azure | Protected |

+| microsoft.storage | Azure Storage | Protected |

+| microsoft.storagecache | Azure Storage Cache | Protected |

+| microsoft.storagesync | Azure File Sync | Protected |

+| microsoft.streamanalytics | Azure Stream Analytics | Not protected |

+| microsoft.synapse | Synapse Analytics (formerly SQL DW) and Synapse Studio (formerly SQL DW Studio) | Protected |

+| microsoft.usagebilling | Azure Usage and Billing Portal | Not protected |

+| microsoft.videoindexer | Video Indexer | Protected |

+| microsoft.voiceservices | Azure Communication Services - Voice APIs | Not protected |

+| microsoft.web | Web Apps | Protected |

+## Next steps

+- [Application requirements for the backup authentication system](backup-authentication-system-apps.md)

+- [Introduction to the backup authentication system](https://azure.microsoft.com/blog/advancing-service-resilience-in-azure-active-directory-with-its-backup-authentication-service/)

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

+- [Azure Active Directory SLA performance reporting](../reports-monitoring/reference-azure-ad-sla-performance.md)

+ Title: Azure Active Directory deployment plans

+description: Guidance on Azure Active Directory deployment, such as authentication, devices, hybrid scenarios, governance, and more.

+# Azure Active Directory deployment plans

+Use the following guidance to help deploy Azure Active Directory (Azure AD). Learn about business value, planning considerations, and operational procedures. You can use a browser Print to PDF function to create offline documentation.

+## Your stakeholders

+When beginning your deployment plans, include your key stakeholders. Identify and document stakeholders, roles, responsibilities. Titles and roles can differ from one organization to another, however the ownership areas are similar.

+|Role |Responsibility |

+|-|-|

+|Sponsor|An enterprise senior leader with authority to approve and/or assign budget and resources. The sponsor is the connection between managers and the executive team.|

+|End user|The people for whom the service is implemented. Users can participate in a pilot program.|

+|IT Support Manager|Provides input on the supportability of proposed changesΓÇ»|

+|Identity architect or Azure Global Administrator|Defines how the change aligns with identity management infrastructure|

+|Application business owner |Owns the affected application(s), which might include access management. Provides input on the user experience.

+|Security owner|Confirms the change plan meets security requirements|

+|Compliance manager|Ensures compliance with corporate, industry, or governmental requirements|

+### RACI

+RACI is an acronym derived from four key responsibilities:

+* **Responsible**

+* **Accountable**

+* **Consulted**

+* **Informed**

+Use these terms to clarify and define roles and responsibilities in your project, and for other cross-functional or departmental projects and processes.

+## Authentication

+Use the following list to plan for authentication deployment.

+* **Azure AD multi-factor authentication (MFA)** - Using admin-approved authentication methods, Azure AD MFA helps safeguard access to your data and applications while meeting the demand for a simple sign-in process:

+ * See the video, [How to configure and enforce multi-factor authentication in your tenant](https://www.youtube.com/watch?v=qNndxl7gqVM)

+ * See, [Plan an Azure Active Directory Multi-Factor Authentication deployment](../authentication/howto-mfa-getstarted.md)

+* **Conditional Access** - Implement automated access-control decisions for users to access cloud apps, based on conditions:

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

+ * See, [Plan a Conditional Access deployment](../conditional-access/plan-conditional-access.md)

+* **Azure AD self-service password reset (SSPR)** - Help users reset a password without administrator intervention:

+ * See, [Passwordless authentication options for Azure AD](../authentication/concept-authentication-passwordless.md)

+ * See, [Plan an Azure Active Directory self-service password reset deployment](../authentication/howto-sspr-deployment.md)

+* **Passwordless authentication** - Implement passwordless authentication using the Microsoft Authenticator app or FIDO2 Security keys:

+ * See, [Enable passwordless sign-in with Microsoft Authenticator](../authentication/howto-authentication-passwordless-phone.md)

+ * See, [Plan a passwordless authentication deployment in Azure Active Directory](../authentication/howto-authentication-passwordless-deployment.md)

+## Applications and devices

+Use the following list to help deploy applications and devices.

+* **Single sign-on (SSO)** - Enable user access to apps and resources while signing in once, without being required to enter credentials again:

+ * See, [What is SSO in Azure AD?](../manage-apps/what-is-single-sign-on.md)

+ * See, [Plan a SSO deployment](../manage-apps/plan-sso-deployment.md)

+* **My Apps portal** - A web-based portal to discover and access applications. Enable user productivity with self-service, for instance requesting access to groups, or managing access to resources on behalf of others.

+ * See, [My Apps portal overview](../manage-apps/myapps-overview.md)

+* **Devices** - Evaluate device integration methods with Azure AD, choose the implementation plan, and more.

+ * See, [Plan your Azure Active Directory device deployment](../devices/plan-device-deployment.md)

+## Hybrid scenarios

+The following list describes features and services for productivity gains in hybrid scenarios.

+* **Active Directory Federation Services (AD FS)** - Migrate user authentication from federation to cloud with pass-through authentication or password hash sync:

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

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

+* **Azure AD Application Proxy** - Enable employees to be productive at any place or time, and from a device. Learn about software as a service (SaaS) apps in the cloud and corporate apps on-premises. Azure AD Application Proxy enables access without virtual private networks (VPNs) or demilitarized zones (DMZs):

+ * See, [Remote access to on-premises applications through Azure AD Application Proxy](../app-proxy/application-proxy.md)

+ * See, [Plan an Azure AD Application Proxy deployment](../app-proxy/application-proxy-deployment-plan.md)

+* **Seamless single sign-on (Seamless SSO)** - Use Seamless SSO for user sign-in, on corporate devices connected to a corporate network. Users don't need to enter passwords to sign in to Azure AD, and usually don't need to enter usernames. Authorized users access cloud-based apps without extra on-premises components:

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

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

+## Users

+* **User identities** - Learn about automation to create, maintain, and remove user identities in cloud apps, such as Dropbox, Salesforce, ServiceNow, and more.

+ * See, [Plan an automatic user provisioning deployment in Azure Active Directory](../app-provisioning/plan-auto-user-provisioning.md)

+* **Identity governance** - Create identity governance and enhance business processes that rely on identity data. With HR products, such as Workday or Successfactors, manage employee and contingent-staff identity lifecycle with rules. These rules map Joiner-Mover-Leaver processes, such as New Hire, Terminate, Transfer, to IT actions such as Create, Enable, Disable.

+ * See, [Plan cloud HR application to Azure Active Directory user provisioning](../app-provisioning/plan-cloud-hr-provision.md)

+* **Azure AD B2B collaboration** - Improve external-user collaboration with secure access to applications:

+ * See, [B2B collaboration overview](../external-identities/what-is-b2b.md)

+ * See, [Plan an Azure Active Directory B2B collaboration deployment](secure-external-access-resources.md)

+## Identity Governance and reporting

+Use the following list to learn about identity governance and reporting. Items in the list refer to Microsoft Entra.

+Learn more: [Secure access for a connected worldΓÇömeet Microsoft Entra](https://www.microsoft.com/en-us/security/blog/?p=114039)

+* **Privileged identity management (PIM)** - Manage privileged administrative roles across Azure AD, Azure resources, and other Microsoft Online Services. Use it for just-in-time access, request approval workflows, and fully integrated access reviews to help prevent malicious activities:

+ * See, [Start using Privileged Identity Management](../privileged-identity-management/pim-getting-started.md)

+ * See, [Plan a Privileged Identity Management deployment](../privileged-identity-management/pim-deployment-plan.md)

+* **Reporting and monitoring** - Your Azure AD reporting and monitoring solution design has dependencies and constraints: legal, security, operations, environment, and processes.

+ * See, [Azure Active Directory reporting and monitoring deployment dependencies](../reports-monitoring/plan-monitoring-and-reporting.md)

+* **Access reviews** - Understand and manage access to resources:

+ * See, [What are access reviews?](../governance/access-reviews-overview.md)

+ * See, [Plan a Microsoft Entra access reviews deployment](../governance/deploy-access-reviews.md)

+* **Identity governance** - Meet your compliance and risk management objectives for access to critical applications. Learn how to enforce accurate access.

+ * See, [Govern access for applications in your environment](../governance/identity-governance-applications-prepare.md)

+## Best practices for a pilot

+Use pilots to test with a small group, before making a change for larger groups, or everyone. Ensure each use case in your organization is tested.

+### Pilot: Phase 1

+In your first phase, target IT, usability, and other users who can test and provide feedback. Use this feedback to gain insights on potential issues for support staff, and to develop communications and instructions you send to all users.

+### Pilot: Phase 2

+Widen the pilot to larger groups of users by using dynamic membership, or by manually adding users to the targeted group(s).

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

+ Title: Governing Azure Active Directory service accounts

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

+# Governing Azure Active Directory service accounts

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

+Learn more:

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

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

+> [!NOTE]

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

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

+## Plan your service account

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

+| Data| Description| Details |

+| - | - | - |

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

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

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

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

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

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

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

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

+## Principle of least privileges

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

+We recommend the following practices for service account privileges.

+### Permissions

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

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

+* The service principal is assigned a privileged role

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

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

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

+

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

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

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

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

+* Confirm the scopes service accounts request for resources

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

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

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

+### Duration

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

+* Schedule periodic reviews of service account usage and purpose

+ * Ensure reviews occur prior to account expiration

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

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

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

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

+## Build a lifecycle process

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

+### Monitor service accounts

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

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

+Use one of the following monitoring methods:

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

+* Export the Azure AD Sign-In Logs to

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

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

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

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

+

+#### Sign-in log details

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

+* Service accounts not signed in to the tenant

+* Changes in sign-in service account patterns

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

+### Review service account permissions

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

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

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

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

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

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

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

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

+### Recertify service account use

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

+The process includes:

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

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

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

+* Instructions if owners fail to review or respond

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

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

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

+* Account is necessary

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

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

+* Account credentials are accurate: credential type and lifetime

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

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

+### Deprovision service accounts

+Deprovision service accounts under the following circumstances:

+* Account script or application is retired

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

+* Service account is replaced by another service account

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

+Deprovisioning includes the following tasks:

+After the associated application or script is deprovisioned:

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

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

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

+* Revoke service account role assignments and OAuth2 consent grants

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

+## Next steps

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

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

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

+ Title: Monitor application sign-in health for resilience in Azure Active Directory

+description: Create queries and notifications to monitor the sign-in health of your applications.

+# Monitoring application sign-in health for resilience

+To increase infrastructure resilience, set up monitoring of application sign-in health for your critical applications. You can receive an alert when an impacting incident occurs. This article walks through setting up the App sign-in health workbook to monitor for disruptions to your users' sign-ins.

+You can configure alerts based on the App sign-in health workbook. This workbook enables administrators to monitor authentication requests for applications in their tenants. It provides these key capabilities:

+- Configure the workbook to monitor all or individual apps with near real-time data.

+- Configure alerts for authentication pattern changes so that you can investigate and respond.

+- Compare trends over a period of time. Week over week is the workbook's default setting.

+> [!NOTE]

+> See all available workbooks and the prerequisites for using them in [How to use Azure Monitor workbooks for reports](../reports-monitoring/howto-use-azure-monitor-workbooks.md).

+During an impacting event, two things may happen:

+- The number of sign-ins for an application may abruptly drop when users can't sign in.

+- The number of sign-in failures may increase.

+## Prerequisites

+- An Azure AD tenant.

+- A user with global administrator or security administrator role for the Azure AD tenant.

+- A Log Analytics workspace in your Azure subscription to send logs to Azure Monitor logs. Learn how to [create a Log Analytics workspace](../../azure-monitor/logs/quick-create-workspace.md).

+- Azure AD logs integrated with Azure Monitor logs. Learn how to [Integrate Azure AD Sign- in Logs with Azure Monitor Stream.](../reports-monitoring/howto-integrate-activity-logs-with-log-analytics.md)

+## Configure the App sign-in health workbook

+To access workbooks in the **Azure portal**, select **Azure Active Directory**, select **Workbooks**. The following screenshot shows the Workbooks Gallery in the Azure portal.

+Workbooks appear under **Usage**, **Conditional Access**, and **Troubleshoot**. The App sign in health workbook appears in the **Health** section. After you use a workbook, it may appear in the **Recently modified workbooks** section.

+You can use the App sign-in health workbook to visualize what is happening with your sign-ins. As shown in the following screenshot, the workbook presents two graphs.

+In the preceding screenshot, there are two graphs:

+- **Hourly usage (number of successful users)**. Comparing your current number of successful users to a typical usage period helps you to spot a drop in usage that may require investigation. A drop-in successful usage rate can help detect performance and utilization issues that the failure rate can't detect. For example, when users can't reach your application to attempt to sign in, there's a drop in usage but no failures. See the sample query for this data in the next section of this article.

+- **Hourly failure rate**. A spike in failure rate may indicate an issue with your authentication mechanisms. Failure rate measures only appear when users can attempt to authenticate. When users can't gain access to make the attempt, there are no failures.

+## Configure the query and alerts

+You create alert rules in Azure Monitor and can automatically run saved queries or custom log searches at regular intervals. You can configure an alert that notifies a specific group when the usage or failure rate exceeds a specified threshold.

+Use the following instructions to create email alerts based on the queries reflected in the graphs. The sample scripts send an email notification when:

+- The successful usage drops by 90% from the same hour two days ago, as shown in the preceding hourly usage graph example.

+- The failure rate increases by 90% from the same hour two days ago, as shown in the preceding hourly failure rate graph example.

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

+1. In the workbook, select **Edit** as shown in the following screenshot. Select the **query icon** in the upper right corner of the graph.

+ :::image type="content" source="./media/monitor-sign-in-health-for-resilience/edit-workbook.png" alt-text="Screenshot showing edit workbook.":::

+2. View the query log as shown in the following screenshot.

+ :::image type="content" source="./media/monitor-sign-in-health-for-resilience/query-log.png" alt-text="Screenshot showing the query log.":::

+3. Copy one of the following sample scripts for a new Kusto query.

+ - [Kusto query for increase in failure rate](#kusto-query-for-increase-in-failure-rate)

+ - [Kusto query for drop in usage](#kusto-query-for-drop-in-usage)

+4. Paste the query in the window. Select **Run**. Look for the **Completed** message and the query results as shown in the following screenshot.

+ :::image type="content" source="./media/monitor-sign-in-health-for-resilience/run-query.png" alt-text="Screenshot showing the run query results.":::

+5. Highlight the query. Select **+ New alert rule**.

+

+ :::image type="content" source="./media/monitor-sign-in-health-for-resilience/new-alert-rule.png" alt-text="Screenshot showing the new alert rule screen.":::

+6. Configure alert conditions. As shown in the following example screenshot, in the **Condition** section, under **Measurement**, select **Table rows** for **Measure**. Select **Count** for **Aggregation type**. Select **2 days** for **Aggregation granularity**.

+ :::image type="content" source="./media/monitor-sign-in-health-for-resilience/configure-alerts.png" alt-text="Screenshot showing configure alerts screen.":::

+

+ - **Table rows**. You can use the number of rows returned to work with events such as Windows event logs, Syslog, and application exceptions.

+ - **Aggregation type**. Data points applied with Count.

+ - **Aggregation granularity**. This value defines the period that works with **Frequency of evaluation**.

+7. In **Alert Logic**, configure the parameters as shown in the example screenshot.

+ :::image type="content" source="./media/monitor-sign-in-health-for-resilience/alert-logic.png" alt-text="Screenshot showing alert logic screen.":::

+

+ - **Threshold value**: 0. This value alerts on any results.

+ - **Frequency of evaluation**: 1 hour. This value sets the evaluation period to once per hour for the previous hour.

+8. In the **Actions** section, configure settings as shown in the example screenshot.

+ :::image type="content" source="./media/monitor-sign-in-health-for-resilience/create-alert-rule.png" alt-text="Screenshot showing the Create an alert rule screen.":::

+

+ - Select **Select action group** and add the group for which you want alert notifications.

+ - Under **Customize actions**, select **Email alerts**.

+ - Add a **subject line**.

+9. In the **Details** section, configure settings as shown in the example screenshot.

+ :::image type="content" source="./media/monitor-sign-in-health-for-resilience/details-section.png" alt-text="Screenshot showing the Details section.":::

+

+ - Add a **Subscription** name and a description.

+ - Select the **Resource group** to which you want to add the alert.

+ - Select the default **Severity**.

+ - Select **Enable upon creation** if you want it to immediately go live. Otherwise, select **Mute actions**.

+10. In the **Review + create** section, configure settings as shown in the example screenshot.

+ :::image type="content" source="./media/monitor-sign-in-health-for-resilience/review-create.png" alt-text="Screenshot showing the Review + create section.":::

+11. Select **Save**. Enter a name for the query. For **Save as**, select **Query**. For **Category**, select **Alert**. Again, select **Save**.

+ :::image type="content" source="./media/monitor-sign-in-health-for-resilience/save-query.png" alt-text="Screenshot showing the save query button.":::

+### Refine your queries and alerts

+To modify your queries and alerts for maximum effectiveness:

+- Always test alerts.

+- Modify alert sensitivity and frequency to receive important notifications. Admins can become desensitized to alerts and miss something important if they get too many.

+- In administrator's email clients, add the email from which alerts come to the allowed senders list. This approach prevents missed notifications due to a spam filter on their email clients.

+- [By design](https://github.com/MicrosoftDocs/azure-docs/issues/22637), alert queries in Azure Monitor can only include results from the past 48 hours.

+## Sample scripts

+### Kusto query for increase in failure rate

+In the following query, we detect increasing failure rates. As necessary, you can adjust the ratio at the bottom. It represents the percent change in traffic in the last hour as compared to yesterday's traffic at same time. A 0.5 result indicates a 50% difference in the traffic.

+```kusto

+let today = SigninLogs

+| where TimeGenerated > ago(1h) // Query failure rate in the last hour

+| project TimeGenerated, UserPrincipalName, AppDisplayName, status = case(Status.errorCode == "0", "success", "failure")

+// Optionally filter by a specific application

+//| where AppDisplayName == **APP NAME**

+| summarize success = countif(status == "success"), failure = countif(status == "failure") by bin(TimeGenerated, 1h) // hourly failure rate

+| project TimeGenerated, failureRate = (failure * 1.0) / ((failure + success) * 1.0)

+| sort by TimeGenerated desc

+| serialize rowNumber = row_number();

+let yesterday = SigninLogs

+| where TimeGenerated between((ago(1h) ΓÇô totimespan(1d))..(now() ΓÇô totimespan(1d))) // Query failure rate at the same time yesterday

+| project TimeGenerated, UserPrincipalName, AppDisplayName, status = case(Status.errorCode == "0", "success", "failure")

+// Optionally filter by a specific application

+//| where AppDisplayName == **APP NAME**

+| summarize success = countif(status == "success"), failure = countif(status == "failure") by bin(TimeGenerated, 1h) // hourly failure rate at same time yesterday

+| project TimeGenerated, failureRateYesterday = (failure * 1.0) / ((failure + success) * 1.0)

+| sort by TimeGenerated desc

+| serialize rowNumber = row_number();

+today

+| join (yesterday) on rowNumber // join data from same time today and yesterday

+| project TimeGenerated, failureRate, failureRateYesterday

+// Set threshold to be the percent difference in failure rate in the last hour as compared to the same time yesterday

+// Day variable is the number of days since the previous Sunday. Optionally ignore results on Sat, Sun, and Mon because large variability in traffic is expected.

+| extend day = dayofweek(now())

+| where day != time(6.00:00:00) // exclude Sat

+| where day != time(0.00:00:00) // exclude Sun

+| where day != time(1.00:00:00) // exclude Mon

+| where abs(failureRate ΓÇô failureRateYesterday) > 0.5

+```

+### Kusto query for drop in usage

+In the following query, we compare traffic in the last hour to yesterday's traffic at the same time. We exclude Saturday, Sunday, and Monday because we expect large variability in the previous day's traffic at the same time.

+As necessary, you can adjust the ratio at the bottom. It represents the percent change in traffic in the last hour as compared to yesterday's traffic at same time. A 0.5 result indicates a 50% difference in the traffic. Adjust these values to fit your business operation model.

+```kusto

+Let today = SigninLogs // Query traffic in the last hour

+| where TimeGenerated > ago(1h)

+| project TimeGenerated, AppDisplayName, UserPrincipalName

+// Optionally filter by AppDisplayName to scope query to a single application

+//| where AppDisplayName contains "Office 365 Exchange Online"

+| summarize users = dcount(UserPrincipalName) by bin(TimeGenerated, 1hr) // Count distinct users in the last hour

+| sort by TimeGenerated desc

+| serialize rn = row_number();

+let yesterday = SigninLogs // Query traffic at the same hour yesterday

+| where TimeGenerated between((ago(1h) ΓÇô totimespan(1d))..(now() ΓÇô totimespan(1d))) // Count distinct users in the same hour yesterday

+| project TimeGenerated, AppDisplayName, UserPrincipalName

+// Optionally filter by AppDisplayName to scope query to a single application

+//| where AppDisplayName contains "Office 365 Exchange Online"

+| summarize usersYesterday = dcount(UserPrincipalName) by bin(TimeGenerated, 1hr)

+| sort by TimeGenerated desc

+| serialize rn = row_number();

+today

+| join // Join data from today and yesterday together

+(

+yesterday

+)

+on rn

+// Calculate the difference in number of users in the last hour compared to the same time yesterday

+| project TimeGenerated, users, usersYesterday, difference = abs(users ΓÇô usersYesterday), max = max_of(users, usersYesterday)

+| extend ratio = (difference * 1.0) / max // Ratio is the percent difference in traffic in the last hour as compared to the same time yesterday

+// Day variable is the number of days since the previous Sunday. Optionally ignore results on Sat, Sun, and Mon because large variability in traffic is expected.

+| extend day = dayofweek(now())

+| where day != time(6.00:00:00) // exclude Sat

+| where day != time(0.00:00:00) // exclude Sun

+| where day != time(1.00:00:00) // exclude Mon

+| where ratio > 0.7 // Threshold percent difference in sign-in traffic as compared to same hour yesterday

+```

+## Create processes to manage alerts

+After you set up queries and alerts, create business processes to manage the alerts.

+- Who monitors the workbook and when?

+- When alerts occur, who investigates them?

+- What are the communication needs? Who creates the communications and who receives them?

+- When an outage occurs, what business processes apply?

+## Next steps

+[Learn more about workbooks](../reports-monitoring/howto-use-azure-monitor-workbooks.md)

+ Title: Common considerations for multi-tenant user management in Azure Active Directory

+description: Learn about the common design considerations for user access across Azure Active Directory tenants with guest accounts

+# Common considerations for multi-tenant user management

+This article is the third in a series of articles that provide guidance for configuring and providing user lifecycle management in Azure Active Directory (Azure AD) multi-tenant environments. The following articles in the series provide more information as described.

+- [Multi-tenant user management introduction](multi-tenant-user-management-introduction.md) is the first in the series of articles that provide guidance for configuring and providing user lifecycle management in Azure Active Directory (Azure AD) multi-tenant environments.

+- [Multi-tenant user management scenarios](multi-tenant-user-management-scenarios.md) describes three scenarios for which you can use multi-tenant user management features: end user-initiated, scripted, and automated.

+- [Common solutions for multi-tenant user management](multi-tenant-common-solutions.md) when single tenancy doesn't work for your scenario, this article provides guidance for these challenges: automatic user lifecycle management and resource allocation across tenants, sharing on-premises apps across tenants.

+The guidance helps to you achieve a consistent state of user lifecycle management. Lifecycle management includes provisioning, managing, and deprovisioning users across tenants using the available Azure tools that include [Azure AD B2B collaboration](../external-identities/what-is-b2b.md) (B2B) and [cross-tenant synchronization](../multi-tenant-organizations/cross-tenant-synchronization-overview.md).

+Synchronization requirements are unique to your organization's specific needs. As you design a solution to meet your organization's requirements, the following considerations in this article will help you identify your best options.

+- Cross-tenant synchronization

+- Directory object

+- Azure AD Conditional Access

+- Additional access control

+- Office 365

+## Cross-tenant synchronization

+[Cross-tenant synchronization](../multi-tenant-organizations/cross-tenant-synchronization-overview.md) can address collaboration and access challenges of multi-tenant organizations. The following table shows common synchronization use cases. You can use both cross-tenant synchronization and customer development to satisfy use cases when considerations are relevant to more than one collaboration pattern.

+| Use case | Cross-tenant sync | Custom development |

+| - | - | - |

+| User lifecycle management |  |  |

+| File sharing and app access |  |  |

+| Support sync to/from sovereign clouds | |  |

+| Control sync from resource tenant | |  |

+| Sync Group objects | |  |

+| Sync Manager links | |  |

+| Attribute level Source of Authority | |  |

+| Azure AD write-back to AD | |  |

+## Directory object considerations

+### Inviting an external user with UPN versus SMTP Address

+Azure AD B2B expects that a user's **UserPrincipalName** (UPN) is the primary SMTP (Email) address for sending invitations. When the user's UPN is the same as their primary SMTP address, B2B works as expected. However, if the UPN is different than the external user's primary SMTP address, it may fail to resolve when a user accepts an invitation, which may be a challenge if you don't know the user's real UPN. You need to discover and use the UPN when sending invitations for B2B.

+The [Microsoft Exchange Online](#microsoft-exchange-online) section of this article explains how to change the default primary SMTP on external users. This technique is useful if you want all email and notifications for an external to flow to the real primary SMTP address as opposed to the UPN. It may be a requirement if the UPN isn't route-able for mail flow.

+### Converting an external user's UserType

+When you use the console to manually create an invitation for an external user account, it creates the user object with a guest user type. Using other techniques to create invitations enable you to set the user type to something other than an external guest account. For example, when using the API, you can configure whether the account is an external member account or an external guest account.

+- Some of the [limits on guest functionality can be removed](../external-identities/user-properties.md#guest-user-permissions).

+- You can [convert guest accounts to member user type.](../external-identities/user-properties.md#can-azure-ad-b2b-users-be-added-as-members-instead-of-guests)

+If you convert from an external guest user to an external member user account, there might be issues with how Exchange Online handles B2B accounts. You can't mail-enable accounts that you invited as external member users. To mail-enable an external member account, use the following best approach.

+- Invite the cross-org users as external guest user accounts.

+- Show the accounts in the GAL.

+- Set the UserType to Member.

+When you use this approach, the accounts show up as MailUser objects in Exchange Online and across Office 365. Also, note there's a timing challenge. Make sure the user is visible in the GAL by checking both Azure AD user ShowInAddressList property aligns with the Exchange Online PowerShell HiddenFromAddressListsEnabled property (that are reverse of each other). The [Microsoft Exchange Online](#microsoft-exchange-online) section of this article provides more information on changing visibility.

+It's possible to convert a member user to a guest user, which is useful for internal users that you want to restrict to guest-level permissions. Internal guest users are users that aren't employees of your organization but for whom you manage their users and credentials. It may allow you to avoid licensing the internal guest user.

+### Issues with using mail contact objects instead of external users or members

+You can represent users from another tenant using a traditional GAL synchronization. If you perform a GAL synchronization rather than using Azure AD B2B collaboration, it creates a mail contact object.

+- A mail contact object and a mail-enabled external member or guest user can't coexist in the same tenant with the same email address at the same time.

+- If a mail contact object exists for the same mail address as the invited external user, it creates the external user but isn't mail-enabled.

+- If the mail-enabled external user exists with the same mail, an attempt to create a mail contact object throws an exception at creation time.

+> [!NOTE]

+> Using mail contacts requires Active Directory Directory Services (AD DS) or Exchange Online PowerShell. Microsoft Graph doesn't provide an API call for managing contacts.

+The following table displays the results of mail contact objects and external user states.

+| Existing state | Provisioning scenario | Effective result |

+| - | - | - |

+| None | Invite B2B Member | Non-mail-enabled member user. See important note above. |

+| None | Invite B2B Guest | Mail-enable external user. |

+| Mail contact object exists | Invite B2B Member | Error. Conflict of Proxy Addresses. |

+| Mail contact object exists | Invite B2B Guest | Mail-contact and Non-Mail enabled external user. See important note above. |

+| Mail-enabled external guest user | Create mail contact object | Error |

+| Mail-enabled external member user exists | Create mail-contact | Error |

+Microsoft recommends using Azure AD B2B collaboration (instead of traditional GAL synchronization) to create:

+- External users that you enable to show in the GAL.

+- External member users that show in the GAL by default but aren't mail-enabled.

+You can choose to use the mail contact object to show users in the GAL. This approach integrates a GAL without providing other permissions because mail contacts aren't security principals.

+Follow this recommended approach to achieve the goal:

+- Invite guest users.

+- Unhide them from the GAL.

+- Disable them by [blocking them from sign-in](/powershell/module/azuread/set-azureaduser).

+A mail contact object can't convert to a user object. Therefore, properties associated with a mail contact object can't transfer (such as group memberships and other resource access). Using a mail contact object to represent a user comes with the following challenges.

+- **Office 365 Groups.** Office 365 Groups support policies governing the types of users allowed to be members of groups and interact with content associated with groups. For example, a group may not allow guest users to join. These policies can't govern mail contact objects.

+- **Azure AD Self-service group management (SSGM).** Mail contact objects aren't eligible to be members in groups using the SSGM feature. You may need more tools to manage groups with recipients represented as contacts instead of user objects.

+- **Azure AD Identity Governance, Access Reviews.** You can use the access reviews feature to review and attest to membership of Office 365 group. Access reviews are based on user objects. Members represented by mail contact objects are out of scope for access reviews.

+- **Azure AD Identity Governance, Entitlement Management (EM).** When you use EM to enable self-service access requests for external users in the company's EM portal, it creates a user object the time of request. It doesn't support mail contact objects.

+## Azure AD conditional access considerations

+The state of the user, device, or network in the user's home tenant doesn't convey to the resource tenant. Therefore, an external user might not satisfy conditional access (CA) policies that use the following controls.

+Where allowed, you can override this behavior with [Cross-Tenant Access Settings (CTAS)](../external-identities/cross-tenant-access-overview.md) that honor MFA and device compliance from the home tenant.

+- **Require multi-factor authentication.** Without CTAS configured, an external user must register/respond to MFA in the resource tenant (even if MFA was satisfied in the home tenant), which results in multiple MFA challenges. If they need to reset their MFA proofs, they might not be aware of the multiple MFA proof registrations across tenants. The lack of awareness might require the user to contact an administrator in the home tenant, resource tenant, or both.

+- **Require device to be marked as compliant.** Without CTAS configured, device identity isn't registered in the resource tenant, so the external user can't access resources that require this control.

+- **Require Hybrid Azure AD Joined device.** Without CTAS configured, device identity isn't registered in the resource tenant (or on-premises Active Directory connected to resource tenant), so the external user can't access resources that require this control.

+- **Require approved client app or Require app protection policy.** Without CTAS configured, external users can't apply the resource tenant Intune Mobile App Management (MAM) policy because it also requires device registration. Resource tenant Conditional Access (CA) policy, using this control, doesn't allow home tenant MAM protection to satisfy the policy. Exclude external users from every MAM-based CA policy.

+Additionally, while you can use the following CA conditions, be aware of the possible ramifications.

+- **Sign-in risk and user risk.** User behavior in their home tenant determines, in part, the sign-in risk and user risk. The home tenant stores the data and risk score. If resource tenant policies block an external user, a resource tenant admin might not be able to enable access. [Identity Protection and B2B users](../identity-protection/concept-identity-protection-b2b.md) explains how Identity Protection detects compromised credentials for Azure AD users.

+- **Locations.** The named location definitions in the resource tenant determine the scope of the policy. The scope of the policy doesn't evaluate trusted locations managed in the home tenant. If your organization wants to share trusted locations across tenants, define the locations in each tenant where you define the resources and conditional access policies.

+## Other access control considerations

+The following are considerations for configuring access control.

+- Define [access control policies](../external-identities/authentication-conditional-access.md) to control access to resources.

+- Design CA policies with external users in mind.

+- Create policies specifically for external users.

+- If your organization is using the [**all users** dynamic group](../external-identities/use-dynamic-groups.md) condition in your existing CA policy, this policy affects external users because they are in scope of **all users**.

+- Create dedicated CA policies for external accounts.

+### Require user assignment

+If an application has the **User assignment required?** property set to **No**, external users can access the application. Application admins must understand access control impacts, especially if the application contains sensitive information. [Restrict your Azure AD app to a set of users in an Azure AD tenant](../develop/howto-restrict-your-app-to-a-set-of-users.md) explains how registered applications in an Azure Active Directory (Azure AD) tenant are, by default, available to all users of the tenant who successfully authenticate.

+### Terms and conditions

+[Azure AD terms of use](../conditional-access/terms-of-use.md) provides a simple method that organizations can use to present information to end users. You can use terms of use to require external users to approve terms of use before accessing your resources.

+### Licensing considerations for guest users with Azure AD Premium features

+Azure AD External Identities pricing is based on monthly active users (MAU). The number of active users is the count of unique users with authentication activity within a calendar month. [Billing model for Azure AD External Identities](../external-identities/external-identities-pricing.md) describes how pricing is based on monthly active users (MAU), which is the count of unique users with authentication activity within a calendar month.

+## Office 365 considerations

+The following information addresses Office 365 in the context of this paper's scenarios. Detailed information is available at [Microsoft 365 inter-tenant collaboration 365 inter-tenant collaboration](/office365/enterprise/office-365-inter-tenant-collaboration) describes options that include using a central location for files and conversations, sharing calendars, using IM, audio/video calls for communication, and securing access to resources and applications.

+### Microsoft Exchange Online

+Exchange online limits certain functionality for external users. You can lessen the limits by creating external member users instead of external guest users. Support for external users has the following limitations.

+- You can assign an Exchange Online license to an external user. However, you can't issue to them a token for Exchange Online. The results are that they can't access the resource.

+ - External users can't use shared or delegated Exchange Online mailboxes in the resource tenant.

+ - You can assign an external user to a shared mailbox but they can't access it.

+- You need to unhide external users to include them in the GAL. By default, they're hidden.

+ - Hidden external users are created at invite time. The creation is independent of whether the user has redeemed their invitation. So, if all external users are unhidden, the list includes user objects of external users who haven't redeemed an invitation. Based on your scenario, you may or may not want the objects listed.

+ - External users may be unhidden using [Exchange Online PowerShell](/powershell/exchange/exchange-online-powershell-v2). You can execute the [Set-MailUser](/powershell/module/exchange/set-mailuser) PowerShell cmdlet to set the **HiddenFromAddressListsEnabled** property to a value of **\$false**.

+

+For example:

+```Set-MailUser [ExternalUserUPN] -HiddenFromAddressListsEnabled:\$false\```

+Where **ExternalUserUPN** is the calculated **UserPrincipalName.**

+For example:

+```Set-MailUser externaluser1_contoso.com#EXT#@fabricam.onmicrosoft.com\ -HiddenFromAddressListsEnabled:\$false```

+- External users may be unhidden using [Azure AD PowerShell](/powershell/module/azuread). You can execute the [Set-AzureADUser](/powershell/module/azuread/set-azureaduser) PowerShell cmdlet to set the **ShowInAddressList** property to a value of **\$true.**

+

+For example:

+```Set-AzureADUser -ObjectId [ExternalUserUPN] -ShowInAddressList:\$true\```

+Where **ExternalUserUPN** is the calculated **UserPrincipalName.**

+For example:

+```Set-AzureADUser -ObjectId externaluser1_contoso.com#EXT#@fabricam.onmicrosoft.com\ -ShowInAddressList:\$true```

+- There's a timing delay when you update attributes and must perform additional automation afterwards, which is a result of the backend sync that occurs between Azure AD and Exchange Online. Make sure the user is visible in the GAL by checking that the Azure AD user property **ShowInAddressList** aligns with the Exchange Online PowerShell property **HiddenFromAddressListsEnabled** (that are reverse of each other) before continuing operations.

+- You can only set updates to Exchange-specific properties (such as the **PrimarySmtpAddress**, **ExternalEmailAddress**, **EmailAddresses**, and **MailTip**) using [Exchange Online PowerShell](/powershell/exchange/exchange-online-powershell-v2). The Exchange Online Admin Center doesn't allow you to modify the attributes using the GUI.

+As shown above, you can use the [Set-MailUser](/powershell/module/exchange/set-mailuser) PowerShell cmdlet for mail-specific properties. There are user properties that you can modify with the [Set-User](/powershell/module/exchange/set-user) PowerShell cmdlet. You can modify most properties with the Azure AD Graph APIs.

+One of the most useful features of **Set-MailUser** is the ability to manipulate the **EmailAddresses** property. This multi-valued attribute may contain multiple proxy addresses for the external user (such as SMTP, X500, SIP). By default, an external user has the primary SMTP address stamped correlating to the **UserPrincipalName** (UPN). If you want to change the primary SMTP and/or add SMTP addresses, you can set this property. You can't use the Exchange Admin Center; you must use Exchange Online PowerShell. [Add or remove email addresses for a mailbox in Exchange Online](/exchange/recipients-in-exchange-online/manage-user-mailboxes/add-or-remove-email-addresses) shows different ways to modify a multivalued property such as **EmailAddresses.**

+### Microsoft SharePoint Online

+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/o365-external-user.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.

+After you enable external sharing in SharePoint Online, the ability to search for guest users in the SharePoint Online people picker is **OFF** by default. This setting prohibits guest users from being discoverable when they're hidden from the Exchange Online GAL. You can enable guest users to become visible in two ways (not mutually exclusive):

+- You can enable the ability to search for guest users in these ways:

+ - Modify the **ShowPeoplePickerSuggestionsForGuestUsers** setting at the tenant and site collection level.

+ - Set the feature using the [Set-SPOTenant](/powershell/module/sharepoint-online/Set-SPOTenant) and [Set-SPOSite](/powershell/module/sharepoint-online/set-sposite) [SharePoint Online PowerShell](/powershell/sharepoint/sharepoint-online/connect-sharepoint-online) cmdlets.

+- Guest users that are visible in the Exchange Online GAL are also visible in the SharePoint Online people picker. The accounts are visible regardless of the setting for **ShowPeoplePickerSuggestionsForGuestUsers**.

+### Microsoft Teams

+Microsoft Teams has features to limit access and based on user type. Changes to user type can affect content access and features available. Microsoft Teams will require users to change their context using the tenant switching mechanism of their Teams client when working in Teams outside their home tenant.

+The tenant switching mechanism for Microsoft Teams might require users to manually switch the context of their Teams client when working in Teams outside their home tenant.

+You can enable Teams users from another entire external domain to find, call, chat, and set up meetings with your users with Teams Federation. [Manage external meetings and chat with people and organizations using Microsoft identities](/microsoftteams/manage-external-access) describes how you can allow users in your organization to chat and meet with people outside the organization who are using Microsoft as an identity provider.

+### Licensing considerations for guest users in Teams

+When you use Azure B2B with Office 365 workloads, key considerations include instances in which guest users (internal or external) don't have the same experience as member users.

+- **Microsoft Groups.** [Adding guests to Office 365 Groups](https://support.office.com/article/adding-guests-to-office-365-groups-bfc7a840-868f-4fd6-a390-f347bf51aff6) describes how guest access in Microsoft 365 Groups lets you and your team collaborate with people from outside your organization by granting them access to group conversations, files, calendar invitations, and the group notebook.

+- **Microsoft Teams.** [Team owner, member, and guest capabilities in Teams](https://support.office.com/article/team-owner-member-and-guest-capabilities-in-teams-d03fdf5b-1a6e-48e4-8e07-b13e1350ec7b) describes the guest account experience in Microsoft Teams. You can enable a full fidelity experience in Teams by using external member users. Office 365 recently clarified its licensing policy for multi-tenant organizations. Users licensed in their home tenant may access resources in another tenant within the same legal entity. You can grant access using the external members setting with no extra licensing fees. The setting applies for SharePoint, OneDrive for Business, Teams, and Groups.

+- **Identity Governance features.** Entitlement Management and access reviews may require other licenses for external users.

+- **Other products.** Products such as Dynamics CRM may require licensing in every tenant in which a user is represented.

+## Next steps

+- [Multi-tenant user management introduction](multi-tenant-user-management-introduction.md) is the first in the series of articles that provide guidance for configuring and providing user lifecycle management in Azure Active Directory (Azure AD) multi-tenant environments.

+- [Multi-tenant user management scenarios](multi-tenant-user-management-scenarios.md) describes three scenarios for which you can use multi-tenant user management features: end user-initiated, scripted, and automated.

+- [Common solutions for multi-tenant user management](multi-tenant-common-solutions.md) when single tenancy doesn't work for your scenario, this article provides guidance for these challenges: automatic user lifecycle management and resource allocation across tenants, sharing on-premises apps across tenants.

+ Title: Common solutions for multi-tenant user management in Azure Active Directory

+description: Learn about common solutions used to configure user access across Azure Active Directory tenants with guest accounts

+# Common solutions for multi-tenant user management

+This article is the fourth in a series of articles that provide guidance for configuring and providing user lifecycle management in Azure Active Directory (Azure AD) multi-tenant environments. The following articles in the series provide more information as described.

+- [Multi-tenant user management introduction](multi-tenant-user-management-introduction.md) is the first in the series.

+- [Multi-tenant user management scenarios](multi-tenant-user-management-scenarios.md) describes three scenarios for which you can use multi-tenant user management features: end user-initiated, scripted, and automated.

+- [Common considerations for multi-tenant user management](multi-tenant-common-considerations.md) provides guidance for these considerations: cross-tenant synchronization, directory object, Azure AD Conditional Access, additional access control, and Office 365.

+The guidance helps to you achieve a consistent state of user lifecycle management. Lifecycle management includes provisioning, managing, and deprovisioning users across tenants using the available Azure tools that include [Azure AD B2B collaboration](../external-identities/what-is-b2b.md) (B2B) and [cross-tenant synchronization](../multi-tenant-organizations/cross-tenant-synchronization-overview.md).

+Microsoft recommends a single tenant wherever possible. If single tenancy doesn't work for your scenario, reference the following solutions that Microsoft customers have successfully implemented for these challenges:

+- Automatic user lifecycle management and resource allocation across tenants

+- Sharing on-premises apps across tenants

+## Automatic user lifecycle management and resource allocation across tenants

+A customer acquires a competitor with whom they previously had close business relationships. The organizations want to maintain their corporate identities.

+### Current state

+Currently, the organizations are synchronizing each other's users as mail contact objects so that they show in each other's directories. Each resource tenant has enabled mail contact objects for all users in the other tenant. Across tenants, no access to applications is possible.

+### Goals

+The customer has the following goals.

+- Every user appears in each organization's GAL.

+ - User account lifecycle changes in the home tenant automatically reflected in the resource tenant GAL.

+ - Attribute changes in home tenants (such as department, name, SMTP address) automatically reflected in resource tenant GAL and the home GAL.

+- Users can access applications and resources in the resource tenant.

+- Users can self-serve access requests to resources.

+### Solution architecture

+The organizations use a point-to-point architecture with a synchronization engine such as Microsoft Identity Manager (MIM). The following diagram illustrates an example of point-to-point architecture for this solution.

+ Diagram Title: Point-to-point architecture solution. On the left, a box labeled Company A contains internal users and external users. On the right, a box labeled Company B contains internal users and external users. Between Company A and Company B, sync engine interactions go from Company A to Company B and from Company B to Company A.

+Each tenant admin performs the following steps to create the user objects.

+1. Ensure that their user database is up to date.

+1. [Deploy and configure MIM](/microsoft-identity-manager/microsoft-identity-manager-deploy).

+ 1. Address existing contact objects.

+ 1. Create external member user objects for the other tenant's internal member users.

+ 1. Synchronize user object attributes.

+1. Deploy and configure [Entitlement Management](../governance/entitlement-management-overview.md) access packages.

+ 1. Resources to be shared.

+ 1. Expiration and access review policies.

+## Sharing on-premises apps across tenants

+A customer with multiple peer organizations needs to share on-premises applications from one of the tenants.

+### Current state

+Peer organizations are synchronizing external users in a mesh topology, enabling resource allocation to cloud applications across tenants. The customer offers following functionality.

+- Share applications in Azure AD.

+- Automated user lifecycle management in resource tenant on home tenant (reflecting add, modify, and delete).

+The following diagram illustrates this scenario, where only internal users in Company A access Company A's on-premises apps.

+ Diagram Title: Mesh topology. On the top left, a box labeled Company A contains internal users and external users. On the top right, a box labeled Company B contains internal users and external users. On the bottom left, a box labeled Company C contains internal users and external users. On the bottom right, a box labeled Company D contains internal users and external users. Between Company A and Company B and between Company C and Company D, sync engine interactions go between the companies on the left and the companies on the right.

+### Goals

+Along with the current functionality, they want to offer the following.

+- Provide access to Company A's on-premises resources for the external users.

+- Apps with SAML authentication.

+- Apps with Integrated Windows Authentication and Kerberos.

+### Solution architecture

+Company A provides SSO to on-premises apps for its own internal users using Azure Application Proxy as illustrated in the following diagram.

+ Diagram Title: Azure Application Proxy architecture solution. On the top left, a box labeled https: //sales.constoso.com contains a globe icon to represent a website. Below it, a group of icons represent the User and are connected by an arrow from the User to the website. On the top right, a cloud shape labeled Azure Active Directory contains an icon labeled Application Proxy Service. An arrow connects the website to the cloud shape. On the bottom right, a box labeled DMZ has the subtitle On-premises. An arrow connects the cloud shape to the DMZ box, splitting in two to point to icons labeled Connector. Below the Connector icon on the left, an arrow points down and splits in two to point to icons labeled App 1 and App 2. Below the Connector icon on the right, an arrow points down to an icon labeled App 3.

+Admins in tenant A perform the following steps to enable their external users to access the same on-premises applications.

+1. [Configure access to SAML apps](../external-identities/hybrid-cloud-to-on-premises.md#access-to-saml-apps).

+1. [Configure access to other applications](../external-identities/hybrid-cloud-to-on-premises.md#access-to-iwa-and-kcd-apps).

+1. Create on-premises users through [MIM](../external-identities/hybrid-cloud-to-on-premises.md#create-b2b-guest-user-objects-through-mim) or [PowerShell](https://www.microsoft.com/download/details.aspx?id=51495).

+The following articles provide additional information about B2B collaboration.

+- [Grant B2B users in Azure AD access to your on-premises resources](../external-identities/hybrid-cloud-to-on-premises.md) describes how you can provide B2B users access to on-premises apps.

+- [Azure Active Directory B2B collaboration for hybrid organizations](../external-identities/hybrid-organizations.md) describes how you can give your external partners access to apps and resources in your organization.

+## Next steps

+- [Multi-tenant user management introduction](multi-tenant-user-management-introduction.md) is the first in the series of articles that provide guidance for configuring and providing user lifecycle management in Azure Active Directory (Azure AD) multi-tenant environments.

+- [Multi-tenant user management scenarios](multi-tenant-user-management-scenarios.md) describes three scenarios for which you can use multi-tenant user management features: end user-initiated, scripted, and automated.

+- [Common considerations for multi-tenant user management](multi-tenant-common-considerations.md) provides guidance for these considerations: cross-tenant synchronization, directory object, Azure AD Conditional Access, additional access control, and Office 365.

+ Title: Configuring multi-tenant user management in Azure Active Directory

+description: Learn about the different patterns used to configure user access across Azure Active Directory tenants with guest accounts

+# Multi-tenant user management introduction

+This article is the first in a series of articles that provide guidance for configuring and providing user lifecycle management in Azure Active Directory (Azure AD) multi-tenant environments. The following articles in the series provide more information as described.

+- [Multi-tenant user management scenarios](multi-tenant-user-management-scenarios.md) describes three scenarios for which you can use multi-tenant user management features: end user-initiated, scripted, and automated.

+- [Common considerations for multi-tenant user management](multi-tenant-common-considerations.md) provides guidance for these considerations: cross-tenant synchronization, directory object, Azure AD Conditional Access, additional access control, and Office 365.

+- [Common solutions for multi-tenant user management](multi-tenant-common-solutions.md) when single tenancy doesn't work for your scenario, this article provides guidance for these challenges: automatic user lifecycle management and resource allocation across tenants, sharing on-premises apps across tenants.

+The guidance helps to you achieve a consistent state of user lifecycle management. Lifecycle management includes provisioning, managing, and deprovisioning users across tenants using the available Azure tools that include [Azure AD B2B collaboration](../external-identities/what-is-b2b.md) (B2B) and [cross-tenant synchronization](../multi-tenant-organizations/cross-tenant-synchronization-overview.md).

+Provisioning users into a single Azure Active Directory (Azure AD) tenant provides a unified view of resources and a single set of policies and controls. This approach enables consistent user lifecycle management.

+Microsoft recommends a single tenant when possible. Having multiple tenants can result in unique cross-tenant collaboration and management requirements. When consolidation to a single Azure AD tenant isn't possible, multi-tenant organizations may span two or more Azure AD tenants for reasons that include the following.

+- Mergers

+- Acquisitions

+- Divestitures

+- Collaboration across public, sovereign, and regional clouds

+- Political or organizational structures that prohibit consolidation to a single Azure AD tenant

+## Azure AD B2B collaboration

+Azure AD B2B collaboration (B2B) enables you to securely share your company's applications and services with external users. When users can come from any organization, B2B helps you maintain control over access to your IT environment and data.

+You can use B2B collaboration to provide external access for your organization's users to access multiple tenants that you manage. Traditionally, B2B external user access can authorize access to users that your own organization doesn't manage. However, external user access can manage access across multiple tenants that your organization manages.

+An area of confusion with Azure AD B2B collaboration surrounds the [properties of a B2B guest user](../external-identities/user-properties.md). The difference between internal versus external user accounts and member versus guest user types contributes to confusion. Initially, all internal users are member users with **UserType** attribute set to *Member* (member users). An internal user has an account in your Azure AD that is authoritative and authenticates to the tenant where the user resides. A member user is a licensed user with default [member-level permissions](../fundamentals/users-default-permissions.md) in the tenant. Treat member users as employees of your organization.

+You can invite an internal user of one tenant into another tenant as an external user. An external user signs in with an external Azure AD account, social identity, or other external identity provider. External users authenticate outside the tenant to which you invite the external user. At the B2B first release, all external users were of **UserType** *Guest* (guest users). Guest users have [restricted permissions](../fundamentals/users-default-permissions.md) in the tenant. For example, guest users can't enumerate the list of all users nor groups in the tenant directory.

+For the **UserType** property on users, B2B supports flipping the bit from internal to external, and vice versa, which contributes to the confusion.

+You can change an internal user from member user to guest user. For example, you can have an unlicensed internal guest user with guest-level permissions in the tenant, which is useful when you provide a user account and credentials to a person that isn't an employee of your organization.

+You can change an external user from guest user to member user, giving member-level permissions to the external user. Making this change is useful when you manage multiple tenants for your organization and need to give member-level permissions to a user across all tenants. This need may occur regardless of whether the user is internal or external in any given tenant. Member users may require more [licenses](../external-identities/external-identities-pricing.md).

+Most documentation for B2B refers to an external user as a guest user. It conflates the **UserType** property in a way that assumes all guest users are external. When documentation calls out a guest user, it assumes that it's an external guest user. This article specifically and intentionally refers to external versus internal and member user versus guest user.

+## Cross-tenant synchronization

+[Cross-tenant synchronization](../multi-tenant-organizations/cross-tenant-synchronization-overview.md) enables multi-tenant organizations to provide seamless access and collaboration experiences to end users, leveraging existing B2B external collaboration capabilities. The feature doesn't allow cross-tenant synchronization across Microsoft sovereign clouds (such as Microsoft 365 US Government GCC High, DOD or Office 365 in China). See [Common considerations for multi-tenant user management](multi-tenant-common-considerations.md#cross-tenant-synchronization) for help with automated and custom cross-tenant synchronization scenarios.

+Watch Arvind Harinder talk about the cross-tenant sync capability in Azure AD (embedded below).

+> [!VIDEO https://www.youtube.com/embed/7B-PQwNfGBc]

+The following conceptual and how-to articles provide information about Azure AD B2B collaboration and cross-tenant synchronization.

+### Conceptual articles

+- [B2B best practices](../external-identities/b2b-fundamentals.md) features recommendations for providing the smoothest experience for users and administrators.

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

+- [Properties on an Azure AD B2B collaboration user](../external-identities/user-properties.md) describes the properties and states of the external user object in Azure AD. The description provides details before and after invitation redemption.

+- [B2B user tokens](../external-identities/user-token.md) provides examples of the bearer tokens for B2B for an external user.

+- [Conditional access for B2B](../external-identities/authentication-conditional-access.md) describes how conditional access and MFA work for external users.

+- [Cross-tenant access settings](../external-identities/cross-tenant-access-overview.md) provides granular control over how external Azure AD organizations collaborate with you (inbound access) and how your users collaborate with external Azure AD organizations (outbound access).

+- [Cross-tenant synchronization overview](../multi-tenant-organizations/cross-tenant-synchronization-overview.md) explains how to automate creating, updating, and deleting Azure AD B2B collaboration users across tenants in an organization.

+### How-to articles

+- [Use PowerShell to bulk invite Azure AD B2B collaboration users](../external-identities/bulk-invite-powershell.md) describes how to use PowerShell to send bulk invitations to external users.

+- [Enforce multifactor authentication for B2B guest users](../external-identities/b2b-tutorial-require-mfa.md) explains how you can use conditional access and MFA policies to enforce tenant, app, or individual external user authentication levels.

+- [Email one-time passcode authentication](../external-identities/one-time-passcode.md) describes how the Email one-time passcode feature authenticates external users when they can't authenticate through other means like Azure AD, a Microsoft account (MSA), or Google Federation.

+## Terminology

+The following terms in Microsoft content refer to multi-tenant collaboration in Azure AD.

+- **Resource tenant:** The Azure AD tenant containing the resources that users want to share with others.

+- **Home tenant:** The Azure AD tenant containing users that require access to the resources in the resource tenant.

+- **Internal user:** An internal user has an account that is authoritative and authenticates to the tenant where the user resides.

+- **External user:** An external user has an external Azure AD account, social identity, or other external identity provider to sign in. The external user authenticates somewhere outside the tenant to which you have invited the external user.

+- **Member user:** An internal or external member user is a licensed user with default member-level permissions in the tenant. Treat member users as employees of your organization.

+- **Guest user:** An internal or external guest user has restricted permissions in the tenant. Guest users aren't employees of your organization (such as users for partners). Most B2B documentation refers to B2B Guests, which primarily refers to external guest user accounts.

+- **User lifecycle management:** The process of provisioning, managing, and deprovisioning user access to resources.

+- **Unified GAL:** Each user in each tenant can see users from each organization in their Global Address List (GAL).

+## Deciding how to meet your requirements

+Your organization's unique requirements influence your strategy for managing users across tenants. To create an effective strategy, consider the following requirements.

+- Number of tenants

+- Type of organization

+- Current topologies

+- Specific user synchronization needs

+### Common requirements

+Organizations initially focus on requirements that they want in place for immediate collaboration. Sometimes called *Day One* requirements, they focus on enabling end users to smoothly merge without interrupting their ability to generate value. As you define Day One and administrative requirements, consider including the following requirements and needs.

+### Communications requirements

+- **Unified global address list:** Each user can see all other users in the GAL in their home tenant.

+- **Free/busy information:** Enable users to discover each other's availability. You can do so with [Organization relationships in Exchange Online](/exchange/sharing/organization-relationships/create-an-organization-relationship).

+- **Chat and presence:** Enable users to determine others' presence and initiate instant messaging. Configure through [external access in Microsoft Teams](/microsoftteams/trusted-organizations-external-meetings-chat).

+- **Book resources such as meeting rooms:** Enable users to book conference rooms or other resources across the organization. Cross-tenant conference room booking isn't currently available.

+- **Single email domain:** Enable all users to send and receive mail from a single email domain (for example, `users@contoso.com`). Sending requires an email address rewrite solution.

+### Access requirements

+- **Document access:** Enable users to share documents from SharePoint, OneDrive, and Teams.

+- **Administration:** Allow administrators to manage configuration of subscriptions and services deployed across multiple tenants.

+- **Application access:** Allow end users to access applications across the organization.

+- **Single Sign On:** Enable users to access resources across the organization without the need to enter more credentials.

+### Patterns for account creation

+Microsoft mechanisms for creating and managing the lifecycle of your external user accounts follow three common patterns. You can use these patterns to help define and implement your requirements. Choose the pattern that best aligns with your scenario and then focus on the pattern details.

+| Mechanism | Description | Best when |

+| - | - | - |

+| [End user-initiated](multi-tenant-user-management-scenarios.md#end-user-initiated-scenario) | Resource tenant admins delegate the ability to invite external users to the tenant, an app, or a resource to users within the resource tenant. You can invite users from the home tenant or they can individually sign up. | Unified Global Address List on Day One not required. |

+|[Scripted](multi-tenant-user-management-scenarios.md#scripted-scenario) | Resource tenant administrators deploy a scripted *pull* process to automate discovery and provisioning of external users to support sharing scenarios. | Small number of tenants (such as two). |

+|[Automated](multi-tenant-user-management-scenarios.md#automated-scenario)| Resource tenant admins use an identity provisioning system to automate the provisioning and deprovisioning processes. | You need Unified Global Address List across tenants. |

+

+## Next steps

+- [Multi-tenant user management scenarios](multi-tenant-user-management-scenarios.md) describes three scenarios for which you can use multi-tenant user management features: end user-initiated, scripted, and automated.

+- [Common considerations for multi-tenant user management](multi-tenant-common-considerations.md) provides guidance for these considerations: cross-tenant synchronization, directory object, Azure AD Conditional Access, additional access control, and Office 365.

+- [Common solutions for multi-tenant user management](multi-tenant-common-solutions.md) when single tenancy doesn't work for your scenario, this article provides guidance for these challenges: automatic user lifecycle management and resource allocation across tenants, sharing on-premises apps across tenants.

+- [Multi-tenant synchronization from Active Directory](../hybrid/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.

+ Title: Common scenarios for using multi-tenant user management in Azure Active Directory

+description: Learn about common scenarios where guest accounts can be used to configure user access across Azure Active Directory tenants

+# Multi-tenant user management scenarios

+This article is the second in a series of articles that provide guidance for configuring and providing user lifecycle management in Azure Active Directory (Azure AD) multi-tenant environments. The following articles in the series provide more information as described.

+- [Multi-tenant user management introduction](multi-tenant-user-management-introduction.md) is the first in the series of articles that provide guidance for configuring and providing user lifecycle management in Azure Active Directory (Azure AD) multi-tenant environments.

+- [Common considerations for multi-tenant user management](multi-tenant-common-considerations.md) provides guidance for these considerations: cross-tenant synchronization, directory object, Azure AD Conditional Access, additional access control, and Office 365.

+- [Common solutions for multi-tenant user management](multi-tenant-common-solutions.md) when single tenancy doesn't work for your scenario, this article provides guidance for these challenges: automatic user lifecycle management and resource allocation across tenants, sharing on-premises apps across tenants.

+The guidance helps to you achieve a consistent state of user lifecycle management. Lifecycle management includes provisioning, managing, and deprovisioning users across tenants using the available Azure tools that include [Azure AD B2B collaboration](../external-identities/what-is-b2b.md) (B2B) and [cross-tenant synchronization](../multi-tenant-organizations/cross-tenant-synchronization-overview.md).

+This article describes three scenarios for which you can use multi-tenant user management features.

+- End user-initiated

+- Scripted

+- Automated

+## End user-initiated scenario

+In end user-initiated scenarios, resource tenant administrators delegate certain abilities to users in the tenant. Administrators enable end users to invite external users to the tenant, an app, or a resource. You can invite users from the home tenant or they can individually sign up.

+For example, a global professional services firm collaborates with subcontractors on projects. Subcontractors (external users) require access to the firm's applications and documents. Firm admins can delegate to its end users the ability to invite subcontractors or configure self-service for subcontractor resource access.

+### Provisioning accounts

+Here are the most widely used ways to invite end users to access tenant resources.

+- [**Application-based invitations.**](../external-identities/o365-external-user.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/my-apps-deployment-plan.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.

+- [**Entitlement management.**](../governance/entitlement-management-overview.md) Enable admins or resource owners to create access packages with resources, allowed external organizations, external user expiration, and access policies. Publish access packages to enable external user self-service sign-up for resource access.

+- [**Azure portal.**](../external-identities/add-users-administrator.md) End users with the [Guest Inviter role](../external-identities/external-collaboration-settings-configure.md) can sign in to the Azure portal and invite external users from the **Users** menu in Azure AD.

+- [**Programmatic (PowerShell, Graph API).**](../external-identities/customize-invitation-api.md) End users with the [Guest Inviter role](../external-identities/external-collaboration-settings-configure.md) can use PowerShell or Graph API to invite external users.

+### Redeeming invitations

+When you provision accounts to access a resource, email invitations go to the invited user's email address.

+When an invited user receives an invitation, they can follow the link contained in the email to the redemption URL. In doing so, the invited user can approve or deny the invitation and, if necessary, create an external user account.

+Invited users can also try to directly access the resource, referred to as just-in-time (JIT) redemption, if either of the following scenarios are true.

+- The invited user already has an Azure AD or Microsoft account, or

+- Admins have enabled [email one-time passcodes](../external-identities/one-time-passcode.md).

+During JIT redemption, the following considerations may apply.

+- If administrators haven't [suppressed consent prompts](../external-identities/cross-tenant-access-settings-b2b-collaboration.md), the user must consent before accessing the resource.

+- PowerShell allows control over whether an email is sent when [using PowerShell](https://microsoft-my.sharepoint.com/powershell/module/azuread/new-azureadmsinvitation?view=azureadps-2.0&preserve-view=true) to invite users.

+- You can allow or block invitations to external users from specific organizations by using an [allowlist or a blocklist](../external-identities/allow-deny-list.md).

+For more information, see [Azure Active Directory B2B collaboration invitation redemption](../external-identities/redemption-experience.md).

+### Enabling one-time passcode authentication

+In scenarios where you allow for ad hoc B2B, enable [email one-time passcode authentication](../external-identities/one-time-passcode.md). This feature authenticates external users when you can't authenticate them through other means, such as:

+- Azure AD.

+- Microsoft account (MSA).

+- Gmail account through Google Federation.

+- Account from a SAML/WS-Fed IDP through Direct Federation.

+With one-time passcode authentication, there's no need to create a Microsoft account. When the external user redeems an invitation or accesses a shared resource, they receive a temporary code at their email address. They then enter the code to continue signing in.

+### Managing accounts

+In the end user-initiated scenario, the resource tenant administrator manages external user accounts in the resource tenant (not updated based on the updated values in the home tenant). The only visible attributes received include the email address and display name.

+You can configure more attributes on external user objects to facilitate different scenarios (such as entitlement scenarios). You can include populating the address book with contact details. For example, consider the following attributes.

+- **HiddenFromAddressListsEnabled** [ShowInAddressList]

+- **FirstName** [GivenName]

+- **LastName** [SurName]

+- **Title**

+- **Department**

+- **TelephoneNumber**

+You might set these attributes to add external users to the global address list (GAL) and to people search (such as SharePoint People Picker). Other scenarios may require different attributes (such as setting entitlements and permissions for Access Packages, Dynamic Group Membership, and SAML Claims).

+By default, the GAL hides invited external users. Set external user attributes to be unhidden to include them in the unified GAL. The Microsoft Exchange Online section of [Common considerations for multi-tenant user management](multi-tenant-common-considerations.md) describes how you can lessen limits by creating external member users instead of external guest users.

+### Deprovisioning accounts

+End user-initiated scenarios decentralize access decisions, which can create the challenge of deciding when to remove an external user and their associated access. [Entitlement management](../governance/entitlement-management-overview.md) and [access reviews](../governance/manage-guest-access-with-access-reviews.md) let you review and remove existing external users and their resource access.

+When you invite users outside of entitlement management, you must create a separate process to review and manage their access. For example, if you directly invite an external user through SharePoint Online, it isn't in your entitlement management process.

+## Scripted scenario

+In the scripted scenario, resource tenant administrators deploy a scripted pull process to automate discovery and external user provisioning.

+For example, a company acquires a competitor. Each company has a single Azure AD tenant. They want the following Day One scenarios to work without users having to perform any invitation or redemption steps. All users must be able to:

+- Use single sign-on to all provisioned resources.

+- Find each other and resources in a unified GAL.

+- Determine each other's presence and initiate chat.

+- Access applications based on dynamic group membership.

+In this scenario, each organization's tenant is the home tenant for its existing employees while being the resource tenant for the other organization's employees.

+### Provisioning accounts

+With [Delta Query](/graph/delta-query-overview), tenant admins can deploy a scripted pull process to automate discovery and identity provisioning to support resource access. This process checks the home tenant for new users. It uses the B2B Graph APIs to provision new users as external users in the resource tenant as illustrated in the following multi-tenant topology diagram.

+ Diagram Title: Multi-tenant topology diagram. On the left, a box labeled Company A contains internal users and external users. On the right, a box labeled Company B contains internal users and external users. Between Company A and Company B, an interaction goes from Company A to Company B with the label, Script to pull A users to B. Another interaction goes from Company B to Company A with the label, Script to pull B users to A.

+- Tenant administrators prearrange credentials and consent to allow each tenant to read.

+- Tenant administrators automate enumeration and pulling scoped users to the resource tenant.

+- Use Microsoft Graph API with consented permissions to read and provision users with the invitation API.

+- Initial provisioning can read source attributes and apply them to the target user object.

+### Managing accounts

+The resource organization may augment profile data to support sharing scenarios by updating the user's metadata attributes in the resource tenant. However, if ongoing synchronization is necessary, then a synchronized solution might be a better option.

+### Deprovisioning accounts

+[Delta Query](/graph/delta-query-overview) can signal when an external user needs to be deprovisioned. [Entitlement management](../governance/entitlement-management-overview.md) and [access reviews](../governance/manage-guest-access-with-access-reviews.md) can provide a way to review and remove existing external users and their access to resources.

+If you invite users outside of entitlement management, create a separate process to review and manage external user access. For example, if you invite the external user directly through SharePoint Online, it isn't in your entitlement management process.

+## Automated scenario

+Synchronized sharing across tenants is the most complex of the patterns described in this article. This pattern enables more automated management and deprovisioning options than end user-initiated or scripted.

+In automated scenarios, resource tenant admins use an identity provisioning system to automate provisioning and deprovisioning processes. In scenarios within Microsoft's Commercial Cloud instance, we have [cross-tenant synchronization](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/seamless-application-access-and-lifecycle-management-for-multi/ba-p/3728752). In scenarios that span Microsoft Sovereign Cloud instances, you need other approaches because cross-tenant synchronization doesn't yet support cross-cloud.

+For example, within a Microsoft Commercial Cloud instance, a multi-national/regional conglomeration has multiple subsidiaries with the following requirements.

+- Each has their own Azure AD tenant and need to work together.

+- In addition to synchronizing new users among tenants, automatically synchronize attribute updates and automate deprovisioning.

+- If an employee is no longer at a subsidiary, remove their account from all other tenants during the next synchronization.

+In an expanded, cross-cloud scenario, a Defense Industrial Base (DIB) contractor has a defense-based and commercial-based subsidiary. These have competing regulation requirements:

+- The US defense business resides in a US Sovereign Cloud tenant such as Microsoft 365 US Government GCC High and Azure Government.

+- The commercial business resides in a separate Azure AD tenant in Commercial such as an Azure AD environment running on the global Azure cloud.

+To act like a single company deployed into a cross-cloud architecture, all users synchronize to both tenants. This approach enables unified GAL availability across both tenants and may ensure that users automatically synchronized to both tenants include entitlements and restrictions to applications and content. Example requirements include:

+- US employees may have ubiquitous access to both tenants.

+- Non-US employees show in the unified GAL of both tenants but don't have access to protected content in the GCC High tenant.

+This scenario requires automatic synchronization and identity management to configure users in both tenants while associating them with the proper entitlement and data protection policies.

+[Cross-cloud B2B](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/collaborate-securely-across-organizational-boundaries-and/ba-p/3094109) requires you to configure [Cross-Tenant Access Settings](../external-identities/cross-cloud-settings.md) for each organization with which you want to collaborate in the remote cloud instance.

+### Provisioning accounts

+This section describes three techniques for automating account provisioning in the automated scenario.

+#### Technique 1: Use the [built-in cross-tenant synchronization capability in Azure AD](../multi-tenant-organizations/cross-tenant-synchronization-overview.md)

+This approach only works when all tenants that you need to synchronize are in the same cloud instance (such as Commercial to Commercial).

+#### Technique 2: Provision accounts with Microsoft Identity Manager

+Use an external Identity and Access Management (IAM) solution such as [Microsoft Identity Manager](/microsoft-identity-manager/microsoft-identity-manager-2016) (MIM) as a synchronization engine.

+This advanced deployment uses MIM as a synchronization engine. MIM calls the [Microsoft Graph API](https://developer.microsoft.com/graph) and [Exchange Online PowerShell](/powershell/exchange/exchange-online/exchange-online-powershell?view=exchange-ps&preserve-view=true). Alternative implementations can include the cloud-hosted [Active Directory Synchronization Service](/windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview) (ADSS) managed service offering from [Microsoft Industry Solutions](https://www.microsoft.com/industrysolutions). There are non-Microsoft offerings that you can create from scratch with other IAM offerings (such as SailPoint, Omada, and OKTA).

+You perform a cloud-to-cloud synchronization of identity (users, contacts, and groups) from one tenant to another as illustrated in the following diagram.

+ Diagram Title: Cloud-to-cloud identity synchronization. On the left, a box labeled Company A contains internal users and external users. On the right, a box labeled Company B contains internal users and external users. Between Company A and Company B, sync engine interactions go from Company A to Company B and from Company B to Company A.

+Considerations that are outside the scope of this article include integration of on-premises applications.

+#### Technique 3: Provision accounts with Azure AD Connect

+This technique only applies for complex organizations that manage all identity in traditional Windows Server-based Active Directory Domain Services (AD DS). The approach uses Azure AD Connect as the synchronization engine as illustrated in the following diagram.

+ Diagram Title: Provision accounts with Azure AD Connect. The diagram shows four main components. A box on the left represents the Customer. A cloud shape on the right represents B2B Conversion. At the top center, a box containing a cloud shape represents Microsoft Commercial Cloud. At the bottom center, a box containing a cloud shape represents Microsoft US Government Sovereign Cloud. Inside the Customer box, a Windows Server Active Directory icon connects to two boxes, each with an Azure AD Connect label. The connections are dashed red lines with arrows at both ends and a refresh icon. Inside the Microsoft Commercial Cloud shape is another cloud shape that represents Microsoft Azure Commercial. Inside is another cloud shape that represents Azure Active Directory. To the right of the Microsoft Azure Commercial cloud shape is a box that represents Office 365 with a label, Public Multi-Tenant. A solid red line with arrows at both ends connects the Office 365 box with the Microsoft Azure Commercial cloud shape and a label, Hybrid Workloads. Two dashed lines connect from the Office 365 box to the Azure Active Directory cloud shape. One has an arrow on the end that connects to Azure Active Directory. The other has arrows on both ends. A dashed line with arrows on both ends connects the Azure Active Directory cloud shape to the top Customer Azure AD Connect box. A dashed line with arrows on both ends connects the Microsoft Commercial Cloud shape to the B2B Conversion cloud shape. Inside the Microsoft US Government Sovereign Cloud box is another cloud shape that represents Microsoft Azure Government. Inside is another cloud shape that represents Azure Active Directory. To the right of the Microsoft Azure Commercial cloud shape is a box that represents Office 365 with a label, US Gov GCC-High L4. A solid red line with arrows at both ends connects the Office 365 box with the Microsoft Azure Government cloud shape and a label, Hybrid Workloads. Two dashed lines connect from the Office 365 box to the Azure Active Directory cloud shape. One has an arrow on the end that connects to Azure Active Directory. The other has arrows on both ends. A dashed line with arrows on both ends connects the Azure Active Directory cloud shape to the bottom Customer Azure AD Connect box. A dashed line with arrows on both ends connects the Microsoft Commercial Cloud shape to the B2B Conversion cloud shape.

+Unlike the MIM technique, all identity sources (users, contacts, and groups) come from traditional Windows Server-based Active Directory Domain Services (AD DS). The AD DS directory is typically an on-premises deployment for a complex organization that manages identity for multiple tenants. Cloud-only identity isn't in scope for this technique. All identity must be in AD DS to include them in scope for synchronization.

+Conceptually, this technique synchronizes a user into a home tenant as an internal member user (default behavior). Alternatively, it may synchronize a user into a resource tenant as an external user (customized behavior).

+Microsoft supports this dual sync user technique with careful considerations to what modifications occur in the Azure AD Connect configuration. For example, if you make modifications to the wizard-driven setup configuration, you need to document the changes if you must rebuild the configuration during a support incident.

+Out of the box, Azure AD Connect can't synchronize an external user. You must augment it with an external process (such as a PowerShell script) to convert the users from internal to external accounts.

+Benefits of this technique include Azure AD Connect synchronizing identity with attributes stored in AD DS. Synchronization may include address book attributes, manager attributes, group memberships, and other hybrid identity attributes into all tenants within scope. It deprovisions identity in alignment with AD DS. It doesn't require a more complex IAM solution to manage the cloud identity for this specific task.

+There's a one-to-one relationship of Azure AD Connect per tenant. Each tenant has its own configuration of Azure AD Connect that you can individually alter to support member and/or external user account synchronization.

+### Choosing the right topology

+Most customers use one of the following topologies in automated scenarios.

+- A mesh topology enables sharing of all resources in all tenants. You create users from other tenants in each resource tenant as external users.

+- A single resource tenant topology uses a single tenant (the resource tenant), in which users from other tenants are external users.

+Reference the following table as a decision tree while you design your solution. Following the table, diagrams illustrate both topologies to help you determine which is right for your organization.

+#### Comparison of mesh versus single resource tenant topologies

+| Consideration | Mesh topology | Single resource tenant |

+| - | - |-|

+| Each company has separate Azure AD tenant with users and resources | Yes | Yes |

+| **Resource location and collaboration** | | |

+| Shared apps and other resources remain in their current home tenant | Yes | No. You can share only apps and other resources in the resource tenant. You can't share apps and other resources remaining in other tenants. |

+| All viewable in individual company's GALs (Unified GAL) | Yes| No |

+| **Resource access and administration** | | |

+| You can share ALL applications connected to Azure AD among all companies. | Yes | No. Only applications in the resource tenant are shared. You can't share applications remaining in other tenants. |

+| Global resource administration | Continue at tenant level. | Consolidated in the resource tenant. |

+| Licensing: Office 365 SharePoint Online, unified GAL, Teams access all support guests; however, other Exchange Online scenarios don't. | Continues at tenant level. | Continues at tenant level. |

+| Licensing: [Azure AD (premium)](../external-identities/external-identities-pricing.md) | First 50 K Monthly Active Users are free (per tenant). | First 50 K Monthly Active Users are free. |

+| Licensing: SaaS apps | Remain in individual tenants, may require licenses per user per tenant. | All shared resources reside in the single resource tenant. You can investigate consolidating licenses to the single tenant if appropriate. |

+#### Mesh topology

+The following diagram illustrates mesh topology.

+ Diagram Title: Mesh topology. On the top left, a box labeled Company A contains internal users and external users. On the top right, a box labeled Company B contains internal users and external users. On the bottom left, a box labeled Company C contains internal users and external users. On the bottom right, a box labeled Company D contains internal users and external users. Between Company A and Company B and between Company C and Company D, sync engine interactions go between the companies on the left and the companies on the right.

+In a mesh topology, every user in each home tenant synchronizes to each of the other tenants, which become resource tenants.

+- You can share any resource within a tenant with external users.

+- Each organization can see all users in the conglomerate. In the above diagram, there are four unified GALs, each of which contains the home users and the external users from the other three tenants.

+[Common considerations for multi-tenant user management](multi-tenant-common-considerations.md) provides information on provisioning, managing, and deprovisioning users in this scenario.

+#### Mesh topology for cross-cloud

+You can use the mesh topology in as few as two tenants, such as in the scenario for a DIB defense contractor straddling a cross-sovereign cloud solution. As with the mesh topology, each user in each home tenant synchronizes to the other tenant, which becomes a resource tenant. In the [Technique 3 section](#technique-3-provision-accounts-with-azure-ad-connect) diagram, the public Commercial tenant internal user synchronizes to the US sovereign GCC High tenant as an external user account. At the same time, the GCC High internal user synchronizes to Commercial as an external user account.

+The diagram also illustrates data storage locations. Data categorization and compliance is outside the scope of this article, but you can include entitlements and restrictions to applications and content. Content may include locations where an internal user's user-owned data resides (such as data stored in an Exchange Online mailbox or OneDrive for Business). The content may be in their home tenant and not in the resource tenant. Shared data may reside in either tenant. You can restrict access to the content through access control and conditional access policies.

+#### Single resource tenant topology

+The following diagram illustrates single resource tenant topology.

+ Diagram Title: Single resource tenant topology. At the top, a box that represents Company A contains three boxes. On the left, a box represents all shared resources. In the middle, a box represents internal users. On the right, a box represents external users. Below the Company A box is a box that represents the sync engine. Three arrows connect the sync engine to Company A. Below the sync engine box, at the bottom of the diagram, are three boxes that represent Company B, Company C, and Company D. An arrow connects each of them to the sync engine box. Inside each of the bottom company boxes is a label, Microsoft Graph API Exchange online PowerShell, and icons that represent internal users.

+In a single resource tenant topology, users and their attributes synchronize to the resource tenant (Company A in the above diagram).

+- All resources shared among the member organizations must reside in the single resource tenant. If multiple subsidiaries have subscriptions to the same SaaS apps, there's an opportunity to consolidate those subscriptions.

+- Only the GAL in the resource tenant displays users from all companies.

+### Managing accounts

+This solution detects and syncs attribute changes from source tenant users to resource tenant external users. You can use these attributes to make authorization decisions (such as when you're using dynamic groups).

+### Deprovisioning accounts

+Automation detects object deletion in the source environment and deletes the associated external user object in the target environment.

+[Common considerations for multi-tenant user management](multi-tenant-common-considerations.md) provides additional information on provisioning, managing, and deprovisioning users in this scenario.

+## Next steps

+- [Multi-tenant user management introduction](multi-tenant-user-management-introduction.md) is the first in the series of articles that provide guidance for configuring and providing user lifecycle management in Azure Active Directory (Azure AD) multi-tenant environments.

+- [Common considerations for multi-tenant user management](multi-tenant-common-considerations.md) provides guidance for these considerations: cross-tenant synchronization, directory object, Azure AD Conditional Access, additional access control, and Office 365.

+- [Common solutions for multi-tenant user management](multi-tenant-common-solutions.md) when single tenancy doesn't work for your scenario, this article provides guidance for these challenges: automatic user lifecycle management and resource allocation across tenants, sharing on-premises apps across tenants.

+ Title: University multilateral federation baseline design

+description: Learn about a baseline design for a multilateral federation solution for universities.

+# Baseline architecture overview

+Microsoft often speaks with research universities that operate in hybrid environments in which applications are either cloud based or hosted on-premises. In both cases, applications can use various authentication protocols. In some cases, these protocols are reaching end of life or aren't providing the required level of security.

+[](media/multilateral-federation-baseline/typical-baseline-environment.png#lightbox)

+Applications drive much of the need for different authentication protocols and different identity management (IdM) mechanisms.

+In research university environments, research apps often drive IdM requirements. A university might use a federation provider, such as Shibboleth, as a primary identity provider (IdP). If so, Azure Active Directory (Azure AD) is often configured to federate with Shibboleth. If Microsoft 365 apps are also in use, Azure AD enables you to configure integration.

+Applications used in research universities operate in various parts of the overall IT footprint:

+* Research and multilateral federation applications are available through InCommon and eduGAIN.

+* Library applications provide access to electronic journals and other e-content providers.

+* Some applications use legacy authentication protocols such as Central Authentication Service to enable single sign-on.

+* Student and faculty applications often use multiple authentication mechanisms. For example, some are integrated with Shibboleth or other federation providers, whereas others are integrated with Azure AD.

+* Microsoft 365 applications are integrated with Azure AD.

+* Windows Server Active Directory might be in use and synchronized with Azure AD.

+* Lightweight Directory Access Protocol (LDAP) is in use at many universities that might have an external LDAP directory or identity registry. These registries are often used to house confidential attributes, role hierarchy information, and even certain types of users, such as applicants.

+* On-premises Active Directory, or an external LDAP directory, is often used to enable single-credential sign-in for non-web applications and various non-Microsoft operating system sign-ins.

+## Baseline architecture challenges

+Baseline architectures often evolve over time, introducing complexity and rigidness to the design and the ability to update. Some of the challenges with using the baseline architecture include:

+* **Hard to react to new requirements**: Having a complex environment makes it hard to quickly adapt and keep up with the most recent regulations and requirements. For example, if you have apps in lots of locations, and these apps are connected in different ways with different IdMs, you have to decide where to locate multifactor authentication (MFA) services and how to enforce MFA.

+ Higher education also experiences fragmented service ownership. The people responsible for key services such as enterprise resource planning, learning management systems, division, and department solutions might resist efforts to change or modify the systems that they operate.

+* **Can't take advantage of all Microsoft 365 capabilities for all apps** (for example, Intune, Conditional Access, passwordless): Many universities want to move toward the cloud and use their existing investments in Azure AD. However, with a different federation provider as their primary IdP, universities can't take advantage of all the Microsoft 365 capabilities for the rest of their apps.

+* **Complexity of a solution**: There are many components to manage. Some components are in the cloud, and some are on-premises or in infrastructure as a service (IaaS) instances. Apps are operated in many places. From a user perspective, this experience can be disjointed. For example, users sometime see a Shibboleth sign-in page and other times see an Azure AD sign-in page.

+We present three solutions to solve these challenges, while also addressing the following requirements:

+* Ability to participate in multilateral federations such as InCommon and eduGAIN

+* Ability to support all types of apps (even apps that require legacy protocols)

+* Ability to support external directories and attribute stores

+We present the three solutions in order, from most preferred to least preferred. Each satisfies requirements but introduces tradeoff decisions that are expected in a complex architecture. Based on your requirements and starting point, select the one that best suits your environment. We also provide a decision tree to aid in this decision.

+## Next steps

+See these related articles about multilateral federation:

+[Multilateral federation introduction](multilateral-federation-introduction.md)

+[Multilateral federation Solution 1: Azure AD with Cirrus Bridge](multilateral-federation-solution-one.md)

+[Multilateral federation Solution 2: Azure AD with Shibboleth as a SAML proxy](multilateral-federation-solution-two.md)

+[Multilateral federation Solution 3: Azure AD with AD FS and Shibboleth](multilateral-federation-solution-three.md)

+[Multilateral federation decision tree](multilateral-federation-decision-tree.md)

+ Title: University multilateral federation decision tree

+description: Use this decision tree to help design a multilateral federation solution for universities.

+# Decision tree

+Use this decision tree to determine the multilateral federation solution that's best suited for your environment.

+[](media/multilateral-federation-decision-tree/tradeoff-decision-matrix.png#lightbox)

+## Migration resources

+The following resources can help with your migration to the solutions covered in this content.

+| Migration resource | Description | Relevant for migrating to... |

+| - | - | - |

+| [Resources for migrating applications to Azure Active Directory](../manage-apps/migration-resources.md) | List of resources to help you migrate application access and authentication to Azure Active Directory (Azure AD) | Solution 1, Solution 2, and Solution 3 |

+| [Azure AD custom claims provider](../develop/custom-claims-provider-overview.md)| Overview of the Azure AD custom claims provider | Solution 1 |

+| [Custom security attributes](../fundamentals/custom-security-attributes-manage.md) | Steps for managing access to custom security attributes | Solution 1 |

+| [Azure AD SSO integration with Cirrus Bridge](../saas-apps/cirrus-identity-bridge-for-azure-ad-tutorial.md) | Tutorial to integrate Cirrus Bridge with Azure AD | Solution 1 |

+| [Cirrus Bridge overview](https://blog.cirrusidentity.com/documentation/azure-bridge-setup-rev-6.0) | Cirrus Identity documentation for configuring Cirrus Bridge with Azure AD | Solution 1 |

+| [Configuring Shibboleth as a SAML proxy](https://shibboleth.atlassian.net/wiki/spaces/KB/pages/1467056889/Using+SAML+Proxying+in+the+Shibboleth+IdP+to+connect+with+Azure+AD) | Shibboleth article that describes how to use the SAML proxying feature to connect the Shibboleth identity provider (IdP) to Azure AD | Solution 2 |

+| [Azure AD Multi-Factor Authentication deployment considerations](../authentication/howto-mfa-getstarted.md) | Guidance for configuring Azure AD Multi-Factor Authentication | Solution 1 and Solution 2 |

+## Next steps

+See these related articles about multilateral federation:

+[Multilateral federation introduction](multilateral-federation-introduction.md)

+[Multilateral federation baseline design](multilateral-federation-baseline.md)

+[Multilateral federation Solution 1: Azure AD with Cirrus Bridge](multilateral-federation-solution-one.md)

+[Multilateral federation Solution 2: Azure AD with Shibboleth as a SAML proxy](multilateral-federation-solution-two.md)

+[Multilateral federation Solution 3: Azure AD with AD FS and Shibboleth](multilateral-federation-solution-three.md)

+ Title: University multilateral federation solution design

+description: Learn how to design a multilateral federation solution for universities.

+# Introduction to multilateral federation solutions

+Research universities need to collaborate with one another. To accomplish collaboration, they require multilateral federation to enable authentication and access between universities globally.

+## Challenges with multilateral federation solutions

+Universities face many challenges. For example, a university might use one identity management system and a set of protocols. Other universities might use a different set of technologies, depending on their requirements. In general, universities can:

+* Use different identity management systems.

+* Use different protocols.

+* Use customized solutions.

+* Need support for a long history of legacy functionality.

+* Need support for solutions that are built in different IT generations.

+Many universities are also adopting the Microsoft 365 suite of productivity and collaboration tools. These tools rely on Azure Active Directory (Azure AD) for identity management, which enables universities to configure:

+* Single sign-on across multiple applications.

+* Modern security controls, including passwordless authentication, multifactor authentication, adaptive Conditional Access, and identity protection.

+* Enhanced reporting and monitoring.

+Because Azure AD doesn't natively support multilateral federation, this content describes three solutions for federating authentication and access between universities with a typical research university architecture. These scenarios mention non-Microsoft products for illustrative purposes only and to represent the broader class of products. For example, this content uses Shibboleth as an example of a federation provider.

+## Next steps

+See these related articles about multilateral federation:

+[Multilateral federation baseline design](multilateral-federation-baseline.md)

+[Multilateral federation Solution 1: Azure AD with Cirrus Bridge](multilateral-federation-solution-one.md)

+[Multilateral federation Solution 2: Azure AD with Shibboleth as a SAML proxy](multilateral-federation-solution-two.md)

+[Multilateral federation Solution 3: Azure AD with AD FS and Shibboleth](multilateral-federation-solution-three.md)

+[Multilateral federation decision tree](multilateral-federation-decision-tree.md)

+ Title: 'Solution 1: Azure AD with Cirrus Bridge'

+description: This article describes design considerations for using Azure AD with Cirrus Bridge as a multilateral federation solution for universities.

+# Solution 1: Azure AD with Cirrus Bridge

+Solution 1 uses Azure Active Directory (Azure AD) as the primary identity provider (IdP) for all applications. A managed service provides multilateral federation. In this example, Cirrus Bridge is the managed service for integration of Central Authentication Service (CAS) and multilateral federation apps.

+[](media/multilateral-federation-solution-one/cirrus-bridge.png#lightbox)

+If you're also using an on-premises Active Directory instance, you can [configure Active Directory](../hybrid/whatis-hybrid-identity.md) with hybrid identities. Implementing a solution of using Azure AD with Cirrus Bridge provides:

+* **Security Assertion Markup Language (SAML) bridge**: Configure multilateral federation and participation in InCommon and eduGAIN. You can also use the SAML bridge to configure Azure AD Conditional Access policies, app assignment, governance, and other features for each multilateral federation app.

+* **CAS bridge**: Provide protocol translation to support on-premises CAS apps to authenticate with Azure AD. You can use the CAS bridge to configure Azure AD Conditional Access policies, app assignment, and governance for all CAS apps as a whole.

+When you implement Azure AD with Cirrus Bridge, you can take advantage of more capabilities in Azure AD:

+* **Custom claims provider support**: With the [Azure AD custom claims provider](../develop/custom-claims-provider-overview.md), you can use an external attribute store (like an external LDAP directory) to add claims into tokens for individual apps. The custom claims provider uses a custom extension that calls an external REST API to fetch claims from external systems.

+* **Custom security attributes**: You can add custom attributes to objects in the directory and control who can read them. [Custom security attributes](../fundamentals/custom-security-attributes-overview.md) enable you to store more of your attributes directly in Azure AD.

+## Advantages

+Here are some of the advantages of implementing Azure AD with Cirrus Bridge:

+* **Seamless cloud authentication for all apps**

+ * All apps authenticate through Azure AD.

+ * Elimination of all on-premises identity components in a managed service can potentially lower your operational and administrative costs, reduce security risks, and free up resources for other efforts.

+* **Streamlined configuration, deployment, and support model**

+ * [Cirrus Bridge](../saas-apps/cirrus-identity-bridge-for-azure-ad-tutorial.md) is registered in the Azure AD app gallery.

+ * You benefit from an established process for configuring and setting up the bridge solution.

+ * Cirrus Identity provides continuous support.

+* **Conditional Access support for multilateral federation apps**

+ * Implementation of Conditional Access controls helps you comply with [NIH](https://auth.nih.gov/CertAuthV3/forms/help/compliancecheckhelp.html) and [REFEDS](https://refeds.org/category/research-and-scholarship) requirements.

+ * This solution is the only architecture that enables you to configure granular Azure AD Conditional Access for both multilateral federation apps and CAS apps.

+* **Use of other Azure AD-related solutions for all apps**

+ * You can use Intune and Azure AD join for device management.

+ * Azure AD join enables you to use Windows Autopilot, Azure AD Multi-Factor Authentication, and passwordless features. Azure AD join supports achieving a Zero Trust posture.

+ > [!NOTE]

+ > Switching to Azure AD Multi-Factor Authentication might help you save significant costs over other solutions that you have in place.

+## Considerations and trade-offs

+Here are some of the trade-offs of using this solution:

+* **Limited ability to customize the authentication experience**: This scenario provides a managed solution. It might not offer you the flexibility or granularity to build a custom solution by using federation provider products.

+* **Limited third-party MFA integration**: The number of integrations available to third-party MFA solutions might be limited.

+* **One-time integration effort required**: To streamline integration, you need to perform a one-time migration of all student and faculty apps to Azure AD. You also need to set up Cirrus Bridge.

+* **Subscription required for Cirrus Bridge**: The subscription fee for Cirrus Bridge is based on anticipated annual authentication usage of the bridge.

+## Migration resources

+The following resources help with your migration to this solution architecture.

+| Migration resource | Description |

+| - | - |

+| [Resources for migrating applications to Azure Active Directory](../manage-apps/migration-resources.md) | List of resources to help you migrate application access and authentication to Azure AD |

+| [Azure AD custom claims provider](../develop/custom-claims-provider-overview.md)| Overview of the Azure AD custom claims provider |

+| [Custom security attributes](../fundamentals/custom-security-attributes-manage.md) | Steps for managing access to custom security attributes |

+| [Azure AD single sign-on integration with Cirrus Bridge](../saas-apps/cirrus-identity-bridge-for-azure-ad-tutorial.md) | Tutorial to integrate Cirrus Bridge with Azure AD |

+| [Cirrus Bridge overview](https://blog.cirrusidentity.com/documentation/azure-bridge-setup-rev-6.0) | Cirrus Identity documentation for configuring Cirrus Bridge with Azure AD |

+| [Azure AD Multi-Factor Authentication deployment considerations](../authentication/howto-mfa-getstarted.md) | Guidance for configuring Azure AD Multi-Factor Authentication |

+## Next steps

+See these related articles about multilateral federation:

+[Multilateral federation introduction](multilateral-federation-introduction.md)

+[Multilateral federation baseline design](multilateral-federation-baseline.md)

+[Multilateral federation Solution 2: Azure AD with Shibboleth as a SAML proxy](multilateral-federation-solution-two.md)

+[Multilateral federation Solution 3: Azure AD with AD FS and Shibboleth](multilateral-federation-solution-three.md)

+[Multilateral federation decision tree](multilateral-federation-decision-tree.md)

+ Title: 'Solution 3: Azure AD with AD FS and Shibboleth'

+description: This article describes design considerations for using Azure AD with AD FS and Shibboleth as a multilateral federation solution for universities.

+# Solution 3: Azure AD with AD FS and Shibboleth

+In Solution 3, the federation provider is the primary identity provider (IdP). In this example, Shibboleth is the federation provider for the integration of multilateral federation apps, on-premises Central Authentication Service (CAS) apps, and any Lightweight Directory Access Protocol (LDAP) directories.

+[](media/multilateral-federation-solution-three/shibboleth-adfs-azure-ad.png#lightbox)

+In this scenario, Shibboleth is the primary IdP. Participation in multilateral federations (for example, with InCommon) is done through Shibboleth, which natively supports this integration. On-premises CAS apps and the LDAP directory are also integrated with Shibboleth.

+Student apps, faculty apps, and Microsoft 365 apps are integrated with Azure Active Directory (Azure AD). Any on-premises instance of Active Directory is synced with Azure AD. Active Directory Federation Services (AD FS) provides integration with third-party multifactor authentication (MFA). AD FS performs protocol translation and enables certain Azure AD features, such as Azure AD join for device management, Windows Autopilot, and passwordless features.

+## Advantages

+Here are some of the advantages of using this solution:

+* **Customized authentication**: You can customize the experience for multilateral federation apps through Shibboleth.

+* **Ease of execution**: The solution is simple to implement in the short term for institutions that already use Shibboleth as their primary IdP. You need to migrate student and faculty apps to Azure AD and add an AD FS instance.

+* **Minimal disruption**: The solution allows third-party MFA. You can keep existing MFA solutions, such as Duo, in place until you're ready for an update.

+## Considerations and trade-offs

+Here are some of the trade-offs of using this solution:

+* **Higher complexity and security risk**: An on-premises footprint might mean higher complexity for the environment and extra security risks, compared to a managed service. Increased overhead and fees might also be associated with managing on-premises components.

+* **Suboptimal authentication experience**: For multilateral federation and CAS apps, there's no cloud-based authentication mechanism and there might be multiple redirects.

+* **No Azure AD Multi-Factor Authentication support**: This solution doesn't enable Azure AD Multi-Factor Authentication support for multilateral federation or CAS apps. You might miss potential cost savings.

+* **No granular Conditional Access support**: The lack of granular Conditional Access support limits your ability to make granular decisions.

+* **Significant ongoing staff allocation**: IT staff must maintain infrastructure and software for the authentication solution. Any staff attrition might introduce risk.

+## Migration resources

+The following resources can help with your migration to this solution architecture.

+| Migration resource | Description |

+| - | - |

+| [Resources for migrating applications to Azure Active Directory](../manage-apps/migration-resources.md) | List of resources to help you migrate application access and authentication to Azure AD |

+## Next steps

+See these related articles about multilateral federation:

+[Multilateral federation introduction](multilateral-federation-introduction.md)

+[Multilateral federation baseline design](multilateral-federation-baseline.md)

+[Multilateral federation Solution 1: Azure AD with Cirrus Bridge](multilateral-federation-solution-one.md)

+[Multilateral federation Solution 2: Azure AD with Shibboleth as a SAML proxy](multilateral-federation-solution-two.md)

+[Multilateral federation decision tree](multilateral-federation-decision-tree.md)

+ Title: 'Solution 2: Azure AD with Shibboleth as a SAML proxy'

+description: This article describes design considerations for using Azure AD with Shibboleth as a SAML proxy as a multilateral federation solution for universities.

+# Solution 2: Azure AD with Shibboleth as a SAML proxy

+In Solution 2, Azure Active Directory (Azure AD) acts as the primary identity provider (IdP). The federation provider acts as a Security Assertion Markup Language (SAML) proxy to the Central Authentication Service (CAS) apps and the multilateral federation apps. In this example, [Shibboleth acts as the SAML proxy](https://shibboleth.atlassian.net/wiki/spaces/KB/pages/1467056889/Using+SAML+Proxying+in+the+Shibboleth+IdP+to+connect+with+Azure+AD) to provide a reference link.

+[](media/multilateral-federation-solution-two/azure-ad-shibboleth-as-sp-proxy.png#lightbox)

+Because Azure AD is the primary IdP, all student and faculty apps are integrated with Azure AD. All Microsoft 365 apps are also integrated with Azure AD. If Azure Active Directory Domain Services is in use, it also is synchronized with Azure AD.

+The SAML proxy feature of Shibboleth integrates with Azure AD. In Azure AD, Shibboleth appears as a non-gallery enterprise application. Universities can get single sign-on (SSO) for their CAS apps and can participate in the InCommon environment. Additionally, Shibboleth provides integration for Lightweight Directory Access Protocol (LDAP) directory services.

+## Advantages

+Advantages of using this solution include:

+* **Cloud authentication for all apps**: All apps authenticate through Azure AD.

+* **Ease of execution**: This solution provides short-term ease of execution for universities that are already using Shibboleth.

+## Considerations and trade-offs

+Here are some of the trade-offs of using this solution:

+* **Higher complexity and security risk**: An on-premises footprint might mean higher complexity for the environment and extra security risks, compared to a managed service. Increased overhead and fees might also be associated with managing on-premises components.

+* **Suboptimal authentication experience**: For multilateral federation and CAS apps, the authentication experience for users might not be seamless because of redirects through Shibboleth. The options for customizing the authentication experience for users are limited.

+* **Limited third-party multifactor authentication (MFA) integration**: The number of integrations available to third-party MFA solutions might be limited.

+* **No granular Conditional Access support**: Without granular Conditional Access support, you have to choose between the least common denominator (optimize for less friction but have limited security controls) or the highest common denominator (optimize for security controls at the expense of user friction). Your ability to make granular decisions is limited.

+## Migration resources

+The following resources can help with your migration to this solution architecture.

+| Migration resource | Description |

+| - | - |

+| [Resources for migrating applications to Azure Active Directory](../manage-apps/migration-resources.md) | List of resources to help you migrate application access and authentication to Azure AD |

+| [Configuring Shibboleth as a SAML proxy](https://shibboleth.atlassian.net/wiki/spaces/KB/pages/1467056889/Using+SAML+Proxying+in+the+Shibboleth+IdP+to+connect+with+Azure+AD) | Shibboleth article that describes how to use the SAML proxying feature to connect the Shibboleth IdP to Azure AD |

+| [Azure AD Multi-Factor Authentication deployment considerations](../authentication/howto-mfa-getstarted.md) | Guidance for configuring Azure AD Multi-Factor Authentication |

+## Next steps

+See these related articles about multilateral federation:

+[Multilateral federation introduction](multilateral-federation-introduction.md)

+[Multilateral federation baseline design](multilateral-federation-baseline.md)

+[Multilateral federation Solution 1: Azure AD with Cirrus Bridge](multilateral-federation-solution-one.md)

+[Multilateral federation Solution 3: Azure AD with AD FS and Shibboleth](multilateral-federation-solution-three.md)

+[Multilateral federation decision tree](multilateral-federation-decision-tree.md)

+ Title: Azure Active Directory Authentication management operations reference guide

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

+tags: azuread

+# Azure Active Directory Authentication management operations reference guide

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

+> [!NOTE]

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

+## Key operational processes

+### Assign owners to key tasks

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

+| Task | Owner |

+| :- | :- |

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

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

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

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

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

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

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

+> [!NOTE]

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

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

+#### Owner recommended reading

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

+## Credentials management

+### Password policies

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

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

+| Issue | Recommendation |

+| :- | :- |

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

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

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

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

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

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

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

+#### Password policies recommended reading

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

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

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

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

+- Deflect help desk calls.

+- Replace the use of temporary passwords.

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

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

+> [!NOTE]

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

+### Strong credential management

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

+

+### On-premises outage authentication resiliency

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

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

+

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

+### Programmatic usage of credentials

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

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

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

+## Authentication experience

+### On-premises authentication

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

+### Device trust access policies

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

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

+- Blocking access from untrusted devices

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

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

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

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

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

+

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

+

+#### Device trust access policies recommended reading

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

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

+### Windows Hello for Business

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

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

+## Application authentication and assignment

+### Single sign-on for apps

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

+

+> [!NOTE]

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

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

+#### Single sign-on recommended reading

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

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

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

+

+> [!NOTE]

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

+### Assign users to applications

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

+- Delegate group management and governance to application owners.

+- Allow self-service access to the application.

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

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

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

+#### Assign users to applications recommended reading

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

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

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

+## Access policies

+### Named locations

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

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

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

+

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

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

+| | -- | -- |

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

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

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

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

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

+### Risk-based access policies

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

+

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

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

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

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

+### Client application access policies

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

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

+

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

+### Conditional Access implementation

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

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

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

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

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

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

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

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

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

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

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

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

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

+#### Conditional Access recommended reading

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

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

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

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

+## Access surface area

+### Legacy authentication

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

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

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

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

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

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

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

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

+

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

+

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

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

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

+#### Legacy authentication recommended reading

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

+### Consent grants

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

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

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

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

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

+| Resource | Permission |

+| :- | :- |

+| Exchange Online | EAS.AccessAsUser.All |

+| | EWS.AccessAsUser.All |

+| | Mail.Read |

+| Microsoft Graph API | Mail.Read |

+| | Mail.Read.Shared |

+| | Mail.ReadWrite |

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

+|Resource | Permission |

+| :- | :- |

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

+| Azure REST API | user_impersonation |

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

+#### Consent grants recommended reading

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

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

+### User and group settings

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

+#### User settings

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

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

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

+

+> [!NOTE]

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

+#### Group settings

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

+#### Groups recommended reading

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

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

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

+- [Use groups to manage access to resources in Azure Active Directory](../fundamentals/concept-learn-about-groups.md)

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

+### Traffic from unexpected locations

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

+

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

+## Access usage

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

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

+#### Logs recommended reading

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

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

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

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

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

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

+## Summary

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

+- Assign owners to key tasks.

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

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

+- Implement passwordless authentication.

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

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

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

+- Configure risk-based access policies.

+- Lock down legacy authentication protocols.

+- Detect and remediate illicit consent grants.

+- Lock down user and group settings.

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

+## Next steps

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

+ Title: Azure Active Directory governance operations reference guide

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

+tags: azuread

+# Azure Active Directory governance operations reference guide

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

+> [!NOTE]

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

+## Key operational processes

+### Assign owners to key tasks

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

+| Task | Owner |

+| :- | :- |

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

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

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

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

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

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

+| Regularly review consent grants | InfoSec Architecture Team |

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

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

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

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

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

+#### Owner recommended reading

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

+### Configuration changes testing

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

+| Scenario| Recommendation |

+|-|-|

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

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

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

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

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

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

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

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

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

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

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

+## Access reviews

+### Access reviews to applications

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

+

+> [!NOTE]

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

+### Access reviews to external identities

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

+> [!NOTE]

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

+## Privileged account management

+### Privileged account usage

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

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

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

+#### Privileged account management recommended reading

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

+### Emergency access accounts

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

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

+- Administrative staff turnover

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

+### Privileged access to Azure EA portal

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

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

+#### Privileged access recommended reading

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

+## Entitlement management

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

+> [!NOTE]

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

+## Summary

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

+- Assign owners to key tasks.

+- Implement a testing strategy.

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

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

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

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

+- Lock down access to the Azure EA portal.

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

+## Next steps

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

+ Title: Azure Active Directory Identity and access management operations reference guide

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

+tags: azuread

+# Azure Active Directory Identity and access management operations reference guide

+This section of the [Azure AD operations reference guide](ops-guide-intro.md) describes the checks and actions you should consider to secure and manage the lifecycle of identities and their assignments.

+> [!NOTE]

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

+## Key operational processes

+### Assign owners to key tasks

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

+| Task | Owner |

+| :- | :- |

+| Define the process how to create Azure subscriptions | Varies by organization |

+| Decide who gets Enterprise Mobility + Security licenses | IAM Operations Team |

+| Decide who gets Microsoft 365 licenses | Productivity Team |

+| Decide who gets other licenses, for example, Dynamics, Visual Studio Codespaces | Application Owner |

+| Assign licenses | IAM Operations Team |

+| Troubleshoot and remediate license assignment errors | IAM Operations Team |

+| Provision identities to applications in Azure AD | IAM Operations Team |

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

+#### Assigning owners recommended reading

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

+## On-premises identity synchronization

+### Identify and resolve synchronization issues

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

+### Azure AD Connect Sync configuration

+To enable all hybrid experiences, device-based security posture, and integration with Azure AD, it's required that you synchronize user accounts that your employees use to login to their desktops.

+If you don't synchronize the forest users log into, then you should change the synchronization to come from the proper forest.

+#### Synchronization scope and object filtering

+Removing known buckets of objects that aren't required to be synchronized has the following operational benefits:

+- Fewer sources of sync errors

+- Faster sync cycles

+- Less "garbage" to carry forward from on-premises, for example, pollution of the global address list for on-premises service accounts that aren't relevant in the cloud

+> [!NOTE]

+> If you find you are importing many objects that aren't being exported to the cloud, you should filter by OU or specific attributes.

+Examples of objects to exclude are:

+- Service Accounts that aren't used for cloud applications

+- Groups that aren't meant to be used in cloud scenarios such as those used to grant access to resources

+- Users or contacts that are external identities that are meant to be represented with Azure AD B2B Collaboration

+- Computer Accounts where employees aren't meant to access cloud applications from, for example, servers

+> [!NOTE]

+> If a single human identity has multiple accounts provisioned from something such as a legacy domain migration, merger, or acquisition, you should only synchronize the account used by the user on a day-to-day basis, for example, what they use to log in to their computer.

+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/how-to-connect-sync-configure-filtering.md) plus a simple attribute mapping to the cloudFiltered attribute is an effective filtering combination.

+> [!IMPORTANT]

+> If you use group filtering in production, you should transition to another filtering approach.

+#### Sync failover or disaster recovery

+Azure AD Connect plays a key role in the provisioning process. If the Sync Server goes offline for any reason, changes to on-premises can't be updated in the cloud and can result in access issues for users. Therefore, it's important to define a failover strategy that allows administrators to quickly resume synchronization after the sync server goes offline. Such strategies may fall into the following categories:

+- **Deploy Azure AD Connect Server(s) in Staging Mode** - allows an administrator to "promote" the staging server to production by a simple configuration switch.

+- **Use Virtualization** - If the Azure AD connect is deployed in a virtual machine (VM), admins can leverage their virtualization stack to live migrate or quickly redeploy the VM and therefore resume synchronization.

+If your organization is lacking a disaster recovery and failover strategy for Sync, you shouldn't hesitate to deploy Azure AD Connect in Staging Mode. Likewise, if there's a mismatch between your production and staging configuration, you should re-baseline Azure AD Connect staging mode to match the production configuration, including software versions and configurations.

+

+#### Stay current

+Microsoft updates Azure AD Connect regularly. Stay current to take advantage of the performance improvements, bug fixes, and new capabilities that each new version provides.

+If your Azure AD Connect version is more than six months behind, you should upgrade to the most recent version.

+#### Source anchor

+Using **ms-DS-consistencyguid** as the [source anchor](../hybrid/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.

+If you're currently using **ObjectGuid** as the source anchor, we recommend you switch to using **ms-DS-ConsistencyGuid**.

+#### Custom rules

+Azure AD Connect custom rules provide the ability to control the flow of attributes between on-premises objects and cloud objects. However, overusing or misusing custom rules can introduce the following risks:

+- Troubleshooting complexity

+- Degradation of performance when performing complex operations across objects

+- Higher probability of divergence of configuration between the production server and staging server

+- Additional overhead when upgrading Azure AD Connect if custom rules are created within the precedence greater than 100 (used by built-in rules)

+If you're using overly complex rules, you should investigate the reasons for the complexity and find opportunities for simplification. Likewise, if you have created custom rules with precedence value over 100, you should fix the rules so they aren't at risk or conflict with the default set.

+Examples of misusing custom rules include:

+- **Compensate for dirty data in the directory** - In this case, it's recommended to work with the owners of the AD team and clean up the data in the directory as a remediation task, and adjust processes to avoid reintroduction of bad data.

+- **One-off remediation of individual users** - It's common to find rules that special case outliers, usually because of an issue with a specific user.

+- **Overcomplicated "CloudFiltering"** - While reducing the number of objects is a good practice, there's a risk of creating and overcomplicated sync scope using many sync rules. If there's complex logic to include/exclude objects beyond the OU filtering, it's recommended to deal with this logic outside of sync and label the objects with a simple "cloudFiltered" attribute that can flow with a simple Sync Rule.

+#### Azure AD Connect configuration documenter

+The [Azure AD Connect Configuration Documenter](https://github.com/Microsoft/AADConnectConfigDocumenter) is a tool you can use to generate documentation of an Azure AD Connect installation to enable a better understanding of the sync configuration, build confidence in getting things right, and to know what was changed when you applied a new build or configuration of Azure AD Connect or added or updated custom sync rules. The current capabilities of the tool include:

+- Documentation of the complete configuration of Azure AD Connect sync.

+- Documentation of any changes in the configuration of two Azure AD Connect sync servers or changes from a given configuration baseline.

+- Generation of a PowerShell deployment script to migrate the sync rule differences or customizations from one server to another.

+## Assignment to apps and resources

+### Group-based licensing for Microsoft cloud services

+Azure Active Directory streamlines the management of licenses through [group-based licensing](../fundamentals/licensing-whatis-azure-portal.md) for Microsoft cloud services. This way, IAM provides the group infrastructure and delegated management of those groups to the proper teams in the organizations. There are multiple ways to set up the membership of groups in Azure AD, including:

+- **Synchronized from on-premises** - Groups can come from on-premises directories, which could be a good fit for organizations that have established group management processes that can be extended to assign licenses in Microsoft 365.

+- **Attribute-based / dynamic** - Groups can be created in the cloud based on an expression based on user attributes, for example, Department equals "sales". Azure AD maintains the members of the group, keeping it consistent with the expression defined. Using this kind of group for license assignment enables an attribute-based license assignment, which is a good fit for organizations that have high data quality in their directory.

+- **Delegated ownership** - Groups can be created in the cloud and can be designated owners. This way, you can empower business owners, for example, Collaboration team or BI team, to define who should have access.

+If you're currently using a manual process to assign licenses and components to users, we recommend you implement group-based licensing. If your current process doesn't monitor licensing errors or what is Assigned versus Available, you should define improvements to the process to address licensing errors and monitor licensing assignment.

+Another aspect of license management is the definition of service plans (components of the license) that should be enabled based on job functions in the organization. Granting access to service plans that aren't necessary, can result in users seeing tools in the Office portal that they haven't been trained for or shouldn't be using. It can drive additional help desk volume, unnecessary provisioning, and put your compliance and governance at risk, for example, when provisioning OneDrive for Business to individuals that might not be allowed to share content.

+Use the following guidelines to define service plans to users:

+- Administrators should define "bundles" of service plans to be offered to users based on their role, for instance, white-collar worker versus floor worker.

+- Create groups by cluster and assign the license with service plan.

+- Optionally, an attribute can be defined to hold the packages for users.

+> [!IMPORTANT]

+> Group-based licensing in Azure AD introduces the concept of users in a licensing error state. If you notice any licensing errors, then you should immediately [identify and resolve](../enterprise-users/licensing-groups-resolve-problems.md) any license assignment problems.

+

+#### Lifecycle management

+If you're currently using a tool, such as [Microsoft Identity Manager](/microsoft-identity-manager/) or third-party system, that relies on an on-premises infrastructure, we recommend you offload assignment from the existing tool, implement group-based licensing and define a group lifecycle management based on [groups](../enterprise-users/licensing-group-advanced.md#use-group-based-licensing-with-dynamic-groups). Likewise, if your existing process doesn't account for new employees or employees that leave the organization, you should deploy group-based licensing based on dynamic groups and define a group membership lifecycle. Finally, if group-based licensing is deployed against on-premises groups that lack lifecycle management, consider using cloud groups to enable capabilities such as delegated ownership or attribute-based dynamic membership.

+### Assignment of apps with "All users" group

+Resource owners may believe that the **All users** group contains only **Enterprise Employees** when they may actually contain both **Enterprise Employees** and **Guests**. As a result, you should take special care when using the **All users** group for application assignment and granting access to resources such as SharePoint content or applications.

+> [!IMPORTANT]

+> If the **All users** group is enabled and used for conditional access policies, app or resource assignment, make sure to [secure the group](../external-identities/use-dynamic-groups.md) if you don't want it to include guest users. Furthermore, you should fix your licensing assignments by creating and assigning to groups that contain **Enterprise Employees** only. On the other hand, if you find that the **All users** group is enabled but not being used to grant access to resources, make sure your organization's operational guidance is to intentionally use that group (which includes both **Enterprise Employees** and **Guests**).

+### Automated user provisioning to apps

+[Automated user provisioning](../app-provisioning/user-provisioning.md) to applications is the best way to create a consistent provisioning, deprovisioning, and lifecycle of identities across multiple systems.

+If you're currently provisioning apps in an ad-hoc manner or using things like CSV files, JIT, or an on-premises solution that doesn't address lifecycle management, we recommend you [implement application provisioning](../app-provisioning/user-provisioning.md#how-do-i-set-up-automatic-provisioning-to-an-application) with Azure AD for supported applications and define a consistent pattern for applications that aren't yet supported by Azure AD.

+

+### Azure AD Connect delta sync cycle baseline

+It's important to understand the volume of changes in your organization and make sure that it isn't taking too long to have a predictable synchronization time.

+The [default delta sync](../hybrid/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/plan-connect-performance-factors.md).

+#### Azure AD Connect troubleshooting recommended reading

+- [Prepare directory attributes for synchronization with Microsoft 365 by using the IdFix tool](/office365/enterprise/prepare-directory-attributes-for-synch-with-idfix)

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

+## Summary

+There are five aspects to a secure Identity infrastructure. This list will help you quickly find and take the necessary actions to secure and manage the lifecycle of identities and their entitlements in your organization.

+- Assign owners to key tasks.

+- Find and resolve synchronization issues.

+- Define a failover strategy for disaster recovery.

+- Streamline the management of licenses and assignment of apps.

+- Automate user provisioning to apps.

+## Next steps

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

+ Title: Azure Active Directory operations reference guide

+description: This operations reference guide describes the checks and actions you should take to secure and maintain identity and access management, authentication, governance, and operations

+tags: azuread

+# Azure Active Directory operations reference guide

+This operations reference guide describes the checks and actions you should take to secure and maintain the following areas:

+- **[Identity and access management](ops-guide-iam.md)** - ability to manage the lifecycle of identities and their entitlements.

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

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

+- **[Operations](ops-guide-ops.md)** - optimize the operations Azure Active Directory (Azure AD).

+Some recommendations here might not be applicable to all customers' environment, for example, AD FS best practices might not apply if your organization uses password hash sync.

+> [!NOTE]

+> These recommendations are current as of the date of publishing but can change over time. Organizations should continuously evaluate their identity practices as Microsoft products and services evolve over time. Recommendations can change when organizations subscribe to a different Azure AD Premium license.

+## Stakeholders

+Each section in this reference guide recommends assigning stakeholders to plan and implement key tasks successfully. The following table outlines the list of all the stakeholders in this guide:

+| Stakeholder | Description |

+| :- | :- |

+| IAM Operations Team | This team handles managing the day to day operations of the Identity and Access Management system |

+| Productivity Team | This team owns and manages the productivity applications such as email, file sharing and collaboration, instant messaging, and conferencing. |

+| Application Owner | This team owns the specific application from a business and usually a technical perspective in an organization. |

+| InfoSec Architecture Team | This team plans and designs the Information Security practices of an organization. |

+| InfoSec Operations Team | This team runs and monitors the implemented Information Security practices of the InfoSec Architecture team. |

+## Next steps

+Get started with the [Identity and access management checks and actions](ops-guide-iam.md).

+ Title: Azure Active Directory general operations guide reference

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

+tags: azuread

+# Azure Active Directory general operations guide reference

+This section of the [Azure AD operations reference guide](ops-guide-intro.md) describes the checks and actions you should take to optimize the general operations of Azure Active Directory (Azure AD).

+> [!NOTE]

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

+## Key operational processes

+### Assign owners to key tasks

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

+| Task | Owner |

+| :- | :- |

+| Drive Improvements on Identity Secure Score | InfoSec Operations Team |

+| Maintain Azure AD Connect Servers | IAM Operations Team |

+| Regularly execute and triage IdFix Reports | IAM Operations Team |

+| Triage Azure AD Connect Health Alerts for Sync and AD FS | IAM Operations Team |

+| If not using Azure AD Connect Health, then customer has equivalent process and tools to monitor custom infrastructure | IAM Operations Team |

+| If not using AD FS, then customer has equivalent process and tools to monitor custom infrastructure | IAM Operations Team |

+| Monitor Hybrid Logs: Azure AD App Proxy Connectors | IAM Operations Team |

+| Monitor Hybrid Logs: Passthrough Authentication Agents | IAM Operations Team |

+| Monitor Hybrid Logs: Password Writeback Service | IAM Operations Team |

+| Monitor Hybrid Logs: On-premises password protection gateway | IAM Operations Team |

+| Monitor Hybrid Logs: Azure AD MFA NPS Extension (if applicable) | IAM Operations Team |

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

+#### Owners recommended reading

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

+## Hybrid management

+### Recent versions of on-premises components

+Having the most up-to-date versions of on-premises components provides the customer all the latest security updates, performance improvements and functionality that could help to further simplify the environment. Most components have an automatic upgrade setting, which will automate the upgrade process.

+These components include:

+- Azure AD Connect

+- Azure AD Application Proxy Connectors

+- Azure AD Pass-through authentication agents

+- Azure AD Connect Health Agents

+Unless one has been established, you should define a process to upgrade these components and rely on the automatic upgrade feature whenever possible. If you find components that are six or more months behind, you should upgrade as soon as possible.

+#### Hybrid management recommended reading

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

+- [Understand Azure AD Application Proxy connectors | Automatic updates](../app-proxy/application-proxy-connectors.md#automatic-updates)

+### Azure AD Connect Health alert baseline

+Organizations should deploy [Azure AD Connect Health](../hybrid/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.

+

+As you monitor the health of your environment, you must immediately address any high severity alerts, followed by lower severity alerts.

+#### Azure AD Connect Health recommended reading

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

+### On-premises agents logs

+Some identity and access management services require on-premises agents to enable hybrid scenarios. Examples include password reset, pass-through authentication (PTA), Azure AD Application Proxy, and Azure AD MFA NPS extension. It's key that the operations team baseline and monitor the health of these components by archiving and analyzing the component agent logs using solutions such as System Center Operations Manager or SIEM. It's equally important your Infosec Operations team or help desk understand how to troubleshoot patterns of errors.

+#### On-premises agents logs recommended reading

+- [Troubleshoot Application Proxy](../app-proxy/application-proxy-troubleshoot.md)

+- [Self-service password reset troubleshooting](../authentication/troubleshoot-sspr.md)

+- [Understand Azure AD Application Proxy connectors](../app-proxy/application-proxy-connectors.md)

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

+- [Troubleshoot error codes for the Azure AD MFA NPS extension](../authentication/howto-mfa-nps-extension-errors.md)

+### On-premises agents management

+Adopting best practices can help the optimal operation of on-premises agents. Consider the following best practices:

+- Multiple Azure AD Application proxy connectors per connector group are recommended to provide seamless load balancing and high availability by avoiding single points of failure when accessing the proxy applications. If you presently have only one connector in a connector group that handles applications in production, you should deploy at least two connectors for redundancy.

+- Creating and using an app proxy connector group for debugging purposes can be useful for troubleshooting scenarios and when onboarding new on-premises applications. We also recommend installing networking tools such as Message Analyzer and Fiddler in the connector machines.

+- Multiple pass-through authentication agents are recommended to provide seamless load balancing and high availability by avoiding single point of failure during the authentication flow. Be sure to deploy at least two pass-through authentication agents for redundancy.

+#### On-premises agents management recommended reading

+- [Understand Azure AD Application Proxy connectors](../app-proxy/application-proxy-connectors.md)

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

+## Management at scale

+### Identity secure score

+The [identity secure score](./../fundamentals/identity-secure-score.md) provides a quantifiable measure of the security posture of your organization. It's key to constantly review and address findings reported and strive to have the highest score possible. The score helps you to:

+- Objectively measure your identity security posture

+- Plan identity security improvements

+- Review the success of your improvements

+

+If your organization currently has no program in place to monitor changes in Identity Secure Score, it is recommended you implement a plan and assign owners to monitor and drive improvement actions. Organizations should remediate improvement actions with a score impact higher than 30 as soon as possible.

+### Notifications

+Microsoft sends email communications to administrators to notify various changes in the service, configuration updates that are needed, and errors that require admin intervention. It's important that customers set the notification email addresses so that notifications are sent to the proper team members who can acknowledge and act upon all notifications. We recommend you add multiple recipients to the [Message Center](/office365/admin/manage/message-center) and request that notifications (including Azure AD Connect Health notifications) be sent to a distribution list or shared mailbox. If you only have one Global Administrator account with an email address, be sure to configure at least two email-capable accounts.

+There are two "From" addresses used by Azure AD: <o365mc@email2.microsoft.com>, which sends Message Center notifications; and <azure-noreply@microsoft.com>, which sends notifications related to:

+- [Azure AD Access Reviews](../governance/access-reviews-overview.md)

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

+- [Azure AD Identity Protection](../identity-protection/howto-identity-protection-configure-notifications.md)

+- [Azure AD Privileged Identity Management](../privileged-identity-management/pim-email-notifications.md)

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

+- Enterprise App Provisioning Service Notifications

+Refer to the following table to learn the type of notifications that are sent and where to check for them:

+| Notification source | What is sent | Where to check |

+|:-|:-|:-|

+| Technical contact | Sync errors | Azure portal - properties blade |

+| Message Center | Incident and degradation notices of Identity Services and Microsoft 365 backend services | Office Portal |

+| Identity Protection Weekly Digest | Identity Protection Digest | Azure AD Identity Protection blade |

+| Azure AD Connect Health | Alert notifications | Azure portal - Azure AD Connect Health blade |

+| Enterprise Applications Notifications | Notifications when certificates are about to expire and provisioning errors | Azure portal - Enterprise Application blade (each app has its own email address setting) |

+#### Notifications recommended reading

+- [Change your organization's address, technical contact, and more](/office365/admin/manage/change-address-contact-and-more)

+## Operational surface area

+### AD FS lockdown

+Organizations, which configure applications to authenticate directly to Azure AD benefit from [Azure AD smart lockout](../authentication/concept-sspr-howitworks.md). If you use AD FS in Windows Server 2012 R2, implement AD FS [extranet lockout protection](/windows-server/identity/ad-fs/operations/configure-ad-fs-extranet-soft-lockout-protection). If you use AD FS on Windows Server 2016 or later, implement [extranet smart lockout](https://support.microsoft.com/help/4096478/extranet-smart-lockout-feature-in-windows-server-2016). At a minimum, we recommend you enable extranet lockout to contain the risk of brute force attacks against on-premises Active Directory. However, if you have AD FS in Windows 2016 or higher, you should also enable extranet smart lockout that will help to mitigate [password spray](https://www.microsoft.com/microsoft-365/blog/2018/03/05/azure-ad-and-adfs-best-practices-defending-against-password-spray-attacks/) attacks.

+If AD FS is only used for Azure AD federation, there are some endpoints that can be turned off to minimize the attack surface area. For example, if AD FS is only used for Azure AD, you should disable WS-Trust endpoints other than the endpoints enabled for **usernamemixed** and **windowstransport**.

+### Access to machines with on-premises identity components

+Organizations should lock down access to the machines with on-premises hybrid components in the same way as your on-premises domain. For example, a backup operator or Hyper-V administrator shouldn't be able to sign in to the Azure AD Connect Server to change rules.

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

+

+The [tier model](/windows-server/identity/securing-privileged-access/securing-privileged-access-reference-material) is composed of three levels and only includes administrative accounts, not standard user accounts.

+- **Tier 0** - Direct Control of enterprise identities in the environment. Tier 0 includes accounts, groups, and other assets that have direct or indirect administrative control of the Active Directory forest, domains, or domain controllers, and all the assets in it. The security sensitivity of all Tier 0 assets is equivalent as they're all effectively in control of each other.

+- **Tier 1** - Control of enterprise servers and applications. Tier 1 assets include server operating systems, cloud services, and enterprise applications. Tier 1 administrator accounts have administrative control of a significant amount of business value that is hosted on these assets. A common example role is server administrators who maintain these operating systems with the ability to impact all enterprise services.

+- **Tier 2** - Control of user workstations and devices. Tier 2 administrator accounts have administrative control of a significant amount of business value that is hosted on user workstations and devices. Examples include Help Desk and computer support administrators because they can impact the integrity of almost any user data.

+Lock down access to on-premises identity components such as Azure AD Connect, AD FS, and SQL services the same way as you do for domain controllers.

+## Summary

+There are seven aspects to a secure Identity infrastructure. This list will help you find the actions you should take to optimize the operations for Azure Active Directory (Azure AD).

+- Assign owners to key tasks.

+- Automate the upgrade process for on-premises hybrid components.

+- Deploy Azure AD Connect Health for monitoring and reporting of Azure AD Connect and AD FS.

+- Monitor the health of on-premises hybrid components by archiving and analyzing the component agent logs using System Center Operations Manager or a SIEM solution.

+- Implement security improvements by measuring your security posture with Identity Secure Score.

+- Lock down AD FS.

+- Lock down access to machines with on-premises identity components.

+## Next steps

+Refer to the [Azure AD deployment plans](deployment-plans.md) for implementation details on any capabilities you haven't deployed.

+ Title: 'Parallel and combined identity infrastructure options'

+description: This article describes the various options available for organizations to run multiple tenants and multicloud scenarios

+ na

+# Parallel and combined identity infrastructure options

+Microsoft delivers a range of technologies and solutions to integrate between their different on-premises and cloud components of their identity infrastructure. Often customers are unclear on which technologies are most right and may incorrectly think "the most recent release covers all scenarios of earlier technology releases."

+This article covers scenarios when your company is going through a complex scenario outlined below and looking to combine your identity information. Ideally, an organization with a single HR source, a single Active Directory forest, and a single Azure Active Directory (Azure AD) tenant, all integrated with the same people in each, will have the best identity experience for their Microsoft Online Services. However, in practice, an enterprise customer may not always be in a situation where that is possible. For example, the customer may be going through a merger, or have a need for isolation for some users or applications. A customer who has multiple HR, multiple AD, or multiple Azure AD tenants must decide on whether to combine to fewer instances of each or keep them in parallel.

+Based on our customer feedback, the following are some of the common scenarios and requirements.

+## Scenarios that come up for multicloud and multi-org identities

+- Mergers and acquisitions (M&A) ΓÇô refers to a situation where, usually Company A buys Company B.

+- Rebranding ΓÇô A company name or brand change and typically an e-mail domain name change.

+- Azure AD or Office 365 tenant consolidation - Companies with more than one Office 365 tenant may want to combine because of compliance or historic requirements.

+- Active Directory Domain or forest consolidation - Companies evaluating to perform Active Directory domain or forest consolidation.

+- Divestitures ΓÇô Where a division or business group of a company is sold or becomes independent.

+- User information privacy ΓÇô Where companies have requirements to keep certain data (attributes) from not being publicly visible and only right delegated groups or users can read, change, and update it.

+## Requirements that stem out from these scenarios

+- Bring all users' and groups' data to a single place, including email and status availability for meeting scheduling by creating a central or **universal directory**.

+- Maintain a **single username and credentials** while reducing the need to enter usernames and passwords across all applications by implementing Single Sign On.

+- Streamline user on-boarding so it doesn't take weeks or months.

+- Prepare the organization for future acquisitions and access management demands.

+- Enable and improve cross-company collaboration and productivity.

+- Reduce the likelihood of a security breach or data exfiltration with security policies deployed centrally and consistently!

+## Scenarios not covered in this article

+- Partial M&A. For example, an organization buys part of another organization.

+- Divesture or splitting organizations

+- Renaming organizations.

+- Joint ventures or temporary partners

+This article outlines various multicloud or multi-org identity environments including M&A scenarios that Microsoft supports today and outline how an organization might select the right technologies depending upon how they approach consolidation.

+## Consolidation options for a hypothetical M&A scenario

+The following sections cover four main scenarios for a hypothetical M&A scenario:

+Suppose Contoso is an enterprise customer, and their IT has a single (on-premises) HR system, single Active Directory forest, single tenant Azure AD for their apps, running as expected. Users are brought in from their HR system into Active Directory and projected into Azure AD and from there into SaaS apps. This scenario is illustrated with the diagram below, with the arrows showing the flow of identity information. The same model is also applicable to customers with cloud HR system such as Workday or SuccessFactors provisioning Active Directory, not just customers using Microsoft Identity Manager (MIM).

+

+

+Next, Contoso has begun to merge with Litware, which has previously been running their own IT independently. Contoso IT will handle the merger and expects that Contoso's IT will continue to have Contoso's apps remain unchanged, but they want to be able to have Litware's users receive access to them and collaborate within those apps. For Microsoft apps, third-party SaaS, and custom apps, the end state should be that Contoso and Litware users conceptually have access to the same data.

+The first IT decision is how much they wish to combine infrastructure. They could choose to not rely upon any of Litware's identity infrastructure. Or they could consider using Litware's infrastructure and converging over time while minimizing disruption to Litware's environment. In some cases, the customer may wish to keep Litware's existing identity infrastructure independent and not converging it, while still using it to give Litware employee access to Contoso apps.

+If the customer chooses to keep some or all Litware's identity infrastructure, then there are tradeoffs on how much of Litware's Active Directory Domain Services or Azure AD are used to give Litware users access to Contoso resources. This section looks at workable options, based on what Contoso would use for Litware's users:

+- Scenario A - Don't use *any* of Litware's identity infrastructure.

+- Scenario B - Use Litware's Active Directory forests, but not Litware's Azure AD (if they've one)

+- Scenario C - Use Litware's Azure AD.

+- Scenario D - Use Litware's non-Microsoft identity infrastructure (if Litware isn't using Active Directory/Azure AD)

+The following table summarizes each option with the technologies for how the customer could achieve those outcomes, the constraints, and benefits of each.

+| Considerations | A1: Single HR, single IAM & tenant | A2: Separate HR, single IAM, and tenant | B3: Active Directory forest trust, single Azure AD Connect | B4: Azure AD Connect their Active Directory to the single tenant | B5: Azure AD Connect cloud sync their Active Directory | C6: parallel provision multiple tenants into apps | C7: read from their tenant and B2B invite their users | C8: single IAM and B2B users as needed | D9: DF with their non-Azure AD IDP |

+|:-|:-|:-|:-|:-|:-|:-|:-|:-|:-|

+| Migration effort | High | Medium effort | Lower effort | Low effort | Low effort | None | None | None | None |

+| Deployment effort | Less effort | Medium effort | Medium effort | Medium effort | Low | Low | High | High | Very High |

+| End-user impact during migration | High | High | Medium | Medium | Medium | None | None | None | None |

+| Operating effort | Low cost | Low cost | Low cost | Low cost | Low cost | High | High | High | Very High |

+| Privacy and data capabilities (geo location/data boundaries) | None (Major roadblock for geo-location scenarios) | Limited isolation even though challenging | Limited isolation on-prem but not on the cloud | Limited isolation on-prem but not on the cloud | Limited isolation on-prem but not on the cloud | Good isolation both on-prem and on the cloud | Limited isolation both on-prem and cloud | Limited isolation both on-prem and cloud | Isolation both on-prem and on the cloud |

+| Isolation (separate delegation and setup different admin models) Note: as defined in source system (HR) | Not possible | Possible | Possible | Possible | Possible | Highly Possible | Highly possible | Highly possible | Possible |

+| Collaboration capabilities | Excellent | Excellent | Excellent | Excellent | Excellent | Poor | Average | Average | Poor |

+| IT admin model supported (centralized vs. separated) | Centralized | Centralized | Centralized | Centralized | Centralized | Decentralized | Decentralized | Decentralized | Actively Decentralized |

+| Limitations | No isolation | Limited isolation | Limited isolation | Limited isolation | Limited isolation. No writeback capabilities | Won't work for Microsoft Online Services apps. Highly dependent on app capability | Requires apps to be B2B aware | Requires apps to be B2B aware | Require apps to be B2B aware. Uncertainty in how it all works together |

+Table details

+- The employee effort tries to predict the required expertise and extra work required to implement the solution in an organization.

+- Operating effort tries to predict the cost and effort it takes to keep the solution running.

+- Privacy and data capabilities show if the solution allows support for geo location and data boundaries.

+- Isolation shows if this solution supplies the ability to separate or delegate admin models.

+- Collaboration capabilities show the level of collaboration the solution supports, more integrated solutions supply higher fidelity of teamwork.

+- The IT admin model shows if the admin model requires to centralized or can be decentralized.

+- Limitations: any issues of challenges worth listing.

+### Decision tree

+Use the following decision tree to help you decide which scenario would work best for your organization.

+[](media/parallel-identity-options/identity-decision-tree.png#lightbox)

+The rest of this document, will outline four scenarios A-D with various options supporting them.

+## Scenario A - If Contoso doesn't wish to rely upon Litware's existing identity infrastructure

+For this option, Litware may not have any identity systems (for example, a small business), or the customer may wish to turn off Litware's infrastructure. Or they wish to leave it untouched, for use by Litware employees to authenticate to Litware's apps but give Litware employees new identities as part of Contoso. For example, if Alice Smith was a Litware employee, she might have two identities ΓÇô Alice@litware.com and ASmith123@contoso.com. Those identities would be entirely distinct from each other.

+### Option 1 - Combine into a single HR system

+Typically, customers would bring the Litware employees into the Contoso HR system. This option would trigger those employees to receive accounts and the right access to Contoso's directories and apps. A Litware user would then have a new Contoso identity, which they could use to request access to the right Contoso apps.

+### Option 2 - Keep Litware HR system

+Sometimes converging the HR systems may not be possible, at least not in the short term. Instead, the customer would connect their provisioning system, for example, MIM, to read from *both* HR systems. In this diagram, the top HR is the existing Contoso environment, and the second HR is Litware's addition to the overall infrastructure.

+

+The same scenario would also be possible using Azure AD Workday or SuccessFactors inbound ΓÇô Contoso could bring in users from Litware's Workday HR source alongside existing Contoso employees.

+### Outcomes of consolidating all identity infrastructure

+- Reduced IT infrastructure, only one identity system to manage, no network connectivity requirements except for an HR system.

+- Consistent end user and administrative experience

+### Constraints of consolidating all identity infrastructure

+- Any data that is needed by Contoso employees that originated in Litware must be migrated to the Contoso environment.

+- Any Active Directory or Azure AD-integrated apps from Litware that will be needed for Contoso must be reconfigured to the Contoso environment. This reconfiguration may require changes to the configuration, which groups it uses for access, or potentially to the apps themselves.

+## Scenario B - If Contoso wishes to keep Litware's Active Directory forests, but not use Litware's Azure AD

+Litware may have many existing Active Directory-based apps that they rely on, and so Contoso may wish to continue to have Litware employees keep their own identities in their existing AD. A Litware employee would then use their existing identity for their authentication of their existing resources and authentication of Contoso resources. In this scenario, Litware doesn't have any cloud identities in Microsoft Online Services ΓÇô either Litware wasn't an Azure AD customer, nothing of Litware's cloud assets were to be shared with Contoso, or Contoso migrated Litware's cloud assets to be part of Contoso's tenant.

+### Option 3 - Forest trust with the acquired forest

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

+

+### Outcome of setting up a forest trust

+- All Litware employees can authenticate Contoso's Active Directory or Azure AD-integrated apps, and Contoso can use current AD-based tools to manage authorization.

+### Constraints of setting up a forest trust

+- Requires TCP/IP connectivity between users who are domain joined to one forest and resources joined to the other forest.

+- Requires the Active Directory-based apps in the Contoso forest to be multi-forest-aware

+### Option 4 - Configure Azure AD Connect to the acquired forest without forest trust

+A customer can also configure Azure AD Connect to read from another forest. This configuration enables the Litware users to authenticate to Contoso's Azure AD integrated apps but doesn't supply access to Contoso's Active Directory integrated apps to the Litware user ΓÇô those Contoso apps don't recognize Litware users. This deployment topology requires TCP/IP network connectivity between Azure AD Connect and Litware's domain controllers. For example, if Azure AD Connect is on a Contoso IaaS VM, they would need to establish a tunnel also to Litware's network as well.

+

+### Outcome of using Azure AD Connect to provision one tenant

+- All Litware employees can authenticate Contoso's Azure AD integrated apps.

+### Constraints of using Azure AD Connect to provision one tenant

+- Requires TCP/IP connectivity between Contoso's Azure AD Connect and Litware's Active Directory domains.

+- Doesn't permit Litware users to have access to Contoso's Active Directory based applications

+### Option 5 - Deploy Azure AD Connect cloud sync in the acquired forest

+[Azure AD Connect cloud provisioning](../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.

+

+### Outcome of deploying Azure AD Connect cloud sync in the acquired forest

+- All Litware employees can authenticate Contoso's Azure AD-integrated apps.

+### Constraints of using Azure AD Connect cloud sync in the acquired forest

+- Doesn't permit Litware users to have access to Contoso's AD-based applications

+## Scenario C - If Contoso wants to keep Litware's Azure AD

+Litware may be a Microsoft Online Services or Azure customer or may have one or more Azure AD-based apps that they rely on. So, Contoso may want to continue to have Litware employees keep their own identities for access to those resources. A Litware employee would then use their existing identity for their authentication of their existing resources and authentication of Contoso resources.

+This scenario is suitable in cases where:

+- Litware has an extensive Azure or Microsoft Online Services investment including multiple Office 365 tenants that would be costly or time consuming to migrate to another tenant.

+- Litware may be spun out in future or is a partnership that will run independently.

+- Litware doesn't have on-premises infrastructure

+### Option 6 - Maintain parallel provisioning and SSO for apps in each Azure AD

+One option is for each Azure AD to independently provide SSO and [provision](../app-provisioning/user-provisioning.md) users from their directory into the target app. For example, if Contoso IT are using an app such as Salesforce, they would provide Litware with administrative rights to create users in the same Salesforce subscription.

+

+### Outcome of parallel provisioning

+- Users can authenticate apps using their existing identity, without making changes to Contoso's infrastructure.

+### Constraints of parallel provisioning

+- If using federation, it requires applications to support multiple federation providers for the same subscription.

+- Not possible for Microsoft apps such as Office or Azure

+- Contoso doesn't have visibility in their Azure AD of application access for Litware users

+### Option 7 - Configure B2B accounts for users from the acquired tenant

+If Litware has been running its own tenant, then Contoso can read the users from that tenant, and through the B2B API, invite each of those users into the Contoso tenant. (This bulk invite process can be done through the [MIM graph connector](/microsoft-identity-manager/microsoft-identity-manager-2016-connector-graph), for example.) If Contoso also has AD-based apps that they wish to make available to Litware users, then MIM could also create users in Active Directory that would map to the UPNs of Azure AD users, so that the app proxy could perform KCD on behalf of a representation of a Litware user in Contoso's Active Directory.

+Then when a Litware employee wishes to access a Contoso app, they can do so by authenticating to their own directory, with access assignment to the resource tenant.

+

+### Outcome of setting up B2B accounts for users from the other tenant

+- Litware users can authenticate Contoso apps, and Contoso controls that access in their tenant.

+### Constraints of setting up B2B accounts for users from the other tenant

+- It requires a duplicate account for each Litware user who requires access to Contoso resources.

+- Requires the apps to be B2B capable for SSO.

+### Option 8 - Configure B2B but with a common HR feed for both directories

+In some situations, after acquisition the organization may converge on a single HR platform, but still run existing identity management systems. In this scenario, MIM could provision users into multiple Active Directory systems, depending on which part of the organization the user is affiliated with. They could continue to use B2B so that users authenticate their existing directory, and have a unified GAL.

+

+### Outcome of setting up B2B guest users from a common HR system feed

+- Litware users can authenticate to Contoso apps, and Contoso control that access in their tenant.

+- Litware and Contoso have a unified GAL.

+- No change to Litware's Active Directory or Azure AD

+### Constraints of setting up B2B guest users from a common HR system feed

+- Requires changes to Contoso's provisioning to also send users to Litware's Active Directory, and connectivity between Litware's domains and Contoso's domains.

+- Requires the apps to be B2B capable for SSO.

+## Scenario D - If Litware is using non-Active Directory infrastructure

+Finally, if Litware is using another directory service, either on-premises or in the cloud, then Contoso IT can still configure that Litware employees authenticate and can get access to Contoso's resources using their existing identity.

+### Option 9 - Use B2B direct federation (public preview)

+In this scenario, Litware is assumed to have:

+- Some existing directories, such as OpenLDAP or even an SQL database or flat file of users with their email addresses that they can regularly share with Contoso.

+- An identity provider that supports SAML, such as PingFederate or OKTA.

+- A publicly routed DNS domain such as Litware.com and users with email addresses in that domain

+In this approach, Contoso would configure a [direct federation](../external-identities/direct-federation.md) relationship from their tenant for that domain to Litware's identity provider, and then regularly read updates to Litware users from their directory to invite the Litware users into Contoso's Azure AD. This update can be done with a MIM Graph connector. If Contoso also has Active Directory-based apps that they wish to make available to Litware users, then MIM could also create users in Active Directory that would map to the UPNs of Azure AD users, so that the app proxy could perform KCD on behalf of a representation of a Litware user in Contoso's Active Directory.

+

+### Outcome of using B2B direct federation

+- Litware users authenticate to Contoso's Azure AD with their existing identity provider and access Contoso's cloud and on-premises web apps,

+### Constraints of using B2B direct federation

+- Require the Contoso apps to able to support B2B user SSO.

+## Next steps

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

+- [Setup Inbound provisioning for Azure AD](../app-provisioning/plan-cloud-hr-provision.md)

+- [Setup B2B direct federation](../external-identities/direct-federation.md)

+- [Multi-tenant user management options](multi-tenant-user-management-introduction.md)

+- [What is application provisioning?](../app-provisioning/user-provisioning.md)

+ Title: Protecting Microsoft 365 from on-premises attacks

+description: Learn how to configure your systems to help protect your Microsoft 365 cloud environment from on-premises compromise.

+ - it-pro

+ - seodec18

+ - kr2b-contr-experiment

+

+# Protecting Microsoft 365 from on-premises attacks

+Many customers connect their private corporate networks to Microsoft 365 to benefit their users, devices, and applications. However, these private networks can be compromised in many well-documented ways. Microsoft 365 acts as a sort of nervous system for many organizations. It's critical to protect it from compromised on-premises infrastructure.

+This article shows you how to configure your systems to help protect your Microsoft 365 cloud environment from on-premises compromise, including the following elements:

+- Azure Active Directory (Azure AD) tenant configuration settings

+- How Azure AD tenants can be safely connected to on-premises systems

+- The tradeoffs required to operate your systems in ways that protect your cloud systems from on-premises compromise

+Microsoft strongly recommends that you implement this guidance.

+## Threat sources in on-premises environments

+Your Microsoft 365 cloud environment benefits from an extensive monitoring and security infrastructure. Microsoft 365 uses machine learning and human intelligence to look across worldwide traffic. It can rapidly detect attacks and allow you to reconfigure nearly in real time.

+Hybrid deployments can connect on-premises infrastructure to Microsoft 365. In such deployments, many organizations delegate trust to on-premises components for critical authentication and directory object state management decisions. If the on-premises environment is compromised, these trust relationships become an attacker's opportunities to compromise your Microsoft 365 environment.

+The two primary threat vectors are *federation trust relationships* and *account synchronization.* Both vectors can grant an attacker administrative access to your cloud.

+- **Federated trust relationships**, such as Security Assertions Markup Language (SAML) authentication, are used to authenticate to Microsoft 365 through your on-premises identity infrastructure. If a SAML token-signing certificate is compromised, federation allows anyone who has that certificate to impersonate any user in your cloud.

+ We recommend that you disable federation trust relationships for authentication to Microsoft 365 when possible.

+- **Account synchronization** can be used to modify privileged users, including their credentials, or groups that have administrative privileges in Microsoft 365.

+ We recommend that you ensure that synchronized objects hold no privileges beyond a user in Microsoft 365. You can control privileges either directly or through inclusion in trusted roles or groups. Ensure these objects have no direct or nested assignment in trusted cloud roles or groups.

+## Protecting Microsoft 365 from on-premises compromise

+To address the threats described above, we recommend you adhere to the principles illustrated in the following diagram:

+

+1. **Fully isolate your Microsoft 365 administrator accounts.** They should be:

+ - Mastered in Azure AD.

+ - Authenticated by using multifactor authentication.

+ - Secured by Azure AD Conditional Access.

+ - Accessed only by using Azure-managed workstations.

+ These administrator accounts are restricted-use accounts. No on-premises accounts should have administrative privileges in Microsoft 365.

+ For more information, see [About admin roles](/microsoft-365/admin/add-users/about-admin-roles). Also, see [Roles for Microsoft 365 in Azure AD](../roles/m365-workload-docs.md).

+1. **Manage devices from Microsoft 365.** Use Azure AD join and cloud-based mobile device management (MDM) to eliminate dependencies on your on-premises device management infrastructure. These dependencies can compromise device and security controls.

+1. **Ensure no on-premises account has elevated privileges to Microsoft 365.** Some accounts access on-premises applications that require NTLM, LDAP, or Kerberos authentication. These accounts must be in the organization's on-premises identity infrastructure. Ensure that these accounts, including service accounts, aren't included in privileged cloud roles or groups. Also ensure that changes to these accounts can't affect the integrity of your cloud environment. Privileged on-premises software must not be capable of affecting Microsoft 365 privileged accounts or roles.

+1. **Use Azure AD cloud authentication to eliminate dependencies on your on-premises credentials.** Always use strong authentication, such as Windows Hello, FIDO, Microsoft Authenticator, or Azure AD multifactor authentication.

+## Specific security recommendations

+The following sections provide guidance about how to implement the principles described above.

+### Isolate privileged identities

+In Azure AD, users who have privileged roles, such as administrators, are the root of trust to build and manage the rest of the environment. Implement the following practices to minimize the effects of a compromise.

+- Use cloud-only accounts for Azure AD and Microsoft 365 privileged roles.

+- Deploy privileged access devices for privileged access to manage Microsoft 365 and Azure AD. See [Device roles and profiles](/security/compass/privileged-access-devices#device-roles-and-profiles).

+ Deploy Azure AD Privileged Identity Management (PIM) for just-in-time access to all human accounts that have privileged roles. Require strong authentication to activate roles. See [What is Azure AD Privileged Identity Management](../privileged-identity-management/pim-configure.md).

+- Provide administrative roles that allow the least privilege necessary to do required tasks. See [Least privileged roles by task in Azure Active Directory](../roles/delegate-by-task.md).

+- To enable a rich role assignment experience that includes delegation and multiple roles at the same time, consider using Azure AD security groups or Microsoft 365 Groups. These groups are collectively called *cloud groups*.

+ Also, enable role-based access control. See [Assign Azure AD roles to groups](../roles/groups-assign-role.md). You can use administrative units to restrict the scope of roles to a portion of the organization. See [Administrative units in Azure Active Directory](../roles/administrative-units.md).

+- Deploy emergency access accounts. Do *not* use on-premises password vaults to store credentials. See [Manage emergency access accounts in Azure AD](../roles/security-emergency-access.md).

+For more information, see [Securing privileged access](/security/compass/overview). Also, see [Secure access practices for administrators in Azure AD](../roles/security-planning.md).

+### Use cloud authentication

+Credentials are a primary attack vector. Implement the following practices to make credentials more secure:

+- **Deploy passwordless authentication**. Reduce the use of passwords as much as possible by deploying passwordless credentials. These credentials are managed and validated natively in the cloud. For more information, see [Plan a passwordless authentication deployment in Azure Active Directory](../authentication/howto-authentication-passwordless-deployment.md).

+ Choose from these authentication methods:

+ - [Windows Hello for business](/windows/security/identity-protection/hello-for-business/passwordless-strategy)

+ - [The Microsoft Authenticator app](../authentication/howto-authentication-passwordless-phone.md)

+ - [FIDO2 security keys](../authentication/howto-authentication-passwordless-security-key-windows.md)

+- **Deploy multifactor authentication**. For more information, see [Plan an Azure Active Directory Multi-Factor Authentication deployment](../authentication/howto-mfa-getstarted.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](../fundamentals/resilience-in-credentials.md) and [Create a resilient access control management strategy by using Azure AD](./resilience-overview.md).

+### Limitations and tradeoffs

+Hybrid account password management requires hybrid components such as password protection agents and password writeback agents. If your on-premises infrastructure is compromised, attackers can control the machines on which these agents reside. This vulnerability won't compromise your cloud infrastructure. But your cloud accounts won't protect these components from on-premises compromise.

+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/how-to-connect-password-hash-synchronization.md) option to force password changes.

+## Provision user access from the cloud

+*Provisioning* refers to the creation of user accounts and groups in applications or identity providers.

+

+We recommend the following provisioning methods:

+- **Provision from cloud HR apps to Azure AD.** This provisioning enables an on-premises compromise to be isolated. This isolation doesn't disrupt your joiner-mover-leaver cycle from your cloud HR apps to Azure AD.

+- **Cloud applications.** Where possible, deploy Azure AD app provisioning as opposed to on-premises provisioning solutions. This method protects some of your software as a service (SaaS) apps from malicious hacker profiles in on-premises breaches. For more information, see [What is app provisioning in Azure Active Directory](../app-provisioning/user-provisioning.md).

+- **External identities.** Use Azure AD B2B collaboration to reduce the dependency on on-premises accounts for external collaboration with partners, customers, and suppliers. Carefully evaluate any direct federation with other identity providers. For more information, see [B2B collaboration overview](../external-identities/what-is-b2b.md).

+ We recommend limiting B2B guest accounts in the following ways:

+ - Limit guest access to browsing groups and other properties in the directory. Use the external collaboration settings to restrict guests' ability to read groups they're not members of.

+ - Block access to the Azure portal. You can make rare necessary exceptions. Create a Conditional Access policy that includes all guests and external users. Then implement a policy to block access. See [Conditional Access](../conditional-access/concept-conditional-access-cloud-apps.md).

+- **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](../cloud-sync/what-is-cloud-sync.md).

+### Limitations and tradeoffs

+When used to provision hybrid accounts, the Azure-AD-from-cloud-HR system relies on on-premises synchronization to complete the data flow from Active Directory to Azure AD. If synchronization is interrupted, new employee records won't be available in Azure AD.

+## Use cloud groups for collaboration and access

+Cloud groups allow you to decouple your collaboration and access from your on-premises infrastructure.

+- **Collaboration**. Use Microsoft 365 Groups and Microsoft Teams for modern collaboration. Decommission on-premises distribution lists, and [upgrade distribution lists to Microsoft 365 Groups in Outlook](/office365/admin/manage/upgrade-distribution-lists).

+- **Access**. Use Azure AD security groups or Microsoft 365 Groups to authorize access to applications in Azure AD.

+- **Office 365 licensing**. Use group-based licensing to provision to Office 365 by using cloud-only groups. This method decouples control of group membership from on-premises infrastructure.

+Owners of groups that are used for access should be considered privileged identities to avoid membership takeover in an on-premises compromise. A takeover would include direct manipulation of group membership on-premises or manipulation of on-premises attributes that can affect dynamic group membership in Microsoft 365.

+## Manage devices from the cloud

+Use Azure AD capabilities to securely manage devices.

+Deploy Azure AD joined Windows 10 workstations with mobile device management policies. Enable Windows Autopilot for a fully automated provisioning experience. See [Plan your Azure AD join implementation](../devices/device-join-plan.md) and [Windows Autopilot](/mem/autopilot/windows-autopilot).

+- **Use Windows 10 workstations**.

+ - Deprecate machines that run Windows 8.1 and earlier.

+ - Don't deploy computers that have server operating systems as workstations.

+- **Use Microsoft Intune as the authority for all device management workloads.** See [Microsoft Intune](https://www.microsoft.com/security/business/endpoint-management/microsoft-intune).

+- **Deploy privileged access devices.** For more information, see [Device roles and profiles](/security/compass/privileged-access-devices#device-roles-and-profiles).

+### Workloads, applications, and resources

+- **On-premises single-sign-on (SSO) systems**

+ Deprecate any on-premises federation and web access management infrastructure. Configure applications to use Azure AD.

+- **SaaS and line-of-business (LOB) applications that support modern authentication protocols**

+ Use Azure AD for SSO. The more apps you configure to use Azure AD for authentication, the less risk in an on-premises compromise. For more information, see [What is single sign-on in Azure Active Directory](../manage-apps/what-is-single-sign-on.md).

+- **Legacy applications**

+ You can enable authentication, authorization, and remote access to legacy applications that don't support modern authentication. Use [Azure AD Application Proxy](../app-proxy/application-proxy.md). Or, enable them through a network or application delivery controller solution by using secure hybrid access partner integrations. See [Secure legacy apps with Azure Active Directory](../manage-apps/secure-hybrid-access.md).

+ Choose a VPN vendor that supports modern authentication. Integrate its authentication with Azure AD. In an on-premises compromise, you can use Azure AD to disable or block access by disabling the VPN.

+- **Application and workload servers**

+ Applications or resources that required servers can be migrated to Azure infrastructure as a service (IaaS). Use Azure AD Domain Services (Azure AD DS) to decouple trust and dependency on on-premises instances of Active Directory. To achieve this decoupling, make sure virtual networks used for Azure AD DS don't have a connection to corporate networks. See [Azure AD Domain Services](../../active-directory-domain-services/overview.md).

+ Use credential tiering. Application servers are typically considered tier-1 assets. For more information, see [Enterprise access model](/security/compass/privileged-access-access-model#ADATM_BM).

+## Conditional Access policies

+Use Azure AD Conditional Access to interpret signals and use them to make authentication decisions. For more information, see the [Conditional Access deployment plan](../conditional-access/plan-conditional-access.md).

+- Use Conditional Access to block legacy authentication protocols whenever possible. Additionally, disable legacy authentication protocols at the application level by using an application-specific configuration. See [Block legacy authentication](../conditional-access/howto-conditional-access-policy-block-legacy.md).

+ For more information, see [Legacy authentication protocols](../fundamentals/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).

+- Implement the recommended identity and device access configurations. See [Common Zero Trust identity and device access policies](/microsoft-365/security/office-365-security/identity-access-policies).

+- If you're using a version of Azure AD that doesn't include Conditional Access, use [Security defaults in Azure AD](../fundamentals/concept-fundamentals-security-defaults.md).

+ For more information about Azure AD feature licensing, see the [Azure AD pricing guide](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing).

+## Monitor

+After you configure your environment to protect your Microsoft 365 from an on-premises compromise, proactively monitor the environment. For more information, see [What is Azure Active Directory monitoring](../reports-monitoring/overview-monitoring.md).

+### Scenarios to monitor

+Monitor the following key scenarios, in addition to any scenarios specific to your organization. For example, you should proactively monitor access to your business-critical applications and resources.

+- **Suspicious activity**

+ Monitor all Azure AD risk events for suspicious activity. See [How To: Investigate risk](../identity-protection/howto-identity-protection-investigate-risk.md). Azure AD Identity Protection is natively integrated with [Microsoft Defender for Identity](/defender-for-identity/what-is).

+ Define network named locations to avoid noisy detections on location-based signals. See [Using the location condition in a Conditional Access policy](../conditional-access/location-condition.md).

+- **User and Entity Behavioral Analytics (UEBA) alerts**

+ Use UEBA to get insights on anomaly detection. Microsoft Defender for Cloud Apps provides UEBA in the cloud. See [Investigate risky users](/cloud-app-security/tutorial-ueba).

+ You can integrate on-premises UEBA from Azure Advanced Threat Protection (ATP). Microsoft Defender for Cloud Apps reads signals from Azure AD Identity Protection. See [Connect to your Active Directory Forest](/defender-for-identity/install-step2).

+- **Emergency access accounts activity**

+ Monitor any access that uses emergency access accounts. See [Manage emergency access accounts in Azure AD](../roles/security-emergency-access.md). Create alerts for investigations. This monitoring must include the following actions:

+ - Sign-ins

+ - Credential management

+ - Any updates on group memberships

+ - Application assignments

+- **Privileged role activity**

+ Configure and review security alerts generated by Azure AD Privileged Identity Management (PIM). Monitor direct assignment of privileged roles outside PIM by generating alerts whenever a user is assigned directly. See [Security alerts](../privileged-identity-management/pim-how-to-configure-security-alerts.md?tabs=new#security-alerts).

+- **Azure AD tenant-wide configurations**

+ Any change to tenant-wide configurations should generate alerts in the system. These changes include but aren't limited to the following changes:

+ - Updated custom domains

+ - Azure AD B2B changes to allowlists and blocklists

+ - Azure AD B2B changes to allowed identity providers, such as SAML identity providers through direct federation or social sign-ins

+ - Conditional Access or Risk policy changes

+- **Application and service principal objects**

+ - New applications or service principals that might require Conditional Access policies

+ - Credentials added to service principals

+ - Application consent activity

+- **Custom roles**

+ - Updates to the custom role definitions

+ - Newly created custom roles

+### Log management

+Define a log storage and retention strategy, design, and implementation to facilitate a consistent tool set. For example, you could consider security information and event management (SIEM) systems like Microsoft Sentinel, common queries, and investigation and forensics playbooks.

+- **Azure AD logs**. Ingest generated logs and signals by consistently following best practices for settings such as diagnostics, log retention, and SIEM ingestion.

+ The log strategy must include the following Azure AD logs:

+ - Sign-in activity

+ - Audit logs

+ - Risk events

+ Azure AD provides Azure Monitor integration for the sign-in activity log and audit logs. See [Azure AD activity logs in Azure Monitor](../reports-monitoring/concept-activity-logs-azure-monitor.md).

+ Use the Microsoft Graph API to ingest risk events. See [Use the Microsoft Graph identity protection APIs](/graph/api/resources/identityprotection-root).

+ You can stream Azure AD logs to Azure Monitor logs. See [Integrate Azure AD logs with Azure Monitor logs](../reports-monitoring/howto-integrate-activity-logs-with-log-analytics.md).

+- **Hybrid infrastructure operating system security logs**. All hybrid identity infrastructure operating system logs should be archived and carefully monitored as a tier-0 system, because of the surface-area implications. Include the following elements:

+ - Application Proxy agents

+ - Password writeback agents

+ - Password Protection Gateway machines

+ - Network policy servers (NPSs) that have the Azure AD multifactor authentication RADIUS extension

+ - Azure AD Connect

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

+## Next steps

+- [Build resilience into identity and access management by using Azure AD](resilience-overview.md)

+- [Secure external access to resources](secure-external-access-resources.md)

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

+ Title: Recover from deletions in Azure Active Directory

+description: Learn how to recover from unintended deletions.

+# Recover from deletions

+This article addresses recovering from soft and hard deletions in your Azure Active Directory (Azure AD) tenant. If you haven't already done so, read [Recoverability best practices](recoverability-overview.md) for foundational knowledge.

+## Monitor for deletions

+The [Azure AD Audit log](../reports-monitoring/concept-audit-logs.md) contains information on all delete operations performed in your tenant. Export these logs to a security information and event management tool such as [Microsoft Sentinel](../../sentinel/overview.md).

+You can also use Microsoft Graph to audit changes and build a custom solution to monitor differences over time. For more information on how to find deleted items by using Microsoft Graph, see [List deleted items - Microsoft Graph v1.0](/graph/api/directory-deleteditems-list?tabs=http).

+### Audit log

+The Audit log always records a "Delete \<object\>" event when an object in the tenant is removed from an active state by either a soft or hard deletion.

+[](./media/recoverability/delete-audit-log.png#lightbox)

+A delete event for applications, users, and Microsoft 365 Groups is a soft delete. For any other object type, it's a hard delete. Track the occurrence of hard-delete events by comparing "Delete \<object\>" events with the type of object that was deleted. Note the events that don't support soft delete. Also note "Hard Delete \<object\>" events.

+| Object type | Activity in log| Result |

+| - | - | - |

+| Application| Delete application| Soft deleted |

+| Application| Hard delete application| Hard deleted |

+| User| Delete user| Soft deleted |

+| User| Hard delete user| Hard deleted |

+| Microsoft 365 Group| Delete group| Soft deleted |

+| Microsoft 365 Group| Hard delete group| Hard deleted |

+| All other objects| Delete "objectType"| Hard deleted |

+> [!NOTE]

+> The Audit log doesn't distinguish the group type of a deleted group. Only Microsoft 365 Groups are soft deleted. If you see a Delete group entry, it might be the soft delete of a Microsoft 365 Group or the hard delete of another type of group.

+>

+>*It's important that your documentation of your known good state includes the group type for each group in your organization*. To learn more about documenting your known good state, see [Recoverability best practices](recoverability-overview.md).

+### Monitor support tickets

+A sudden increase in support tickets about access to a specific object might indicate that a deletion occurred. Because some objects have dependencies, deletion of a group used to access an application, an application itself, or a Conditional Access policy that targets an application can all cause broad sudden impact. If you see a trend like this, check to ensure that none of the objects required for access were deleted.

+## Soft deletions

+When objects such as users, Microsoft 365 Groups, or application registrations are soft deleted, they enter a suspended state in which they aren't available for use by other services. In this state, items retain their properties and can be restored for 30 days. After 30 days, objects in the soft-deleted state are permanently, or hard, deleted.

+> [!NOTE]

+> Objects can't be restored from a hard-deleted state. They must be re-created and reconfigured.

+### When soft deletes occur

+It's important to understand why object deletions occur in your environment so that you can prepare for them. This section outlines frequent scenarios for soft deletion by object class. You might see scenarios that are unique to your organization, so a discovery process is key to preparation.

+### Users

+Users enter the soft-delete state anytime the user object is deleted by using the Azure portal, Microsoft Graph, or PowerShell.

+The most frequent scenarios for user deletion are:

+* An administrator intentionally deletes a user in the Azure portal in response to a request or as part of routine user maintenance.

+* An automation script in Microsoft Graph or PowerShell triggers the deletion. For example, you might have a script that removes users who haven't signed in for a specified time.

+* A user is moved out of scope for synchronization with Azure AD Connect.

+* A user is removed from an HR system and is deprovisioned via an automated workflow.

+### Microsoft 365 Groups

+The most frequent scenarios for Microsoft 365 Groups being deleted are:

+* An administrator intentionally deletes the group, for example, in response to a support request.

+* An automation script in Microsoft Graph or PowerShell triggers the deletion. For example, you might have a script that deletes groups that haven't been accessed or attested to by the group owner for a specified time.

+* Unintentional deletion of a group owned by non-admins.

+### Application objects and service principals

+The most frequent scenarios for application deletion are:

+* An administrator intentionally deletes the application, for example, in response to a support request.

+* An automation script in Microsoft Graph or PowerShell triggers the deletion. For example, you might want a process for deleting abandoned applications that are no longer used or managed. In general, create an offboarding process for applications rather than scripting to avoid unintentional deletions.

+When you delete an application, the application registration by default enters the soft-delete state. To understand the relationship between application registrations and service principals, see [Apps and service principals in Azure AD - Microsoft identity platform](../develop/app-objects-and-service-principals.md).

+### Administrative units

+The most common scenario for deletions is when administrative units (AU) are deleted by accident, although still needed.

+## Recover from soft deletion

+You can restore soft-deleted items in the administrative portal, or by using Microsoft Graph. Not all object classes can manage soft-delete capabilities in the portal, some are only listed, viewed, hard deleted, or restored using the deletedItems Microsoft Graph API.

+### Properties maintained with soft delete

+|Object type|Important properties maintained|

+|||

+|Users (including external users)|All properties maintained, including ObjectID, group memberships, roles, licenses, and application assignments|

+|Microsoft 365 Groups|All properties maintained, including ObjectID, group memberships, licenses, and application assignments|

+|Application registration | All properties maintained. See more information after this table.|

+|Service principal|All properties maintained|

+|Administrative unit (AU)|All properties maintained|

+### Users

+You can see soft-deleted users in the Azure portal on the **Users | Deleted users** page.

+

+For more information on how to restore users, see the following documentation:

+* To restore from the Azure portal, see [Restore or permanently remove recently deleted user](../fundamentals/users-restore.md).

+* To restore by using Microsoft Graph, see [Restore deleted item ΓÇô Microsoft Graph v1.0](/graph/api/directory-deleteditems-restore?tabs=http).

+### Groups

+You can see soft-deleted Microsoft 365 Groups in the Azure portal on the **Groups | Deleted groups** page.

+

+For more information on how to restore soft-deleted Microsoft 365 Groups, see the following documentation:

+* To restore from the Azure portal, see [Restore a deleted Microsoft 365 Group](../enterprise-users/groups-restore-deleted.md).

+* To restore by using Microsoft Graph, see [Restore deleted item ΓÇô Microsoft Graph v1.0](/graph/api/directory-deleteditems-restore?tabs=http).

+### Applications and service principals

+Applications have two objects: the application registration and the service principal. For more information on the differences between the registration and the service principal, see [Apps and service principals in Azure AD](../develop/app-objects-and-service-principals.md).

+To restore an application from the Azure portal, select **App registrations** > **Deleted applications**. Select the application registration to restore, and then select **Restore app registration**.

+[](./media/recoverability/deletion-restore-application.png#lightbox)

+Currently, service principals can be listed, viewed, hard deleted, or restored via the deletedItems Microsoft Graph API. To restore applications using Microsoft Graph, see [Restore deleted item - Microsoft Graph v1.0.](/graph/api/directory-deleteditems-restore?tabs=http).

+### Administrative units

+AUs can be listed, viewed, or restored via the deletedItems Microsoft Graph API. To restore AUs using Microsoft Graph, see [Restore deleted item - Microsoft Graph v1.0.](/graph/api/directory-deleteditems-restore?tabs=http). Once an AU is deleted it remains in a soft deleted state and can be restored for 30 days, but cannot be hard deleted during that time. Soft deleted AUs are hard deleted automatically after 30 days.

+## Hard deletions

+A hard deletion is the permanent removal of an object from your Azure AD tenant. Objects that don't support soft delete are removed in this way. Similarly, soft-deleted objects are hard deleted after a deletion time of 30 days. The only object types that support a soft delete are:

+* Users

+* Microsoft 365 Groups

+* Application registration

+* Service principal

+* Administrative unit

+> [!IMPORTANT]

+> All other item types are hard deleted. When an item is hard deleted, it can't be restored. It must be re-created. Neither administrators nor Microsoft can restore hard-deleted items. Prepare for this situation by ensuring that you have processes and documentation to minimize potential disruption from a hard delete.

+>

+> For information on how to prepare for and document current states, see [Recoverability best practices](recoverability-overview.md).

+### When hard deletes usually occur

+Hard deletes might occur in the following circumstances.

+Moving from soft to hard delete:

+* A soft-deleted object wasn't restored within 30 days.

+* An administrator intentionally deletes an object in the soft delete state.

+Directly hard deleted:

+* The object type that was deleted doesn't support soft delete.

+* An administrator chooses to permanently delete an item by using the portal, which typically occurs in response to a request.

+* An automation script triggers the deletion of the object by using Microsoft Graph or PowerShell. Use of an automation script to clean up stale objects isn't uncommon. A robust off-boarding process for objects in your tenant helps you to avoid mistakes that might result in mass deletion of critical objects.

+## Recover from hard deletion

+Hard-deleted items must be re-created and reconfigured. It's best to avoid unwanted hard deletions.

+### Review soft-deleted objects

+Ensure you have a process to frequently review items in the soft-delete state and restore them if appropriate. To do so, you should:

+* Frequently [list deleted items](/graph/api/directory-deleteditems-list?tabs=http).

+* Ensure that you have specific criteria for what should be restored.

+* Ensure that you have specific roles or users assigned to evaluate and restore items as appropriate.

+* Develop and test a continuity management plan. For more information, see [Considerations for your Enterprise Business Continuity Management Plan](/compliance/assurance/assurance-developing-your-ebcm-plan).

+For more information on how to avoid unwanted deletions, see the following articles in [Recoverability best practices](recoverability-overview.md):

+* Business continuity and disaster planning

+* Document known good states

+* Monitoring and data retention

+ Title: Recover from misconfigurations in Azure Active Directory

+description: Learn how to recover from misconfigurations.

+# Recover from misconfiguration

+Configuration settings in Azure Active Directory (Azure AD) can affect any resource in the Azure AD tenant through targeted or tenant-wide management actions.

+## What is configuration?

+Configurations are any changes in Azure AD that alter the behavior or capabilities of an Azure AD service or feature. For example, when you configure a Conditional Access policy, you alter who can access the targeted applications and under what circumstances.

+You need to understand the configuration items that are important to your organization. The following configurations have a high impact on your security posture.

+### Tenant-wide configurations

+* **External identities**: Global administrators for the tenant identify and control the external identities that can be provisioned in the tenant. They determine:

+ * Whether to allow external identities in the tenant.

+ * From which domains external identities can be added.

+ * Whether users can invite users from other tenants.

+* **Named locations**: Global administrators can create named locations, which can then be used to:

+ * Block sign-ins from specific locations.

+ * Trigger Conditional Access policies like multifactor authentication.

+* **Allowed authentication methods**: Global administrators set the authentication methods allowed for the tenant.

+* **Self-service options**: Global administrators set self-service options like self-service password reset and create Office 365 groups at the tenant level.

+The implementation of some tenant-wide configurations can be scoped, provided they aren't overridden by global administration policies. For example:

+* If the tenant is configured to allow external identities, a resource administrator can still exclude those identities from accessing a resource.

+* If the tenant is configured to allow personal device registration, a resource administrator can exclude those devices from accessing specific resources.

+* If named locations are configured, a resource administrator can configure policies that either allow or exclude access from those locations.

+### Conditional Access configurations

+Conditional Access policies are access control configurations that bring together signals to make decisions and enforce organizational policies.

+

+To learn more about Conditional Access policies, see [What is Conditional Access in Azure Active Directory?](../conditional-access/overview.md).

+> [!NOTE]

+> While configuration alters the behavior or capabilities of an object or policy, not all changes to an object are configuration. You can change the data or attributes associated with an item, like changing a user's address, without affecting the capabilities of that user object.

+## What is misconfiguration?

+Misconfiguration is a configuration of a resource or policy that diverges from your organizational policies or plans and causes unintended or unwanted consequences.

+A misconfiguration of tenant-wide settings or Conditional Access policies can seriously affect your security and the public image of your organization by:

+* Changing how administrators, tenant users, and external users interact with resources in your tenant:

+ * Unnecessarily limiting access to resources.

+ * Loosening access controls on sensitive resources.

+* Changing the ability of your users to interact with other tenants and external users to interact with your tenant.

+* Causing denial of service, for example, by not allowing customers to access their accounts.

+* Breaking dependencies among data, systems, and applications resulting in business process failures.

+### When does misconfiguration occur?

+Misconfiguration is most likely to occur when:

+* A mistake is made during ad-hoc changes.

+* A mistake is made as a result of troubleshooting exercises.

+* An action was carried out with malicious intent by a bad actor.

+## Prevent misconfiguration

+It's critical that alterations to the intended configuration of an Azure AD tenant are subject to robust change management processes, including:

+* Documenting the change, including prior state and intended post-change state.

+* Using Privileged Identity Management (PIM) to ensure that administrators with intent to change must deliberately escalate their privileges to do so. To learn more about PIM, see [What is Privileged Identity Management?](../privileged-identity-management/pim-configure.md).

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

+## Monitor for configuration changes

+While you want to prevent misconfiguration, you can't set the bar for changes so high that it affects the ability of administrators to perform their work efficiently.

+Closely monitor for configuration changes by watching for the following operations in your [Azure AD Audit log](../reports-monitoring/concept-audit-logs.md):

+* Add

+* Create

+* Update

+* Set

+* Delete

+The following table includes informative entries in the Audit log you can look for.

+### Conditional Access and authentication method configuration changes

+Conditional Access policies are created on the **Conditional Access** page in the Azure portal. Changes to policies are made on the **Conditional Access policy details** page for the policy.

+| Service filter| Activities| Potential impacts |

+| - | - | - |

+| Conditional Access| Add, update, or delete Conditional Access policy| User access is granted or blocked when it shouldnΓÇÖt be. |

+| Conditional Access| Add, update, or delete named location| Network locations consumed by the Conditional Access policy aren't configured as intended, which creates gaps in Conditional Access policy conditions. |

+| Authentication method| Update authentication methods policy| Users can use weaker authentication methods or are blocked from a method they should use. |

+### User and password reset configuration changes

+User settings changes are made on the Azure portal **User settings** page. Password reset changes are made on the **Password reset** page. Changes made on these pages are captured in the Audit log as detailed in the following table.

+| Service filter| Activities| Potential impacts |

+| - | - | - |

+| Core directory| Update company settings| Users might or might not be able to register applications, contrary to intent. |

+| Core directory| Set company information| Users might or might not be able to access the Azure AD administration portal, contrary to intent. <br>Sign-in pages don't represent the company brand, with potential damage to reputation. |

+| Core directory| **Activity**: Updated service principal<br>**Target**: 0365 LinkedIn connection| Users might or might not be able to connect their Azure AD account with LinkedIn, contrary to intent. |

+| Self-service group management| Update MyApps feature value| Users might or might not be able to use user features, contrary to intent. |

+| Self-service group management| Update ConvergedUXV2 feature value| Users might or might not be able to use user features, contrary to intent. |

+| Self-service group management| Update MyStaff feature value| Users might or might not be able to use user features, contrary to intent. |

+| Core directory| **Activity**: Update service principal<br>**Target**: Microsoft password reset service| Users are able or unable to reset their password, contrary to intent. <br>Users are required or not required to register for self-service password reset, contrary to intent.<br> Users can reset their password by using methods that are unapproved, for example, by using security questions. |

+### External identities configuration changes

+You can make changes to these settings on the **External identities** or **External collaboration** settings pages in the Azure portal.

+| Service filter| Activities| Potential impacts |

+| - | - | - |

+| Core directory| Add, update, or delete a partner to cross-tenant access setting| Users have outbound access to tenants that should be blocked.<br>Users from external tenants who should be blocked have inbound access. |

+| B2C| Create or delete identity provider| Identity providers for users who should be able to collaborate are missing, blocking access for those users. |

+| Core directory| Set directory feature on tenant| External users have greater or less visibility of directory objects than intended.<br>External users might or might not invite other external users to your tenant, contrary to intent. |

+| Core directory| Set federation settings on domain| External user invitations might or might not be sent to users in other tenants, contrary to intent. |

+| AuthorizationPolicy| Update authorization policy| External user invitations might or might not be sent to users in other tenants, contrary to intent. |

+| Core directory| Update policy| External user invitations might or might not be sent to users in other tenants, contrary to intent. |

+### Custom role and mobility definition configuration changes

+| Service filter| Activities/portal| Potential impacts |

+| - |- | -|

+| Core directory| Add role definition| Custom role scope is narrower or broader than intended. |

+| PIM| Update role setting| Custom role scope is narrower or broader than intended. |

+| Core directory| Update role definition| Custom role scope is narrower or broader than intended. |

+| Core directory| Delete role definition| Custom roles are missing. |

+| Core directory| Add delegated permission grant| Mobile device management or mobile application management configuration is missing or misconfigured, which leads to the failure of device or application management. |

+### Audit log detail view

+Selecting some audit entries in the Audit log will provide you with details on the old and new configuration values. For example, for Conditional Access policy configuration changes, you can see the information in the following screenshot.

+

+## Use workbooks to track changes

+Azure Monitor workbooks can help you monitor configuration changes.

+The [Sensitive operations report workbook](../reports-monitoring/workbook-sensitive-operations-report.md) can help identify suspicious application and service principal activity that might indicate a compromise, including:

+* Modified application or service principal credentials or authentication methods.

+* New permissions granted to service principals.

+* Directory role and group membership updates for service principals.

+* Modified federation settings.

+The [Cross-tenant access activity workbook](../reports-monitoring/workbook-cross-tenant-access-activity.md) can help you monitor which applications in external tenants your users are accessing and which applications your tenant external users are accessing. Use this workbook to look for anomalous changes in either inbound or outbound application access across tenants.

+## Next steps

+- For foundational information on recoverability, see [Recoverability best practices](recoverability-overview.md).

+- For information on recovering from deletions, see [Recover from deletions](recover-from-deletions.md).

+ Title: Recoverability best practices in Azure Active Directory

+description: Learn the best practices for increasing recoverability.

+# Recoverability best practices

+Unintended deletions and misconfigurations will happen to your tenant. To minimize the impact of these unintended events, you must prepare for their occurrence.

+Recoverability is the preparatory processes and functionality that enable you to return your services to a prior functioning state after an unintended change. Unintended changes include the soft or hard deletion or misconfiguration of applications, groups, users, policies, and other objects in your Azure Active Directory (Azure AD) tenant.

+Recoverability helps your organization be more resilient. Resilience, while related, is different. Resilience is the ability to endure disruption to system components and recover with minimal impact to your business, users, customers, and operations. For more information about how to make your systems more resilient, see [Building resilience into identity and access management with Azure Active Directory](resilience-overview.md).

+This article describes the best practices in preparing for deletions and misconfigurations to minimize the unintended consequences to your organization's business.

+## Deletions and misconfigurations

+Deletions and misconfigurations have different impacts on your tenant.

+### Deletions

+The impact of deletions depends on the object type.

+Users, Microsoft 365 Groups, and applications can be soft deleted. Soft-deleted items are sent to the Azure AD recycle bin. While in the recycle bin, items aren't available for use. However, they retain all their properties and can be restored via a Microsoft Graph API call or in the Azure portal. Items in the soft-delete state that aren't restored within 30 days are permanently, or hard, deleted.

+

+> [!IMPORTANT]

+> All other object types are hard deleted immediately when they're selected for deletion. When an object is hard deleted, it can't be recovered. It must be re-created and reconfigured.

+>

+>For more information on deletions and how to recover from them, see [Recover from deletions](recover-from-deletions.md).

+### Misconfigurations

+Misconfigurations are configurations of a resource or policy that diverge from your organizational policies or plans and cause unintended or unwanted consequences. Misconfiguration of tenant-wide settings or Conditional Access policies can seriously affect your security and the public image of your organization. Misconfigurations can:

+* Change how administrators, tenant users, and external users interact with resources in your tenant.

+* Change the ability of your users to interact with other tenants and external users to interact with your tenant.

+* Cause denial of service.

+* Break dependencies among data, systems, and applications.

+For more information on misconfigurations and how to recover from them, see [Recover from misconfigurations](recover-from-misconfigurations.md).

+## Shared responsibility

+Recoverability is a shared responsibility between Microsoft as your cloud service provider and your organization.

+

+You can use the tools and services that Microsoft provides to prepare for deletions and misconfigurations.

+## Business continuity and disaster planning

+Restoring a hard-deleted or misconfigured item is a resource-intensive process. You can minimize the resources needed by planning ahead. Consider having a specific team of admins in charge of restorations.

+### Test your restoration process

+Rehearse your restoration process for different object types and the communication that will go out as a result. Be sure to rehearse with test objects, ideally in a test tenant.

+Testing your plan can help you determine the:

+- Validity and completeness of your object state documentation.

+- Typical time to resolution.

+- Appropriate communications and their audiences.

+- Expected successes and potential challenges.

+### Create the communication process

+Create a process of predefined communications to make others aware of the issue and timelines for restoration. Include the following points in your restoration communication plan:

+- The types of communications to go out. Consider creating predefined templates.

+- Stakeholders to receive communications. Include the following groups, as applicable:

+ - Affected business owners.

+ - Operational admins who will perform recovery.

+ - Business and technical approvers.

+ - Affected users.

+- Define the events that trigger communications, such as:

+ - Initial deletion.

+ - Impact assessment.

+ - Time to resolution.

+ - Restoration.

+## Document known good states

+Document the state of your tenant and its objects regularly. Then if a hard delete or misconfiguration occurs, you have a roadmap to recovery. The following tools can help you document your current state:

+- [Microsoft Graph APIs](/graph/overview) can be used to export the current state of many Azure AD configurations.

+- [Azure AD Exporter](https://github.com/microsoft/azureadexporter) is a tool you can use to export your configuration settings.

+- [Microsoft 365 Desired State Configuration](https://github.com/microsoft/Microsoft365DSC/wiki/What-is-Microsoft365DSC) is a module of the PowerShell Desired State Configuration framework. You can use it to export configurations for reference and application of the prior state of many settings.

+- [Conditional Access APIs](https://github.com/Azure-Samples/azure-ad-conditional-access-apis) can be used to manage your Conditional Access policies as code.

+### Commonly used Microsoft Graph APIs

+You can use Microsoft Graph APIs to export the current state of many Azure AD configurations. The APIs cover most scenarios where reference material about the prior state, or the ability to apply that state from an exported copy, could become vital to keeping your business running.

+Microsoft Graph APIs are highly customizable based on your organizational needs. To implement a solution for backups or reference material requires developers to engineer code to query for, store, and display the data. Many implementations use online code repositories as part of this functionality.

+### Useful APIs for recovery

+| Resource types| Reference links |

+| - | - |

+| Users, groups, and other directory objects| [directoryObject API](/graph/api/resources/directoryObject) |

+| Directory roles| [directoryRole API](/graph/api/resources/directoryrole) |

+| Conditional Access policies| [Conditional Access policy API](/graph/api/resources/conditionalaccesspolicy) |

+| Devices| [devices API](/graph/api/resources/device) |

+| Domains| [domains API](/graph/api/domain-list?tabs=http) |

+| Administrative units| [administrative unit API)](/graph/api/resources/administrativeunit) |

+| Deleted items*| [deletedItems API](/graph/api/resources/directory) |

+*Securely store these configuration exports with access provided to a limited number of admins.

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

+- Verify that you've implemented the desired configuration.

+- Use the exporter to capture current configurations.

+- Review the export, understand the settings for your tenant that aren't exported, and manually document them.

+- Store the output in a secure location with limited access.

+> [!NOTE]

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

+The [Microsoft 365 Desired State Configuration](https://github.com/microsoft/Microsoft365DSC/wiki/What-is-Microsoft365DSC) module uses Microsoft Graph and PowerShell to retrieve the state of many of the configurations in Azure AD. This information can be used as reference information or, by using PowerShell Desired State Configuration scripting, to reapply a known good state.

+ Use [Conditional Access Graph APIs](https://github.com/Azure-Samples/azure-ad-conditional-access-apis) to manage policies like code. Automate approvals to promote policies from preproduction environments, backup and restore, monitor change, and plan ahead for emergencies.

+### Map the dependencies among objects

+The deletion of some objects can cause a ripple effect because of dependencies. For example, deletion of a security group used for application assignment would result in users who were members of that group being unable to access the applications to which the group was assigned.

+#### Common dependencies

+| Object type| Potential dependencies |

+| - | - |

+| Application object| Service principal (enterprise application). <br>Groups assigned to the application. <br>Conditional Access policies affecting the application. |

+| Service principals| Application object. |

+| Conditional Access policies| Users assigned to the policy.<br>Groups assigned to the policy.<br>Service principal (enterprise application) targeted by the policy. |

+| Groups other than Microsoft 365 Groups| Users assigned to the group.<br>Conditional Access policies to which the group is assigned.<br>Applications to which the group is assigned access. |

+## Monitoring and data retention

+The [Azure AD Audit log](../reports-monitoring/concept-audit-logs.md) contains information on all delete and configuration operations performed in your tenant. We recommend that you export these logs to a security information and event management tool such as [Microsoft Sentinel](../../sentinel/overview.md). You can also use Microsoft Graph to audit changes and build a custom solution to monitor differences over time. For more information on finding deleted items by using Microsoft Graph, see [List deleted items - Microsoft Graph v1.0 ](/graph/api/directory-deleteditems-list?tabs=http).

+### Audit logs

+The Audit log always records a "Delete \<object\>" event when an object in the tenant is removed from an active state, either from active to soft deleted or active to hard deleted.

+A Delete event for applications, service principals, users, and Microsoft 365 Groups is a soft delete. For any other object type, it's a hard delete.

+| Object type | Activity in log| Result |

+| - | - | - |

+| Application| Delete application and service principal| Soft deleted |

+| Application| Hard delete application | Hard deleted |

+| Service principal| Delete service principal| Soft deleted |

+| Service principal| Hard delete service principal| Hard deleted |

+| User| Delete user| Soft deleted |

+| User| Hard delete user| Hard deleted |

+| Microsoft 365 Groups| Delete group| Soft deleted |

+| Microsoft 365 Groups| Hard delete group| Hard deleted |

+| All other objects| Delete ΓÇ£objectTypeΓÇ¥| Hard deleted |

+> [!NOTE]

+> The Audit log doesn't distinguish the group type of a deleted group. Only Microsoft 365 Groups are soft deleted. If you see a Delete group entry, it might be the soft delete of a Microsoft 365 Group or the hard delete of another type of group. Your documentation of your known good state should include the group type for each group in your organization.

+For information on monitoring configuration changes, see [Recover from misconfigurations](recover-from-misconfigurations.md).

+### Use workbooks to track configuration changes

+Azure Monitor workbooks can help you monitor configuration changes.

+The [Sensitive operations report workbook](../reports-monitoring/workbook-sensitive-operations-report.md) can help identify suspicious application and service principal activity that might indicate a compromise, including:

+- Modified application or service principal credentials or authentication methods.

+- New permissions granted to service principals.

+- Directory role and group membership updates for service principals.

+- Modified federation settings.

+The [Cross-tenant access activity workbook ](../reports-monitoring/workbook-cross-tenant-access-activity.md)can help you monitor which applications in external tenants your users are accessing and which applications in your tenant external users are accessing. Use this workbook to look for anomalous changes in either inbound or outbound application access across tenants.

+## Operational security

+Preventing unwanted changes is far less difficult than needing to re-create and reconfigure objects. Include the following tasks in your change management processes to minimize accidents:

+- Use a least privilege model. Ensure that each member of your team has the least privileges necessary to complete their usual tasks. Require a process to escalate privileges for more unusual tasks.

+- Administrative control of an object enables configuration and deletion. Use read-only admin roles, for example, the Global Reader role, for tasks that don't require operations to create, update, or delete (CRUD). When CRUD operations are required, use object-specific roles when possible. For example, User administrators can delete only users, and Application administrators can delete only applications. Use these more limited roles whenever possible, instead of a Global administrator role, which can delete anything, including the tenant.

+- [Use Privileged Identity Management (PIM)](../privileged-identity-management/pim-configure.md). PIM enables just-in-time escalation of privileges to perform tasks like hard deletion. You can configure PIM to have notifications or approvals for the privilege escalation.

+## Next steps

+- [Recover from deletions](recover-from-deletions.md)

+- [Recover from misconfigurations](recover-from-misconfigurations.md)

+ Title: Increase the resilience of authentication and authorization applications you develop

+description: Resilience guidance for application development using Azure Active Directory and the Microsoft identity platform

+# Increase the resilience of authentication and authorization applications you develop

+The Microsoft identity platform helps you build applications your users and customers can sign in to using their Microsoft identities or social accounts. Microsoft identity platform uses token-based authentication and authorization. Client applications acquire tokens from an identity provider (IdP) to authenticate users and authorize applications to call protected APIs. A service validates tokens.

+Learn more:

+[What is the Microsoft identity platform?](../develop/v2-overview.md)

+[Security tokens](../develop/security-tokens.md)

+A token is valid for a length of time, and then the app must acquire a new one. Rarely, a call to retrieve a token fails due to network or infrastructure issues or an authentication service outage.

+The following articles have guidance for client and service applications for a signed in user and daemon applications. They contain best practices for using tokens and calling resources.

+- [Increase the resilience of authentication and authorization in client applications you develop](resilience-client-app.md)

+- [Increase the resilience of authentication and authorization in daemon applications you develop](resilience-daemon-app.md)

+- [Build resilience in your identity and access management infrastructure](resilience-in-infrastructure.md)

+- [Build resilience in your customer identity and access management with Azure AD B2C](resilience-b2c.md)

+- [Build services that are resilient to Azure AD's OpenID Connect metadata refresh](../develop/howto-build-services-resilient-to-metadata-refresh.md)

+ Title: Build resilience in external user authentication with Azure Active Directory

+description: A guide for IT admins and architects to building resilient authentication for external users

+# Build resilience in external user authentication

+[Azure Active Directory B2B collaboration](../external-identities/what-is-b2b.md) (Azure AD B2B) is a feature of [External Identities](../external-identities/external-collaboration-settings-configure.md) that enables collaboration with other organizations and individuals. It enables the secure onboarding of guest users into your Azure AD tenant without having to manage their credentials. External users bring their identity and credentials with them from an external identity provider (IdP) so they don't have to remember a new credential.

+## Ways to authenticate external users

+You can choose the methods of external user authentication to your directory. You can use Microsoft IdPs or other IdPs.

+With every external IdP, you take a dependency on the availability of that IdP. With some methods of connecting to IdPs, there are things you can do to increase your resilience.

+> [!NOTE]

+> Azure AD B2B has the built-in ability to authenticate any user from any [Azure Active Directory](../index.yml) tenant or with a personal [Microsoft Account](https://account.microsoft.com/account). You do not have to do any configuration with these built-in options.

+### Considerations for resilience with other IdPs

+When you use external IdPs for guest user authentication, there are configurations that you must maintain to prevent disruptions.

+| Authentication Method| Resilience considerations |

+| - | - |

+| Federation with social IDPs like [Facebook](../external-identities/facebook-federation.md) or [Google](../external-identities/google-federation.md).| You must maintain your account with the IdP and configure your Client ID and Client Secret. |

+| [SAML/WS-Fed identity provider (IdP) federation](../external-identities/direct-federation.md)| You must collaborate with the IdP owner for access to their endpoints upon which you're dependent. You must maintain the metadata that contain the certificates and endpoints. |

+| [Email one-time passcode](../external-identities/one-time-passcode.md)| You're dependent on Microsoft's email system, the user's email system, and the user's email client. |

+## Self-service sign-up

+As an alternative to sending invitations or links, you can enable [Self-service sign-up](../external-identities/self-service-sign-up-overview.md). This method allows external users to request access to an application. You must create an [API connector](../external-identities/self-service-sign-up-add-api-connector.md) and associate it with a user flow. You associate user flows that define the user experience with one or more applications.

+It's possible to use [API connectors](../external-identities/api-connectors-overview.md) to integrate your self-service sign-up user flow with external systems' APIs. This API integration can be used for [custom approval workflows](../external-identities/self-service-sign-up-add-approvals.md), [performing identity verification](../external-identities/code-samples-self-service-sign-up.md), and other tasks such as overwriting user attributes. Using APIs requires that you manage the following dependencies.

+* **API Connector Authentication**: Setting up a connector requires an endpoint URL, a username, and a password. Set up a process by which these credentials are maintained, and work with the API owner to ensure you know any expiration schedule.

+* **API Connector Response**: Design API Connectors in the sign-up flow to fail gracefully if the API isn't available. Examine and provide to your API developers these [example API responses](../external-identities/self-service-sign-up-add-api-connector.md) and the [best practices for troubleshooting](../external-identities/self-service-sign-up-add-api-connector.md). Work with the API development team to test all possible response scenarios, including continuation, validation-error, and blocking responses.

+## Next steps

+### Resilience resources for administrators and architects

+

+* [Build resilience with credential management](resilience-in-credentials.md)

+* [Build resilience with device states](resilience-with-device-states.md)

+* [Build resilience by using Continuous Access Evaluation (CAE)](resilience-with-continuous-access-evaluation.md)

+* [Build resilience in your hybrid authentication](resilience-in-hybrid.md)

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

+### Resilience resources for developers

+* [Build IAM resilience in your applications](resilience-app-development-overview.md)

+* [Build resilience in your CIAM systems](resilience-b2c.md)

+ Title: Resilience through developer best practices using Azure AD B2C

+description: Resilience through developer best practices in Customer Identity and Access Management using Azure AD B2C

+# Resilience through developer best practices

+In this article, we share some learnings that are based on our experience from working with large customers. You may consider these recommendations in the design and implementation of your services.

+

+## Use the Microsoft Authentication Library (MSAL)

+The [Microsoft Authentication Library (MSAL)](../develop/msal-overview.md) and the [Microsoft identity web authentication library for ASP.NET](../develop/reference-v2-libraries.md) simplify acquiring, managing, caching, and refreshing the tokens an application requires. These libraries are optimized specifically to support Microsoft Identity including features that improve application resiliency.

+Developers should adopt latest releases of MSAL and stay up to date. See [how to increase resilience of authentication and authorization](resilience-app-development-overview.md) in your applications. Where possible, avoid implementing your own authentication stack and use well-established libraries.

+## Optimize directory reads and writes

+The Microsoft Azure AD B2C directory service supports billions of authentications a day. It's designed for a high rate of reads per second. Optimize your writes to minimize dependencies and increase resilience.

+### How to optimize directory reads and writes

+- **Avoid write functions to the directory on sign-in**: Never execute a write on sign-in without a precondition (if clause) in your custom policies. One use case that requires a write on a sign-in is [just-in-time migration of user passwords](https://github.com/azure-ad-b2c/user-migration/tree/master/seamless-account-migration). Avoid any scenario that requires a write on every sign-in. [Preconditions](../../active-directory-b2c/userjourneys.md) in a user journey will look like this:

+ ```xml

+ <Precondition Type="ClaimEquals" ExecuteActionsIf="true">

+ <Value>requiresMigration</Value>

+ ...

+ <Precondition/>

+ ```

+- **Understand throttling**: The directory implements both application and tenant level throttling rules. There are further rate limits for Read/GET, Write/POST, Update/PUT, and Delete/DELETE operations and each operation have different limits.

+ - A write at the time of sign-in will fall under a POST for new users or PUT for existing users.

+ - A custom policy that creates or updates a user on every sign-in, can potentially hit an application level PUT or POST rate limit. The same limits apply when updating directory objects via Azure AD or Microsoft Graph. Similarly, examine the reads to keep the number of reads on every sign-in to the minimum.

+ - Estimate peak load to predict the rate of directory writes and avoid throttling. Peak traffic estimates should include estimates for actions such as sign-up, sign-in, and Multi-factor authentication (MFA). Be sure to test both the Azure AD B2C system and your application for peak traffic. It's possible that Azure AD B2C can handle the load without throttling, when your downstream applications or services won't.

+ - Understand and plan your migration timeline. When planning to migrate users to Azure AD B2C using Microsoft Graph, consider the application and tenant limits to calculate the time needed to complete the migration of users. If you split your user creation job or script using two applications, you can use the per application limit. It would still need to remain below the per tenant threshold.

+ - Understand the effects of your migration job on other applications. Consider the live traffic served by other relying applications to make sure you don't cause throttling at the tenant level and resource starvation for your live application. For more information, see the [Microsoft Graph throttling guidance](/graph/throttling).

+ - Use a [load test sample](https://github.com/azure-ad-b2c/load-tests) to simulate sign-up and sign-in.

+ - Learn more about [Azure Active Directory B2C service limits and restrictions](../../active-directory-b2c/service-limits.md?pivots=b2c-custom-policy).

+

+## Extend token lifetimes

+In an unlikely event, when the Azure AD B2C authentication service is unable to complete new sign-ups and sign-ins, you can still provide mitigation for users who are signed in. With [configuration](../../active-directory-b2c/configure-tokens.md), you can allow users that are already signed in to continue using the application without any perceived disruption until the user signs out from the application or the [session](../../active-directory-b2c/session-behavior.md) times out due to inactivity.

+Your business requirements and desired end-user experience will dictate your frequency of token refresh for both web and Single-page applications (SPAs).

+### How to extend token lifetimes

+- **Web applications**: For web applications where the authentication token is validated at the beginning of sign-in, the application depends on the session cookie to continue to extend the session validity. Enable users to remain signed in by implementing rolling session times that will continue to renew sessions based on user activity. If there's a long-term token issuance outage, these session times can be further increased as a onetime configuration on the application. Keep the lifetime of the session to the maximum allowed.

+- **SPAs**: A SPA may depend on access tokens to make calls to the APIs. A SPA traditionally uses the implicit flow that doesn't result in a refresh token. The SPA can use a hidden `iframe` to perform new token requests against the authorization endpoint if the browser still has an active session with the Azure AD B2C. For SPAs, there are a few options available to allow the user to continue to use the application.

+ - Extend the access token's validity duration to meet your business requirements.

+ - Build your application to use an API gateway as the authentication proxy. In this configuration, the SPA loads without any authentication and the API calls are made to the API gateway. The API gateway sends the user through a sign-in process using an [authorization code grant](https://oauth.net/2/grant-types/authorization-code/) based on a policy and authenticates the user. Then the authentication session between the API gateway and the client is maintained using an authentication cookie. The API gateway services the APIs using the token that is obtained by the API gateway (or some other direct authentication method such as certificates, client credentials, or API keys).

+ - [Migrate your SPA from implicit grant](https://developer.microsoft.com/identity/blogs/msal-js-2-0-supports-authorization-code-flow-is-now-generally-available/) to [authorization code grant flow](../../active-directory-b2c/implicit-flow-single-page-application.md) with Proof Key for Code Exchange (PKCE) and Cross-origin Resource Sharing (CORS) support. Migrate your application from MSAL.js 1.x to MSAL.js 2.x to realize the resiliency of Web applications.

+ - For mobile applications, it's recommended to extend both the refresh and access token lifetimes.

+- **Backend or microservice applications**: Because backend (daemon) applications are non-interactive and aren't in a user context, the prospect of token theft is greatly diminished. Recommendation is to strike a balance between security and lifetime and set a long token lifetime.

+## Configure Single sign-on

+With [Single sign-on (SSO)](../manage-apps/what-is-single-sign-on.md), users sign in once with a single account and get access to multiple applications. The application can be a web, mobile, or a Single page application (SPA), regardless of platform or domain name. When the user initially signs in to an application, Azure AD B2C persists a [cookie-based session](../../active-directory-b2c/session-behavior.md).

+Upon subsequent authentication requests, Azure AD B2C reads and validates the cookie-based session and issues an access token without prompting the user to sign in again. If SSO is configured with a limited scope at a policy or an application, later access to other policies and applications will require fresh authentication.

+### How to configure SSO

+[Configure SSO](../hybrid/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.

+## Safe deployment practices

+The most common disrupters of service are the code and configuration changes. Adoption of Continuous Integration and Continuous Delivery (CICD) processes and tools help with rapid deployment at a large scale and reduces human errors during testing and deployment into production. Adopt CICD for error reduction, efficiency, and consistency. [Azure Pipelines](/azure/devops/pipelines/apps/cd/azure/cicd-data-overview) is an example of CICD.

+## Protect from bots

+Protect your applications against known vulnerabilities such as Distributed Denial of Service (DDoS) attacks, SQL injections, cross-site scripting, remote code execution, and many others as documented in [OWASP Top 10](https://owasp.org/www-project-top-ten/). Deployment of a Web Application Firewall (WAF) can defend against common exploits and vulnerabilities.

+- Use Azure [WAF](../../web-application-firewall/overview.md), which provides centralized protection against attacks.

+- Use WAF with Azure AD [Identity Protection and Conditional Access to provide multi-layer protection](../../active-directory-b2c/conditional-access-identity-protection-overview.md) when using Azure AD B2C.

+- Build resistance to bot-driven [sign-ups by integrating with a CAPTCHA system](https://github.com/azure-ad-b2c/samples/tree/master/policies/captcha-integration).

+## Secrets rotation

+Azure AD B2C uses secrets for applications, APIs, policies, and encryption. The secrets secure authentication, external interactions, and storage. The National Institute of Standards and Technology (NIST) calls the time span during which a specific key is authorized for use by legitimate entities a cryptoperiod. Choose the right length of [cryptoperiod](https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final) to meet your business needs. Developers need to manually set the expiration and rotate secrets well in advance of their expiration.

+### How to implement secret rotation

+- Use [managed identities](../managed-identities-azure-resources/overview.md) for supported resources to authenticate to any service that supports Azure AD authentication. When you use managed identities, you can manage resources automatically, including rotation of credentials.

+- Take an inventory of all the [keys and certificates configured](../../active-directory-b2c/policy-keys-overview.md) in Azure AD B2C. This list is likely to include keys used in custom policies, [APIs](../../active-directory-b2c/secure-rest-api.md), signing ID token, and certificates for SAML.

+- Using CICD, rotate secrets that are about to expire within two months from the anticipated peak season. The recommended maximum cryptoperiod of private keys associated to a certificate is one year.

+- Proactively monitor and rotate the API access credentials such as passwords, and certificates.

+## Test REST APIs

+In the context of resiliency, testing of REST APIs needs to include verification of ΓÇô HTTP codes, response payload, headers, and performance. Testing shouldn't include only happy path tests, but also check whether the API handles problem scenarios gracefully.

+### How to test APIs

+We recommend your test plan to include [comprehensive API tests](../../active-directory-b2c/best-practices.md#testing). If you're planning for an upcoming surge because of promotion or holiday traffic, you need to revise your load testing with the new estimates. Conduct load testing of your APIs and Content Delivery Network (CDN) in a developer environment and not in production.

+## Next steps

+- [Resilience resources for Azure AD B2C developers](resilience-b2c.md)

+ - [Resilient end-user experience](resilient-end-user-experience.md)

+ - [Resilient interfaces with external processes](resilient-external-processes.md)

+ - [Resilience through monitoring and analytics](resilience-with-monitoring-alerting.md)

+- [Build resilience in your authentication infrastructure](resilience-in-infrastructure.md)

+- [Increase resilience of authentication and authorization in your applications](resilience-app-development-overview.md)

+ Title: Build resilience in Customer Identity and Access Management using Azure AD B2C

+description: Methods to build resilience in Customer Identity and Access Management using Azure AD B2C

+# Build resilience in your customer identity and access management with Azure Active Directory B2C

+[Azure Active Directory (AD) B2C](../../active-directory-b2c/overview.md) is a Customer Identity and Access Management (CIAM) platform that is designed to help you launch your critical customer facing applications successfully. We have many built-in features for [resilience](https://azure.microsoft.com/blog/advancing-azure-active-directory-availability/) that are designed to help our service scale to your needs and improve resilience in the face of potential outage situations. In addition, when launching a mission critical application, it's important to consider various design and configuration elements in your application. Consider how the application is configured within Azure AD B2C to ensure that you get a resilient behavior in response to outage or failure scenarios. In this article, we'll discuss some of the best practices to help you increase resilience.

+A resilient service is one that continues to function despite disruptions. You can help improve resilience in your service by:

+- understanding all the components

+- eliminating single points of failures

+- isolating failing components to limit their impact

+- providing redundancy with fast failover mechanisms and recovery paths

+As you develop your application, we recommend considering how to [increase resilience of authentication and authorization in your applications](resilience-app-development-overview.md) with the identity components of your solution. This article attempts to address enhancements for resilience specific to Azure AD B2C applications. Our recommendations are grouped by CIAM functions.

+

+In the subsequent sections, we'll guide you to build resilience in the following areas:

+- [End-user experience](resilient-end-user-experience.md): Enable a fallback plan for your authentication flow and mitigate the potential impact from a disruption of Azure AD B2C authentication service.

+- [Interfaces with external processes](resilient-external-processes.md): Build resilience in your applications and interfaces by recovering from errors.

+- [Developer best practices](resilience-b2c-developer-best-practices.md): Avoid fragility because of common custom policy issues and improve error handling in the areas like interactions with claims verifiers, third-party applications, and REST APIs.

+- [Monitoring and analytics](resilience-with-monitoring-alerting.md): Assess the health of your service by monitoring key indicators and detect failures and performance disruptions through alerting.

+- [Build resilience in your authentication infrastructure](resilience-in-infrastructure.md)

+- [Increase resilience of authentication and authorization in your applications](resilience-app-development-overview.md)

+Watch this video to know how to build resilient and scalable flows using Azure AD B2C.

+>[!Video https://www.youtube.com/embed/8f_Ozpw9yTs]

+ Title: Increase the resilience of authentication and authorization in client applications you develop

+description: Learn to increasing resiliency of authentication and authorization in client application using the Microsoft identity platform

+# Increase the resilience of authentication and authorization in client applications you develop

+Learn to build resilience into client applications that use the Microsoft identity platform and Azure Active Directory (Azure AD) to sign in users, and perform actions on behalf of those users.

+## Use the Microsoft Authentication Library (MSAL)

+The Microsoft Authentication Library (MSAL) is part of the Microsoft identity platform. MSAL acquires, manages, caches, and refreshes tokens; it uses best practices for resilience. MSAL helps developers create secure solutions.

+Learn more:

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

+* [What is the Microsoft identity platform?](../develop/v2-overview.md)

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

+MSAL caches tokens and uses a silent token acquisition pattern. MSAL serializes the token cache on operating systems that natively provide secure storage like Universal Windows Platform (UWP), iOS, and Android. Customize the serialization behavior when you're using:

+* Microsoft.Identity.Web

+* MSAL.NET

+* MSAL for Java

+* MSAL for Python

+Learn more:

+* [Token cache serialization](https://github.com/AzureAD/microsoft-identity-web/wiki/token-cache-serialization)

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

+* [Custom token cache serialization in MSAL for Java](../develop/msal-java-token-cache-serialization.md)

+* [Custom token cache serialization in MSAL for Python](../develop/msal-python-token-cache-serialization.md).

+ 

+When you're using MSAL, token caching, refreshing, and silent acquisition is supported. Use simple patterns to acquire the tokens for authentication. There's support for many languages. Find code sample on, [Microsoft identity platform code samples](../develop/sample-v2-code.md).

+## [C#](#tab/csharp)

+```csharp

+try

+{

+ result = await app.AcquireTokenSilent(scopes, account).ExecuteAsync();

+}

+catch(MsalUiRequiredException ex)

+{

+ result = await app.AcquireToken(scopes).WithClaims(ex.Claims).ExecuteAsync()

+}

+```

+## [JavaScript](#tab/javascript)

+```javascript

+return myMSALObj.acquireTokenSilent(request).catch(error => {

+ console.warn("silent token acquisition fails. acquiring token using redirect");

+ if (error instanceof msal.InteractionRequiredAuthError) {

+ // fallback to interaction when silent call fails

+ return myMSALObj.acquireTokenPopup(request).then(tokenResponse => {

+ console.log(tokenResponse);

+ return tokenResponse;

+ }).catch(error => {

+ console.error(error);

+ });

+ } else {

+ console.warn(error);

+ }

+});

+```

+MSAL is able to refresh tokens. When the Microsoft identity platform issues a long-lived token, it can send information to the client to refresh the token (refresh\_in). The app runs while the old token is valid, but it takes longer for another token acquisition.

+### MSAL releases

+We recommend developers build a process to use the latest MSAL release because authentication is part of app security. Use this practice for libraries under development and improve app resilience.

+Find the latest version and release notes:

+* [microsoft-authentication-library-for-js](https://github.com/AzureAD/microsoft-authentication-library-for-js/releases)

+* [microsoft-authentication-library-for-dotnet](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/releases)

+* [microsoft-authentication-library-for-python](https://github.com/AzureAD/microsoft-authentication-library-for-python/releases)

+* [microsoft-authentication-library-for-java](https://github.com/AzureAD/microsoft-authentication-library-for-java/releases)

+* [microsoft-authentication-library-for-objc](https://github.com/AzureAD/microsoft-authentication-library-for-objc/releases)

+* [microsoft-authentication-library-for-android](https://github.com/AzureAD/microsoft-authentication-library-for-android/releases)

+* [microsoft-authentication-library-for-js](https://github.com/AzureAD/microsoft-authentication-library-for-js/releases)

+* [microsoft-identity-web](https://github.com/AzureAD/microsoft-identity-web/releases)

+## Resilient patterns for token handling

+If you don't use MSAL, use resilient patterns for token handling. The MSAL library implements best practices.

+Generally, applications using modern authentication call an endpoint to retrieve tokens that authenticate the user, or authorize the application to call protected APIs. MSAL handles authentication and implements patterns to improve resilience. If you don't use MSAL, use the guidance in this section for best practices. Otherwise, MSAL implements best practices automatically.

+### Cache tokens

+Ensure apps cache tokens accurately from the Microsoft identity platform. After your app receives tokens, the HTTP response with tokens has an `expires_in` property that indicates the duration to cache, and when to reuse it. Confirm application don't attempt to decode an API access token.

+ 

+Cached tokens prevent unnecessary traffic between an app and the Microsoft identity platform. This scenario makes the app less susceptible to token acquisition failures by reducing token acquisition calls. Cached tokens improve application performance, because the app blocks acquiring tokens less frequently. Users remain signed in to your application for the token lifetime.

+### Serialize and persist tokens

+Ensure apps serialize their token cache securely to persist the tokens between app instances. Reuse tokens during their lifetime. Refresh tokens and access tokens are issued for many hours. During this time, users might start your application several times. When an app starts, confirm it looks for valid access, or a refresh token. This increases app resilience and performance.

+Learn more:

+* [Refresh the access tokens](../develop/v2-oauth2-auth-code-flow.md#refresh-the-access-token)

+* [Microsoft identity platform access tokens](../develop/access-tokens.md)

+ 

+Ensure persistent token storage has access control and encryption, in relation to the user-owner, or process identity. On various operating systems, there are credential storage features.

+### Acquire tokens silently

+Authenticating a user or retrieving authorization to call an API entails multiple steps in Microsoft identity platform. For example, users signing in for the first time enter credentials and perform a multi-factor authentication. Each step affects the resource that provides the service. The best user experience with the least dependencies is silent token acquisition.

+ 

+Silent token acquisition starts with a valid token from the app token cache. If there's no valid token, the app attempts to acquire a token using an available refresh token, and the token endpoint. If neither option is available, the app acquires a token using the `prompt=none` parameter. This action uses the authorization endpoint, but no UI appears for the user. If possible, the Microsoft identity platform provides a token to the app without user interaction. If no method results in a token, then the user manually reauthenticates.

+> [!NOTE]

+> In general, ensure apps don't use prompts like 'login' and 'consent'. These prompts force user interaction, when no interaction is required.

+## Response code handling

+Use the following sections to learn about response codes.

+### HTTP 429 response code

+There are error responses that affect resilience. If your application receives an HTTP 429 response code, Too Many Requests, Microsoft identity platform is throttling your requests. If an app makes too many requests, it's throttled to prevent the app from receiving tokens. Don't allow an app to attempt token acquisition, before the **Retry-After** response field time is complete. Often, a 429 response indicates the application isn't caching and reusing tokens correctly. Confirm how tokens are cached and reused in the application.

+### HTTP 5x response code

+If an application receives an HTTP 5x response code, the app must not enter a fast retry loop. Use the same handling for a 429 response. If no Retry-After header appears, implement an exponential back-off retry with the first retry, at least 5 seconds after the response.

+When a request times out, immediate retries are discouraged. Implement an exponential back-off retry, with the first retry, at least 5 seconds after the response.

+## Retrieving authorization related information

+Many applications and APIs need user information to authorize. Available methods have advantages and disadvantages.

+### Tokens

+Identity (ID) tokens and access tokens have standard claims that provide information. If needed information is in the token, the most efficient technique is token claims, because that prevents another network call. Fewer network calls equate better resilience.

+Learn more:

+* [Microsoft identity platform ID tokens](../develop/id-tokens.md)

+* [Microsoft identity platform access tokens](../develop/access-tokens.md)

+> [!NOTE]

+> Some applications call the UserInfo endpoint to retrieve claims about the authenticated user. The information in the ID token is a superset of information from the UserInfo endpoint. Enable apps to use the ID token instead of calling the UserInfo endpoint.

+Augment standard token claims with optional claims, such as groups. The **Application Group** option includes groups assigned to the application. The **All** or **Security groups** options include groups from apps in the same tenant, which can add groups to the token. Evaluate the effect, because it can negate the efficiency of requesting groups in the token by causing token bloat, and requiring more calls to get the groups.

+Learn more:

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

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

+We recommend you use and include app roles, which customers manage by using the portal or APIs. Assign roles to users and groups to control access. When a token is issued, the assigned roles are in the token roles claim. Information derived from a token prevents more APIs calls.

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

+Add claims based on tenant information. For example, an extension has an enterprise-specific User ID.

+Adding information from the directory to a token is efficient and increases resiliency by reducing dependencies. It doesn't address resilience issues due to an inability to acquire a token. Add optional claims for the application's primary scenarios. If the app requires information for administrative functionality, the application can obtain that information, as needed.

+### Microsoft Graph

+Microsoft Graph has a unified API endpoint to access Microsoft 365 data about productivity patterns, identity, and security. Applications using Microsoft Graph can use Microsoft 365 information for authorization.

+Apps require one token to access Microsoft 365, which is more resilient than previous APIs for Microsoft 365 components like Microsoft Exchange or Microsoft SharePoint that required multiple tokens.

+When using Microsoft Graph APIs, use a Microsoft Graph SDK that simplifies building resilient applications that access Microsoft Graph.

+See, [Microsoft Graph SDK overview](/graph/sdks/sdks-overview)

+For authorization, consider using token claims instead of some Microsoft Graph calls. Request groups, app roles, and optional claims in tokens. Microsoft Graph for authorization requires more network calls that rely on the Microsoft identity platform and Microsoft Graph. However, if your application relies on Microsoft Graph as its data layer, then Microsoft Graph for authorization isn't more risk.

+## Use broker authentication on mobile devices

+On mobile devices, an authentication broker like Microsoft Authenticator improves resilience. The authentication broker uses a primary refresh token (PRT) with claims about the user and device. Use PRT for authentication tokens to access other applications from the device. When a PRT requests application access, Azure Active Directory (Azure AD) trusts its device and MFA claims. This increases resilience by reducing steps to authenticate the device. Users aren't challenged with multiple MFA prompts on the same device.

+See, [What is a Primary Refresh Token?](../devices/concept-primary-refresh-token.md)

+ 

+MSAL supports broker authentication. Learn more:

+* [SSO through Authentication broker on iOS](../develop/single-sign-on-macos-ios.md#sso-through-authentication-broker-on-ios)

+* [Enable cross-app SSO on Android using MSAL](../develop/msal-android-single-sign-on.md)

+## Continuous Access Evaluation

+Continuous Access Evaluation (CAE) increases application security and resilience with long-lived tokens. With CAE, an access token is revoked based on critical events and policy evaluation, rather than short token lifetimes. For some resource APIs, because risk and policy are evaluated in real time, CAE increases token lifetime up to 28 hours. MSAL refreshes long-lived tokens.

+Learn more:

+* [Continuous Access Evaluation](../conditional-access/concept-continuous-access-evaluation.md)

+* [Securing applications with Continuous Access Evaluation](/security/zero-trust/develop/secure-with-cae)

+* [Critical event evaluation](../conditional-access/concept-continuous-access-evaluation.md#critical-event-evaluation)

+* [Conditional Access policy evaluation](../conditional-access/concept-continuous-access-evaluation.md#conditional-access-policy-evaluation)

+* [How to use CAE enabled APIs in your applications](../develop/app-resilience-continuous-access-evaluation.md)

+If you develop resource APIs, go to openid.net for [Shared Signals ΓÇô A Secure Webhooks Framework](https://openid.net/wg/sse/).

+## Next steps

+* [How to use CAE enabled APIs in your applications](../develop/app-resilience-continuous-access-evaluation.md)

+* [Increase the resilience of authentication and authorization in daemon applications you develop](resilience-daemon-app.md)

+* [Build resilience in your identity and access management infrastructure](resilience-in-infrastructure.md)

+* [Build resilience in your customer identity and access management with Azure AD B2C](resilience-b2c.md)

+ Title: Increase the resilience of authentication and authorization in daemon applications you develop

+description: Learn to increase authentication and authorization resiliency in daemon application using the Microsoft identity platform

+# Increase the resilience of authentication and authorization in daemon applications you develop

+Learn to use the Microsoft identity platform and Azure Active Directory (Azure AD) to increase the resilience of daemon applications. Find information about background processes, services, server to server apps, and applications without users.

+See, [What is the Microsoft identity platform?](../develop/v2-overview.md)

+The following diagram illustrates a daemon application making a call to Microsoft identity platform.

+ 

+## Managed identities for Azure resources

+If you're building daemon apps on Microsoft Azure, use managed identities for Azure resources, which handle secrets and credentials. The feature improves resilience by handling certificate expiry, rotation, or trust.

+See, [What are managed identities for Azure resources?](../managed-identities-azure-resources/overview.md)

+Managed identities use long-lived access tokens and information from Microsoft identity platform to acquire new tokens before tokens expire. Your app runs while acquiring new tokens.

+Managed identities use regional endpoints, which help prevent out-of-region failures by consolidating service dependencies. Regional endpoints help keep traffic in a geographical area. For example, if your Azure resource is in WestUS2, all traffic stays in WestUS2.

+## Microsoft Authentication Library

+If you develop daemon apps and don't use managed identities, use the Microsoft Authentication Library (MSAL) for authentication and authorization. MSAL eases the process of providing client credentials. For example, your application doesn't need to create and sign JSON web token assertions with certificate-based credentials.

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

+### Microsoft.Identity.Web for .NET developers

+If you develop daemon apps on ASP.NET Core, use the Microsoft.Identity.Web library to ease authorization. It includes distributed token cache strategies for distributed apps that run in multiple regions.

+Learn more:

+* [Microsoft Identity Web authentication library](../develop/microsoft-identity-web.md)

+* [Distributed token cache](https://github.com/AzureAD/microsoft-identity-web/wiki/token-cache-serialization#distributed-token-cache)

+## Cache and store tokens

+If you don't use MSAL for authentication and authorization, there are best practices for caching and storing tokens. MSAL implements and follows these best practices.

+An application acquires tokens from an identity provider (IdP) to authorize the application to call protected APIs. When your app receives tokens, the response with the tokens contains an `expires\_in` property that tells the application how long to cache, and reuse, the token. Ensure applications use the `expires\_in` property to determine token lifespan. Confirm application don't attempt to decode an API access token. Using the cached token prevents unnecessary traffic between an app and Microsoft identity platform. Users are signed in to your application for the token's lifetime.

+## HTTP 429 and 5xx error codes

+Use the following sections to learn about HTTP 429 and 5xx error codes

+### HTTP 429

+There are HTTP errors that affect resilience. If your application receives an HTTP 429 error code, Too Many Requests, Microsoft identity platform is throttling your requests, which prevents your app from receiving tokens. Ensure your apps don't attempt to acquire a token until the time in the **Retry-After** response field expires. The 429 error often indicates the application doesn't cache and reuse tokens correctly.

+### HTTP 5xx

+If an application receives an HTTP 5x error code, the app must not enter a fast retry loop. Ensure applications wait until the **Retry-After** field expires. If the response provides no Retry-After header, use an exponential back-off retry with the first retry, at least 5 seconds after the response.

+When a request times out, confirm that applications don't retry immediately. Use the previously cited exponential back-off retry.

+## Next steps

+* [Increase the resilience of authentication and authorization in client applications you develop](resilience-client-app.md)

+* [Build resilience in your identity and access management infrastructure](resilience-in-infrastructure.md)

+* [Build resilience in your customer identity and access management with Azure AD B2C](resilience-b2c.md)

+ Title: Build resilience with credential management in Azure Active Directory

+description: A guide for architects

+ and IT administrators on building a resilient credential strategy.

+# Build resilience with credential management

+When a credential is presented to Azure Active Directory (Azure AD) in a token request, there are multiple dependencies that must be available for validation. The first authentication factor relies on Azure AD authentication and, in some cases, on on-premises infrastructure. For more information on hybrid authentication architectures, see [Build resilience in your hybrid infrastructure](resilience-in-hybrid.md).

+If you implement a second factor, the dependencies for the second factor are added to the dependencies for the first. For example, if your first factor is via PTA and your second factor is SMS, your dependencies are as follows.

+* Azure AD authentication services

+* Azure AD Multi-Factor Authentication service

+* On-premises infrastructure

+* Phone carrier

+* The user's device (not pictured)

+

+

+Your credential strategy should consider the dependencies of each authentication type and provision methods that avoid a single point of failure.

+Because authentication methods have different dependencies, it's a good idea to enable users to register for as many second factor options as possible. Be sure to include second factors with different dependencies, if possible. For example, Voice call and SMS as second factors share the same dependencies, so having them as the only options doesn't mitigate risk.

+The most resilient credential strategy is to use passwordless authentication. Windows Hello for Business and FIDO 2.0 security keys have fewer dependencies than strong authentication with two separate factors. The Microsoft Authenticator app, Windows Hello for Business, and FIDO 2.0 security keys are the most secure.

+For second factors, the Microsoft Authenticator app or other authenticator apps using time-based one time passcode (TOTP) or OAuth hardware tokens have the fewest dependencies and are, therefore, more resilient.

+## How do multiple credentials help resilience?

+Provisioning multiple credential types gives users options that accommodate their preferences and environmental constraints. As a result, interactive authentication where users are prompted for Multi-factor authentication will be more resilient to specific dependencies being unavailable at the time of the request. You can [optimize reauthentication prompts for Multi-factor authentication](../authentication/concepts-azure-multi-factor-authentication-prompts-session-lifetime.md).

+In addition to individual user resiliency described above, enterprises should plan contingencies for large-scale disruptions such as operational errors that introduce a misconfiguration, a natural disaster, or an enterprise-wide resource outage to an on-premises federation service (especially when used for Multi-factor authentication).

+## How do I implement resilient credentials?

+* Deploy [Passwordless credentials](../authentication/howto-authentication-passwordless-deployment.md) such as Windows Hello for Business, Phone Authentication, and FIDO2 security keys to reduce dependencies.

+* Deploy the [Microsoft Authenticator App](https://support.microsoft.com/account-billing/how-to-use-the-microsoft-authenticator-app-9783c865-0308-42fb-a519-8cf666fe0acc) as a second factor.

+* Turn on [password hash synchronization](../hybrid/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.

+* [Analyze usage of Multi-factor authentication methods](/samples/azure-samples/azure-mfa-authentication-method-analysis/azure-mfa-authentication-method-analysis/) to improve user experience.

+* [Implement a resilient access control strategy](../authentication/concept-resilient-controls.md)

+## Next steps

+### Resilience resources for administrators and architects

+

+* [Build resilience with device states](resilience-with-device-states.md)

+* [Build resilience by using Continuous Access Evaluation (CAE)](resilience-with-continuous-access-evaluation.md)

+* [Build resilience in external user authentication](resilience-b2b-authentication.md)

+* [Build resilience in your hybrid authentication](resilience-in-hybrid.md)

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

+### Resilience resources for developers

+* [Build IAM resilience in your applications](resilience-app-development-overview.md)

+* [Build resilience in your CIAM systems](resilience-b2c.md)

+ Title: Build more resilient hybrid authentication in Azure Active Directory

+description: A guide for architects and IT administrators on building a resilient hybrid infrastructure.

+# Build resilience in your hybrid architecture

+Hybrid authentication allows users to access cloud-based resources with their identities mastered on premises. A hybrid infrastructure includes both cloud and on premises components.

+* Cloud components include Azure Active Directory (Azure AD), Azure resources and services, your organization's cloud-based apps, and SaaS applications.

+* on premises components include on premises applications, resources like SQL databases, and an identity provider like Windows Server Active Directory.

+> [!IMPORTANT]

+> As you plan for resilience in your hybrid infrastructure, it's key to minimize dependencies and single points of failure.

+Microsoft offers three mechanisms for hybrid authentication. The options are listed in order of resilience. We recommend that you implement password hash synchronization, if possible.

+* [Password hash synchronization](../hybrid/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/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/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/choose-ad-authn.md). This article contains a decision tree that can help you decide on your methodology.

+## Password hash synchronization

+The simplest and most resilient hybrid authentication option for Azure AD is [Password Hash Synchronization](../hybrid/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.

+

+If you choose this authentication option, you won't experience disruption when on premises identity components become unavailable. On premises disruption can occur for many reasons, including hardware failure, power outages, natural disasters, and malware attacks.

+### How do I implement PHS?

+To implement PHS, see the following resources:

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

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

+If your requirements are such that you can't use PHS, use Pass-through Authentication.

+## Pass-through Authentication

+Pass-through Authentication has a dependency on authentication agents that reside on premises on servers. A persistent connection, or service bus, is present between Azure AD and the on premises PTA agents. The firewall, servers hosting the authentication agents, and the on premises Windows Server Active Directory (or other identity provider) are all potential failure points.

+

+### How do I implement PTA?

+To implement Pass-through Authentication, see the following resources.

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

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

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

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

+ ## Federation

+Federation involves the creation of a trust relationship between Azure AD and the federation service, which includes the exchange of endpoints, token signing certificates, and other metadata. When a request comes to Azure AD, it reads the configuration and redirects the user to the endpoints configured. At that point, the user interacts with the federation service, which issues a SAML assertion that is validated by Azure AD.

+The following diagram shows a topology of an enterprise AD FS deployment that includes redundant federation and web application proxy servers across multiple on premises data centers. This configuration relies on enterprise networking infrastructure components like DNS, Network Load Balancing with geo-affinity capabilities, and firewalls. All on premises components and connections are susceptible to failure. Visit the [AD FS Capacity Planning Documentation](/windows-server/identity/ad-fs/design/planning-for-ad-fs-server-capacity) for more information.

+> [!NOTE]

+> Federation has the highest number of on premises dependencies and, therefore, the most potential points of failure. While this diagram shows AD FS, other on premises identity providers are subject to similar design considerations to achieve high availability, scalability, and fail over.

+

+ ### How do I implement federation?

+If you're implementing a federated authentication strategy or want to make it more resilient, see the following resources.

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

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

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

+* Follow the [AD FS capacity planning documentation](/windows-server/identity/ad-fs/design/planning-for-ad-fs-server-capacity)

+* [Deploying AD FS in Azure IaaS](/windows-server/identity/ad-fs/deployment/how-to-connect-fed-azure-adfs)

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

+## Next steps

+### Resilience resources for administrators and architects

+

+* [Build resilience with credential management](resilience-in-credentials.md)

+* [Build resilience with device states](resilience-with-device-states.md)

+* [Build resilience by using Continuous Access Evaluation (CAE)](resilience-with-continuous-access-evaluation.md)

+* [Build resilience in external user authentication](resilience-b2b-authentication.md)

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

+### Resilience resources for developers

+* [Build IAM resilience in your applications](resilience-app-development-overview.md)

+* [Build resilience in your CIAM systems](resilience-b2c.md)

+ Title: Build resilience in your IAM infrastructure with Azure Active Directory

+description: A guide for architects and IT administrators on building resilience to disruption of their IAM infrastructure.

+# Build resilience in your identity and access management infrastructure

+Azure Active Directory (Azure AD) is a global cloud identity and access management system that provides critical services such as authentication and authorization to your organization's resources. This article provides you with guidance to understand, contain, and mitigate the risk of disruption of authentication or authorization services for resources that rely on Azure AD.

+The document set is designed for

+* Identity Architects

+* Identity Service Owners

+* Identity Operations teams

+Also see the documentation for [application developers](./resilience-app-development-overview.md) and for [Azure AD B2C systems](resilience-b2c.md).

+## What is resilience?

+In the context of your identity infrastructure, resilience is the ability to endure disruption to services like authentication and authorization, or failure of other components, with minimal or no effect on your business, users, and operations. The effect of disruption can be severe and resilience requires diligent planning.

+## Why worry about disruption?

+Every call to the authentication system is subject to disruption if any component of the call fails. When authentication is disrupted, because of the underlying component failures, your users won't access their applications. Therefore, reducing the number of authentication calls and number of dependencies in those calls is important to your resilience. Application developers can assert some control over how often tokens are requested. For example, work with your developers to ensure they're using Azure AD Managed Identities for their applications wherever possible.

+In a token-based authentication system like Azure AD, a user's application (client) must acquire a security token from the identity system before it can access an application or other resource. During the validity period, a client can present the same token multiple times to access the application.

+When the token presented to the application expires, the application rejects the token, and the client must acquire a new token from Azure AD. Acquiring a new token potentially requires user interaction, such as credential prompts or meeting other requirements of the authentication system. Reducing the frequency of authentication calls with longer-lived tokens decreases unnecessary interactions. However, you must balance token life with the risk created by fewer policy evaluations. For more information on managing token lifetimes, see this article on [optimizing reauthentication prompts](../authentication/concepts-azure-multi-factor-authentication-prompts-session-lifetime.md).

+## Ways to increase resilience

+The following diagram shows six concrete ways you can increase resilience. Each method is explained in detail in the articles linked in the following Next steps portion of this article.

+

+

+## Next steps

+## Resilience resources for administrators and architects

+

+* [Build resilience with credential management](resilience-in-credentials.md)

+* [Build resilience with device states](resilience-with-device-states.md)

+* [Build resilience by using Continuous Access Evaluation (CAE)](resilience-with-continuous-access-evaluation.md)

+* [Build resilience in external user authentication](resilience-b2b-authentication.md)

+* [Build resilience in your hybrid authentication](resilience-in-hybrid.md)

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

+## Resilience resources for developers

+* [Build IAM resilience in your applications](resilience-app-development-overview.md)

+* [Build resilience in your CIAM systems](resilience-b2c.md)

+ Title: Build resilience in application access with Application Proxy

+description: A guide for architects and IT administrators on using Application Proxy for resilient access to on-premises applications

+# Build resilience in application access with Application Proxy

+Application Proxy is a feature of Azure Active Directory (Azure AD) that enables users to access on premises web applications from a remote client. Application Proxy includes the Application Proxy service in the cloud and the Application Proxy connectors that run on an on premises server.

+Users access on premises resources through a URL published via Application Proxy. They're redirected to the Azure AD sign-in page. The Application Proxy service in Azure AD then sends a token to the Application Proxy connector in the corporate network that passes the token to the on premises Active Directory. The authenticated user can then access the on premises resource. In the diagram below, [connectors](../app-proxy/application-proxy-connectors.md) are shown in a [connector group](../app-proxy/application-proxy-connector-groups.md).

+> [!IMPORTANT]

+> When you publish your applications via Application Proxy, you must implement [capacity planning and appropriate redundancy for the Application Proxy connectors](../app-proxy/application-proxy-connectors.md#capacity-planning).

+)

+## How do I implement Application Proxy?

+To implement remote access with Azure AD Application Proxy, see the following resources.

+* [Planning an Application Proxy deployment](../app-proxy/application-proxy-deployment-plan.md)

+* [High availability and load balancing best practices](../app-proxy/application-proxy-high-availability-load-balancing.md)

+* [Configure proxy servers](../app-proxy/application-proxy-configure-connectors-with-proxy-servers.md)

+* [Design a resilient access control strategy](../authentication/concept-resilient-controls.md)

+## Next steps

+### Resilience resources for administrators and architects

+

+* [Build resilience with credential management](resilience-in-credentials.md)

+* [Build resilience with device states](resilience-with-device-states.md)

+* [Build resilience by using Continuous Access Evaluation (CAE)](resilience-with-continuous-access-evaluation.md)

+* [Build resilience in external user authentication](resilience-b2b-authentication.md)

+* [Build resilience in your hybrid authentication](resilience-in-hybrid.md)

+### Resilience resources for developers

+* [Build IAM resilience in your applications](resilience-app-development-overview.md)

+* [Build resilience in your CIAM systems](resilience-b2c.md)

+ Title: Resilience in identity and access management with Azure Active Directory

+description: Learn how to build resilience into identity and access management. Resilience helps endure disruption to system components and recover with minimal effort.

+ - it-pro

+ - seodec18

+ - kr2b-contr-experiment

+# Building resilience into identity and access management with Azure Active Directory

+Identity and access management (IAM) is a framework of processes, policies, and technologies. IAM facilitates the management of identities and what they access. It includes the many components supporting the authentication and authorization of user and other accounts in your system.

+IAM resilience is the ability to endure disruption to system components and recover with minimal impact to your business, users, customers, and operations. Reducing dependencies, complexity, and single-points-of-failure, while ensuring comprehensive error handling, increases your resilience.

+Disruption can come from any component of your IAM systems. To build a resilient IAM system, assume disruptions will occur and plan for them.

+When planning the resilience of your IAM solution, consider the following elements:

+* Your applications that rely on your IAM system

+* The public infrastructures your authentication calls use, including telecom companies, Internet service providers, and public key providers

+* Your cloud and on-premises identity providers

+* Other services that rely on your IAM, and the APIs that connect them

+* Any other on-premises components in your system

+Whatever the source, recognizing and planning for the contingencies is important. However, adding other identity systems, and their resultant dependencies and complexity, may reduce your resilience rather than increase it.

+To build more resilience in your systems, review the following articles:

+* [Build resilience in your IAM infrastructure](resilience-in-infrastructure.md)

+* [Build IAM resilience in your applications](resilience-app-development-overview.md)

+* [Build resilience in your Customer Identity and Access Management (CIAM) systems](resilience-b2c.md)

+ Title: Build resilience by using Continuous Access Evaluation in Azure Active Directory

+description: A guide for architects and IT administrators on using CAE

+# Build resilience by using Continuous Access Evaluation

+[Continuous Access Evaluation](../conditional-access/concept-continuous-access-evaluation.md) (CAE) allows Azure Active Directory (Azure AD) applications to subscribe to critical events that can then be evaluated and enforced. CAE includes evaluation of the following events:

+* User account deleted or disabled

+* Password for user changed

+* MFA enabled for user

+* Administrator explicitly revokes a token

+* Elevated user risk detected

+As a result, applications can reject unexpired tokens based on the events signaled by Azure AD as depicted in the following diagram.

+

+## How does CAE help?

+The CAE mechanism allows Azure AD to issue longer-lived tokens while enabling applications to revoke access and force reauthentication only when needed. The net result of this pattern is fewer calls to acquire tokens, which means that the end-to-end flow is more resilient.

+To use CAE, both the service and the client must be CAE-capable. Microsoft 365 services such as Exchange Online, Teams, and SharePoint Online support CAE. On the client side, browser-based experiences that use these Office 365 services (such as Outlook Web App) and specific versions of Office 365 native clients are CAE-capable. More Microsoft cloud services will become CAE-capable.

+Microsoft is working with the industry to build [standards](https://openid.net/wg/sse/) that will allow third party applications to use CAE capability. You can also develop applications that are CAE-capable. For more information about CAE-capable application development, see [How to build resilience in your application](resilience-app-development-overview.md).

+## How do I implement CAE?

+* [Update your code to use CAE-enabled APIs](../develop/app-resilience-continuous-access-evaluation.md).

+* [Enable CAE](../conditional-access/concept-continuous-access-evaluation.md) in the Azure AD Security Configuration.

+* Ensure that your organization is using [compatible versions](../conditional-access/concept-continuous-access-evaluation.md) of Microsoft Office native applications.

+* [Optimize your reauthentication prompts](../authentication/concepts-azure-multi-factor-authentication-prompts-session-lifetime.md).

+## Next steps

+### Resilience resources for administrators and architects

+

+* [Build resilience with credential management](resilience-in-credentials.md)

+* [Build resilience with device states](resilience-with-device-states.md)

+* [Build resilience in external user authentication](resilience-b2b-authentication.md)

+* [Build resilience in your hybrid authentication](resilience-in-hybrid.md)

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

+### Resilience resources for developers

+* [Build IAM resilience in your applications](resilience-app-development-overview.md)

+* [Build resilience in your CIAM systems](resilience-b2c.md)

+ Title: Build resilience by using device states in Azure Active Directory

+description: A guide for architects and IT administrators to building resilience by using device states

+# Build resilience with device states

+By enabling [device states](../devices/overview.md) with Azure Active Directory (Azure AD), administrators can author [Conditional Access policies](../conditional-access/overview.md) that control access to applications based on device state. Enabling device states satisfies strong authentication requirements for resource access, reduces multi-factor authentication (MFA) requests, and improves resiliency.

+The following flow chart presents ways to onboard devices in Azure AD that enable device states. You can use more than one in your organization.

+

+When you use [device states](../devices/overview.md), in most cases users will experience single sign-on to resources through a [Primary Refresh Token](../devices/concept-primary-refresh-token.md) (PRT). The PRT contains claims about the user and the device. You can use these claims to get authentication tokens to access applications from the device. The PRT is valid for 14 days and is continuously renewed as long as the user actively uses the device, providing users a resilient experience. For more information about how a PRT can get multi-factor authentication claims, see [When does a PRT get an MFA claim](../devices/concept-primary-refresh-token.md).

+## How do device states help?

+When a PRT requests access to an application, its device, session, and MFA claims are trusted by Azure AD. When administrators create policies that require either a device-based control or a multi-factor authentication control, then the policy requirement can be met through its device state without attempting MFA. Users won't see more MFA prompts on the same device. This increases resilience to a disruption of the Azure AD Multi-Factor Authentication service or dependencies such as local telecom providers.

+## How do I implement device states?

+* Enable [hybrid Azure AD Joined](../devices/hybrid-azuread-join-plan.md) and [Azure AD Join](../devices/device-join-plan.md) for company-owned Windows devices and require they be joined, if possible. If not possible, require they be registered. If there are older versions of Windows in your organization, upgrade those devices to use Windows 10.

+* Standardize user browser access to use either [Microsoft Edge](/deployedge/microsoft-edge-security-identity) or Google Chrome with [supported](https://chrome.google.com/webstore/detail/windows-10-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji) [extensions](https://chrome.google.com/webstore/detail/office/ndjpnladcallmjemlbaebfadecfhkepb) that enable seamless SSO to web applications using the PRT.

+* For personal or company-owned iOS and Android devices, deploy the [Microsoft Authenticator App](https://support.microsoft.com/account-billing/how-to-use-the-microsoft-authenticator-app-9783c865-0308-42fb-a519-8cf666fe0acc). In addition to MFA and password-less sign-in capabilities, the Microsoft Authenticator app enables single sign-on across native applications through [brokered authentication](../develop/msal-android-single-sign-on.md) with fewer authentication prompts for end users.

+* For personal or company-owned iOS and Android devices, use [mobile application management](/mem/intune/apps/app-management) to securely access company resources with fewer authentication requests.

+* For macOS devices, use the [Microsoft Enterprise SSO plug-in for Apple devices (preview)](../develop/apple-sso-plugin.md) to register the device and provide SSO across browser and native Azure AD applications. Then, based on your environment, follow the steps specific to Microsoft Intune or Jamf Pro.

+## Next steps

+### Resilience resources for administrators and architects

+

+* [Build resilience with credential management](resilience-in-credentials.md)

+* [Build resilience by using Continuous Access Evaluation (CAE)](resilience-with-continuous-access-evaluation.md)

+* [Build resilience in external user authentication](resilience-b2b-authentication.md)

+* [Build resilience in your hybrid authentication](resilience-in-hybrid.md)

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

+### Resilience resources for developers

+* [Build IAM resilience in your applications](resilience-app-development-overview.md)

+* [Build resilience in your CIAM systems](resilience-b2c.md)

+ Title: Resilience through monitoring and analytics using Azure AD B2C

+description: Resilience through monitoring and analytics using Azure AD B2C

+# Resilience through monitoring and analytics

+Monitoring maximizes the availability and performance of your applications and services. It delivers a comprehensive solution for collecting, analyzing, and acting on telemetry from your infrastructure and applications. Alerts proactively notify you when issues are found with your service or applications. They allow you to identify and address issues before the end users of your service notice them. [Azure AD Log Analytics](https://azure.microsoft.com/services/monitor/?OCID=AID2100131_SEM_6d16332c03501fc9c1f46c94726d2264:G:s&ef_id=6d16332c03501fc9c1f46c94726d2264:G:s&msclkid=6d16332c03501fc9c1f46c94726d2264#features) helps you analyze, search the audit logs and sign-in logs, and build custom views.

+Watch this video to learn how to set up monitoring and reporting in Azure AD B2C using Azure Monitor.

+>[!Video https://www.youtube.com/embed/Mu9GQy-CbXI]

+## Monitor and get notified through alerts

+Monitoring your system and infrastructure is critical to ensure the overall health of your services. It starts with the definition of business metrics, such as, new user arrival, end user's authentication rates, and conversion. Configure such indicators to monitor. If you're planning for an upcoming surge because of promotion or holiday traffic, revise your estimates specifically for the event and corresponding benchmark for the business metrics. After the event, fall back to the previous benchmark.

+Similarly, to detect failures or performance disruptions, setting up a good baseline and then defining alerting is an indispensable practice to respond to emerging issues promptly.

+

+### How to implement monitoring and alerting

+- **Monitoring**: Use [Azure Monitor](../../active-directory-b2c/azure-monitor.md) to continuously monitor health against key Service Level Objectives (SLO) and get notification whenever a critical change happens. Begin by identifying Azure AD B2C policy or an application as a critical component of your business whose health needs to be monitored to maintain SLO. Identify key indicators that align with your SLOs.

+For example, track the following metrics, since a sudden drop in either will lead to a loss in business.

+ - **Total requests**: The total "n" number of requests sent to Azure AD B2C policy.

+ - **Success rate (%)**: Successful requests/Total number of requests.

+ Access the [key indicators](../../active-directory-b2c/view-audit-logs.md) in [application insights](../../active-directory-b2c/analytics-with-application-insights.md) where Azure AD B2C policy-based logs, [audit logs](../../active-directory-b2c/analytics-with-application-insights.md), and sign-in logs are stored.

+ - **Visualizations**: Using Log analytics build dashboards to visually monitor the key indicators.

+ - **Current period**: Create temporal charts to show changes in the Total requests and Success rate (%) in the current period, for example, current week.

+ - **Previous period**: Create temporal charts to show changes in the Total requests and Success rate (%) over some previous period for reference purposes, for example, last week.

+- **Alerting**: Using log analytics define [alerts](../../azure-monitor/alerts/alerts-log.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:

+ - Alert against abrupt drop in Total requests: Trigger an alert when number of total requests drop abruptly. For example, when there's a 25% drop in the total number of requests compared to previous period, raise an alert.

+ - Alert against significant drop in Success rate (%): Trigger an alert when success rate of the selected policy significantly drops.

+ - Upon receiving an alert, troubleshoot the issue using [Log Analytics](../reports-monitoring/howto-install-use-log-analytics-views.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.

+- **Service alerts**: Use the [Azure AD B2C service level alerts](../../service-health/service-health-overview.md) to get notified of service issues, planned maintenance, health advisory, and security advisory.

+- **Reporting**: [By using log analytics](../reports-monitoring/howto-integrate-activity-logs-with-log-analytics.md), build reports that help you gain understanding about user insights, technical challenges, and growth opportunities.

+ - **Health Dashboard**: Create [custom dashboards using Azure Dashboard](../../azure-monitor/app/tutorial-app-dashboards.md) feature, which supports adding charts using Log Analytics queries. For example, identify pattern of successful and failed sign-ins, failure reasons and telemetry about devices used to make the requests.

+ - **Abandon Azure AD B2C journeys**: Use the [workbook](https://github.com/azure-ad-b2c/siem#list-of-abandon-journeys) to track the list of abandoned Azure AD B2C journeys where user started the sign-in or sign-up journey but never finished it. It provides you details about policy ID and breakdown of steps that are taken by the user before abandoning the journey.

+ - **Azure AD B2C monitoring workbooks**: Use the [monitoring workbooks](https://github.com/azure-ad-b2c/siem) that include Azure AD B2C dashboard, Multi-factor authentication (MFA) operations, Conditional Access report, and Search logs by correlationId. This practice provides better insights into the health of your Azure AD B2C environment.

+

+## Next steps

+- [Resilience resources for Azure AD B2C developers](resilience-b2c.md)

+ - [Resilient end-user experience](resilient-end-user-experience.md)

+ - [Resilient interfaces with external processes](resilient-external-processes.md)

+ - [Resilience through developer best practices](resilience-b2c-developer-best-practices.md)

+- [Build resilience in your authentication infrastructure](resilience-in-infrastructure.md)

+- [Increase resilience of authentication and authorization in your applications](resilience-app-development-overview.md)

+ Title: Resilient end-user experience using Azure AD B2C

+description: Methods to build resilience in end-user experience using Azure AD B2C

+# Resilient end-user experience

+The sign-up and sign-in end-user experience is made up of the following elements:

+- The interfaces the user interacts with ΓÇô such as CSS, HTML, and JavaScript

+- The user flows and custom policies you create ΓÇô such as sign-up, sign-in, and profile edit

+- The identity providers (IDPs) for your application ΓÇô such as local account username/password, Outlook, Facebook, and Google

+

+## Choose between user flow and custom policy

+To help you set up the most common identity tasks, Azure AD B2C provides built-in configurable [user flows](../../active-directory-b2c/user-flow-overview.md). You can also build your own [custom policies](../../active-directory-b2c/custom-policy-overview.md) that offer you maximum flexibility. However, it's recommended to use custom policies only to address complex scenarios.

+### How to decide between user flow and custom policy

+Choose built-in user flows if your business requirements can be met by them. Since extensively tested by Microsoft, you can minimize the testing needed for validating policy-level functional, performance, or scale of these identity user flows. You still need to test your applications for functionality, performance, and scale.

+Should you [choose custom policies](../../active-directory-b2c/user-flow-overview.md) because of your business requirements, make sure you perform policy-level testing for functional, performance, or scale in addition to application-level testing.

+See the article that [compares user flows and custom polices](../../active-directory-b2c/user-flow-overview.md#comparing-user-flows-and-custom-policies) to help you decide.

+## Choose multiple IDPs

+When using an [external identity provider](../../active-directory-b2c/add-identity-provider.md) such as Facebook, make sure to have a fallback plan in case the external provider becomes unavailable.

+### How to set up multiple IDPs

+As part of the external identity provider registration process, include a verified identity claim such as the user's mobile number or email address. Commit the verified claims to the underlying Azure AD B2C directory instance. If the external provider is unavailable, revert to the verified identity claim, and fall back to the phone number as an authentication method. Another option is to send the user a one-time passcode to allow the user to sign in.

+ Follow these steps to [build alternate authentication paths](https://github.com/azure-ad-b2c/samples/tree/master/policies/idps-filter):

+ 1. Configure your sign-up policy to allow sign up by local account and external IDPs.

+ 2. Configure a profile policy to allow users to [link the other identity to their account](https://github.com/Azure-Samples/active-directory-b2c-advanced-policies/tree/master/account-linking) after they sign in.

+ 3. Notify and allow users to [switch to an alternate IDP](../../active-directory-b2c/customize-ui-with-html.md#configure-dynamic-custom-page-content-uri) during an outage.

+## Availability of Multi-factor authentication

+When using a [phone service for Multi-factor authentication (MFA)](../../active-directory-b2c/phone-authentication-user-flows.md), make sure to consider an alternative service provider. The local Telco or phone service provider may experience disruptions in their service.

+### How to choose an alternate MFA

+The Azure AD B2C service uses a built-in phone-based MFA provider, to deliver time-based One-time passcodes (OTPs). It is in the form of a voice call and text message to user's pre-registered phone number. The following alternative methods are available for various scenarios:

+When you use **user flows**, there are two methods to build resilience:

+- **Change user flow configuration**: Upon detecting a disruption in the phone-based OTP delivery, change the OTP delivery method from phone-based to email-based and redeploy the user flow, leaving the applications unchanged.

+

+- **Change applications**: For each identity task such as sign-up and sign-in, define two sets of user flows. Configure first set to use phone-based OTP and the second to email-based OTP. Upon detecting a disruption in the phone-based OTP delivery, change and redeploy the applications to switch from the first set of user flows to the second, leaving the user flows unchanged.

+When you use **custom policies**, there are four methods to build resilience. Below list is in the order of complexity and you'll need to redeploy updated policies.

+- **Enable user selection of either phone-based OTP or email-based OTP**: Expose both options to the users and enable users to self-select one of the options. There's no need to make changes to the policies or applications.

+- **Dynamically switch between phone-based OTP and email-based OTP**: Collect both phone and email information at sign-up. Define custom policy in advance to conditionally switch during a phone disruption, from phone-based to email-based OTP delivery. There's no need to make changes to the policies or applications.

+- **Use an Authenticator app**: Update custom policy to use an [Authenticator app](https://github.com/azure-ad-b2c/samples/tree/master/policies/custom-mfa-totp). If your normal MFA is either phone-based or email-based OTP, then redeploy your custom policies to switch to use the Authenticator app.

+>[!Note]

+>Users need to configure Authenticator app integration during the sign-up.

+- **Use Security Questions**: If none of the above methods are applicable, implement Security Questions as a backup. Set up Security Questions for users during onboarding or profile edit and store the answers in a separate database other than the directory. This method doesn't meet the MFA requirement of "something you have" for example, phone, but offers a secondary "something that you know".

+## Use a content delivery network

+Content delivery networks (CDNs) are better performant and less expensive than blob stores for storage of custom user flow UI. The web page content is delivered faster from a geographically distributed network of highly available servers.

+Periodically test your CDN's availability and the performance of content distribution through end-to-end scenario and load testing. If you're planning for an upcoming surge because of promotion or holiday traffic, revise your estimates for load testing.

+

+## Next steps

+- [Resilience resources for Azure AD B2C developers](resilience-b2c.md)

+

+ - [Resilient interfaces with external processes](resilient-external-processes.md)

+ - [Resilience through developer best practices](resilience-b2c-developer-best-practices.md)

+ - [Resilience through monitoring and analytics](resilience-with-monitoring-alerting.md)

+- [Build resilience in your authentication infrastructure](resilience-in-infrastructure.md)

+- [Increase resilience of authentication and authorization in your applications](resilience-app-development-overview.md)

+ Title: Resilient interfaces with external processes using Azure AD B2C

+description: Methods to build resilient interfaces with external processes

+# Resilient interfaces with external processes

+In this article, we provide you guidance on how to plan for and implement the RESTful APIs in the user journey and make your application more resilient to API failures.

+

+## Ensure correct placement of the APIs

+Identity experience framework (IEF) policies allow you to call an external system using a [RESTful API technical profile](../../active-directory-b2c/restful-technical-profile.md). External systems aren't controlled by the IEF runtime environment and are a potential failure point.

+### How to manage external systems using APIs

+- While calling an interface to access certain data, check whether the data is going to drive the authentication decision. Assess whether the information is essential to the core functionality of the application. For example, an e-commerce vs. a secondary functionality such as an administration. If the information isn't needed for authentication and only required for secondary scenarios, then consider moving the call to the application logic.

+- If the data that is necessary for authentication is relatively static and small, and has no other business reason to be externalized from the directory, then consider having it in the directory.

+- Remove API calls from the pre-authenticated path whenever possible. If you can't, then you must place strict protections for Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks in front of your APIs. Attackers can load the sign-in page and try to flood your API with DoS attacks and cripple your application. For example, using CAPTCHA in your sign in, sign up flow can help.

+- Use [API connectors of built-in sign-up user flow](../../active-directory-b2c/api-connectors-overview.md) wherever possible to integrate with web APIs either After federating with an identity provider during sign-up or before creating the user. Since the user flows are already extensively tested, it's likely that you don't have to perform user flow-level functional, performance, or scale testing. You still need to test your applications for functionality, performance, and scale.

+- Azure AD RESTful API [technical profiles](../../active-directory-b2c/restful-technical-profile.md) don't provide any caching behavior. Instead, RESTful API profile implements a retry logic and a timeout that is built into the policy.

+- For APIs that need writing data, queue up a task to have such tasks executed by a background worker. Services like [Azure queues](../../storage/queues/storage-queues-introduction.md) can be used. This practice will make the API return efficiently and increase the policy execution performance.

+## API error handling

+As the APIs live outside the Azure AD B2C system, it's needed to have proper error handling within the technical profile. Make sure the end user is informed appropriately and the application can deal with failure gracefully.

+### How to gracefully handle API errors

+- An API could fail for various reasons, make your application resilient to such failures. [Return an HTTP 4XX error message](../../active-directory-b2c/restful-technical-profile.md#returning-validation-error-message) if the API is unable to complete the request. In the Azure AD B2C policy, try to gracefully handle the unavailability of the API and perhaps render a reduced experience.

+- [Handle transient errors gracefully](../../active-directory-b2c/restful-technical-profile.md#error-handling). The RESTful API profile allows you to configure error messages for various [circuit breakers](/azure/architecture/patterns/circuit-breaker).

+- Proactively monitor and using Continuous Integration/Continuous Delivery (CICD), rotate the API access credentials such as passwords and certificates used by the [Technical profile engine](../../active-directory-b2c/restful-technical-profile.md).

+## API management - best practices

+While you deploy the REST APIs and configure the RESTful technical profile, following the recommended best practices will help you from not making common mistakes and things being overlooked.

+### How to manage APIs

+- API Management (APIM) publishes, manages, and analyzes your APIs. APIM also handles authentication to provide secure access to backend services and microservices. Use an API gateway to scale out API deployments, caching, and load balancing.

+- Recommendation is to get the right token at the beginning of the user journey instead of calling multiple times for each API and [secure an Azure APIM API](../../active-directory-b2c/secure-api-management.md?tabs=app-reg-ga).

+## Next steps

+- [Resilience resources for Azure AD B2C developers](resilience-b2c.md)

+ - [Resilient end-user experience](resilient-end-user-experience.md)

+ - [Resilience through developer best practices](resilience-b2c-developer-best-practices.md)

+ - [Resilience through monitoring and analytics](resilience-with-monitoring-alerting.md)

+- [Build resilience in your authentication infrastructure](resilience-in-infrastructure.md)

+- [Increase resilience of authentication and authorization in your applications](resilience-app-development-overview.md)

+ Title: Road to the cloud - Establish a footprint for moving identity and access management from Active Directory to Azure AD

+description: Establish an Azure AD footprint as part of planning your migration of IAM from Active Directory to Azure AD.

+documentationCenter: ''

+# Establish an Azure AD footprint

+Before you migrate identity and access management (IAM) from Active Directory to Azure Active Directory (Azure AD), you need to set up Azure AD.

+## Required tasks

+If you're using Microsoft Office 365, Exchange Online, or Teams, then you're already using Azure AD. Your next step is to establish more Azure AD capabilities:

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

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

+* Secure your hybrid identity infrastructure by following [Five steps to securing your identity infrastructure](../../security/fundamentals/steps-secure-identity.md).

+## Optional tasks

+The following functions aren't specific or mandatory to move from Active Directory to Azure AD, but we recommend incorporating them into your environment. These items are also recommended in the [Zero Trust](/security/zero-trust/) guidance.

+### Deploy passwordless authentication

+In addition to the security benefits of [passwordless credentials](../authentication/concept-authentication-passwordless.md), passwordless authentication simplifies your environment because the management and registration experience is already native to the cloud. Azure AD provides passwordless credentials that align with various use cases. Use the information in this article to plan your deployment: [Plan a passwordless authentication deployment in Azure Active Directory](../authentication/howto-authentication-passwordless-deployment.md).

+After you roll out passwordless credentials to your users, consider reducing the use of password credentials. You can use the [reporting and insights dashboard](../authentication/howto-authentication-methods-activity.md) to continue to drive the use of passwordless credentials and reduce the use of passwords in Azure AD.

+>[!IMPORTANT]

+>During your application discovery, you might find applications that have a dependency or assumptions around passwords. Users of these applications need to have access to their passwords until those applications are updated or migrated.

+### Configure hybrid Azure AD join for existing Windows clients

+You can configure hybrid Azure AD join for existing Active Directory-joined Windows clients to benefit from cloud-based security features such as [co-management](/mem/configmgr/comanage/overview), conditional access, and Windows Hello for Business. New devices should be Azure AD joined and not hybrid Azure AD joined.

+To learn more, check [Plan your hybrid Azure Active Directory join implementation](../devices/hybrid-azuread-join-plan.md).

+## Next steps

+* [Introduction](road-to-the-cloud-introduction.md)

+* [Cloud transformation posture](road-to-the-cloud-posture.md)

+* [Implement a cloud-first approach](road-to-the-cloud-implement.md)

+* [Transition to the cloud](road-to-the-cloud-migrate.md)

+ Title: Road to the cloud - Implement a cloud-first approach when moving identity and access management from Active Directory to Azure AD

+description: Implement a cloud-first approach as part of planning your migration of IAM from Active Directory to Azure AD.

+documentationCenter: ''

+# Implement a cloud-first approach

+It's mainly a process and policy-driven phase to stop, or limit as much as possible, adding new dependencies to Active Directory and implement a cloud-first approach for new demand of IT solutions.

+It's key at this point to identify the internal processes that would lead to adding new dependencies on Active Directory. For example, most organizations would have a change management process that has to be followed before the implementation of new scenarios, features, and solutions. We strongly recommend making sure that these change approval processes are updated to:

+- Include a step to evaluate whether the proposed change would add new dependencies on Active Directory.

+- Request the evaluation of Azure Active Directory (Azure AD) alternatives when possible.

+## Users and groups

+You can enrich user attributes in Azure AD to make more user attributes available for inclusion. Examples of common scenarios that require rich user attributes include:

+* App provisioning: The data source of app provisioning is Azure AD, and necessary user attributes must be in there.

+* Application authorization: A token that Azure AD issues can include claims generated from user attributes so that applications can make authorization decisions based on the claims in the token. It can also contain attributes coming from external data sources through a [custom claims provider](../develop/custom-claims-provider-overview.md).

+* Group membership population and maintenance: Dynamic groups enable dynamic population of group membership based on user attributes, such as department information.

+These two links provide guidance on making schema changes:

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

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

+These links provide more information on this topic but aren't specific to changing the schema:

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

+* [What are custom security attributes in Azure AD (preview)?](../fundamentals/custom-security-attributes-overview.md)

+* [Customize Azure Active Directory attribute mappings in application provisioning](../app-provisioning/customize-application-attributes.md)

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

+These links provide more information about groups:

+* [Create or edit a dynamic group and get status in Azure AD](../enterprise-users/groups-create-rule.md)

+* [Use self-service groups for user-initiated group management](../enterprise-users/groups-self-service-management.md)

+* [Attribute-based application provisioning with scoping filters](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md) or [What is Azure AD entitlement management?](../governance/entitlement-management-overview.md) (for application access)

+* [Compare groups](/microsoft-365/admin/create-groups/compare-groups)

+* [Restrict guest access permissions in Azure Active Directory](../enterprise-users/users-restrict-guest-permissions.md)

+You and your team might feel compelled to change your current employee provisioning to use cloud-only accounts at this stage. The effort is nontrivial but doesn't provide enough business value. We recommend that you plan this transition at a different phase of your transformation.

+## Devices

+Client workstations are traditionally joined to Active Directory and managed via Group Policy objects (GPOs) or device management solutions such as Microsoft Configuration Manager. Your teams will establish a new policy and process to prevent newly deployed workstations from being domain joined. Key points include:

+* Mandate [Azure AD join](../devices/concept-azure-ad-join.md) for new Windows client workstations to achieve "no more domain join."

+* Manage workstations from the cloud by using unified endpoint management (UEM) solutions such as [Intune](/mem/intune/fundamentals/what-is-intune).

+[Windows Autopilot](/mem/autopilot/windows-autopilot) can help you establish a streamlined onboarding and device provisioning, which can enforce these directives.

+[Windows Local Administrator Password Solution](../devices/howto-manage-local-admin-passwords.md) (LAPS) enables a cloud-first solution to manage the passwords of local administrator accounts.

+For more information, see [Learn more about cloud-native endpoints](/mem/cloud-native-endpoints-overview).

+## Applications

+Traditionally, application servers are often joined to an on-premises Active Directory domain so that they can use Windows Integrated Authentication (Kerberos or NTLM), directory queries through LDAP, and server management through GPO or Microsoft Configuration Manager.

+The organization has a process to evaluate Azure AD alternatives when it's considering new services, apps, or infrastructure. Directives for a cloud-first approach to applications should be as follows. (New on-premises applications or legacy applications should be a rare exception when no modern alternative exists.)

+* Provide a recommendation to change the procurement policy and application development policy to require modern protocols (OIDC/OAuth2 and SAML) and authenticate by using Azure AD. New apps should also support [Azure AD app provisioning](../app-provisioning/what-is-hr-driven-provisioning.md) and have no dependency on LDAP queries. Exceptions require explicit review and approval.

+ > [!IMPORTANT]

+ > Depending on the anticipated demands of applications that require legacy protocols, you can choose to deploy [Azure Active Directory Domain Services](../../active-directory-domain-services/overview.md) when more current alternatives won't work.

+* Provide a recommendation to create a policy to prioritize use of cloud-native alternatives. The policy should limit deployment of new application servers to the domain. Common cloud-native scenarios to replace Active Directory-joined servers include:

+ * File servers:

+ * SharePoint or OneDrive provides collaboration support across Microsoft 365 solutions and built-in governance, risk, security, and compliance.

+ * [Azure Files](../../storage/files/storage-files-introduction.md) offers fully managed file shares in the cloud that are accessible via the industry-standard SMB or NFS protocol. Customers can use native [Azure AD authentication to Azure Files](../../virtual-desktop/create-profile-container-azure-ad.md) over the internet without line of sight to a domain controller.

+ * Azure AD works with third-party applications in the Microsoft [application gallery](/microsoft-365/enterprise/integrated-apps-and-azure-ads).

+ * Print servers:

+ * If your organization has a mandate to procure [Universal Print](/universal-print/)-compatible printers, see [Partner integrations](/universal-print/fundamentals/universal-print-partner-integrations).

+ * Bridge with the [Universal Print connector](/universal-print/fundamentals/universal-print-connector-overview) for incompatible printers.

+## Next steps

+* [Introduction](road-to-the-cloud-introduction.md)

+* [Cloud transformation posture](road-to-the-cloud-posture.md)

+* [Establish an Azure AD footprint](road-to-the-cloud-establish.md)

+* [Transition to the cloud](road-to-the-cloud-migrate.md)

+ Title: Road to the cloud - Introduction to moving identity and access management from AD to Azure AD

+description: Learn how to plan a migration of IAM from Active Directory to Azure AD.

+documentationCenter: ''

+# Road to the cloud: Introduction

+Some organizations set goals to remove Active Directory and their on-premises IT footprint. Others take advantage of some cloud-based capabilities to reduce the Active Directory footprint, but not to completely remove their on-premises environments.

+This content provides guidance to move:

+* *From* Active Directory and other non-cloud-based services, either on-premises or infrastructure as a service (IaaS), that provide identity management (IDM), identity and access management (IAM), and device management.

+* *To* Azure Active Directory (Azure AD) and other Microsoft cloud-native solutions for IDM, IAM, and device management.

+>[!NOTE]

+> In this content, *Active Directory* refers to Windows Server Active Directory Domain Services.

+Transformation must be aligned with and achieve business objectives, including increased productivity, reduced costs and complexity, and improved security posture. To better understand the costs versus value of moving to the cloud, see [Forrester TEI for Microsoft Azure Active Directory](https://www.microsoft.com/security/business/forrester-tei-study) and [Cloud economics](https://azure.microsoft.com/overview/cloud-economics/).

+## Next steps

+* [Cloud transformation posture](road-to-the-cloud-posture.md)

+* [Establish an Azure AD footprint](road-to-the-cloud-establish.md)

+* [Implement a cloud-first approach](road-to-the-cloud-implement.md)

+* [Transition to the cloud](road-to-the-cloud-migrate.md)

+ Title: Road to the cloud - Move identity and access management from Active Directory to an Azure AD migration workstream

+description: Learn to plan your migration workstream of IAM from Active Directory to Azure AD.

+documentationCenter: ''

+# Transition to the cloud

+After you align your organization toward halting growth of the Active Directory footprint, you can focus on moving the existing on-premises workloads to Azure Active Directory (Azure AD). This article describes the various migration workstreams. You can execute the workstreams in this article based on your priorities and resources.

+A typical migration workstream has the following stages:

+* **Discover**: Find out what you currently have in your environment.

+* **Pilot**: Deploy new cloud capabilities to a small subset of users, applications, or devices, depending on the workstream.

+* **Scale out**: Expand the pilot to complete the transition of a capability to the cloud.

+* **Cut over (when applicable)**: Stop using the old on-premises workload.

+## Users and groups

+### Enable password self-service

+We recommend a [passwordless environment](../authentication/concept-authentication-passwordless.md). Until then, you can migrate password self-service workflows from on-premises systems to Azure AD to simplify your environment. Azure AD [self-service password reset (SSPR)](../authentication/concept-sspr-howitworks.md) gives users the ability to change or reset their password, with no administrator or help desk involvement.

+To enable self-service capabilities, choose the appropriate [authentication methods](../authentication/concept-authentication-methods.md) for your organization. After the authentication methods are updated, you can enable user self-service password capability for your Azure AD authentication environment. For deployment guidance, see [Deployment considerations for Azure Active Directory self-service password reset](../authentication/howto-sspr-deployment.md).

+Additional considerations include:

+* Deploy [Azure AD Password Protection](../authentication/howto-password-ban-bad-on-premises-operations.md) in a subset of domain controllers with **Audit** mode to gather information about the impact of modern policies.

+* Gradually enable [combined registration for SSPR and Azure AD Multi-Factor Authentication](../authentication/concept-registration-mfa-sspr-combined.md). For example, roll out by region, subsidiary, or department for all users.

+* Go through a cycle of password change for all users to flush out weak passwords. After the cycle is complete, implement the policy expiration time.

+* Switch the Password Protection configuration in the domain controllers that have the mode set to **Enforced**. For more information, see [Enable on-premises Azure AD Password Protection](../authentication/howto-password-ban-bad-on-premises-operations.md).

+>[!NOTE]

+>* We recommend user communications and evangelizing for a smooth deployment. See [Sample SSPR rollout materials](https://www.microsoft.com/download/details.aspx?id=56768).

+>* If you use Azure AD Identity Protection, enable [password reset as a control in Conditional Access policies](../identity-protection/howto-identity-protection-configure-risk-policies.md) for users marked as risky.

+### Move management of groups

+To transform groups and distribution lists:

+* For security groups, use your existing business logic that assigns users to security groups. Migrate the logic and capability to Azure AD and dynamic groups.

+* For self-managed group capabilities provided by Microsoft Identity Manager, replace the capability with self-service group management.

+* You can [convert distribution lists to Microsoft 365 groups](/microsoft-365/admin/manage/upgrade-distribution-lists) in Outlook. This approach is a great way to give your organization's distribution lists all the features and functionality of Microsoft 365 groups.

+* Upgrade your [distribution lists to Microsoft 365 groups in Outlook](https://support.microsoft.com/office/7fb3d880-593b-4909-aafa-950dd50ce188) and [decommission your on-premises Exchange server](/exchange/decommission-on-premises-exchange).

+### Move provisioning of users and groups to applications

+You can simplify your environment by removing application provisioning flows from on-premises identity management (IDM) systems such as Microsoft Identity Manager. Based on your application discovery, categorize your application based on the following characteristics:

+* Applications in your environment that have a provisioning integration with the [Azure AD application gallery](https://www.microsoft.com/security/business/identity-access-management/integrated-apps-azure-ad).

+* Applications that aren't in the gallery but support the SCIM 2.0 protocol. These applications are natively compatible with the Azure AD cloud provisioning service.

+* On-premises applications that have an ECMA connector available. These applications can be integrated with [Azure AD on-premises application provisioning](../app-provisioning/on-premises-application-provisioning-architecture.md).

+For more information, check [Plan an automatic user-provisioning deployment for Azure Active Directory](../app-provisioning/plan-auto-user-provisioning.md).

+### Move to cloud HR provisioning

+You can reduce your on-premises footprint by moving the HR provisioning workflows from on-premises IDM systems, such as Microsoft Identity Manager, to Azure AD. Two account types are available for Azure AD cloud HR provisioning:

+* For new employees who are exclusively using applications that use Azure AD, you can choose to provision *cloud-only accounts*. This provisioning helps you contain the footprint of Active Directory.

+* For new employees who need access to applications that have dependency on Active Directory, you can provision *hybrid accounts*.

+Azure AD cloud HR provisioning can also manage Active Directory accounts for existing employees. For more information, see [Plan cloud HR application to Azure Active Directory user provisioning](../app-provisioning/plan-cloud-hr-provision.md) and [Plan the deployment project](../app-provisioning/plan-auto-user-provisioning.md).

+### Move lifecycle workflows

+Evaluate your existing joiner/mover/leaver workflows and processes for applicability and relevance to your Azure AD cloud environment. You can then simplify these workflows and [create new ones](../governance/create-lifecycle-workflow.md) using [lifecycle workflows](../governance/what-are-lifecycle-workflows.md).

+### Move external identity management

+If your organization provisions accounts in Active Directory or other on-premises directories for external identities such as vendors, contractors, or consultants, you can simplify your environment by managing those third-party user objects natively in the cloud. Here are some possibilities:

+* For new external users, use [Azure AD External Identities](../external-identities/external-identities-overview.md), which stops the Active Directory footprint of users.

+* For existing Active Directory accounts that you provision for external identities, you can remove the overhead of managing local credentials (for example, passwords) by configuring them for business-to-business (B2B) collaboration. Follow the steps in [Invite internal users to B2B collaboration](../external-identities/invite-internal-users.md).

+* Use [Azure AD entitlement management](../governance/entitlement-management-overview.md) to grant access to applications and resources. Most companies have dedicated systems and workflows for this purpose that you can now move out of on-premises tools.

+* Use [access reviews](../governance/access-reviews-external-users.md) to remove access rights and/or external identities that are no longer needed.

+## Devices

+### Move non-Windows workstations

+You can integrate non-Windows workstations with Azure AD to enhance the user experience and to benefit from cloud-based security features such as conditional access.

+* For macOS:

+ * Register macOS to Azure AD and [enroll/manage them by using a mobile device management solution](/mem/intune/enrollment/macos-enroll).

+ * Deploy the [Microsoft Enterprise SSO (single sign-on) plug-in for Apple devices](../develop/apple-sso-plugin.md).

+ * Plan to deploy [Platform SSO for macOS 13](https://techcommunity.microsoft.com/t5/microsoft-endpoint-manager-blog/microsoft-simplifies-endpoint-manager-enrollment-for-apple/ba-p/3570319).

+* For Linux, you can [sign in to a Linux virtual machine (VM) by using Azure Active Directory credentials](../../active-directory/devices/howto-vm-sign-in-azure-ad-linux.md).

+### Replace other Windows versions for workstations

+If you have the following operating systems on workstations, consider upgrading to the latest versions to benefit from cloud-native management (Azure AD join and unified endpoint management):

+* Windows 7 or 8.x

+* Windows Server

+### VDI solution

+This project has two primary initiatives:

+* **New deployments**: Deploy a cloud-managed virtual desktop infrastructure (VDI) solution, such as Windows 365 or Azure Virtual Desktop, that doesn't require on-premises Active Directory.

+* **Existing deployments**: If your existing VDI deployment is dependent on Active Directory, use business objectives and goals to determine whether you maintain the solution or migrate it to Azure AD.

+For more information, see:

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

+* [Windows 365 planning guide](/windows-365/enterprise/planning-guide)

+## Applications

+To help maintain a secure environment, Azure AD supports modern authentication protocols. To transition application authentication from Active Directory to Azure AD, you must:

+* Determine which applications can migrate to Azure AD with no modification.

+* Determine which applications have an upgrade path that enables you to migrate with an upgrade.

+* Determine which applications require replacement or significant code changes to migrate.

+The outcome of your application discovery initiative is to create a prioritized list for migrating your application portfolio. The list contains applications that:

+* Require an upgrade or update to the software, and an upgrade path is available.

+* Require an upgrade or update to the software, but an upgrade path isn't available.

+By using the list, you can further evaluate the applications that don't have an existing upgrade path. Determine whether business value warrants updating the software or if it should be retired. If the software should be retired, decide whether you need a replacement.

+Based on the results, you might redesign aspects of your transformation from Active Directory to Azure AD. There are approaches that you can use to extend on-premises Active Directory to Azure infrastructure as a service (IaaS) (lift and shift) for applications with unsupported authentication protocols. We recommend that you set a policy that requires an exception to use this approach.

+### Application discovery

+After you've segmented your app portfolio, you can prioritize migration based on business value and business priority. You can use tools to create or refresh your app inventory.

+There are three main ways to categorize your apps:

+* **Modern authentication apps**: These applications use modern authentication protocols (such as OIDC, OAuth2, SAML, or WS-Federation) or that use a federation service such as Active Directory Federation Services (AD FS).

+* **Web access management (WAM) tools**: These applications use headers, cookies, and similar techniques for SSO. These apps typically require a WAM identity provider, such as Symantec SiteMinder.

+* **Legacy apps**: These applications use legacy protocols such as Kerberos, LDAP, Radius, Remote Desktop, and NTLM (not recommended).

+Azure AD can be used with each type of application to provide levels of functionality that results in different migration strategies, complexity, and trade-offs. Some organizations have an application inventory that can be used as a discovery baseline. (It's common that this inventory isn't complete or updated.)

+To discover modern authentication apps:

+* If you're using AD FS, use the [AD FS application activity report](../manage-apps/migrate-adfs-application-activity.md).

+* If you're using a different identity provider, use the logs and configuration.

+The following tools can help you discover applications that use LDAP:

+* [Event1644Reader](/troubleshoot/windows-server/identity/event1644reader-analyze-ldap-query-performance): Sample tool for collecting data on LDAP queries made to domain controllers by using field engineering logs.

+* [Microsoft 365 Defender for Identity](/defender-for-identity/monitored-activities): Security solution that uses a sign-in operations monitoring capability. (Note that it captures binds by using LDAP, not Secure LDAP.)

+* [PSLDAPQueryLogging](https://github.com/RamblingCookieMonster/PSLDAPQueryLogging): GitHub tool for reporting on LDAP queries.

+### Migrate AD FS or other federation services

+When you plan your migration to Azure AD, consider migrating the apps that use modern authentication protocols (such as SAML and OpenID Connect) first. You can reconfigure these apps to authenticate with Azure AD either via a built-in connector from the Azure App Gallery or via registration in Azure AD.

+After you move SaaS applications that were federated to Azure AD, there are a few steps to decommission the on-premises federation system:

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

+* [Migrate from Azure AD Multi-Factor Authentication Server to Azure AD Multi-Factor Authentication](../authentication/how-to-migrate-mfa-server-to-azure-mfa.md)

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

+* [Move remote access to internal applications](#move-remote-access-to-internal-applications), if you're using Azure AD Application Proxy

+>[!IMPORTANT]

+>If you're using other features, verify that those services are relocated before you decommission Active Directory Federation Services.

+### Move WAM authentication apps

+This project focuses on migrating SSO capability from WAM systems to Azure AD. To learn more, see [Migrate applications from Symantec SiteMinder to Azure AD](https://azure.microsoft.com/resources/migrating-applications-from-symantec-siteminder-to-azure-active-directory/).

+### Define an application server management strategy

+In terms of infrastructure management, on-premises environments often use a combination of Group Policy objects (GPOs) and Microsoft Configuration Manager features to segment management duties. For example, duties can be segmented into security policy management, update management, configuration management, and monitoring.

+Active Directory is for on-premises IT environments, and Azure AD is for cloud-based IT environments. One-to-one parity of features isn't present here, so you can manage application servers in several ways.

+For example, Azure Arc helps bring many of the features that exist in Active Directory together into a single view when you use Azure AD for identity and access management (IAM). You can also use Azure Active Directory Domain Services (Azure AD DS) to domain-join servers in Azure AD, especially when you want those servers to use GPOs for specific business or technical reasons.

+Use the following table to determine what Azure-based tools you can use to replace the on-premises environment:

+| Management area | On-premises (Active Directory) feature | Equivalent Azure AD feature |

+| - | - | -|

+| Security policy management| GPO, Microsoft Configuration Manager| [Microsoft 365 Defender for Cloud](https://azure.microsoft.com/services/security-center/) |

+| Update management| Microsoft Configuration Manager, Windows Server Update Services| [Azure Automation Update Management](../../automation/update-management/overview.md) |

+| Configuration management| GPO, Microsoft Configuration Manager| [Azure Automation State Configuration](../../automation/automation-dsc-overview.md) |

+| Monitoring| System Center Operations Manager| [Azure Monitor Log Analytics](../../azure-monitor/logs/log-analytics-overview.md) |

+Here's more information that you can use for application server management:

+* [Azure Arc](https://azure.microsoft.com/services/azure-arc/) enables Azure features for non-Azure VMs. For example, you can use it to get Azure features for Windows Server when it's used on-premises or on Amazon Web Services, or [authenticate to Linux machines with SSH](/azure/azure-arc/servers/ssh-arc-overview?tabs=azure-cli).

+* [Manage and secure your Azure VM environment](https://azure.microsoft.com/services/virtual-machines/secure-well-managed-iaas/).

+* If you must wait to migrate or perform a partial migration, you can use GPOs with [Azure AD DS](https://azure.microsoft.com/services/active-directory-ds/).

+If you require management of application servers with Microsoft Configuration Manager, you can't achieve this requirement by using Azure AD DS. Microsoft Configuration Manager isn't supported to run in an Azure AD DS environment. Instead, you need to extend your on-premises Active Directory instance to a domain controller running on an Azure VM. Or, you need to deploy a new Active Directory instance to an Azure IaaS virtual network.

+### Define the migration strategy for legacy applications

+Legacy applications have dependencies like these to Active Directory:

+* User authentication and authorization: Kerberos, NTLM, LDAP bind, ACLs.

+* Access to directory data: LDAP queries, schema extensions, read/write of directory objects.

+* Server management: As determined by the [server management strategy](#define-an-application-server-management-strategy).

+To reduce or eliminate those dependencies, you have three main approaches.

+#### Approach 1

+In the most preferred approach, you undertake projects to migrate from legacy applications to SaaS alternatives that use modern authentication. Have the SaaS alternatives authenticate to Azure AD directly:

+1. Deploy Azure AD DS into an Azure virtual network and [extend the schema](/azure/active-directory-domain-services/concepts-custom-attributes) to incorporate additional attributes needed by the applications.

+2. Lift and shift legacy apps to VMs on the Azure virtual network that are domain-joined to Azure AD DS.

+3. Publish legacy apps to the cloud by using Azure AD Application Proxy or a [secure hybrid access](../manage-apps/secure-hybrid-access.md) partner.

+4. As legacy apps retire through attrition, eventually decommission Azure AD DS running in the Azure virtual network.

+>[!NOTE]

+>* Use Azure AD DS if the dependencies are aligned with [common deployment scenarios for Azure AD DS](../../active-directory-domain-services/scenarios.md).

+>* To validate if Azure AD DS is a good fit, you might use tools like [Service Map in Azure Marketplace](https://azuremarketplace.microsoft.com/marketplace/apps/Microsoft.ServiceMapOMS?tab=Overview) and [automatic dependency mapping with Service Map and Live Maps](https://techcommunity.microsoft.com/t5/system-center-blog/automatic-dependency-mapping-with-service-map-and-live-maps/ba-p/351867).

+>* Validate that your SQL Server instantiations can be [migrated to a different domain](https://social.technet.microsoft.com/wiki/contents/articles/24960.migrating-sql-server-to-new-domain.aspx). If your SQL service is running in virtual machines, [use this guidance](/azure/azure-sql/migration-guides/virtual-machines/sql-server-to-sql-on-azure-vm-individual-databases-guide).

+#### Approach 2

+If the first approach isn't possible and an application has a strong dependency on Active Directory, you can extend on-premises Active Directory to Azure IaaS.

+You can replatform to support modern serverless hosting--for example, use platform as a service (PaaS). Or, you can update the code to support modern authentication. You can also enable the app to integrate with Azure AD directly. [Learn about Microsoft Authentication Library in the Microsoft identity platform](../develop/msal-overview.md).

+1. Connect an Azure virtual network to the on-premises network via virtual private network (VPN) or Azure ExpressRoute.

+2. Deploy new domain controllers for the on-premises Active Directory instance as virtual machines into the Azure virtual network.

+3. Lift and shift legacy apps to VMs on the Azure virtual network that are domain joined.

+4. Publish legacy apps to the cloud by using Azure AD Application Proxy or a [secure hybrid access](../manage-apps/secure-hybrid-access.md) partner.

+5. Eventually, decommission the on-premises Active Directory infrastructure and run Active Directory in the Azure virtual network entirely.

+6. As legacy apps retire through attrition, eventually decommission the Active Directory instance running in the Azure virtual network.

+#### Approach 3

+If the first migration isn't possible and an application has a strong dependency on Active Directory, you can deploy a new Active Directory instance to Azure IaaS. Leave the applications as legacy applications for the foreseeable future, or sunset them when the opportunity arises.

+This approach enables you to decouple the app from the existing Active Directory instance to reduce surface area. We recommend that you consider it only as a last resort.

+1. Deploy a new Active Directory instance as virtual machines in an Azure virtual network.

+2. Lift and shift legacy apps to VMs on the Azure virtual network that are domain-joined to the new Active Directory instance.

+3. Publish legacy apps to the cloud by using Azure AD Application Proxy or a [secure hybrid access](../manage-apps/secure-hybrid-access.md) partner.

+4. As legacy apps retire through attrition, eventually decommission the Active Directory instance running in the Azure virtual network.

+#### Comparison of strategies

+| Strategy | Azure AD DS | Extend Active Directory to IaaS | Independent Active Directory instance in IaaS |

+| - | - | - | - |

+| Decoupling from on-premises Active Directory| Yes| No| Yes |

+| Allowing schema extensions| No| Yes| Yes |

+| Full administrative control| No| Yes| Yes |

+| Potential reconfiguration of apps required (for example, ACLs or authorization)| Yes| No| Yes |

+### Move VPN authentication

+This project focuses on moving your VPN authentication to Azure AD. It's important to know that different configurations are available for VPN gateway connections. You need to determine which configuration best fits your needs. For more information on designing a solution, see [VPN gateway design](../../vpn-gateway/design.md).

+Here are key points about usage of Azure AD for VPN authentication:

+* Check if your VPN providers support modern authentication. For example:

+ * [Tutorial: Azure Active Directory SSO integration with Cisco AnyConnect](../saas-apps/cisco-anyconnect.md)

+ * [Tutorial: Azure Active Directory SSO integration with Palo Alto Networks GlobalProtect](../saas-apps/palo-alto-networks-globalprotect-tutorial.md)

+* For Windows 10 devices, consider integrating [Azure AD support into the built-in VPN client](/windows-server/remote/remote-access/vpn/ad-ca-vpn-connectivity-windows10).

+* After you evaluate this scenario, you can implement a solution to remove your dependency with on-premises to authenticate to VPN.

+### Move remote access to internal applications

+To simplify your environment, you can use [Azure AD Application Proxy](../app-proxy/application-proxy.md) or [secure hybrid access](../manage-apps/secure-hybrid-access.md) partners to provide remote access. This allows you to remove the dependency on on-premises reverse proxy solutions.

+It's important to mention that enabling remote access to an application by using the preceding technologies is an interim step. You need to do more work to completely decouple the application from Active Directory.

+Azure AD DS allows you to migrate application servers to the cloud IaaS and decouple from Active Directory, while using Azure AD Application Proxy to enable remote access. To learn more about this scenario, check [Deploy Azure AD Application Proxy for Azure Active Directory Domain Services](../../active-directory-domain-services/deploy-azure-app-proxy.md).

+## Next steps

+* [Introduction](road-to-the-cloud-introduction.md)

+* [Cloud transformation posture](road-to-the-cloud-posture.md)

+* [Establish an Azure AD footprint](road-to-the-cloud-establish.md)

+* [Implement a cloud-first approach](road-to-the-cloud-implement.md)

+ Title: Road to the cloud - Determine cloud transformation posture when moving identity and access management from Active Directory to Azure AD

+description: Determine your cloud transformation posture when planning your migration of IAM from Active Directory to Azure AD.

+documentationCenter: ''

+# Cloud transformation posture

+Active Directory, Azure Active Directory (Azure AD), and other Microsoft tools are at the core of identity and access management (IAM). For example, Active Directory Domain Services (AD DS) and Microsoft Configuration Manager provide device management in Active Directory. In Azure AD, Intune provides the same capability.

+As part of most modernization, migration, or Zero Trust initiatives, organizations shift IAM activities from using on-premises or infrastructure-as-a-service (IaaS) solutions to using built-for-the-cloud solutions. For an IT environment that uses Microsoft products and services, Active Directory and Azure AD play a role.

+Many companies that migrate from Active Directory to Azure AD start with an environment that's similar to the following diagram. The diagram overlays three pillars:

+* **Applications**: Includes applications, resources, and their underlying domain-joined servers.

+* **Devices**: Focuses on domain-joined client devices.

+* **Users and Groups**: Represents human and workload identities and attributes for resource access and group membership for governance and policy creation.

+[](media/road-to-cloud-posture/road-to-the-cloud-start.png#lightbox)

+Microsoft has modeled five states of transformation that commonly align with the business goals of customers. As the goals of customers mature, it's typical for them to shift from one state to the next at a pace that suits their resources and culture.

+The five states have exit criteria to help you determine where your environment resides today. Some projects, such as application migration, span all five states. Other projects span a single state.

+The content then provides more detailed guidance that's organized to help with intentional changes to people, process, and technology. The guidance can help you:

+* Establish an Azure AD footprint.

+* Implement a cloud-first approach.

+* Start to migrate out of your Active Directory environment.

+Guidance is organized by user management, device management, and application management according to the preceding pillars.

+Organizations that are formed in Azure AD rather than in Active Directory don't have the legacy on-premises environment that more established organizations must contend with. For them, or for customers who are completely re-creating their IT environment in the cloud, becoming 100 percent cloud-centric can happen as the new IT environment is established.

+For customers who have an established on-premises IT capability, the transformation process introduces complexity that requires careful planning. Also, because Active Directory and Azure AD are separate products targeted at different IT environments, they don't have like-for-like features. For example, Azure AD doesn't have the notion of Active Directory domain and forest trusts.

+## Five states of transformation

+In enterprise-sized organizations, IAM transformation, or even transformation from Active Directory to Azure AD, is typically a multi-year effort with multiple states. You analyze your environment to determine your current state, and then set a goal for your next state. Your goal might remove the need for Active Directory entirely, or you might decide not to migrate some capability to Azure AD and leave it in place.

+The states logically group initiatives into projects toward completing a transformation. During the state transitions, you put interim solutions in place. The interim solutions enable the IT environment to support IAM operations in both Active Directory and Azure AD. The interim solutions must also enable the two environments to interoperate.

+The following diagram shows the five states:

+[](media/road-to-cloud-posture/road-to-the-cloud-five-states.png#lightbox)

+>[!NOTE]

+> The states in this diagram represent a logical progression of cloud transformation. Your ability to move from one state to the next depends on the functionality that you've implemented and the capabilities within that functionality to move to the cloud.

+### State 1: Cloud attached

+In the cloud-attached state, organizations have created an Azure AD tenant to enable user productivity and collaboration tools. The tenant is fully operational.

+Most companies that use Microsoft products and services in their IT environment are already in or beyond this state. In this state, operational costs might be higher because there's an on-premises environment and a cloud environment to maintain and make interactive. People must have expertise in both environments to support their users and the organization.

+In this state:

+* Devices are joined to Active Directory and managed through Group Policy or on-premises device management tools.

+* Users are managed in Active Directory, provisioned via on-premises identity management (IDM) systems, and synchronized to Azure AD through Azure AD Connect.

+* Apps are authenticated to Active Directory and to federation servers like Active Directory Federation Services (AD FS) through a web access management (WAM) tool, Microsoft 365, or other tools such as SiteMinder and Oracle Access Manager.

+### State 2: Hybrid

+In the hybrid state, organizations start to enhance their on-premises environment through cloud capabilities. The solutions can be planned to reduce complexity, increase security posture, and reduce the footprint of the on-premises environment.

+During the transition and while operating in this state, organizations grow the skills and expertise for using Azure AD for IAM solutions. Because user accounts and device attachments are relatively easy and a common part of day-to-day IT operations, most organizations have used this approach.

+In this state:

+* Windows clients are hybrid Azure AD joined.

+* Non-Microsoft platforms based on software as a service (SaaS) start being integrated with Azure AD. Examples are Salesforce and ServiceNow.

+* Legacy apps are authenticating to Azure AD via Application Proxy or partner solutions that offer secure hybrid access.

+* Self-service password reset (SSPR) and password protection for users are enabled.

+* Some legacy apps are authenticated in the cloud through Azure AD DS and Application Proxy.

+### State 3: Cloud first

+In the cloud-first state, the teams across the organization build a track record of success and start planning to move more challenging workloads to Azure AD. Organizations typically spend the most time in this state of transformation. As complexity, the number of workloads, and the use of Active Directory grow over time, an organization needs to increase its effort and its number of initiatives to shift to the cloud.

+In this state:

+* New Windows clients are joined to Azure AD and are managed through Intune.

+* ECMA connectors are used to provision users and groups for on-premises apps.

+* All apps that previously used an AD DS-integrated federated identity provider, such as AD FS, are updated to use Azure AD for authentication. If you used password-based authentication through that identity provider for Azure AD, it's migrated to password hash synchronization.

+* Plans to shift file and print services to Azure AD are being developed.

+* Azure AD provides a business-to-business (B2B) collaboration capability.

+* New groups are created and managed in Azure AD.

+### State 4: Active Directory minimized

+Azure AD provides most IAM capability, whereas edge cases and exceptions continue to use on-premises Active Directory. A state of minimizing Active Directory is more difficult to achieve, especially for larger organizations that have significant on-premises technical debt.

+Azure AD continues to evolve as your organization's transformation matures, bringing new features and tools that you can use. Organizations are required to deprecate capabilities or build new capabilities to provide replacement.

+In this state:

+* New users provisioned through the HR provisioning capability are created directly in Azure AD.

+* A plan to move apps that depend on Active Directory and are part of the vision for the future-state Azure AD environment is being executed. A plan to replace services that won't move (file, print, or fax services) is in place.

+* On-premises workloads have been replaced with cloud alternatives such as Windows Virtual Desktop, Azure Files, or Universal Print. Azure SQL Managed Instance replaces SQL Server.

+### State 5: 100% cloud

+In the 100%-cloud state, Azure AD and other Azure tools provide all IAM capability. This state is the long-term aspiration for many organizations.

+In this state:

+* No on-premises IAM footprint is required.

+* All devices are managed in Azure AD and cloud solutions such as Intune.

+* The user identity lifecycle is managed through Azure AD.

+* All users and groups are cloud native.

+* Network services that rely on Active Directory are relocated.

+## Transformation analogy

+The transformation between the states is similar to moving locations:

+1. **Establish a new location**: You purchase your destination and establish connectivity between the current location and the new location. These activities enable you to maintain your productivity and ability to operate. For more information, see [Establish an Azure AD footprint](road-to-the-cloud-establish.md). The results transition you to state 2.

+1. **Limit new items in the old location**: You stop investing in the old location and set a policy to stage new items in the new location. For more information, see [Implement a cloud-first approach](road-to-the-cloud-implement.md). These activities set the foundation to migrate at scale and reach state 3.

+1. **Move existing items to the new location**: You move items from the old location to the new location. You assess the business value of the items to determine if you move them as is, upgrade them, replace them, or deprecate them. For more information, see [Transition to the cloud](road-to-the-cloud-migrate.md).

+ These activities enable you to complete state 3 and reach states 4 and 5. Based on your business objectives, you decide what end state you want to target.

+Transformation to the cloud isn't only the identity team's responsibility. The organization needs coordination across teams to define policies that include people and process change, along with technology. Using a coordinated approach helps ensure consistent progress and reduces the risk of regressing to on-premises solutions. Involve teams that manage:

+* Devices/endpoints

+* Networks

+* Security/risk

+* Application owners

+* Human resources

+* Collaboration

+* Procurement

+* Operations

+### High-level journey

+As organizations start a migration of IAM to Azure AD, they must determine the prioritization of efforts based on their specific needs. Operational staff and support staff must be trained to perform their jobs in the new environment. The following chart shows the high-level journey for migration from Active Directory to Azure AD:

+* **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](../fundamentals/protect-m365-from-on-premises-attacks.md) early in your journey.

+* **Implement a cloud-first approach**: Establish a policy that all new devices, apps, and services should be cloud-first. New applications and services that use legacy protocols (for example, NTLM, Kerberos, or LDAP) should be by exception only.

+* **Transition to the cloud**: Shift the management and integration of users, apps, and devices away from on-premises and over to cloud-first alternatives. Optimize user provisioning by taking advantage of [cloud-first provisioning capabilities](../governance/what-is-provisioning.md) that integrate with Azure AD.

+The transformation changes how users accomplish tasks and how support teams provide user support. The organization should design and implement initiatives or projects in a way that minimizes the impact on user productivity.

+As part of the transformation, the organization introduces self-service IAM capabilities. Some parts of the workforce more easily adapt to the self-service user environment that's prevalent in cloud-based businesses.

+Aging applications might need to be updated or replaced to operate well in cloud-based IT environments. Application updates or replacements can be costly and time-consuming. The planning and other stages must also take the age and capability of the organization's applications into account.

+## Next steps

+* [Introduction](road-to-the-cloud-introduction.md)

+* [Establish an Azure AD footprint](road-to-the-cloud-establish.md)

+* [Implement a cloud-first approach](road-to-the-cloud-implement.md)

+* [Transition to the cloud](road-to-the-cloud-migrate.md)

+ Title: Best practices to secure with Azure Active Directory

+description: Best practices we recommend you follow to secure your isolated environments in Azure Active Directory.

+# Best practices for all isolation architectures

+The following are design considerations for all isolation configurations. Throughout this content, there are many links. We link to content, rather than duplicate it here, so you'll always have access to the most up-to-date information.

+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/active-directory-deployment-checklist-p2.md).

+>[!NOTE]

+>For all isolated tenants we suggest you use clear and differentiated branding to help avoid human error of working in the wrong tenant.

+## Isolation security principles

+When designing isolated environments, it's important to consider the following principles:

+* **Use only modern authentication** - Applications deployed in isolated environments must use claims-based modern authentication (for example, SAML, * Auth, OAuth2, and OpenID Connect) to use capabilities such as federation, Azure AD B2B collaboration, delegation, and the consent framework. This way, legacy applications that have dependency on legacy authentication methods such as NT LAN Manager (NTLM) won't carry forward in isolated environments.

+* **Enforce strong authentication** - Strong authentication must always be used when accessing the isolated environment services and infrastructure. Whenever possible, [passwordless authentication](../authentication/concept-authentication-passwordless.md) such as [Windows for Business Hello](/windows/security/identity-protection/hello-for-business/hello-overview) or a [FIDO2 security keys](../authentication/howto-authentication-passwordless-security-key.md)) should be used.

+* **Deploy secure workstations** - [Secure workstations](/security/compass/privileged-access-devices) provide the mechanism to ensure that the platform and the identity that platform represents is properly attested and secured against exploitation. Two other approaches to consider are:

+ * Use Windows 365 Cloud PCs (Cloud PC) with the Microsoft Graph API.

+ * Use [Conditional Access](../conditional-access/concept-condition-filters-for-devices.md) and filter for devices as a condition.

+* **Eliminate legacy trust mechanisms** - Isolated directories and services shouldn't establish trust relationships with other environments through legacy mechanisms such as Active Directory trusts. All trusts between environments should be established with modern constructs such as federation and claims-based identity.

+* **Isolate services** - Minimize the surface attack area by protecting underlying identities and service infrastructure from exposure. Enable access only through modern authentication for services and secure remote access (also protected by modern authentication) for the infrastructure.

+* **Directory-level role assignments** - Avoid or reduce numbers of directory-level role assignments (User Administrator on directory scope instead of AU-scoping) or service-specific directory roles with control plane actions (Knowledge Admin with permissions to manage security group memberships).

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

+## Human identity provisioning

+### Privileged Accounts

+Provision accounts in the isolated environment for administrative personnel and IT teams who operate the environment. This enables you to add stronger security policies such as device-based access control for [secure workstations](/security/compass/privileged-access-deployment). As discussed in previous sections, nonproduction environments can potentially utilize Azure AD B2B collaboration to onboard privileged accounts to the non-production tenants using the same posture and security controls designed for privileged access in their production environment.

+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](../fundamentals/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.

+>[!NOTE]

+>There are no technical controls to do identity proofing for Azure AD B2B accounts. External identities provisioned with Azure AD B2B are bootstrapped with a single factor. The mitigation is for the organization to have a process to proof the required identities prior to a B2B invitation being issued, and regular access reviews of external identities to manage the lifecycle. Consider enabling a Conditional Access policy to control the MFA registration.

+### Outsourcing high risk roles

+To mitigate inside threats, it's possible to outsource access to the global administrator, and privileged role administrator roles to be managed service provider using Azure B2B collaboration or delegating access through a CSP partner or lighthouse. This access can be controlled by in-house staff via approval flows in Azure Privileged Identity Management (PIM). This approach can greatly reduce inside threats. This is an approach that you can use to meet compliance demands for customers that have concerns.

+## Nonhuman identity provisioning

+### Emergency access accounts

+Provision [emergency access accounts](../roles/security-emergency-access.md) for "break glass" scenarios where normal administrative accounts can't be used in the event you're accidentally locked out of your Azure AD organization. For on-premises environments using federation systems such as Active Directory Federation Services (AD FS) for authentication, maintain alternate cloud-only credentials for your global administrators to ensure service delivery during an on-premises infrastructure outage.

+### Azure managed identities

+Use [Azure managed identities](../managed-identities-azure-resources/overview.md) for Azure resources that require a service identity. Check the [list of services that support managed identities](../managed-identities-azure-resources/managed-identities-status.md) when designing your Azure solutions.

+If managed identities aren't supported or not possible, consider [provisioning service principal objects](../develop/app-objects-and-service-principals.md).

+### Hybrid service accounts

+Some hybrid solutions might require access to both on-premises and cloud resources. An example of a use case would be an Identity Governance solution that uses a service account on premises for access to AD DS and requires access to Azure AD.

+On-premises service accounts typically don't have the ability to sign in interactively, which means that in cloud scenarios they can't fulfill strong credential requirements such as multi-factor authentication (MFA). In this scenario, don't use a service account that has been synced from on-premises, but instead use a managed identity \ service principal. For service principal (SP), use a certificate as a credential, or [protect the SP with Conditional Access](../conditional-access/workload-identity.md).

+If there are technical constraints that don't make this possible and the same account must be used for both on-premises and cloud, then implement compensating controls such as Conditional Access to lock down the hybrid account to come from a specific network location.

+## Resource assignment

+An enterprise solution may be composed of multiple Azure resources and its access should be managed and governed as a logical unit of assignment - a resource group. In that scenario, Azure AD security groups can be created and associated with the proper permissions and role assignment across all solution resources, so that adding or removing users from those groups results in allowing or denying access to the entire solution.

+We recommend you use security groups to grant access to Microsoft services that rely on licensing to provide access (for example, Dynamics 365, Power BI).

+Azure AD cloud native groups can be natively governed from the cloud when combined with [Azure AD access reviews](../governance/access-reviews-overview.md) and [Azure AD entitlement management](../governance/access-reviews-overview.md). Organizations who already have on-premises group governance tools can continue to use those tools and rely on identity synchronization with Azure AD Connect to reflect group membership changes.

+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](../fundamentals/ops-guide-ops.md). Direct assignment might be a good fit for end-user facing assignment.

+Some scenarios might require granting access to on-premises resources through on-premises Active Directory security groups. For those cases, consider the synchronization cycle to Azure AD when designing processes SLA.

+## Authentication management

+This section describes the checks to perform and actions to take for credential management and access policies based on your organization's security posture.

+### Credential management

+#### Strong credentials

+All human identities (local accounts and external identities provisioned through B2B collaboration) in the isolated environment must be provisioned with strong authentication credentials such as multi-factor authentication or a FIDO key. Environments with an underlying on-premises infrastructure with strong authentication such as smart card authentication can continue using smart card authentication in the cloud.

+#### Passwordless credentials

+A [passwordless solution](../authentication/concept-authentication-passwordless.md) is the best solution for ensuring the most convenient and secure method of authentication. Passwordless credentials such as [FIDO security keys](../authentication/howto-authentication-passwordless-security-key.md) and [Windows Hello for Business](/windows/security/identity-protection/hello-for-business/hello-overview) are recommended for human identities with privileged roles.

+#### Password protection

+If the environment is synchronized from an on-premises Active Directory forest, you should deploy [Azure AD password protection](../authentication/concept-password-ban-bad-on-premises.md) to eliminate weak passwords in your organization. [Azure AD smart lockout](../authentication/howto-password-smart-lockout.md) should also be used in hybrid or cloud-only environments to lock out bad actors who are trying to guess your users' passwords or use brute-force methods to get in.

+#### Self-service password management

+Users needing to change or reset their passwords is one of the biggest sources of volume and cost of help desk calls. In addition to cost, changing the password as a tool to mitigate a user risk is a fundamental step in improving the security posture of your organization. At a minimum, deploy [Self-Service Password Management](../authentication/howto-sspr-deployment.md) for human and test accounts with passwords to deflect help desk calls.

+#### External identities passwords

+By using Azure AD B2B collaboration, an [invitation and redemption process](../external-identities/what-is-b2b.md) lets external users such as partners, developers, and subcontractors use their own credentials to access your company's resources. This mitigates the need to introduce more passwords into the isolated tenants.

+>[!Note]

+>Some applications, infrastructure, or workflows might require a local credential. Evaluate this on a case-by-case basis.

+#### Service principals credentials

+For scenarios where service principals are needed, use certificate credentials for service principals or [Conditional Access for workload identities](../conditional-access/workload-identity.md). If necessary, use client secrets as an exception to organizational policy.

+In both cases, Azure Key Vault can be used with Azure managed identities, so that the runtime environment (for example, an Azure function) can retrieve the credential from the key vault.

+Check this example to [create service principals with self-signed certificate](../develop/howto-authenticate-service-principal-powershell.md) for authentication of service principals with certificate credentials.

+### Access policies

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

+* Define [Conditional Access policies](../conditional-access/workload-identity.md) for the [Microsoft Azure Management](../authentication/howto-password-smart-lockout.md) cloud app to enforce identity security posture when accessing Azure Resource Manager. This should include controls on MFA and device-based controls to enable access only through secure workstations (more on this in the Privileged Roles section under Identity Governance). Additionally, use [Conditional Access to filter for devices](../conditional-access/concept-condition-filters-for-devices.md).

+* All applications onboarded to isolated environments must have explicit Conditional Access policies applied as part of the onboarding process.

+* Define Conditional Access policies for [security information registration](../conditional-access/howto-conditional-access-policy-registration.md) that reflects a secure root of trust process on-premises (for example, for workstations in physical locations, identifiable by IP addresses, that employees must visit in person for verification).

+* Consider managing Conditional Access policies at scale with automation using [MS Graph CA API](../conditional-access/howto-conditional-access-apis.md)). For example, you can use the API to configure, manage, and monitor CA policies consistently across tenants.

+* Consider using Conditional Access to restrict workload identities. Create a policy to limit or better control access based on location or other relevant circumstances.

+### Authentication Challenges

+* External identities provisioned with Azure AD B2B might need to reprovision multi-factor authentication (MFA) credentials in the resource tenant. This might be necessary if a cross-tenant access policy hasn't been set up with the resource tenant. This means that onboarding to the system is bootstrapped with a single factor. With this approach, the risk mitigation is for the organization to have a process to proof the user and credential risk profile prior to a B2B invitation being issued. Additionally, define Conditional Access to the registration process as described previously.

+* Use [External identities cross-tenant access settings](../external-identities/cross-tenant-access-overview.md) to manage how they collaborate with other Azure AD organizations and other Microsoft Azure clouds through B2B collaboration and [B2B direct connect](../external-identities/cross-tenant-access-settings-b2b-direct-connect.md).

+* 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/environment-setup.md), [Azure Bastion](../../bastion/bastion-overview.md), or [Cloud PC](/graph/cloudpc-concept-overview).

+* Billing management applications such as Azure EA portal or MCA billing accounts aren't represented as cloud applications for Conditional Access targeting. As a compensating control, define separate administration accounts and target Conditional Access policies to those accounts using an "All Apps" condition.

+## Identity Governance

+### Privileged roles

+Below are some identity governance principles to consider across all the tenant configurations for isolation.

+* **No standing access** - No human identities should have standing access to perform privileged operations in isolated environments. Azure Role-based access control (RBAC) integrates with [Azure AD Privileged Identity Management](../privileged-identity-management/pim-configure.md) (PIM). PIM provides just-in-time activation determined by security gates such as Multi-Factor Authentication, approval workflow, and limited duration.

+* **Number of admins** - Organizations should define minimum and maximum number of humans holding a privileged role to mitigate business continuity risks. With too few privileged roles, there may not be enough time-zone coverage. Mitigate security risks by having as few administrators as possible, following the least-privilege principle.

+* **Limit privileged access** - Create cloud-only and role-assignable groups for high privilege or sensitive privileges. This offers protection of the assigned users and the group object.

+* **Least privileged access** - Identities should only be granted the permissions needed to perform the privileged operations per their role in the organization.

+ * Azure RBAC [custom roles](../../role-based-access-control/custom-roles.md) allow designing least privileged roles based on organizational needs. We recommend that custom roles definitions are authored or reviewed by specialized security teams and mitigate risks of unintended excessive privileges. Authoring of custom roles can be audited through [Azure Policy](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/General/Subscription_AuditCustomRBACRoles_Audit.json).

+ * To mitigate accidental use of roles that aren't meant for wider use in the organization, use Azure Policy to define explicitly which role definitions can be used to assign access. Learn more from this [GitHub Sample](https://github.com/Azure/azure-policy/tree/master/samples/Authorization/allowed-role-definitions).

+* **Privileged access from secure workstations** - All privileged access should occur from secure, locked down devices. Separating these sensitive tasks and accounts from daily use workstations and devices protect privileged accounts from phishing attacks, application and OS vulnerabilities, various impersonation attacks, and credential theft attacks such as keystroke logging, [Pass-the-Hash](https://aka.ms/AzureADSecuredAzure/27a), and Pass-The-Ticket.

+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/environment-setup.md), [Azure Bastion](../../bastion/bastion-overview.md), or [Cloud PC](/graph/cloudpc-concept-overview), or creating Azure-managed workstations or privileged access workstations.

+* **Privileged role process guardrails** - Organizations must define processes and technical guardrails to ensure that privileged operations can be executed whenever needed while complying with regulatory requirements. Examples of guardrails criteria include:

+ * Qualification of humans with privileged roles (for example, full-time employee/vendor, clearance level, citizenship)

+ * Explicit incompatibility of roles (also known as separation of duties). Examples include teams with Azure AD directory roles shouldn't be responsible for managing Azure Resource Manager privileged roles, etc.

+ * Whether direct user or groups assignments are preferred for which roles.

+### Resource access

+* **Attestation** - Identities that hold privileged roles should be reviewed periodically to keep membership current and justified. [Azure AD Access Reviews](../governance/access-reviews-overview.md) integrate with Azure RBAC roles, group memberships and Azure AD B2B external identities.

+* **Lifecycle** - Privileged operations might require access to multiple resources such as line of business applications, SaaS Applications, and Azure resource groups and subscriptions. [Azure AD Entitlement Management](../governance/entitlement-management-overview.md) allows defining access packages that represent a set resource that is assigned to users as a unit, establish a validity period, approval workflows, etc.

+### Governance challenges

+* The Azure Enterprise (Azure EA) Agreement portal doesn't integrate with Azure RBAC or Conditional Access. The mitigation for this is to use dedicated administration accounts that can be targeted with policies and additional monitoring.

+* The Azure EA Enterprise portal doesn't provide an audit log. To mitigate this, consider an automated governed process to provision subscriptions with the considerations described above and use dedicated EA accounts and audit the authentication logs.

+* [Microsoft Customer Agreement](../../cost-management-billing/understand/mca-overview.md) (MCA) roles don't integrate natively with PIM. To mitigate this, use dedicated MCA accounts and monitor usage of these accounts.

+* Monitoring IAM assignments outside Azure AD PIM isn't automated through Azure Policies. The mitigation is to not grant Subscription Owner or User Access Administrator roles to engineering teams. Instead create groups assigned to least privileged roles such as Contributor and delegate the management of those groups to engineering teams.

+* Privileged roles in Azure AD B2C tenants aren't integrated with Azure AD PIM. The mitigation is to create dedicated accounts in the organization's Azure AD tenant, onboard them in the Azure AD B2C tenant and apply conditional access policies to these dedicated administration accounts.

+* Azure AD B2C tenant privileged roles aren't integrated with Azure AD Access Reviews. The mitigation is to create dedicated accounts in the organization's Azure AD tenant, add these accounts to a group and perform regular access reviews on this group.

+* There are no technical controls to subordinate the creation of tenants to an organization. However, the activity is recorded in the Audit log. The onboarding to the billing plane is a compensating control at the gate. This needs to be complemented with monitoring and alerts instead.

+* There's no out-of-the box product to implement the subscription provisioning workflow recommended above. Organizations need to implement their own workflow.

+## Tenant and subscription lifecycle management

+### Tenant lifecycle

+* We recommend implementing a process to request a new corporate Azure AD tenant. The process should account for:

+ * Business justification to create it. Creating a new Azure AD tenant will increase complexity significantly, so it's key to ascertain if a new tenant is necessary.

+ * The Azure cloud in which it should be created (for example, Commercial, Government, etc.).

+ * Whether this is production or not production

+ * Directory data residency requirements

+ * Global Administrators who will manage it

+ * Training and understanding of common security requirements.

+* Upon approval, the Azure AD tenant will be created, configured with necessary baseline controls, and onboarded in the billing plane, monitoring, etc.

+* Regular review of the Azure AD tenants in the billing plane needs to be implemented to detect and discover tenant creation outside the governed process. Refer to the *Inventory and Visibility* section of this document for further details.

+* Azure AD B2C tenant creation can be controlled using Azure Policy. The policy executes when an Azure subscription is associated to the B2C tenant (a pre-requisite for billing). Customers can limit the creation of Azure AD B2C tenants to specific management groups.

+### Subscription lifecycle

+Below are some considerations when designing a governed subscription lifecycle process:

+* Define a taxonomy of applications and solutions that require Azure resources. All teams requesting subscriptions should supply their "product identifier" when requesting subscriptions. This information taxonomy will determine:

+ * Azure AD tenant to provision the subscription

+ * Azure EA account to use for subscription creation

+ * Naming convention

+ * Management group assignment

+ * Other aspects such as tagging, cross-charging, product-view usage, etc.

+* Don't allow ad-hoc subscription creation through the portals or by other means. Instead consider managing [subscriptions programmatically using Azure Resource Manager](../../cost-management-billing/manage/programmatically-create-subscription.md) and pulling consumption and billing reports [programmatically](/rest/api/consumption/). This can help limit subscription provisioning to authorized users and enforce your policy and taxonomy goals. Guidance on following [AZOps principals](https://github.com/azure/azops/wiki/introduction) can be used to help create a practical solution.

+* When a subscription is provisioned, create Azure AD cloud groups to hold standard Azure Resource Manager Roles needed by application teams such as Contributor, Reader and approved custom roles. This enables you to manage Azure RBAC role assignments with governed privileged access at scale.

+ 1. Configure the groups to become eligible for Azure RBAC roles using Azure AD PIM with the corresponding controls such as activation policy, access reviews, approvers, etc.

+ 1. Then [delegate the management of the groups](../enterprise-users/groups-self-service-management.md) to solution owners.

+ 1. As a guardrail, don't assign product owners to User Access Administrator or Owner roles to avoid inadvertent direct assignment of roles outside Azure AD PIM, or potentially changing the subscription to a different tenant altogether.

+ 1. For customers who choose to enable cross-tenant subscription management in non-production tenants through Azure Lighthouse, make sure that the same access policies from the production privileged account (for example, privileged access only from [secured workstations](/security/compass/privileged-access-deployment)) are enforced when authenticating to manage subscriptions.

+* If your organization has pre-approved reference architectures, the subscription provisioning can be integrated with resource deployment tools such as [Azure Blueprints](../../governance/blueprints/overview.md) or [Terraform](https://www.terraform.io).

+* Given the tenant affinity to Azure Subscriptions, subscription provisioning should be aware of multiple identities for the same human actor (employee, partner, vendor, etc.) across multiple tenants and assign access accordingly.

+### Azure AD B2C tenants

+* In an Azure AD B2C tenant, the built-in roles don't support PIM. To increase security, we recommend using Azure AD B2B collaboration to onboard the engineering teams managing Customer Identity Access Management (CIAM) from your Azure tenant, and assign them to Azure AD B2C privileged roles.

+* Following the emergency access guidelines for Azure AD above, consider creating equivalent [emergency access accounts](../roles/security-emergency-access.md) in addition to the external administrators described above.

+* We recommend the logical ownership of the underlying Azure AD subscription of the B2C tenant aligns with the CIAM engineering teams, in the same way that the rest of Azure subscriptions are used for the B2C solutions.

+## Operations

+The following are additional operational considerations for Azure AD, specific to multiple isolated environments. Check the [Azure Cloud Adoption Framework](/azure/cloud-adoption-framework/manage/), the [Microsoft cloud security benchmark](/security/benchmark/azure/) and [Azure AD Operations guide](./ops-guide-ops.md) for detailed guidance to operate individual environments.

+### Cross-environment roles and responsibilities

+**Enterprise-wide SecOps architecture** - Members of operations and security teams from all environments in the organization should jointly define the following:

+* Principles to define when environments need to be created, consolidated, or deprecated.

+* Principles to define management group hierarchy on each environment.

+* Billing plane (EA portal / MCA) security posture, operational posture, and delegation approach.

+* Tenant creation process.

+* Enterprise application taxonomy.

+* Azure subscription provisioning process.

+* Isolation and administration autonomy boundaries and risk assessment across teams and environments.

+* Common baseline configuration and security controls (technical and compensating) and operational baselines to be used in all environments.

+* Common standard operational procedures and tooling that spans multiple environments (for example, monitoring, provisioning).

+* Agreed upon delegation of roles across multiple environments.

+* Segregation of duty across environments.

+* Common supply chain management for privileged workstations.

+* Naming conventions.

+* Cross-environment correlation mechanisms.

+**Tenant creation** - A specific team should own creating the tenant following standardized procedures defined by enterprise-wide SecOps architecture. This includes:

+* Underlying license provisioning (for example, Microsoft 365).

+* Onboarding to corporate billing plan (for example, Azure EA or MCA).

+* Creation of Azure management group hierarchy.

+* Configuration of management policies for various perimeters including identity, data protection, Azure, etc.

+* Deployment of security stack per agreed upon cybersecurity architecture, including diagnostic settings, SIEM onboarding, CASB onboarding, PIM onboarding, etc.

+* Configuration of Azure AD roles based on agreed upon delegation.

+* Configuration and distribution of initial privileged workstations.

+* Provisioning emergency access accounts.

+* Configuration of identity provisioning stack.

+**Cross-environment tooling architecture** - Some tools such as identity provisioning and source control pipelines might need to work across multiple environments. These tools should be considered critical to the infrastructure and must be architected, designed, implemented, and managed as such. As a result, architects from all environments should be involved whenever cross-environment tools need to be defined.

+### Inventory and visibility

+**Azure subscription discovery** - For each discovered tenant, an Azure AD global administrator can [elevate access](../../role-based-access-control/elevate-access-global-admin.md) to gain visibility of all subscriptions in the environment. This elevation will assign the global administrator the User Access Administrator built-in role at the root management group.

+>[!NOTE]

+>This action is highly privileged and might give the admin access to subscriptions that hold extremely sensitive information if that data has not been properly isolated.

+**Enabling read access to discover resources** - Management groups enable RBAC assignment at scale across multiple subscriptions. Customers can grant a Reader role to a centralized IT team by configuring a role assignment in the root management group, which will propagate to all subscriptions in the environment.

+**Resource discovery** - After gaining resource Read access in the environment, [Azure Resource Graph](../../governance/resource-graph/overview.md) can be used to query resources in the environment.

+### Logging and monitoring

+**Central security log management** - Ingest logs from each environment in a [centralized way](/security/benchmark/azure/security-control-logging-monitoring), following consistent best practices across environments (for example, diagnostics settings, log retention, SIEM ingestion, etc.). [Azure Monitor](../../azure-monitor/overview.md) can be used to ingest logs from different sources such as endpoint devices, network, operating systems' security logs, etc.

+Detailed information on using automated or manual processes and tools to monitor logs as part of your security operations is available at [Azure Active Directory security operation guide](https://github.com/azure/azops/wiki/introduction).

+Some environments might have regulatory requirements that limit which data (if any) can leave a given environment. If centralized monitoring across environments isn't possible, teams should have operational procedures to correlate activities of identities across environments for auditing and forensics purposes such as cross-environment lateral movement attempts. It's recommended that the object unique identifiers human identities belonging to the same person is discoverable, potentially as part of the identity provisioning systems.

+The log strategy must include the following Azure AD logs for each tenant used in the organization:

+* Sign-in activity

+* Audit logs

+* Risk events

+Azure AD provides [Azure Monitor integration](../reports-monitoring/concept-activity-logs-azure-monitor.md) for the sign-in activity log and audit logs. Risk events can be ingested through [Microsoft Graph API](/graph/tutorial-riskdetection-api).

+The following diagram shows the different data sources that need to be incorporated as part of the monitoring strategy:

+Azure AD B2C tenants can be [integrated with Azure Monitor](../../active-directory-b2c/azure-monitor.md). We recommend monitoring of Azure AD B2C using the same criteria discussed above for Azure AD.

+Subscriptions that have enabled cross-tenant management with Azure Lighthouse can enable cross-tenant monitoring if the logs are collected by Azure Monitor. The corresponding Log Analytics workspaces can reside in the resource tenant and can be analyzed centrally in the managing tenant using Azure Monitor workbooks. To learn more, check [Monitor delegated resources at scale - Azure Lighthouse](../../lighthouse/how-to/monitor-at-scale.md).

+### Hybrid infrastructure OS security logs

+All hybrid identity infrastructure OS logs should be archived and carefully monitored as a Tier 0 system, given the surface area implications. This includes:

+* AD FS servers and Web Application Proxy

+* Azure AD Connect

+* Application Proxy Agents

+* Password write-back agents

+* Password Protection Gateway machines

+* NPS that has the Azure AD Multi-Factor Authentication RADIUS extension

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

+**Log storage retention** - All environments should have a cohesive log storage retention strategy, design, and implementation to facilitate a consistent toolset (for example, SIEM systems such as Azure Sentinel), common queries, investigation, and forensics playbooks. Azure Policy can be used to set up diagnostic settings.

+**Monitoring and log reviewing** - The operational tasks around identity monitoring should be consistent and have owners in each environment. As described above, strive to consolidate these responsibilities across environments to the extent allowed by regulatory compliance and isolation requirements.

+The following scenarios must be explicitly monitored and investigated:

+* **Suspicious activity** - All [Azure AD risk events](../identity-protection/overview-identity-protection.md) should be monitored for suspicious activity. All tenants should define the network [named locations](../conditional-access/location-condition.md) to avoid noisy detections on location-based signals. [Azure AD Identity Protection](../identity-protection/overview-identity-protection.md) is natively integrated with Azure Security Center. It's recommended that any risk detection investigation includes all the environments the identity is provisioned (for example, if a human identity has an active risk detection in the corporate tenant, the team operating the customer facing tenant should also investigate the activity of the corresponding account in that environment).

+* **User entity behavioral analytics (UEBA) alerts** - UEBA should be used to get insightful information based on anomaly detection. [Microsoft Microsoft 365 Defender for Cloud Apps](https://www.microsoft.com/security/business/siem-and-xdr/microsoft-defender-cloud-apps) provides [UEBA in the cloud](/defender-cloud-apps/tutorial-ueba). Customers can integrate [on-premises UEBA from Microsoft Microsoft 365 Defender for Identity](/defender-cloud-apps/mdi-integration). MCAS reads signals from Azure AD Identity Protection.

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

+ * Sign-ins

+ * Credential management

+ * Any updates on group memberships

+ * Application Assignments

+* **Billing management accounts** - Given the sensitivity of accounts with billing management roles in Azure EA or MCA, and their significant privilege, it's recommended to monitor and alert:

+ * Sign in attempts by accounts with billing roles.

+ * Any attempt to authenticate to applications other than the EA Portal.

+ * Any attempt to authenticate to applications other than Azure Resource Management if using dedicated accounts for MCA billing tasks.

+ * Assignment to Azure resources using dedicated accounts for MCA billing tasks.

+* **Privileged role activity** - Configure and review security [alerts generated by Azure AD PIM](../privileged-identity-management/pim-how-to-configure-security-alerts.md). If locking down direct RBAC assignments isn't fully enforceable with technical controls (for example, Owner role has to be granted to product teams to do their job), then monitor direct assignment of privileged roles outside PIM by generating alerts whenever a user is assigned directly to access the subscription with Azure RBAC.

+* **Classic role assignments** - Organizations should use the modern Azure RBAC role infrastructure instead of the classic roles. As a result, the following events should be monitored:

+ * Assignment to classic roles at the subscription level

+* **Tenant-wide configurations** - Any tenant-wide configuration service should generate alerts in the system.

+ * Updating Custom Domains

+ * Updating branding

+ * Azure AD B2B allow/block list

+ * Azure AD B2B allowed identity providers (SAML IDPs through direct federation or Social Logins)

+ * Conditional Access Policies changes

+* **Application and service principal objects**

+ * New Applications / Service principals that might require Conditional Access policies

+ * Application Consent activity

+* **Management group activity** - The following Identity Aspects of management groups should be monitored:

+ * RBAC role assignments at the MG

+ * Azure Policies applied at the MG

+ * Subscriptions moved between MGs

+ * Any changes to security policies to the Root MG

+* **Custom roles**

+ * Updates of the custom role definitions

+ * New custom roles created

+* **Custom governance rules** - If your organizations established any separation of duties rules (for example, a holder of a Global Administrator tenant GA can't be owner/contributor of subscriptions), create alerts or configure periodic reviews to detect violations.

+**Other monitoring considerations** - Azure subscriptions that contain resources used for Log Management should be considered as critical infrastructure (Tier 0) and locked down to the Security Operations team of the corresponding environment. Consider using tools such as Azure Policy to enforce additional controls to these subscriptions.

+### Operational tools

+**Cross-environment** tooling design considerations:

+* Whenever possible, operational tools that will be used across multiple tenants should be designed to run as an Azure AD multi-tenant application to avoid redeployment of multiple instances on each tenant and avoid operational inefficiencies. The implementation should include authorization logic in to ensure that isolation between users and data is preserved.

+* Add alerts and detections to monitor any cross-environment automation (for example, identity provisioning) and threshold limits for fail-safes. For example, you may want an alert if deprovisioning of user accounts reaches a specific level, as it may indicate a bug or operational error that could have broad impact.

+* Any automation that orchestrates cross-environment tasks should be operated as highly privileged system. This system should be homed to the highest security environment and pull from outside sources if data from other environments is required. Data validation and thresholds need to be applied to maintain system integrity. A common cross-environment task is identity lifecycle management to remove identities from all environments for a terminated employee.

+**IT service management tools** - Organizations using IT Service Management (ITSM) systems such as ServiceNow should configure [Azure AD PIM role activation settings](../privileged-identity-management/pim-how-to-change-default-settings.md) to request a ticket number as part of the activation purposes.

+Similarly, Azure Monitor can be integrated with ITSM systems through the [IT Service Management Connector](../../azure-monitor/alerts/itsmc-overview.md).

+**Operational practices** - Minimize operational activities that require direct access to the environment to human identities. Instead model them as Azure Pipelines that execute common operations (for example, add capacity to a PaaS solution, run diagnostics, etc.) and model direct access to the Azure Resource Manager interfaces to "break glass" scenarios.

+### Operations challenges

+* Activity of Service Principal Monitoring is limited for some scenarios

+* Azure AD PIM alerts don't have an API. The mitigation is to have a regular review of those PIM alerts.

+* Azure EA Portal doesn't provide monitoring capabilities. The mitigation is to have dedicated administration accounts and monitor the account activity.

+* MCA doesn't provide audit logs for billing tasks. The mitigation is to have dedicated administration accounts and monitor the account activity.

+* Some services in Azure needed to operate the environment need to be redeployed and reconfigured across environments as they can't be multi-tenant or multi-cloud.

+* There's no full API coverage across Microsoft Online Services to fully achieve infrastructure as code. The mitigation is to use APIs as much as possible and use portals for the remainder. This [Open-Source initiative](https://microsoft365dsc.com/) to help you with determining an approach that might work for your environment.

+* There's no programmatic capability to discover resource tenants that have delegated subscription access to identities in a managing tenant. For example, if an email address enabled a security group in the contoso.com tenant to manage subscriptions in the fabrikam.com tenant, administrators in the contoso.com don't have an API to discover that this delegation took place.

+* Specific account activity monitoring (for example, break-glass account, billing management account) isn't provided out of the box. The mitigation is for customers to create their own alert rules.

+* Tenant-wide configuration monitoring isn't provided out of the box. The mitigation is for customers to create their own alert rules.

+## Next steps

+* [Introduction to delegated administration and isolated environments](secure-introduction.md)

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

+* [Azure resource management fundamentals](secure-resource-management.md)

+* [Resource isolation in a single tenant](secure-single-tenant.md)

+* [Resource isolation with multiple tenants](secure-multiple-tenants.md)

+ Title: Plan an Azure Active Directory B2B collaboration deployment

+description: A guide for architects and IT administrators on securing and governing external access to internal resources

+# Plan an Azure Active Directory B2B collaboration deployment

+Secure collaboration with your external partners ensures they have correct access to internal resources, and for the expected duration. Learn about governance practices to reduce security risks, meet compliance goals, and ensure accurate access.

+## Governance benefits

+Governed collaboration improves clarity of ownership of access, reduces exposure of sensitive resources, and enables you to attest to access policy.

+* Manage external organizations, and their users who access resources

+* Ensure access is correct, reviewed, and time bound

+* Empower business owners to manage collaboration with delegation

+## Collaboration methods

+Traditionally, organizations use one of two methods to collaborate:

+* Create locally managed credentials for external users, or

+* Establish federations with partner identity providers (IdP)

+Both methods have drawbacks. For more information, see the following table.

+| Area of concern | Local credentials | Federation |

+|-|||

+| Security | - Access continues after external user terminates<br> - UserType is Member by default, which grants too much default access | - No user-level visibility <br> - Unknown partner security posture|

+| Expense | - Password and multi-factor authentication (MFA) management<br> - Onboarding process<br> - Identity cleanup<br> - Overhead of running a separate directory | Small partners can't afford the infrastructure, lack expertise, and might use consumer email|

+| Complexity | Partner users manage more credentials | Complexity grows with each new partner, and increased for partners|

+Azure Active Directory (Azure AD) B2B integrates with other tools in Azure AD, and Microsoft 365 services. Azure AD B2B simplifies collaboration, reduces expense, and increases security.

+## Azure AD B2B benefits

+- If the home identity is disabled or deleted, external users can't access resources

+- User home IdP handles authentication and credential management

+- Resource tenant controls guest-user access and authorization

+- Collaborate with users who have an email address, but no infrastructure

+- IT departments don't connect out-of-band to set up access or federation

+- Guest user access is protected by the same security processes as internal users

+- Clear end-user experience with no extra credentials required

+- Users collaborate with partners without IT department involvement

+- Guest default permissions in the Azure AD directory aren't limited or highly restricted

+## Next steps

+* [Determine your security posture for external access](1-secure-access-posture.md)

+* [Discover the current state of external collaboration in your organization](2-secure-access-current-state.md)

+* [Create a security plan for external access](3-secure-access-plan.md)

+* [Securing external access with groups](4-secure-access-groups.md)

+* [Transition to governed collaboration with Azure Active Directory B2B collaboration](5-secure-access-b2b.md)

+* [Manage external access with entitlement management](6-secure-access-entitlement-managment.md)

+* [Secure access with Conditional Access policies](7-secure-access-conditional-access.md)

+* [Control access with sensitivity labels](8-secure-access-sensitivity-labels.md)

+* [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business](9-secure-access-teams-sharepoint.md)

+* [Convert local guest accounts](10-secure-local-guest.md)

+* [Onboard external users to Line-of-business applications](11-onboard-external-user.md)

+ Title: Fundamentals of securing with Azure Active Directory

+description: Fundamentals of securing your tenants in Azure Active Directory.

+# Azure Active Directory fundamentals

+Azure Active Directory (Azure AD) provides an identity and access boundary for Azure resources and trusting applications. Most environment-separation requirements can be fulfilled with delegated administration in a single Azure AD tenant. This configuration reduces management overhead of your systems. However, some specific cases, for example complete resource and identity isolation, require multiple tenants.

+You must determine your environment separation architecture based on your needs. Areas to consider include:

+* **Resource separation**. If a resource can change directory objects such as user objects, and the change would interfere with other resources, the resource may need to be isolated in a multi-tenant architecture.

+* **Configuration separation**. Tenant-wide configurations affect all resources. The effect of some tenant-wide configurations can be scoped with conditional access (CA) policies and other methods. If you have a need for different tenant configurations that can't be scoped with CA policies, you may need a multi-tenant architecture.

+* **Administrative separation**. You can delegate the administration of management groups, subscriptions, resource groups, resources, and some policies within a single tenant. A Global Administrator always has access to everything within the tenant. If you need to ensure that the environment doesn't share administrators with another environment, you need a multi-tenant architecture.

+To stay secure, you must follow best practices for identity provisioning, authentication management, identity governance, lifecycle management, and operations consistently across all tenants.

+## Terminology

+This list of terms is commonly associated with Azure AD and relevant to this content:

+**Azure AD tenant**. A dedicated and trusted instance of Azure AD that is automatically created when your organization signs up for a Microsoft cloud service subscription. Examples of subscriptions include Microsoft Azure, Microsoft Intune, or Microsoft 365. An Azure AD tenant generally represents a single organization or security boundary. The Azure AD tenant includes the users, groups, devices, and applications used to perform identity and access management (IAM) for tenant resources.

+**Environment**. In the context of this content, an environment is a collection of Azure subscriptions, Azure resources, and applications that are associated with one or more Azure AD tenets. The Azure AD tenant provides the identity control plane to govern access to these resources.

+**Production environment**. In the context of this content, a production environment is the live environment with the infrastructure and services that end users directly interact with. For example, a corporate or customer-facing environment.

+**Non-production environment**. In the context of this content, a nonproduction environment refers to an environment used for:

+* Development

+* Testing

+* Lab purposes

+Non-production environments are commonly referred to as sandbox environments.

+**Identity**. An identity is a directory object that can be authenticated and authorized for access to a resource. Identity objects exist for human identities and non-human identities. Non-human entities include:

+* Application objects

+* Workload identities (formerly described as service principles)

+* Managed identities

+* Devices

+**Human identities** are user objects that generally represent people in an organization. These identities are either created and managed directly in Azure AD or are synchronized from an on-premises Active Directory to Azure AD for a given organization. These types of identities are referred to as **local identities**. There can also be user objects invited from a partner organization or a social identity provider using [Azure AD B2B collaboration](../external-identities/what-is-b2b.md). In this content, we refer to these types of identity as **external identities**.

+**Non-human identities** include any identity not associated with a human. This type of identity is an object such as an application that requires an identity to run. In this content, we refer to this type of identity as a **workload identity**. Various terms are used to describe this type of identity, including [application objects and service principals](../../marketplace/manage-aad-apps.md).

+* **Application object**. An Azure AD application is defined by its application object. The object resides in the Azure AD tenant where the application registered. The tenant is known as the application's "home" tenant.

+ * **Single-tenant** applications are created to only authorize identities coming from the "home" tenant.

+ * **Multi-tenant** applications allow identities from any Azure AD tenant to authenticate.

+* **Service principal object**. Although there are [exceptions](../../marketplace/manage-aad-apps.md), application objects can be considered the *definition* of an application. Service principal objects can be considered an instance of an application. Service principals generally reference an application object, and one application object is referenced by multiple service principals across directories.

+**Service principal objects** are also directory identities that can perform tasks independently from human intervention. The service principal defines the access policy and permissions for a user or application in the Azure AD tenant. This mechanism enables core features such as authentication of the user or application during sign-in and authorization during resource access.

+Azure AD allows application and service principal objects to authenticate with a password (also known as an application secret), or with a certificate. The use of passwords for service principals is discouraged and [we recommend using a certificate](../develop/howto-create-service-principal-portal.md) whenever possible.

+* **Managed identities for Azure resources**. Managed identities are special service principals in Azure AD. This type of service principal can be used to authenticate against services that support Azure AD authentication without needing to store credentials in your code or handle secrets management. For more information, see [What are managed identities for Azure resources?](../managed-identities-azure-resources/overview.md)

+* **Device identity**: A device identity verifies the device in the authentication flow has undergone a process to attest the device is legitimate and meets the technical requirements. Once the device has successfully completed this process, the associated identity can be used to further control access to an organization's resources. With Azure AD, devices can authenticate with a certificate.

+Some legacy scenarios required a human identity to be used in *non-human* scenarios. For example, when service accounts being used in on-premises applications such as scripts or batch jobs require access to Azure AD. This pattern isn't recommended and we recommend you use [certificates](../authentication/concept-certificate-based-authentication-technical-deep-dive.md). However, if you do use a human identity with password for authentication, protect your Azure AD accounts with [Azure Active Directory Multi-Factor Authentication](../authentication/concept-mfa-howitworks.md).

+**Hybrid identity**. A hybrid identity is an identity that spans on-premises and cloud environments. This provides the benefit of being able to use the same identity to access on-premises and cloud resources. The source of authority in this scenario is typically an on-premises directory, and the identity lifecycle around provisioning, de-provisioning and resource assignment is also driven from on-premises. For more information, see [Hybrid identity documentation](../hybrid/index.yml).

+**Directory objects**. An Azure AD tenant contains the following common objects:

+* **User objects** represent human identities and non-human identities for services that currently don't support service principals. User objects contain attributes that have the required information about the user including personal details, group memberships, devices, and roles assigned to the user.

+* **Device objects** represent devices that are associated with an Azure AD tenant. Device objects contain attributes that have the required information about the device. This includes the operating system, associated user, compliance state, and the nature of the association with the Azure AD tenant. This association can take multiple forms depending on the nature of the interaction and trust level of the device.

+ * **Hybrid Domain Joined**. Devices that are owned by the organization and [joined](../devices/concept-hybrid-join.md) to both the on-premises Active Directory and Azure AD. Typically a device purchased and managed by an organization and managed by System Center Configuration Manager.

+ * **Azure AD Domain Joined**. Devices that are owned by the organization and joined to the organization's Azure AD tenant. Typically a device purchased and managed by an organization that is joined to Azure AD and managed by a service such as [Microsoft Intune](https://www.microsoft.com/microsoft-365/enterprise-mobility-security/microsoft-intune).

+ * **Azure AD Registered**. Devices not owned by the organization, for example, a personal device, used to access company resources. Organizations may require the device be enrolled via [Mobile Device Management (MDM)](https://www.microsoft.com/itshowcase/mobile-device-management-at-microsoft), or enforced through [Mobile Application Management (MAM)](/office365/enterprise/office-365-client-support-mobile-application-management) without enrollment to access resources. This capability can be provided by a service such as Microsoft Intune.

+* **Group objects** contain objects for the purposes of assigning resource access, applying controls, or configuration. Group objects contain attributes that have the required information about the group including the name, description, group members, group owners, and the group type. Groups in Azure AD take multiple forms based on an organization's requirements and can be mastered in Azure AD or synchronized from on-premises Active Directory Domain Services (AD DS).

+ * **Assigned groups**. In Assigned groups, users are added to or removed from the group manually, synchronized from on-premises AD DS, or updated as part of an automated scripted workflow. An assigned group can be synchronized from on-premises AD DS or can be homed in Azure AD.

+ * **Dynamic membership groups**. In Dynamic groups, users are assigned to the group automatically based on defined attributes. This allows group membership to be dynamically updated based on data held within the user objects. A dynamic group can only be homed in Azure AD.

+**Microsoft Account (MSA)**. You can create Azure subscriptions and tenants using Microsoft Accounts (MSA). A Microsoft Account is a personal account (as opposed to an organizational account) and is commonly used by developers and for trial scenarios. When used, the personal account is always made a guest in an Azure AD tenant.

+## Azure AD functional areas

+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/active-directory-whatis.md).

+### Authentication

+**Authentication**. Azure AD provides support for authentication protocols compliant with open standards such as Open ID Connect, OAuth and SAML. Azure AD also provides capabilities to allow organizations to federate existing on-premises identity providers such as Active Directory Federation Services (AD FS) to authenticate access to Azure AD integrated applications.

+Azure AD provides industry-leading strong authentication options that organizations can use to secure access to resources. Azure Active Directory Multi-Factor Authentication, device authentication and password-less capabilities allow organizations to deploy strong authentication options that suit their workforce's requirements.

+**Single sign-on (SSO)**. With single sign-on, users sign in once with one account to access all resources that trust the directory such as domain-joined devices, company resources, software as a service (SaaS) applications, and all Azure AD integrated applications. For more information, see [single sign-on to applications in Azure Active Directory](../manage-apps/what-is-single-sign-on.md).

+### Authorization

+**Resource access assignment**. Azure AD provides and secures access to resources. Assigning access to a resource in Azure AD can be done in two ways:

+* **User assignment**: The user is directly assigned access to the resource and the appropriate role or permission is assigned to the user.

+* **Group assignment**: A group containing one or more users is assigned to the resource and the appropriate role or permission is assigned to the group

+**Application access policies**. Azure AD provides capabilities to further control and secure access to your organization's applications.

+**Conditional Access**. Azure AD Conditional Access policies are tools to bring user and device context into the authorization flow when accessing Azure AD resources. Organizations should explore use of Conditional Access policies to allow, deny, or enhance authentication based on user, risk, device, and network context. For more information, see the [Azure AD Conditional Access documentation](../conditional-access/index.yml).

+**Azure AD Identity Protection**. This feature enables organizations to automate the detection and remediation of identity-based risks, investigate risks, and export risk detection data to third-party utilities for further analysis. For more information, see [overview on Azure AD Identity Protection](../identity-protection/overview-identity-protection.md).

+### Administration

+**Identity management**. Azure AD provides tools to manage the lifecycle of user, group, and device identities. [Azure AD Connect](../hybrid/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.

+Azure AD also provides a portal and the Microsoft Graph API to allow organizations to manage identities or integrate Azure AD identity management into existing workflows or automation. To learn more about Microsoft Graph, see [Use the Microsoft Graph API](/graph/use-the-api).

+**Device management**. Azure AD is used to manage the lifecycle and integration with cloud and on-premises device management infrastructures. It also is used to define policies to control access from cloud or on-premises devices to your organizational data. Azure AD provides the lifecycle services of devices in the directory and the credential provisioning to enable authentication. It also manages a key attribute of a device in the system that is the level of trust. This detail is important when designing a resource access policy. For more information, see [Azure AD Device Management documentation](../devices/index.yml).

+**Configuration management**. Azure AD has service elements that need to be configured and managed to ensure the service is configured to an organization's requirements. These elements include domain management, SSO configuration, and application management to name but a few. Azure AD provides a portal and the Microsoft Graph API to allow organizations to manage these elements or integrate into existing processes. To learn more about Microsoft Graph, see [Use the Microsoft Graph API](/graph/use-the-api).

+### Governance

+**Identity lifecycle**. Azure AD provides capabilities to create, retrieve, delete, and update identities in the directory, including external identities. Azure AD also [provides services to automate the identity lifecycle](../app-provisioning/how-provisioning-works.md) to ensure it's maintained in line with your organization's needs. For example, using Access Reviews to remove external users who haven't signed in for a specified period.

+**Reporting and analytics**. An important aspect of identity governance is visibility into user actions. Azure AD provides insights into your environment's security and usage patterns. These insights include detailed information on:

+* What your users access

+* Where they access it from

+* The devices they use

+* Applications used to access

+Azure AD also provides information on the actions that are being performed within Azure AD, and reports on security risks. For more information, see [Azure Active Directory reports and monitoring](../reports-monitoring/index.yml).

+**Auditing**. Auditing provides traceability through logs for all changes done by specific features within Azure AD. Examples of activities found in audit logs include changes made to any resources within Azure AD like adding or removing users, apps, groups, roles, and policies. Reporting in Azure AD enables you to audit sign-in activities, risky sign-ins, and users flagged for risk. For more information, see [Audit activity reports in the Azure portal](../reports-monitoring/concept-audit-logs.md).

+**Access certification**. Access certification is the process to prove that a user is entitled to have access to a resource at a point in time. Azure AD Access Reviews continually review the memberships of groups or applications and provide insight to determine whether access is required or should be removed. This enables organizations to effectively manage group memberships, access to enterprise applications, and role assignments to make sure only the right people have continued access. For more information, see [What are Azure AD access reviews?](../governance/access-reviews-overview.md)

+**Privileged access**. [Azure AD Privileged Identity Management](../privileged-identity-management/pim-configure.md) (PIM) provides time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions to Azure resources. It's used to protect privileged accounts by lowering the exposure time of privileges and increasing visibility into their use through reports and alerts.

+### Self-service management

+**Credential registration**. Azure AD provides capabilities to manage all aspects of user identity lifecycle and self-service capabilities to reduce the workload of an organization's helpdesk.

+**Group management**. Azure AD provides capabilities that enable users to request membership in a group for resource access and to create groups that can be used for securing resources or collaboration. These capabilities can be controlled by the organization so that appropriate controls are put in place.

+### Consumer Identity and Access Management (IAM)

+**Azure AD B2C**. Azure AD B2C is a service that can be enabled in an Azure subscription to provide identities to consumers for your organization's customer-facing applications. This is a separate island of identity and these users don't appear in the organization's Azure AD tenant. Azure AD B2C is managed by administrators in the tenant associated with the Azure subscription.

+## Next steps

+* [Introduction to delegated administration and isolated environments](secure-introduction.md)

+* [Azure resource management fundamentals](secure-resource-management.md)

+* [Resource isolation in a single tenant](secure-single-tenant.md)

+* [Resource isolation with multiple tenants](secure-multiple-tenants.md)

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

+ Title: Delegated administration to secure with Azure Active Directory

+description: Introduction to delegated administration and isolated environments in Azure Active Directory.

+# Introduction to delegated administration and isolated environments

+An Azure Active Directory (Azure AD) single-tenant architecture with delegated administration is often adequate for separating environments. As detailed in other sections of this article, Microsoft provides many tools to do this. However, there may be times when your organization requires a degree of isolation beyond what can be achieved in a single tenant.

+Before discussing specific architectures, it's important to understand:

+* How a typical single tenant works.

+* How administrative units in Azure AD work.

+* The relationships between Azure resources and Azure AD tenants.

+* Common requirements driving isolation.

+## Azure AD tenant as a security boundary

+An Azure AD tenant provides identity and access management (IAM) capabilities to applications and resources used by the organization.

+An identity is a directory object that can be authenticated and authorized for access to a resource. Identity objects exist for human identities and non-human identities. To differentiate between human and non-human identities, human identities are referred to as identities and non-human identities are referred to as workload identities. Non-human entities include application objects, service principals, managed identities, and devices. The terminology is inconsistent across the industry, but generally a workload identity is something you need for your software entity to authenticate with some system.

+To distinguish between human and non-human identities, different terms are emerging across the IT industry to distinguish between the two:

+* **Identity** - Identity started by describing the Active Directory (AD) and Azure AD object used by humans to authenticate. In this series of articles, identity refers to objects that represent humans.

+* **Workload identity** - In Azure Active Directory (Azure AD), workload identities are applications, service principals, and managed identities. The workload identity is used to authenticate and access other services and resources.

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

+The Azure AD tenant is an identity security boundary that is under the control of global administrators. Within this security boundary, administration of subscriptions, management groups, and resource groups can be delegated to segment administrative control of Azure resources. While not directly interacting, these groupings are dependent on tenant-wide configurations of policies and settings. And those settings and configurations are under the control of the Azure AD Global Administrators.

+Azure AD is used to grant objects representing identities access to applications and Azure resources. In that sense both Azure resources and applications trusting Azure AD are resources that can be managed with Azure AD. In the following diagram, The Azure AD tenant boundary shows the Azure AD identity objects and the configuration tools. Below the directory are the resources that use the identity objects for identity and access management. Following best practices, the environment is set up with a test environment to test the proper operation of IAM.

+

+### Access to apps that use Azure AD

+Identities can be granted access to many types of applications. Examples include:

+* Microsoft productivity services such as Exchange Online, Microsoft Teams, and SharePoint Online

+* Microsoft IT services such as Azure Sentinel, Microsoft Intune, and Microsoft 365 Defender ATP

+* Microsoft Developer tools such as Azure DevOps and Microsoft Graph API

+* SaaS solutions such as Salesforce and ServiceNow

+* On-premises applications integrated with hybrid access capabilities such as Azure AD Application Proxy

+* Custom in-house developed applications

+Applications that use Azure AD require directory objects to be configured and managed in the trusted Azure AD tenant. Examples of directory objects include application registrations, service principals, groups, and [schema attribute extensions](/graph/extensibility-overview).

+### Access to Azure resources

+Users, groups, and service principal objects (workload identities) in the Azure AD tenant are granted roles by using [Azure Role Based Access Control](../../role-based-access-control/overview.md) (RBAC) and [Azure attribute-based access control](../../role-based-access-control/conditions-overview.md) (ABAC).

+* Azure RBAC enables you to provide access based on role as determined by security principal, role definition, and scope.

+* Azure ABAC builds on Azure RBAC by adding role assignment conditions based on attributes in the context of specific actions. A role assignment condition is another check that you can optionally add to your role assignment to provide more fine-grained access control.

+Azure resources, resource groups, subscriptions, and management groups are accessed through using these assigned RBAC roles. For example, the following diagram shows distribution of administrative capability in Azure AD using role-based access control.

+

+Azure resources that [support Managed Identities](../managed-identities-azure-resources/overview.md) allow resources to authenticate, be granted access to, and be assigned roles to other resources within the Azure AD tenant boundary.

+Applications using Azure AD for sign-in may also use Azure resources such as compute or storage as part of its implementation. For example, a custom application that runs in Azure and trusts Azure AD for authentication has directory objects and Azure resources.

+Lastly, all Azure resources in the Azure AD tenant affect tenant-wide [Azure Quotas and Limits](../../azure-resource-manager/management/azure-subscription-service-limits.md).

+### Access to Directory Objects

+As outlined in the previous diagram, identities, resources, and their relationships are represented in an Azure AD tenant as directory objects. Examples of directory objects include users, groups, service principals, and app registrations.

+Having a set of directory objects in the Azure AD tenant boundary engenders the following Capabilities:

+* Visibility. Identities can discover or enumerate resources, users, groups, access usage reporting and audit logs based on their permissions. For example, a member of the directory can discover users in the directory per Azure AD [default user permissions](../fundamentals/users-default-permissions.md).

+* Applications can affect objects. Applications can manipulate directory objects through Microsoft Graph as part of their business logic. Typical examples include reading/setting user attributes, updating user's calendar, sending emails on behalf of the user, etc. Consent is necessary to allow applications to affect the tenant. Administrators can consent for all users. For more information, see [Permissions and consent in the Microsoft identity platform](../develop/v2-admin-consent.md).

+>[!NOTE]

+>Use caution when using application permissions. For example, with Exchange Online, you should [scope application permissions to specific mailboxes and permissions](/graph/auth-limit-mailbox-access).

+* Throttling and service limits. Runtime behavior of a resource might trigger [throttling](/graph/throttling) in order to prevent overuse or service degradation. Throttling can occur at the application, tenant, or entire service level. Most commonly it occurs when an application has a large number of requests within or across tenants. Similarly, there are [Azure AD service limits and restrictions](../enterprise-users/directory-service-limits-restrictions.md) that might affect the runtime behavior of applications.

+## Administrative units for role management

+Administrative units restrict permissions in a role to any portion of your organization that you define. You could, for example, use administrative units to delegate the [Helpdesk Administrator](../roles/permissions-reference.md) role to regional support specialists, so they can manage users only in the region that they support. An administrative unit is an Azure AD resource that can be a container for other Azure AD resources. An administrative unit can contain only:

+* Users

+* Groups

+* Devices

+In the following diagram, administrative units are used to segment the Azure AD tenant further based on the business or organizational structure. This is useful when different business units or groups have dedicated IT support staff. The administrative units can be used to provide privileged permissions that are limited to a designated administrative unit.

+

+For more information on administrative units, see [Administrative units in Azure Active Directory](../roles/administrative-units.md).

+### Common reasons for resource isolation

+Sometimes a group of resources should be isolated from other resources for security or other reasons, such as the resources have unique access requirements. This is a good use case for using administrative units. You must determine which users and security principals should have resource access and in what roles. Reasons to isolate resources might include:

+* Developer teams need the flexibility to safely iterate during the software development lifecycle of apps. But the development and testing of apps that write to Azure AD can potentially affect the Azure AD tenant through write operations. Some examples of this include:

+ * New applications that may change Office 365 content such as SharePoint sites, OneDrive, MS Teams, etc.

+ * Custom applications that can change data of users with MS Graph or similar APIs at scale (for example, applications that are granted Directory.ReadWrite.All)

+ * DevOps scripts that update large sets of objects as part of a deployment lifecycle.

+ * Developers of Azure AD integrated apps need the ability to create user objects for testing, and those user objects shouldn't have access to production resources.

+* Nonproduction Azure resources and applications that may affect other resources. For example, a new beta version of a SaaS application may need to be isolated from the production instance of the application and production user objects

+* Secret resources that should be shielded from discovery, enumeration, or takeover from existing administrators for regulatory or business critical reasons.

+## Configuration in a tenant

+Configuration settings in Azure AD can affect any resource in the Azure AD tenant through targeted, or tenant-wide management actions. Examples of tenant-wide settings include:

+* **External identities**: Global administrators for the tenant identify and control the external identities that can be provisioned in the tenant.

+ * Whether to allow external identities in the tenant.

+ * From which domain(s) external identities can be added.

+ * Whether users can invite users from other tenants.

+* **Named Locations**: Global administrators can create named locations, which can then be used to

+ * Block sign-ins from specific locations.

+ * Trigger conditional access policies such as MFA.

+ * Bypass security requirements

+>[!NOTE]

+>Using [Named Locations](../conditional-access/location-condition.md) can present some challenges to your [zero-trust journey](https://www.microsoft.com/security/business/zero-trust). Verify that using Named Locations fits into your security strategy and principles.

+Allowed authentication methods: Global administrators set the authentication methods allowed for the tenant.

+* **Self-service options**. Global Administrators set self-service options such as self-service-password reset and create Microsoft 365 groups at the tenant level.

+The implementation of some tenant-wide configurations can be scoped as long as they don't get overridden by global administration policies. For example:

+* If the tenant is configured to allow external identities, a resource administrator can still exclude those identities from accessing a resource.

+* If the tenant is configured to allow personal device registration, a resource administrator can exclude those devices from accessing specific resources.

+* If named locations are configured, a resource administrator can configure policies either allowing or excluding access from those locations.

+### Common reasons for configuration isolation

+Configurations, controlled by Global Administrators, affect resources. While some tenant-wide configuration can be scoped with policies to not apply or partially apply to a specific resource, others can't. If a resource has configuration needs that are unique, isolate it in a separate tenant. Examples of configuration isolation scenarios include:

+* Resources having requirements that conflict with existing tenant-wide security or collaboration postures. (for example allowed authentication types, device management policies, ability to self-service, identity proofing for external identities, etc.).

+* Compliance requirements that scope certification to the entire environment, including all resources and the Azure AD tenant itself, especially when those requirements conflict with or must exclude other organizational resources.

+* External user access requirements that conflict with production or sensitive resource policies.

+* Organizations that span multiple countries/regions, and companies hosted in a single Azure AD Tenant. For example, what settings and licenses are used in different countries/regions, or business subsidiaries.

+## Administration in a tenant

+Identities with privileged roles in the Azure AD tenant have the visibility and permissions to execute the configuration tasks described in the previous sections. Administration includes both the administration of identity objects such as users, groups, and devices, and the scoped implementation of tenant-wide configurations for authentication, authorization, etc.

+### Administration of directory objects

+Administrators manage how identity objects can access resources, and under what circumstances. They also can disable, delete, or modify directory objects based on their privileges. Identity objects include:

+* **Organizational identities**, such as the following, are represented by user objects:

+ * Administrators

+ * Organizational users

+ * Organizational developers

+ * Service Accounts

+ * Test users

+* **External identities** represent users from outside the organization such as:

+ * Partners, suppliers, or vendors that are provisioned with accounts local to the organization environment

+ * Partners, suppliers, or vendors that are provisioned via Azure B2B collaboration

+* **Groups** are represented by objects such as:

+ * Security groups

+ * [Microsoft 365 groups](/microsoft-365/community/all-about-groups)

+ * Dynamic Groups

+ * Administrative Units

+* **Devices** are represented by objects such as:

+ * Hybrid Azure AD joined devices (On-premises computers synchronized from on-premises Active Directory)

+ * Azure AD joined devices

+ * Azure AD registered mobile devices used by employees to access their workplace applications.

+ * Azure AD registered down-level devices (legacy). For example, Windows 2012 R2.

+* **Workload Identities**

+ * Managed identities

+ * Service principals

+ * Applications

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

+### Administration of identity services

+Administrators with appropriate permissions can also manage how tenant-wide policies are implemented at the level of resource groups, security groups, or applications. When considering administration of resources, keep the following in mind. Each can be a reason to keep resources together, or to isolate them.

+* A **Global Administrator** can take control of any Azure subscription linked to the Tenant.

+* An **identity assigned an Authentication Administrator role** can require nonadministrators to reregister for MFA or FIDO authentication.

+* A **Conditional Access (CA) Administrator** can create CA policies that require users signing-in to specific apps to do so only from organization-owned devices. They can also scope configurations. For example, even if external identities are allowed in the tenant, they can exclude those identities from accessing a resource.

+* A **Cloud Application Administrator** can consent to application permissions on behalf of all users.

+### Common reasons for administrative isolation

+Who should have the ability to administer the environment and its resources? There are times when administrators of one environment must not have access to another environment. Examples include:

+* Separation of tenant-wide administrative responsibilities to further mitigate the risk of security and operational errors affecting critical resources.

+* Regulations that constrain who can administer the environment based on conditions such as citizenship, residency, clearance level, etc. that can't be accommodated with staff.

+## Security and operational considerations

+Given the interdependence between an Azure AD tenant and its resources, it's critical to understand the security and operational risks of compromise or error. If you're operating in a federated environment with synchronized accounts, an on-premises compromise can lead to an Azure AD compromise.

+* **Identity compromise** - Within the boundary of a tenant, any identity can be assigned any role, given the one providing access has sufficient privileges. While the effect of compromised non-privileged identities is largely contained, compromised administrators can have broad implications. For example, if an Azure AD global administrator account is compromised, Azure resources can become compromised. To mitigate risk of identity compromise, or bad actors, implement [tiered administration](/security/compass/privileged-access-access-model) and ensure that you follow principles of least privilege for [Azure AD Administrator Roles](../roles/delegate-by-task.md). Similarly, ensure that you create CA policies that specifically exclude test accounts and test service principals from accessing resources outside of the test applications. For more information on privileged access strategy, see [Privileged access: Strategy](/security/compass/privileged-access-strategy).

+* **Federated environment compromise**

+* **Trusting resource compromise** - Human identities aren't the only security consideration. Any compromised component of the Azure AD tenant can affect trusting resources based on its level of permissions at the tenant and resource level. The effect of a compromised component of an Azure AD trusting resource is determined by the privileges of the resource; resources that are deeply integrated with the directory to perform write operations can have profound impact in the entire tenant. Following [guidance for zero trust](/azure/architecture/guide/security/conditional-access-zero-trust) can help limit the impact of compromise.

+* **Application development** - Early stages of the development lifecycle for applications with writing privileges to Azure AD, where bugs can unintentionally write changes to the Azure AD objects, present a risk. Follow [Microsoft Identity platform best practices](../develop/identity-platform-integration-checklist.md) during development to mitigate these risks.

+* **Operational error** - A security incident can occur not only due to bad actors, but also because of an operational error by tenant administrators or the resource owners. These risks occur in any architecture. Mitigate these risks with separation of duties, tiered administration, following principles of least privilege, and following best practices before trying to mitigate by using a separate tenant.

+Incorporating zero-trust principles into your Azure AD design strategy can help guide your design to mitigate these considerations. For more information, visit [Embrace proactive security with Zero Trust](https://www.microsoft.com/security/business/zero-trust).

+## Next steps

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

+* [Azure resource management fundamentals](secure-resource-management.md)

+* [Resource isolation in a single tenant](secure-single-tenant.md)

+* [Resource isolation with multiple tenants](secure-multiple-tenants.md)

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

+ Title: Resource isolation with multiple tenants to secure with Azure Active Directory

+description: Introduction to resource isolation with multiple tenants in Azure Active Directory.

+# Resource isolation with multiple tenants

+There are specific scenarios when delegating administration in a single tenant boundary doesn't meet your needs. In this section, there are requirements that may drive you to create a multi-tenant architecture. Multi-tenant organizations might span two or more Azure AD tenants. This can result in unique cross-tenant collaboration and management requirements. Multi-tenant architectures increase management overhead and complexity and should be used with caution. We recommend using a single tenant if your needs can be met with that architecture. For more detailed information, see [Multi-tenant user management](multi-tenant-user-management-introduction.md).

+A separate tenant creates a new boundary, and therefore decoupled management of Azure AD directory roles, directory objects, conditional access policies, Azure resource groups, Azure management groups, and other controls as described in previous sections.

+A separate tenant is useful for an organization's IT department to validate tenant-wide changes in Microsoft services such as, Intune, Azure AD Connect, or a hybrid authentication configuration while protecting an organization's users and resources. This includes testing service configurations that might have tenant-wide effects and can't be scoped to a subset of users in the production tenant.

+Deploying a non-production environment in a separate tenant might be necessary during development of custom applications that can change data of production user objects with MS Graph or similar APIs (for example, applications that are granted Directory.ReadWrite.All, or similar wide scope).

+>[!Note]

+>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/plan-connect-topologies.md).

+## Outcomes

+In addition to the outcomes achieved with a single tenant architecture as described previously, organizations can fully decouple the resource and tenant interactions:

+### Resource separation

+* **Visibility** - Resources in a separate tenant can't be discovered or enumerated by users and administrators in other tenants. Similarly, usage reports and audit logs are contained within the new tenant boundary. This separation of visibility allows organizations to manage resources needed for confidential projects.

+* **Object footprint** - Applications that write to Azure AD and/or other Microsoft Online services through Microsoft Graph or other management interfaces can operate in a separate object space. This enables development teams to perform tests during the software development lifecycle without affecting other tenants.

+* **Quotas** - Consumption of tenant-wide [Azure Quotas and Limits](../../azure-resource-manager/management/azure-subscription-service-limits.md) is separated from that of the other tenants.

+### Configuration separation

+A new tenant provides a separate set of tenant-wide settings that can accommodate resources and trusting applications that have requirements that need different configurations at the tenant level. Additionally, a new tenant provides a new set of Microsoft Online services such as Office 365.

+### Administrative separation

+A new tenant boundary involves a separate set of Azure AD directory roles, which enables you to configure different sets of administrators.

+## Common usage

+The following diagram illustrates a common usage for resource isolation in multiple tenants: a pre-production or "sandbox" environment that requires more separation than can be achieved with delegated administration in a single tenant.

+ 

+Contoso is an organization that augmented their corporate tenant architecture with a pre-production tenant called ContosoSandbox.com. The sandbox tenant is used to support ongoing development of enterprise solutions that write to Azure AD and Microsoft 365 using Microsoft Graph. These solutions are deployed in the corporate tenant.

+The sandbox tenant is brought online to prevent those applications under development from impacting production systems either directly or indirectly, by consuming tenant resources and affecting quotas, or throttling.

+Developers require access to the sandbox tenant during the development lifecycle, ideally with self-service access requiring additional permissions that are restricted in the production environment. Examples of these additional permissions might include creating, deleting, and updating user accounts, registering applications, provisioning and deprovisioning Azure resources, and changes to policies or overall configuration of the environment.

+In this example, Contoso uses [Azure AD B2B Collaboration](../external-identities/what-is-b2b.md) to provision users from the corporate tenant to enable users that can manage and access resources in applications in the sandbox tenant without managing multiple credentials. This capability is primarily oriented to cross-organization collaboration scenarios. However, enterprises with multiple tenants like Contoso can use this capability to avoid additional credential lifecycle administration and user experience complexities.

+Use [External Identities cross-tenant access](../external-identities/cross-tenant-access-settings-b2b-collaboration.md) settings to manage how you collaborate with other Azure AD organizations through B2B collaboration. These settings determine both the level of inbound access users in external Azure AD organizations have to your resources, and the level of outbound access your users have to external organizations. They also let you trust multifactor authentication (MFA) and device claims ([compliant claims and hybrid Azure AD joined claims](../conditional-access/howto-conditional-access-policy-compliant-device.md)) from other Azure AD organizations. For details and planning considerations, see [Cross-tenant access in Azure AD External Identities](../external-identities/cross-tenant-access-overview.md).

+Another approach could have been to utilize the capabilities of Azure AD Connect to sync the same on-premises Azure AD credentials to multiple tenants, keeping the same password but differentiating on the users UPN domain.

+## Multi-tenant resource isolation

+With a new tenant, you have a separate set of administrators. Organizations can choose to use corporate identities through [Azure AD B2B collaboration](../external-identities/what-is-b2b.md). Similarly, organizations can implement [Azure Lighthouse](../../lighthouse/overview.md) for cross-tenant management of Azure resources so that non-production Azure subscriptions are managed by identities in the production counterpart. Azure Lighthouse can't be used to manage services outside of Azure, such as Microsoft Intune. For Managed Service Providers (MSPs), [Microsoft 365 Lighthouse](/microsoft-365/lighthouse/m365-lighthouse-overview?view=o365-worldwide&preserve-view=true) is an admin portal that helps secure and manage devices, data, and users at scale for small- and medium-sized business (SMB) customers who are using Microsoft 365 Business Premium, Microsoft 365 E3, or Windows 365 Business.

+This will allow users to continue to use their corporate credentials, while achieving the benefits of separation.

+Azure AD B2B collaboration in sandbox tenants should be configured to allow only identities from the corporate environment to be onboarded using Azure B2B [allow/deny lists](../external-identities/allow-deny-list.md). For tenants that you do want to allow for B2B consider using External Identities cross-tenant access settings for cross tenant multifactor authentication\Device trust.

+>[!IMPORTANT]

+>Multi-tenant architectures with external identity access enabled provide only resource isolation, but don't enable identity isolation. Resource isolation using Azure AD B2B collaboration and Azure Lighthouse don't mitigate risks related to identities.

+If the sandbox environment shares identities with the corporate environment, the following scenarios are applicable to the sandbox tenant:

+* A malicious actor that compromises a user, a device, or hybrid infrastructure in the corporate tenant, and is invited into the sandbox tenant, might gain access to the sandbox tenant's apps and resources.

+* An operational error (for example, user account deletion or credential revocation) in the corporate tenant might affect the access of an invited user into the sandbox tenant.

+You must do the risk analysis and potentially consider identity isolation through multiple tenants for business-critical resources that require a highly defensive approach. Azure Privileged Identity Management can help mitigate some of the risks by imposing extra security for accessing business critical tenants and resources.

+### Directory objects

+The tenant you use to isolate resources may contain the same types of objects, Azure resources, and trusting applications as your primary tenant. You may need to provision the following object types:

+**Users and groups**: Identities needed by solution engineering teams, such as:

+* Sandbox environment administrators.

+* Technical owners of applications.

+* Line-of-business application developers.

+* Test end-user accounts.

+These identities might be provisioned for:

+* Employees who come with their corporate account through [Azure AD B2B collaboration](../external-identities/what-is-b2b.md).

+* Employees who need local accounts for administration, emergency administrative access, or other technical reasons.

+Customers who have or require non-production Active Directory on-premises can also synchronize their on-premises identities to the sandbox tenant if needed by the underlying resources and applications.

+**Devices**: The non-production tenant contains a reduced number of devices to the extent that are needed in the solution engineering cycle:

+* Administration workstations

+* Non-production computers and mobile devices needed for development, testing, and documentation

+### Applications

+Azure AD integrated applications: Application objects and service principals for:

+* Test instances of the applications that are deployed in production (for example, applications that write to Azure AD and Microsoft online services).

+* Infrastructure services to manage and maintain the non-production tenant, potentially a subset of the solutions available in the corporate tenant.

+Microsoft Online

+* Typically, the team that owns the Microsoft Online Services in production should be the one owning the non-production instance of those services.

+* Administrators of non-production test environments shouldn't be provisioning Microsoft Online Services unless those services are specifically being tested. This avoids inappropriate use of Microsoft services, for example setting up production SharePoint sites in a test environment.

+* Similarly, provisioning of Microsoft Online services that can be initiated by end users (also known as ad-hoc subscriptions) should be locked down. For more information, see [What is self-service sign-up for Azure Active Directory?](../enterprise-users/directory-self-service-signup.md).

+* Generally, all non-essential license features should be disabled for the tenant using group-based licensing. This should be done by the same team that manages licenses in the production tenant, to avoid misconfiguration by developers who might not know the effect of enabling licensed features.

+### Azure resources

+Any Azure resources needed by trusting applications may also be deployed. For example, databases, virtual machines, containers, Azure functions, etc. For your sandbox environment, you must weigh the cost savings of using less-expensive SKUs for products and services with the less security features available.

+The RBAC model for access control should still be employed in a non-production environment in case changes are replicated to production after tests have concluded. Failure to do so allows security flaws in the non-production environment to propagate to your production tenant.

+## Resource and identity isolation with multiple tenants

+### Isolation outcomes

+There are limited situations where resource isolation can't meet your requirements. You can isolate both resources and identities in a multi-tenant architecture by disabling all cross-tenant collaboration capabilities and effectively building a separate identity boundary. This approach is a defense against operational errors and compromise of user identities, devices, or hybrid infrastructure in corporate tenants.

+### Isolation common usage

+A separate identity boundary is typically used for business-critical applications and resources such as customer-facing services. In this scenario, Fabrikam has decided to create a separate tenant for their customer-facing SaaS product to avoid the risk of employee identity compromise affecting their SaaS customers. The following diagram illustrates this architecture:

+The FabrikamSaaS tenant contains the environments used for applications that are offered to customers as part of Fabrikam's business model.

+### Isolation of directory objects

+The directory objects in FabrikamSaas are as follows:

+Users and groups: Identities needed by solution IT teams, customer support staff, or other necessary personnel are created within the SaaS tenant. To preserve isolation, only local accounts are used, and Azure AD B2B collaboration isn't enabled.

+Azure AD B2C directory objects: If the tenant environments are accessed by customers, it may contain an Azure AD B2C tenant and its associated identity objects. Subscriptions that hold these directories are good candidates for an isolated consumer-facing environment.

+Devices: This tenant contains a reduced number of devices; only those that are needed to run customer-facing solutions:

+* Secure administration workstations.

+* Support personnel workstations (this can include engineers who are "on call" as described above).

+### Isolation of applications

+**Azure AD integrated applications**: Application objects and service principals for:

+* Production applications (for example, multi-tenant application definitions).

+* Infrastructure services to manage and maintain the customer-facing environment.

+**Azure Resources**: Hosts the IaaS, PaaS and SaaS resources of the customer-facing production instances.

+## Next steps

+* [Introduction to delegated administration and isolated environments](secure-introduction.md)

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

+* [Azure resource management fundamentals](secure-resource-management.md)

+* [Resource isolation in a single tenant](secure-single-tenant.md)

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

+ Title: Resource management fundamentals in Azure Active Directory

+description: Introduction to resource management in Azure Active Directory.

+# Azure resource management fundamentals

+It's important to understand the structure and terms that are specific to Azure resources. The following image shows an example of the four levels of scope that are provided by Azure:

+

+## Terminology

+The following are some of the terms you should be familiar with:

+**Resource** - A manageable item that is available through Azure. Virtual machines, storage accounts, web apps, databases, and virtual networks are examples of resources.

+**Resource group** - A container that holds related resources for an Azure solution such as a collection of virtual machines, associated VNets, and load balancers that require management by specific teams. The [resource group](../../azure-resource-manager/management/overview.md) includes those resources that you want to manage as a group. You decide which resources belong in a resource group based on what makes the most sense for your organization. Resource groups can also be used to help with life-cycle management by deleting all resources that have the same lifespan at one time. This approach also provides security benefit by leaving no fragments that might be exploited.

+**Subscription** - From an organizational hierarchy perspective, a subscription is a billing and management container of resources and resource groups. An Azure subscription has a trust relationship with Azure AD. A subscription trusts Azure AD to authenticate users, services, and devices.

+>[!Note]

+>A subscription may trust only one Azure AD tenant. However, each tenant may trust multiple subscriptions and subscriptions can be moved between tenants.

+**Management group** - [Azure management groups](../../governance/management-groups/overview.md) provide a hierarchical method of applying policies and compliance at different scopes above subscriptions. It can be at the tenant root management group (highest scope) or at lower levels in the hierarchy. You organize subscriptions into containers called "management groups" and apply your governance conditions to the management groups. All subscriptions within a management group automatically inherit the conditions applied to the management group. Note, policy definitions can be applied to a management group or subscription.

+**Resource provider** - A service that supplies Azure resources. For example, a common [resource provider](../../azure-resource-manager/management/resource-providers-and-types.md) is Microsoft. Compute, which supplies the virtual machine resource. Microsoft. Storage is another common resource provider.

+**Resource Manager template** - A JavaScript Object Notation (JSON) file that defines one or more resources to deploy to a resource group, subscription, tenant, or management group. The template can be used to deploy the resources consistently and repeatedly. See [Template deployment overview](../../azure-resource-manager/templates/overview.md). Additionally, the [Bicep language](../../azure-resource-manager/bicep/overview.md) can be used instead of JSON.

+## Azure Resource Management Model

+Each Azure subscription is associated with controls used by [Azure Resource Manager](../../azure-resource-manager/management/overview.md) (ARM). Resource Manager is the deployment and management service for Azure, it has a trust relationship with Azure AD for identity management for organizations, and the Microsoft Account (MSA) for individuals. Resource Manager provides a management layer that enables you to create, update, and delete resources in your Azure subscription. You use management features like access control, locks, and tags, to secure and organize your resources after deployment.

+>[!NOTE]

+>Prior to ARM, there was another deployment model named Azure Service Manager (ASM) or "classic". To learn more, see [Azure Resource Manager vs. classic deployment](../../azure-resource-manager/management/deployment-models.md). Managing environments with the ASM model is out of scope of this content.

+Azure Resource Manager is the front-end service, which hosts the REST APIs used by PowerShell, the Azure portal, or other clients to manage resources. When a client makes a request to manage a specific resource, Resource Manager proxies the request to the resource provider to complete the request. For example, if a client makes a request to manage a virtual machine resource, Resource Manager proxies the request to the Microsoft. Compute resource provider. Resource Manager requires the client to specify an identifier for both the subscription and the resource group to manage the virtual machine resource.

+Before any resource management request can be executed by Resource Manager, a set of controls is checked.

+* **Valid user check** - The user requesting to manage the resource must have an account in the Azure AD tenant associated with the subscription of the managed resource.

+* **User permission check** - Permissions are assigned to users using [role-based access control (RBAC)](../../role-based-access-control/overview.md). An RBAC role specifies a set of permissions a user may take on a specific resource. RBAC helps you manage who has access to Azure resources, what they can do with those resources, and what areas they have access to.

+* **Azure policy check** - [Azure policies](../../governance/policy/overview.md) specify the operations allowed or explicitly denied for a specific resource. For example, a policy can specify that users are only allowed (or not allowed) to deploy a specific type of virtual machine.

+The following diagram summarizes the resource model we just described.

+

+**Azure Lighthouse** - [Azure Lighthouse](../../lighthouse/overview.md) enables resource management across tenants. Organizations can delegate roles at the subscription or resource group level to identities in another tenant.

+Subscriptions that enable [delegated resource management](../../lighthouse/concepts/azure-delegated-resource-management.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.

+It's worth noting that Azure Lighthouse itself is modeled as an Azure resource provider, which means that aspects of the delegation across a tenant can be targeted through Azure Policies.

+**Microsoft 365 Lighthouse** - [Microsoft 365 Lighthouse](/microsoft-365/lighthouse/m365-lighthouse-overview?view=o365-worldwide&preserve-view=true) is an admin portal that helps Managed Service Providers (MSPs) secure and manage devices, data, and users at scale for small- and medium-sized business (SMB) customers who are using Microsoft 365 Business Premium, Microsoft 365 E3, or Windows 365 Business.

+## Azure resource management with Azure AD

+Now that you have a better understanding of the resource management model in Azure, let's briefly examine some of the capabilities of Azure AD that can provide identity and access management for Azure resources.

+### Billing

+Billing is important to resource management because some billing roles interact with or can manage resources. Billing works differently depending on the type of agreement that you have with Microsoft.

+#### Azure Enterprise Agreements

+Azure Enterprise Agreement (Azure EA) customers are onboarded to the Azure EA Portal upon execution of their commercial contract with Microsoft. Upon onboarding, an identity is associated to a "root" Enterprise Administrator billing role. The portal provides a hierarchy of management functions:

+* Departments help you segment costs into logical groupings and enable you to set a budget or quota at the department level.

+* Accounts are used to further segment departments. You can use accounts to manage subscriptions and to access reports.

+The EA portal can authorize Microsoft Accounts (MSA) or Azure AD accounts (identified in the portal as "Work or School Accounts"). Identities with the role of "Account Owner" in the EA portal can create Azure subscriptions.

+#### Enterprise billing and Azure AD tenants

+When an Account Owner creates an Azure subscription within an enterprise agreement, the identity and access management of the subscription is configured as follows:

+* The Azure subscription is associated with the same Azure AD tenant of the Account Owner.

+* The account owner who created the subscription will be assigned the Service Administrator and Account Administrator roles. (The Azure EA Portal assigns Azure Service Manager (ASM) or "classic" roles to manage subscriptions. To learn more, see [Azure Resource Manager vs. classic deployment](../../azure-resource-manager/management/deployment-models.md).)

+An enterprise agreement can be configured to support multiple tenants by setting the authentication type of "Work or school account cross-tenant" in the Azure EA Portal. Given the above, organizations can set multiple accounts for each tenant, and multiple subscriptions for each account, as shown in the diagram below.

+

+It's important to note that the default configuration described above grants the Azure EA Account Owner privileges to manage the resources in any subscriptions they created. For subscriptions holding production workloads, consider decoupling billing and resource management by changing the service administrator of the subscription right after creation.

+ To further decouple and prevent the account owner from regaining service administrator access to the subscription, the subscription's tenant can be [changed](../fundamentals/active-directory-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.

+To learn more, visit [Azure roles, Azure AD roles, and classic subscription administrator roles](../../role-based-access-control/rbac-and-directory-admin-roles.md).

+### Microsoft Customer Agreement

+Customers enrolled with a [Microsoft Customer Agreement](../../cost-management-billing/understand/mca-overview.md) (MCA) have a different billing management system with its own roles.

+A [billing account](../../cost-management-billing/manage/understand-mca-roles.md) for the Microsoft Customer Agreement contains one or more [billing profiles](../../cost-management-billing/manage/understand-mca-roles.md) that allow managing invoices and payment methods. Each billing profile contains one or more [invoice sections](../../cost-management-billing/manage/understand-mca-roles.md) to organize costs on the billing profile's invoice.

+In a Microsoft Customer Agreement, billing roles come from a single Azure AD tenant. To provision subscriptions for multiple tenants, the subscriptions must be initially created in the same Azure AD Tenant as the MCA, and then changed. In the diagram below, the subscriptions for the Corporate IT pre-production environment were moved to the ContosoSandbox tenant after creation.

+ 

+## RBAC and role assignments in Azure

+In the Azure AD Fundamentals section, you learned Azure RBAC is the authorization system that provides fine-grained access management to Azure resources, and includes many [built-in roles](../../role-based-access-control/built-in-roles.md). You can create [custom roles](../../role-based-access-control/custom-roles.md), and assign roles at different scopes. Permissions are enforced by assigning RBAC roles to objects requesting access to Azure resources.

+Azure AD roles operate on concepts like [Azure role-based access control](../../role-based-access-control/overview.md). The [difference be