O365 and SSO
Recently I decided that I wanted to give all my users the free office they can get under EES Student Advantage. I had looked into this before and it was one hell of a nightmare to set up I thought, looking at the poor Microsoft documentation, and my own lack of understanding.
Ultimately I wanted to do the following:
- Have users be able to login to O365, using their local domain credentials
- Only allow them access to OneDrive and to download office (we have local exchange 2013 here)
So here is what I did, with some of the bits I did wrong removed. I am hoping I can remember it all.
1) Get the licences
I had to get my EES supplier to add the licences I needed, so Luke at Millgate got this set up (well, he didn’t, someone else who has an idea of anything more then sales did!)
These Show up as Online Service Activations in VLSC – and you need to have a MS account ready set up to import them into. I actually found it really hard to find the link to sign up for education accounts – but here it is:
You get trials for 30 days of the full blown plan (E2/E3) but they are not actually what I wanted, I don’t want full O365. When you activate your Online Service from VLSC it creates new plans for staff and pupils which only gives them access to download the software and One Drive.
The rest of this will probably work for setting up full blown O365, but I haven’t trialed it. It certainly will get the users in.
2) Getting your domain sorted
Start this one early. You need to get some DNS or MX records done on your domain to prove your ownership, its straight forward stuff, but you cant sync users and do anything without it. Once logged into the 0365 control panel (login.microsoftonline.com) select domains and follow the instructions.
At this point, I strongly suggest setting up a user that is not someone who will be migrated over from AD at any point, for instance, I setup an admin2
3) Sorting out the Sync and SSO
So bloody complicated.
- If your domain is a .local or similar, or it doesnt match the your external domain, you will need to add an additonal UPN: https://technet.microsoft.com/en-us/library/cc772007.aspx
- You will then need to change the UPN users will use – you can do this in bulk in AD (select a load of users, right click etc), and it has no effect on anything else (or at least hasn’t so far)
- Choose a server to be your ADFS Server, that is not a DC, if you run a remote access server, with HAP or RDC (or both) with its own SSL already in place, great. You need an SSL to do all this wizardry.
- Install the ADFS role on this server. Best practice is to work through a ADFS proxy as well, but, well, I didn’t. Note: if you are installing on Server2008R2 you will need to download ADFS 2.0 – so don’t install the role. Install the role if Svr 2012R2
- ADFS 2.0 for Svr 2008R2 http://www.microsoft.com/en-gb/download/details.aspx?id=10909
- MS Guide for installing it: http://g.microsoftonline.com/0BX20en/228
- Install the Windows Azure Active Directory Module for Windows PowerShell – login to your admin on 0365 > users > Manage SSO and its number 3
- On another server download and install DirSync – the software that will Sync your AD to the cloud: https://technet.microsoft.com/en-us/library/jj151800 – this is pretty straightforward, but, you will need to redo it if you mess up anything such as change passwords, or setup the wrong domain or something. Once done, you should see users appear within 10 minutes.
- Back on your AFDS server, run the AFDS powershell – these are the all important commands you need to follow to setup the link etc
- Open the Microsoft Azure Active Directory Module for Windows PowerShell.
$cred=Get-Credential. When this cmdlet prompts you for credentials, type your cloud service administrator account credentials.
Connect-MsolService –Credential $cred. This cmdlet connects you to the cloud service. Creating a context that connects you to the cloud service is required before running any of the additional cmdlets installed by the tool.
Set-MSOLAdfscontext -Computer <AD FS primary server>, where <AD FS primary server> is the internal FQDN name of the primary AD FS server. This cmdlet creates a context that connects you to AD FS.
Note If you have installed the Microsoft Azure Active Directory Module on the primary server, then you do not need to run this cmdlet.
Update-MSOLFederatedDomain –DomainName <domain>. This cmdlet updates the settings from AD FS into the cloud service and configures the trust relationship between the two.
Remember when it talks about a domain, you want the UPN that matches your external domain, not your internal one.
Finally – to get SSO working accross browsers: http://www.powerobjects.com/2012/11/02/adfs-and-single-sing-o-cross-browser/
I am not a great tutorial writer I am afraid, but hopefully this might put all the links and the general process in a useful place.