Best Practices for Single Sign-on with Office 365

Many people are moving to an Office 365 environment to simplify control and maintenance of some of their core systems. These benefits can include the following:

  • Overtime reduced for technical staff’s support for email systems.
  • Reduction in on-premises storage requirements.
  • Reduction in on-premises hardware requirements.
  • Improved availability of service and redundancy (99.9% up SLA).
  • Less concern for individual mailbox storage requirements.
  • The ability to have a hybrid exchange model for hosting mailboxes locally, for situations where the hosted solution may not work.
  • Single Sign-on (SSO) federated to your on premises Active Directory (AD).
  • And last but not least, automated provisioning of users from AD.

But before you run out and sign up for Office 365 and implement SSO, there are some best practices and considerations you should review. This blog will highlight the key things you should know before you go to an Office 365 federated environment.

Where will your identities live?

For most of you going to Office 365, you probably have an on premises Active Directory environment. Some of you may use SSO vendors which require you to replicate all of your AD identities to their cloud service. Centrify feels that this is an unnecessary step that forces customers to give up a degree of control, is less secure, and forces vendor lock-in. Some SSO solutions require you to have up to eight different servers to provide the same functionality that Centrify can achieve with our Identity Service Cloud Connectors that can be deployed on existing servers. We believe that your FTE identities should stay on premise and that your 3rd party or contractor identities should live separately.

We provide our Cloud User Identity Service for just that hybrid scenario. We provide a model that addresses the complete application end-user life-cycle. We handle the process from on-boarding to application authorization for both mobile and web, and when the time comes you have a single point of de-provisioning.




Having said that, this is a great opportunity to do some AD cleanup and make sure you are ready for a federated Office 365 environment.

UPNs and Domain name

One of the things that AD brought us was the ability to have non-routable local domain suffixes such as “mycompany.local”. This is a great security practice and reduces the ability to hack from the outside. But guess what? Before you can go to Office 365 or federate to AD you need to use an Internet-resolvable domain name as the suffix in each user’s username. If you have a .local domain you now need to add the Internet routable domain UPN suffix to Office 365 and AD. Don’t worry it’s easy to add a UPN suffix. Here are the steps.

  1. Open Active Directory Domains and Trusts.
  2. In the console tree, right-click Active Directory Domains and Trusts , and then click Properties.
  3. On the UPN Suffixes tab, type an alternative UPN suffix for the forest, and then click Add.

Prepare Your Centrify Identity Service Environment

If you are not already a Centrify customer it’s easy to get started with a trial at Centrify will also come on site and show you how to set everything up for your proof of concept. Here is a great video from our CTO Paul Moore that shows how the Cloud Identity service works. One note is that our proxy service has been renamed to Cloud Connector.

If you are a customer or you have signed up for our 30-day trial, the first thing you will get is a set of credentials to administer the Cloud Identity Service. When you log in, the first thing to do is change your administrator password and be sure to use a complex password. From there you will need to install a cloud connector on any member server in your domain. It can be a physical server or virtualized. You can have as many as you like and can have them distributed across your global enterprise. You can find a short 5-minute video of the process here.

Add Your UPN Domain to Office 365

The earlier example used a publicly resolvable domain name of with an internal Active Directory domain of yourcompany.local. Your domain can be anything. The Active Directory name doesn’t need to align with the external domain you use for e-mail addresses, although doing so makes things easier for users to remember.

If the publicly resolvable domain name you choose isn’t already linked to Office 365, do so via the Microsoft Online Services Portal. Click Domains in the Admin console and then select Add a Domain. The wizard will prompt you for the domain name, and then give you one of two options for authenticating ownership. You’ll need to add either a TXT or MX record to the publicly accessible DNS server hosting the domain.

It can take anywhere from 15 minutes to 72 hours for the update to fully propagate, so it might take a while before you can complete the validation process. Validation affirms to Office 365 that you own the domain name your clients will later use to authenticate. You don’t need to have any servers within this domain for federation to function. All you need to complete this step is the domain itself that you can resolve from the Internet. You can find the “how to” video here.

Connect Centrify with Office 365 and Synchronize Active Directory User IDs

Now it’s time to configure Office 365 to federate user authentication. This process entrusts your internal Active Directory domain with authenticating users, while letting Office 365 merely trust your domain’s authentication response. That’s the cool thing about federation—no passwords are ever transferred between ADFS and Office 365, it’s just a secure token exchange.

While federation removes the need to send passwords between Active Directory and Office 365, it still requires that you continuously synchronize user accounts. You can perform this synchronization manually and then edit each user to assign a license profile, or you can use the Centrify Identity Service to not only synchronize users but provision them also.

Below are all three of Centrify’s Office 365 federation and provisioning “how to” videos that will take you through all of the above necessary steps. Each video is about 5 minutes long.

  • Part 1
  • Part 2
  • Part 3


Validate Synchronization and Verify Federation in a Test Environment

As with all projects it is best to validate in a test environment. You can easily sign up for a separate O365 trial and use a sub domain or your externally routable domain, e.g. Centrify allows you to assign applications to individual users or groups of users so you can test with pilot groups and then roll out to the entire enterprise.

Centrify’s online help system can help if you run in to any issues. And don’t forget to checkout Centrify’s SaaS community site for some additional resources.