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?
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.
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.
For us this was fully resolved by updating to 220.127.116.11+ (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
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
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 18.104.22.168. 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