AnyConnect: Configuring user filtering based on certificate authentication

[Alexander Vasilev]

Hello network collegues,

recently I needed to configure AnyConnect SSL VPN with certificate authentication for the needs of Connect-on-Demand functionality of Cisco Jabber.

Everything is ok, but I need to filter users based on information from their personal certificates. For example - now everyone who has personal certificate from our CA can access this VPN. I want to define users by email from the certificate and only these users to be granted for access.

I used this commands:

webvpn

enable Outside

anyconnect image disk0:/anyconnect-win-3.1.04072-k9.pkg 1

anyconnect enable

tunnel-group-list enable

certificate-group-map Cert-Filter 10 Company-Jabber

crypto ca certificate map Cert-Filter 10

subject-name attr ea eq testuser@company.com

The problem is that I aways have access - If I change testuser@company.com to

On the AnyConnect client - I connect to the GroupURL of the Connection Profile Company-Jabber

[Herbert Baerten · Accepted solution]

Hi Alexander

there are many ways to address this and it depends a bit on the rest of the config, e.g. if you have other tunnel-groups etc.

I guess the simplest way (if it does not interfere with the rest of your config) is to add something like this:

crypto ca certificate map Cert-Filter 65535
 subject-name ne ""

This would catch all users/certificates not matching your earlier rule(s).

Then under webvpn you map these users to another tunnel-group (connection profile):

certificate-group-map Cert-Filter 65535 NoAccess

And configure the NoAccess group in such a way that access is denied (e.g. by setting simultaneous logins to 0 in the corresponding group-policy).

Other ways would be to use DAP (Dynamic Access Policies) to do roughly the same as the certmap, or LDAP authorization (i.e. extract the username from the certificate, then do an LDAP lookup to see if the user is allowed to use the VPN - in that scenario you do not need to list all the users on the ASA but you need to e.g. create a new group on your LDAP server that contains all VPN users).

Let me know if you want to go deeper into any of the above

cheers

Herbert

[Alexander Vasilev]

Thank you for the very helpful answer, Herbert!

I have LDAP query for another AnyConnect Profile which is user/pass based.

aaa-server LDAP (Inside) host 192.168.1.148

server-port 389

ldap-base-dn DC=company,DC=com

ldap-scope subtree

ldap-naming-attribute sAMAccountName

ldap-login-password *****

ldap-login-dn CN=VPN User,OU=__ System Accounts,DC=company,DC=com

server-type microsoft

ldap-attribute-map LDAP_Member_of_VPN_Groups

ldap attribute-map LDAP_Member_of_VPN_Groups

  map-name  memberOf Group-Policy

  map-value memberOf "CN= Phone VPN Access,OU= Security Groups,OU=_Groups,OU=__Staff,DC=comapny,DC=com" PHONES_POLICY

  map-value memberOf "CN= VPN Access,OU=Security Groups,OU=_Groups,OU=__Staff,DC=company,DC=com" FULLVPN_POLICY

Can I use this somehow to check users?

[Herbert Baerten · Accepted solution]

Hi Alexander

you could use this ldap server as authorization-server-group in your tunnel-group, but I'm not sure if that will do what you want - it would allow anyone to connect if they have a certificate and belong to the Phone VPN Access group OR the VPN Access group.

You can probably solve that using the grouip-lock command in the group-policy, e.g.

group-policy FULLVPN_POLICY

  group-lock value MY_USERPASS_TUNNELGROUP

group-policy PHONES_POLICY attributes

  group-lock value MY_CERT_TUNNELGROUP

but you may get unexpected results if there are users that are member of both groups.

In that case you may need to create a second attribute map, link it to a new ldap server group (containing the same server(s)) and then use that new group for authorization.

BTW in your tunnel-group you may also need to configure "username-from-certificate cn" or something similar.

Sorry for the brevity of my answer but I hope this can get you a bit further already and if it is unclear or you are hitting another problem, let us know.

