Sign up for Office 365
Learn more about Office 365
John Speare, Senior Tech Writer, Microsoft
In a Microsoft Office 365 environment, source of authority refers to the location where Active Directory directory service objects, such as users and groups, are mastered (an original source that defines copies of an object) in a cross-premises deployment. For example, by running Active Directory synchronization, you are mastering objects from within your on-premises Active Directory. Alternatively, when you create objects by using the Exchange Control Panel (ECP) or the Office 365 portal, you are mastering objects from within the Office 365 cloud.
Office 365 requires a single source of authority for every object. This reduces the likelihood that directory data could be inadvertently overwritten.
By default, Office 365 directory objects are mastered in the cloud, which means they must be edited by using cloud-based tools. You can use the Office 365 portal, Windows PowerShell, or the ECP to create users, mailboxes, contacts, and groups in the cloud directory. 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.
When the directory synchronization tool is activated in the Office 365 Admin page, 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 the Office 365 Admin page or with Windows PowerShell. Source of authority is transferred after you perform the first sync.
Activating directory synchronization is a requirement for an Exchange hybrid deployment, an Active Directory Federation Services (ADFS)/single sign-on (SSO), and the staged Exchange migration scenarios.
Deactivating directory synchronization is a requirement if you want to transfer all user, group, contact, and mailbox management 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.
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 a company that activated directory synchronization in January and created synced users in the cloud. In July, the company 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 ADFS/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:
It’s important to understand these variables so that you can prepare your environment for the source of authority transfer, helping 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.
If a GUID or an SMTP match cannot be made, the directory synchronization process creates a new object in the cloud that is mastered from within the on-premises Active Directory.
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 does not 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.
To make a backup of cloud user object data:
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. But it is important to know that rolling back reactivation is a manual, and potentially lengthy, process. You’ll need the help of Microsoft Support.
To help ensure that mail flow works after you reactivate directory synchronization, copy all relevant proxy addresses from the cloud user objects to their corresponding on-premises objects before you reactivate.
You can use Userlist.csv (that you created for your backup) to validate your SMTP addressing scheme. 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.
If you want to manage objects in Office 365, and you no longer want to use directory synchronization, follow this procedure:
Set-MsolDirSyncEnabled –EnableDirSync $false
(Get-MsolCompanyInformation).DirectorySynchronizationEnabled
When this command returns False, directory synchronization has been disabled. It may take 72 hours for deactivation to be completed. The time depends on the number of objects that are in your Office 365 subscription account.
The Windows PowerShell cmdlet to activate or reactive directory synchronization is Set-MsolDirSyncEnabled –EnableDirSync $true.
As previously noted, the reactivate scenario has the potential to overwrite cloud directory object data. Be sure that you understand the variables and consequences of reactivating directory synchronization in your environment.
ADFS/SSO in a cross-premises Office 365 environment requires directory synchronization. When you have enabled and configured ADFS/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 ADFS/SSO.
Deactivating directory synchronization does not 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 ADFS/SSO in an existing cloud-only Office 365 messaging environment
Enabling ADFS/SSO requires directory synchronization. However, the previous version of the directory synchronization 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 wiki post) 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 wiki post).
See the wiki post, Cutover Exchange Migration and Single Sign-On, for implementation details.
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.
Use SMTP match to transfer the source of authority for an Office 365 account to your on-premises Active Directory
In some scenarios, you may have to transfer the source of authority for a user account when that account is originally authored by using Office 365 management tools. These tools include the Office 365 portal, Microsoft Online Services Module for Windows PowerShell, and so on. You can transfer the source of authority so that the account can be managed through an on-premises Active Directory Domain Services (AD DS) user account by using directory synchronization.
See the support article, How to use SMTP matching to match on-premises user accounts to Office 365 user accounts for Directory Synchronization.
(http://technet.microsoft.com/en-us/library/bb124152(EXCHG.65).aspx).