Recently a client approached me about improving their VPN authentication. Although the current VPN authentication method had been in place for many years without any issues, the new IT manager’s goal was to migrate the Windows server farm to the latest and greatest version (Windows Server 2008) and improve the authentication to the domain controllers by utilizing group memberships within AD. After a few months, this became an urgent issue because they were moving forward with their Microsoft domain controller upgrades to a Virtual Windows Server 2008 environment. This upgrade would require the use of LDAP as the communication protocol between the ASA and the server(s).
Background: The current ASA appliance also acts as the VPN head end, in addition to its standard perimeter protection duties. The configuration on the ASA had been upgraded from PIX 6.x to 7.2 and not properly cleaned up afterwards. In addition the previous admin had experimented with many different authentication methods and protocols, along with many unused VPN groups which were still in the configuration of the firewall. As a good consultant, upon completion of the project, all the old unused configurations were removed (after confirming with client off course).
Project Goal: The goal for this task is to authenticate VPN users via LDAP to the Windows 2008 domain controllers. In addition to the simple AD authentication requirement, the client wanted to match the user’s credentials against a VPN group in the AD database, as a second layer of protection. This second check against the AD group membership helps to ensure that the user didn’t just obtain the VPN group password along with a user’s username and password. In addition, it gives more control to the IT administrator to make sure that only approved users have VPN access, not all users in the AD branch.
Additional Suggestions: As consultants, we must help our customers secure their environments as much as possible. In this particular situation, I recommended that the client utilizes secure encrypted LDAP communications between the ASA appliance and the authentication servers. The client liked the idea (added value) and agreed to re-visit the idea once his internal certificate servers were ready in production (leads to future work).
Requirements: In order to complete this task, the following items were needed:
1. Upgrade the ASA appliance to 8.0(4). At the time of the project, this version was stable and allowed authentication directly to AD without the need for an additional RADIUS services to be installed on the domain controllers. The most current version of the ASA code today (February 2010) is 8.2(11). If the customer has strict policies in place, they may not allow additional software to be installed on their domain controllers, even if it is a Microsoft product, i.e. Microsoft IAS.
2. A single user account with basic privileges in the AD database. For best results, place this user in the root of the tree (Base DN). Most Windows administrators are OK with this request versus installing RADIUS services on their domain controllers.
3. A solid understanding of the AD directory path. If you are not familiar with AD, I recommend purchasing a tool that will walk the AD tree and give you the entire path in the correct format. A tool that we often use is LDAP Browser http://www.ldapbrowser.com. Typically the onsite Windows administrator will know the path.
Assumptions: An existing functioning VPN group is already in place. A small downtime window will be provided in order to change the authentication method to the new servers and test. If the client can’t give you a window for testing, I recommend building a test VPN group in parallel, test the authentication and then change the production group’s authentication servers.
Procedure: Now let’s get to the configuration steps required to complete this task. I will be using the ASA CLI (command line interface).
The first step is to create an attribute map called ASAMAP. In the map subcommands, we match the well known Microsoft attribute “memberOf” to a standard IETF Radius class, which the ASA is familiar with. The next line takes the newly created association to the path of the AD group, in this example the group name is VPN_Users. The final important note in this step is to notice the value being mapped to the already existing VPN group called ciscovpn. Now that the map name and value to be checked has been created, it will later be associated with the VPN tunnel group.
ldap attribute-map ASAMAP
map-name memberOf IETF-Radius-Class
map-value memberOf “CN=VPN_Users,OU=Security Groups,OU=Groups,OU=CompanyXYZHQ,DC=companyxyz,DC=com” ciscovpn
Create the new AAA server(s) called LDAP-Auth2-AD (you can use any name you like). In this case, these are the new 2008 servers. In addition, the communication protocol is determined in this step. For our example, I use LDAP.
aaa-server LDAP-Auth2-AD protocol ldap
Now that we have identified the protocol as LDAP and created a new method, we add each server independently. Just like anything else with the ASA, you must tell it which interface to use in order to communicate with the server, in this case, the (inside) interface. Larger clients might have their authentication servers in a DMZ. After entering the following command, the rest of the commands are sub-commands.
aaa-server LDAP-Auth2-AD (inside) host 172.16.1.91
In this step we tell the ASA where the Base DN is for the AD tree. This is basically the path to the root of the tree.
ldap-base-dn DC=CompanyXYZ,DC=com
ldap-scope subtree
ldap-naming-attribute sAMAccountName
As we continue with the sub commands, we provide a username and password for the ASA to use in order to log into AD and make sure the user exists. I usually let the Windows admin dictate the name. In this example, the username is S_ASA_LDAP. In order to have a successful implementation, you can use the following command to test the LDAP authentication: “test aaa-server authentication LDAP-Auth2-AD host 172.16.1.91 username S_ASA_LDAP password abc123″. If the test fails, I recommend you stop and figure out the AD problems first.
ldap-login-password
ldap-login-dn CN=S_ASA_LDAP,OU=service accounts,OU=Users,OU=CompanyXYZ HQ,DC=CompanyXYZ,DC=com
server-type Microsoft
Still in subcommands, we add our second layer of authentication by telling the ASA t o also check against the LDAP attribute created in step 1.
ldap-attribute-map ASAMAP
The next step is to point the existing production VPN tunnel group to the new authentication servers created earlier. First we enter the VPN group policy section, and then assign the appropriate authentication method. Note, there are other attribute settings for this group, however, we only care about the authentication method.
tunnel-group ciscovpn general-attributes
authentication-server-group LDAP-Auth2-AD
The ASA automatically defers to the default group policy if a user authentication fails and no authentication method is specified, therefore, we need to make sure that the built-in default policy is using the same authentication method. The fiirst step is to change the default tunnel group defaultRAGroup to utilize the same authentication method. Note: If you don’t perform these two steps, the authentication will still work even if you remove the user from the AD group.
tunnel-group DefaultRAGroup general-attributes
authentication-server-group LDAP-Auth2-AD
Finally, the VPN default group policy attributes are basically disabled by changing the simultaneous logins to zero.
group-policy DfltGrpPolicy attributes
vpn-simultaneous-logins 0
Now it is time to test. The ASA has a simple debug command to verify the results.
debug ldap 255
Here is a sample debug of the LDAP authentication. The only part we need for this task is to make sure that the “memberOf” variable is being properly matched. If the match is being performed properly, the rest depends on the users group membership. Below we see a match with the “Users” group.
[20330] memberOf: value = CN=VPN_Users,OU=Security Groups,OU=Groups,OU=CompanyXYZ HQ,DC=compnayxyz,DC=COM
[20330] mapped to IETF-Radius-Class: value = policy_1
In addition, the “debug ldap 255” command is very useful to see the Active Directly Base DN path and what the server is expecting from the ASA. In addition, this debug command can be very useful to find out where the authentication maybe failing. For example, if the login fails, you can see if the issue was related to a bad password, lack of communication with the server, or no group match.
Note: If you forget to disable the logins and authentication for the default VPN group, you will see in the debug that the user is not a member of the VPN group, yet authentication is still successful.
In conclusion, I have included a snippet from the actual running configuration:
ldap attribute-map ASAMAP
map-name memberOf IETF-Radius-Class
map-value memberOf “CN=VPN_Users,OU=Security Groups,OU=Groups,OU=CompanyXYZ HQ,DC=CompanyXYZ,DC=com” ciscovpn
dynamic-access-policy-record DfltAccessPolicy
aaa-server LDAP-Auth2-AD protocol ldap
aaa-server LDAP-Auth2-AD (inside) host 172.16.1.91
ldap-base-dn DC=CompanyXYZ,DC=com
ldap-scope subtree
ldap-naming-attribute sAMAccountName
ldap-login-password *
ldap-login-dn CN=S_ASA_LDAP,OU=service accounts,OU=Users,OU=CompanyXYZ HQ,DC=CompanyXYZ,DC=com
server-type microsoft
ldap-attribute-map ASAMAP
aaa-server LDAP-Auth2-AD (inside) host 172.16.1.92
ldap-base-dn DC=CompanyXYZ,DC=com
ldap-scope subtree
ldap-naming-attribute sAMAccountName
ldap-login-password *
ldap-login-dn CN=S_ASA_LDAP,OU=service accounts,OU=Users,OU=CompanyXYZ HQ,DC=CompanyXYZ,DC=com
server-type microsoft
ldap-attribute-map ASAMAP
Finally, a simple topology diagram:
