AD FS Not Authenticating SAML Requests

Question

This morning, it was brought to our attention that Active Directory Federation Services has stopped performing SAML authentications for all SAML-based relying party trusts (about 8 of them). Office 365 logins going through the same ADFS server (server 2012 R2) are not experiencing an issue. No updates, reboots, or configuration changes were performed over the weekend, and SAML was happily authenticating as recent as 48 hours ago.

One of the relying party trusts, a DokuWiki system, spits out the following error: "ADFS: Signature validation failed. SAML Response rejected"

A 3rd party system (SAML authenticated) gives the error: "ADFS signature validation failed, please contact your system administrator."

Because I'm getting the same error from two different systems attempting to authenticate via SAML at this ADFS server, I'm ruling out the systems and narrowing my vision to the ADFS server.

In the ADFS Admin Log via Event viewer, the only new event to appear is:

The SAML artifact resolution endpoint is not configured or it is disabled. 

The artifact resolution service is not started. 

User Action 
If the artifact resolution service is required, use the AD FS Management snap-in to configure or enable the SAML artifact resolution endpoint.

Which seems relevant... but I'm not seeing anything about artifact resolution in the ADFS console or via powershell. Additionally, I'm not finding a lot of others on the internet with the same issue, which always makes me consider I'm tracking a red herring.

Edit to add Certificate Rollover details from Get-ADFSProperties:

AutoCertificateRollover                    : True
CertificateCriticalThreshold               : 2
CertificateDuration                        : 365
CertificateGenerationThreshold             : 20
CertificatePromotionThreshold              : 5
CertificateRolloverInterval                : 720

Get-AdfsCertificate shows:

Certificate     : [Subject]
                    CN=*.ourdomain.edu, O=Our Org, L=Eugene, S=Oregon, C=US

                  [Issuer]
                    CN=DigiCert SHA2 High Assurance Server CA, OU=www.digicert.com, O=DigiCert Inc, C=US

                  [Serial Number]
                    (SerialNumber1)

                  [Not Before]
                    6/9/2019 5:00:00 PM

                  [Not After]
                    9/8/2020 5:00:00 AM

                  [Thumbprint]
                    (Thumprint goes here)

CertificateType : Service-Communications
IsPrimary       : True
StoreLocation   : LocalMachine
StoreName       : My
Thumbprint      : (Thumprint goes here)

Certificate     : [Subject]
                    CN=ADFS Encryption - fs.our-org.edu

                  [Issuer]
                    CN=ADFS Encryption - fs.our-org.edu

                  [Serial Number]
                    (SerialNumber1)

                  [Not Before]
                    2/4/2020 2:13:25 AM

                  [Not After]
                    2/3/2021 2:13:25 AM

                  [Thumbprint]
                    (Thumprint goes here)

CertificateType : Token-Decrypting
IsPrimary       : True
StoreLocation   : CurrentUser
StoreName       : My
Thumbprint      : (Thumprint goes here)

Certificate     : [Subject]
                    CN=ADFS Signing - fs.our-org.edu

                  [Issuer]
                    CN=ADFS Signing - fs.our-org.edu

                  [Serial Number]
                    (SerialNumber1)

                  [Not Before]
                    2/4/2020 2:13:27 AM

                  [Not After]
                    2/3/2021 2:13:27 AM

                  [Thumbprint]
                    (Thumprint goes here)

CertificateType : Token-Signing
IsPrimary       : True
StoreLocation   : CurrentUser
StoreName       : My
Thumbprint      : (Thumprint goes here)

Certificate     : [Subject]
                    CN=ADFS Encryption - fs.our-org.edu

                  [Issuer]
                    CN=ADFS Encryption - fs.our-org.edu

                  [Serial Number]
                    (SerialNumber1)

                  [Not Before]
                    2/23/2019 8:52:39 PM

                  [Not After]
                    2/23/2020 8:52:39 PM

                  [Thumbprint]
                    (Thumprint goes here)

CertificateType : Token-Decrypting
IsPrimary       : False
StoreLocation   : CurrentUser
StoreName       : My
Thumbprint      : (Thumprint goes here)

Certificate     : [Subject]
                    CN=ADFS Signing - fs.our-org.edu

                  [Issuer]
                    CN=ADFS Signing - fs.our-org.edu

                  [Serial Number]
                    (SerialNumber1)

                  [Not Before]
                    2/23/2019 8:52:40 PM

                  [Not After]
                    2/23/2020 8:52:40 PM

                  [Thumbprint]
                    (Thumprint goes here)

CertificateType : Token-Signing
IsPrimary       : False
StoreLocation   : CurrentUser
StoreName       : My
Thumbprint      : (Thumprint goes here)

Where would you go with this? I'm happy to dig up any details or post output/logs as needed.

Thank you!

Solution

I doubt if this is an artefact resolution problem.

I wonder if this is related to the fact that the ADFS certificates have rolled and the new certificates need to be distributed to the RP.

O365 will not be affected because that uses OpenID Connect.

Comments

[Lex]

I am thinking along the line of certificate as well. It sound like it's something centralized on the ADFS causing all the failures. Has some sort of automatic rollover happened. I would test out the certificate to ensure it's valid

[SteadH]

@Lex are you thinking service, token decrypting, or token signing certificates? We do auto roll certificates, but Get-AdfsCertificates gives some dates in the past.

[SteadH]

AutoCertificateRollover : True CertificateCriticalThreshold : 2 CertificateDuration : 365 CertificateGenerationThreshold : 20 CertificatePromotionThreshold : 5 CertificateRolloverInterval : 720

[rbrayb]

Signing certificate - use the ADFS wizard - look under certificates.

[SteadH]

@nzpcmad it does appear that the token signing cert rolled last week (feb 3), but we didn't experience an issue until 2/10.

[SteadH]

@nzpcmad Interestingly enough, opening the primary cert for token signing, it says CA Root not trusted (it's self signed). I hit install a few times, but it did not resolve. Then, I hit install and chose trusted root store... and it doesn't show the red x anymore... will test.

[SteadH]

@nzpcmad Signing & Decrypting certs are now trusted, but the error persists.

[rbrayb]

Yes but you need to send the certificate to all the RP so they can install on their side. Easiest way is to send the ADFS metadata.

[SteadH]

Thanks @nzpcmad - it looks like the cert had to be added to the RP and we're good to go! I'm still confused as to what/when/why the cert changed prior to it's expiration, but glad we're back up and running. Thank you for the help!

[rbrayb]

docs.microsoft.com/en-us/windows-server/identity/ad-fs/…

[Lex]

Sorry.. I am late to the party. We had a similar issue where some some RP are not updating the cert from the metadata. It's best to check the metadata and ensure all new certs are there. Glad it's resolved at this point