Applies to: Live@edu Upgrade to Office 365

In Microsoft Office 365, single sign-on is implemented differently than in Microsoft Live@edu. In Office 365, single sign-on uses identity federation rather than the Live@edu SSO Toolkit.

  • You must apply an update to the SSO Toolkit in order to maintain single sign-on access to Outlook Web App for your users during and after the upgrade to Office 365.
  • The SSO Toolkit will only be supported on Office 365 until December 31, 2014, so you must move to federation before then.

There are two ways to implement federation:

  • Active Directory Federation Services (AD FS) 2.0
  • Shibboleth Identity Provider (IDP) with SAML 2.0   

Important: When you are ready to set up identify federation in Office 365, follow the process in this topic, rather than the general Office 365 instructions. The order of installing the tools is different, because your upgraded domain already has users.

In this article

Update the SSO Toolkit to maintain single sign-on access Implement federation

Update the SSO Toolkit to maintain single sign-on access

An update to the Live@edu SSO Toolkit is available as an interim single sign-on solution in Office 365. The updated SSO Toolkit will be supported until December 31, 2014. At that point, you need to implement federation to continue having single sign-on functionality.

Important: The SSO Toolkit will stop working during the upgrade to Office 365 if you have not updated to version 4.5. Apply the update before the upgrade to prevent any interruption in single sign-on to Outlook Web App for your users during and after the upgrade, and to provide single sign-on access to Office 365 services.

The following table summarizes the user sign-in experience after updating the SSO Toolkit. Note that even after updating the SSO Toolkit, SSO access is not available after the upgrade for:

  • Personal Microsoft accounts. After the upgrade, these accounts are no longer managed by your institution. Users need to use their Microsoft account user name and password.
  • Desktop clients and email clients on smart phones and other devices. Users will still need to provide their Office 365 user name and password.
  • Lync client. If you subscribe to an Office 365 academic plan after the upgrade, users will need to provide their Office 365 user name and password to use the Lync client.
Sign-in experience Before upgrade During upgrade**  After upgrade
SSO access available
  • Outlook Web App
  • Microsoft services like SkyDrive
  •  Outlook Web App
  • Outlook Web App
  • Admin pages for Office 365, Exchange Online, SharePoint Online*, Lync Online*
  • SharePoint Online*
User name and password required
  • Email clients on smart phones and other devices
  • Desktop applications like Outlook and Thunderbird
  • Microsoft services like SkyDrive
  • Email clients on smart phones and other devices
  • Desktop applications like Outlook and Thunderbird
  • Microsoft services like SkyDrive
  • Email clients on smart phones and other devices
  • Desktop applications like Outlook and Thunderbird
  • Lync client*

* SharePoint Online and Lync Online are available with plan A2 or higher.

** The changes take place at the Assign license step. During the upgrade, you can check which step of the upgrade you're on by going to the Live@edu Service Management Portal.

Before the upgrade

1. Update the SSO Toolkit

To update your on-premises SSO Toolkit installation, complete the following steps:
  1. Download the Live@edu SSO Toolkit 4.5 Update for the Office 365 Upgrade package.
  2. Back up your current solution.
  3. Follow the steps in the "How to update Live@edu SSO Toolkit to 4.5" document included in the downloaded package to update the SSO Toolkit and verify single sign-on access.

2. Tell users how to access their personal Microsoft account in advance

During the upgrade, each Live@edu account becomes two separate accounts. Because the upgrade changes the Microsoft accounts to be personal accounts rather than associated with your educational institution, you can no longer provide single sign-on access to SkyDrive and you can no longer set passwords for your users’ Microsoft accounts.

If you have not given your users their Live@edu password, provide your users with the following instructions:

  1. Before the upgrade, add an alternate email address to your Live@edu account by following the instructions in Why do I need to add security info?
  2. During the upgrade, sign in to a Microsoft site such as https://skydrive.live.com/.
    1. On the sign-in page, click Can't access your account?
    2. Follow the directions on the Reset your password page.
If a user needs to reset their Microsoft account password during the upgrade and they don’t have an alternate email address set, they need to go to https://account.live.com/acsr  to request a password reset.

After the upgrade

1. Prevent password lockout

Unlike in Live@edu, Office 365 has a default password expiration policy of 90 days and requires newly created users to reset their password on first sign-in by default.

  • If you have not given your users their Live@edu password, upgraded users will not be able to access Outlook Web App or other Office 365 services when prompted to reset their password 90 days after the upgrade.
  • Depending on how you plan to create users in Office 365, new users will not be able to access Outlook Web App or other Office 365 services when prompted to reset their password upon first sign-in or 90 days after being created.

