VPN 8 - Two-factor authentication with certificate

Under the Prelogin Policy are the created policies, there is at least one, which is initially called Default. Directly on it, we enable the use of Cache Cleaner and possibly Secure Desktop (Vault), and then define their parameters. If we don't enable any of these items, the policy doesn't do anything (but we can use its name in DAP).

Configuration > Remote Access VPN > Secure Desktop Manager > Host Scan

We have described the Host Scan options, here we can configure all the properties. In the Basic Host Scan section, we can add detection of various files, registry keys or processes. In the Host Scan Extensions section, we can enable some extension, by default we have Endpoint Assessment ver 3.6.8133.2.

Configuration > Remote Access VPN > Network (Client) Access > Dynamic Access Policies

DAP policies are applied last, when applied to VPN login, so they can override some values that were set, for example, using the Group Policy. There is always a default policy DfltAccessPolicy, which is used if no other DAP is assigned. So the default policy has no criteria for selection and is the last in the list. If we want to create different policies that allow access (and check certain conditions on them), we must not forget to set the default policy to block access (Action: Terminate). Of course, we can also do it the other way around, we have allowed by default and choose the situations where we block. We must also not forget that DAP apply to all types of Remote Access VPN.

When creating new policies, we first define when it should be applied (Selection Criteria). We can use many attributes from AAA (such as the used Group Policy, Connection Profile, IP address, username, any RADIUS or LDAP attribute) or Endpoint (these are the properties from CSD), or Logical Expression. And what should be set, i.e. Access/Authorization Policy Attributes. We can specify the action Continue, Quarantine, Terminate and set the displayed message. Apply ACLs, change access options (AnyConnect, Web-portal), enable/disable certain Clientless SSL VPN features.

Note: The Quarantine action allows applying a special restrictive ACL to the client, so that they can only access certain services and remedy their state. This feature requires Advanced Endpoint Assessment (and therefore the appropriate license).

Each created policy has a certain priority and the list is traversed according to them (from 0 upwards) when a session is created and a match is searched for in the selection criteria. All records that match are combined and the resulting policy that is applied is assembled.

At the bottom of the page, we can use the Test Dynamic Access Policies button. We enter the attributes and get the output of which policies and how they are applied in such a case.

In the next steps, we will set up authentication so that the certificate authentication is performed first, and then the user is prompted for a username and password, which is verified against the RADIUS server (and ultimately Active Directory).

Configuration > Remote Access VPN > AAA/Local Users > AAA Server Groups

We will prepare an AAA Server Group for authentication. As the protocol, we will choose RADIUS and leave the default values. We will add the RADIUS server to the group, enter the address of the MS Network Policy and Access Services (NPS) server through the inside interface and leave the default ports or modify them according to the server settings.

Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles

