Multi-forest Directory Sync with Single Sign-On Scenario
Published: November 21, 2013
Updated: December 2, 2013
Applies To: Office 365, Windows Azure, Windows Intune
A common requirement of many companies who have an established on-premises Active Directory environment is the ability to leverage their existing on-premises user and group accounts. With DirSync and the Windows Azure AD connector for FIM 2010, Microsoft offers two solutions for leveraging already existing on-premises user and group accounts. The objective of this topic is to provide you with the information you need to successfully plan and deploy a multi-forest synchronization solution in an enterprise environment using the Windows Azure AD connector for FIM 2010.
If you want to leverage your on-premises user and group accounts in your on-premises Active Directory environment, you can either use the Windows Azure Active Directory Sync tool (“DirSync”) or the Windows Azure AD connector for FIM 2010 to accomplish this goal.
In this context, the Windows Azure Active Directory Sync tool is the recommended solution for this scenario. However, while typically most business requirements can be addressed using DirSync, there are cases where the Windows Azure AD connector for FIM represents the better choice.
From a high-level perspective, DirSync represents a packaged implementation of FIM that is optimized and isolated to a scenario that enables you to connect a single on-premised Active Directory forest with your Windows Azure AD tenant. FIM is a highly customizable platform for managing distributed identities from a central point. For FIM, your Windows Azure AD tenant represents “just” one possible connection point that can be accessed using the Windows Azure AD connector for FIM. As a consequence of this, you are required to take care of all the steps that are necessary to integrate the Windows Azure AD connector for FIM into your FIM environment. While DirSync typically represents the right choice if you only need to connect to a single Active Directory forest with your Windows Azure AD tenant, the Windows Azure AD connector for FIM enables you to connect your tenant with a multi-forest environment.
In addition to synchronizing on-premises identity data with your Windows Azure AD tenant, a common requirement in this context is to provide a single sign-on (SSO) solution. DirSync provides a convenient SSO solution that is implemented in form of a password hash sync. This feature is not available when implementing the Windows Azure AD connector. The only SSO option you have for the Windows Azure AD connector is based on ADFS.
Windows Server 2012 R2 has introduced a new object type called device objects. This object type is not supported by the version of FIM (FIM 2010 R2 SP1) that is required for the Windows Azure AD connector.
You can use the following list of guidelines when making a decision for the right technology to leveraging existing on-premises user and group accounts:
Use DirSync if you haven’t deployed FIM yet and you need to synchronize from a single-forest Active Directory forest to Windows Azure AD.
Use DirSync if FIM you have deployed FIM and you need to synchronize from a single-forest Active Directory forest to Windows Azure AD.
Use the Windows Azure AD connector if you need to synchronize from a multi-forest Active Directory to Windows Azure AD.
Use the Windows Azure AD connector if you need to synchronize from a non-Active Directory source to Windows Azure AD.
Multi-forest synchronization using the Windows Azure AD Connector enables Windows Azure AD and Office 365 deployment options such as:
Hybrid deployment - Mailboxes for your organization can reside on-premises in an Exchange organization and in the cloud. In the hybrid deployment scenario, messaging functionality is seamless across the on-premises deployment and the cloud deployment. This hybrid deployment scenario can also include single sign-on, which lets users use their existing Active Directory on-premises credentials to access all on-premises and cloud resources.
All mailboxes in the cloud - If your long-term goal doesn’t require messaging functionality that spans cross-premises, you should plan to move all your mailboxes to the cloud. It may take a week or maybe months to complete this migration, but it is the best option if your ultimate objective is migrating all your mailboxes to the cloud.
Manage on-premises users with Office 365 tools - An alternative form of migration is to move all mailboxes to the cloud, but to continue to manage users and resources from your existing Active Directory. After you set up single sign-on and deploy the Windows Azure AD connector, users can use their Active Directory corporate credentials (user name and password) to access their new mailboxes in the cloud and their existing on-premises resources.
Provision users from your on-premises Active Directory into the cloud - Deploying Active Directory synchronization in the on-premises organization lets you provision users from your on-premises Active Directory into the cloud. This solution may work for organizations that maintain mail routing between a cloud-based organization and a non-Exchange on-premises messaging system, or for organizations that simply prefer to source all users from their on-premises Active Directory.
Having users, groups and contacts distributed across multiple Active Directory Forests introduces several additional considerations when using Windows Azure AD. The presence of multiple on-premises Active Directory forests, and the configuration of those Forests, will dictate specific decisions/configurations.
The main concepts/configurations impacted by multi-forest deployments are:
How Windows Azure AD uniquely identifies and correlates objects on-premises with those in the Office 365 service.
Allows customers to host some of their Exchange & Lync services on-premises as well as in the cloud.
Control over whether a user is allowed to login via the customer’s on-premises Active Directory, but also impacts SharePoint Online access.
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 is referred to as the ImmutableId.
As part of the Directory Synchronization process, a unique identifier value is “stamped” on all synchronized objects. The standard Directory Synchronization tool uses an object’s ObjectGUID value from the on-premises Active Directory (see Object-Guid attribute for details on the ObjectGUID attribute) to compute the SourceAnchor value. This document prescribes how an alternate unique identifier value should be chosen for the custom directory synchronization scenario.
Certain Exchange Hybrid features (between on-premises and Office 365) can be enabled if you have multiple on-premises Active Directory Forests. Examples are:
staged mailbox migrations
mailbox off-boarding (migrating from cloud INVALID USE OF SYMBOLS on-premises)
In order to light up these Exchange Hybrid features, you will need to “writeback” a specific set of attributes from the Office 365 service to their on–premises Active Directory.
Not all customers that have aggregated multiple Active Directory forests for synchronization to Office 365 will be able to enable the Hybrid Deployment feature set. Due to design limitations in the Office 365 service, organizations that have multiple Exchange Organizations on-premises are not supported at this time.
Due to design limitations in the Office 365 service, organizations that have multiple Exchange Organizations on-premises are not supported at this time.
For a list of attributes that are modified in the cloud and are written back to the on-premises Active Directory when in an Exchange Hybrid Deployment, see List of Attributes that are Synced by the Windows Azure Active Directory Sync Tool
The ability for a user to “login” or “not login” is a critical part of accessing the service. In particular, the AccountEnabled attribute of a sync’d user object in Windows Azure AD is used to determine whether a user can log into the User ID service – a user must first be able to log into the User ID service before authorizing against any of Windows Azure AD services. Customers that are synchronizing users from on-premises Active Directory Forests must ensure that the AccountEnabled attribute in Windows Azure AD is set correctly for each user. In the case where user attributes are mastered in multiple Active Directory forests, it is critical that the AccountEnabled attribute value that is synchronized to Windows Azure AD be the correct value as this is required in order to allow users to access the Windows Azure AD services.
If so, we recommend that you start by following the steps provided in the Multi-forest Directory Sync with Single Sign-On Roadmap.