Important In order to prevent your users from not being able to access Office 365 services, we recommend using Windows Azure Active Directory PowerShell for the following scenarios:

    Users upgraded from Live@edu

    For users upgraded from Live@edu, configure their passwords to never expire by using the Windows Azure Active Directory Set-MsolUser cmdlet.

  • This action must be run for each user.
  • For more information, see Configure user passwords to never expire.
  • Example: To set passwords to never expire for all users in a specific domain, run the following cmdlet:
    Get-MsolUser -DomainName fineartschool.net -All | Set-MsolUser -PasswordNeverExpires $true

    Reset a user password

    To reset a user password, use the Windows Azure Active Directory Set-MsolUserPassword cmdlet.

  • You can prevent a user from being prompted to change their password on first sign-in by specifying the -ForceChangePassword parameter.
  • This option is useful for institutions that set passwords for users to access their email via smart phones and desktop applications.
  • Example:
    Set-MsolUserPassword –UserPrincipleName dina@fineartschool.net -NewPassword "P@ssw0rd!" -ForceChangePassword $false

    Create a new user in Office 365

    To create a new user in Office 365, use the Windows Azure Active Directory New-MsolUser cmdlet.

  • You can prevent a user from being prompted to change their password on first sign-in and prevent their password from expiring by specifying the -ForceChangePassword and -PasswordNeverExpires parameters, respectively.
  • If you create a new user using the Admin page of Office 365, Exchange Control Panel, or the Exchange Online cmdlets, you can reset their password and configure their password to never expire after creating them.
  • Example:
    New-MsolUser -UserPrincipalName rowena@fineartschool.net –DisplayName “Rowena Berry” –FirstName “Rowena” –LastName “Berry” –UsageLocation “US” -LicenseAssignment “FineArtSchool:EXCHANGESTANDARD_STUDENT” –Password “P@ssw0rd!” –ForceChangePassword $false –PasswordNeverExpires $true

For information about differences between using Windows PowerShell in Live@edu and Office 365, see Windows PowerShell.

2. Implement federation

The SSO Toolkit will only be supported on Office 365 until December 31, 2014, so you must implement federation before then.

There are two ways to implement federation:

Implement federation

Whether you plan to start using federation immediately after upgrading from Live@edu or to implement it later, we recommend that you first build and test federation with a trial Office 365 domain. After testing federation with a trial domain, you can quickly switch federation over to your production domain.

If you want to switch to federation immediately, there are tasks you need to do prior to and after the upgrade from Live@edu to Office 365. If you have updated the SSO Toolkit, then all the federation set-up steps can be done after the upgrade to Office 365.

Set up AD FS 2.0 federation for Office 365

Before starting:

Before the upgrade

Run the Deployment Readiness Tool.
  1. Run the Deployment Readiness Tool.
Build and test AD FS 2.0 and the Windows Azure Active Directory Sync tool on an Office 365 trial tenant.
  1. Create your trial Office 365 tenant.
    1. Go to Plans and pricing for Office 365 for education, and click FREE 30-DAY TRIAL. This gives you a 30-day trial tenant.
      • Note that this trial domain can't be merged with your production domain.

      • The Office 365 trial includes the Office 365 service upgrade that your institution will receive after your upgrade from Live@edu. This difference does not matter with respect to testing identity federation. For more information about the Office 365 service upgrade, see the Upgrade FAQs.

    2. Add a test domain that is not a subdomain of your production tenant to the Office 365 trial tenant.
    3. Create test users in your on-premises Active Directory.
    4. Using the Admin page of Office 365 or Windows PowerShell, create new users in Office 365 with the same user principal names as the ones you created on-premises in the previous step, and assign Exchange Online licenses to each user. To learn how to create users, see Create or edit users or Create a mail user with Windows PowerShell.
    5. Sign in to the test mailboxes to verify they are functional.
  2. Set up AD FS 2.0.
    1. Complete all steps in Plan for and deploy AD FS 2.0 for use with single sign-on.
    2. Complete the steps in Install Windows PowerShell for single sign-on.
      • Follow the instructions to “Convert the domain” when setting up a trust between AD FS 2.0 and Office 365.
    3. Verify that you can sign in using federation when you sign in on-premises and to Office 365.
  3. (Optional) Install and set up the Directory Sync tool.
    Important:
    • The Directory Sync tool cannot be installed on the same server as OLSync, Identity Lifecycle Manager (ILM) 2007, or Forefront Identity Manager (FIM) 2010.
    • If you install the Directory Sync tool to use with a test domain, you will need to uninstall and reinstall after the upgrade in order to use it with your production domain.
    1. Follow the instructions in Configure directory synchronization.
    2. Synchronize your test domain.
  4. (Optional) Create a new user in Active Directory, synchronize, and verify that the user can sign in to Office 365 using federation.

