RSA SecurID Access SAML Configuration for Microsoft Office 365 issue – “AADSTS50008: Unable to verify token signature. The signing key identifier does not match any valid registered keys”

There recently have been couple cases when the customers who has configured the Azure AD federation with RSA SecureID by following these instructions https://community.rsa.com/docs/DOC-1019 were randomly experiencing the error during users sign in: “AADSTS50008: Unable to verify token signature. The signing key identifier does not match any valid registered keys”.

The issue temporary goes away when the domain is converted to managed and back to federated.
Looking at the mentioned RSA instructions, noticed that the RSA recommends to set up Issuer Entity ID for the SAML response as “urn:uri:o365”.
Since multiple customers most likely are selecting the same Issuer ID (most likely by copying the example), the confusion takes place on Azure AD side what tenant the SAML response is intended to and the token signing certificate validation fails.
The recommended fix is to change the Issued Entity ID on RSA and AAD side to “urn:uri:your_domain” (ex: urn:uri:contoso) to make it unique.

AD FS Relying Party certificates errors troubleshooting (EventID 317)

Customer has configured the new Relying Party Trust by using the Relying Party Trust Wizard and importing the data from the file that was downloaded earlier on the management computer.

When testing the Relying Party sign-on, the application was returning the error

“An error SAML response status was received. urn:oasis:names:tc:SAML:2.0:status:Responder”

Per following article https://msdn.microsoft.com/en-us/library/hh269642.aspx this means “The request could not be performed due to an error on the part of the SAML responder or SAML authority.”

Looking at the AD FS event logs, located the following self-explanatory error corresponding to unsuccessful sign in attempt.

