Freeradius3 + SQL -> radusergroup check is not matched

[Martin Bednar]

Hello,

if anyone would be interested in future - my problem was quite simple:

for eap module I didn't enable

copy_request_to_tunnel = yes

so it makes sense now that there was no match in radgroupcheck as
there was no value to compare.

# vi mods-available/eap

ttls {
       copy_request_to_tunnel = yes
}

peap {
       copy_request_to_tunnel = yes
}

Regards,

Martin

On Mon, May 15, 2017 at 8:57 PM, Martin Bednar <mato.bednar at gmail.com> wrote:
> Hello Alan,
>
> again thanks for your time. The goal is simple. When is user
> connecting to the wireless network he is asked for username/password
> if there is a match and at the same time he is allowed to use this
> SSID he is authenticated.
>
> username/password check should happen in radcheck table
> SSID check should happen in radusergroup table
>
>>> MariaDB [radius]> select * from radgroupreply where groupname =
>
>>> "SSID_EMPL-Test";
>>> +----+----------------+-----------+----+--------+
>>> | id | groupname      | attribute | op | value  |
>>> +----+----------------+-----------+----+--------+
>>> |  6 | SSID_EMPL-Test | Auth-Type | :=  | Accept |
>>> +----+----------------+-----------+----+--------+
>>> 1 row in set (0.00 sec)
>
>>  i.e. anyone who logs into the  EMPL-Test SSID gets accepted?
>
> You're right - that's not right. In this case even if the
> username/password would be wrong user would receive Access Accept. I
> believe that normally there is no need for radgroupreply item because
> Access Accept/Reject is already set from radcheck.
>
> Would it works like this ?
>
> Check user in radcheck -> is  username/passsword are ok -> Accept
> otherwise Reject
> Check user in radgroupcheck -> for allowed SSID there would be group
> with no reply action -> if no match last group (highest priority)
> would be Reject which would be always matched.
>
>
> Yes solution proposed by you looks straightforward and would probably
> work but I have no idea where I should put that condition and I'm
> afraid that if I'd go this direction it would bring more questions
> than answers.
>
> Thanks for help
> --
> "Martin Bednar"



-- 
"Martin Bednar"
(mato.bednar at gmail.com)