Anyconnect cert map on FTD?

[AdamKoch58333]

Just configured cert map for Anyconnect connection profile autoselection, with no luck.

Configuration:

Cert map matches subject email field with value "scep@company.com" -- if this condition is true, it should pick profile 2

Otherwise if no match is found, it should default to profile 1.

So, when configured, the option to select a profile still exists for the user when they click connect.  This seemed unexpected to me.

Next I saw there was a checkbox in FMC to disable connection profile selection, so I did this and deployed, and the option to select went away, however I now only get login failures.  Neither the cert map to profile 2, nor the default to profile 1 logic was ever referenced in my testing, so I rolled back.

Seems like this feature doesn't work?  Anyone know what I might be doing wrong?  Cert auth works just fine with my profiles, I'm just trying to force users into certain ones based on certificate attributes.

[Cisco_Virtual_Engineer]

It appears that the certificate map configuration for the AnyConnect connection profile autoselection is not working as expected. To troubleshoot this issue, please follow these steps:

1. Verify the certificate map configuration on the ASA. Make sure the syntax and attribute matching are correct. The configuration should look similar to this:


crypto ca certificate map CERT_MAP_NAME 10
subject-name attr email match ^scep@company.com


2. In the group policy for the connection profile, make sure the certificate map is applied correctly:


group-policy GROUP_POLICY_NAME attributes
certificate-map CERT_MAP_NAME


3. Verify that the certificate map is correctly associated with the connection profile:


tunnel-group PROFILE_2_NAME type remote-access
tunnel-group PROFILE_2_NAME general-attributes
default-group-policy GROUP_POLICY_NAME


4. Check the ASA logs for any errors or issues related to the certificate map or connection profiles. This can help identify any configuration issues or problems with the certificates themselves.

5. If the issue persists, you may need to collect the DART (Diagnostic AnyConnect Reporting Tool) bundle from the client experiencing the issue. This will provide more detailed information about the connection attempt and any errors that may have occurred.

If you still face issues after trying the above steps, you might want to open a support case with Cisco TAC for further assistance.

[tvotna]

AnyConnect certificate mapping rules definitely work. We use them successfully. You can collect DART and check what's happening.

[AdamKoch58333]

I just don't have a test env to work with - FTDv Eval doesn't enable RAVPN.

In FMC, I've gone to Devices -> VPN -> Remote Access -> Advanced, and configured certificate map there as per my OP.

Can you tell me if that's what you've configured?  Is there anything else?  I'm still waiting for an answer from TAC, it's been a little over a month

[tvotna]

We're on ASA. And there are three distinct features: 1) client-side certificate selection -- rules in AnyConnect profile which allow you to select client certificate automatically; 2) server-side connection profile selection with certificate maps to select connection profile (tunnel-group) the client request lands to; 3) client-side connection entry selection controlled from server with "tunnel-group-list enable" ASA CLI -- this can be disabled as you did. All of them work just fine, unless there is some bug on ASA (server-side selection is implemented by the underlying ASA code of FTD).

So far as I remember, there are two helpful debugs to debug connection profile mapping:

debug aggregate-auth 255debug crypto ca 255

At some point you'll see something like this:

CRYPTO_PKI: Attempting to find tunnel group for cert with serial number: 29, subject name: cn=NAME, issuer_name: cn=SubCA,ou=OU,o=ORG,c=US.
...CRYPTO_PKI: Processing map TEST sequence 10...
CRYPTO_PKI: Match of subject-name attr field to map PASSED. Peer cert field: cn = NAME, map rule: subject-name attr cn co name.
CRYPTO_PKI: Peer cert has been authorized by map: TEST sequence: 10.
CRYPTO_PKI: Tunnel Group Match on map TEST sequence # 10. Group name is ACTG

[Rob Ingram · Accepted solution]

@AdamKoch58333 if you don't want the users to have the option to select a connection profile then don't create aliases for the other connection profiles. Configure the DefaultWEBVPNGroup with the authentication settings, then use the certificate map to connect the users to the correct connection profile. When the user clicks connect they will not be prompted to select a connection profile, they will initially connect to the DefaultWEBVPNGroup before being mapped to the correct connection profile as per the certificate map rules.

[Salman Mahajan]

Hi 

Can you share your config 

Regards
SALMAN

[AdamKoch58333]

6.4.0.9. I know it is old.

[AdamKoch58333]

Ok, did some more testing.

Additional details: 

 - COMPANY_RA_Policy_1 = AAA only, COMPANY_RA_Policy_2 = AAA+Cert. 

 - TestPC1 = No valid cert.  TestPC2 = Valid machine cert w/ EA=scep@company.com SAN attribute

 - TestPC1 should connect to COMPANY_RA_Policy_1 (and does today successfully using Alias)

 - TestPC2 should connect to COMPANY_RA_Policy_2 (and does today successfully using Alias)

Goal: 

 - Have TestPC1 automatically map to default connection profile (as defined below) as it has no valid cert so should match no rules

 - Have TestPC2 automatically map to COMPANY_RA_Policy_2 on merit of it's certificate + SAN EA attribute

