Directory synchronization and source of authority
Published: November 15, 2012
Updated: September 24, 2014
Applies To: Azure, Office 365, Windows Intune
In a Microsoft Azure Active Directory (Microsoft Azure AD) environment, source of authority refers to the location where Active Directory objects, such as users and groups, are mastered (an original source that defines copies of an object) in a cross-premises deployment. Azure AD requires a single source of authority for every object. This reduces the likelihood that directory data could be inadvertently overwritten. By default, Azure AD directory objects are mastered in the cloud, which means they must be edited by using cloud-based tools.
Therefore, when you create objects by using either the Windows PowerShell cmdlet or account portal tools such as the Office 365 portal, you are mastering objects from within the cloud. All subsequent changes to these objects are also made by using the same tools. In this scenario, the source of authority is in the cloud. For more information about the various tools that you can use to create and manage objects in Azure AD, see Administering your Azure AD directory.
Alternatively, when you are running Active Directory synchronization, you are mastering objects from within your on-premises Active Directory. Once Directory Synchronization has been activated, and after the first sync cycle has been completed, the source of authority is transferred from the cloud to the on-premises Active Directory. In this scenario, users, contacts, and groups are created on-premises and then synchronized to the cloud. All subsequent changes to the cloud objects (with the exception of licensing) are mastered from the on-premises Active Directory tools. The corresponding cloud objects are read-only. Administrators cannot edit cloud objects if the source of authority is on-premises.
There are three scenarios where you may change the source of authority for an object—when you activate, deactivate, or reactivate directory synchronization from within any account portal or with Windows PowerShell. Source of authority is transferred after you perform the first synchronization.
Activate: When you activate directory synchronization and then synchronize directories, the source of authority for any cloud object that is matched to an on-premises object is transferred from the cloud to your on-premises Active Directory.
Activating directory synchronization is a requirement for an Exchange hybrid deployment, an Active Directory Federation Services 2.0 (AD FS 2.0)/single sign-on (SSO), and the staged Exchange migration scenarios.
Deactivate: When you deactivate directory synchronization, the source of authority is transferred from the on-premises Active Directory to the cloud.
Deactivating directory synchronization is a requirement if you want to transfer all user, group, contact, and mailbox management using Windows PowerShell and account portal tools to the cloud. For example, some organizations that used the staged Exchange migration tools to move their mailboxes to the cloud and no longer want to manage objects from on-premises can deactivate directory synchronization.
Reactivate: When you reactivate directory synchronization, the source of authority is transferred from the cloud back to your on-premises Active Directory (where it previously resided).
It’s important to understand the implications of reactivating directory synchronization in this scenario. Directory data loss can occur when the source of authority is transferred from the cloud back to your on-premises organization.
For example, consider an organization that activated directory synchronization in January, and then created synced users in the cloud. In July, the organization deactivates directory synchronization. This transferred the source of authority to the cloud, where the company subsequently edited the objects. In September, the company decided to deploy AD FS 2.0/SSO. They reactivated directory synchronization to transfer the source of authority back to the on-premises Active Directory.
In this example, when directory synchronization is reactivated and run, any changes that have been made to the cloud objects from July through September would be overwritten and lost.
The following variables influence whether this example would cause the data for cloud objects to be lost:
The matching Simple Mail Transfer Protocol (SMTP) and GUID functionality that directory synchronization uses during the reactivate scenario
The difference between user property data and the two corresponding objects in their respective directories (your on-premises Active Directory versus the cloud directory)
It’s important to understand these variables so that you can prepare your environment for the source of authority transfer. This helps you to minimize directory data loss. Specifically, data loss around email proxy addresses can create mail flow and logon issues for users. Therefore, the focus of your preparation should be on evaluating how you use proxy addresses for mail routing in your current messaging implementation.
Matching functionality 1—GUID match logic. When you reactivate directory synchronization, objects in the on-premises Active Directory are matched with objects in the cloud according to previous directory synchronization GUID (objectGUID) on the cloud objects. When such a match is found, the directory synchronization process makes a GUID match and overwrites the target object data in the cloud objects with the data from the corresponding on-premises objects.
Matching functionality 2—SMTP match logic. If directory synchronization does not find a GUID match in the cloud, a process called SMTP match is used. In this process, directory synchronization matches corresponding objects, according to the primary SMTP address. If a target (cloud) object’s primary SMTP address matches a primary SMTP address of an object in the on-premises organization, the data for the on-premises object is used to overwrite the data for the corresponding cloud object.
If neither a GUID nor an SMTP match can be made, the directory synchronization process creates a new object in the cloud that is mastered from within the on-premises Active Directory.
User property differences. The degree and nature of the differences between corresponding user objects in the on-premises and cloud directories are important considerations.
|If you have made no changes or have made only minimal changes to the user objects during the time the source of authority was in the cloud, the risk of mail-flow failure is low. If, on the other hand, you have made changes to SMTP addresses (primary, secondary, proxy, target address, and so on) to enable cross-premises routing, you must make sure that reactivating directory synchronization doesn’t interrupt mail flow. Before you reactivate directory synchronization, we strongly recommend that you back up the existing cloud object data, and then evaluate how you’ve configured SMTP addressing in the cloud.|
Before you reactivate directory synchronization, it’s a best practice to back up your cloud user object data. You should make a backup even if you have made minimal changes to user objects since you last deactivated directory synchronization.
To make a backup of cloud user object data
Connect to the cloud by using Windows PowerShell for Exchange. For more information about installing and connecting with remote Windows PowerShell, see Use Windows PowerShell in Exchange Online.
After you connect to the cloud, run the following cmdlet:
Get-Mailbox |select emailaddresses, name, userprincipalname, identity|export-csv -path C:\export\userlist.csv
This cmdlet extracts all user data into Userlist.csv. This file is in the Export directory.
If you want to roll back the reactivation, Userlist.csv helps you to recover user objects to their current state. Rolling back reactivation is a manual, and potentially lengthy, process. You’ll need the help of Support.
If you have deployed Office 365 in a cross-premises organization and you have configured mail flow between your on-premises Exchange organization and the cloud, it’s likely that the user objects are configured with proxy addresses to enable cross-premises mail flow.
To help ensure that mail flow works after you reactivate directory synchronization—before you reactivate—copy all relevant proxy addresses from the cloud user objects to their corresponding on-premises objects.
You can use Userlist.csv (that you created for your backup) to validate your SMTP addressing plan. Additionally, if you are reactivating directory synchronization to enable an Exchange hybrid deployment, you should follow the SMTP addressing recommendations in the Exchange Server Deployment Assistant for your organization. This helps ensure that directory synchronization updates the cloud objects with the correct SMTP addresses.
AD FS 2.0/SSO in a cross-premises cloud service environment requires directory synchronization. When you have enabled and configured AD FS 2.0/SSO in your environment, user objects that are mastered on-premises are automatically provisioned with a federated account in the cloud.
If you transfer the source of authority to the cloud by deactivating directory synchronization, new users are not automatically provisioned for AD FS 2.0/SSO.
Deactivating directory synchronization doesn’t affect existing federated users in the cloud. They continue to be federated after you deactivate directory synchronization.
Transferring the source of authority makes the following email migration scenarios possible:
Enabling AD FS 2.0/SSO in an existing cloud-only Office 365 messaging environment
Decoupling the on-premises Active Directory from a staged Exchange migration environment
Enabling AD FS 2.0/SSO in an existing cloud-only Office 365 messaging environment.
Enabling AD FS 2.0/SSO requires directory synchronization. However, the previous version of the Microsoft Azure Active Directory Sync tool could not be run after some of the Exchange migration tools had already been run. Specifically, a cutover Exchange migration migrates users and mailboxes to the cloud by first creating a user account that is based on the SMTP address.
The previous version of directory synchronization did not create new cloud users if an existing user object in the cloud had the same primary SMTP address as the corresponding on-premises user. However, the current version of directory synchronization uses SMTP match functionality (described earlier in this topic) to match on-premises users to cloud users.
Remember that user data associated with matched cloud user objects is overwritten by the corresponding on-premises user data. This is especially important in the case of proxy addresses for complex mail-routing scenarios. Before you transfer the source of authority from the cloud to your on-premises Active Directory, be sure to copy all relevant proxy addresses from the cloud user objects to their corresponding on-premises objects (as described earlier in this topic).
For details about implementation, see Cutover Exchange Migration and Single Sign-On.
Decoupling the on-premises Active Directory from a staged Exchange migration environment
Running the staged Exchange migration tool requires activating and running directory synchronization. For some organizations, email migration is one phase of a full migration to the cloud. For organizations that want to completely decouple their cloud environment from their on-premises environment, or that want to decommission their on-premises Active Directory, transferring the source of authority to the cloud is likely the final step in their migration plan.
In some scenarios, you may have to transfer the source of authority for a user account when that account is originally authored by using cloud-based management tools such as and account portals. You can transfer the source of authority so that the account can be managed through an on-premises Active Directory Domain Services user account by using directory synchronization.
For more information see, How to use SMTP matching to match on-premises user accounts to cloud accounts for Directory Synchronization.