Prepare for single sign-on
Updated: June 25, 2015
Applies To: Azure, Office 365, Power BI, Windows Intune
Note
This topic might not be completely applicable to users of Microsoft Azure in China. For more information about Azure service in China, see windowsazure.cn.
In order to prepare for single sign on, complete the following steps:
Step 1: Review the requirements for single sign-on
Step 2: Prepare Active Directory
Step 1: Review the requirements for single sign-on
In order to implement this SSO solution, you must meet the following requirements:
Have Active Directory deployed and running in either Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2 with a functional level of mixed or native mode.
If you plan to use AD FS as your STS, you will need to do one of the following:
Download, install and deploy AD FS 2.0 on a Windows Server 2008 or Windows Server 2008 R2 server. Also, if users will be connecting from outside your company’s network, you must deploy an AD FS 2.0 proxy.
Install the AD FS role service on a Windows Server 2012 or Windows Server 2012 R2 server.
If you plan to use Shibboleth Identity Provider as your STS, you will need to install and prepare an operational Shibboleth Identity Provider.
Important
Microsoft supports this single sign-on experience as the integration of a Microsoft cloud service, such as Microsoft Intune or Office 365, with the already installed and operational Shibboleth Identity Provider. Shibboleth Identity Provider is a third-party product and therefore Microsoft does not provide support for the deployment, configuration, troubleshooting, best practices, etc. issues and questions regarding the Shibboleth Identity Provider. For more information about the Shibboleth Identity Provider, see https://go.microsoft.com/fwlink/?LinkID=256497.
Based on the type of STS you will set up, use the Microsoft Azure Active Directory Module for Windows PowerShell to establish a federated trust between your on-premises STS and Azure AD.
Install the required updates for your Microsoft cloud service subscriptions to ensure that your users are running the latest updates of either Windows 7, Windows Vista, or Windows XP. Some features may not work properly without the appropriate versions of operating systems, browsers, and software. For more information, see Appendix A: Review software requirements.
Step 2: Prepare Active Directory
Active Directory must have certain settings configured in order to work properly with single sign-on. In particular, the user principal name (UPN), also known as a user logon name, must be set up in a specific way for each user.
Note
To prepare your Active Directory environment for single sign-on, we recommend that you run the Microsoft Deployment Readiness Tool. This tool inspects your Active Directory environment and provides a report that includes information about whether or not you are ready to set up single sign-on. If not, it lists the changes you need to make to prepare for single sign-on. For example, it inspects whether or not your users have UPNs and if those UPNs are in the correct format.
Depending on each of your domains, you may need to do the following:
The UPN must be set and known by the user.
The UPN domain suffix must be under the domain that you choose to set up for single sign-on.
The domain you choose to federate must be registered as a public domain with a domain registrar or within your own public DNS servers.
To create UPNs, follow the instructions in the Active Directory topic Add User Principal Name Suffixes. Keep in mind that UPNs that are used for single sign-on can only contain letters, numbers, periods, dashes, and underscores.
If your Active Directory domain name is not a public Internet domain (for example, it ends with a “.local” suffix), you must set a UPN to have a domain suffix that is under a Internet domain name that can be registered publically. We recommend that you use something familiar to your users, such as their email domain.
If you have already set up Active Directory synchronization, the user’s UPN may not match the user’s on-premises UPN defined in Active Directory. To fix this, rename the user’s UPN using the Set-MsolUserPrincipalName cmdlet in the Microsoft Azure Active Directory Module for Windows PowerShell.