Cisco AnyConnect with Azure Single Sign-On failing with problem retrieving SSO cookie

[Michael Fox]

I am having a problem with my configuration of AnyConnect authentication using Azure Single Sign-On. This configuration was done following the "Configure a SAML 2.0 Identity Provider (IdP)" & "Example SAML 2.0 and Onelogin" sections of the following Cisco CLI Book 3 document:

https://www.cisco.com/c/en/us/td/docs/security/asa/asa96/configuration/vpn/asa-96-vpn-config/webvpn-configure-users.html

 When connecting I am getting the message "Authentication failed due to problem retrieving the single sign-on cookie." and within the ASDM logs I am getting "Failed to consume SAML assertion. reason: The profile cannot verify a signature on the message."

So far I have double checked my certificates, URL's and edited the request signature with no change.

Any suggestions would be greatly appreciated.

[Michael Fox · Accepted solution]

After sending Cisco all the debug logs, DART logs, metadata XML files (from SSO) they cam back to me with the following solution.

I’ve done research regarding SAML configuration on ASA and found that changes on SAML configuration do not take effect immediately, it is described in this bug:

CSCvi23605 (https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvi23605/?reffering_site=dumpcr) - Re-enable SAML to make config changes take effect.

SAML on ASA is using lasso library. If we need to make changes take effect and refresh the memory, we can only either re-enable or reboot to destroy the old SAML IdP in memory and create a new one. This is the limitation of the lasso library. So yes, it is kind of cached and this is limitations of used library.

Regarding the tunnel-group. I found only a bug where you can use only one certificate for the same SAML IDP config on the ASA:

CSCvi29084 Creating multiple SAML trustpoints in IDP config (https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvi29084/?reffering_site=dumpcr)

In this situation I suspect that some configuration (like signature algorithm or the certificate) was not applied properly due to this defect. In this situation I propose the following:

Re-enable SAML Auth in tunnel group:

ciscoasa(config-tunnel-webvpn)# no saml identity-provider https://...

ciscoasa(config-tunnel-webvpn)# saml identity-provider https://...

Hope this helps anyone else looking for the solution to this.

[Aqueduct Support]

Wanted to add one additional piece to this, if you require multiple TG's and, as such, multiple Azure apps, you can import your own certificate which may be used across multiple apps for SAML in Azure.

https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/cisco-anyconnect

[vikasgupta2k]

Hi,

We are not able to figure out the multiple tunnel-groups with IDP's certificate as we can only specify one trustpoint under webvpn IDP section. Has someone done it before?

Thanks

[Marvin Rhoads]

Only one is currently supported.

The way to get multiple tunnel-groups using SAML is to have an Authorization server send an attribute to change the user's tunnel-group. For now, the SAML iDP cannot also act as an Authorization server (although I hear that is a feature on the roadmap) so you need to use something like ACS or ISE as the Authorization server.

[lionel valero]

You may try to create a self signed certificate on Azure side and import it to each Cisco anyconnect application, so that you are using the same cert (for exemple only) :

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout MyPrivKey.key -out MyCert.crt
openssl pkcs12 -inkey MyPrivKey.key -in MyCert.crt -export -out Azure_SAML_for_Cisco_Anyconnect.pfx

[mark.jacobson]

One other cause of this error is that the connection group is case sensitive.  So the any connect metadata URL that you enter into the idP configuration should reflect the right case.

Example:

If the connection group is named CONNECTION-GROUP

then the metadata URL you enter into Azure idP should be

https://<VPN URL>/saml/sp/metadata/CONNECTION-GROUP

If you enter  https://<VPN URL>/saml/sp/metadata/connection-group instead, it will also yield the "Authentication failed due to problem retrieving the single sign-on cookie."

[Andreas Foerby]

Hi. 
I'm having the same issue, and have tried the proposed fix, with no luck. 

 When connecting I am getting the message "Authentication failed due to problem retrieving the single sign-on cookie." and within the ASDM logs I am getting "Failed to consume SAML assertion. reason: The profile cannot verify a signature on the message."

Any ideas? 

[Marvin Rhoads]

@Andreas Foerby It's usually the certificate you have configured for the iDP (Azure).

