02-25-2021 06:28 AM
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
05-05-2021 07:40 AM
No fixed version and no workaround yet but:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvw59876
05-06-2021 01:58 AM
Hi,
I see that 10 people had this problem according to the OP "likes", as of now there is 32 support cases for CSCvW59876 (was actually 29 two days ago), so I guess this is still not fixed.
Please, anyone care to share some details - at least the SAML provider? We have this issue with Azure AD, but not for instance with DUO Access Gateway (FTD 6.7)...
Thanks
Kind regards
Ondrej K.
06-01-2021 09:00 AM
Has anyone had any success solving this problem?
06-25-2021 11:39 AM
FTD 6.7 with Azure same problem.
06-28-2021 12:51 AM - edited 06-28-2021 01:01 AM
Hi,
I had the same issue, and managed to solve it - It seems that Azure is sometimes presents the wrongs certificate under SAML config (I think this happens if you download certificate just after creating Enterprise Application) - the correct certificate should have a CN of "Microsoft Azure Federated SSO Certificate", and a start date of the day of creation of the Enterprise Application... So check your SAML certificate from Azure, re-download/import and try again
So I guess there is sometimes a little delay in the creation of SAML certificate on Azure side - and instead of throwing an error when trying to download certicate when this is not ready, they just give you some other certificate (not sure what that is)...
At least this was the issue in my case - got this confirmed by Cisco TAC as well, that they have seen this behaviour multiple times with Azure involved...
Hope this can help others struggling with same issue !
/Rasmus
06-28-2021 08:28 AM
Rasmus
That was the solution, grabbed the correct certificate and it has solved the issue. THANKS!!!
08-14-2021 11:31 PM
Hello, Checked the Azure Certificate and confirmed "Date and CN".
Unfortunately, the AnyConnect from FTD still facing the same error.
May I have more detail?
thanks!
09-29-2021 12:30 PM
I had the same problem today, moved a working Cisco anyconnect VPN to a different tenant and got this error. Yes the initial SAML certificate is a weird one and it doesn't work.
@ctohang99 , after I switched to the correct certificate, it also didn't immediately work. I had to change the connection profile -> SAML identity Provider to None, then change it back, then it worked, You can give it a try.
09-29-2021 01:06 PM
Do you have multiple profiles setup for your VPN? Mine only works for one profile, but I have 5 profiles setup. And Azure doesnt give unique entity IDs for each application so I am completely stuck.
09-29-2021 05:03 PM
I have two profiles, but one of them is LDAP. So you have 5 profiles in same ASA configured with same Azure AD? I would think it shouldn't be a problem. In each Azure application, you will configure different SP identifier :
https://vpn.yourasa.com/saml/sp/metadata/differentProfilename
And in each profile, you should choose the correct SAML certificate.
10-04-2021 07:15 AM
phil.jackson@ai-solutions.com did you get multiple profiles working ?
I guess maybe you didn't configure reply URL ( ACS URL) in Azure properly.
The help shows "Patterns: https://YOUR_CISCO_ANYCONNECT_FQDN/+CSCOE+/SAML/SP/ACS"
But it should be https://YOUR_CISCO_ANYCONNECT_FQDN/+CSCOE+/SAML/SP/ACS?tgname=TunnelGroupName , then you can have multiple tunnel groups.
09-23-2021 09:19 AM
Thank you!!! I have been racking my brain for months trying to figure this out.
09-24-2021 12:45 PM
I also had this problem and the directions in the Cisco documentation here (https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/215935-configure-asa-anyconnect-vpn-with-micros.html_) are part of the problem. Everything up to the downloading of the certificate is solid otherwise.
When you're setting this up, pay particular attention to the download certificate portion. The ASA generally likes things to be in .pem format when uploading certificate files but the default option to download the certificate from Azure is actually in Base64 format.
The step they left out in that documentation that would save you having to re-add the cert (Which means you're going to have to un-apply it from your VPN profile and also un-apply it from the SAML Idp, save, re-import, re-apply, test again) is if you just clicked on the "Edit" button on that section (SAML Signing Certificate) as you're stepping through the Azure configuration and it will give you the option to download the correctly formatted cert (.pem).
Hope this helps some others with the additional elaboration as to why that Base64 download does not work. Cisco, please update this documentation!!
09-27-2021 05:50 AM - edited 09-27-2021 05:50 AM
I tried this and still having issues. It might be how I have it setup. Does anyone have multiple profiles setup using this? Since, Azure only does one entity ID for everything, unlike Okta, which is a unique web link, I have to bunch everything up together. It seems that I can only get one profile to properly login, but everything else gets the cross scripting error. I am regretting moving away from Okta now LOL.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide