Feeds

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

Keeping things simple for the users...

5 things you didn’t know about cloud backup

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 username@externaldomain.tld, 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 username@internaldomain.local 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. ®

Build a business case: developing custom apps

More from The Register

next story
Microsoft: Azure isn't ready for biz-critical apps … yet
Microsoft will move its own IT to the cloud to avoid $200m server bill
Shoot-em-up: Sony Online Entertainment hit by 'large scale DDoS attack'
Games disrupted as firm struggles to control network
Silicon Valley jolted by magnitude 6.1 quake – its biggest in 25 years
Did the earth move for you at VMworld – oh, OK. It just did. A lot
VMware's high-wire balancing act: EVO might drag us ALL down
Get it right, EMC, or there'll be STORAGE CIVIL WAR. Mark my words
Forrester says it's time to give up on physical storage arrays
The physical/virtual storage tipping point may just have arrived
VMware vaporises vCHS hybrid cloud service
AnD yEt mOre cRazy cAps to dEal wIth
prev story

Whitepapers

A new approach to endpoint data protection
What is the best way to ensure comprehensive visibility, management, and control of information on both company-owned and employee-owned devices?
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Maximize storage efficiency across the enterprise
The HP StoreOnce backup solution offers highly flexible, centrally managed, and highly efficient data protection for any enterprise.
How modern custom applications can spur business growth
Learn how to create, deploy and manage custom applications without consuming or expanding the need for scarce, expensive IT resources.
Next gen security for virtualised datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.