Single sign-on to Office 365 using PingFederate or PingOne

Office 365 integration with PingFederate or PingOne acting as the identity provider 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, OneDrive and Exchange Web Access.

Federation to web-based clients is accomplished through the passive profile using WS-Federation, which is based upon SAML 2.0. Both PingFederate and PingOne support SAML 2.0 and WS-Federation making it easy to quickly enable SSO to Office 365. 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. Ping Identity is the only vendor to support all of the identity standards, including WS-Federation and WS-Trust.

The following table captures the SSO support provided by the Ping ecosystem:

[/fusion_table]

In order to federate Ping products 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. The process 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 a 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 synchronization 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 PingFederate or PingOne with Office 365. Using Windows Powershell cmdlets on the DirSync server, the Ping Identity SSO IdP endpoints for active and passive profiles, as well as digital certificates will be registered with Office 365 that enable the SSO.
8. Configure PingFederate or PingOne. Using the Ping Administrative Console, 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 you user community continues to operate similar to 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.

Leveraging your existing investment in Ping Identity solutions to integrate with Office 365 is relatively straight forward. We’ve shared our lessons learned here, but if you need expertise or additional resources, we’re here to help.