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