cheers

Herbert

[Alexander Vasilev]

Yes, that's exactly what I need - everyone with certificates from our CA can connect, but only these within one of the groups in AD will have access to resources. So if I get you right, on the connection profile, which is with certificate authentication (and has unique group URL), I choose LDAP as authorization server group. And below (in ASDM) I'll choose Specify the certificate fields to be used as the username - first field CN, second field OU.

I didn't quite get you with the group-lock, can you explain it again in more details?

Best regards and thanks a lot for the support!

[Herbert Baerten · Accepted solution]

Yes I think you get the first part right - for the username-from-certificate mapping please note that you need to specify the *username* as the ldap server expects it.

For group-lock: let's say you have a (simplified) config like this:

group-policy A

...

group-policy B

...

group-policy no-access

   vpn-simultaneous-logins 0

tunnel-group PW

  default-group-policy no-access

tunnel-group CERT

  default-group-policy no-access

ldap attribute-map

  map-value memberOf "CN= Phone VPN Access" B

  map-value memberOf "CN= VPN Access" A

With this setup, a user that is part of the AD group "Phone VPN Access" can still connect to PW (he will get assigned policy B) and vice versa a user that is in "VPN Access" can connect to group CERT (if he has a valid certificate).

So if you add:

group-policy A

  group-lock PW

group-policy B

  group-lock CERT

Then a user in "Phone VPN Access" can only connect to CERT, and a user in "VPN Access" can only connect to PW.

I think this is what you want.

However, as I mentioned, this will NOT work if you have users that are in both AD groups because the ldap map is not intended for such a scenario.

In that case you will have to use DAP instead (or possibly you can also solve it by creating 2 ldap maps, tie them to 2 authentication-server-groups, one for each tunnel-group).

I hope this makes sense, I always find it difficult to provide enough detail without writing an entire manual

Again if there is anything you want to go into deeper let us know.

To get you started on DAP, see:

ASA 8.X : How to deny remote access to LDAP users that don't have Remote Access Permissions

http://www.cisco.com/en/US/products/ps6120/products_white_paper09186a00809fcf38.shtml

Herbert

[Alexander Vasilev]

Ok, but how am I forming the username from teh certificate? If I user CN for the primary field it will extract Alexander Vasilev from the certificate, and if I use OU for the second field - it will extract _Users Accounts (which i think is not very helpful). If I choose CN for first field and E (email) for the second I think will be much more appropriate?

As for the group-lock - I get it, but It's not suitable for the case right now. If I finish the things with defining LDAP group in the authorization field - everything will be ok. Then I'll have one centralized place for managing VPN users - AD groups.

One more question - to the AAA Server group which makes the LDAP queries I have attached LDAP Attribute map. Will this cause any troubles when I use this AAA server group for authorization in my certificate based connection profile?

Thanks a lot, best regards!

Alexander

[Herbert Baerten · Accepted solution]

Ok, but how am I forming the username from teh certificate? If I user CN for the primary field it will extract Alexander Vasilev from the certificate, and if I use OU for the second field - it will extract _Users Accounts (which i think is not very helpful). If I choose CN for first field and E (email) for the second I think will be much more appropriate?

it depends of course what fields you have in your certificate. The field that you extract is what the ASA will send to the LDAP server as username, so you have to make it match.

Worst case you may need to write a LUA regex and use the "Use script to select username" option. see e.g.

https://supportforums.cisco.com/thread/2052210

One more question - to the AAA Server group which makes the LDAP queries I have attached LDAP Attribute map. Will this cause any troubles when I use this AAA server group for authorization in my certificate based connection profile?

Well, it will apply the same mapping. As far as I understood your setup and your requirements, this is exactly what you want to happen.

If not, let me know

Herbert

[Alexander Vasilev]

Thank you for the helpful answer again!

I removed the certificate maps and configured the LDAP for Authorization, but it didn't go well.

