On 16 Jul 2013, at 10:29, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 16 Jul 2013, at 10:28, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 16 Jul 2013, at 08:58, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
here's yet another thing which caused spurious authentication failures; luckily I was accidently in debug mode looking for something else when I found the cause for some failed auth:
+++- entering policy redundant {...} [sql-imap-hash] expand: %{User-Name} -> pgloden [sql-imap-hash] sql_set_user escaped user --> 'pgloden' rlm_sql (sql-imap-hash): Reserving sql socket id: 7 [sql-imap-hash] expand: (SELECT id, username, attribute, value, op FROM check_imap_ssha1 WHERE username='%{SQL-User-Name}') -> (SELECT id, username, attribute, value, op FROM check_imap_ssha1 WHERE username='pgloden') rlm_sql_mysql: query: (SELECT id, username, attribute, value, op FROM check_imap_ssha1 WHERE username='pgloden') rlm_sql: Failed to create the pair: Non-hex characters at QX rlm_sql (sql-imap-hash): Error getting data from database [sql-imap-hash] SQL query error; rejecting user
The query works just fine and returns a base64-encoded SSHA1 hash of a user's password. The base64 blob happens to start with the two characters "0X" (and then continues with QX, which is in the error message).
It seems like the query response parser tries to be overly clever and thinks that anything starting with 0X is a hex number and needs decoding. This, of course, fails. Needsless to say that the schema doesn't suggest an integer at all, it's a varchar(168).
The workaround right now for us is to set the hashed password, see if it happens to start with 0X, and if so, try with a different salt.
At a guess, i'd say the attribute you were creating was of type OCTETS, in which case the above is the correct behaviour. Can you double check that the type of the attribute is string, and not octets.
Nearly all string to value conversions (all drivers produce values as strings) go through pairparsevalue. String attributes will *not* be treated as hex strings by pairparsevalue, only raw attributes are.
Looking at src/lib/valuepair.c (pairparsevalue), writing to a destination attribute of type octets would describe exactly when you're experiencing.
*that Even. Ug pre-coffee. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team