Hi We have been running Freeradius with 802.1x (peap-mschapv2) against edirectory authentication for a number of years. Currently running on sles 11 sp3 - freeradius-server-2.2.5-11.1 - but I have tested with older freeradius package that ships with SLES 11 SP3. Setup similar to https://www.novell.com/support/kb/doc.php?id=7009035 We have recently noticed that authentication is failing when users are using the £ sign character in their password (and also § found on macbook keyboards) - it seems to work fine with other characters - !"$%^123&*()_+-=[]{};'#:@~,./<>?\| for example. What I see in logs is Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/inner-tunnel +group authenticate { [eap] Request found, released from the list [eap] EAP/mschapv2 [eap] processing type mschapv2 [mschapv2] # Executing group from file /etc/raddb/sites-enabled/inner-tunnel [mschapv2] +group MS-CHAP { [mschap] Creating challenge hash with username: lsxtestaas@lshtm.ac.uk [mschap] Client is using MS-CHAPv2 for lsxtestaas@lshtm.ac.uk, we need NT-Password [mschap] FAILED: MS-CHAP2-Response is incorrect ++[mschap] = reject However as soon as I remove £ sign auth is working fine. Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/inner-tunnel +group authenticate { [eap] Request found, released from the list [eap] EAP/mschapv2 [eap] processing type mschapv2 [eap] Freeing handler ++[eap] = ok +} # group authenticate = ok Login OK: [lsxtestaas@lshtm.ac.uk] (from client aruba port 0 cli C48508CCE903 via TLS tunnel) It also works if you use £ rather than just the £ within the password when authing from a supplicant (tested with android & Windows)- suggesting some kind of encoding issue??. The cleartext password returned from eDirectory seems fine. [ldap] Added the eDirectory password ****£**** in check items as Cleartext-Password [ldap] No default NMAS login sequence [ldap] looking for check items in directory... [ldap] looking for reply items in directory... [ldap] ldap_release_conn: Release Id: 0 ++[ldap] = ok Any thoughts would be appreciated. Thanks Mark
On Feb 11, 2015, at 8:46 AM, Mark Keyte <Mark.Keyte@lshtm.ac.uk> wrote:
We have recently noticed that authentication is failing when users are using the £ sign character in their password (and also § found on macbook keyboards) - it seems to work fine with other characters - !"$%^123&*()_+-=[]{};'#:@~,./<>?\| for example.
i.e. ASCII. The problem is a hard one to solve. The MS-CHAP standards don’t actually say what format the passwords should be in. So implementations have chosen different paths… not all of which are compatible.
However as soon as I remove £ sign auth is working fine.
Exactly.
It also works if you use £ rather than just the £ within the password when authing from a supplicant (tested with android & Windows)- suggesting some kind of encoding issue??.
It’s an encoding issue. FreeRADIUS tries to do the right thing, and has been tested with every supplicant out there. So it *should* work.
Any thoughts would be appreciated.
Post some sample passwords to the list. The one that fails, and the one that works. As *hex* strings. Don’t just cut & paste the password. Mailers *will* modify the password. They won’t modify a hex string. I’ll take a look and see if there’s an issue which can be fixed. Alan DeKok.
Hi, On Wed, Feb 11, 2015 at 4:00 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Feb 11, 2015, at 8:46 AM, Mark Keyte <Mark.Keyte@lshtm.ac.uk> wrote:
We have recently noticed that authentication is failing when users are using the £ sign character in their password (and also § found on macbook keyboards) - it seems to work fine with other characters - !"$%^123&*()_+-=[]{};'#:@~,./<>?\| for example.
i.e. ASCII.
The problem is a hard one to solve. The MS-CHAP standards don’t actually say what format the passwords should be in. So implementations have chosen different paths… not all of which are compatible.
I'd also suggest to try FreeRadius V3 - see related email thread: http://freeradius.1045715.n5.nabble.com/Plans-for-the-next-few-releases-td57... Regards, Isaac B
On 11 Feb 2015, at 10:11, Isaac Boukris <iboukris@gmail.com> wrote:
Hi,
On Wed, Feb 11, 2015 at 4:00 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Feb 11, 2015, at 8:46 AM, Mark Keyte <Mark.Keyte@lshtm.ac.uk> wrote:
We have recently noticed that authentication is failing when users are using the £ sign character in their password (and also § found on macbook keyboards) - it seems to work fine with other characters - !"$%^123&*()_+-=[]{};'#:@~,./<>?\| for example.
i.e. ASCII.
The problem is a hard one to solve. The MS-CHAP standards don’t actually say what format the passwords should be in. So implementations have chosen different paths… not all of which are compatible.
I'd also suggest to try FreeRadius V3 - see related email thread: http://freeradius.1045715.n5.nabble.com/Plans-for-the-next-few-releases-td57...
In ISO/IEC 8859-1 (latin-1), £ is 0xa3, in UTF8 it's a two byte encoding 0xc2 0xa3. Same issue with § (0xa7) which will become 0xc2 0xa7 in UTF8. I specifically remember an issue with the OSX supplicant not using the correct encoding (Olivier B you reported that right?). OP can you confirm this is all platforms and not just OSX? If it's just OSX try using TTLS-PAP instead I seem to remember that working. In any case you'll likely have issues with any char > decimal 127. I know for v3 we added proper UTF8 -> UTF16 conversion (which is what MSCHAPv2 required), this may have exposed the issue. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
In ISO/IEC 8859-1 (latin-1), £ is 0xa3, in UTF8 it's a two byte encoding 0xc2 0xa3. Same issue with § (0xa7) which will become 0xc2 0xa7 in UTF8.
I meant to reply to this earlier. The UTF8 encoding also means that when it is converted to ASCII from its raw byte state, this is the result: 0xc2 0xa7 = £ That's why adding the  to the front of the pound sign will make it generate the correct hash for the password. Unfortunately, in a previous life, we had lots of fun with this on Windows after passwords stored in the registry and in INI files (in ANSI/ASCII format) caused lots of issues when read into a UTF-8 stream without proper conversion (where it was assumed that all the standard ASCII characters when encountered would directly translate to UTF-8, which they of course don't). :-/ Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
participants (5)
-
Alan DeKok -
Arran Cudbard-Bell -
Isaac Boukris -
Mark Keyte -
Stefan Paetow