Sign up for Office 365
Learn more about Office 365
This post describes the steps necessary to pilot single sign-on (also known as identity federation) using corporate credentials within a production user forest through the use of a fictional organization “contoso.com”. This post assumes that the reader is somewhat familiar with single sign-on (identity federation) with Office 365 and that they have already read:
There are two key scenarios involved in piloting and staging rollout of single sign-on to an organization:
Scenario 1: The organization knows that it wants single sign-on (identity federation) to Office 365 right from the start. Therefore the organization establishes a trust between its Active Directory (via Active Directory Federation Service 2.0) and Office 365.
Scenario 2: The organization has decided initially not to use single sign-on (identity federation). Instead the organization’s users are using Microsoft Online cloud IDs (i.e. non-federated IDs) to sign in to Office 365 services. At some point later the organization decides that they want to start using single sign-on, by converting their existing users from standard Microsoft Online cloud IDs to federated IDs. This is a more complicated scenario for piloting and staging rollout, and hence is described in much more detail below.
Contoso Ltd. is an Enterprise size organization with over 2000 employees worldwide. Contoso has deployed Active Directory on premise in a single forest contoso.com. Contoso is also an O365 customer and has over 2000 O365 suite licenses. Contoso has verified domain ownership of contoso.com with O365, and uses Directory Sync to synchronize their on premise AD forest contoso.com (users, contacts and groups) with O365. This has automatically created Microsoft Online IDs (cloud credentials) for each of the on premise users (logon enabled users) in the contoso.com forest. Hence, all Contoso employees using O365 have a cloud credential/UPN (separate from their corporate credential) under the contoso.com. Additionally, contoso.com is the organization’s primary SMTP domain.
Contoso is very happy with their move to Office 365. However they are evaluating various pain points associated with managing accounts on premise and in the cloud. This has led to Contoso researching single sign-on. As such Contoso has decided that the investment to deploy single sign-on is worth taking. However, before making that investment, Contoso IT Admins would like to first pilot single sign-on with real production users and test various federated authentication scenarios before rolling this out to the rest of their company.
Contoso Publishing (or your organization) already has:
Steps to Pilot
Once Contoso is satisfied that single sign-on is correctly configured and working properly through the pilot testing process outlined earlier, Contoso is now ready to roll this out to the existing production users. This involves 2 main steps:
 Being prompted for credentials may not happen immediately because the client caches a service token for the user. When the service token expires, the user will be prompted for credentials.