Office365 / SSO Advice

[IT-Tom]

Hello all,

 

I wondered if anybody else was in a similar situation to ourselves as we have just upgraded from Live@EDU to Office365 and I am after some advice.

 

For Live@EDU we provisioned user accounts manually via CSV - this was ok as we were staging our rollout and only had two year groups with accounts. Now we have upgraded to Office365 we are looking to move over all staff / students (~1600) - due to the volume, it would be much easier to manage if we were able to sync via AD.

 

Current setup - MSOL accounts ([email protected])

 

Internal domain - (school.local)

 

Internal account names UPN example - [email protected]

 

I've read the guide and I understand that we add our Office365 domain as an additional UPN - but how do we map AD accounts to current MSOL accounts - if they have different names?

 

Also for new provisioned accounts - internal usernames are staff codes, such as: SH whereas their e-mail address would need to be [email protected].

 

What is the best way to go about organising this 'migration' - I don't want it to affect current accounts - but I want it to create new accounts for staff / students that don't currently have a 365 account.

 

Not sure if I have explained this well - I am just starting this process and I want to ensure I have a clear picture in my head before continuing.

 

Many thanks.

[EduTech]

Hi Tom,

 

First of all you would not be able to authenticate against Windows Azure AD (Office 365) with your .local UPN because the domain part would not be verified in office 365 and cannot be due to it being internal only. so all of your user accounts UPN needs to be changed to the one you use in office 365 i.e. schooldomain.co.uk

 

If I was you I would take the following approach:

 

- Add your schooldomain.co.uk as a UPN within Active Directory Domains & Trusts

- Login to your Office 365 Portal and Enable SSO for your primary domain schooldomain.co.uk

- Install DirSync on a Domain Member Server, go through the DirSync Configuration Wizard and then start the sync between OnPremise AD & Windows Azure AD

 

Once this has been completed you will find that all of your user accounts will now appear in Office 365, and they will contain the correct UPN. To authenticate against Office 365 you will use the UPN to authenticate & the password for the user accounts that they previously had all being well.

 

If you then wish to add Single Sign On into the mix, you will need to built your AD FS Infrastructure and then when you have done this you will need to convert your domain to a federated domain and then this will enable you to authenticate using your active directory UPN & Password.

 

These changes will not affect your Internal Logon Services because your users won't be using the UPN to authenticate internally i imagine, they would just be using there normal username and password.

 

The only thing I would say be careful off, is if the user accounts within Office 365 already have the schooldomain.co.uk as the primary user name then you just need to make sure that it sync's up correctly, you might have to run some powershell commands to convert these domains properly but in theory it should recognize the match and sync up.

 

The username that people will normally be using won't be a problem, as Office 365 only cares about the UPN which I would always try and make the same as the Primary SMTP Address. This is assuming your users logon with the Pre-Windows 2000 Username & don't already use there UPN to logon to internal systems.

 

I hope that helps, rather quick reply but if you have any question feel free to respond and i will get back to you.

 

Thanks,

James.

Edited March 24, 2013 by EduTech

[jamesbmarshall]

I've read the guide and I understand that we add our Office365 domain as an additional UPN - but how do we map AD accounts to current MSOL accounts - if they have different names?

 

Because you've already got users provisioned in Office 365 you'll have to go through a process of "soft matching" those existing accounts with your local AD accounts when you run DirSync for the first time. In order to ensure everything ties up correctly you need to make sure that the UPNs of the existing users in AD match up with the accounts provisioned in Office 365.

 

Adding, or changing a UPN suffix in AD is fairly simple but be aware that you might have internal services that rely on UPN that may break as a result of changing - you should ensure that altering your UPN suffix will not disrupt any other services. In most cases, it's fine.

 

Also for new provisioned accounts - internal usernames are staff codes, such as: SH whereas their e-mail address would need to be [email protected].

 

It is possible for users in Office 365 to have a different logon name to their primary SMTP address. Their logon name, i.e. their UPN, will have to match up with what is in the local AD, but you can set the mail attribute to be different. See: List of attributes that are synced to Windows Azure Active Directory and attributes that are written back to the on-premises Active Directory Domain Services.

 

What is the best way to go about organising this 'migration' - I don't want it to affect current accounts - but I want it to create new accounts for staff / students that don't currently have a 365 account.

 

As long as you ensure there are no odd duplicates, and that your local UPNs match up exactly with the corresponding existing users in Office 365 you should be ok. If you want help I'd definitely recommend reaching out to a Microsoft partner. Identity can be a complicated thing to get your head around, and our partners have a wealth of experience and expertise that can help!

 

Before you do anything, I'd strongly recommend you run and digest the results of this tool: Microsoft Office 365 Deployment Readiness Tool - Downloads - Office 365 - Microsoft Office 365 Community.

[IT-Tom]

Thank you for the advice guys - going to have a proper look at this over Easter - hopefully get it all up and running!