After the upgrade

Prepare your on-premises and cloud directories for directory synchronization.
  1. Activate Directory synchronization for your upgraded production domain in Office 365.
    • This process takes 24 hours to complete, but you can continue with the steps prior to "Install and run the Directory Sync tool" while waiting.
  2. If you are using OLSync or OLMA, disable them from synchronizing.
    1. Sign in to the Live@edu Service Management Portal by using your Live@edu user name and password.
    2. Click Disable OLMA.
    3. If using the same server for the Directory Sync tool, uninstall OLSync and all components of Identity Lifecyle Manager (ILM) 2007 or Forefront Identity Manager (FIM) 2010. Note that a 64-bit server is required for the Windows Azure Active Directory Sync tool.
  3. Download the Cloud Directory Preparation scripts.
    • These scripts can be run from any domain-joined computer with Windows PowerShell installed.
  4. Open a Windows PowerShell command prompt and navigate to the folder containing the scripts.
  5. In order to allow the scripts to execute, run the Windows PowerShell command:
    Set-ExecutionPolicy Unrestricted.
  6. For each top-level organizational unit, run the read-only mode script, ReadMode.ps1, in Windows PowerShell:
    .\ReadMode.ps1 -OutputFileName <path to file> -Office365AdminUserName <user name> -LDAP <"LDAP path">
    • For usage and troubleshooting information, see ReadMode.ps1 usage.
    • View the output .csv file, and determine if it is ready to use with the RemediationMode.ps1 script:
      • If no errors are found, the .csv file will have four columns: Primary SMTP address, Scenario, ADObjectGUID, and CloudObjectGUID.
        • If the file has these four columns, but no data, no remediation is needed. Proceed directly to the steps for "Switch federation from your trial domain to your production domain."
        • If the file has the four columns and rows with data, continue to step 7 to remediate the issues listed in the file.
      • If there are any errors, follow the troubleshooting instructions to troubleshoot any problems, and then run ReadMode.ps1 again.
  7. For each top-level organizational unit, run the remediation script, RemediationMode.ps1 in Windows PowerShell, using the .csv file created in the previous step:
    .\RemediationMode.ps1 -InputFileName <path to file> -Office365AdminUserName <user name>
    • For usage information, see RemediationMode.ps1 usage.
    • If the script stops executing due to errors, follow the troubleshooting instructions, and then run RemediationMode.ps1 again.
    • After successfully running the RemediationMode.ps1 script, wait 20  minutes, and then run the RemediationMode.ps1 script again to resolve any replication collisions created by the first run of the script.
Switch federation from your trial domain to your production domain.
  1. Before you enable federation, create an administrator account in your upgraded production Office 365 domain.
    • You can use this account to sign in to your production domain in Office 365 to administer your institution if there is a problem with the federated sign in flow.
  2. After creating a new administrator account, enable AD FS 2.0 on your production tenant.
  3. Verify that you can sign in using federation to your on-premises system and to Office 365.
Update your school portal
  1. Change any links to email on your website to go directly to https://portal.microsoftonline.com/.
    • Because you federated, this will send your users to your AD FS 2.0 identity servers to sign in.
  2. If your institution was using the SSO Toolkit, update your school portal to stop using it.
Install and run the Directory Sync tool.
  1. If you already installed the Directory Sync tool for use with your test domain, uninstall it.
  2. Install the Directory Sync tool.
  3. Synchronize your directories using the Directory Sync tool.
  4. Create a new user in Active Directory, synchronize, and verify that the user can sign in to Office 365 using federation.

Set up Shibboleth federation for Office 365

Federation using the Shibboleth Identity Provider (IDP) is supported for Active Directory with the following clients. Note that it does not support the Lync 2010 desktop client.
  • Web-based clients such as Outlook Web App and SharePoint Online.
  • Email-rich clients that use basic authentication and a supported Exchange access method such as IMAP, POP, Active Sync, or MAPI:
    • Microsoft Outlook 2007
    • Microsoft Outlook 2009
    • Thunderbird 8 and 9
    • iPhone (iOS 4, ioS 5)
    • Windows Phone 7
For step-by-step instructions on implementing federation using Shibboleth, see Use Shibboleth Identity Provider to implement single sign-on.

Before the upgrade

Run the Deployment Readiness Tool.
  1. Run the Deployment Readiness Tool.

