Similar Sign On In Office365

Identity, and Identity Management (IDM), is key for any organisation to accurately and securely manage their users and in this sense, schools are no different when it comes to their students and staff.

I have been talking to a number of schools recently who are using either open source LDAP solutions for managing the identities of their students and staff or perhaps using Cloud only identities in Google’s G Suite – in other words, no local Active Directory in place on their network. Many of these schools are simply creating a CSV file of their users and uploading to G Suite meaning they have no equivalent users in Office 365 to sign into the various Microsoft services if they wished to.

A Range Of Possible Solutions:

There is a range of solutions available to schools that slide along the spectrum of technical competency and cost to implement, with some being:

Move the school’s Identity to AzureAD and use integration with G Suite to create true Single Sign On (SS) functionality – this is the best solution but requires reasonably technical skills and often comes at a cost from a partner, therefore it can be a barrier to schools trialing Office365, especially if they wish to keep their email in G Suite.
Encourage schools to use the free School Data Sync (SDS) tool. This is not always feasible / easy because of the formatting required in the 6x CSV files and/or the ability to easily export required data from their Student Management System (SMS) is varied.
If the school is using an Active Directory at their school then they can synchronize the users and groups into AzureAD using the free AzureAD Connect tool.

All of the above are awesome solutions that would deliver a great outcome but require varying levels of technical skill and/or investment with a partner to achieve. Is there a super simple solution that gives schools a “similar sign on” experience?

Similar Sign On:

This is a solution based on adding the school’s real domain name to their O365 tenant, verifying their ownership of it, but not modifying their MX/A records and therefore not impacting their production G Suite environment.

This can be achieved by:

Add the school’s live domain name e.g. school-name.school.nz to their O365 tenant (instructions here), verify ownership of the domain name by adding a TXT record to the zone file of the DNS (this does NOT change/break the MX (email) or A (website) records of the domain name)
Make the school’s domain name the default domain name (instructions here) so that any new users are going to be added under the correct school name i.e. @school-name.school.nz and not the alias e.g. @school-name.onmicrosoft.com
Upload the school students/staff into O365 using the bulk upload via CSV tool (instructions here) – this is virtually identical to the way the school has been adding users to G Suite so they should be very familiar with this.
1. Note: this will replicate the email address format of G Suite that the school has been using e.g. first.last@school-name.school.nz instead of the sub-optimal first.last@school-name.onmicrosoft.com alias that would have been used by default in O365 if the domain name had not been added/verified
2. NOTE: O365 will create a generic password by default and these can be emailed to a single user for distribution to students or bulk set for all users to a standard password with forced reset turned on, so students/staff would need to change their O365 password the very first time they logged in.
3. At this point users are effectively replicated from G Suite into O365, except they have a different password. It is expected most students/staff would set the same password in O365 that they have in G Suite (note: if they change their password in either G Suite or O365 this will not change their password in the other platform. It’s “Similar Sign On Solution” not “Single Sign On”.
NOTE: at this stage, all users would have O365 plans that would include “Exchange Plan 2” – this gives them the ability to see the “Outlook” app in their https://portal.office.com and send emails on their last@school-name.school.nz domain name which is not what you want (all students/staff should be sending email via G Suite in this model)
1. Go to the O365 Admin Portal (https://portal.office.com/adminportal) and disable the Exchange 2 plan for ALL users (instructions here) to prevent the ability to send/receive emails internally on the school domain name within O365 (note: there may be some dependencies when you go to turn off Exchange 2 e.g. MyAnalytics, Planner, Forms etc)

Outcome:

Students/Staff can now sign into any MSFT app that prompts for O365/AzureAD credentials using their first.last@school-name.school.nz email address e.g.

https://portal.office.com
Minecraft:EE sign in
AzureAD joined devices

This is the cheapest/easiest/least disruptive way for “Google Schools” to use O365 and without requiring major technical work to get true SSO turned on and critically, without disrupting their production G Suite environment.

Screenshots Of Making It Happen:

Sign into O365 Admin Portal as a Global Administrator and select “Domains” to edit

Choose to add a new domain name and type it in (you need to have registered a domain name at this stage already, but if you have an existing school domain name using G Suite you’ve already done this):

The next stage involves verifying that you own the domain name by adding a TXT (information) record to your domain name with the registrar where you purchased the domain name. You do need to take a lot of care here because if you change existing records incorrectly, this may have the potential to impact your production environment. O365 tells you the information you need to add as a TXT record:

I signed into my registrar where I purchased/manage my domain name, and chose to edit the DNZ/Zone Record and added the relevant information:

Once I had the records in place and saved my configuration changes I went back to O365 Admin Portal and selected to manage my own DNS:

This gives you the option to NOT select “Exchange” which you should unselect if your email is managed elsewhere, i.e. G Suite:

My domain name was then added and set to Default. If the .onmicrosoft.com is still the default setting amongst your domain names, then select your new domain name and choose “Make Default”

With the domain name in place, you’re ready to add multiple users (i.e. students/staff):

I suggest you download the CSV with example users in it so you can see the correct syntax and demo data of what you can upload:

I used a quick Flash Fill in Excel to replace the example domain name with that of my new domain I’ve added

Do make sure you save the file as a .CSV otherwise it will be rejected:

Upload the file and verify the syntax and formatting is all correct:

Choose the correct default settings for your Users you’re creating & assign the appropriate licenses:

As per instructions above, if you’re going to keep your email at G Suite or elsewhere, make sure you’ve turned off the Exchange Online (Plan 2), along with any apps that have dependencies on this e.g. Bookings, MyAnalytics etc:

Success – users are created:

If you go to the Active Users you’ll see that the new user has been added, with the correct domain name of mcneill.net.nz (this would be your school domain name) and there is no mail available for this user:

Time to test! Go to the Office365 Portal and sign in with one of the new users with the new domain name e.g. ben@mcneill.net.nz

Once you’re signed in you can see the various O365 apps and, importantly, there is no Outlook email app so users can’t send emails from this environment when their real email is managed elsewhere:

Conclusion:

The idea behind this “Similar Sign On” is a simple, low-tech way of allowing students who use a different Cloud Suite as their primary online platform to get into Office365 and have a good experience using their school domain name.

It’s not the recommend method if you’re committing to Office365 permanently (although some of the above steps are still relevant) but in terms of creating an easy way for schools to get started the above works effectively. Where I see this gaining a lot of interest is in the area of Minecraft:Education Edition. A school may only have users in Google but want to use Minecraft:EE in the classroom and allow students to sign in with their school email address. Using the example above of ben@mcneill.net.nz this is very easy, even though the domain name is pointing to Google’s G Suite for email: