Using Dynamic Attribute Maps to change Relative-Distinguished-Name on IOS devices

Atri Basu · ‎08-03-2011

Introduction
Core Issue
Resolution
Sample Configuration

Introduction

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.

Core Issue

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.

.

Resolution

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:

LDAP Attribute	Format	AAA Attribute
airespaceBwDataBurstContract	Ulong	bsn- data-bandwidth-burst-contr
userPassword	String	password
airespaceBwRealBurstContract	Ulong	bsn-realtime-bandwidth-burst-c
employeeType	String	employee-type
airespaceServiceType	Ulong	service-type
airespaceACLName	String	bsn-acl-name
priv-lvl	Ulong	priv-lvl
memberOf	String DN	supplicant-group
cn	String	username
airespaceDSCP	Ulong	bsn-dscp
policyTag	String	tag-name
airespaceQOSLevel	Ulong	bsn-qos-level
airespace8021PType	Ulong	bsn-8021p-type
airespaceBwRealAveContract	Ulong	bsn-realtime-bandwidth-average
airespaceVlanInterfaceName	String	bsn-vlan-interface-name
airespaceVapId	Ulong	bsn-wlan-id
airespaceBwDataAveContract	Ulong	bsn-data-bandwidth-average-con
sAMAccountName	String	sam-account-name
meetingContactInfo	String	contact-info
telephoneNumber	String	telephone-number

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

*Jul 24 11:04:50.568: LDAP: Ldap Search Req sent

ld 1054176200

base dn DC=csco,DC=com

scope 2

filter (&(objectclass=*)(cn=RAJ Kumar))ldap_req_encode

put_filter "(&(objectclass=person)(cn=RAJ Kumar))"

put_filter: AND

put_filter_list "(objectclass=person)(cn=RAJ Kumar)"

put_filter "(objectclass=person)"

put_filter: simple

put_filter "(cn=RAJ Kumar)"

put_filter: simple

Doing socket write

*Jul 24 11:04:50.568: LDAP: LDAP search request sent successfully (reqid:13)

In order to change this behavior and force it to use the sAMAccountName, we will need to create the following dynamic attribute map first:

ldap attribute map username

map type sAMAccountName username

Once this attribute map has been defined map this attribute map to the aaa-server group you want to use using the "attribute map <dynamic-attribute-map-name>" command.

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.

Sample Configuration

To define the dynamic attribute map:

ldap attribute map <dyn-attribute-map-name>

map type sAMAccountName username

To define the aaa server group:

aaa group server ldap <server-group-name>

server <server-name>

To define the server:

ldap server <server-name>
ipv4 <host-address>

attribute map <dyn-attribute-map-name>

bind authentication root-dn <complete-dn-root-user> password <root-user-pwd>

base-dn <complete-dn-serach-base>

To define the list of authentication methods, the name is used to associate the authentication method with a feature.

aaa authentication login <name> group <server-group-name>

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:

ldap server ss-ldap

ipv4 4.4.3.6

attribute map ad-map

transport port 3268

bind authenticate root-dn CN=abcd,OU=Employees,OU=Cisco Users,DC=cisco,DC=com password blabla

base-dn DC=cisco,DC=com

authentication bind-first

ldap attribute-map ad-map

map type sAMAccountName username

Then you're likely to see a failure in your authentication attempt. The error message you will see is "Invalid credentials, Result code =49". The logs will look something like the logs below:

Oct 4 13:03:08.503: LDAP: LDAP: Queuing AAA request 0 for processing

Oct 4 13:03:08.503: LDAP: Received queue event, new AAA request

Oct 4 13:03:08.503: LDAP: LDAP authentication request

Oct 4 13:03:08.503: LDAP: Attempting first next available LDAP server

Oct 4 13:03:08.503: LDAP: Got next LDAP server :ss-ldap

Oct 4 13:03:08.503: LDAP: First Task: Send bind req

Oct 4 13:03:08.503: LDAP: Authentication policy: bind-first

Oct 4 13:03:08.503: LDAP: Dynamic map configured

Oct 4 13:03:08.503: LDAP: Dynamic map found for aaa type=username

Oct 4 13:03:08.503: LDAP: Bind: User-DN=sAMAccountName=abcd,DC=cisco,DC=com

ldap_req_encode

Doing socket write

Oct 4 13:03:08.503: LDAP: LDAP bind request sent successfully (reqid=36)

Oct 4 13:03:08.503: LDAP: Sent the LDAP request to server

Oct 4 13:03:08.951: LDAP: Received socket event

Oct 4 13:03:08.951: LDAP: Checking the conn status

Oct 4 13:03:08.951: LDAP: Socket read event socket=0

Oct 4 13:03:08.951: LDAP: Found socket ctx

Oct 4 13:03:08.951: LDAP: Receive event: read=1, errno=9 (Bad file number)

Oct 4 13:03:08.951: LDAP: Passing the client ctx=314BA6ECldap_result

wait4msg (timeout 0 sec, 1 usec)

ldap_select_fd_wait (select)

ldap_read_activity lc 0x296EA104

Doing socket read

LDAP-TCP:Bytes read = 109

ldap_match_request succeeded for msgid 36 h 0

changing lr 0x300519E0 to COMPLETE as no continuations

removing request 0x300519E0 from list as lm 0x296C5170 all 0

ldap_msgfree

Oct 4 13:03:08.951: LDAP:LDAP Messages to be processed: 1

Oct 4 13:03:08.951: LDAP: LDAP Message type: 97

Oct 4 13:03:08.951: LDAP: Got ldap transaction context from reqid 36ldap_parse_result

Oct 4 13:03:08.951: LDAP: resultCode: 49 (Invalid credentials)

Oct 4 13:03:08.951: LDAP: Received Bind Responseldap_parse_result ldap_err2string

Oct 4 13:03:08.951: LDAP: Ldap Result Msg: FAILED:Invalid credentials, Result code =49

Oct 4 13:03:08.951: LDAP: LDAP Bind operation result : failed

Oct 4 13:03:08.951: LDAP: Restoring root bind status of the connection

Oct 4 13:03:08.951: LDAP: Performing Root-Dn bind operationldap_req_encode

Doing socket write

Oct 4 13:03:08.951: LDAP: Root Bind on CN=abcd,DC=cisco,DC=com

initiated.ldap_msgfree

Oct 4 13:03:08.951: LDAP: Closing transaction and reporting error to AAA

Oct 4 13:03:08.951: LDAP: Transaction context removed from list [ldap reqid=36]

Oct 4 13:03:08.951: LDAP: Notifying AAA: REQUEST FAILED

Oct 4 13:03:08.951: LDAP: Received socket event

Oct 4 13:03:09.491: LDAP: Received socket event

Oct 4 13:03:09.491: LDAP: Checking the conn status

Oct 4 13:03:09.491: LDAP: Socket read event socket=0

Oct 4 13:03:09.491: LDAP: Found socket ctx

Oct 4 13:03:09.495: LDAP: Receive event: read=1, errno=9 (Bad file number)

Oct 4 13:03:09.495: LDAP: Passing the client ctx=314BA6ECldap_result

wait4msg (timeout 0 sec, 1 usec)

ldap_select_fd_wait (select)

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

ldap_msgfree

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]

ldap_msgfree

ldap_result

wait4msg (timeout 0 sec, 1 usec)

ldap_select_fd_wait (select)

ldap_err2string

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.

Related Information

Devashree Chakrabarti · ‎08-11-2011

Doc is good.