Freeradius3 + SQL -> radusergroup check is not matched

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Freeradius3 + SQL -> radusergroup check is not matched

Martin Bednar
Hello Allan,

many thanks for help. To be honest I believe that for me it would be
easier to make it work with tables and queries already in place so if
you don't mind I'd just like to doublecheck what am I not
understanding well from the rlm_sql documentation.

-->Search the radcheck table for any check attributes specific to the user
-->If check attributes are found, and there's a match, pull the reply
items from the radreply table for this user and add them to the reply

 In my case it is password

MariaDB [radius]> select * from radcheck where username = "miro";
+----+----------+--------------------+----+-------+
| id | username | attribute          | op | value |
+----+----------+--------------------+----+-------+
|  7 | miro     | Cleartext-Password | := | miro  |
+----+----------+--------------------+----+-------+

nothing is in radreply table

MariaDB [radius]> select * from radreply;
Empty set (0.00 sec)

 --> Group processing then begins if any of the following conditions are met:

The user IS NOT found in radcheck
The user IS found in radcheck, but the check items don't match
The user IS found in radcheck, the check items DO match AND
Fall-Through is set in the radreply table
The user IS found in radcheck, the check items DO match AND the
read_groups directive is set to 'yes'

I'm matching last condition:

# grep read_clients /etc/raddb/mods-available/sql
        read_clients = yes

--> If groups are to be processed for this user, the first thing that
is done is the list of groups this user is a member of is pulled from
the usergroup table ordered by the priority field.

 MariaDB [radius]> select * from radusergroup where username = "miro"
order by priority;
+----------+----------------+----------+
| username | groupname      | priority |
+----------+----------------+----------+
| miro     | SSID_EMPL-Test |        1 |
| miro     | Reject-Profile |        2 |
+----------+----------------+----------+
2 rows in set (0.00 sec)

So group SSID_EMPL-Test is the one which will be checked first :

MariaDB [radius]> select * from radgroupcheck where groupname =
"SSID_EMPL-Test";
+----+----------------+------------------+----+-----------+
| id | groupname      | attribute        | op | value     |
+----+----------------+------------------+----+-----------+
|  6 | SSID_EMPL-Test | Aruba-Essid-Name | == | EMPL-Test |
+----+----------------+------------------+----+-----------+
1 row in set (0.00 sec)

--> If there is a match, the reply items for this group are pulled
from the radgroupreply table and applied.

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)

--> Processing continues to the next group IF:
 There was not a match for the last group's check items

so my understanding is that check won't continue and user will get
Accept. Clearly I'm missing something but I don't know what. You're
saying that

" 6 | SSID_EMPL-Test     | Aruba-Essid-Name  | == | EMPL-Test
Which says that anyone in the SSID_EMPL-Test is rejected if they use
the EMPL-Test  SSID."

If you could show me here right directions I'd really appreciate that.
How should I check if Aruba-Essid-Name has value EMPL-Test and if so
Accept the user ?

Thanks for your time,

Martin
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Reply | Threaded
Open this post in threaded view
|

Re: Freeradius3 + SQL -> radusergroup check is not matched

Alan DeKok-2
On May 15, 2017, at 10:17 AM, Martin Bednar <[hidden email]> wrote:
> many thanks for help. To be honest I believe that for me it would be
> easier to make it work with tables and queries already in place so if
> you don't mind I'd just like to doublecheck what am I not
> understanding well from the rlm_sql documentation.

  The default schemas / queries should work... if they're used correctly.

> The user IS found in radcheck, the check items DO match AND the
> read_groups directive is set to 'yes'
>
> I'm matching last condition:
>
> # grep read_clients /etc/raddb/mods-available/sql
>        read_clients = yes

  Details matter.  "read_clients" is not "read_groups".

> So group SSID_EMPL-Test is the one which will be checked first :
>
> MariaDB [radius]> select * from radgroupcheck where groupname =
> "SSID_EMPL-Test";
> +----+----------------+------------------+----+-----------+
> | id | groupname      | attribute        | op | value     |
> +----+----------------+------------------+----+-----------+
> |  6 | SSID_EMPL-Test | Aruba-Essid-Name | == | EMPL-Test |
> +----+----------------+------------------+----+-----------+

  That just says people are in the SSID_EMPL-Test group when they're logging into the EMPL-Test SSID.

  i.e. it does NO checking that a *user* is in a group.

> --> If there is a match, the reply items for this group are pulled
> from the radgroupreply table and applied.
>
> 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?

  Is that what you want?


  You've created a particular solution, and you want to fix the solution to solve the problem you have.   But, you haven't written down the problem.

  Again, you need to write down what you want to happen.  Use simple English.  Then, see how the SQL module can be used to get what you want.

  I suggest a simple solution which I think solves the problem (even tho the problem is largely unstated).

  Would my solution work?

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Reply | Threaded
Open this post in threaded view
|

Re: Freeradius3 + SQL -> radusergroup check is not matched

Martin Bednar
In reply to this post by Martin Bednar
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"
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Reply | Threaded
Open this post in threaded view
|

Re: Freeradius3 + SQL -> radusergroup check is not matched

Alan DeKok-2
On May 15, 2017, at 2:57 PM, Martin Bednar <[hidden email]> wrote:
> 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.

  That's still too high level.

  My suggestion was to read the rlm_sql documentation and write things down.  If you're not going to do that, you're just wasting everyone's time.

  i.e. go through the rlm_sql documentation.  Read the discussion on how the packets are processed.  For each item in the list, write down what is in the packet, and what is in the SQL table.  Then, check the processing to see if it matches.

> username/password check should happen in radcheck table
> SSID check should happen in radusergroup table

  So you want users to be checked, and SSIDs to be checked.  But there's nothing about how users are put into groups.

  Again, see the wiki for rlm_sql.  Look for the "usergroup" table.  It's largely what I suggested earlier, but integrated with rlm_sql.

>> 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 rcadcheck.

  That's the wrong way to do it.

  It's OK to reject users anywhere.  Because a reject is always a reject.

  It's *not* OK to definitively accept a user anywhere.  Because a later processing stage may decide to reject the user.

  i.e. *not* being in rcadcheck means they're rejected.  Being in rcadcheck means they *might* be accepted, if they're in the right group and are using the right SSID.

> Would it works like this ?
> \
> Check user in radcheck -> is  username/passsword are ok -> Accept
> otherwise Reject

  Again, you don't want to "accept" users here.

> Check user in radgroupcheck -> for allowed SSID there would be group
> with no reply action -> if no match last group (highest priority)

  From the sql documentation... if the group matches AND there's no Fall-Through, then group processing stops.

> would be Reject which would be always matched.

  Does the SQL module documentation mention "always matched"?

  Again, you're trying to design a solution based on what you want it to do.  You need instead to design a solution based on how it actually works.

  And write things down, in detail.  Follow the flow of the documentation.

  Posting vague requirements and guesses for "will this work?" is just unhelpful/

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Reply | Threaded
Open this post in threaded view
|

Re: Freeradius3 + SQL -> radusergroup check is not matched

Martin Bednar
In reply to this post by 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 <[hidden email]> 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"
([hidden email])
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html