Here is what I tested:

1).  Disabled Aliases for COMPANY_RA_Policy_1 and COMPANY_RA_Policy_2

FMC >> tunnel-group COMPANY_RA_Policy_1 webvpn-attributes

FMC >> group-alias COMPANYMFA disable

FMC >> exit

FMC >> tunnel-group COMPANY_RA_Policy_2 webvpn-attributes

FMC >> group-alias COMPANYMFA-AOVPN disable

FMC >> exit

2).  Configured cert maps for email address as discussed

FMC >> tunnel-group-map default-group COMPANY_RA_Policy_1

FMC >> crypto ca certificate map CertMap_SCEP_Email 10

FMC >> subject-name attr ea eq scep@COMPANY.com

FMC >> exit

FMC >> webvpn

FMC >> certificate-group-map CertMap_SCEP_Email 10 COMPANY_RA_Policy_2

Both TestPC1 and TestPC2 client experience was as such:

Connect -> Prompted for username/password -> enter in proper username/password -> Login failure.

Submitted DART logs to TAC. 

More additional info:  Did not configure DefaultWebVPNGroup with Cert+AAA as one of my machines cannot pass cert auth - not sure if this is documented anywhere that this group must be used?

[tvotna]

To use certificate maps you don't really need to enable certificate authentication in the DefaultWebVPNGroup. Software is smart enough to understand that certificate authentication may need be used if certificate-group-map is configured under webvpn. During AnyConnect handshake (inside application protocol) client certificate will be matched and connection mapped to corresponding tunnel group.

Did you disable group-mapping completely ("no tunnel-group-list enable") or just disabled few group-aliases? If you configure "no tunnel-group-list enable", does it make any difference for your TestPC1? Does DefaultWebVPNGroup have everything configured properly like IP address pool, etc. to connect to it? You can run another test: leave "tunnel-group-list enable", configure "group-alias" in the DefaultWebVPNGroup and test if TestPC1 can connect to DefaultWebVPNGroup.

For TestPC2 it worth to try some other cert attribute, e.g. CN, etc, instead of EA. There might be a bug with EA specifically (?).

Once again, to troubleshoot, you either need to collect debugs or syslog at level 7. Below syslog messages will help, e.g.:

%ASA-7-717025: Validating certificate chain containing 2 certificate(s).
%ASA-7-717029: Identified client certificate within certificate chain. serial number: 29, subject name: cn=PC.
%ASA-7-717030: Found a suitable trustpoint SubCA to validate certificate.
%ASA-6-717022: Certificate was successfully validated. serial number: 29, subject name: cn=PC.
%ASA-6-717028: Certificate chain was successfully validated with warning, revocation status was not checked.
...%ASA-7-717036: Looking for a tunnel group match based on certificate maps for peer certificate with serial number: 29, subject name: cn=PC, issuer_name: cn=SubCA,ou=TEST,o=COMPANY,c=US.
%ASA-7-717038: Tunnel group match found. Tunnel Group: ACTG, Peer certificate: serial number: 29, subject name: cn=PC, issuer_name: cn=SubCA,ou=TEST,o=COMPANY,c=US.

[AdamKoch58333]

I did try both disabling aliases and disabling the tunnel group list selection, no luck.  

I do not use DefaultWebVPNGroup at all.  It has no authentication configured or anything, it is empty/default.  So, to clarify, if I am not using this tunnel-group at all, but I still need to configure it for cert maps?  Is this documented anywhere?  To what degree must it be configured?  Just authentication, or also IP pools?

Tunnel group list on FTD:

DefaultWebVPNGroup - no authentication configured, no authorization configured, no accounting configured

Company_RA_Policy_1 - AAA only auth + RAVPN IP pool, etc... - this is a production tunnel-group in use today

Company_RA_Policy_2 - AAA + Cert + RAVPN IP Pool, etc... - this is also a production tunnel-group in use today

I am going to try to set up a virtual test env in GNS3 so I can stop trying to test in production.

[MHM Cisco World]

Can i see profile of your anyconnect pc.

[AdamKoch58333]

