Office 365 – Identity Scenario Adoption Approach
When considering to use Office 365 for your organization, you go ahead and sign-up for a Free Trial and many people think that they need to do loads of work with there on-premise infrastructure before they can start to look at the benefits of office 365 when the truth is you can try out Office 365 without actually changing your on-premise configuration.
Identity Scenarios
First of all, I will start by giving you an overview of the 3 different identity scenarios
Cloud Identity
Users are created and managed in the Office 365 Administration Portal, and are stored in Windows Azure Active Directory (WAAD) and there is no connection to your organization directory services.
Cloud Identity has no initial integration requirements as it is totally separate from your organization infrastructure, Each user is created in the cloud identity platform and only exists in Windows Azure Active Directory.
Directory Synchronization
Users are created and managed by an on-premise identity provider (Generally Active Directory) and are synchronized to Windows Azure Active Directory (WAAD) so that you can use the same On-Premise Identity to login to Office 365 Services.
Directory Synchronization uses an existing on-premise directory and synchronizes it to Windows Azure Active Directory, This synchronization can be done from an On-Premise Identity Provider such as Active Directory using the Directory Synchronization Tool or it can be done from an identity provider that is non-active directory using PowerShell and Azure AD APIs.
Synchronization means that your user accounts are managed on-premise which also means that the user attributes cannot be edited through the Office 365 Administration Portal, If you are using the Directory Synchronization tool with Windows Active Directory then you will also be pleased to know that in an update released earlier this year also means that passwords can also be synchronized so that your users can not only login with the same username, they can also use the same password when using Office 365 Cloud Services.
Considerations:
- SQL Server is recommended if you have more than 50,000 User Objects
- Directory Sync should not be installed on a Domain Controller
- Don’t forget about it, Keep an eye out for new version releases
Federated Identity
In order for Federated Identity to work, you will also need to use Directory Synchronization but rather than synchronizing the passwords you will only synchronize the identity, unlike directory sync which just synchronized the username & password with federated identity login requests are handled by the on-premise identity provider, and people generally implement federated identity for the added benefit for Single Sign On (SSO).
Identity Federation allows a user to be signed in using the federated identity provider for the users password, as mentioned above directory synchronization is still required as a pre-requisite in order to populate Windows Azure Active Directory. I most common scenarios organizations use Active Directory Federation Services, which manages the password aspect of the login process with the On-Premise Active Directory Infrastructure. In other scenarios as oppose to Active Directory Federation Services.
Active Directory Federation Services Overview
Considerations
(AD FS) Feature |
Windows Internal Database (WID) |
SQL Server |
Scalability |
Limited to five servers in the farm |
No limitation |
High Availability |
built-in “replication” mechanism |
Needs SQL cluster |
Adv. features |
Not available |
SAML artifact resolution & SAML/WS-Federation token replay detection |
NOTE: In terms of Office 365 it does not use any of the AD FS Advanced Features and so WID is still a valid choice.
If you are going to be using a 3rd party for identity federation ensure that the company is listed on the ‘Works with Office 365 Identity Program’, If you use a Non-Active Directory you may wish to use Shibboleth Identity Provider, Shibboleth is a SAML 2.0 Identity Provider.
Use third-party identity providers to implement single sign-on
The 3rd Party providers use one of the following two protocols:
- WS-Federation is the protocol used to support sign-in to Office 365 using the web interface, sometimes known as "passive authentication." This includes the Office 365 portal, SharePoint Online, Outlook Web Access, and the Office Web Apps.
- WS-Trust is the protocol used to support sign-in to Office 365 using Office client applications, sometimes known as "active authentication." This includes Outlook, Lync, Word, Excel, PowerPoint, and OneNote.
Use Shibboleth Identity Provider to implement single sign-on
Shibboleth is an alternative to the WS-* protocols, and it provides sign-in support for web applications that is similar to WS-Federation. In some cases Shibboleth can also be used to sign in to Outlook using the Enhanced Client or Proxy (ECP) extension.
NOTE: Sign-in to Office 365 from other Office client applications is not possible with Shibboleth.
The Approach
I have worked with many organizations around the globe assisting them with the adoption of Microsoft Office 365 and my recommendation continues to be the same, keep it simple and ramp up. there is no requirement for you to deploy federated identity right from the start you have the ability to start off using cloud identity, and then if you were happy with the services office 365 provides you could look at implementing Directory Synchronization & Password Synchronization and then if you wanted to provider you end-users with the complete single sign on (SSO) experience then you should look at implementing federated identity.
If you are looking to do an Exchange Hybrid Deployment in order to migrate your organization to Exchange Online, people’s perception is that Active Directory Federation Services is a requirement, when the truth is that it isn’t, Single Sign On (SSO) is though recommended though in a hybrid deployment but it is NOT a requirement.
The only disadvantage to organizations when deploying Single Sign on is that you have to install new servers, which require a certificate issued by a certification authority (CA) and add some complexity and cost to user management, but this can be simplified and much more cost effective if you consider looking at putting this infrastructure in Windows Azure using Infrastructure as a Service (IaaS) platform.
Single sign-on is good solution for some large organizations that plan to migrate all mailboxes to Office 365 over many months and for most organizations that plan to maintain an on-premises set of Active Directory resources along with Office 365, single sign-on is a good solution for streamlining user identity management.
Sign-On Experience
So, I imagine this has crossed many peoples minds and that is what are the differences in terms of user experience when selecting the right identity scenario for you, obviously depending on what identity scenario you choose with depend on what the users experience is going be, so for example if you choose to use cloud identity when deploying office 365 to your organization your users and you have a separate directory service on-premise then your users are going to have to remember to separate sets of credentials, and from an IT Administration point of view this will give you much more of an overhead as you will have to also manage these users identity separately to the corporate directory, likewise if you plan to implement directory sync your users may have the same identity but unless you choose the option to synchronize the password hashes your users will need to remember a separate password, and keep this updated and you as an IT Admin will have to manage password resets from within the Office 365 Administration Portal & On-Premise Directory which is why Microsoft brought the password sync feature to the market which is something that i would recommend you enable should you choose to implement directory synchronization. The experience in this scenario is by far the easiest to manage from an IT Administration perspective and also employees will only need to remember one set of credentials and will also mean you have no complex infrastructure to manage but like everything without the extra infrastructure you loose the Single Sign On Experience which if your used to having On Premise Exchange, SharePoint or Lync deployments then this might be a disadvantage for your users.
The following table will show you in a simple overview, the different experiences when choosing which identity provider to go with long term:
Conclusion
It’s simple really, just remember to Keep It Simple Stupid (KISS) when adopting Office 365, do not try to over complicate the experience at the start learn how the platform works, take full advantage of the services that are provided and ensure it meets your organization requirements once you are happy, do a pilot and engage your end-users with the cloud experience and generate feedback, you can do this with a separate identity in the first instance if required so that you do not need to deploy any infrastructure, accepted that in some larger organizations this isn’t a valid pilot then still keep things simple and start of with directory synchronization with password synchronization so that your users are able to keep the same identity. Once you are happy, then you weigh up the experience for the users if you can deploy office 365 to your organization using Directory Synchronization then do so, get everyone migrated and then at a later date if you want the advantage of Single Sign On, Go ahead and implement Federated Identity.
I hope that you have found this overview, to be of help! if you have any questions, be sure to drop me a note using the contact form.
Many Thanks,
James.