On May 2, 2016, at 1:15 PM, Rudolf Mayer <rmayer@sba-research.org> wrote:
It seems that somewhere along the lines the characters get scrambled.
The first thing is to figure out *where* it gets scrambled.
*) Trying with the Cisco ASA radius test client, I see in the freeradius logs things like
Auth: Login incorrect: [blabla/D$D4?p?591924] (from client xxx port y)
Something is mangling the password.
(the ? where initially ß)
*) And with the radtest tool:
radtest blabla 'ßß' xxx.yyy.zzz.aaa secret => Auth: Login incorrect: [blabla/<C3>?<C3>?] (from client xxx port 18120)
Which is different.. And... as always, READ THE DEBUG LOG. Really.. it's not hard. It tells you what the server is going, and why. radtest doesn't modify its inputs. If you give it random nonsense in the password, it sends that to the server.
Is there any specific restriction on characters that are allowed? ß is part of the ISO/IEC 8859-1, so it doesn't actually require unicode or the likes.
ISO 8859 is not UTF-8. i.e. You're putting wrong things into the password field. Now, FreeRADIUS being well designed.. it *hopes* that the password is UTF-8. But if it isn't UTF-8, FreeRADIUS doesn't mangle it.
I would also rule out any issues with my LDAP backend, as the passwords work fine when doing authentication directly via LDAP PAM, and via various other applications using an Apache module.
The Cisco ASA radius test client is mangling the password. If you want to know what FreeRADIUS is doing, read the debug log as suggested in the FAQ, "man" page, web pages, and daily on this list. But the short answer is don't use ISO 8859. Use UTF-8. It's been required in RFC 2865 for over 15 years now. Alan DeKok.