cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10629
Views
15
Helpful
5
Replies

Anyconnect + ikev2 + PSK (pre-shared key) possible like under ikev1 with cisco vpn client

will
Level 3
Level 3

Is it possible to create an Anyconnect RA VPN with just username/password + pre-shared (group) key for connection, like could be done for ikev1 with cisco VPN client? I am running 8.4.X ASA code and it looks like tunnel-group commands have change from 8.2.X a fair amount. Now if you change the tunnel group type to remote-access, there is no option for IKEv2 pre-shared key. This is only available when you choose type

FW1(config)# tunnel-group TG_TEST type ?

configure mode commands/options:
  ipsec-l2l      IPSec Site to Site group
  ipsec-ra       IPSec Remote Access group (DEPRECATED)
  remote-access  Remote access (IPSec and WebVPN) group
  webvpn         WebVPN group (DEPRECATED)

FW1(config-tunnel-general)# tunnel-group TG_TEST ipsec-attributes
FW1(config-tunnel-ipsec)# ?

tunnel-group configuration commands:
  authorization-required  Require users to authorize successfully in order to
                          connect (DEPRECATED)
  chain                   Enable sending certificate chain
  exit                    Exit from tunnel-group IPSec attribute configuration
                          mode
  help                    Help for tunnel group configuration commands
  ikev1                   Configure IKEv1
  isakmp                  Configure ISAKMP policy
  no                      Remove an attribute value pair
  peer-id-validate        Validate identity of the peer using the peer's
                          certificate
  radius-with-expiry      Enable negotiation of password update during RADIUS
                          authentication (DEPRECATED)

FW1(config-tunnel-ipsec)# ikev1 ?

tunnel-group-ipsec mode commands/options:
  pre-shared-key       Associate a pre-shared key with the connection policy

I'm getting old so I hope this doesn't turn into another curmudgeonly complaint about loss of features. :)

Many smaller companies don't want to invest in PKI infrastructure. this is typically a pain to deploy, backup, make redundant, etc.

But it would be nice to have a bit more security on VPN other than just username and password connections.

If this is not possible, is it possible to configure Anyconnect client to do IKEv1 with PSK and group name at the client level?

If that's not possible, WTH did cisco end support for cisco VPN client as a VPN connection choice (other than to get more per-seat license fees)?!?

I sure hope something like this is available still!

thx,

WR

2 Accepted Solutions

Accepted Solutions

You're welcome,

Besides two factor, you can also do double authentication (i.e both using username and password). Each set of credentials can come from a different identity store.

With that scheme, you could could setup a local (common) username with password on the ASA (think of that as your PSK analogue) and have the other one be the user's AD credentials.

 

View solution in original post

will
Level 3
Level 3

Hi marvin, thx again for the second reply. I tested this over the past week. where I'm at (I think):

ASA 8.4 + SSL cert for the server identity.

ASA configure for radius auth. to windows 2008 server (users tied from specific NT groups -> ASA group policies). Using the built-in Radius application role that comes with Windows 200X. This has had plenty of different names in the past such as IAS. It is now called NPS (Network Policy Server)*. Did I mention I like marketing departments that change application names as much as I like client certificates! :)

ASA configured for generic "group-based" client certs. by groups, I mean that each specific user policy gets tied to a group. each user in that policy gets the same client certificate. client certificate is tied to actual user VPN details, such as timeouts, etc. this saves me from having to have a client cert for each user and configure that uniquely on the ASA.

ASA also sets up policy by looking at the client certificate name, which equals the group policy name. client certificates live on the ASA. have a ASA CA server configured, with a 10 year expire cert on he CA and 5 year expires cert on the client side. I know it will be another PITA when the 5 year mark rolls around and I have to issue new client certs to the folks, but it shouldn't be too bad. And I wanted to keep the client cert functionality off the Windows server platform if possible. just seems easier that way, especially if you are a network guy!** :)

ASA can send out the client cert link with a one-time password. user is put into a non-cert NT group with limited SSLVPN permissions, and can login to get the one-time cert and install it. then IT admin moves user to their real policy group. alternately, IT admin can just store the cert on a file share and install it as part of the users PC build/device setup.

In any case, this seems to be working pretty well, with the caveat that client certs are still a PITA! :)

*The configuration notes on NPS are confusing as it is now comprised of a Radius Server (Connection Request Policies-CRP) and Client (Network Polices-NP) configuration Sub-folders. the references on its configuration are confusing as you don't appear to need the CRP portion of the configuration. You just need a simple policy in the CRP area, which is their by default-"Use Windows authentication for all users".

** in working on this, I started to worry about all the meta-data on the ASA that needs backed up - like certs, web customizations, etc. I found that there is a nifty tool in the ASDM from the TOOLs menu that allows one to back up all the junk into specific files/folders. I highly recommend to do this periodically. one advantage of generic role-based client certs, is I don't have to do this each time a new user is created.

thx again, hope this helps others in the same boat. did I mention client certs are a PITA! :)

