This document provides a sample configuration on how to use LDAP authproxy on IOS headends and change the default Relative-Distinguished-Name(RDN) to be the sAMAccountName.
Most users using the MS AD with LDAP, usually define their RDN to be the sAMAccountName. If you are using auth-proxy and an ASA as a headend for your VPN clients, this can be easily fixed by eithe defining the AD server-type when defining the aaa-server or by using the "ldap-naming-attribute" command. On the IOS however neither of these two options are available. Instead by default the IOS used the full CN defined in the AD for user-name authenctication.
Although IOS devices do not support the above methods of modifying the RDN, you can use dynamic attribute maps on IOS to achieve something similar. If you run the command "show ldap attribute" on the IOS headend, you'll see the following output:
As you can see from the attribute highlighted in red, the IOS Network-Access-Device(NAD) uses this mapping for both authentication requests as well as once the response is received. Without any user-defined attribute-maps, a basic LDAP configuration on the NAD, when the request is sent out you see the following log message:
*Jul 24 11:04:50.568: LDAP: Check the default map for aaa type=username
In order to make this entire process easier the enhancment request #CSCtr45874 has been filed. If this is implemented it will allow users to identify what kind of LDAP server is being used and therefor automatically change some of these default maps to reflect the values used by that particular server.
Issues with using "authentication bind-first" with user-defined attribute-maps:
In an LDAP deployment, search operation is performed first and bind operation is performed later. This operation is performed because, if the password attribute is returned as part of the search operation, then password verification can be done locally on the LDAP client and there is no need for an extra bind operation. If the password attribute is not returned, a bind operation can be performed later. Another advantage of performing the search operation first and bind operation later is that the distinguished name (DN) received in the search result can be used as the user DN instead of forming a DN by prefixing the username (cn attribute) with base DN.
When this command is used along with user-defined attribute map which changes what the username attribute points to, there can be issues. For example if you use the following configuration:
Oct 4 13:03:09.495: LDAP: Passing the client ctx=314BA6ECldap_result
wait4msg (timeout 0 sec, 1 usec)
ldap_read_activity lc 0x296EA104
Doing socket read
LDAP-TCP:Bytes read= 22
ldap_match_request succeeded for msgid 37 h 0
changing lr 0x300519E0 to COMPLETE as no continuations
removing request 0x300519E0 from list as lm 0x296C5170 all 0
Oct 4 13:03:09.495: LDAP: LDAP Messages to be processed: 1
Oct 4 13:03:09.495: LDAP: LDAP Message type: 97
Oct 4 13:03:09.495: LDAP: Got ldap transaction context from reqid 37ldap_parse_result
Oct 4 13:03:09.495: LDAP: resultCode: 0 (Success)P: Received Bind Response
Oct 4 13:03:09.495: LDAP: Received Root Bind Response ldap_parse_result
Oct 4 13:03:09.495: LDAP: Ldap Result Msg: SUCCESS, Result code =0
Oct 4 13:03:09.495: LDAP: Root DN bind Successful on:CN=abcd,DC=cisco,DC=com
Oct 4 13:03:09.495: LDAP: Transaction context removed from list [ldap reqid=37]
wait4msg (timeout 0 sec, 1 usec)
Oct 4 13:03:09.495: LDAP: Finished processing ldap msg, Result:Success
Oct 4 13:03:09.495: LDAP: Received socket event
The lines highlighted in red indicate what's going wrong with the initial bind before authentication. If you remove the command "authentication bind-first" from the above configuration everything will work properly.