When I use User/Pass login I input for example for username avasilev, but when I extract from the certificate CN I get Alexander Vasilev, which is not valid login username. If I extract UPN - I get the Email address, which is not valid also.

You wrote for some LUA regex configuration, and if I understand write it can extract some portion of the certificate - for example avasilev from the UPN, can you help me with this?

One more thing - my certificate is validated, but the revocation list is not checked. The error is:

%ASA-6-717028: Certificate chain was successfully validated with warning, revocation status was not checked.

How can I fix this?

Best regards!

Log:

Feb 04 2014 16:41:39: %ASA-6-725001: Starting SSL handshake with client Outside:213.169.XX.XX/24362 for TLSv1 session.

Feb 04 2014 16:41:39: %ASA-7-725010: Device supports the following 5 cipher(s).

Feb 04 2014 16:41:39: %ASA-7-725011: Cipher[1] : DHE-RSA-AES256-SHA

Feb 04 2014 16:41:39: %ASA-7-725011: Cipher[2] : AES256-SHA

Feb 04 2014 16:41:39: %ASA-7-725011: Cipher[3] : DHE-RSA-AES128-SHA

Feb 04 2014 16:41:39: %ASA-7-725011: Cipher[4] : AES128-SHA

Feb 04 2014 16:41:39: %ASA-7-725011: Cipher[5] : DES-CBC3-SHA

Feb 04 2014 16:41:39: %ASA-7-725008: SSL client Outside:213.169.XX.XX/24362 proposes the following 8 cipher(s).

Feb 04 2014 16:41:39: %ASA-7-725011: Cipher[1] : AES128-SHA

Feb 04 2014 16:41:39: %ASA-7-725011: Cipher[2] : AES256-SHA

Feb 04 2014 16:41:39: %ASA-7-725011: Cipher[3] : RC4-SHA

Feb 04 2014 16:41:39: %ASA-7-725011: Cipher[4] : DES-CBC3-SHA

Feb 04 2014 16:41:39: %ASA-7-725011: Cipher[5] : DHE-DSS-AES128-SHA

Feb 04 2014 16:41:39: %ASA-7-725011: Cipher[6] : DHE-DSS-AES256-SHA

Feb 04 2014 16:41:39: %ASA-7-725011: Cipher[7] : EDH-DSS-DES-CBC3-SHA

Feb 04 2014 16:41:39: %ASA-7-725011: Cipher[8] : RC4-MD5

Feb 04 2014 16:41:39: %ASA-7-725012: Device chooses cipher : AES256-SHA for the SSL session with client Outside:213.169.XX.XX/24362

Feb 04 2014 16:41:39: %ASA-7-717025: Validating certificate chain containing 1 certificate(s).

Feb 04 2014 16:41:39: %ASA-7-717029: Identified client certificate within certificate chain. serial number: 133433334343, subject name: e=avasilev@company.com,cn=Alexander Vasilev,ou=_Users Accounts,ou=__Staff,dc=company,dc=com.

Feb 04 2014 16:41:39: %ASA-7-717030: Found a suitable trustpoint ASDM_TrustPoint0 to validate certificate.

Feb 04 2014 16:41:39: %ASA-6-717022: Certificate was successfully validated. serial number: 133433334343, subject name:  e=avasilev@company.com,cn=Alexander Vasilev,ou=_Users Accounts,ou=__Staff,dc=company,dc=com.

Feb 04 2014 16:41:39: %ASA-6-717028: Certificate chain was successfully validated with warning, revocation status was not checked.

Feb 04 2014 16:41:39: %ASA-6-725002: Device completed SSL handshake with client Outside:213.169.XX.XX/24362

Feb 04 2014 16:41:39: %ASA-6-302013: Built inbound TCP connection 3626447 for Outside:213.169.XX.XX/24363 (213.169.XX.XX/24363) to identity:213.169.XX.XX/443 (213.169.55.50/443)

