Anyconnect Azure AD SAML SSO Issue

[Garry Cross]

I am creating the post to help others solve a problem that we encountered on the subject.

We had a working SAML configuration using Azure as the IDP. There is a large mixture of documentation on the subject.

A few guides I found useful are as follows.

https://www.wiresandwi.fi/blog/asa-vpn-saml-authentication-some-tips-and-tricks

https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/215935-configure-asa-anyconnect-vpn-with-micros.html

https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/cisco-anyconnect

We used the Microsoft one and we were successful in getting it up a running. It ran for awhile, maybe 1 month or more when all of a sudden it would fail with this message on the AC client.

Authentication failed due to problem retrieving the single sign-on cookie.

We had changed nothing on our side. We messed around for days, reading various tips about how some folks managed to resolve it.

We learned that to implement any change one must remove and add the saml idp statement from the tunnel group webvpn-attributes section. This is a known Cisco bug that is deemed to be a feature request rather than a bug.

In the end after doing debug webvpn saml 255 multiple times I realized the clue was right here in this message.

Jun 20 15:15:37 [SAML] consume_assertion: assertion is expired or not valid

Our ntp config is good, we even changed to use time.window.com but this did not change a thing.

Looking at the debug output in more detail we have this. It is tagged onto the end of another debug and easy to miss.

Jun 20 15:23:13 [SAML] NotBefore:2023-06-20T19:18:12.888Z NotOnOrAfter:2023-06-20T20:23:12.888Z timeout: 300

Note the timestamp of the log entry. Note the GMT time in the message of NotBefore. It is 5:01 min prior to the actual time. With a timeout of 300 sec configured on the ASA the assertion was expired as far as the ASA was concerned.

The change to fix the issue, I believe recommended somewhere, is to have no timeout or in my case I changed it to 600 just to test. Somehow I had timeout assertion 300. Seems that Azure purposely sets their clock 5 min behind.

webvpn
 saml idp https://sts.window.net/xxxx/
 timeout assertion 600 
tunnel-group xxxxSSO webvpn-attributes
 no saml identity-provider https://sts.window.net/xxxx/
 saml identity-provider https://sts.window.net/xxxx/

Optional use "no timeout assertion"

Hope this helps.

Regards.

[Cisco_Virtual_Engineer]

Thank you for sharing your experience. Your solution to increase the timeout assertion to 600 seconds seems to have worked in this case due to Azure's clock setting.

For others encountering a similar issue, it is essential to note that the timeout assertion parameter specifies the amount of time that the ASA will wait for a SAML assertion from the Identity Provider (IdP) after the user has been authenticated. If the ASA does not receive the SAML assertion within the specified timeout period, the authentication will fail.

This issue arises when there is a time discrepancy between the ASA and the IdP, in this case, Azure AD. The ASA expects the assertion to be valid at the time of receipt, but due to Azure's clock setting, the assertion is deemed expired by the ASA.

Here are the steps to resolve this issue:

1. Check your NTP configuration to ensure that your ASA and Azure AD are synchronized.
2. If the issue persists, increase the timeout assertion in your SAML IdP configuration on the ASA. This can be done using the command: `webvpn saml idp (IDP-URL) timeout assertion (timeout-value)`.
3. Lastly, remove the SAML IdP from your VPN tunnel group, then add it back. This is necessary due to a known issue with Cisco ASA where changes to the SAML IdP configuration are not applied until the IdP is removed and re-added.

Remember, it's essential to debug and understand the root cause of the authentication failure before making changes to your configuration. And always make a backup of your configuration before making changes.