[Home]

Summary:ASTERISK-23097: Module res_ldap uses cn for peer username regardless of attribute
Reporter:Stephen Mandolare (smandolare)Labels:
Date Opened:2014-01-03 19:31:50.000-0600Date Closed:2017-12-14 13:02:55.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Resources/res_config_ldap
Versions:11.2.2 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Asterisk 11.2-cert3 built by root @ us-ma-pbx1.us.ieptechnologies.com on a i686 running Linux on 2013-12-27 20:33:59 UTC Linux us-ma-pbx1.us.ieptechnologies.com 2.6.32-431.1.2.0.1.el6.i686 #1 SMP Fri Dec 13 11:45:23 UTC 2013 i686 i686 i386 GNU/Linux CentOS release 6.5 (Final)Attachments:( 0) myDebugLog
( 1) myDebugLog.txt
Description:With the following config in res_ldap.conf in conjuction with Active Directory (Global Catalog in my case)

[_general]
url=ldap://***.com:3268/
protocol=3
basedn=dc=***,dc=com
user=***
pass=***

[sip]
name=sAMAccountName
callerid=cn
auth=sAMAccountName
regexten=ipPhone
mailbox=sAMAccountName
host=astAccountHost
type=astAccountType
md5secret=astAccountPassword
context=astAccountContext
insecure=astAccountInsecure
qualify=astQualify
additionalFilter=(objectClass=user)

The registration successfully queries the directory with the file name = sAMAccountName, but authentication fails with error:

[Jan  3 20:27:43] WARNING[31236]: chan_sip.c:16296 check_auth: username mismatch, have <cn>, digest has <sAMAccountName>

it appears that regardless of attribute mappings, the username of the peer is always set to the LDAP cn.

*Workaround:*

To work around this the Auth Username must be set in the client to the LDAP cn, this works but appears "clunky" to users.
Comments:By: Rusty Newton (rnewton) 2014-01-07 17:52:05.408-0600

@Stephen, can you attach a debug log following the instructions here: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Along with making sure it has DEBUG messages, make sure "sip set debug on" is enabled so we can see the registration and the relevant messages.
By: Stephen Mandolare (smandolare) 2014-01-07 21:25:16.681-0600

Debug Information
By: Rusty Newton (rnewton) 2014-01-27 12:55:59.030-0600

re-attaching the debug with .txt extension for ease of viewing without downloading.
By: Rusty Newton (rnewton) 2014-01-27 13:00:30.600-0600

I don't have a LDAP database setup to easily reproduce this, but looking at your config and debug, it looks like a bug to me. That is assuming Asterisk has been reloaded completely and has parsed the configuration shown in the description.

I'm going to open this issue up. Note that res_config_ldap is under extended support and is therefore supported by the broader development community, response time will reflect that. Thanks for the report and debug.
By: Reto Rayen (John222) 2016-04-18 10:06:03.228-0500

Hi guys

I'm experiencing the same issue in version 13.6.0. The workaround is not a accepting solution. Because especially in Active directory environments it's common to use the distinguished name to reference to objects in ldap. So changing the cn seems to be a bad workaround.

By: Sean Bright (seanbright) 2017-02-17 09:09:00.142-0600

This is working fine for me with Asterisk 13 git. Can you try with the latest Asterisk 13 release and let us know if the problem persists? If so, please upload a fresh batch of debug logs for us to review.