Define a hybrid identity adoption strategy
In this task, you define the hybrid identity adoption strategy for your hybrid identity solution to meet the business requirements that were discussed in:
- Determine business needs
- Determine directory synchronization requirements
- Determine multi-factor authentication requirements
Define business needs strategy
The first task addresses determining the organizations business needs. This task can be broad and scope creep can occur if you aren't careful. In the beginning, keep it simple but always remember to plan for a design that will accommodate and facilitate change in the future. Regardless of whether it's a simple design or a complex one, Azure Active Directory is the Microsoft Identity platform that supports Microsoft 365, Microsoft Online Services, and cloud aware applications.
Define an integration strategy
Microsoft has three main integration scenarios: cloud identities, synchronized identities, and federated identities. You should plan on adopting one of these integration strategies. The strategy you choose can vary. Decisions in choosing one may include, what type of user experience you want to provide, do you've an existing infrastructure, and what is the most cost effective.
The scenarios defined in the above figure are:
- Cloud identities: identities that exist solely in the cloud. For Azure AD, they would reside specifically in your Azure AD directory.
- Synchronized: identities that exist on-premises and in the cloud. Using Azure AD Connect, users are either created or joined with existing Azure AD accounts. The user’s password hash is synchronized from the on-premises environment to the cloud in what is called a password hash. Remember that if a user is disabled in the on-premises environment, it can take up to three hours for that account status to show up in Azure AD. This behavior is due to the synchronization time interval.
- Federated: identities exist both on-premises and in the cloud. Using Azure AD Connect, users are either created or joined with existing Azure AD accounts.
For more information about the Synchronization options, read Integrating your on-premises identities with Azure Active Directory.
The following table helps in determining the advantages and disadvantages of each of the following strategies:
|Cloud identities||Easier to manage for small organization.
Nothing to install on-premises. No extra hardware needed
Easily disabled if the user leaves the company
|Users will need to sign in when accessing workloads in the cloud
Passwords may or may not be the same for cloud and on-premises identities
|Synchronized||On-premises password authenticates both on-premises and cloud directories
Easier to manage for small, medium, or large organizations
Users can have single sign-on (SSO) for some resources
Microsoft preferred method for synchronization
Easier to manage
|Some customers may be reluctant to synchronize their directories with the cloud due specific company’s policies|
|Federated||Users can have single sign-on (SSO)
If a user is terminated or leaves, the account can be immediately disabled and access revoked,
Supports advanced scenarios that can't be accomplished with synchronized
|More steps to set up and configure
May require extra hardware for the STS infrastructure
May require extra hardware to install the federation server. Other software is required if AD FS is used
Require extensive setup for SSO
Critical point of failure if the federation server is down, users won’t be able to authenticate
The strategy that you use will dictate the user sign-in experience. The following tables provide you with information on what the users should expect their sign-in experience to be. Not all federated identity providers support SSO in all scenarios.
Domain-joined and private network applications:
|Application||Synchronized Identity||Federated Identity|
|Web Browsers||Forms-based authentication||single sign-on, sometimes required to supply organization ID|
|Outlook||Prompt for credentials||Prompt for credentials|
|Skype for Business (Lync)||Prompt for credentials||single sign-on for Lync, prompted credentials for Exchange|
|OneDrive for Business||Prompt for credentials||single sign-on|
|Office Pro Plus Subscription||Prompt for credentials||single sign-on|
External or untrusted sources:
|Application||Synchronized Identity||Federated Identity|
|Web Browsers||Forms-based authentication||Forms-based authentication|
|Outlook, Skype for Business (Lync), OneDrive for Business, Office subscription||Prompt for credentials||Prompt for credentials|
|Exchange ActiveSync||Prompt for credentials||single sign-on for Lync, prompted credentials for Exchange|
|Mobile apps||Prompt for credentials||Prompt for credentials|
If you've a third-party IdP or are going to use one to provide federation with Azure AD, you need to be aware of the following supported capabilities:
- Any SAML 2.0 provider that is compliant for the SP-Lite profile can support authentication to Azure AD and associated applications
- Supports passive authentication, which facilitates authentication to OWA, SPO, etc.
- Exchange Online clients can be supported via the SAML 2.0 Enhanced Client Profile (ECP)
You must also be aware of what capabilities won't be available:
- Without WS-Trust/Federation support, all other active clients break
- That means no Lync client, OneDrive client, Office Subscription, Office Mobile prior to Office 2016
- Transition of Office to passive authentication allows them to support pure SAML 2.0 IdPs, but support will still be on a client-by-client basis
For the most updated list read the article Azure AD federation compatibility list.
Define synchronization strategy
This task defines the tools that will be used to synchronize the organization’s on-premises data to the cloud and what topology you should use. Because, most organizations use Active Directory, information on using Azure AD Connect to address the questions above is provided in some detail. For environments that don't have Active Directory, there's information about using FIM 2010 R2 or MIM 2016 to help plan this strategy. However, future releases of Azure AD Connect will support LDAP directories, so depending on your timeline, this information may be able to assist.
Over the years, several synchronization tools have existed and used for various scenarios. Currently Azure AD Connect is the go to tool of choice for all supported scenarios. Azure AD Sync and DirSync are also still around and may even be present in your environment now.
For the latest information regarding the supported capabilities of each tool, read Directory integration tools comparison article.
When defining a synchronization strategy, the topology that is used must be determined. Depending on the information that was determined in step 2 you can determine which topology is the proper one to use. The single forest, single Azure AD topology is the most common and consists of a single Active Directory forest and a single instance of Azure AD. This topology is going to be used in most scenarios and is the expected topology when using Azure AD Connect Express installation as shown in the figure below.
Single Forest Scenario It's common for large and even small organizations to have multiple forests, as shown in Figure 5.
For more information about the different on-premises and Azure AD topologies with Azure AD Connect sync read the article Topologies for Azure AD Connect.
The multi-forest single Azure AD topology should be considered if the following items are true:
- Users have only 1 identity across all forests – the uniquely identifying users section below describes this scenario in more detail.
- The user authenticates to the forest in which their identity is located
- UPN and Source Anchor (immutable ID) will come from this forest
- All forests are accessible by Azure AD Connect – meaning it does not need to be domain joined and can be placed in a DMZ.
- Users have only one mailbox
- The forest that hosts a user’s mailbox has the best data quality for attributes visible in the Exchange Global Address List (GAL)
- If there's no mailbox on the user, then any forest may be used to contribute values
- If you've a linked mailbox, then there's also another account in a different forest used to sign in.
Objects that exist in both on-premises and in the cloud are “connected” via a unique identifier. In the context of Directory Synchronization, this unique identifier is referred to as the SourceAnchor. In the context of Single Sign-On, this identifier is referred to as the ImmutableId. Design concepts for Azure AD Connect for more considerations regarding the use of SourceAnchor.
If the above aren't true and you've more than one active account or more than one mailbox, Azure AD Connect will pick one and ignore the other. If you've linked mailboxes but no other account, accounts won't be exported to Azure AD and that user won't be a member of any groups. This behavior is different from how it was in the past with DirSync and is intentional to better support multi-forest scenarios. A multi-forest scenario is shown in the figure below.
Multi-forest multiple Azure AD scenario
It's recommended to have just a single directory in Azure AD for an organization. However, it's supported if a 1:1 relationship is kept between an Azure AD Connect sync server and an Azure AD directory. For each instance of Azure AD, you need an installation of Azure AD Connect. Also, Azure AD, by design is isolated and users in one instance of Azure AD, won't be able to see users in another instance.
It's possible and supported to connect one on-premises instance of Active Directory to multiple Azure AD directories as shown in the figure below:
Single-forest filtering scenario
The following statements must be true:
- Azure AD Connect sync servers must be configured for filtering so they each have a mutually exclusive set of objects. This done, for example, by scoping each server to a particular domain or OU.
- A DNS domain can only be registered in a single Azure AD directory so the UPNs of the users in the on-premises AD must use separate namespaces
- Users in one instance of Azure AD will only be able to see users from their instance. They won't be able to see users in the other instances
- Only one of the Azure AD directories can enable Exchange hybrid with the on-premises AD
- Mutual exclusivity also applies to write-back. Thus, some write-back features aren't supported with this topology since it's assumed to be a single on-premises configuration.
- Group write-back with default configuration
- Device write-back
The following items aren't supported and should not be chosen as an implementation:
- It isn't supported to have multiple Azure AD Connect sync servers connecting to the same Azure AD directory even if they are configured to synchronize mutually exclusive set of object
- It's unsupported to sync the same user to multiple Azure AD directories.
- It's also unsupported to make a configuration change to make users in one Azure AD to appear as contacts in another Azure AD directory.
- It's also unsupported to modify Azure AD Connect sync to connect to multiple Azure AD directories.
- Azure AD directories are by design isolated. It's unsupported to change the configuration of Azure AD Connect sync to read data from another Azure AD directory in an attempt to build a common and unified GAL between the directories. It's also unsupported to export users as contacts to another on-premises AD using Azure AD Connect sync.
If your organization restricts computers on your network from connecting to the Internet, this article lists the endpoints (FQDNs, IPv4, and IPv6 address ranges) that you should include in your outbound allow lists and Internet Explorer Trusted Sites Zone of client computers to ensure your computers can successfully use Microsoft 365. For more information read Office 365 URLs and IP address ranges.
Define multi-factor authentication strategy
In this task, you'll define the multi-factor authentication strategy to use. Azure AD Multi-Factor Authentication comes in two different versions. One is a cloud-based and the other is on-premises based using the Azure MFA Server. Based on the evaluation you did above you can determine which solution is the correct one for your strategy. Use the table below to determine which design option best fulfills your company’s security requirement:
Multi-factor design options:
|Asset to secure||MFA in the cloud||MFA on-premises|
|SaaS apps in the app gallery||yes||yes|
|IIS applications published through Azure AD App Proxy||yes||yes|
|IIS applications not published through the Azure AD App Proxy||no||yes|
|Remote access as VPN, RDG||no||yes|
Even though you may have settled on a solution for your strategy, you still need to use the evaluation from above. This decision may cause the solution to change. Use the table below to assist you determining this:
|User location||Preferred design option|
|Azure Active Directory||Multi-FactorAuthentication in the cloud|
|Azure AD and on-premises AD using federation with AD FS||Both|
|Azure AD and on-premises AD using Azure AD Connect no password sync||Both|
|Azure AD and on-premises using Azure AD Connect with password sync||Both|
|On-premises AD||Multi-Factor Authentication Server|
You should also ensure that the multi-factor authentication design option that you selected supports the features that are required for your design. For more information read Choose the multi-factor security solution for you.
Multi-Factor Auth Provider
Multi-factor authentication is available by default for Hybrid Identity Administrators who have an Azure Active Directory tenant. However, if you wish to extend multi-factor authentication to all of your users and/or want to your Hybrid Identity Administrators to be able to take advantage features such as the management portal, custom greetings, and reports, then you must purchase and configure Multi-Factor Authentication Provider.
You should also ensure that the multi-factor authentication design option that you selected supports the features that are required for your design.