After you, the administrator, have deployed Active Directory Federation Services (AD FS) 2.0, the next step to set up single sign-on is to download, install, and configure the Microsoft Online Services Module for Windows PowerShell. To do this, you must have the required software for the Microsoft Online Services Module. After you have downloaded and installed the module, you then run a series of cmdlets in the Windows PowerShell command-line interface to add or convert domains for single sign-on.
For more information about deploying AD FS 2.0, see Plan for and deploy Active Directory Federation Services 2.0 for use with single sign-on.
The following are required in order to run the Microsoft Online Services Module:
-
Operating system: Use Windows 7 or Windows Server 2008 R2.
-
Microsoft .NET Framework: You must turn on the Microsoft .NET Framework 3.51 feature in Windows 7 or Windows Server 2008 R2.
-
Windows PowerShell 2.0 and AD FS 2.0: In order to run the cmdlets to set up single sign-on, you must turn on the Windows PowerShell 2.0 feature, and you must have administrator privileges on the AD FS 2.0 server. We recommend that you use remote access to the AD FS 2.0 server when you run the cmdlets; to do this you must use Windows PowerShell remoting. For information, see About_Remote_Requirements.
-
All Office 365 software updates: From the Office 365 downloads page, install the required updates. To access the Office 365 downloads page, sign in to the Office 365 portal, and, under Resources, click Downloads. These updates are required because the features in Office 365 will not work properly without the appropriate versions of operating systems, browsers, and software. For more information, see Set up your desktop for Office 365.
The Microsoft Online Services Module for Windows PowerShell is a download that comes with Office 365. This module installs a set of cmdlets to Windows PowerShell; you run those cmdlets to set up single sign-on for Office 365. Before you set up single sign-on in your full production environment, you can also run a single sign-on pilot. See Run a pilot to test single sign-on before setting it up (optional).
 Note: |
|---|
|
Run a pilot to test single sign-on before setting it up (optional)
Before adding or converting a domain as a single sign-on domain, you may want to run a pilot. Performing a staged rollout of single sign-on is not currently possible; all users become federated at the same time. However, you can pilot single sign-on with a set of production users from your production Active Directory forest.
Pilot users should thoroughly test various sign-in scenarios to ensure that single sign-on (and the AD FS 2.0 deployment) is correctly configured and ready to be rolled out across the entire organization. To test this, have users access Office 365 services from browsers as well as rich client applications (such as Microsoft Office 2010) in the following environments:
-
From a domain-joined computer
-
From a non-domain-joined computer inside the corporate network
-
From a roaming domain-joined computer outside the corporate network
-
From the different operating systems that you use in your company
-
From a home computer
-
From an Internet kiosk (browser only)
-
From a smart phone (for example, a smart phone that uses Microsoft Exchange ActiveSync)
For more information, see How to pilot single sign-on in a production user forest.
Each domain that you want to federate must either be added as a single sign-on domain or converted to be a single sign-on domain from a standard domain. Adding or converting a domain sets up a trust between AD FS 2.0 and Office 365.
 Important: |
|---|
|
Add a domain
-
Open the Microsoft Online Services Module.
-
Run
$cred=Get-Credential. When the cmdlet prompts you for credentials, type your Office 365 administration account credentials. -
Run
Connect-MsolService -Credential $cred. This cmdlet connects you to Office 365. Creating a context that connects you to Office 365 is required before running any of the additional cmdlets installed by the tool. -
Run
Set-MsolAdfscontext -Computer <AD FS 2.0 primary server>, where <AD FS 2.0 primary server> is the internal FQDN name of the primary AD FS 2.0 server. This cmdlet creates a context that connects you to AD FS 2.0.Note: If you have installed the Microsoft Online Services Module on the primary AD FS 2.0 server, then you do not need to run this cmdlet. -
Run
New-MsolFederatedDomain -DomainName <domain>, where <domain> is the domain to be added and enabled for single sign-on. This cmdlet adds a new top-level domain or subdomain that will be configured for federated authentication.Note: Once you have used the New-MsolFederatedDomain cmdlet to add a top-level domain you will not be able to use the New-MsolDomain cmdlet to add standard domains (non-federated). -
Using the information provided by the results of the
New-MsolFederatedDomaincmdlet, contact your domain registrar to create the required DNS record. This verifies that you own the domain. Note that this may take up to 15 minutes to propagate, depending on your registrar. It can take up to 72 hours for changes to propagate through the system. For more information, see Locate my domain name registrar and Verify a domain at any domain name registrar. -
Run
New-MsolFederatedDomaina second time, specifying the same domain name to finalize the process.
Convert a domain
When you convert an existing domain to a single sign-on domain, every licensed user will become a federated user, using their existing Active Directory corporate credentials (user name and password) to access services in Office 365. Performing a staged rollout of single sign-on is not currently possible; however, you can pilot single sign-on with a set of production users from your production Active Directory forest. For more information, see Run a pilot to test single signon before setting it up (optional).
|
Note: |
|---|
| It’s best to perform a conversion when there are the fewest users, such as on a weekend, to reduce the impact on your users. |
To convert an existing domain to a single sign-on domain, follow these steps.
-
Open the Microsoft Online Services Module.
-
Run
$cred=Get-Credential. When the cmdlet prompts you for credentials, type your Office 365 administration account credentials. -
Run
Connect-MsolService -Credential $cred. This cmdlet connects you to Office 365. Creating a context that connects you to Office 365 is required before running any of the additional cmdlets installed by the tool. -
Run
Set-MsolAdfscontext -Computer <AD FS 2.0 primary server>, where <AD FS 2.0 primary server> is the internal FQDN name of the primary AD FS 2.0 server. This cmdlet creates a context that connects you to AD FS 2.0.Note: If you have installed the Microsoft Online Services Module on the primary AD FS 2.0 server, then you do not need to run this cmdlet. -
Run
Convert-MsolDomainToFederated -DomainName <domain>, where <domain> is the domain to be converted. This cmdlet changes the domain from standard authentication to single sign-on.
|
Note: |
|---|
To verify that the conversion has worked, compare the settings on the AD FS 2.0 server and on Office 365 by running Get-MsolFederationProperty -DomainName <domain>, where <domain> is the domain for which you want to view settings. If they don’t match, you can run Update-MsolFederatedDomain -DomainName <domain> to sync the settings.
|
Now that you have installed the module and configured the domains to use single sign-on, you must set up Active Directory synchronization. For more information, see Active Directory synchronization: Roadmap. After you have set up Active Directory synchronization, see Verify and manage single sign-on.
