Single sign-on to Office 365 using open standards

Office 365 integration with an SSO Identity Provider (IdP) is accomplished through the open standards WS-Federation and WS-Trust, which support both active and passive user profiles. Active profiles are needed to support rich client applications such as Lync, Office Subscription, as well as email rich clients such as Outlook and Active Sync. Passive profiles are needed to support web-based clients such as SharePoint Online and Exchange Web Access. Many vendors are part of the “Works with Office 365” program (more info here), including PingFederate, Okta, OneLogin, CA SiteMinder, and Centrify to name a few.

Federation to web-based clients is accomplished through the passive profile using WS-Federation, which is based upon SAML 2.0. Federation for rich clients (e.g. Office desktop applications) is accomplished through the active profile that is not supported by SAML 2.0, but rather through WS-Trust, which is a part of the Microsoft backed WS.* standard. Identity Providers (IdPs), whether on-premise or Identity as a Service (IDaaS) that support the SAML 2.0 and WS-Federation can be used to quickly enable SSO to Office 365, however configuration of the active profiles are supported through the configuration of WS-Trust.

While the driving motivation for Office 365 and moving Exchange to the cloud is to realize cost savings, a key decision is whether to perform a full cutover migration and deployment, or a hybrid deployment where users are migrated over time. A hybrid deployment is extremely useful if you have a very large migrations or where you want to split users permanently into a hybrid configuration. Once complete, your users shouldn’t know (or care) where their mailbox is located. They will be able to access mail, arrange meetings and see calendar availability for everyone, regardless of their location or their device.

In order to federate an SSO IdP with Office 365, there are technical design and implementation steps that need to be performed:

1. Establish an Office 365 subscription. This is accomplished through the Office 365 sign-up wizard where you will create an Office 365 login. The wizard will require you to enter your country where service will Office 365 services will be used, a valid email and phone number, an initial login name unique for Office 365 administration (e.g. john@mycompany.onmicrosoft.com). This is started by going to Select a Plan to choose the plan you want to buy and to start the sign-up wizard. If you start with a free trial, you can buy it later. All your users and data from the trial will still be there. You don’t need to cancel a trial. If you don’t buy the trial subscription, it automatically expires at the end of the trial period, and all the information is permanently deleted. Once Office 365 is active, you login at https://portal.microsoftonline.com to access the portal with administrative functions.
2. Register a domain with Office 365. Your organizational domain will need to be configured within Office 365 in order to host email accounts. You will register and verify your domain with Office 365.
3. Decide on a UPN naming convention. Office 365 users are identified by two pieces of information – a UPN (of the format username@domainname) and an ImmutableID (a never-recycled UUID for a user account). The UPN will typically be your local account username appended with @domainname for the registered domain you own. If you are using Active Directory, this will be the userPrincipalName schema element that should be configured to use the sAMAccountName@domainname as the rule for generating the scheme elements during user provisioning.
4. Decide on a UUID/ImmutableID strategy. As mentioned in the UPN naming convention, the UUID/ImmutableID is a never-recycled UUID for a user account that Office 365 uses to maintain integrity between an on-premise user repository and the Office 365 user information. If you are using Active Directory, this will be the objectGUID schema element.
5. Install Directory Synchronization upon a Windows Server to include Windows Powershell. The Directory Synchronization Tool (e.g. DirSync) is an application that provides one-way synchronization from an organization’s Active Directory to Microsoft Azure Active Directory that is supporting Office 365. As part of the DirSync installation, you will need to ensure that the appropriate configuration for Microsoft Federated Identity Manager (FIM) is completed. The DirSync application utilizes Microsoft FIM as the core user provisioning capability to synchronize on-premise users with the Office 365 cloud. DirSync uses on-premises service account named MSOL_AD_SYNC that is granted read and synchronizes permissions to the local Active Directory. You should not change the password associated with the MSOL_AD_SYNC service account. However, if your company forces password changes, you must run the Directory Sync Configuration Wizard if the password associated with this account is changed.
6. Provision users to Office 365 using DirSync. Ensure full synchronization has been executed for the organization upon the Active Directory OU hosting all desired Office 365 users. Verify that the desired users have been pushed into the Office 365 cloud via inspection using the Office 365 admin portal.
7. Register and configure Federation with Office 365 (e.g. configure the Service Provider). Using Windows Powershell cmdlets on the DirSync server, the SSO IdP endpoints for active and passive profiles, as well as digital certificates will be registered with Office 365 that enables the SSO.
8. Configure your organizational Single Sign-On (SSO) IdP Server. Using the SSO IdP this process will configure WS-Federation and WS-Trust to Office 365, as well as the digital signing certificates for security of the SSO assertions.
9. Migrate email mailboxes. One of the keys to success is the decision for full deployment or a hybrid deployment. If Office 365 is configured as a hybrid deployment, special attention to migration of email mailboxes will need to be performed to ensure your user community continues to operate same as before the migration to Office 365. As part of the migration of email mailboxes, MX records will need to be updated so that Office 365 is the primary mail provider for your organizational domain. In a hybrid mode, mail is first resolved at Office 365 and then resolved at your on-premise Exchange server. One thing to be aware is that hybrid mode does require a minimum of Exchange 2010.

That’s pretty much it – those are the steps to leverage your existing SSO/federated identity management solution for Office 365. Contact us if you have questions or if you need help making the most of your identity and access management investment.