<?xml version="1.0" encoding="UTF-8"?>
<AnyConnectProfile xmlns="http://schemas.xmlsoap.org/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.xmlsoap.org/encoding/ AnyConnectProfile.xsd">
<ClientInitialization>
<UseStartBeforeLogon UserControllable="true">false</UseStartBeforeLogon>
<AutomaticCertSelection UserControllable="false">true</AutomaticCertSelection>
<ShowPreConnectMessage>false</ShowPreConnectMessage>
<CertificateStore>Machine</CertificateStore>
<CertificateStoreMac>All</CertificateStoreMac>
<CertificateStoreOverride>true</CertificateStoreOverride>
<ProxySettings>Native</ProxySettings>
<AllowLocalProxyConnections>false</AllowLocalProxyConnections>
<AuthenticationTimeout>60</AuthenticationTimeout>
<AutoConnectOnStart UserControllable="true">false</AutoConnectOnStart>
<MinimizeOnConnect UserControllable="true">true</MinimizeOnConnect>
<LocalLanAccess UserControllable="false">false</LocalLanAccess>
<DisableCaptivePortalDetection UserControllable="false">false</DisableCaptivePortalDetection>
<ClearSmartcardPin UserControllable="true">true</ClearSmartcardPin>
<IPProtocolSupport>IPv4,IPv6</IPProtocolSupport>
<AutoReconnect UserControllable="false">true
<AutoReconnectBehavior UserControllable="false">ReconnectAfterResume</AutoReconnectBehavior>
</AutoReconnect>
<SuspendOnConnectedStandby>false</SuspendOnConnectedStandby>
<AutoUpdate UserControllable="false">true</AutoUpdate>
<RSASecurIDIntegration UserControllable="false">Automatic</RSASecurIDIntegration>
<WindowsLogonEnforcement>SingleLocalLogon</WindowsLogonEnforcement>
<LinuxLogonEnforcement>SingleLocalLogon</LinuxLogonEnforcement>
<WindowsVPNEstablishment>LocalUsersOnly</WindowsVPNEstablishment>
<LinuxVPNEstablishment>LocalUsersOnly</LinuxVPNEstablishment>
<AutomaticVPNPolicy>true
<TrustedDNSServers>x.x.x.x y.y.y.y z.z.z.z</TrustedDNSServers>
<TrustedNetworkPolicy>Disconnect</TrustedNetworkPolicy>
<UntrustedNetworkPolicy>Connect</UntrustedNetworkPolicy>
<AlwaysOn>true
<ConnectFailurePolicy>Open
<AllowCaptivePortalRemediation>false
<CaptivePortalRemediationTimeout>5</CaptivePortalRemediationTimeout>
</AllowCaptivePortalRemediation>
<ApplyLastVPNLocalResourceRules>false</ApplyLastVPNLocalResourceRules>
</ConnectFailurePolicy>
<AllowVPNDisconnect>true</AllowVPNDisconnect>
</AlwaysOn>
</AutomaticVPNPolicy>
<PPPExclusion UserControllable="false">Automatic
<PPPExclusionServerIP UserControllable="false"></PPPExclusionServerIP>
</PPPExclusion>
<EnableScripting UserControllable="false">false</EnableScripting>
<EnableAutomaticServerSelection UserControllable="false">false
<AutoServerSelectionImprovement>20</AutoServerSelectionImprovement>
<AutoServerSelectionSuspendTime>4</AutoServerSelectionSuspendTime>
</EnableAutomaticServerSelection>
<RetainVpnOnLogoff>false
</RetainVpnOnLogoff>
<CaptivePortalRemediationBrowserFailover>false</CaptivePortalRemediationBrowserFailover>
<AllowManualHostInput>true</AllowManualHostInput>
</ClientInitialization>
<ServerList>
<HostEntry>
<HostName>COMPANY VPN</HostName>
<HostAddress>vpn.company.com</HostAddress>
</HostEntry>
<HostEntry>
<HostName>Data Center A</HostName>
<HostAddress>dca.company.com</HostAddress>
</HostEntry>
<HostEntry>
<HostName>Data Center B</HostName>
<HostAddress>dcb.company.com</HostAddress>
</HostEntry>
</ServerList>
</AnyConnectProfile>

[tvotna · Accepted solution]

Your TestPC1 doesn't have valid certificate, hence certificate map doesn't match and connection lands to DefaultWebVPNGroup, unless you enabled other features, i.e. mapping to connection profile by "group-alias" or by "group-url". To be honest, I don't remember how combination of "group-alias" and "certificate map" works. For "group-url" + "certificate map", "certificate map" has priority by default. If "certificate map" doesn't match, the system falls back to "group-url" mapping method.

So, if IP pool is not configured in the DefaultWebVPNGroup, it cannot accept connections. (The AAA/LOCAL authentication is enabled there by default which means that user should be in LOCAL database). This explains why TestPC1 cannot connect.

For TestPC2 you don't need to configure DefaultWebVPNGroup (in my opinion and from my ASA experience -- I don't believe FTD is different). It looks like certificate map indeed doesn't work for some reason and connection again lands to DefaultWebVPNGroup. You see password prompt (AAA/LOCAL in ON by default), user is not in LOCAL database and connection attempt fails.

[AdamKoch58333]

Thanks for your response - This makes sense to me, but I'm wondering if you can link any documentation that I can read to gain a better understanding of the "DefaultWebVPNGroup" behavior?  

I'd think that since this is configured:  tunnel-group-map default-group COMPANY_RA_Policy_1

That regardless of a valid cert or not, it'd map to Company_RA_Policy_1 - if this is not the case it is not very intuitive

It is also possible that I ran into a bug where email address is not being considered for TestPC2.

The bug + DefaultWebVPNGroup not being configured sounds like the exact cause for my problems.