ASA VPN LDAP Authentication + Group Membership Verification
!
!
!
!
!
!
!
!
!
!
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.
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.
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).
I recommend building a test VPN group in parallel, test the authentication and then
change the production group’s authentication servers.
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.
use this command on a domain controller to find the full path of the ASAuser account:
dsquery user -samid ASAUser
Your login DN has to contain the complete location of the user ID you are using.
For example CN=ASAUser,OU=ServiceAccounts,DC=cisco,DC=com
!
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
to 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
!
tunnel-group ciscovpn general-attributes
authentication-server-group LDAP-Auth2-AD
tunnel-group DefaultRAGroup general-attributes
authentication-server-group LDAP-Auth2-AD
group-policy DfltGrpPolicy attributes
vpn-simultaneous-logins 0
