Weird problem with some special characters in passwords
Hi all, we have difficulties with a freeradius server authenticating against an LDAP backend. We use the freeradius server for eduroam and also for a few custom applications. We have tried to force the password to UTF-8 or ISO-8859-1 and other encodings in the custom applications, to no avail (we have no way to force this in the securew2 client for eduroam anyway). This works very well most of the time, but fails if the password contains seleCompanyd special charaCompanyrs, like ° (degree) or § (paragraph), for example. We are short of ideas as to what to try next.... Any pointers would be greatly appreciated..... Thanks a lot in advance Frank Weis -------------------------8<----------------------------- +- entering group LDAP3 {...} [ldap3] login attempt by "blabla" with password "qwertz��" [ldap3] user DN: cn=blabla,ou=Company,ou=Persons,o=IDENTITIES rlm_ldap: (re)connect to idm3.iamlocal.blabla.com:636, authentication 1 rlm_ldap: setting TLS mode to 1 rlm_ldap: setting TLS CACert File to //etc/raddb/certs/iam_ca.pem rlm_ldap: bind as cn=blabla,ou=Company,ou=Persons,o=IDENTITIES/qwertz�� to idm3.iamlocal.blabla.com:636 rlm_ldap: waiting for bind result ... rlm_ldap: cn=blabla,ou=Company,ou=Persons,o=IDENTITIES bind to idm3.iamlocal.blabla.com:636 failed Internal (implementation specific) error [ldap3] NDS error: insufficient buffer (-649) [ldap3] ldap_connect() failed ++[ldap3] returns fail A user with a more 'gentle' password succeeds: +- entering group LDAP3 {...} [ldap3] login attempt by "blabla2" with password "bla!!bla" [ldap3] user DN: cn=blabla2,ou=Company,ou=Persons,o=IDENTITIES rlm_ldap: (re)connect to idm3.iamlocal.blabla.com:636, authentication 1 rlm_ldap: setting TLS mode to 1 rlm_ldap: setting TLS CACert File to //etc/raddb/certs/iam_ca.pem rlm_ldap: bind as cn=blabla2,ou=Company,ou=Persons,o=IDENTITIES/bla!!bla to idm3.iamlocal.blabla.com:636 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful [ldap3] user blabla2 authenticated succesfully ++[ldap3] returns ok When I try an ldapsearch to the LDAP-backend on the commandline of the radius server, it works too. When I try a 'radtest' on the commandline of the freeradius server, it succeeds also: radtest blabla qwertz°° 127.0.0.1 1234 testing123 Sending Access-Request of id 129 to 127.0.0.1 port 1812 User-Name = "blabla" User-Password = "qwertz°°" NAS-IP-Address = 1.2.3.4 NAS-Port = 1234 rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=129, length=20 (radiusd -X says this: +- entering group LDAP3 {...} [ldap3] login attempt by "blabla" with password "qwertz°°" [ldap3] user DN: cn=blabla,ou=Company,ou=Persons,o=IDENTITIES rlm_ldap: (re)connect to idm3.iamlocal.blabla.com:636, authentication 1 rlm_ldap: setting TLS mode to 1 rlm_ldap: setting TLS CACert File to //etc/raddb/certs/iam_ca.pem rlm_ldap: bind as cn=blabla,ou=Company,ou=Persons,o=IDENTITIES/qwertz°° to idm3.iamlocal.blabla.com:636 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful [ldap3] user blabla authenticated succesfully ++[ldap3] returns ok -- _______________________________________________ Centre de Technologie de l'Education 29 avenue John F. Kennedy L-1855 Luxembourg-Kirchberg email: Frank.Weis@Company.lu tél.: +352 247-85973 fax: +352 333797 _______________________________________________
Frank Weis wrote:
We have tried to force the password to UTF-8 or ISO-8859-1 and other encodings in the custom applications, to no avail (we have no way to force this in the securew2 client for eduroam anyway).
I think this issue is being addressed in SecureW2.
This works very well most of the time, but fails if the password contains seleCompanyd special charaCompanyrs, like ° (degree) or § (paragraph), for example.
The contents of the password are... whatever the client determines them to be. This is known to be wrong, and not inter-operable.
We are short of ideas as to what to try next.... Any pointers would be greatly appreciated.....
FreeRADIUS just receives the information in the password from the client. It takes care to not mangle it too much.
+- entering group LDAP3 {...} [ldap3] login attempt by "blabla" with password "qwertz��"
If that's what the client application sent, there's little you can do to FreeRADIUS to fix it. You can fix the client, or (somehow) re-write the "bad" password into a "good" password in FreeRADIUS. Given that the mapping of "good" characters to "bad" characters is nearly infinite, and client dependent, re-writing it in FreeRADIUS isn't easy. Alan DeKok.
participants (2)
-
Alan DeKok -
Frank Weis