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

Alan DeKok aland at deployingradius.com
Fri Feb 19 23:30:40 CET 2016


On Feb 19, 2016, at 4:44 PM, Sylvain Munaut <s.munaut at whatever-company.com> wrote:
> Well that's just for the Wifi SSID, but I have a bunch of other
> services too. All those checks are done in the rachgroupcheck and I'd
> rather avoid having to duplicate all of them in the config files as
> well.

  It helps to describe your requirements accurately.  I gave you the simplest solution for the problem you posted.

> Is there a way to recover the group that was matched ?

  SQL groups are matched via SQL-Group.  This is documented.

> The current options I'm using is to :

  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.

> But I find this a bit of a mess because :

  It's a solution in search of a problem.

  When you state the requirements clearly, the solution often becomes simple.

> - Since I pretty much "invented" that and not followed an official
> example, I'm not entirely sure I didn't break the security and that
> there is no way to bypass those checks.

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

> As improvements I was thinking either :

  Write down your requirements.  Then, implement a solution to the requirements.

  This is the *only* way to be sure that the requirements are met, and that there is no way to bypass the checks you implement.

> Since this seems like such a common usecase, I thought there would be
> a "canonical / proven / recommended" way to  handle this.

  Since I have no idea what your requirements are, I can't comment on the canonical way to implement them.

  I *can* comment on the canonical problem solving approach: write down the requirements.  And write down what you see in each packet.  Use the differences between the packets to implement the requirements.

  And don't rely on the default SQL schema.  If it's too restrictive, create a new one.  It's literally 5 lines of "unlang" to implement a custom user/SSID mapping, as I showed in my easier message.

  If you have 5000 users with similar data... create a custom SQL schema.  Rely on the database to store data.  Implement policies (if / then / else) in unlang.

  Alan DeKok.




More information about the Freeradius-Users mailing list