Sysadmins: Chucked your Exchange servers up? Let's enable SSO

Keeping things simple for the users...

Sysadmin blog My previous article focused on migrating Exchange into Microsoft's cloud, but there is more to Office 365 than just Exchange. Single Sign On (SSO) between Office 365 and your local Microsoft domain can be a bit tricky. A proper implementation has high minimum requirements, and there are very good arguments against cutting corners.

SSO is about convenience. The more of Office 365's services you use, the more sense SSO starts to make. Nobody wants to be punching in the passwords a dozen times a day to use vital business tools.

There are some security arguments that can be part of the sales pitch, but in reality they boil down to "the more difficult you make things, the more likely your users are to disregard security". Economic arguments should also be considered: fewer passwords to remember and reset equals fewer support calls.

While the sounds ideal, the devil is in the details. The idea behind SSO is that a user either within the corporate firewall or operating in a cloud-tools-only mode can access Office 365's services and applications using their corporate credentials. Unfortunately, Microsoft's implementation of SSO is totally dependent upon Microsoft's cloud being able to communicate with a corporate active directory server.

The communications between cloud and corporate network is provided by Active Directory Federation Service (ADFS.) If the link between ADFS and Office 365 is down for any reason, users can't log in. Because of this, it is highly recommended that the ADFS servers on the corporate side of the equation be clustered. For the gold medal deployments, two clusters are recommended.

The first: a back-end ADFS pool. For security reasons, you don't want to expose your actual ADFS authorisation servers directly to the internet, but they need to be highly available so that staff can still access their cloudy services during updates, hardware failures, etc. The front-end ADFS proxy servers also need to be clustered, and for the same reasons. Preferably, they'd also have access to redundant internet access so that you can withstand the loss of a single ISP.

So what does it take to finish your Exchange to Office 365 migration and enable SSO?

Implementing SSO

In the previous article, I covered migrating mailboxes up to the cloud. In order to for SSO to work, we would now need to convert the remnant local mailboxes to mail-enabled users. We start by gathering mailbox information from Office 365 into a CSV, and then running a powershell script. The script is provided.

Next, we need to ensure the User Principal Name (UPN) for all of our users is set to a publically addressable domain name. This ensures that you can address your users as [e-mail], which Office 365 can understand. (As a public domain name, Office 365 can look up.) Adding a UPN suffix doesn't require you to change your internal domain name, so users will still be able to be addressed as [e-mail] behind the corporate firewall.

Now it's cluster time. Deploy Active Directory Federation Services' NLB cluster by running the ADFS wizard. Then create and deploy an ADFS cluster.

Be sure to double-check the size of your Active Directory. Less than 50K objects can be handled by SQL express; more requires a full SQL install. Additionally, there are limits to how many objects can be replicated to Office 365. If you think you might have more than 20,000 objects that need to be replicated, contact Office 365 support for some special hand-holding.

We round the SSO setup by installing the directory synchronisation tool and triggeringdirectory synchronisation. After this, you should have SSO set up between your domain and Office 365.

As you can tell, we left Small and Medium Enterprises (SMEs) behind a long time ago. This is major infrastructure: in many cases more than all of an SME's currently deployed server estate.

A practicable alternative exists. The Microsoft Online Services Sign-In Assistant (MOS SIA) was made to help bridge the gap. While each of your users will have two sets of credentials (local corporate and cloud-based), with the MOS SIA, you only have to sign in once.

While not SSO, MOS SIA is a freely downloadable tool that is "close enough" in practice. While useful and convenient, Office 365 SSO in its current form just doesn't make sense for SMEs. ®