When Microsoft reported its third-quarter financial results in April, the company revealed that 25 percent of its enterprise customers have Office 365. When you take trial subscriptions into account, the actual deployment numbers are almost certainly lower. Small-business deployments are probably higher because this service is particularly appealing to companies without a lot of pre-existing IT infrastructure. Nonetheless, a lot of companies are looking hard at Office 365—and they're probably running up against difficult single sign-on (SSO) requirements. This month, I want to take a look at the challenges of integrating Office 365 into your environment while preventing your users from encountering credentials prompts; I also want to show you how third-party identity management providers can make that connection easier.
Office 365 Integration Options
Office 365 can integrate with your existing on-premises environment in five ways, from essentially no integration to full SSO using your existing corporate credentials, as you see in Table 1. Three of these integration methods use your company—typically an Active Directory (AD) forest—as the identity provider. Two of them use the same user IDs and passwords for Office 365 as for your corporate directory. But only one provides seamless access to Office 365 as you'd access your local resources via SSO. For midsized-to-large enterprises, this method is usually the best way to go; any time you require a password prompt, user confusion and support costs will increase.
Regardless of whether you're trying to connect to Office 365 or another cloud service provider (CSP) such as Google Apps, Internet SSO requires two major components. First, you can't have access to a cloud service without an identity on that service. Therefore, you must have a method to populate—then keep synchronized—your on-premises identities with the cloud service. Microsoft's utility for identity provisioning to Office 365 is the Windows Azure Active Directory Synchronization Tool(more efficiently known as DirSync). Third-party identity management tools also have their own account provisioning mechanisms, which I'll cover shortly.
Account Provisioning with DirSync
DirSync straightforwardly monitors and synchronizes local AD objects with Windows Azure AD. It's a one-way sync, which means your local AD objects are always authoritative over the synchronized objects in Azure AD. Of course, when you dig a little deeper, it's not quite so simple. (It never is.) DirSync will synchronize as many as 50,000 objects with no intervention; if you need to sync more than that, you need to call Microsoft support (to promise that you're not launching a Denial of Service—DoS—attack on Azure AD, I assume). Also if you need to sync more than 50,000 accounts, you must install a full instance of SQL Server 2008/SQL Server 2008 R2. The DirSync server must be a member of the forest in which it's syncing objects, and the server needs to be as tightly secured as a domain controller (DC), but it can't be installed on a DC. If you're using DirSync with the password synchronization option (which isn't necessary or recommended if you're using federation), password changes are replicated every two minutes, but other changes might take several hours. Fellow Directory Services MVP Sander Berkouwer wrote a blog post called "Five Things you should know about using DirSync with Password Sync"that describes some of these characteristics.
Federation with AD FS
Once you have your identities up in Office 365, to get SSO you need a way to authenticate them with where they came from—your company, as the identity provider. With identity federation, this authentication occurs through a component known as an identity bridge. Microsoft’s general-purpose identity bridge is Active Directory Federation Services (AD FS), and third parties (notably IDaaS providers) have dedicated identity bridges.
Although it gets easier with each new release, designing and deploying a production AD FS installation isn’t a trivial task. AD FS was previously not to be installed on a DC, but in Windows Server 2012 R2 the recommended configuration is to be installed on a DC. You should configure AD FS for high availability because your users won’t be able to log on to critical office functions without it. Thus, you need to set up a Windows Failover cluster with the AD FS role installed, deploy an AD FS proxy server in your corporate DMZ, and obtain and install public certificates. Once installed and in production, the AD FS installation must be monitored and updated, and you can’t let your public certificates expire or your trusts will fail. Further, a Microsoft-only solution requires that your federated trust with Office 365 be with a single forest, so if you have accounts in multiple AD forests, or non-AD identity sources, you need to perform some kind of consolidation. Thomas Kemp, in "Options for Federated Identity for Office 365, Part 2," does a nice job summarizing some of the challenges in a local AD FS deployment.
Cleaning Up Dirty Directory Data
It doesn’t matter how nicely you’re connected to Office 365 if the data in your directory isn’t clean. Different username and phone number conventions are common, for example, and although the Office 365 Deployment Readiness Tool will show you where your data problems are, correcting them and setting policies in place to keep them clean can take time. (Note that the Office 365 Deployment Readiness Tool, which used to be a free download that you could run against any AD forest to check for problems that would delay or prevent Office 365 migration, has been moved into the Office 365 subscription. To use it, you'll have to sign up for a trial subscription.)
This adds up to a solid set of challenges in the way of an Office 365 deployment. And it's not even Office 365 itself that’s the challenge: It's the plumbing that's getting in the way.
Third-Party Solutions
As it does in so many scenarios, Microsoft provides basic functionality out of the box to get the job done, but it might not be the easiest or most fully featured implementation. Are you in a rush to deploy Office 365? Are you willing to spend some money to simplify the connection? Budgets are tight, but time is money, so in this case throwing cash at the problem really can help. Identity vendors will be happy to help ease your pain.
If you have problems with your on-premises identity sources not playing well with one another, an on-premises virtual directory service (VDS) can quickly make all of them appear to be a single directory. You can also create rules in the VDS to reformat your dirty data to present a clean view to offsite web services. If you don't want the hassle of hosting your own highly available AD FS cluster, you can find several on-premises identity bridges specifically designed to connect to Office 365 with a minimum of configuration work. And IDaaS vendors—with the easy-to-deploy, specialized identity bridge that Figure 1 shows—can quickly get you through the federation problem. They provide SSO capability to hundreds of cloud service providers, including Office 365. They also provide account provisioning capabilities, though their Office 365 account provisioning ability varies. (This is where the emerging System for Cross-domain Identity Management—SCIM—provisioning specification is hoped to provide relief in the future.) Finally, many of these vendors provide all three of these important functions (federation, provisioning, and identity consolidation) within their product suites.
I've recently found myself repeating a quote that Gil Kirkpatrick related to me several years ago in an interview (see "Identity as a Service and the Future of Active Directory"): "The only people interested in identity management are people in the identity management business." For everyone else, identity is just a speed bump getting in the way of what they want to do. Connecting your enterprise to Office 365 is just such a speed bump: The less your users are aware of the connection, the better. And third-party solutions can help reduce your time to deployment significantly.
Sean writes about cloud identity, Microsoft hybrid identity, and whatever else he finds interesting at his blog on Enterprise Identity and on Twitter at @shorinsean.