1. Double check the Azure side certificate is the one you imported into your ASA as a CA certificate.

2. Double check that the very same certificate bound to a trustpoint and that the trustpoint is the one specified in the "trustpoint idp" section of the saml config in the webvpn section of the ASA configuration.

As noted, if you make any change to the saml configuration, you need to remove and re-add it to the tunnel-group ("connection profile" in ASDM)

[Andreas Foerby]

@Marvin Rhoads 
I have double checked the Azure side certificate - OK.
Double checked trustpoints mathing - OK. 
I have tried both removing the saml config from tunnel-group and added it again, but also rebooted the appliance. 

Time is synchonized with a public NTP server. 

To make sure I don't hit a bug or something like, I have requested an upgrade to recommended release (ASA 9.14.2). 

Will give you an update after.  

[Andreas Foerby]

Have updated the firewall now to 9.14.2, but the error is still coming. 

I tried to do a debug webvpn saml 255 while trying which gave me this output: 

May 03 13:42:57
[SAML] build_authnrequest:
https://login.microsoftonline.com/.................

[SAML] saml_is_idp_internal: getting SAML config for tg AnyConnect_AAD_SAML
AnyConnect_AAD_SAML
May 03 13:42:57
[SAML] consume_assertion:
PHNhbWxwOlJlc3BvbnNlIElEPSJfMGU5MmJkMjUtOTE5Zi00ZjBjLWI5NWUtN2RkMTI1OGJkNmUzIiBWZXJzaW9uPSIyLjAiIElzc3VlSW5zdGFudD0iMjAyMS0
wNS0wM1QxMTo0Mjo1Ny4zNjhaIiBEZXN0aW5hdGlvbj0iaHR0cHM6Ly92cG4uc3ZlbmRzZW4tc3BvcnQuY29tLytDU0NPRSsvc2FtbC9zcC9hY3M/dGduYW1lPU
FueUNvbm5lY3RfQUFEX1NBTUwiIEluUmVzcG9uc2VUbz0iXzU2NDk4QzBEMjY5QjEyM0RBNTQ2QzVBRjA5MDgwODE2IiB4bWxuczpzYW1scD0idXJuOm9hc2lzO
m5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIj48SXNzdWVyIHhtbG5zPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIj5odHRwczovL3N0
cy53aW5kb3dzLm5ldC81NTQwNGYwMS04NDFkLTQ4NjAtYmU5NC00OWY5NDcyODdlNWYvPC9Jc3N1ZXI+PHNhbWxwOlN0YXR1cz48c2FtbHA6U3RhdHVzQ29kZSB
WYWx1ZT0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnN0YXR1czpTdWNjZXNzIi8+PC9zYW1scDpTdGF0dXM+PEFzc2VydGlvbiBJRD0iXzA2YzA4NTRjLT
liNzAtNDZhZC1hMjI4LTNhM2U2ZWEwOTQwMSIgSXNzdWVJbnN0YW50PSIyMDIxLTA1LTAzVDExOjQyOjU3LjM2M1oiIFZlcnNpb249IjIuMCIgeG1sbnM9InVyb
jpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iPjxJc3N1ZXI+aHR0cHM6Ly9zdHMud2luZG93cy5uZXQvNTU0MDRmMDEtODQxZC00ODYwLWJlOTQt
NDlmOTQ3Mjg3ZTVmLzwvSXNzdWVyPjxTaWduYXR1cmUgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiPjxTaWduZWRJbmZvPjxDYW5
vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+PFNpZ25hdHVyZU1ldGhvZCBBbG
dvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZHNpZy1tb3JlI3JzYS1zaGEyNTYiLz48UmVmZXJlbmNlIFVSST0iI18wNmMwODU0Yy05YjcwL
TQ2YWQtYTIyOC0zYTNlNmVhMDk0MDEiPjxUcmFuc2Zvcm1zPjxUcmFuc2Zvcm0gQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcj
ZW52ZWxvcGVkLXNpZ25hdHVyZSIvPjxUcmFuc2Zvcm0gQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzEwL3htbC1leGMtYzE0biMiLz48L1RyYW5
zZm9ybXM+PERpZ2VzdE1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI3NoYTI1NiIvPjxEaWdlc3RWYWx1ZT5IOThxQ2
VEaVFuL2YvOVo0UDBZWEU0VHEvVVBUK3BQLzd6UmExeCtRbS9jPTwvRGlnZXN0VmFsdWU+PC9SZWZlcmVuY2U+PC9TaWduZWRJbmZvPjxTaWduYXR1cmVWYWx1Z
T5QMHJSL2RQQXdTdE4ybTNlS2lGaTR0VmVlUTVRYW5XSHlXTGlvVDMyWGQwenpNUXV1TmxmTGFMVmpKRzFNQkphamNuVWNxQWltT1pCWmlmL0ZKY3J3OThyM0Fw
TkFJOEtsVlc0MFNYSFB4Y0lWZkhUbkkzTlp3bVNWTk50UlJ4RnZ0Z3BtUEhRY0FDZCtrUjlMNU85Ky9kMW8wS3o5alN2cXF1YjdzdHhwL1BYS09ia3QzSC90NkZ
YQUVXWnNySnFxRnp0U0NUNWN1YjFBMVIxckcrUW1JRmVMbUFoSVBQZTFnYkZOQXgwc3p4WCt0VzVJUGhIeUtPajBvMkt4MTFSUWJOQlJhRXlIakdKMHFScEJaUG
dOMVF4Z095cFQ1OHRvMGpWbU5IWmJTZUk3TWxrN0gzeG41RWVGOG52dWtNTjFuSVhiRC9tWjFwR3FLTUJoNlFTdFE9PTwvU2lnbmF0dXJlVmFsdWU+PEtleUluZ
m8+PFg1MDlEYXRhPjxYNTA5Q2VydGlmaWNhdGU+TUlJQzhEQ0NBZGlnQXdJQkFnSVFVTy9hV2t4UmdJWkxZR01LU2lRVEd6QU5CZ2txaGtpRzl3MEJBUXNGQURB
ME1USXdNQVlEVlFRREV5bE5hV055YjNOdlpuUWdRWHAxY21VZ1JtVmtaWEpoZEdWa0lGTlRUeUJEWlhKMGFXWnBZMkYwWlRBZUZ3MHlNVEEwTWprd056QTRNRGh
hRncweU5EQTBNamt3TnpBNE1EaGFNRFF4TWpBd0JnTlZCQU1US1UxcFkzSnZjMjltZENCQmVuVnlaU0JHWldSbGNtRjBaV1FnVTFOUElFTmxjblJwWm1sallYUm
xNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQTNOQUl1MmhDb0ZaaVk0LzV4YTRUazBNM1lBWU5UYVFMb2F3ZUFoKzhJcjJrMEUxV
FVZRWFnMWg3VTMrNDVpYWp3QlI4Yy9RbkZKRWVEQzkweTd6aHVOZEtzbVBhamVESmhBT1ZFU3VJY255MU95WmFvSkZWOXZaZmZFdkx2R3lsMW1Lc0R0OUtWY2VX
cHdnR3Y3ck01MEwvRW9Od0ZvM0MrcnNtQW1LaDFUU080NEFzQ0xPMzg2cmdCNnVZcmE3K0g5cGFiMTZabWJUWkJKZFpndVZCdFdGUnJkYTFsOGpxZU8rSTFZRVB
FWVk4STB6eDF6SUVjbzhZdGhUdjF2NmNGWXNhalhZdTRyRU8xS3d6VWx3MjBEcFpWSjR1akFoVm1oOWxXN09ZMUI2MzMxTkduM0dMY3VlTzIxVVBCaVA1NzhrcG
41KzR4V1JyN0drcHFZZ0R1UUlEQVFBQk1BMEdDU3FHU0liM0RRRUJDd1VBQTRJQkFRQkRrWVdoaVZNWjFiL3AyTzdwQmdIVnpDMjNkMC81WThXMUxEZTNMUVp3Z
Xh4amRieXZGaWJQYTBoNitLUXhVcm1JWThKUTRkNjZqSDUzZXJ6eGI1M3RUZVNaNFE4N1htdHRoeUdvaEJyc0Y1akU0TnBvRXk4TzBjOWowdkhlMnRrZ0RCTXFX
cjg3YTRXYjBqSmRKSFU5ZWdHYVhYak1XT2FsTnJGQ1BzblRrYlNuTUdoMGlja2k0Q014UGxWdUFKYVVuWDNxbEVGYVViS05jcmFlZDRMN3krbWxkN2hUZ1FwSEl
VdmVUYnJ0dTRoaEtpZUhuU3g4WEp3NFJMK0s0MTBvYVpOQnJuVldqYVlBeWhUQVVmTEpjUm9hM2JBY2lQRHpCVmdoYVlZVzJ5eW5VM2swQVN2eFk2eTlWaFMwMU
5yVU5mek9WYnU3Qk1Kd0dadVZvNkN4PC9YNTA5Q2VydGlmaWNhdGU+PC9YNTA5RGF0YT48L0tleUluZm8+PC9TaWduYXR1cmU+PFN1YmplY3Q+PE5hbWVJRCBGb
3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjEuMTpuYW1laWQtZm9ybWF0OmVtYWlsQWRkcmVzcyI+QnJpYW4uQmVjaC5MYXVyc2VuQHN2ZW5kc2VuLXNw
b3J0LmNvbTwvTmFtZUlEPjxTdWJqZWN0Q29uZmlybWF0aW9uIE1ldGhvZD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmNtOmJlYXJlciIMay 03 13:42
:57 [Lasso] func=xmlSecOpenSSLEvpSignatureVerify:file=/local/jenkins/workspace/fxplatform/Builds/release__2.8.1_fcs_jubilee
/build-smp-compile/fxos/linux/wrlinux/bitbake_build/tmp/work/corei7-64-wrs-linux/xmlsec1/1.2.20-r1/xmlsec1-1.2.20/src/opens
sl/signatures.c:line=493:obj=rsa-sha256:subj=EVP_VerifyFinal:error=18:data do not match:signature do not match

