are there any characters not allowed in a password used withLDAP "bind as user"?

mark.leese at stfc.ac.uk mark.leese at stfc.ac.uk
Mon Oct 25 13:55:26 CEST 2010


> -----Original Message-----
> From: freeradius-users-
> bounces+mark.leese=stfc.ac.uk at lists.freeradius.org [mailto:freeradius-
> users-bounces+mark.leese=stfc.ac.uk at lists.freeradius.org] On Behalf Of
> Phil Mayers
> Sent: 21 October 2010 22:44
> To: freeradius-users at lists.freeradius.org
> Subject: Re: are there any characters not allowed in a password used
> withLDAP "bind as user"?
> 
> On 10/21/2010 10:27 PM, Phil Mayers wrote:
> > On 10/21/2010 08:52 PM, mark.leese at stfc.ac.uk wrote:
> >
> >>
> >> I don't know whether the problem lies with me (for allowing a
> backslash
> >> in the password in the first place) the NAS for appearing to
> 'escape'
> >> the backslash (with a backslash)
> >
> > rlm_ldap accesses the raw string value of the request->password AVP,
> so
> > it shouldn't be anything inside FreeRadius.
> >
> > What is the NAS?
> 
> Hmm. I've just tried this locally and I don't seem to get the same
> results as you; I see the backslash doubled in the initial FreeRadius
> dump (as expected - FreeRadius writes the debug output as you would
> write config files):
> 
> rad_recv: Access-Request packet from host 127.0.0.1 port 53973, id=123,
> length=44
> 	User-Name = "pjm3"
> 	User-Password = "foo\\bar"
> 
> ...and I then see:
> 
> [ldap] login attempt by "pjm3" with password "foo\bar"
> [ldap] user DN: CN=pjm3,...
>    [ldap] (re)connect to icads1.ic.ac.uk:389, authentication 1
>    [ldap] bind as CN=pjm3,.../foo\bar to icads1.ic.ac.uk:389
>    [ldap] waiting for bind result ...
> 
> ...note the backslash just appears singly here; the rlm_ldap debugging
> output code writes the raw value out. You however have two backslashes
> by this point, so it must be your rlm_perl module. Can you prevent the
> perl module touching the User-Password attribute, and see if that
> helps?
> -

Hi Phil,

The NAS is Trapeze wireless kit. The username and password come from an SSL encrypted captive portal web page. I'm running freeradius-2.1.3-1 on Linux.

It's really interesting that you get different debug output to me. The Perl script doesn't do anything with the User-Password attribute, and I've updated it so that it doesn't even take the hash of Access-Request RADIUS attributes - the top of the Perl script now reads...

    use vars qw(%RAD_REPLY %RAD_CHECK);

...i.e. %RAD_REQUEST isn't included.

Unfortunately, I still get the same debug output, with two backslashes appearing in all references to the password.

Is there a way to test this with radtest or radclient, and I could try on a development box without even using the Perl script? Unfortunately, whatever option I've tried with radtest and radclient so far has resulted in two backslashes appearing in the password or none. For example, none of these produce the required result...

    radtest bill 'w[)xg=\k2' 127.0.0.1 10 s£cret
    radtest bill 'w[)xg=\\k2' 127.0.0.1 10 s£cret
    radtest bill "w[)xg=\k2" 127.0.0.1 10 s£cret
    radtest bill "w[)xg=\\k2" 127.0.0.1 10 s£cret
    radtest bill w\[\)xg=\\k2 127.0.0.1 10 s£cret
    etc.

Cheers,

Mark.

-- 
Scanned by iCritical.




More information about the Freeradius-Users mailing list