Le 28/11/2014 14:41, Alan DeKok a écrit :
On Nov 28, 2014, at 3:06 AM, Philippe MARASSE <philippe.marasse@ch-poitiers.fr> wrote:
So I'm wondering about the expected behavior : actually sql group processing stops after the first group, although the check item does not match (in my case Huntgroup does not match). Is this expected ? No. It should match and stop, or not match and continue. Perfect ! So I've not misunderstood :-).
I've just tested the patch proposed by Arran. Unfortunately, this time it does not continue after trying to get user check attributes : (0) sql: EXPAND %{User-Name} (0) sql: --> 90fba6e49245 (0) sql: SQL-User-Name set to '90fba6e49245' rlm_sql (sql): Reserved connection (4) (0) sql: EXPAND SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id (0) sql: --> SELECT id, username, attribute, value, op FROM radcheck WHERE username = '90fba6e49245' ORDER BY id rlm_sql (sql): Executing query: 'SELECT id, username, attribute, value, op FROM radcheck WHERE username = '90fba6e49245' ORDER BY id' ERROR: (0) sql: SQL query error getting check attributes rlm_sql (sql): Released connection (4) (0) [sql] = fail (0) } # authorize = fail (0) Using Post-Auth-Type Reject Although SQL query returns : mysql> SELECT id, username, attribute, value, op FROM radcheck WHERE username = '90fba6e49245' ORDER BY id; +-----+--------------+--------------------+--------------+----+ | id | username | attribute | value | op | +-----+--------------+--------------------+--------------+----+ | 426 | 90fba6e49245 | Cleartext-Password | 90fba6e49245 | := | +-----+--------------+--------------------+--------------+----+ 1 row in set (0.00 sec) This time I don't understand why ?? Regards. -- Philippe MARASSE Responsable pôle Infrastructures - DSIO Centre Hospitalier Henri Laborit CS 10587 - 370 avenue Jacques Coeur 86021 Poitiers Cedex Tel : 05.49.44.57.19