Synchronizing your directory with Office 365 is easy
Paul Andrew is technical product manager for Identity Management on the Office 365 team.
If you’re just getting started with Office 365, you’re probably considering how to extend the user directory that you use for accessing internal resources for connecting to cloud resources. The simplest way to achieve this is with the Windows Azure Active Directory Sync Tool (DirSync). This tool runs on a Windows Server machine on your network and synchronizes users to the cloud. DirSync has a wizard-driven install and can be set up in just a few minutes. You should be able to synchronize your directory to Office 365 in under a day.
This blog post provides the basic information you need to successfully implement DirSync. It also points you to more detailed information, for cases not addressed here. Specifically, it covers what you should review before you synchronize your directory with Azure Active Directory. Office 365 uses Azure Active Directory for storing all user accounts, for all directory lookup, and for doing user sign-in authentication.
DirSync sends user accounts to Office 365 as a starting point for federated single sign-in, or both user accounts and password hashes for same sign-in.
Single sign-on and same sign-on
If you have an on-premises directory then you are going to be choosing between DirSync with password sync and DirSync with Active Directory Federation Services. The DirSync tool is common to both of these scenarios. Single sign-on is where users are signed in to Office 365 automatically and with no password required when they are already signed in to their domain-joined PC. Single sign-on requires both DirSync and Active Directory Federation Services to be configured. DirSync with password sync can provide what we call “same sign-on,” where the sign-in to Office 365 is always the same password that is used on the PC, but the password must be either retyped or saved on the client. By going with same sign-on and requiring that extra password entry, you avoid the additional server configuration, hardware cost, and network complexity that is required for single sign-on. Also, the Microsoft Outlook rich client requires username and password to be entered even when single sign-on is enabled.
There will be two more posts following up this one. A second post that gives detailed advice about choosing between the three identity models for Office 365 including cloud managed identities, DirSync with password sync, and DirSync with Active Directory Federation Services. And a third post where I’ll describe the steps required for single sign-on and other features that come with Active Directory Federation Services (AD FS).
If you choose AD FS then DirSync is still required to synchronize the user accounts to Office 365, so it is generally recommended that you set up DirSync and password hash synchronization first, then add AD FS later.
Setting up DirSync and password hash synchronization
By taking certain easy steps before you install DirSync you can help ensure a smooth and successful implementation. Here are the steps:
Four things to review your on-premises directory for.
1. Before you install, review your on-premises directory structure
One of the first steps you should take before installing DirSync is to look at the directory that you have on-premises and make sure it’s healthy and ready to synchronize to Azure Active Directory. Here are a few things you need to look at:
- Active Directory remediation. DirSync has certain requirements on attributes in the directory, and aligning the attribute values with the DirSync requirements is commonly known as Active Directory remediation. To help with Active Directory remediation, you should use the IdFix tool, which reviews the directory and performs interactive Active Directory remediation. This tool checks for and helps you correct any invalid data and duplicate data in directory attributes, including userPrincipalName (UPN), mailNickName, proxyAddress, sAMAccountName, targetAddress, and others. The IDFix tool also provides assistance for migrating from a non-routable UPN (such as “domain.local,” for example) to an Internet routable domain name, because using an Internet-routable domain is one of the requirements for Azure Active Directory. Be sure to run the IdFix tool from within your network, so that it has access to the domain controllers.
- Forest functional level. You need to check the forest functional level of your directory, which must be set at Windows Server 2003 forest functional level or higher. If it is not, then you need to upgrade that before installing DirSync, as described in this Microsoft KB article.
- Multiple forests. Multiple forests are not handled by the standard DirSync tool. A deployment of Forefront Identity Manager 2010 with configured adapters can synchronize multiple forests to Azure Active Directory; however, it does not support password hash synchronization.
- Directories other than Active Directory. If you do not use Active Directory and have some other directory on-premises directory, then you can still use Office 365, but you will need to seek other guidance. Azure Active Directory Sync can synchronize non-Active Directory directory sources, including LDAP v3, SQL database tables, and CSV files. In addition, PowerShell cmdlets can be used to manually update user provisioning with Azure Active Directory
2. Before you install, decide if you need additional servers
The next thing to do before installing DirSync is to take a look at what new on-premises directory servers you will need. Here are the things to review:
- A domain controller collocated install isn’t recommended. DirSync can be installed on an existing domain controller, but this isn’t recommended for other than very small directories or test/pilot topologies. If you install DirSync on an existing domain controller, then no new on-premises servers are required.
- One server is most common. A single-server deployment of DirSync is the norm. If you have more than 50,000 directory objects, you will also need a separate SQL Server installation. You will have more directory objects than actual users, because there are user objects for contacts and groups as well as users. DirSync requires connectivity to a domain controller for each domain being synchronized and in rare circumstances where existing domain controllers are not always accessible you will need an additional domain controller server. This would be a total of four servers.
- Consider using Azure. If you don’t want any new on-premises servers, you can deploy DirSync and any SQL Server databases required on an Azure IaaS environment, as described in Deploy DirSync on Azure.
- Use the DirSync road map. When you read the DirSync road map, you can skip the details about the Microsoft Deployment Readiness Toolkit and on updating your UPNs, because you already took care of those automatically with the IdFix tool (in Step 1 above). Here are a few key things you do want to note in the DirSync road map: having accurate time on your DirSync server, having the administrator account available for your Office 365 tenant, and making sure you have network connectivity to domain controllers for all domains.
Screen shot from the DirSync install wizard.
3. Install and check your DirSync progress
Installing DirSync is the easiest part, because you just download it and run the wizard on a domain-joined machine. Once the install has completed, you need to review for any errors during synchronization. Here are the areas to review:
- Be aware of directory object limits. A new Office 365 tenant can sync up to 50,000 directory objects by default. If you register a vanity domain within your tenant, this limit will be increased to 300,000. The limit can also be increased as needed by contacting support.
- Add domains to Office 365. If you add your public domain names to Office 365 prior to using DirSync, then your sign-in UPNs will be synchronized with those. You can skip adding your public domain names to Office 365 initially, but this will result in all your users showing up in Office 365 as onmicrosoft.com in their UPN instead of your custom domain name. To get the correct UPNs back with your public domains, you will need to force a synchronization update from on-premises after you have added the domains later to correct this.
- Sync now. DirSync will synchronize the directory every three hours and the initial synchronization will take about one hour per 5,000 user objects. You can tell it to initiate a synchronization by running a PowerShell command on the server. This is described in the TechNet install guide for DirSync. If you enabled password hash synchronization, then password changes are synced every two minutes.
- Check event logs. After you install, look in the event log on the machine running DirSync. If you’re not familiar with this, run EVENTVWR.EXE from the command line. Open the Windows Logs folder and view the Application log. The admin for the tenant will also receive emails showing any errors that need to be resolved, but the event log is the quickest place to get to these errors. Any errors from DirSync will have the event source listed as Directory Synchronization. You can troubleshoot the error codes with this KB article.
- Check the password expiry date for the Office 365 administrator account. Watch the password expiry date on the Office 365 administrator account that you use for DirSync. If it expires, then DirSync will fail.
- Assign licenses. After users are synchronized, you will need to assign them Office 365 usage licenses. This can be done in the Office 365 admin center, or you can use PowerShell as shown in this article on Technet.
Passwords synchronized to Azure AD have security processing so that the original password cannot be obtained.
Other Considerations for DirSync
Here are a few additional topics you should review as you will find that people commonly have questions about them:
- High availability. Your organization may have high availability requirements. DirSync can run on only one server, but this doesn’t mean you cannot get high availability. If the DirSync server is offline, then users will still be able to sign in, because Azure Active Directory does not require a connection to the DirSync server for authentication. If you are concerned about availability for user and password hash synchronization, you can implement SQL Server in a high availability scenario. You can also have a cold standby server with DirSync ready to be installed. Users are synchronized only every three hours and you can install and start synchronizing again very quickly. Although a first time synchronization can take a while, the update after reinstalling DirSync will be much faster if you have the SQL Server database properly prepared for restore.
- Security of hashes. There may be security department concerns at your organization about having password hashes stored in Azure Active Directory. Security is a top priority for Microsoft and the Office 365 team. The on-premises Active Directory Domain Service stores passwords in the form of a hash value representation of the actual user password. The password hash cannot be used to log in to your on-premises network. It is also designed so that it cannot be reversed in order to gain access to the user’s plaintext password. To synchronize a password, the DirSync tool extracts the user password hash from the on-premises Active Directory. Additional security processing is applied to the password hash before it is synchronized to Azure Active Directory.
- Filtering DirSync. By default DirSync synchronizes all users to Azure Active Directory. You can configure this and limit the users who are synchronized by organizational unit, by domain, or by user attributes, as detailed on TechNet. Note that for in-scope users all attributes are synchronized and you cannot select specific attributes.
There is so much more you can do with Office 365 connections to your on-premises systems. Directory synchronization is easy and should be the first part of Office 365 that you set up.
—Paul Andrew, @pndrw