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" <[EMAIL PROTECTED]> 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. > > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html