Deploying Office 365 Education? You don’t need single sign-on, and here’s why!

TL;DR? Providing highly available single sign-on to cloud solutions can be a complex thing to do. The most successful deployments keep things simple, and work up. In most cases, there are better, quicker, and more cost effective ways to simplify access for students and teachers.

There are a number of ways to provide access to Office 365 Education; everything from a separate username and password, through to transparent single sign-on. If you don’t already have the infrastructure and skills in place to roll it out, the latter can be complex to achieve. I’ve come to the conclusion that on day one you don’t need single sign-on, and here’s why!

I should preface this post by saying two things. First, my argument is largely aimed at primary and secondary schools (or K-12 if that’s your thing). Further and higher education institutions have the advantage of bigger IT departments, relatively bigger budgets, and generally more expertise on site.

Second, my argument isn’t just centred around the technology. Obviously, with an unlimited budget and time providing the richest, seamless, experience to users is desirable. That said, there’s a balance between what’s nice and what’s necessary on day one.

Why move to Office 365?

It helps to understand why people move to Office 365 Education in the first place. Almost every time I speak to a customer about what they’re trying to achieve by moving to the cloud they come back with the same aims:

  • Make IT easier to manage, or quickly replace ageing and failing infrastructure.
  • Take advantage of the huge (and free) amount of storage you get in Exchange Online, and SkyDrive Pro and give users the best technology experience possible.
  • Give access to school resources from home.

Usually this is driven by the IT department, but increasingly I speak to people who are getting an SLT directive to “move to the cloud” as soon as possible, and to make it totally seamless for students and teachers. It seems that “SSO” is becoming a bit of a buzzword amongst non-technical folks, it’s just a shame that they don’t always fully understand what it means!

Seamless: single or same?

I define single sign-on (SSO) as being a system by which a user authenticates once at the domain-joined desktop and is not given any further prompts to enter credentials to access other managed services, including Office 365. SSO for Office 365 Education is typically enabled by SAML 2.0 technologies like Active Directory Federation Services (AD FS), Shibboleth or other implementations of the SAML 2.0 protocol.

Same sign-on (or CSO, as in consistent sign-on), by contrast, is a means of ensuring that every managed service a student or teacher accesses can be done so with the same username and password; even if that means entering it in a few different places. CSO for Office 365 Education is enabled by using the Windows Azure AD Sync Tool (DirSync) to synchronise user accounts and passwords from your local AD to Windows Azure AD; the identity store underpinning Office 365.

At a really high level, there are four models for deploying Office 365:

Cloud ID Synchronised ID Sync’d ID + Password Sync (CSO) Federated ID (SSO)
Accounts in Office 365 are totally separate from accounts in the local AD.They might look the same (i.e. username might match) but the passwords are not linked. Accounts are created manually. Accounts in Office 365 are synchronised with the local Active Directory.Usernames are the same in both places, but passwords are not linked. Accounts can be created automatically. Accounts and passwords in Office 365 are synchronised with the local Active Directory.Usernames are the same, and the local password is also synchronised. Accounts can be created automatically, and when a user changes the password on-premises, this is changed in Office 365 automatically. Accounts in Office 365 are copies of accounts in the local Active Directory but all authentication is handled at the school.No passwords are stored in Office 365, and the school must ensure its federation servers are available 24×7 or no users will be able to access Office 365.Accounts can be created automatically.

The third option, synchronised ID + password sync, is a perfect balance between simplicity, time to deploy, and user experience.


No, not the 70’s painted rock band.

The “keep it simple, stupid” principal applies perfectly when it comes to deciding whether or not you need single sign-on. The best guidance I can give in all my years of helping customers deploy this technology is to avoid complication.

Adopting a new model of consuming services from software-as-a-service providers is a big enough paradigm shift without adding to the complexity of it all by trying to achieve SSO from day one.

Scale at your own pace

The beauty of Office 365 is the flexibility and choice offered when it comes to deciding how to deploy. Keeping KISS in mind, starting simply does not mean you write-off any future hopes of being able to scale up to full SSO; you can build up your deployment over time.

For the same reasons I recommend people pick one Office 365 Education workload (such as Exchange Online) to deploy first and add others over time, I also recommend starting either with just Cloud IDs or CSO and then see how you get on. You can always “upgrade” to SSO later. Let’s also not forget that you don’t have to do any of this yourself; there are trusted Microsoft partners, like IAM Cloud, or RM’s Unify, who can implement and even host the whole SSO infrastructure so that you don’t have to.

So what’s the real difference to my students and teachers?

The experience for your students and teachers accessing Office 365 falls into three categories. Let’s say that you’ve decided to go down the SSO route, below is a table describing the experience users would get via a web browser:




Domain-joined, inside school network.


Personal device, inside school network.


Any device, outside school network.


As you can see, even in the SSO world the only scenario where a user actually gets “SSO” is on a domain joined device in school. When they go home, or are using their own device in school they’re getting CSO anyway since they’d be prompted to enter their username and password when they hit your external-facing AD FS proxy servers, configured for Forms-Based Authentication, rather than benefitting from the internal AD FS servers that will use Integrated Windows Authentication to make it all seamless.

What’s right for the job?

Aside from the technology arguments, getting best value for money in schools is very important. That doesn’t mean cheapest, or most expensive, but rather I think “right for the job”. Providing a highly available, redundant, secure, and seamless SSO infrastructure is never free, and in some cases would require investment in order to implement properly. If you’re going to make the investment it should be carefully planned and executed properly. There’s no point in cutting corners, otherwise you should stick to CSO. So, you have to ask yourself what’s more important: having the same username and password everywhere, or only having to enter it once?

And now for my final thought…

For those who like to have all the trimmings, so to speak, SSO is an awesome finishing touch and can really make the difference between a service that’s used by some and one that’s relied upon by all. SSO must be done properly though. You should carefully consider whether you can make your SSO infrastructure sufficiently reliable because in the event of an outage your users will not be able to authenticate. If access to services such as Lync Online, Exchange Online and SharePoint Online is critical then you might want to consider either sticking with CSO, or looking at the Office 365 Adapter and Microsoft partners to help.

Ultimately my point is that you shouldn’t rush into it and end up biting off more than you can chew. Start small, grow big. KISS. Insert any other cheesy idiom.

I’d love to know your thoughts, if you’ve managed to read this far, in the comments.

Featured Image: J Aaron Farr