We will choose to edit the profile that we will use for the connection. In the Authentication section, we will set the Method to Both and select the created AAA Server Group. This will use both certificate authentication and AAA authentication. In most cases (described in previous parts - using RADIUS with MS-CHAPv2, otherwise the authentication will fail and we'll get a Login failed.) we will also switch to the Advanced - General tab and check Enable password management.

Optionally, we can set a number of other parameters. If there was a reason for it, we could use double authentication (Double Authentication). On the profile, we switch to Advanced - Secondary Authentication and set another AAA Server Group here. In this case, two username and password fields will be displayed when the client logs in.

For greater security, we can set that the username is taken from the certificate and used permanently for authentication (the user cannot change it and does not even need to see it). On the profile, we switch to Advanced - Authentication, in the bottom part we choose which information from the certificate should be used as the username. We can also check Pre-fill-username from certificate for this. Setting the certificate field that is to be used as the username is also important for identifying the user within the session on the ASA. So for example, for the SmartCard Logon certificate, we change the value to UPN so that we get the user's login name and not their display name.

One more configuration option is worth mentioning. In a situation where we use only certificate authentication, and it doesn't pass any authorization information. We can set up authorization against a separate AAA Server Group (LDAP or RADIUS can be considered), even though we don't perform authentication against it. The setting is done in Advanced - Authorization.

Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Client Profile

In the client profile settings, we can specify the parameters by which the certificate for authentication is searched. Of course, it is important that the given client profile is assigned to the Group Policy that is applied to the client.

In the Preferences (Part 1) section, we set the Certificate Store, whether certificates on Windows are searched in the user, computer or both stores. There is also an option for Certificate Store Override, this setting ensures that the computer store is searched, even if the user does not have administrative privileges.

In the Preferences (Part 2) section, we can set the option Disable Automatic Certificate Selection. It decides whether the client is displayed a list of suitable certificates found, or the first one is used automatically.

In the Certificate Matching section, we can restrict (or in other words, allow) the certificates that the client will offer for use in authentication. We can choose some Key Usage and Extended Key Usage values, or enter any OID (into Custom Extended Match Key). In the Distinguished Name part, we can set filters by DN in Subject or Issuer, for example that OU == IT. We can also use various masks for comparison.

Error in Certificate Matching

During testing, I encountered a fundamental error. When I used a character with diacritics in the DN rule. The profile was saved to the profile-name.xml file, but then it couldn't be opened in ASDM anymore. When I tried to open this XML file in Internet Explorer, it reported an error precisely on the Czech character. But what's worse, when the client downloaded this profile, it reported an error immediately at startup. The only solution was to delete the file on the disk c:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile\profile-name.xml.

Application of the AnyConnect Client Profile

Using the client profile, we can set and restrict a number of features that have a security impact. So it's important to know how and when the profile is applied. The Client Profile is assigned via the Group Policy, in the policy Advanced - AnyConnect Client - Client Profiles to Download. The policy is applied after the client logs in, so when we make any changes, it is only after the client successfully logs in, downloads the new settings, and they become active for the next login.

When deploying the client via the web (logging in to Clientless VPN), the current profile is installed immediately during the client installation (it knows the details because we are already logged into the VPN). So the first login is relatively secure.

The downside is that the profile is actually an XML file that is stored on the client's disk. And when someone knows where the file is located, they can delete or edit it and set any values. So all the settings in the profile cannot be considered secure. Where the profile is stored is mentioned in Locations to Deploy the AnyConnect Profiles.

Verification

For verification and troubleshooting, we can use all the usual options. View logs about the login process in Monitoring > Logging > Real-Time Log Viewer, use debug, view information about current VPN connections in Monitoring > VPN > VPN Statistics > Sessions, where in the Details we see a number of information including the authentication method.

For example, in Sessions, and in other places, the username is displayed. That is the information the user authenticated with. In the case of certificate authentication, the set attribute from the certificate is used. If not found, the name <Unknown> is used.

Troubleshooting - debug

I deployed this authentication method on ASA 9.1(5)21 and computer certificate authentication didn't work for me. A user certificate from the same authority worked, though. Neither on the client nor on the ASA was any other information logged than

No valid certificates available for authentication
Certificate validation failure

I don't know what eventually helped, I upgraded to the latest ASA 9.1(7)12. I also uninstalled the AnyConnect client and deleted its profile and all data (this is recommended in some discussions). Then authentication suddenly worked (originally I had also tried from another PC where I hadn't deleted the profile).

Before that, I tried to get some information on where the error was. I was inspired by the article ASA AnyConnect Double Authentication with Certificate Validation, Mapping, and Pre-Fill Configuration Guide. It describes the debug process where we connect to the ASA CLI via SSH (or telnet or console) and enable debugging of the relevant areas:

ASA#debug aaa authentication 
ASA#debug aaa authorization
ASA#debug webvpn 255
ASA#debug crypto ca 255

The article also shows examples of debugging output. It seems quite puzzling to me when the debugging information is displayed, because sometimes it was beautifully printed to the SSH window, sometimes only something, and often nothing at all. Obviously, many people have this problem, as it is discussed in many forums, but nothing helped me. Some say you need to connect through the console or enable logging to your session.

ASA#terminal monitor

It may be useful to print the enabled debugging or turn off all debugging output.

ASA#show debug 
ASA#undebug all

Another option is to display logging information and its settings.

ASA#show logging
ASA(config)#logging monitor debugging