When configuring a Microsoft Outlook profile for an Office 365 mailbox, authentication continuously fails for all users

Published: 06/29/2016

Issue Description:

The Issue described in this article applies to an environment where you've federated your Office 365 tenant with PingOne and ADConnect with IIS for SSO. 

When configuring a Microsoft Outlook profile for an Office 365 mailbox, authentication continuously fails for all users that attempt to create a mail profile.  The users will constantly get re-prompted for credentials. There will be no login failures reported in the ADConnect logs.

If you run the Microsoft connectivity Analyzer (https://testconnectivity.microsoft.com) it will report the following error:
 
The Microsoft Connectivity Analyzer is attempting to retrieve and analyze a security token for user user@company.com.
An error occurred while attempting to retrieve and analyze the security token.

>Test Steps
The Microsoft Connectivity Analyzer is attempting  to authenticate to the security token service at https://connect365.pingone.com/365/active/sign-in/<Unique Identifier>
An error occurred while attempting to retrieve the security token.
>Additional Details
No SAML token was found in the response from the Security Token service.

Cause: 

PingOne is unable to connect to your ADConnect with IIS endpoint, so the process does not get far enough for the user's credentials to be validated against Active Directory.
There are two main issues that could prevent a successful connection between PingOne and ADConnect with IIS 

1. The IIS Server URL for ADConnect with IIS is not externally accessible.

The IIS Server URL needs to be externally accessible (regardless of where the users are located), and route to your internal ADConnect with IIS Server. You can view/update your IIS Server URL by logging into https://admin.pingone.com, click setup and then click Identity Repository.

2. The certificate that is presented by IIS is not trusted by PingOne.

The Certificate that is presented by IIS needs to be issued from a trusted 3rd party Certificate Authority. IIS also needs to present the full certificate chain right up to the Root Certificate Authority. Otherwise, PingOne will not establish an SSL connection with ADConnect with IIS. 

  • For example, certificates that are issued by Godaddy's Go Daddy Root Certificate Authority -- G2 Certificate Authority will sometimes cause this error. Although it's a Root Certificate Authority, it's CA certificate was issued by Go Daddy Class 2 Certification Authority. This scenario can be hard to identify, because most browsers will detect that Go Daddy Root Certificate Authority -- G2 is a root certificate that can be verified, so everything looks correct when you're viewing the certificate chain from a web browser. 
  • You can verify that ADConnect with IIS is presenting the full certificate chain by using a tool such as Qualys SSO Labs (https://www.ssllabs.com/ssltest/analyze.html). If your certificate was issued by Go Daddy Root Certificate Authority -- G2, you will want to ensure that there is a Certification Path that includes Go Daddy Class 2 Certification Authority.
  • In order to ensure that the full certificate chain is presented, we recommend that the Certificate Provider's steps to install the certificate in IIS are followed exactly. Usually this process includes importing the certificate chain into the Local Computer's keystore before you install the certificate. This ensures that the chain is correct, and IIS will present the full chain.
After verifying the Certificate and chain, if you are still seeing this issue, please reach out to Ping Identity Support to further investigate the cause of the error.
    
Category:
ADConnect , 
KB or other URL: