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

[Sylvain Munaut]

Hi Alan,


>> Is there a way to recover the group that was matched ?
>
>   SQL groups are matched via SQL-Group.  This is documented.

Thanks for the pointer, but "it's documented", I'd say no, not really.

It's not on the wiki page for Rlm_sql where I'd expect it. There is a
reference to it in "mods-available/sql" : 'group_attribute =
"SQL-Group"'  but unless you know what 'group_attribute' means / is,
it's not obvious.
It's actually much clearer in the LDAP wiki page, but until 5 min ago,
I hadn't read that page because ... I don't use LDAP so it seemed
irrelevant.


>   I can't really comment on those options, because I have no idea what your requirements are.
>
>   Please explain your requirements.  Completely, and in detail.

I thought I had, but let me try again :

I have a bunch of services like VPN server, Wifi SSID, Wired port
auth, ...  some are on the same NAS (like several SSID on the same
AP), some are on other NAS ( like VPN server, .. ).

For each service, I have a bunch of checks to make sure the request is
for that particular service, for instances things like :

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

And then sometimes for theses I also have some specific attributes to
be added to the response :

wifi_private  | Cisco-AVPair  | += | ssid=Private


Then I have users that authenticate using either EAP-MD5 / EAP-PEAP /
EAP-MSCHAPv2 / EAP-TLS  (depends on the user and depend on the
service, some only have certs, some only have passwords).
And for each of theses users, I have a list of the services they must
be able to access.

If the user tries to access a service he's allowed to, he must be allowed.
If the user tries to access a service he's not allowed to, he must be rejected.
If the user doesn't even exist (for instance, he has a EAP-TLS cert
but he's not appearing in the DB at all), then he must be rejected as
well.

(and wrt to EAP-TLS, yes, I'm already checking the User-Name matches
the cert CN, the 'check-eap-tls' virtual server was pretty clear about
what to do for this).


>   Exactly.  You don't know what the requirements are, so you don't know if the solution meets those requirements.

Huh ... I know the functional requirements.

But I don't know every detail of every messages for every
authentication protocol and how they could possibly be manipulated by
a malicious party to make things behave weirdly.

For instance, currently I assume that if I don't set a
Cleartext-Password, a user can't possibly authenitcate with MSCHAPv2.
But is that true ? Or is not setting a password equivalent to an empty
string ? Not something I can even test easily as most clients don't
let you try an empty string as the password to attempt connection.
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.

Which is why I'm trying to find the solution that modify the _least_
the default files that come with Freeradius because I'm relying on the
fact the defaults have been written by people who know a whole lot
more than me about Radius, the authentication protocols it supports
and Freeradius codebase itself. And that's also consistent with the
wiki that recommends to edit as little as possible.


Cheers,

    Sylvain