Detailed implementation guidance for single sign-on (SSO) is available in the Office 365 Help documentation. If you encounter a problem when you implement SSO by using that guidance, you can refer to this article. It provides a roadmap to help troubleshoot common problems with each implementation step.
Use the Microsoft Office 365 Deployment Readiness Tool to scan Active Directory for issues that might cause directory synchronization issues.
Note Only user accounts that have user principal name (UPN) suffixes that match the domain that is federated for single sign-on (SSO) can take advantage of SSO features.
For more information about the Office 365 Deployment Readiness Tool, go to the following Microsoft website:
The Deployment Readiness Tool report provides inline links to Microsoft Online Deployment Guide troubleshooting guidance for the particular problems that are detected. To troubleshoot, follow these steps:
Use Deployment Readiness Tool inline links to Microsoft Online Deployment Guide guidance to resolve problems that the tool detects.
Note Incorrect preparation of Active Directory or failure to resolve issues that the tool identifies can result in directory synchronization problems in step 4. Follow the troubleshooting guidance that is offered by the Deployment Readiness Tool to correct the problems, and make sure that the Deployment Readiness Tool runs without any errors. This prevents the following problems from occurring later in the implementation:
To validate Windows Azure Active Directory Module for Windows PowerShell for SSO, follow these steps:
Run the Windows Azure Active Directory Module for Windows PowerShell as an admin.
Type the following commands, and make sure that you press Enter after you type each command:
$cred=Get-Credential
Note When you're prompted, type your Office 365 admin credentials.
Connect-MsolService -Credential $cred
Note This command connects you to Office 365. You must create a context that connects you to Office 365 before you run any of the additional cmdlets that are installed by the Windows Azure Active Directory Module for Windows PowerShell.
If you installed the Windows Azure Active Directory Module for Windows PowerShell on the primary Active Directory Federation Services (AD FS) 2.0 server, you don't have to run this cmdlet.
In this command, the placeholder <AD FS 2.0 primary server> represents the internal fully qualified domain name (FQDN) of the primary AD FS 2.0 server. This command creates a context that connects you to AD FS 2.0.
Note In this command, the placeholder <federated domain name> represents the domain name that was federated in the implementation steps.
Compare the first half (Source: AD FS Server) and last half (Source: Microsoft Office 365) of the output of the Get-MSOLFederationProperty command that you ran in step 2D to make sure that all entries match. If they don't match, use the "Resolution" section of the following Microsoft Knowledge Base article to update the Rely Party Trust data:
"Your organization could not sign you in to this service" error and "80041317" or "80043431" error code when a federated user tries to sign in to Office 365
Troubleshoot issues with validation for step 3
To troubleshoot, follow these steps:
Troubleshoot common validation problems by using the following Microsoft Knowledge Base articles, as appropriate for your situation:
An administrator cannot add a domain to an Office 365 account
Error when you run the New-MsolFederatedDomain cmdlet for the second time because domain verification fails. For more information about this scenario, see the following Knowledge Base article:
Error when you try to configure a second federated domain in Office 365: "Federation service identifier specified in the AD FS 2.0 server is already in use."
Time issues cause issues with the New-MSOLFederatedDomain cmdlet or the Convert-MSOLDomainToFederated cmdlet. For more information about this scenario, see the following Knowledge Base article:
Run the Windows Azure Active Directory Module for Windows PowerShell as an admin.
Type the following commands. Make sure that you press Enter after you type each command.
$cred=Get-Credential
Note When you're prompted, type your Office 365 admin credentials.
Connect-MsolService -Credential $cred
Note This command connects you to Office 365. You must create a context that connects you to Office 365 before you run any of the additional cmdlets that are installed by the Windows Azure Active Directory Module for Windows PowerShell.
Get-MSOLCompanyInformation
Check the LastDirSyncTime value from the output of the previous commands, and make sure that it shows a synchronization after the Windows Azure Active Directory Sync Tool was installed.
Note The date and time stamp for this value is displayed in Coordinated Universal Time (Greenwich Mean Time).
If LastDirSyncTime isn't updated, monitor the Application log of the server on which the Windows Azure Active Directory Sync Tool is installed for the following event:
Source: Directory Synchronization
Event ID: 4
Level: Information
This event indicates that directory synchronization finished on the server. When this happens, rerun these steps to make sure that the LastDirSyncTime value was updated appropriately.
Troubleshoot problems with validation for step 4
Troubleshoot common validation problems by using the following Microsoft Knowledge Base articles, as appropriate for your situation:
Error when you run the Windows Azure Active Directory Sync Tool in Office 365: "Your version of the Windows Azure Active Directory Sync Configuration Wizard is outdated"
Error when you try to run the Windows Azure Active Directory Sync Tool Configuration Wizard: "Your credentials could not be authenticated. Retype your credentials and try again"
"LogonUser() Failed with error code: 1789" after you enter enterprise administrator credentials in the Directory Sync Tool Configuration Wizard in Office 365
"An unknown error occurred with the Microsoft Online Services Sign-in Assistant" error when you run the Windows Azure Active Directory Sync Tool Configuration Wizard
Run Office 365 Desktop Setup on all client computers that use rich client applications. Rich client applications include Microsoft Outlook, Microsoft Lync 2010, Microsoft Office Professional Plus, Office 365 PowerShell management snap-ins, Office desktop applications, and Microsoft SharePoint integration applications.
If a seamless, no-prompt experience is expected for domain-joined and domain-connected client computers, add the AD FS 2.0 Federation Service URL to the local intranet zone in Windows Internet Explorer. For example, do the following:
In Internet Explorer, on the Tools menu, click Internet Options.
Click the Security tab, click Local intranet, click Sites, and then click Advanced.
Type https://sts.contoso.com in the Add this website to the zone box, and then click Add.
Note "sts.contoso.com" represents the FQDN of the AD FS 2.0 Federation Service.
For more information about this configuration, see the following Microsoft Knowledge Base article:
A federated user is prompted unexpectedly to enter their credentials when they access an Office 365 resource
If domain-joined and domain-connected client computers access Internet resources by using a proxy server that resolves Internet addresses by using public DNS queries (and not internal, split-brain DNS), add the AD FS 2.0 Federation Service URL to the list for which Internet Explorer will bypass proxy filtering. The following is an example of how to add the URL to the Internet Explorer exceptions list:
In Internet Explorer, on the Tools menu, click Internet Options.
On the Connections tab, click LAN settings, and then click Advanced.
In the Exceptions box, enter the value by using the fully qualified DNS name of the AD FS 2.0 service endpoint name. For example, enter sts.contoso.com.
Validation for step 5
To validate, follow these steps:
Make sure that Microsoft Online Services Sign-in Assistant service is installed and running. To do this, follow these steps:
Click Start, click Run, type Services.msc, and then click OK.
Locate the Microsoft Online Services Sign-in Assistant entry, and then make sure that the service is running.
If the service isn't running, right-click the entry, and then select Start.
Go to the AD FS 2.0 MEX website to make sure that the endpoint is part of the Internet Explorer intranet security zone. To do this, follow these steps:
Start Internet Explorer, and then go to the AD FS 2.0 service endpoint website. The following is an example of a service endpoint website:
Check the status bar at the bottom of the window to make sure that the security zone that is indicated for this URL is Local intranet.
Step 6: Final validation
On a configured client computer, test the expected SSO authentication experience. To do this, authenticate by using an SSO-enabled user. You may want to test authentication of an SSO-enabled user in the following scenarios:
In the on-premises network and authenticated to the on-premises Active Directory
From an Internet-neutral IP location and not authenticated to the on-premises Active Directory
To validate, follow these steps:
Run the Microsoft Online Services Diagnostics and Logging (MOSDAL) Support Toolkit to test validating enterprise SSO by using the following article in the Microsoft Knowledge Base:
as a federated user by using local Active Directory credentials.
Sign in to Outlook Web App as a federated user (by using local Active Directory credentials) who has an Exchange Online mailbox. For example, sign in to Outlook Web App at the following URL:
https://outlook.com/owa/contoso.com
Note In this URL, "contoso.com" represents the federated domain name.
Sign in to Microsoft SharePoint Online as a federated user (by using local Active Directory credentials) who has access to the Team Site collection. For example, sign in to SharePoint Online at the following URL:
http://contoso.sharepoint.com
Note In this URL, "contoso" represents the Office 365 tenant account name.
Test rich client or active requestor authentication. To do this, follow these steps:
Configure a Lync Online client profile for a federated user account, and then sign in to the account by using local Active Directory credentials.
Sign in to Windows Azure Active Directory Module for Windows PowerShell by using a federated user account that has global admin credentials through the connect-MSOLService cmdlet.
Test Exchange Online basic authentication by using Microsoft Remote Connectivity Analyzer. For more information about how to use Remote Connectivity Analyzer, see the following article:
Back to the top
