If you are unsure about approaching this issue please call our helpdesk as you can irreversibly damage your PC if you are not careful
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 Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, or Windows Server 2012 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 server.
- If you plan to use Shibboleth Identity Provider as your STS, you will need to install and prepare an operational Shibboleth Identity Provider.
Microsoft supports this single sign-on experience as the integration of a Microsoft cloud service, such as Windows 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 http://go.microsoft.com/fwlink/?LinkID=256497.
- Based on the type of STS you will set up, use the Windows Azure Active Directory Module for Windows PowerShell to establish a federated trust between your on-premises STS and Windows 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.
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.
|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 Windows Azure Active Directory Module for Windows PowerShell.