prevent Fall-through to profile in rlm_sql?
Hello *, can someone give me a hint why freeradius 3.0.12 falls through to profile processing in rlm_sql even if there is "fall-through = No" in the last group reply? Is there a way to tell the server NOT to fall-through to profile processing IF there was a match in the group processing? The "default" profile contains a deny reply which should only be returned if the user was not found in any usergroup. Debug: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id Debug: Parsed xlat tree: Debug: literal --> SELECT id, username, attribute, value, op FROM radcheck WHERE username = ' Debug: attribute --> SQL-User-Name Debug: literal --> ' ORDER BY id Debug: (9) sql1: EXPAND SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id Debug: (9) sql1: --> SELECT id, username, attribute, value, op FROM radcheck WHERE username = '1066876' ORDER BY id Debug: (9) sql1: Executing select query: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '1066876' ORDER BY id Debug: (9) sql1: User found in radcheck table Debug: (9) sql1: Conditional check items matched, merging assignment check items Debug: (9) sql1: NT-Password := 0x3566653839666532653838633631653730363765303636616366363632363636 Debug: (9) sql1: ::: FROM 1 TO 3 MAX 4 Debug: (9) sql1: ::: Examining NT-Password Debug: (9) sql1: ::: APPENDING NT-Password FROM 0 TO 3 Debug: (9) sql1: ::: TO in 3 out 3 Debug: (9) sql1: ::: to[0] = Proxy-To-Realm Debug: (9) sql1: ::: to[1] = CC-SSID Debug: (9) sql1: ::: to[2] = Auth-Type Debug: SELECT id, username, attribute, value, op FROM radreply WHERE username = '%{SQL-User-Name}' ORDER BY id Debug: Parsed xlat tree: Debug: literal --> SELECT id, username, attribute, value, op FROM radreply WHERE username = ' Debug: attribute --> SQL-User-Name Debug: literal --> ' ORDER BY id Debug: (9) sql1: EXPAND SELECT id, username, attribute, value, op FROM radreply WHERE username = '%{SQL-User-Name}' ORDER BY id Debug: (9) sql1: --> SELECT id, username, attribute, value, op FROM radreply WHERE username = '1066876' ORDER BY id Debug: (9) sql1: Executing select query: SELECT id, username, attribute, value, op FROM radreply WHERE username = '1066876' ORDER BY id Debug: (9) sql1: ... falling-through to group processing Debug: SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' AND NOW() between starts and ends ORDER BY priority Debug: Parsed xlat tree: Debug: literal --> SELECT groupname FROM radusergroup WHERE username = ' Debug: attribute --> SQL-User-Name Debug: literal --> ' AND NOW() between starts and ends ORDER BY priority Debug: (9) sql1: EXPAND SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' AND NOW() between starts and ends ORDER BY priority Debug: (9) sql1: --> SELECT groupname FROM radusergroup WHERE username = '1066876' AND NOW() between starts and ends ORDER BY priority Debug: (9) sql1: Executing select query: SELECT groupname FROM radusergroup WHERE username = '1066876' AND NOW() between starts and ends ORDER BY priority Debug: (9) sql1: User found in the group table Debug: SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{sql1-SQL-Group}' ORDER BY id Debug: Parsed xlat tree: Debug: literal --> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = ' Debug: attribute --> sql1-SQL-Group Debug: literal --> ' ORDER BY id Debug: (9) sql1: EXPAND SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{sql1-SQL-Group}' ORDER BY id Debug: (9) sql1: --> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'guest users' ORDER BY id Debug: (9) sql1: Executing select query: SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'guest users' ORDER BY id Debug: (9) sql1: Group "guest users": Conditional check items matched Debug: (9) sql1: Group "guest users": Merging assignment check items Debug: (9) sql1: ::: FROM 0 TO 4 MAX 4 Debug: (9) sql1: ::: TO in 4 out 4 Debug: (9) sql1: ::: to[0] = Proxy-To-Realm Debug: (9) sql1: ::: to[1] = CC-SSID Debug: (9) sql1: ::: to[2] = Auth-Type Debug: (9) sql1: ::: to[3] = NT-Password Debug: SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = '%{sql1-SQL-Group}' ORDER BY id Debug: Parsed xlat tree: Debug: literal --> SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = ' Debug: attribute --> sql1-SQL-Group Debug: literal --> ' ORDER BY id Debug: (9) sql1: EXPAND SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = '%{sql1-SQL-Group}' ORDER BY id Debug: (9) sql1: --> SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = 'guest users' ORDER BY id Debug: (9) sql1: Executing select query: SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = 'guest users' ORDER BY id Debug: (9) sql1: Group "guest users": Merging reply items Debug: (9) sql1: Session-Timeout = 3600 Debug: (9) sql1: Fall-Through = No Debug: (9) sql1: ::: FROM 2 TO 0 MAX 2 Debug: (9) sql1: ::: Examining Session-Timeout Debug: (9) sql1: ::: APPENDING Session-Timeout FROM 0 TO 0 Debug: (9) sql1: ::: Examining Fall-Through Debug: (9) sql1: ::: APPENDING Fall-Through FROM 1 TO 0 Debug: (9) sql1: ::: TO in 0 out 0 Debug: (9) sql1: ... falling-through to profile processing Debug: (9) sql1: Checking profile DEFAULT Best regards, Christof Chen
On Nov 8, 2016, at 12:30 PM, Chen, Christof <christof@chen.de> wrote:
can someone give me a hint why freeradius 3.0.12 falls through to profile processing in rlm_sql even if there is "fall-through = No" in the last group reply?
The behaviour of the SQL is extensively documented. http://wiki.freeradius.org/modules/Rlm_sql
Is there a way to tell the server NOT to fall-through to profile processing IF there was a match in the group processing?
Edit the source. Or don't use profiles.
The "default" profile contains a deny reply which should only be returned if the user was not found in any usergroup.
You'll have to find another way to do that. Alan DeKok.
Thanks for the swift clarification! Best regards, Christof Chen 2016-11-08 18:52 GMT+01:00 Alan DeKok <aland@deployingradius.com>:
On Nov 8, 2016, at 12:30 PM, Chen, Christof <christof@chen.de> wrote:
can someone give me a hint why freeradius 3.0.12 falls through to profile processing in rlm_sql even if there is "fall-through = No" in the last group reply?
The behaviour of the SQL is extensively documented.
http://wiki.freeradius.org/modules/Rlm_sql
Is there a way to tell the server NOT to fall-through to profile processing IF there was a match in the group processing?
Edit the source. Or don't use profiles.
The "default" profile contains a deny reply which should only be returned if the user was not found in any usergroup.
You'll have to find another way to do that.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
participants (2)
-
Alan DeKok -
Chen, Christof