The cloud has brought about many changes in the way we use IT systems, breaking down barriers between corporate networks and the Internet, but bringing with it the expectation of access to services and data anytime, anyplace. The updated Directory Synchronization tool allows organizations to connect Office 365 to Active Directory without having to manage separate identities in the cloud or implement Active Directory Federation Services (ADFS).
In this first in a series of articles, I’m going to look at how to duplicate local AD accounts and passwords in the cloud to provide users with easier access to Office 365. You will learn about the requirements for installing Directory Synchronization on an onsite server and how password synchronization differs from using Active Directory Federation Services.
If you have Windows Server Essentials 2012, you can connect to Office 365 using a simplified procedure and without installing the Directory Sync (dirsync) tool manually. Functionality may differ from what is described using the Directory Synchronization tool in this article. If you want to set up Active Directory Federation Services, for federated identities and single sign-on capabilities with Office 365, see the Active Directory Integration with Office 365 series of articles by John O’Neill Sr.
Microsoft released an update to the Directory Synchronization tool on June 4, 2013, adding the capability to synchronize passwords from a local Active Directory (AD) to Windows Azure AD. The new functionality has been dubbed “same sign-on.” Previously the tool only synchronized AD accounts, and users were required to set their password manually in Office 365 if they wanted it to match their local domain password.
Office 365 uses Windows Azure Active Directory for its own directory services, so when you set up directory synchronization in Office 365, your local AD synchronizes with Windows Azure. Once synchronization is enabled, you can only manage user objects from your local AD.
Not all Office 365 subscriptions offer the capability to synchronize with onsite Active Directory. If you don’t have a midsize or enterprise plan, you are going to be out of luck. AD integration allows you to manage users, groups and permissions, sync the global address list (GAL) if you have an onsite Exchange Server, and provide single sign-on capability (ADFS implantation only). Office 365 AD integration is compatible with Windows Server 2008 R2 and Windows Server 2012.
Office 365 can use cloud or federated identities. Cloud identities require organizations to either manage usernames and passwords in the cloud separately from their onsite Active Directory, or to use directory synchronization to add or merge Active Directory accounts and passwords with Office 365 cloud identities.
Federated identities rely on the onsite Active Directory for user authentication, with the help of Active Directory Federation Services. Using federated identities and ADFS is the only way organizations can provide users with true single sign-on (SSO) to Office 365.
Windows Azure AD supports up to 50,000 objects and as such you can use the dirsync tool with your local AD and SQL Server Express 2008. Your dirsync server must be a member of your local AD domain, but it cannot be a domain controller (DC), it must be running the .NET Framework versions 3.5 SP1 and 4.0, and it must have PowerShell installed.
The Directory Synchronization tool can only be installed on one server in your forest; you cannot have multiple instances to improve performance or provide redundancy. For an AD forest with fewer than 10,000 objects a 1.6GHz CPU and 4GB of RAM should suffice.
Directory synchronization is usually a one-way street, i.e. local AD user objects are synchronized to Windows Azure Active Directory. Except in a hybrid deployment, which is only required if you have an onsite Exchange Server. If you configure dirsync in a hybrid deployment, where selected object attributes are written from Windows Azure AD back to your local AD, the server running dirsync must be able to connect to all domain controllers in your AD forest.
The domain and DCs in your AD forest must meet the following requirements:
Test your local AD environment before deploying a dirsync server using Microsoft’s readiness tool. There are a few simple questions to answer and then you are prompted to install a .cab file in Internet Explorer. Once downloaded, tests are run against Active Directory and a report is produced outlining any potential problems.
Directory Synchronization requires an alternate UPN suffix be configured in your local AD if it doesn’t already match what’s configured in your Office 365 tenant. The Office 365 UPN suffix is the part of your username that appears after the ampersand. For instance, if you sign up for Office 365 without a custom domain name, the UPN suffix is made up of the company name given during signup, plus the standard Microsoft domain. So if your Office 365 domain is contoso.onmicrosoft.com, usernames will be written as [email protected], with contoso.onmicrosoft.com being the UPN suffix.
To add an additional UPN suffix to your local AD configuration:
In the next part of this series, you will learn how to activate Active Directory synchronization in Office 365 and I’ll walk through the process of installing the Directory Synchronization tool.