Feb 04 2014 16:41:39: %ASA-6-725001: Starting SSL handshake with client Outside:213.169.XX.XX/24363 for TLSv1 session.

Feb 04 2014 16:41:39: %ASA-6-725003: SSL client Outside:213.169.XX.XX/24363 request to resume previous session.

Feb 04 2014 16:41:39: %ASA-6-725002: Device completed SSL handshake with client Outside:213.169.XX.XX/24363

Feb 04 2014 16:41:39: %ASA-7-717036: Looking for a tunnel group match based on certificate maps for peer certificate with serial number: 133433334343, subject name: e=avasilev@company.com,cn=Alexander Vasilev,ou=_Users Accounts,ou=__Staff,dc=company,dc=bg, issuer_name: cn=Company Root CA,dc=company,dc=com.

Feb 04 2014 16:41:39: %ASA-4-717037: Tunnel group search using certificate maps failed for peer certificate: serial number: 133433334343, subject name: e=avasilev@company.com,cn=Alexander Vasilev,ou=_Users Accounts,ou=__Staff,dc=company,dc=bg, issuer_name: cn=Company Root CA,dc=company,dc=com.

Feb 04 2014 16:41:39: %ASA-6-302014: Teardown TCP connection 3626445 for Outside:213.169.XX.XX/24361 to identity:213.169.XX.XX/443 duration 0:00:00 bytes 2384 TCP Reset-I

Feb 04 2014 16:41:39: %ASA-6-302014: Teardown TCP connection 3626446 for Outside:213.169.XX.XX/24362 to identity:213.169.XX.XX/443 duration 0:00:00 bytes 2443 TCP Reset-I

Feb 04 2014 16:41:39: %ASA-6-725007: SSL session with client Outside:213.169.XX.XX/24362 terminated.

Feb 04 2014 16:41:39: %ASA-6-725007: SSL session with client Outside:213.169.XX.XX/24363 terminated.

Feb 04 2014 16:41:39: %ASA-6-302014: Teardown TCP connection 3626447 for Outside:213.169.XX.XX/24363 to identity:213.169.XX.XX/443 duration 0:00:00 bytes 985 TCP Reset-I

Feb 04 2014 16:41:39: %ASA-7-609002: Teardown local-host Outside:213.169.55.20 duration 0:00:00

Feb 04 2014 16:41:40: %ASA-6-725001: Starting SSL handshake with client Outside:213.169.XX.XX/24365 for TLSv1 session.

Feb 04 2014 16:41:40: %ASA-6-725003: SSL client Outside:213.169.XX.XX/24365 request to resume previous session.

Feb 04 2014 16:41:40: %ASA-6-725002: Device completed SSL handshake with client Outside:213.169.XX.XX/24365

Feb 04 2014 16:41:40: %ASA-7-113028: Extraction of username from VPN client certificate has been requested.  [Request 192]

Feb 04 2014 16:41:40: %ASA-7-113028: Extraction of username from VPN client certificate has started.  [Request 192]

Feb 04 2014 16:41:40: %ASA-7-113028: Extraction of username from VPN client certificate has finished successfully.  [Request 192]

Feb 04 2014 16:41:40: %ASA-7-113028: Extraction of username from VPN client certificate has completed.  [Request 192]

Feb 04 2014 16:41:40: %ASA-6-302013: Built outbound TCP connection 3626452 for Inside:192.168.1.105/389 (192.168.1.101/389) to identity:192.168.45.2/62059 (192.168.8.2/62059)

Feb 04 2014 16:41:40: %ASA-6-113005: AAA user authorization Rejected : reason = Unspecified : server = 192.168.1.105 : user = Alexander Vasilev

Feb 04 2014 16:41:40: %ASA-6-113009: AAA retrieved default group policy (NoAccess) for user = Alexander Vasilev

Feb 04 2014 16:41:40: %ASA-6-113013: AAA unable to complete the request Error : reason = Simultaneous logins exceeded for user : user = Alexander Vasilev

