cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
16996
Views
60
Helpful
30
Replies

CSCvw59876 - ASA "Potential CSRF attack detected." when SAML assertion validation fails

aleksta9826435
Beginner
Beginner

Hi!

 

I have been encountered the following message "Potential CSRF attack detected". I've tried to reconfigure the SAML within the ASA, but It doesn't help. I'm using the AnyConnect software and everything seems to be working fine when I'm authenticating but It's like the last step it fails on which is frustrating. 


My ASA version is 9.15. Is there any workaround to fix this issue? 

 

Best regards
Aleksander Stanojevic

30 Replies 30

Hi,

 

Did you ever get this too work?

 

Regards

CiscoKiddy

I can only get it to work if I use one profile only. If I add in other links to separate out profiles, it doesn't work.

 

I resorted to working through setting up an NPS server and using the Azure MFA NPS extension to achieve my needs. I am still having a couple issues I am trying to figure out, but so far in testing it works.

For multiple connection profiles, you will need multiple unique Azure SAML apps (one for each connection profile), since each connection profile on the ASA has unique SP metadata.  The challenge here is that Azure, unlike every other cloud-based SAML IdP I have seen, gives you unique IdP certificates per-app but only gives you a single SAML IdP EntityID, which causes a problem since you can't tell the ASA "here is the entity ID, and here is a group of certificates which it might try to use please trust them all".

 

The solution for this is to create a certificate for ALL your AnyConnect SAML apps on Azure (just a standard SSL cert from any trusted public CA should be fine), bundle it as a PKCS12, upload it to Azure, then assign that certificate to every AnyConnect SAML app.  DigiCert for example lets you generate a CSR right on their portal, then you can sign it, download the cert, pvk and CA chain, and bundle it into a pkcs12 with OpenSSL with something like:

openssl pkcs12 -export -out newID_CERT.pfx -inkey privateKey.key -in id_cert.crt -certfile issuer_CA_chain.crt -name <subject:commonName> -passout pass:importPassphrase


Then, you will have the ability to have unique applications to support multiple tunnel-groups, but only need a single IdP and IdP trustpoint on the ASA.

MauryJ
Beginner
Beginner

I'm having the same issue with FTD 6.7.0.2 and Duo SSO.

 

Update:  We found via debug logs that the security assertation was timing out, after authenticating with Duo.   The resolution was to set our FTD to sync time with an authoritative internet time server.

FYI, it's Cisco's recommended best practice to synchronize the FTD to a NTP server. If you're running Firepower Management Center you can generally just set it there and tell the FTDs to use FMC as their source and all is right in the world. Speaking of NTP related issues, I have encountered a problem with clock drift and Duo authentications, not with a firewall, but with a Windows server that was running RADIUS/NPS. The RADIUS server happened to be about 1 minute off (it was the one server in the environment that wasn't set to use NTP, the client I was working had just built it for the purpose of project we were working on) from what the server Duo Auth Proxy was running on and it was causing the 2FA to fail. I ended up finding the answer in the Duo Auth Proxy logs saying time was out of sync (or something along those lines) so if you're not finding the answers in your other device logs, always check your Duo Auth Proxy logs if you're using that.

In our case FTD was already synced with FMC, and FMC was synced to an internal NTP server.   The internal NTP (Windows) server is synced to NIST.   So I'm still not certain why we had an issue with this in the first place.   I assume that somewhere, sync was not actually happening, even though the times appeared to be the same.  

 

Duo technical support could not determine the cause of the problem we were having with this, though I don't recall if they examined the proxy logs.  They did review the configurations in our proxy, FMC and for the service.   So they referred us to TAC, who ultimately figured out what was going on.

 

 

I'm having the same issue on FTD 7.0.1 and azure ad. My FTD's are synced with FMC for NTP.

Thinking of giving this a shot.

Was there any production impact on changing NTP on the FTD's? Is it something that should be done in a maintenance window?

Thanks

For us this was fully resolved by updating to 7.0.1.1+ (And FXOS update) also bear in mind my other comment you get the same error message if you are using client certificate authentication as a second factor that is using an unsupported cipher

Time is then correctly synced with the FMC which then sync's with the time source doing the upgrade will require a maintenance window

So I did 7.0.1 then applied the hot fix a couple of weeks back to get the saml integration. Is this not 7.0.1.1? Hope I don't have to go through this all again.

7.0.1 hotfix.PNG7.0.1.1.PNG

Guess not when looking at availability we actually went with 7.0.2 in the end, would like to eventually update to 7.2 for better support of TLSv1.3 and other features as gives a bit of grief

Hoping I can workaround the problem by pointing the FTDs out to external NTP rather than the FMC. I have a tac case open I'll see what they say too. Thanks for your help.

If it helps and you may be a different problem but our issue was not that the FTD did not fetch the time from the FMC but the FTD did not pass to other modules if that is the right word like the FXOS. If i was willing to guess each module is sandboxed and probably as simple as the NTP port was not exposed so we could go into that module and could see that it had time drift
Sorry if a bit vague but a while ago now and can just about remember having to change modules and seeing one time in one bit and another in the main FTD. Good luck TAC should eventually get you a solution

Deleted the app from azure and started again with different names for the certs and sso server in fmc. All started working after that. Give it a shot if anyone else gets stuck.

andydaws
Beginner
Beginner

We had the same problem on our 4100 Series FTD and Microsoft AD FS following best practice from Cisco all Devices are time synced to the same NTP servers and FTD via FMC.

 

Checking time using CLI shows time to be accurate but going into system support diagnostics-cli shows time to be 2 mins slow?

 

Cisco pointed me to a possible FXOS update but this made no difference to the problem and still adrift

 

Instead as a workaround we configured AD FS for a time Skew with Powershell using the parameter -NotBeforeSkew 5

 

In Powershell you can run Get-AdfsRelyingPartyTrust this will list all Trusts so you can identity the correct name then run Set-AdfsRelyingPartyTrust -TargetName xxxx -NotBeforeSkew 5 to set

 

This does not appear to work if trying to use User Certificates though as an additional MFA (Or Primary) I would add

 

Hopefully that might help someone though

The above work around worked for this environment but was determined to be a Cisco Bug that has since been resolved by updating to the latest FXOS and FTD Version 7.0.1.1. We also found that the exact same error message occurs if you are using User Certificate Authentication in SAML on Microsoft ADFS, but the Certificate is using Elliptical Curve (Which you would think you would want as more secure). Create with RSA and the problem goes away in this case it is MS ADFS that has the problem just the error message not that helpful makes you think same issue

 

Thought would add this so we have a list of possibilities that give the same error message and possible solutions

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: