Re: freeradius sql /mssql

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,radgroupr eply.Attribute,radgroupreply.Value,radgroupreply.o p
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