Will

 

 

View solution in original post

5 Replies 5

Marvin Rhoads
Hall of Fame
Hall of Fame

No - the group PSK has been deprecated with the Cisco IPsec (IKEv1) VPN client.

There are lots of two factor options available for AnyConnect.

With AnyConnect Essentials you can have username and password plus certificate for authentication, certificate plus RSA SecureID passphrase, etc. 

If you have a Windows server infrastructure it's not too awfully difficult to setup a PKI using NDES and use the ASA to proxy SCEP for X.509 certificate issuance. Takes a bit of setup but it's doable.

You can also setup checks for registry keys, presence of files, etc. on the client by using DAP (requires the more pricey AnyConnect Premium). 

hi marvin, thx for quick reply. I'm still sticking to my original comment regarding PKI infrastructure. its much more convoluted, complex and a PIA than one would expect. here is a fairly recent thread on this and the conclusion is still hairy, involving the use of MS clustering with shared storage (and enterprise licenses). this is nice but too costly and complex for SMB's:

http://gallery.technet.microsoft.com/Failover-Clustering-and-b3ea8858/view/Discussions#content

I like to design something that will take a bomb and i can recover from that. Two simple redundant root CA servers in two locations would make me happy (similar to, two always-on AD servers in two locations). It looks like its still a pain! However, it looks like backup CA server is pretty easy and could be done:

http://technet.microsoft.com/en-us/library/cc725565.aspx

would love to hear from Cisco why they thought it was a "non-essential" feature to remove PSK authentication for RA vpn's, or discontinue Cisco VPN client support. This somewhat thoughtless removal of features (or major change) seems to be a recurring theme with companies like Cisco and Microsoft; for example, ASA 8.2->8.3 upgrade or Windows 7->Windows 8. Seems like the program managers just don't seem to get it anymore.

Anyway thx again. I'm sounding old. so ill get off my soapbox now. And start spending my _unpaid_ free-time learning PKI. :)

You're welcome,

Besides two factor, you can also do double authentication (i.e both using username and password). Each set of credentials can come from a different identity store.

With that scheme, you could could setup a local (common) username with password on the ASA (think of that as your PSK analogue) and have the other one be the user's AD credentials.

 

will
Level 3
Level 3

Hi marvin, thx again for the second reply. I tested this over the past week. where I'm at (I think):

ASA 8.4 + SSL cert for the server identity.

ASA configure for radius auth. to windows 2008 server (users tied from specific NT groups -> ASA group policies). Using the built-in Radius application role that comes with Windows 200X. This has had plenty of different names in the past such as IAS. It is now called NPS (Network Policy Server)*. Did I mention I like marketing departments that change application names as much as I like client certificates! :)

ASA configured for generic "group-based" client certs. by groups, I mean that each specific user policy gets tied to a group. each user in that policy gets the same client certificate. client certificate is tied to actual user VPN details, such as timeouts, etc. this saves me from having to have a client cert for each user and configure that uniquely on the ASA.

ASA also sets up policy by looking at the client certificate name, which equals the group policy name. client certificates live on the ASA. have a ASA CA server configured, with a 10 year expire cert on he CA and 5 year expires cert on the client side. I know it will be another PITA when the 5 year mark rolls around and I have to issue new client certs to the folks, but it shouldn't be too bad. And I wanted to keep the client cert functionality off the Windows server platform if possible. just seems easier that way, especially if you are a network guy!** :)

ASA can send out the client cert link with a one-time password. user is put into a non-cert NT group with limited SSLVPN permissions, and can login to get the one-time cert and install it. then IT admin moves user to their real policy group. alternately, IT admin can just store the cert on a file share and install it as part of the users PC build/device setup.

In any case, this seems to be working pretty well, with the caveat that client certs are still a PITA! :)

*The configuration notes on NPS are confusing as it is now comprised of a Radius Server (Connection Request Policies-CRP) and Client (Network Polices-NP) configuration Sub-folders. the references on its configuration are confusing as you don't appear to need the CRP portion of the configuration. You just need a simple policy in the CRP area, which is their by default-"Use Windows authentication for all users".

** in working on this, I started to worry about all the meta-data on the ASA that needs backed up - like certs, web customizations, etc. I found that there is a nifty tool in the ASDM from the TOOLs menu that allows one to back up all the junk into specific files/folders. I highly recommend to do this periodically. one advantage of generic role-based client certs, is I don't have to do this each time a new user is created.

thx again, hope this helps others in the same boat. did I mention client certs are a PITA! :)

Will

 

 

Thanks for updating the thread with your proven solution. It will indeed help pave the path for other folks seeking similar answers.

Lots of departments are challenged getting the Windows admins and network admins speaking the same language (even when it's the same person!). Add into that the products' changing naming and functions and it only complicates the situation.

In part for this reason, the upcoming ISE 1.3 will have its own CA server built-in. Not using certificates is really not an option with ISE; and many of deployments have struggled getting all the Windows- or third party-issued certificates formed properly.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: