I’ve had multiple talks lately about dual factor authentication for VPNs. Basically, there are two options that I’m aware of to accomplish this: a token or a certificate. Dual factor authentication can basically be broken down into two pieces, something you have and something you know. The something you know would be your username and password; the something you have would be your token or certificate. There are benefits to each. Using tokens are easy and most people have had some experience with them. Certificates get a bit tricky because it’s not a skill set that a majority of IT professionals possess. I’m going to touch less on tokens and more on certificates.
Certificate authorities can be configured on a Windows server, a Cisco ASA, or even a Cisco router. The CA on the Cisco ASA and Cisco routers are less scalable and have fewer features than a Windows CA, usually for deployments of less than 50 users. Another major benefit of using a Windows CA is that is usually has a much lower TCO than using tokens.
Once the CA is configured, you then have the challenge of getting the certificates to employees. You can use AD Group Policy to push the certificate to domain computers. You can also use SCEP to easily deploy certificates to mobile and non-AD devices.
Here’s a high level task list for configuring the user template:
1. Duplicate the User certificate template
2. Configure the validity period
3. Check the extensions
4. Disable the export of certs
5. Select the subject criteria (email must be populated for auto-enroll)
6. Set the security permissions on the template and publish it
Once the certificate template is published, you can then use Group Policy to get the certificate onto the domain computers.
To configure SCEP enrollment on the ASA, you need to install the CA Server Certificate chain on the ASA. Once that is done, you can set the enrollment mode for the trust point to request a certificate from a CA. The ASA basically acts as a SCEP Proxy so that clients don’t request certificates directly from the CA.
To prevent users from sharing certificates, you can prefill the username with the certificate CN. Hopefully by doing this only the person that is authorized the certificate will be able to user it. You can also perform checks with the ASA to see if the certificate has moved machines. Optionally, you can use the machine ID as the common name on the cert to tie the cert to a machine. You can then use a dynamic access policy on the ASA to verify device / certificate pair. You can also use a hybrid cert that is a combination of the username and machine name to gain more granular control over who and what can connect. If you decide to use machine identity or hybrid identity certificates, you will need to enroll devices prior to them using the VPN. However, if you use user identity certificates, you can auto enroll the user with SCEP proxy on the ASA.
Another feature that can be used with this is limiting what resources the client is authorized to use during the SCEP enrollment process. Meaning that until they have been enrolled and a certificate issued, you can limit the user to only have http and https access to the CA server.
This is a pretty cool video that shows the process of SCEP enrollment through the ASA with the AnyConnect client. They don’t use prefill on this video, but if you were to prefill the username from the CN of the cert, the user would not have an option to enter their username.
Here is also a link to the Cisco Live breakout session that covers PKI and VPN. You’ll need to register to get a Cisco live account but it’s free.
If you have any questions about VPN dual factor authentication, please contact Network Center, Inc.