May 03 13:42:57 [SAML] consume_assertion: The profile cannot verify a signature on the message
May 03 13:42:57
[SAML] consume_assertion:

[saml] webvpn_login_primary_username: SAML assertion validation failed

I have checked again that the certificates matches each other and they are OK! 

[bp.brugman]

We had the same issue, we tried all mentioned solutions but non helped. Finally I removed the Microsoft Azure Federated SSO Certificate from the ASA and reinstalled it with same base64 certificate and all worked properly. Hopefully this might help others.

[eggersp01]

Thanks bp.brugman!

helped a lot and saved our evening!

[mhrastinski]

I know this has been solved for four years but I have been recently had a ton of problems with this and got it working. 

I have this working on another device and the device I was having issues with under a different profile. We got rid of the old profile and wanted to move the saml configuration to another profile on the device. I modified everything in portal.azure.com to point to the new profile and made the changes. The configuration was based on the guide on the link below.

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

When I attempted to log in. I got the correct MFA prompts. After i was authenticated, i got the error "Authentication failed due to problem retrieving the single sign-on cookie." I attempted to remove the saml configuration from the tunnel group. That did not work. I reloaded to ASA, which also did not work. The ASA would not generate the XML file at http://URL/saml/sp/metadata/ProfileName . I removed the tunnel group and SAML configuration from the ASA and then rebooted. After a reboot I recreated both and still the XML was not created properly.  

I finally just attached the SAML config to another tunnel group and it created the XML file for that group. After that I removed the tunnel group that I was working with and recreated it with all lower case letters in the name instead of all upper case letters. the remainder of the configuration for the tunnel group was unchanged. The XML file for the profile was created and I was able to log in using SAML through Azure. 

I could find very little about this issue online. I hope this helps.

[J. H.]

Got the same problem here but XML seems to be created fine.
We're running Remote Access using Firepower FTD 7.0.6 though and configuration is done via FMC.

Can't seem to find any logs in FMC from the attempts on that vpn-group.
The IdP works and users get MFA, but AnyConnect client reports "Authentication failed due to problem retrieving the single sign-on cookie."