ADFS returns NoAuthnContext due to RequestedAuthnContext Comparison="exact" in SAML request

asked on May 8 • Show version history

I’m running into an issue where Laserfiche insists that the user’s username/password be exactly specified in the SAML request. Here’s the relevant snippet from the request:

<samlp:RequestedAuthnContext Comparison="exact">
  <saml:AuthnContextClassRef>
    urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
  </saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>

Because ADFS isn’t prompting for credentials, it rejects the authentication with a NoAuthnContext status:

<samlp:Status>
  <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder">
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext"/>
  </samlp:StatusCode>
</samlp:Status>

The strict Comparison "exact" seems to be preventing ADFS from satisfying the request. My thought is that if Laserfiche could relax this to something like Comparison "minimum", ADFS would accept the default authentication context and pass credentials.

Has anyone encountered this? How can I adjust either the ADFS or Laserfiche configuration so that ADFS will pass the user credentials (or otherwise satisfy the requested authn context) without returning NoAuthnContext? Any pointers or configuration examples would be greatly appreciated!

0 0

replied on May 8

I am by no means a SAML expert and this doesn't directly address your request but in your SAML configuration in LFDS have you tried changing your Authentication Context value to "urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified" to see if there is any difference in user experience?

0 0

View 3 previous replies

replied on May 8

Hi Shawn,

I noticed this option is available for Azure AD in the support guide, but I didn’t see the same option when the identity provider is set to ActiveDirectory with AD FS authentication enabled.

Thanks,

0 0

SELECTED ANSWER

replied on May 8 • Show version history

It's not available in the "native" AD FS option.

However, you can set up AD FS as a separate SAML identity provider in Directory Server and then associate it with the AD IDP as a Linked Provider. This is an entirely valid configuration and what you have to do if you're using AD FS to provide auth for multiple AD IDPs. I wrote a guide on the general setup, which you can find here:

Laserfiche Directory Server (LFDS) SAML Authentication with Microsoft Entra ID - Laserfiche Answers

You'll of course need to configure the claims and such in AD FS rather than Entra. Hopefully it's not too hard difficult to translate the IDP-side steps to AD FS.

0 0

replied on May 9

Hi Samuel,

If we followed the steps outlined in the AD FS Authentication with LFDS white paper for configuring a relying party trust in the AD FS management console, would any additional configuration be required on the IDP side, or should I be good to proceed with the LFDS steps as outlined?

Additionally, if I set up AD FS as a linked identity provider, I assume I should disable AD FS authentication on our existing Active Directory IDP in LFDS—can you confirm?

Thanks,

adfs-authentication-with-lfds.pdf (502.25 KB)

| Download

0 0

replied on May 9

You need to make one change on the IDP side beyond what you've already done from the white paper.

Change the source LDAP attribute for "Name ID" from SAM-Account-Name to User-Principal-Name. This will mean you're sending the UPN as both "Name ID" and "UPN". That's okay.

On the Directory Server side, you need to make sure all the Claims mappings are correct and match up with what's in the AD FS tokens. The Groups claim mapping is especially critical - without it working, Laserfiche will not see the AD group membership of AD users. This is a useful 3rd party tool I use to inspect SAML responses: https://www.samltool.com/online_tools.php

You don't need to have claim mappings for Display Name, Department, etc. for authentication to work. If you're using AD Group Sync to provision the AD users, those values should get automatically updated on the backend during group sync runs.

When you set up the Linked Provider, use the AD SID as the Matching Attribute type. If you followed the AD FS whitepaper, the name of that claim is "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/sid".

Screenshot of relevant AD FS whitepaper IDP claims instruction page:

0 0

replied on May 13

Hi Samuel,

I followed your guide and was able to successfully configure SSO—thank you! However, for the authentication context, I had to use the Kerberos class to avoid the NoAuthnContext issue:

urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos

I'm not sure if Laserfiche is aware, but based on a conversation with one of our more tenured staff members, it seems AD FS was attempting to pass credentials using Windows Integrated Security. So, I changed the authentication context value from unspecified to Kerberos, and that resolved the issue.

We also found that the certificate needed to be installed in the Intermediate Certification Authorities store—not just in the Trusted Root Certification Authorities.

I really appreciate your help in pointing me in the right direction!

Thanks again,
Jarrett Eason

1 0

replied on May 13

Glad to hear it!

I'm surprised AuthnContext unspecified didn't work. In the SAML specification, that's essentially the value for "I don't care and will accept anything". A working configuration is a working configuration though, so if it's happy with Kerberos there's no issue.

With respect to:

We also found that the certificate needed to be installed in the Intermediate Certification Authorities store—not just in the Trusted Root Certification Authorities.

The Directory Server instance must be able to validate the entire certificate chain. Whereas Entra generates a self-signed signing certificate (that thus only has a root and no intermediates), I'm guessing your AD FS deployment uses a signing certificate issued by a public or private certificate authority that has one or more intermediate certificates in the chain. Installing the cert in the Intermediate Certification Authorities store likely put the intermediate in the right place so full chain validation could succeed.

Cheers,
Sam

0 0

Question

Question

ADFS returns NoAuthnContext due to RequestedAuthnContext Comparison="exact" in SAML request

Answer

Replies

Sign in to reply to this post.