question on ldap_escape_func in rlm_ldap.c

Qin Zhen qin.zhen at pacific.net.sg
Wed Dec 7 15:08:45 CET 2005


Hi,
thanks Nicolas. sorry to trouble u, but i am still not so clear abt the 
lastest freeradius's behaviour.
suppose there is an username 'james',
when i trys to login with username 'james*', ldap_escape_fun acctually 
converts it into 'james\2a\2a\2a\2a\2a\2a...', but the radius debug mode 
still shows
Debug: rlm_ldap:performing search in dc=sg, o=company, with filter 
(&objectclass=radiusprofile)(userlogin=james))
that measn ldap still search based on filter 'userlogin=james' and ignores 
those '\2a\2a\2a' followed, and hence it finds the username 'james' from 
ldap and allows the user to login.
is it the way lastest freeradius supposed to be? or there's anyth wrong with 
my configuration?
if user james can use 'james*' or 'james\\' to login as usual, isnt it 
unsecure?
thanks really a loooooooot!

----- Original Message ----- 
From: "Nicolas Baradakis" <nbk at sitadelle.com>
To: "FreeRadius users mailing list" <freeradius-users at lists.freeradius.org>
Sent: Wednesday, December 07, 2005 9:17 PM
Subject: Re: question on ldap_escape_func in rlm_ldap.c


> Qin Zhen wrote:
>
>> so in lastest version (1.0.5), a username 'jam\' will be converted into
>> 'jam\5c' and ldapsearch will be based on 'jam\5c' right? so this username
>> is supposed not to be found in ldap in this case?
>> but how come in my server, the ldapsearch will base on 'jam' and those
>> invalid charactors r just simply eliminated? scratching head...pls
>> assist..thanks so much
>
> That's what is said in http://www.ietf.org/rfc/rfc2254.txt
>
> <<<<<
>   If a value should contain any of the following characters
>
>           Character       ASCII value
>           ---------------------------
>           *               0x2a
>           (               0x28
>           )               0x29
>           \               0x5c
>           NUL             0x00
>
>   the character must be encoded as the backslash '\' character (ASCII
>   0x5c) followed by the two hexadecimal digits representing the ASCII
>   value of the encoded character. The case of the two hexadecimal
>   digits is not significant.
>>>>>>
>
> -- 
> Nicolas Baradakis
>
> -
> List info/subscribe/unsubscribe? See 
> http://www.freeradius.org/list/users.html
> 




More information about the Freeradius-Users mailing list