Best way to deny users not matching any groups in the SQL DB
aland at deployingradius.com
Mon Feb 22 15:24:59 CET 2016
On Feb 22, 2016, at 9:07 AM, Sylvain Munaut <s.munaut at whatever-company.com> wrote:
> Because one NAS can have several service.
It would be nice to explain that at the start. Or, after I asked you to explain what your requirements were.
This "peek a boo" process of gradually giving more information is counter-productive.
> 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 ...
Then write rules for all of that, and set a server-side attribute which holds the service name. Then, key off of that server-side attribute.
>> 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.
I have no idea what you are doing, because you've been explaining it in bits and pieces. Even after I asked you to explain it all.
> 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 ?
For users? The SQL module by default keys off of User-Name. And puts *users* into groups.
If you want to do something else, you can. But it requires *describing* your requirements. And then implementing them.
>> It's a waste of time to worry about that. Don't bother.
> Heh, I don't completely agree there.
That's up to you. But it's wrong.
> 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 ...
<sigh> I'm asking you to NOT LOOK AT THE DETAILS OF MS-CHAP.
And your response is "I changed a documented FreeRADIUS configuration!"
That's an unproductive response. Explain what you mean. Or, don't be surprised when people don't understand what you mean.
I'm saying it's a good idea to read the FreeRADIUS documentation and configuration. I'm saying it's a complete and utter waste of your time to look at the internal details of MS-CHAP, as you implied in your previous message.
> 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
That's now what you said in your previous message.
There is no misconfiguration of MS-CHAP that allows users to be magically authenticated.
If YOU DECIDE to force "Auth-Type := Accept", then... well... it will authenticate all users (depending on the protocol). But that's *your* misconfiguration, and not the fault of the server.
> 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
Yes, that *is* the case for everything but EAP-TLS. Because EAP-TLS doesn't require users in the DB. The existence of the client certificate means that the user is authentic/
> and that's not the way it works at all in
> RADIUS, but at the time, I didn't know any better.
It helps to understand the systems you're configuring. At least a little bit. And there are many, many, places where EAP-TLS is documented.
More information about the Freeradius-Users