Log Name:      AD FS/Admin
Source:        AD FS
Date:          7/3/2018 9:55:33 AM
Event ID:      317
Task Category: None
Level:         Error
Keywords:      AD FS
User:          xxx
Computer:      XXX
Description:
An error occurred during an attempt to build the certificate chain for the relying party trust ‘microsoft:identityserver:XXX’ certificate identified by thumbprint ‘xxx’. Possible causes are that the certificate has been revoked, the certificate chain could not be verified as specified by the relying party trust’s encryption certificate revocation settings or certificate is not within its validity period.
You can use Windows PowerShell commands for AD FS to configure the revocation settings for the relying party encryption certificate.
Relying party trust’s encryption certificate revocation settings: CheckChainExcludeRoot
The following errors occurred while building the certificate chain: 
A certificate chain could not be built to a trusted root authority.
The revocation function was unable to check revocation for the certificate.
The revocation function was unable to check revocation because the revocation server was offline.
User Action:
Ensure that the relying party trust’s encryption certificate is valid and has not been revoked.
Ensure that AD FS can access the certificate revocation list if the revocation setting does not specify “none” or a “cache only” setting.
Verify your proxy server setting. For more information about how to verify your proxy server setting, see the AD FS Troubleshooting Guide (http://go.microsoft.com/fwlink/?LinkId=182180).

Per environment’s security requirements, the AD FS server had no Internet access, that is why the Certificate Revocation List checks for the Relying Party Encryption and Signing certificates were failing.

Please note, that this is not recommended to turn of the revocation checking, that is why you might review your firewall policy for external connections to the Internet for AD FS and WAP (https://social.technet.microsoft.com/wiki/contents/articles/964.certificate-revocation-list-crl-verification-an-application-choice.aspx)

While the security team was reviewing the option allowing outbound connections from ADFS to some public Certificate Authority CRL URLs, we have used following switches in the Set-ADFSRelyingPartyTrust PowerShell command, to disable Relying Party certificates CRL check by setting the values to None.

-EncryptionCertificateRevocationCheck and – SigninCertificateRevocationCheck

https://docs.microsoft.com/en-us/powershell/module/adfs/set-adfsrelyingpartytrust?view=win10-ps

Per this article these are the acceptable values:

–          None (this is default value)

–          CheckEndCert

–          CheckEndCertCacheOnly

–          CheckChain

–          CheckChainCacheOnly

–          CheckChainExcludingRoot

–          CheckChainExcludingRootCacheOnly

Federated applications (CRM and IIS) ADFS Single Sign-On (SSO) troubleshooting with Fiddler

Recently had very interesting issue to troubleshoot. This (long 😊 ) troubleshooting description for sure will help many to understand the ADFS Single Sign-On (SSO) flow and how to read the Fiddler traces.

Environment: ADFS 3.0, CRM 2013, IIS 8.5 running a site. Both the CRM and the IIS site are federated with the ADFS.

The CRM and the IIS site were accessed from outside of the corporate network, so only Form Based Authentication was taking place when redirected to the ADFS.

Problem: If the user accesses the IIS site first, completes authentication to the ADFS, then the user browses to the CRM site (using the same browser), the ADFS SSO takes place and user do not have to authenticate second time (put user name and password) via ADFS to access the CRM.

But if the user accesses the CRM first, completes authentication to the ADFS and then browses to the IIS site, the ADFS SSO doesn’t take place and the user is presented with the ADFS Form Based Authentication (FBA) page.

Another variable added to the puzzle was the fact that the CRM and the IIS belong to one Active Directory domain (lets call it EXTERNAL) and the ADFS belongs to other (call it PUBLIC). The two-way trust was configured between these domains. As troubleshooting continued, the issue was replicated if all three services (ADFS, CRM, IIS) were placed in the same AD, so the issue was NOT about on-premises AD location and which domain the services belonged to (more details explained below).

Troubleshooting: As always in such cases, the Fiddler trace was captured to get better understanding of browser redirections and sign in processes.

Here is a non-working SSO attempt (Note: in some screenshots I’m not able to show all the details (but will do my best to provide good description).

Frame #2 – user accesses the CRM and is redirected to the ADFS;

Frame #3-8 – user completes the ADFS FBA (providing correct username/password) and browser gets the ADFS SSO cookie – MSISAuth=AAEAAJo…;

Frame #9 – the ADFS redirects the browser with the ADFS SSO cookie to itself, where the ADFS SSO cookie is exchanged to the ADFS access token (MSISAuthenticated) that will be presented to the application as a proof that the user was authenticated;

Frame #10 – browser is redirected to the CRM Ws-Fed endpoint configured in the ADFS CRM Relying Party, where MSISAuthenticated cookie is exchanged to two application session cookies (MSISAuth=77uj… and MSISAuth=VWJ0…). These two cookies will always be presented to the CRM by browser as a proof that this is “authenticated” session;

Frame #13 – user opens a new tab in the browser and goes to the IIS site. The browser presents two CRM session cookies to the IIS site and obviously, the IIS site doesn’t recognize them and redirects the browser to the ADFS for authentication;

Frame #14 (were all fun begins) – The browser presents 3 cookies to the ADFS – the ADFS SSO cookie we got in Frame #8 + 2 CRM application cookies;

Looks like regardless correct ADFS SSO cookie presented (MSISAuth=AAEAAJo…), it was not accepted by the ADFS and the Form Based Authentication sign in page is returned. No errors in the ADFS Admin logs.

In the ADFS Debug logs see the following error:

Log Name:      AD FS Tracing/Debug
Source:        AD FS Tracing
Date:          2/6/2018 1:52:20 PM
Event ID:      67
Task Category: None
Level:         Error
Keywords:      ADFSProtocol
User:          S-1-5-21-1337953637-3591879799-2366245552-4020
Computer:      XXX
Description:
Ignore corrupted SSO cookie.

Have confirmed that this is expected ADFS 3.0 behavior to parse all cookies through its code pipe. Since the browser was presenting 2 cookies with the same name (MSISAuth – one set by the ADFS, other by the CRM) only the last one in the pipe was treated as the ADFS SSO cookie. But as we see from previous screenshot, the last cookie in the pipe was MSISAuth=77uj… and was set by CRM and for sure is not a valid ADFS SSO cookie.

When looking at the trace when we access the IIS site first and the CRM second, the issue with non-working SSO is NOT present, because the IIS site was setting cookies with the name of FedAuth and that cookie name is not causing the issue during the ADFS cookies evaluation.

Explained the above flow to the owner of the environment and said that the solution is to see if we can make sure the CRM is not using MSISAuth name for its session cookie.

After that, the owner of the environment added another variable to this puzzle ☹. He said he has other CRM and IIS site federated with the same ADFS 3.0 farm, but there the issue we are troubleshooting is NOT present there!

Captured new Fiddler trace for working scenario.

Following screenshot is for working sign in.

The authentication flow is the same – user accesses CRM (#2), browser redirected to the ADFS, successfully authenticates (#3-8), the CRM WS-Fed endpoint sets the session cookies with name MSISAuth (#9-10), user opens new tab to the IIS site (#12), site redirects to the ADFS (#13).

But looking at the Frame #13 we see that the browser is sending ADFS only one MSISAuth cookie (the ADFS SSO cookie) which ADFS accepts and issues MSISAuthenticated cookie to the IIS site (SSO takes place to IIS).

So now the question was – why in one scenario the browser presents 3 cookies (ADFS SSO + 2 app session cookies), in other only one ADFS SSO cookie.

You might have already noticed the difference in the scenarios. As mentioned at the beginning, it was NOT about the local AD and what Active Directory domains each of three services belong to.

The explanation was discovered in the Frame #10 where the CRM was setting the application cookies. Going to the Raw tab in the response window and viewing the frame in Notepad, gave the explanation.

The domain scope was set for the cookie by the CRM.

Since in non-working scenario, all three services (ADFS, CRM, IIS) are located in the same domain name space (domainA.com), the browser was presenting the CRM cookies as well to the ADFS when redirected from the IIS site.

In the second scenario the CRM was specifying domainB.com in the session cookies and because ADFS belong to domainA.com, the browser was not presenting the CRM cookies with the ADFS SSO cookie when it was redirected from the IIS to the ADFS for authentication.

To resolve the issue, it was decided to move production ADFS host name to different domain name space than CRM and IIS by the owner of the described environment.

So far was not able to confirm with the CRM team if its possible to change the name of the session cookies or make sure the domain name is not specified (though think the last is not a valid option at all).

AD FS Single Sign on is not working with Internet Explorer 11

Symptom: when accessing the federated application from inside of the corporate network using Internet Explorer, the users are presented with AD FS Forms Based authentication (FBA) page instead of Windows Integrated Authentication taking place. At the same time Edge and Chrome WIA are working as expected from intranet.

Since there was no Windows security pop up asking for user credentials and other browsers work, this was definitely not an issue related to Windows Authentication not being enabled in ADFS Primary Authentication Methods and not an issue when ADFS host name is missing from Local intranet security zone (https://technet.microsoft.com/en-us/library/jj203438.aspx) in Internet Explorer.

Have checked the list of supported WAI agents in the ADFS global properties by using this command:

Get-AdfsProperties |
Select WIASupportedUserAgents -ExpandProperty WIASupportedUserAgents

 The output was following. Can you find the missing agent string?

Correct, the “Trident/7.0” was missing.

Using the following command has resolved the issue:

Set-AdfsProperties -WIASupportedUserAgents ((Get-ADFSProperties |
Select -ExpandProperty WIASupportedUserAgents) + “Trident/7.0”)

You can read more about configuration of intranet form-based authentication for the devices that do not support WIA in this article – https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-intranet-forms-based-authentication-for-devices-that-do-not-support-wia