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

[Alan DeKok]

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

 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.

  Alan DeKok.