sql groups authorization

[tnt at kalik.co.yu]

Why not you use huntgroups:

HGdial   NAS-IP-Address == dial NAS IP
             SQL-Group = dialup,
             ... other dial groups

HGWiFi   NAS-IP-Address == WiFi NAS IP
              SQL-Group = wifi,
              ... other wifi groups

etc.

Ivan Kalik
Kalik Informatika ISP


Dana 6/6/2007, "Happyfrog" <happyfrog at hotbox.ru> piše:

>
>
>Hello Gurus, 
>
>  I need to set up FR with SQL (Postgres) backend storing all
>users/groups information except clients.conf. 
>
>  Groups are mission-critical, because the same user can come from
>different NASes (WiFi, Dial-Up, VPDN) and should get different
>settings (IP addresses etc). 
>
>  Access to different services is granting through radusergroup
>table, where user belong or not belong to corresponding group. 
>
>  If user doesn't belong do group 'dialup' but come from Dial-Up NAS,
>it should be rejected even with correct password. 
>
>  That access idea seems to me very simple, but I've spend many days
>getting it to work state. 
>
>  First of all, i realized that documented rlm_sql `read_groups'
>directive don't affect on sql_config structure read_groups member. 
>
>  This patch fixes that issue: 
>
>  diff ./src/modules/rlm_sql/rlm_sql.c.orig
>../src/modules/rlm_sql/rlm_sql.c
>104a105,106
>>       {"read_groups", PW_TYPE_BOOLEAN,
>>        offsetof(SQL_CONFIG,read_groups), NULL, "yes"}, 
>
>  Well, that didn't fix the problem. 
>
>  Now rlm_sql successfully find the user in radcheck table, setting
>found=1, and then check groups. 
>
>  The problem is that found remains =1 in case of group check failure
>(rlm_sql_process_groups returns 0). 
>
>  diff ./src/modules/rlm_sql/rlm_sql.c.orig
>../src/modules/rlm_sql/rlm_sql.c 
>
>  This patch fixes that issue (line numbers are correct for original
>file without first patch): 
>
>  988a989,991
>>               } else {
>>                   /* no matched group found => decline the user */
>>                   found = 0;
>
>  Well, that also didn't fix the problem. 
>
>  Now rlm_sql returns RLM_MODULE_NOTFOUND, but for FR it doesn'd mean
> 'reject the user immediately', 
>
>  and after processing of next modules, the user is accepted without
>any groups. 
>
>  This patch fixes that issue: 
>
>  diff ./src/modules/rlm_sql/rlm_sql.c.orig
>../src/modules/rlm_sql/rlm_sql.c 
>
>  1044c1044
><               return RLM_MODULE_NOTFOUND;
>---
>>               return RLM_MODULE_REJECT; 
>
>  After that patch the FR (CVS 20070605) is working as expected.  
>
>  here is some database data: 
>
>  radchek table contains only user passwords: 
>
>  # select * from radcheck; 
>
>   id |  username   |   attribute    | op |               value
>----+-------------+----------------+----+------------------------------------
>1 | guest       | Crypt-Password | == | $....... 
>
>  ... 
>
>  radreply table is empty 
>
>  radusergroup table contains user to groups mappings: 
>
>  # select * from radusergroup; 
>
>    username   |   groupname   | priority
>-------------+---------------+----------
>guest       | dialup_guests |        3 
>
>  ...  
>
>  radgroupcheck table contains attributes to distinguish NASes, set
>Pool-Names and some other unimportant things: 
>
>  # select * from radgroupcheck; 
>
>   id |   groupname    |    attribute     | op |      value
>----+----------------+------------------+----+------------------
>3 | dialup_guests  | NAS-IP-Address   | == | 192.168.0.1 
>
>  7 | dialup_guests  | Pool-Name        | := | dialup_pool 
>
>  ... 
>
>  radgroupreply table contains nothing special: 
>
>  # select * from radgroupreply; 
>
>   id |   groupname   |    attribute    | op | value
>----+---------------+-----------------+----+-------
>  1 | dialup_guests | Session-Timeout | := | 900 
>
>  ...
>
>  I'm pretty sure that there is more straight way to do the same
>thing. If someone have another solution, please tell. 
>
>  I would be happy if this info will help somebody. 
>
>  Any comments are greatly appreciated. 
>
>Best regards,
>Andrew.
>
>