ASA VPN LDAP Authentication with Group Membership Verification

NetCraftsmen®

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:

Leave a Reply

 

Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.

 

Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.

 

John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.