Build and test Shibboleth on an Office 365 trial tenant.
  1. Create your trial Office 365 trial tenant.
    1. Go to Plans and pricing for Office 365 for education, and click FREE 30-DAY TRIAL. This gives you a 30-day trial tenant.
      • Note that this trial domain can't be merged with your production domain.

      • The Office 365 trial includes the Office 365 service upgrade that your institution will receive after your upgrade from Live@edu. This difference does not matter with respect to testing identity federation. For more information about the Office 365 service upgrade, see the Upgrade FAQs.

    2. Add a test domain that is not a subdomain of your production tenant to the Office 365 trial tenant.
    3. Create test users in your on-premises Active Directory.
    4. Using the Admin page of Office 365 or Windows PowerShell, create new users in Office 365 with the same user principal names as the ones you created on-premises in the previous step, and assign Exchange Online licenses to each user. To learn how to create users, see Create or edit users or Create a mail user with Windows PowerShell.
    5. Sign in to the test mailboxes to verify they are functional.
  2. Set up Shibboleth following the directions in Use Shibboleth Identity Provider to implement single sign-on.
  3. (Optional) Install and set up the Directory Sync tool.
    Important:
    • The Directory Sync tool cannot be installed on the same server as OLSync, Identity Lifecycle Manager (ILM) 2007, or Forefront Identity Manager (FIM) 2010.
    • If you install the Directory Sync tool to use with a test domain, you will need to uninstall and reinstall after the upgrade in order to use it with your production domain.
    1. Follow the instructions in Configure directory synchronization.
    2. Synchronize your test domain.
  4. (Optional) Create a new user in Active Directory, synchronize, and verify that the user can sign in to Office 365 using federation.

After the upgrade

Prepare your on-premises and cloud directories for directory synchronization.
  1. Activate Directory synchronization for your upgraded production domain in Office 365.
    • This process takes 24 hours to complete, but you can continue with the steps prior to "Install and run the Directory Sync tool" while waiting.
  2. If you are using OLSync or OLMA, disable them from synchronizing.
    1. Sign in to the Live@edu Service Management Portal by using your Live@edu user name and password.
    2. Click Disable OLMA.
    3. If using the same server for the Directory Sync tool, uninstall OLSync and all components of Identity Lifecyle Manager (ILM) 2007 or Forefront Identity Manager (FIM) 2010. Note that a 64-bit server is required for the Windows Azure Active Directory Sync tool.
    • These scripts can be run from any domain-joined computer with Windows PowerShell installed.
  4. Open a Windows PowerShell command prompt and navigate to the folder containing the scripts.
  5. In order to allow the scripts to execute, run the Windows PowerShell command:
    Set-ExecutionPolicy Unrestricted.
  6. For each top-level organizational unit, run the read-only mode script, ReadMode.ps1, in Windows PowerShell:
    .\ReadMode.ps1 -OutputFileName <path to file> -Office365AdminUserName <user name> -LDAP <"LDAP path">
    • For usage and troubleshooting information, see ReadMode.ps1 usage.
    • View the output .csv file, and determine if it is ready to use with the RemediationMode.ps1 script:
      • If no errors are found, the .csv file will have four columns: Primary SMTP address, Scenario, ADObjectGUID, and CloudObjectGUID.
        • If the file has these four columns, but no data, no remediation is needed. Proceed directly to the steps for "Switch federation from your trial domain to your production domain."
        • If the file has the four columns and rows with data, continue to step 7 to remediate the issues listed in the file.
      • If there are any errors, follow the troubleshooting instructions.
  7. For each top-level organizational unit, run the remediation script, RemediationMode.ps1 in Windows PowerShell, using the .csv file created in the previous step:
    .\RemediationMode.ps1 -InputFileName <path to file> -Office365AdminUserName <user name>
    • For usage information, see RemediationMode.ps1 usage.
    • If the script stops executing due to errors, follow the troubleshooting instructions, and then run RemediationMode.ps1 again.
    • After successfully running the RemediationMode.ps1 script, wait 20  minutes, and then run the RemediationMode.ps1 script again to resolve any replication collisions created by the first run of the script.
Switch federation from your trial domain to your production domain.
  1. Before you enable federation, create an administrator account in your upgraded production Office 365 domain.
    • You can use this account to sign in to your production domain in Office 365 to administer your institution if there is a problem with the federated sign in flow.
  2. After creating a new administrator account, enable Shibboleth on your production tenant.
  3. Verify that you can sign in using federation to your on-premises system and to Office 365.
Update your school portal
  1. Change any links to email on your website to go directly to https://portal.microsoftonline.com/.
    • Because you federated, this will send your users to your Shibboleth identity servers to sign in.
  2. If your institution was using the SSO Toolkit, update your school portal to stop using it.
Install and run the Directory Sync tool.
  1. If you already installed the Directory Sync tool for use with your trial domain, uninstall it.
  2. Install the Directory Sync tool.
  3. Synchronize your directories using the Directory Sync tool.
  4. Create a new user in Active Directory, synchronize, and verify that the user can sign in to Office 365 using federation.