Alan DeKok wrote: > Andrew D wrote: >> 1. If the user is found in the sql tables and has reply attributes etc, >> is it still possible to go through the 'users' file? if so how? >> I can't seem to get it to do it. > > Yes, it's possible. The modules are completely independent, so you > just configure both. In fact, if you just uncomment the "sql" entries > in the default radiusd.conf, the server will do that. >
Which it does, but doesn't work like I would expect it to, with the examples given in the docs. huntgroup file test NAS-IP-ADDRESS == some.ip testbad NAS-IP-ADDRESS == some.ip Group = suspend or test NAS-IP-ADDRESS == some.ip testbad NAS-IP-ADDRESS == some.ip, Group == suspend users file DEFAULT Group == "suspend" Framed-IP-Address := 172.16.32.0+, Session-Timeout := 600, Port-Limit := 1 DEFAULT Huntgroup-Name == "testbad" Framed-IP-Address := 172.16.32.0+, Session-Timeout := 600, Port-Limit := 1 DEFAULT Huntgroup-Name == "test" Port-Limit := 1, Fall-Through = 1 a quick snip from radiusd -X radius_xlat: 'SELECT radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op FROM radgroupreply,usergroup WHERE usergroup.Username = 'awd' AND usergroup.GroupName = radgroupreply.GroupName ORDER BY radgroupreply.id' rlm_sql (sql): Released sql socket id: 4 modcall[authorize]: module "sql" returns ok for request 0 users: Matched entry DEFAULT at line 26 users: Matched entry DEFAULT at line 43 users: Matched entry DEFAULT at line 61 modcall[authorize]: module "files" returns ok for request 0 modcall: leaving group authorize (returns ok) for request 0 rad_check_password: Found Auth-Type CHAP auth: type "CHAP" Processing the authenticate section of radiusd.conf modcall: entering group CHAP for request 0 rlm_chap: login attempt by "awd" with CHAP password rlm_chap: Using clear text password start for user awd authentication. It skips the 2 default entries before Huntgroup-Name == "test" line, even though the user is in the suspend group. I've tried swapping them around with no difference(both huntgroups and users file). It seems to be disregarding the group. I also ran the sql query and it returns the suspend group. Basically, depending on the huntgroup I need to send different reply attributes (different NAS types) and if the DB returns the group suspend, different reply attributes are sent. > Or, try reading the FAQ for what information is needed in situations > where "it doesn't work". > >> 2. Is there an ability in any way to have a caching like feature or is >> DB failover and running 2 db servers with replication the only way to go? > > Cache... what? Cache details that it gets from the DB for some configurable time, ie VOPradius caches unames/password and other reply attributes to send to the NAS for 24 hours since the user last connected. >> 3. Is there anyway to log the actual reason for rejection in >> 'Post-Auth-Type REJECT'? ie simultaneous use, invalid password etc? > > Module-Failure-Message often contains the reason, but not always. > That seems to do the trick :) Some info is better than none, and so far in testing its been perfect. May I suggest mentioning this in the variables file. Cheers cya Andrew > Alan DeKok. > -- > http://deployingradius.com - The web site of the book > http://deployingradius.com/blog/ - The blog > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html