Anyconnect with SAML connection issue

[StevenEdmunds6666]

Hi All,

I have configured Cisco AnyConnect to authenticate with SAML and O365.

When I connect, I am presented with the login page at which point I enter the password and then authenticate from my mobile phone. However, when it's 'authenticated' I get a message saying, 'You are Disconnected. You may now close this browser tab'. 

I have also noticed that even though it's gone through, the VPN doesn't actually connect.

The only thing that I have noticed which looks odd to me is that the 'Login URL' and the 'Logout' URL appear to both be the same in the Azure side SAML page.

***Just found this message when authenticating: "Failed to consume SAML assertion. reason: The profile cannot verify a signature on the message." Have tried to re-enable SAML auth in tunnel-group but no luck.***

Thanks for reading and any questions, please let me know.

Steven

[balaji.bandi]

check and validate the config as per below document or post the config here :

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

as suggest bottom of the page run debug to get what causing the issue.

[StevenEdmunds6666]

Thank you for this; I have run the 4 debug commands from the bottom and produced the following results:

Steven

[balaji.bandi]

[saml] webvpn_login_primary_username: SAML assertion validation failed

check the below thread may help to fix 

https://community.cisco.com/t5/vpn/anyconnect-authentication-using-microsoft-adfs-saml/td-p/3479195

[StevenEdmunds6666]

Thanks BB, I think I'm getting closer to it but have a question regarding the SAML metadata XML.

Compared to the one provided in the article you provided, the only that I can see that's different is the section head 'SPSSODescriptor' returns as 'AuthnRequestsSigned="false"' whereas their returns as 'true'. 

I have included if you wish to see...

On top of that, as I go further into the article, it suggests that I need to configure a SAML 2.0 IDP but I'm not sure where in the process this should be going when following the article in your first response.

Just as a sidenote, do I need a vaild SSO cert or can I get away with using the router signed? Currently testing without one.

Steven

[balaji.bandi]

Follow below video

https://www.youtube.com/watch?v=bSGjeJotO2s

Still having issues, post the config from ASA, and new debug logs.

[StevenEdmunds6666]

Thanks for the link BB.

I followed it and still seem to be hitting the same road block. I have attached the config and the debugs.
I did see that it could be related to the following but not 100% sure: CSCvi23605 : Bug Search Tool (cisco.com)

Steven

[Marvin Rhoads]

You need a valid CA-signed certificate on the VPN headend. Also, your headend needs to trust the certificate being presented by the SAML iDP.

[StevenEdmunds6666]

Hi Marvin,

Apologies for the lack of understanding. When you say a valid 'CA-signed Certificate', are you referring to an SSL certificate for the domain like 'vpn.domain.com'? Is this what I'm after: Configure ASA: SSL Digital Certificate Installation and Renewal - Cisco

Thanks.

Steven

[Marvin Rhoads]

@StevenEdmunds6666 stepping back a bit, when an ASA requests authentication be handled by a SAML identity provider (iDP) it contacts the iDP server via SSL/TLS. in doing so, it needs to trust the iDP's certificate. That's one part of the puzzle.

After the SAML iDP interacts with the user to authenticate them, it contacts the ASA to tell it the authentication is complete (or failed, as the case may be). In that piece, the ASA (acting as the "Service Provider" in SAML terms) is the server whose certificate must be trusted by the iDP. So the ASA (or FTD or router - whatever is acting as the VPN headend) needs to have a proper certificate signed by a well-known public Certificate Authority (CA) so that the communication from the iDP to the ASA is likewise trusted and secured.

The document you linked is indeed one that provides instructions on how to acquire and install a certificate on your ASA.

[StevenEdmunds6666]

Hi Marvin,

I tried to install the certificate via the GUI using the documentation under the heading 'CA Certificates' and giving the Trustpoint name. However, I get the attached error.

I was however, still able to install it against the identity I had used to generate the CSR and against the outside interface under the SSL settings. 

Can I continue even with the problem I ran into or by not addressing it, will I make it harder for myself?
I have also included the running config so you can see it.

Thanks,

Steven

[Marvin Rhoads]

I read lately that Digicert's issuing template can cause that error you saw. It looks like your portal is OK.

Is SAML still not working for you? I don't see the SAML config stanzas in the running-config that you shared.

[StevenEdmunds6666]

@Marvin Rhoads that config was pre-MFA when I was having an issue installing the CA cert.

I am indeed still running into the same issue. I have attached the latest config with the debugs.
I have tried everything from recreating the SAML cert on the 365 end and even resetting the config back to an earlier point in time and going through the whole config again.

These are the errors I'm seeing from the debug webvpn saml 255:
[Lasso] func=xmlSecKeyDuplicate:file=keys.c:line=670:obj=unknown
Jan 10 11:20:51 [SAML] consume_assertion: The profile cannot verify a signature on the message
[saml] webvpn_login_primary_username: SAML assertion validation failed

[Marvin Rhoads · Accepted solution]

In my experience, the error "consume_assertion: The profile cannot verify a signature on the message" is almost always due to not having the iDP's certificate installed on the ASA as a trusted CA. I'd double check that and let us know.

[StevenEdmunds6666]

Hi Marvin,

Thanks for your assistance on this one. Tuned out to be a combination of a few things but these are the steps used to resolve the issue.

1. I made a mistake in the CA certificate when reissuing which meant it wasn't looking at 'vpn.companydomain.com'
2. I ended up removing the crypto ca trustpoint AzureAD-AC-SAML and adding the certificate back in from Microsoft again
3. I also had to re-run the command that sets the IDP and SP to MS and local Trustpoint after removing and having to reapply the certificate