FTD 6.7.0-65 Anyconnect Integration with Azure SAML
ฝัง
- เผยแพร่เมื่อ 26 ส.ค. 2024
- This demo video (~20 mins) goes through what's required to setup FMC/FTD 6.7.0-65 Anyconnect integration with Azure SAML. You must have a Microsoft Azure account to do the integration.
![[UNCUT] The Loyal Pin ปิ่นภักดิ์ EP.4 (4/4)](http://i.ytimg.com/vi/d3l5rxl5CVo/mqdefault.jpg)
Finding documentation to support SAML via ASA's running FTD is seriously difficult - thank you so much for putting this together! Great help!
You're very welcome!
IF YOU GET THE ERROR "POTENTIAL CSRF ATTACK DETECTED" TRY THIS. At 6:55 in the video, the Request Timeout is set to 300. I had to increase my setting to 600 and everything worked (the error went away). Not sure why it worked because the error was almost immediate (definitely under 5 minutes) but changing it to 600 and it works so I'm a happy camper! Thanks for the video.
Thanks for the input, John. I have found that if you remove the timeout value, that may work too.
Had the same issue and changing it to 600 did the trick! Thanks for sharing!
I cannot thank you enough, I was going to have to compile multiple different white pages to do this stuff taking hours OR you could just hold my hand through it in 20 minutes... Very much appreciated :D
Very good video, this information/method is not documented well elsewhere. Thank you sir!
Excellent illustration Jerry, Thanks ✨⭐
Helped me set this thing up 🙂
You can also run the following commands on the CLi to troubleshoot
debug webvpn saml 255
debug webvpn 255
debug webvpn session 255
debug webvpn request 255
!
I just realised I posted on your other video too. 🙂
Thanks, very helpful video
Also if this helps someone, I too got the "POTENTIAL CSRF ATTACK DETECTED" error. On the "Single Sign On Server" configuration I had missed the field for the Base URL so it replaced my FTD URL SAML string with the IP address of the Outside Interface. Once corrected this error went away because the certificate now matched the URL.
Really great video! Well explained, very helpful. Sorry a question, why to trust the internal CA Win2016-RootCA? Should we also then a client certificate (given out by Win2016-RootCA) on the laptop (the Any connect side)
Hi, I used the Win2016-CA in my lab for demonstration purposes. Yes, my test client imported the public cert of the Win2016 CA so it will trust it. In a production environment, you can either use a publicly signed certificate from the CA of your choice or you can continue to use your Win2016-CA.
I'm getting this error"authentication failed due to problem retrieving the single sign-on cookie", Please help.
I used this video to build out my MFA connection and it worked great up until the point where I got stuck on the 'POTENTIAL CSRF ATTACK DETECTED' error. In my case (which took more than a month to figure out) I had a typo in the Identity Provider Entity ID field. Yes a typo that I managed to overlook consistently. At the very end of the field, I was missing a single '/' and that was enough to keep it from working.
Thank you for the input, Simen! Very useful to share!
Do you know if this is possible using Firepower Device Manager? Just tried it in the lab, but just getting 'ERROR: SAML IDP certificate failed' when I attempt to deploy.
Hi Darren, sorry for the late response. Was out of the office for a few days. SAML should be supported in FDM. Did you download the certificate from your IDP?
@Nick Johnson Yes, TAC gave us guidance to set up our own CA. Give me a few mins, I will post it here -- we've got this working on a few systems now.
@Nick Johnson
FromTAC:
"After checking internally and testing this in a lab, there is a possible workaround for this case. Since the “no ca-check” command is not available, what you can do is create your own CA certificate (and key) on an external tool, for example XCA or OpenSSL that contains this flag.
I am going to show you the example with XCA, so you can replicate it if you want this functionality. First, you open XCA and create a Database. After that, you create a new certificate and you put the template on the bottom as “CA Template”. You fill the second Tab of subject with the information you want, like country, region, CN, etc. On the bottom you generate a private key as well.
Then in the third tab “Extensions”, in X509 Basic Constraints > Type you choose “Certification Authority”. In the Subject Alternative Name you checkbox the option “copy DNS name” as well.
After that, you click OK and it will save your certificate + private key on the database. Just for being sure that it is correct, if you open the certificate just created, you should be seeing in the tab “Extensions” the extension “CA: TRUE”. This will mean that it is correctly created. After this, you select the certificate from the database menu, and on the right part you click on “Export” and Choose the format .p12 and issue a new password for exporting. You click then “Export” again and format .pem, to just export the certificate. We will be importing to the FDM device just the certificate (.pem) and to Azure portal the .p12 with public and private key.
For importing to Azure, you have to go to your enterprise application for AnyConnect > Single Sign-On and go to “SAML Signing Certificate > Edit”. Then, you click on “Import certificate” and import the .p12 with public and private key (Choose the option of “All Files” instead of .pfx and you’ll be able to upload the .p12). After importing, you’ll see two certificates, one Active and one Inactive. The Inactive should be the one you just imported, so you have to click on the three dots on the right and “Make this certificate Active” for using the certificate.
After the IdP is configured, on FDM side is the same as you were configuring first time, but on the IdP certificate part, you’ll have to paste the .pem that we exported previously from XCA."
Super helpful video and allowed me to get Saml working on one of our FTD devices. Can I ask about configuring Saml VPN on both sets of HA devices and allow for load balancing across both. Idealy we want users to connect (as with current radius config) based on location. FYI we just upgrade to 7.1 so I believe this is now possible
Hi Paul, SAML authentication is currently not available for Anyconnect VPN Load-balancing. You will need to switch back to Radius authentication. This is a roadmap item.
We have 2 FTD as a VPN Gateway in active-standby setup with different FQDN. In such scenario which FQDN to put as a base URL (considering high availability setup)?
Hello there. For FTD/ASA HA setup, always use the primary FQDN because the backup unit will assume the primary FQDN when the primary unit fails.
Good Stuff Mate! really easy to follow! If I may ask, how did you set it up in ISE now that your Authentication in FMC/FTD is now through SAML? I don't think you used AZURE_AD under the policy set for the authentication condition since you already pointed your FMC/FTD to point it to AZURE_AD? Keep up the good work mate!!!
Hi Vher, Authentication is done via Azure SAML and ISE can be added for Authorization if you want to enable ISE Posture services. I have another video posted that shows ASA SAML + ISE authorization setup.
@@chrisandjer Hi Can you share the URL for ASA SAML + ISE Auth
Thank you for making this video, very easy to follow. Is this same setup flow when using OKTA or a physical on premise SAML server and not Azure?
Yes, FTD setup is identical for Okta or other SAML providers. Thanks for watching!
I am attempting this using IBM verify as my IDP but when doing the deployment it errors out with “certificate failed”
Hi, I am not familiar with IBM verify as an IDP and I don't believe we(Cisco) ever tested it. But, the SAML integration process should be the same. Did you download the IBM IDP's certificate so that FTD would trust it?
What settings do you put on the Azure side of the anyconnect app?
Towards the end of the video(~15 mins), I have a segment on the XML settings that you need to get from FTD CLI and copy that into the Azure side. It's the "show saml metadata "
@@chrisandjer Thanks. I am not sure where I'm going wrong, but I get all the way through the authentication, then it says the link is dead.
@@chrisandjer So, it looks like I got it working for both Azure and Okta, but the FTD gives the error "Potential CSRF attack detected" and doesn't let me login. Further along than I was before
Philip, I know about the Potential CSRF attack detected error. It's a bug on the FMC side and Cisco working on fixing this. As a workaround, 1. Remove the SAML SSO Server from your Connection Profile. This will remove the SAML IDP reference. Just temporarily change it to Radius or something and Deploy. 2. Make any tiny changes in your Connection Profile. Change a description, whatever.... just a minor change. 3. Reassign the SAML SSO server and make sure the SSO Timeout Setting is blank. Deploy.
Let me know if this fixes it.
@@ciscolivesecurityfan1136 I eventually got it working for Okta and Azure. However, we are trying to move from Okta to Azure, and the issue popped up again on the Azure side. Been trying everything, and Cisco doesn't even seem to know what's wrong