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 “”.  This post assumes that the reader is somewhat familiar with single sign-on (identity federation) with Office 365 and that they have already read:

  1. How single sign-on works
  2. Preparing for single sign-on
  3. Plan and deploy AD FS 2.0 for Office 365
  4. Establishing a trust to Office 365 Install and configure the Microsoft Online Services Module for Windows PowerShell for single sign-on

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.

  • In  this scenario, the organization is able to pilot and stage rollout, to its users, of single sign-on to Office 365 services, by simply licensing directory synchronized federated users in the administration portal (once they have established the trust using the Microsoft Online Services Module for Windows PowerShell)
  • Additionally the organization can set up an Authorization claim rule on the ADFS 2.0 server, that will only generate a security token (for the authenticated user) if they are a member of an on-premise security group.  Hence your pilot users can be put into this security group, as can your other users as you stage rollout to the organization.

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.

  • NOTE:  Staging rollout of single sign-on to your organization for this scenario is not currently possible with Office 365.  This is because conversion of a standard domain to a federated domain is currently an all or nothing switch (all users are automatically converted to use single sign-on at their next login).  A federated domain may only contain federated/single sign-on users.
  • However, piloting single sign-on with a set of production users from your production forest is possible and is described in detail below.

Setting the stage

Contoso Ltd. is an Enterprise size organization with over 2000 employees worldwide.  Contoso has deployed Active Directory on premise in a single forest  Contoso is also an O365 customer and has over 2000 O365 suite licenses. Contoso has verified domain ownership of with O365, and uses Directory Sync to synchronize their on premise AD forest (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 forest.  Hence, all Contoso employees using O365 have a cloud credential/UPN (separate from their corporate credential) under the  Additionally, 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:

  1. AD on premise.
  2. A single forest containing the user accounts.
  3. Directory synchronization running in their forest.
  4. Users logging in to Office 365 using Microsoft Online cloud IDs that are under the forest domain (like  These are non-federated accounts and are therefore authenticated by the Office 365 identity system.
  5. Users who have a primary SMTP address under  (Note:  this is not mandatory.)
  6. Not yet set up single sign-on.

Steps to Pilot 

  1. Deploy AD FS 2.0 (as per Plan for and deploy AD FS 2.0 for Office 365) in Contoso’s production environment.
  2. Purchase a new domain from a domain registrar.  This domain should be distinct from your production domain (i.e. this cannot be a sub-domain of an existing production domain).  For example here we will assume purchase of and use this in the example from now on.
  3. Federate the domain with Office 365 by following the instructions in Install and configure the Microsoft Online Services Module for Windows PowerShell for single sign-on  on “how to Add a federated domain”.
  4. Add as another UPN domain suffix in your Active Directory forest (See for instructions).
  5. Select pilot users for this pilot program and inform them (ahead of time via emails) that they are part of this single sign-on pilot and the login changes that they should expect during this pilot, and when this change is scheduled for.  Inform them that once the transition is complete that at any time when asked to enter an ID, they need to enter their new UPN (the one under the domain).
  6. Go into Active Directory Administrative Center or ADSI (Active Directory Users and Computers) and toggle the pilot user’s UPNs to be under the domain.
    1. NOTE:  If the users who are in the pilot test group have smart cards then this technique may not be appropriate, since it involves changing the UPN of the user and will render their smart cards invalid for the period of the pilot program.  Organizations should also review whether there are any internal applications or resource access that makes use of user’s UPNs and whether they need any updating.
    2. NOTE:  This will not affect the user’s SIP address or SMTP proxy addresses.  It is perfectly valid to have a UPN that is different from a primary SMTP address.
    3. Once all the pilot users have had their UPNs changed, go to the DirSync machine and “force” a synchronization (or simply wait up to 3 hours for the next sync):
      1. Go to %program files%\Microsoft Online Directory Sync.
      2. Double click on DirSyncConfigShell.psc1 to open a powershell DirSync snap-in session.
      3. At the PS command line type:  Start-OnlineCoexistenceSync and press Enter.
      4. Check that the DirSync update is complete by logging on to the O365 administration portal and into the Exchange Control Panel (ECP) and looking at the user lists in both places.  Your pilot user’s UPN changes should be reflected in both the user lists.
      5. Contoso pilot users are asked to thoroughly test various sign in scenarios to ensure that single sign-on (and the AD FS 2.0 deployment) is correctly configured, and that single sign-on is ready to be rolled out across the entire organization.  Tests include accessing Office 365 services from both browsers and rich client apps (such as Office 2007 or Office 2010, Skype for Business (formerly known as Lync) and Outlook 2007 or Outlook 2010) in the following environments:
        1. From a domain joined machine.
        2. From a non-domain joined machine inside the corporate network.
        3. From a roaming domain joined machine outside the corporate network.
        4. From a home PC.
        5. From a web kiosk (browser only).
        6. From a smart phone (i.e. Exchange Active Sync).

Federate the production domain

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:

  1. Moving the pilot users back into the production standard domain ( and removing the test federated domain (  Removing the test federated domain means that the AD FS 2.0 deployment can now be used to federate your production domain (
  2. Federating the domain, by converting this standard domain to be federated
  3. Inform the pilot users that they are being moved back to the regular production domain and that their single sign-on experience will temporarily go away.  Inform them that their UPN will change back to the production domain ( and that they will be issued with a new temporary password to access Office 365 (i.e. the experience they had before the pilot program began).  They should also be informed that as part of this move they may experience a brief period of downtime.
  4. Toggle the pilot users UPN’s domain back to from
  5. Either wait for DirSync to synchronize the changes or force a synchronization using the instructions given previously.

Moving the pilot users back to the production domain (

  • NOTE:  Due to a code defect Directory Sync will show an error.  Moving from a federated domain to a standard domain in this fashion will be supported in the future once this defect is fixed.
  1. Moving the user back to a standard (non-federated) domain in the cloud requires the use of the Microsoft Online Services Module for Windows PowerShell.  This is the same module that contains the federation tool cmdlets.  For each of your pilot users, move them to the domain by using the Set-MsolUserPrincipalName cmdlet.   For example:


  1. Once you can see the pilot user’s UPNs updated in the administration portal, reset all those pilot user’s cloud passwords (using the administration portal) and distribute the temporary passwords to the pilot users.
  • The pilot users will be forced to change their passwords the first time they login, after being moved back to the domain[1].

Federating the production domain (

  1. On the AD FS machine, open the Microsoft Online Services Module for Windows PowerShell (see Install and configure the Microsoft Online Services Module for Windows PowerShell for single sign-on for further information).  This time, after connecting to the service and AD FS, remove the federated test domain by using the Remove-MSOLFederatedDomain cmdlet.
  2. Inform all production users with Office 365 licenses/accounts in that single sign-on is going to be enabled for their Office 365 login accounts and when this is scheduled for.  Explain the changes in the login experiences to all end users once the domain is federated.
  3. Next federate the domain using the Convert-MSOLDomainToFederated cmdlet. 
    1. NOTE:  This conversion process can take up to 24 hours to complete.  Microsoft recommends that this operation is performed over a weekend.
    2. NOTE:  This conversion process will convert all the user’s cloud credentials into federated credentials – allowing them to use their corporate credentials to sign in to Office 365 services.  Staging of this conversion process is not currently possible with Office 365.


[1] 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.