-----Original Message----- From: freeradius-users- bounces+mark.leese=stfc.ac.uk@lists.freeradius.org [mailto:freeradius- users-bounces+mark.leese=stfc.ac.uk@lists.freeradius.org] On Behalf Of Phil Mayers Sent: 21 October 2010 22:44 To: freeradius-users@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@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.