[Herbert Baerten · Accepted solution]

ok so yes you will need to write a small LUA script to extract the username from the certificate, something like:

local a,b,c;
a,b,c = string.find( cert.subject.ea, '(.+)@company.com' );
return c;

I don't have an ASDM at hand but if I remember well, on the authorization page you can select "use a script" or something like that, and then enter the script above.

For the revocation check, is there a CDP in your certificate, and how is your trustpoint configured?

Herbert

[Alexander Vasilev]

Thank you, authorization is working as I wanted! I'll do tomorrow more tests, but for now is ok!

EDIT: I removed the certificate maps, but I receive following errors:

Tunnel group search using certificate maps failed for peer certificate: serial number: 683553020F6, subject name: e=avasilev@company.com,cn=Alexander Vasilev,ou=_Users Accounts,ou=__Staff,dc=company,dc=com, issuer_name: cn=Company Root CA,dc=company,dc=com.

This is strange...I login, but my colegue can't. Tommorow I'll do some debugs to see why. He is member of the same AD VPN Group.

As for certifcate:

crypto ca trustpoint Company_TP

enrollment terminal

fqdn vpn.company.com

subject-name CN=vpn.company.com,O=Company Ltd.,C=BG,L=Sofia

serial-number

ip-address 213.169.XX.XX

crl configure

crypto ca trustpoint ASDM_TrustPoint0

enrollment terminal

crl configure

crypto ca trustpoint Paraflowcert

keypair Paraflow_TP

crl configure

ssl trust-point Paraflowcert Outside

In personal certificate I have CRL Distribution Point:

[1]CRL Distribution Point

     Distribution Point Name:

          Full Name:

               URL=http://www.company.com/pki/Company%20Root%20CA(2).crl

Best regards!

[Herbert Baerten]

Did you also remove the "certificate-group-map" line under webvpn?

For the CRL: can the ASA resolve "www.company.com", is the CRL actually downloadable from the URL listed in the cert? Other than that my next suggestion would be to debug using "debug crypto ca ..." or "debug crypto pki ..." (enable all debugs starting with that).

[Alexander Vasilev]

Yes, this is all the webvpn config:

webvpn

enable Outside

anyconnect image disk0:/anyconnect-win-3.1.05152-k9.pkg 1 regex "Windows NT"

anyconnect image disk0:/anyconnect-linux-3.1.05152-k9.pkg 2 regex "Linux"

anyconnect image disk0:/anyconnect-macosx-i386-3.1.05152-k9.pkg 3 regex "Intel Mac OS X"

anyconnect enable

tunnel-group-list enable

tunnel-group-preference group-url

If I go in ASDM to Monitoring-Properties-CRL and for my Trustpoint click ViewCRL I get following:

CRL Issuer Name:

    cn=Company Root CA,dc=company,dc=bg

    LastUpdate: 14:48:18 SOF Jan 30 2014

    NextUpdate: 03:08:18 SOF Feb 7 2014

    Cached Until: 13:03:29 SOF Feb 5 2014

    Retrieved from CRL Distribution Point:

      http://www.company.com/pki/Company%20Root%20CA(2).crl

    Size (bytes): 769

    Associated Trustpoints: ASDM_TrustPoint0

Othewise - everything else is working, although It doesn't match certificate map, users are connecting and Authorizing.

Maybe a software bug?

Best regards!

[Herbert Baerten · Accepted solution]

The 'certificate map failed' log message is indeed a cosmetic bug : CSCsv27156 so you can safely ignore this.

For the CRL checking, did you find anything using the pki debugs?

regards

Herbert

[Alexander Vasilev]

Hello Herbert,

as i thought. Ok, there is no problem, in future I'll upgrade.

As for the certificates - I added "revocation-check crl none" in the configuration in my trustpoint and everything is ok. I verified it with debugs in the moment of authentication.

Thank you very much again for the proffesional answers and patience!

Best regards!