SAML Redundancy for Cisco ASA

[latenaite2011]

Hi Everyone,

I have customer who  has an ASA in Active/Standby mode and have SAML Single-Sign-On configured.  The SAML SSO works fine but during failover, it gave and error "Authentication failed due to problem retrieving the single sign-on cookie.  I did further research and the issue seems to be related to Bug CSCvi23605- Re-enable SAML to make config changes take effect.  We had to reload the standby for it to work.

Just wondering if there is a permanent fix for this and when it is expected to be release.

thanks!

[Marvin Rhoads · Accepted solution]

The BugID inidicates it's fixed in ASA 9.16(1).

[latenaite2011]

Hi Marvin,

Unfortunately, the bug is still not resolved.  Upgraded to 9.16(1) and did a failover test and tried to sign on to Azure SSO while the standby ASA (Firepower 2130 running in ASA mode only) was acting as primary, I get "Potential CSR attack detected", see attached.

Do you know what might be causing this?

We have an failover license but the new model I believe only requires one license on the primary as it is a shared licensing (i.e., a secondary license is not required on the standby).  

Also, is there anything required for licensing to be activated on the standby ASA? Show license status shows Smart Licensing is enabled.

Thank you!

LN

[Marvin Rhoads]

Licensing should not cause an issue here.

While trying the AnyConnect client logon, run "debug webvpn saml 255" and capture the output. That should show some more useful details about what's failing.

[latenaite2011]

Ok thanks Marvin.  Is there a way for me to test this while it is running in Standby mode?  I am trying to avoid another maintenance mode if possible.

[Marvin Rhoads]

You can't login to VPN on the unit while it is in Standby unit. Only the Active unit can handle that task.

[latenaite2011]

Hi Marvin,

I was able to capture the "debug webvpn saml 255" while the standby ASA is active.  

Below is what I see during the Anyconnect attempts:

%ASA-3-716162: Failed to consume SAML assertion. reason: assertion is expired or not valid.

SAML] consume_assertion:

PHNhbWxwOlJlc3BvbnNlIElEPSJfYmIxZDNlMmUtNmFmNS00MTBhLThiM2QtYzg4MDZkNDU3YzQ1IiBWZXJzaW9uPSIyLjAiIElzc3VlSW5zdGFudD0iMjAyMS0wOS0xN1QwMjo0NToyNi4zNzRaIiBEZXN0aW5hdGlvbj0iaHR0cHM6Ly9hc2EucGFyYy5jb20vK0NTQ09FKy9zYW1sL3NwL2Fjcz90Z25hbWU9QXp1cmVTU08iIEluUmVzcG9uc2VUbz0iX0Q5RjZFNzMxNzM1QzE1RkRDQzMxMjIyRUE2NkIxQzZCIiB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIj48SXNzdWVyIHhtbG5zPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIj5odHRwczovL3N0cy53aW5kb3dzLm5ldC83MzNkNjkwMy1jOWYxLTRhMGYtYjA1Yi1kNzVlZGRiNTJkMGQvPC9Jc3N1ZXI+PHNhbWxwOlN0YXR1cz48c2FtbHA6U3RhdHVzQ29kZSBWYWx1ZT0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnN0YXR1czpTdWNjZXNzIi8+PC9zYW1scDpTdGF0dXM+PEFzc2VydGlvbiBJRD0iX2Y3OThjMWI3LWZkOGYtNDczYy04NTJiLWEwOTkx.....

 [SAML] consume_assertion: assertion is expired or not valid

[SAML] consume_assertion

I found this URL here that mentions about time not synced:

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

[SAML] consume_assertion: assertion is expired or not valid

Problem 1. ASA time not synced with IdP’s time.

Solution 1. Configure ASA with the same NTP server used by IdP.

Problem 2. The assertion is not valid between the specified time.

Solution 2. Modify the timeout value configured on the ASA.

Not sure about this since it works on the primary ASA and the second ASA has the same configuration as the primary so why would this happen only on the secondary ASA (didn't check the time during the maintenance window and I am analyzing the debug now and just found this solution recommendation).

Thanks!

[latenaite2011]

Hey Marvin,

Just wondering if you have any suggestions to the debug captured on the standby ASA.  

Thank you in advance.

LN

[Marvin Rhoads]

You should be able to verify the time (clock and ntp status) on the secondary unit even while it's in standby role. Even if you cannot log into it directly, you can run the commands from the active unit:

failover exec standby show clock
failover exec standby show ntp assoc

[latenaite2011]

Hey Marvin,

Thanks for the reply.

I checked the clock and there is only a difference of 3 minutes from the
primary to the secondary ASA and the ntp association is very similar.

I don't think the 3 minutes difference should matter.

Let me know if there is any other suggestions?

thanks!

[Marvin Rhoads · Accepted solution]

3 minutes would indeed matter. SAML assertions are only valid from the time issued until 30 seconds after issuance. If the standby ASA clock is off by 3 minutes (either plus or minus) it won't see the assertion as valid.

If it is indeed ntp-synchronized then the clock should be accurate within subsecond accuracy.

[latenaite2011]

Thank you Marvin for the response!  I appreciate it!

[latenaite2011]

Thanks Marvin for your help.  It was a time issue that was off that caused the standby ASA to not work for the SAML SSO for the VPN cleints.