Using your Active Directory for VPN authentication on ASA

Using Active Directory as a LDAP server with ASA

For a long time the only way to use Active Directory (AD) for VPN authentication and authorization was to use a RADIUS server such as Cisco ACS that could use AD as an external database. With the addition of LDAP support on ASA, this changed and it was possible to authenticate directly to AD. Configuring this is sometimes cumbersome. In this two part series, I will discuss LDAP configuration on ASA for authentication and authorization of VPN sessions.

When adding AD as a LDAP server on ASA, it is important to remember that objects need to be reference by their Distinguished Name (DN). If you do not know the DN and other LDAP attribute names which are discussed here, then the best way to find them is by connecting to your AD using a GUI based LDAP browser and looking at your account.

AAA servers on ASA are grouped by protocols. Multiple servers using a protocol can be defined under a single group. To define the LDAP server, you create a server group and then add the server in the group using the following commands:

aaa-server group-tag protocol ldap

aaa-server group-tag [if_name] host {server_ip_address | server_name}

The second command will bring you to the aaa-server-host configuration mode. In this mode, you need to define the parameters that ASA will use to communicate with the LDAP server. You will need to configure the following parameters at the least:

  • ldap-login-dn-The Distinguished Name (DN) for the admin account or any account in the directory which can login, search and retrieve account information from the directory. ASA will login to the directory using this account to search for the user. Since AD is being used, you can specify the username in the UPN format also.
  • ldap-login-password-The password of the account configured as the ldap-login-dn
  • ldap-base-dn-This specifies the starting point for the user search. This can be the base dn of the directory itself. I highly recommend not using the root of the directory as the base DN if your AD tree is very big.
  • ldap-naming-attribute-This is the relative DN which uniquely identifies a user account in the directory. Microsoft Active Directory uses sAMAccountName. Other common naming attributes are CN and UID. In AD various other attributes are available. The choice of the attribute will determine what "username" will be used to authenticate. Generally sAMAccountName is a pretty safe option.
  • ldap-scope-This defines whether ASA will look at the base DN level or go below the base DN level to search for the user accounts.
  • server-port-This defines the port the server is listening on. By default port 389 is used.

A sample configuration is shown below:

aaa-server myservers protocol ldap

aaa-server myservers (inside) host 192.168.1.10

 ldap-base-dn dc=myAD,dc=com

 ldap-scope subtree

 ldap-naming-attribute sAMAccountName

 ldap-login-password test

 ldap-login-dn cn=vivek,cn=Users,dc=myAD,dc=com

When ASA needs to authenticate a user to the configured LDAP server, it first tries to login using the login DN provided. After successful login to the LDAP server, ASA sends a search query for the username provided by the VPN user. This search query is created based on the naming attribute provided in the configuration. LDAP replies to the query with the complete DN of the user. At this stage ASA sends a second login attempt to the LDAP server. In this attempt, ASA tries to login to the LDAP server using the VPN user's full DN and password provided by the user. A successful login to the LDAP server will indicate that the credentials provided by the VPN user are correct and the tunnel negotiation will move to the Phase 2.

If your configuration does not work correctly, then you can use level 255 ldap debugs on ASA (debug ldap 255) and the following three-step approach to find the problem area:

  1. First look for a successful authentication of the admin/login account. If you get a "Failed to bind as administrator" error, the DN or the password of the account is incorrect.
  2. Second, look for the LDAP search sent by ASA. If you get a "User not found" error, then your naming attribute, base DN or scope is incorrect. To further isolate the problem, you can use the root of the directory as the base DN.
  3. If the search query resulted in the DN of the VPN user, the LDAP configuration is correct and the VPN user entered an incorrect password.

Though this article focuses on Active Directory as a LDAP server, the information can be easily applied to any other LDAP server without any change. In the next part of the series, we will look at authorization of VPN users using LDAP attributes and attribute maps.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Now read: Getting grounded in IoT