Best way to deny users not matching any groups in the SQL DB

[Sylvain Munaut]

Hi Alan,


>> wired_private | NAS-IP-Address  | == | 192.168.1.9
>> wired_private | NAS-Port        | <= | 39
>> wired_private | NAS-Port        | >= | 20
>> wired_private | NAS-Port-Type   | == | Ethernet
>> wifi_private  | NAS-IP-Address  | <= | 192.168.1.7
>> wifi_private  | NAS-IP-Address  | >= | 192.168.1.4
>> wifi_private  | NAS-Port-Type   | == | Wireless-802.11
>> wifi_private  | Called-Station-SSID | == | Private
>
>   I'm not sure why this level of detail is necessary.  If these are all RADIUS clients on your network, you can know in advance what function each one offers.

Because one NAS can have several service.

The same access point serves 4 different SSIDs. The same VPN server
will put users on 3 different networks depending on the radgroupreply.
The same switches will put different users in different VLANs
depending on both the users and the switch port they connected to ...


>   This is about separation of functionality.  Mixing & matching NAS rules with user rules is a bad idea.  Write down all of the rules for the NAS, including replies.  Get those implemented.  Then, add user rules on top of that.

I'm not sure I understand that. Because that's what I though I was
doing. Except it's not per NAS it's per-service, because a single NAS
can provide different service so I'm matching on some of the request
attributes to differentiate.

Then I have a table matching a given user to all the services it can access.


>   Then use a separate SQL table to match user to service, as I suggested earlier.
>
>         if (! "%{sql:SELECT username from service_table WHERE username = '%{User-Name}' AND service = "%{client:local_type}"}") {
>                 reject
>         }
>
>   Simple.  The *logic* is in FreeRADIUS.  The *data* is in a database.

Ok, yes I see this would work thanks.

I just thought that the whole concept of groups and the
group_membership_query was meant to serve that exact purpose but
apparently not. Not sure what they're meant for then ? What would be a
typical usage of the groups ?


>> Testing that something works when it's supposed to work is easy.
>> Testing that something indeed fails for every case where it's supposed
>> to fail is pretty much impossible (to be 100%). Even if I could
>> somehow physically test everything I can think of ... that still
>> leaves whatever I can't think of now.
>
>   It's a waste of time to worry about that.  Don't bother.

Heh, I don't completely agree there.

The cert CN vs User-Name in EAP-TLS is a good example. If I hadn't
seen that comment in check-eap-tls, I could have completely overlooked
it and then anyone with a valid cert could just pretend to be someone
else ...

And it's not so much about trusting people, because obviously I have
to (I'm not going to re-read the entire code stack all this depend
on), but it's more about making sure _I_ didn't miss anything ... that
I didn't overlook some config option somewhere that opens a gaping
hole.

The very first time I configured FreeRadius, I fully expected that if
a username wasn't anywhere in the DB, it would fail auth. Obviously
that's no the case at all and that's not the way it works at all in
RADIUS, but at the time, I didn't know any better.


Cheers,

    Sylvain