Office 365 is in many aspects best compatible with an on-premise infrastructure where the customer have followed Microsoft’s guidelines and best practices for design and configuration. A perfect example of such guideline is to keep all Active Directory user data associated with employees (personal user objects) within a single Active Directory forest. For many organizations, this is not the reality, often due to a background of growth by acquisitions where the acquired organisation remain their Active Directory data in their own forest that they always have been using. Such landscape is referred to as a “Multi-forest scenario” (one organization with users are spread across many Active Directory forests).
The aspect that makes the multi-forest scenario problematic is the user provisioning and administration. For single-forest customers (the number of domains within the forest does not matter), it have always been easy to deploy Directory Synchronization from your Windows Server AD forest to Azure AD by using DirSync – but that method have not been supporting the multi-forest scenario (DirSync supports single-forest synchronization only). Different alternatives have since the launch of Office 365 become available to address directory synchronization in the Multi-forest scenario (like the FIM AAD Connector), and there are still different ways to go at it – but now, better native support for this scenario is becoming a reality with the new Azure Active Directory Sync Services (AADSync). This article will provide an overview of the alternative methods, and a detailed step-by-step guide on how to configure multi-forest synchronization from two separate Active Directory forests to one single Azure AD/Office 365 tenant. We will also look in to the feature of Attribute Filtering within AADSync to demonstrate how selected AD attributes can be skipped in the synchronization (please note that filtering out attributes is now possible but not generally recommended, I will explain why later in the article).
MASTERING THE MULTI-FOREST SCENARIO – OPTIONS OVERVIEW (OR “READ THIS FIRST”)
If you are considering Office 365 (or other AAD integrated applications) and multiple Active Directory forests is your reality, consider the options below. Option D will later in the article be explained in detail. There is no preferred order or priority for the given options.
OPTION A – CONSOLIDATE THE FORESTS FIRST: If Active Directory consolidation (merging the forests in to one) is an option, that activity could be completed prior to adopting Azure AD/Office 365 to avoid the multi-forest scenario complexity. The objects that needs to be consolidated to one forest are the user objects for the employees and groups that relate to any of the Office 365 services (i.e distribution lists and mailbox security groups). Computer objects and service accounts etc can still remain in the trusted forest when activating AAD/Office 365 services.
OPTION B – MIX SYNCED IDs WITH CLOUD IDs: If the majority of users resides in one AD forest, and a limited number of users are in a separate forests, a good option can be to implement AD integration (AADSync, ADFS) to the primary forest, but create Cloud ID (separate identities in Azure AD) for the users that are in the separate forests. This creates a mix of integrated and separate identities in the same tenant. If you are using ADFS in the primary forest, keep in mind that users in the other forests (that get’s the Cloud IDs) can not have the same domain in their username, because federation is activated per domain (if domain1.com is activated for federation, domain1.com users can not use Cloud IDs with email@example.com usernames, they would have to use another domain for their usernames).
OPTION C – USE SHADOW ACCOUNTS: This option is similar to Option B, but with the ability to centrally manage all identities. Instead of creating Cloud IDs for the users residing in the separate forest(s), create corresponding user objects (“shadow accounts”) in the primary AD forest for those users instead, and let AADSync provision these accounts in AAD/Office 365. These “shadow accounts” allows the users in the separate forest(s) to login with a centrally managed account, but they will not have Single Sign-on with ADFS as they are not logging in to Windows with the same account as they are using for AAD/Office 365. This option allows ADFS Claim rules, centrally managed password policies and other benefits that comes with proper Active Directory integration – but have considerations regarding end-user experience for the shadow users (there is a separate password associated with the shadow account, etc).
OPTION D – SYNCHRONIZE ALL FORESTS WITH AADSYNC: The final option is to actually enable multi-forest synchronization. This can be accomplished either by using the AAD Connector in FIM that still is available, or by using the new Azure AD Sync Services (AADSync). It is recommended to use AADSync, as the FIM agent (as well as DirSync) is believed to be deprecated over time and replaced with AADSync completely. (A feature comparison between DirSync, FIM AAD Connector and AADSync can be found here). AADSync works like DirSync always have, but have native support for connecting with multiple Active Directory forests. How to implement and configure this option is explained in detail below.
IMPLEMENTING MULTI-FOREST SYNC WITH AADSYNC – SCENARIO OVERVIEW
I will now explain how to configure multi-forest synchronization step by step. Before jumping in to configuration, let’s have a look at the given scenario.
SOURCE: Two separate AD Forests containing users – FOREST-A.int and FOREST-B.int
TARGET: One Azure AD/Office 365 tenant.
METHOD: We will configure AADSync to synchronize objects from both forests to the tenant. We will also configure AADSync to filter out the ipPhone, homePhone and extensionAttribute9 AD attributes from the synchronization.
CONFIGURING MULTI-FOREST DIRECTORY SYNCHRONIZATION STEP-BY-STEP
- You have an AAD/Office 365 tenant
- You have activated all your smtp-domains that are used in the organization (both forests) in your tenant.
- Your users have either or both their UPN-name and mail-attribute in Active Directory populated to match their primary smtp-address.
- You have one machine available to install AADSync (can be joined to any of the forests). The machine can access domain controllers in both forests and is able to resolve both forest DNS names.
- You have user account credentials to read both AD Forests, and you have a Global Administrator account to write to your Azure AD.
Make sure you meet all pre-requisites above. Then, let’s get started.
- The first step is to activate Active Directory Synchronization in your tenant. Do so by logging in to the admin portal, browse to users and follow the link at the top for setting up AD Synchronization.
- Click Activate to enable AD Synchronization in your tenant.
- Download AADSync to the server where you want to install the tool. Get it here.
- Launch the installer executable (MicrosoftAzureADConnectionTool.exe).
- The installer let’s you choose the installation path and accept license terms. Click Install to continue.
- The necessary components are now installed to the server (Sign-in Assistant, SQL LocalDB, SQL Native Client, the actual Sync Service etc). After the component installation, the wizard interface may disappear completely for about 30 seconds, but it will come back when it have finished loading the configuration wizard.
- The first step in the configuration wizard is to connect to your Azure AD. Enter the credentials for a Global Administrator in the tenant and hit Next to continue.
- Next, enter credentials for the first forest you want to synchronize. Start by adding the forest to which you have joined the AADSync server (in this case this is FOREST-A). Hit Add Forest to verify the connectivity and credentials, and to add the next forest.
- Add the next forest. Notice that I use the forest FQDN to specify the domain in the Username field (FOREST-B.int\jesper). I recommend this when adding the external forests to avoid an error that states “The specified domain does not exist or cannot be contacted.”, which may occur if only using the NetBIOS name (FOREST-B\jesper).
- When both forests are added to the list, hit Next to continue.
- The next option screen in the wizard covers settings for user matching. These options require careful consideration if you are using GAL Sync (or for any other reason have users represented as User and/or Contact objects in both forests) and/or are planning for a future Active Directory consolidation/migration of the forests that you currently are configuring for AADSync. Read the following rationales for these options before proceeding:
Matching across forests: If your user objects only occurs in their respective forest, and are not replicated as a contact object or duplicate account in the other forest, leave the “Matching across forests” option at its default – “Your users are only represented once across all forests”. If objects are represented in many forests, you must make a selection for an attributed that can be used as a matching attribute to merge/join the duplicates to one Azure AD identity, or you will have collisions during the synchronization. More information is available if you follow the “Learn more about user matching” link in the wizard.
Matching with Azure AD: These two options are used for identity federation. The sourceAnchor attribute is the immutable ID for the user, and must not be changed during the lifetime of a user object. The default choise – objectGUID – is a good choise IF YOU ARE NOT PLANNING AN ACTIVE DIRECTORY CONSOLIDATION OR MIGRATION IN THE FUTURE. The objectGUID attribute will change if the user is moved to another forest, and would in that case create a duplicate user in Azure AD (and a big mess to clean up). Use the objectGUID if you are certain that the affected user objects will remain in their current forest for their remaining lifetime. The userPrincipalName attribute is the attribute that will populate the Username in Azure AD (the corresponding UPN-name in AAD). Having users signing in to AAD/Office 365 with their primary smtp-address as their username is a best practice, so use the default – userPrincipalName – if attribute is matching the users smtp (email) addresses (or if you are planning them to do so). If your UPN names do not match the primary smtp-address and you are not planning on changing the UPNs to do so, consider using the mail-attribute instead (in that case, just remember to configure ADFS to use the same attribute by following these instructions).
In summary: If your users are represented once across the forests (no GAL Sync or equal in place) and if your UPN-names are matching primary smtp-addresses, you can go ahead with the default options here, like I do in this example. Make your selection and hit Next to continue.
- Next up are Optional features. At the time taking this screenshot, Password Synchronization was not available in AADSync (RTM version, build 1.0.0419.0911), but this is available now (from October 2014). Password write-back is also in its final stages of development and will soon be available to customers that have an Azure AD Premium subscription (not included in Office 365). The Exchange Hybrid option must be selected if you are planning to set up an Exchange Hybrid Configuration between one of your on-premise Exchange organizations and Exchange Online (Multi-org Exchange hybrids are also in development but not yet available at the time writing). I am selecting Exchange hybrid deployment and Azure AD app and attribute filtering to demonstrate the new capabilities to filter out attributes from AADSync. Please note that I do not recommend that you use app and attribute filtering (see explanation below under “Should I filter out apps…”), I am making the selection in this example to demonstrate the capability. Make your selection and hit Next to continue.
- If you selected the “Azure AD app and attribute filtering” in the previous step (not generally recommended), you will now have the option to filter out Azure AD apps (Office 365 services etc). Filtering out apps and attributes is possible, but before you decide doing so, please read the following rationale:
Should I filter out apps and/or attributes from the synchronization? My general answer to this question is “No”. There are in my opinion three main reasons why you shouldn’t.
REASON A – NO SECRETS IN ACTIVE DIRECTORY: By default, all users can read all attributes (not the passwords) for all objects in Active Directory. If you want to filter out attributes because you have secret data stored in AD attributes, you are doing things very wrong. Any user can open any AD or LDAP administration tool (like Active Directory Users and Computers) and read and/or export all your directory data from any machine in the network. If you are allowing shared AD accounts (like POS/kiosk accounts), you will not have any chance to log or trace such export either. You should not store any secret data in Active Directory attributes (another Microsoft Best Practice), and therefore synchronizing attributes to AAD that any user can read anyway should not be imposing a security threat to your organization.
REASON B – KEEP IT SIMPLE, IT IS YOUR PRIVATE DATA: If you filter out apps/attributes in your synchronization, you are immediately configuring a “special setup” with a complexity parameter added to it. Your tenant and your Azure AD is your private data. You are not sharing it with Microsoft or anyone else. Keep your AAD synchronization solution as simple as possible, trust Office 365, and synchronize all attributes as recommended to avoid incompatibility (surprises) in the future as AAD/Office 365 develops.
REASON C – FUNCTIONALITY AND RICH USER EXPERIENCE: To allow the very best end-user experience, GlobalAddress Lists, Lync Contact Cards, SharePoint profile sites etc should all be populated with as much information possible. If you decide to filter out attributes, you will take away functionality and “rich content” from your end users. It is also worth mentioning that Microsoft services, such as Exchange and Lync, depend on Active Directory attributes for their functionality – so filtering out an attribute that is not technically needed today might cause an upcoming feature not to work in your environment in the future. In this example, we are filtering out three attributes, but we will leave attribute scopes for all apps intact in this option screen. Make your selection and hit Next to continue.
- As we selected to use “Azure AD app and attribute filtering” previously, we now get the chance to filter out specific attributes (the previous options screen for apps let us filter out sets of attributes based on specific apps/services). To demonstrate the attribute filtering capability, I am here filtering out the ipPhone, homePhone and extensionAttribute9 attributes from synchronization because we don’t want them to be visible in the Exchange Online Global Address List. I make the selection by first checking the “I want to further limit…” check box and then clearing the attributes from the list. Make your selection and hit Next to continue.
- Next is a summary of your AADSync configuration. Check to see that everything looks OK and hit Configure to continue.
- When the configuration is completed, you have the option to start the first Synchronization immediately, or to finish the wizard without starting the synchronization so that you can configure filtering before starting (if your would like to filter out specific OUs, child-domains or set an attribute based filtering). Filtering with AADSync works and is configured the same way as it always have with DirSync. Instructions on how to enable and configure filtering can be found here. In this example, we want to synchronize the complete scope of both forests, so we let the “Synchronize now” option stay selected and hit Finish to complete the wizard and start the synchronization.
- Now, all we need to do is wait for the synchronization to complete. You can monitor the synchronization progress by opening the Synchronization Service Manager (the miisclient interface) from the Start menu. You can track the different stages of the synchronization in the Operations tab.
- There is also another tool available with AADSync called the Synchronization Rules Editor (you will find it in the Start menu). This tool can be used to see and edit the attribute flows and scoping filters. You can use the tool to create transformation rules for certain attributes etc. In this example, we will not make any such changes, but we open it to have a look while we are waiting for the synchronization to complete.
- When the synchronization is completed, it is time to see the result. Sign in to the Office 365 admin portal and navigate to Users. Now, you will see users from both forests provisioned as synchronized identities “Status is Synchronized with Active Directory”. Success!
- When opening a user from each forest, you see that both users are synchronized (get’s the banner stating they can only be edited in the local Active Directory) and that the user name matches the UPN-name in the local AD.
- The users can now be licensed and start using Office 365, or other AAD-integrated, services. You may also set up federated identities using ADFS and provide Single Sign-on to the users from both forests using a shared ADFS STS service with proper configuration.
SUMMARY AND DISCLAIMER
In this article we have seen how powerful and yet easy to use the new AADSync Service is. Multi-forest is a common and challenging reality for many enterprise customers, and with AADSync there is finally a robust, simple and supported way to get Active Directory synchronization working in that scenario. We are still waiting for a graphical interface for /fullsql installations (when synchronizing over 50 000 AD objects), support for multi-org Exchange hybrid configurations and password write-back capabilities (for AAD Premium customers) to work – but these features will all be available soon. So thank you DirSync and FIM AAD Connector for the great years together, it have been great – but now it’s time for AADSync to take it from here.