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

[Sylvain Munaut]

Hi Matthew,


>> 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 ...
>
> EAP-TLS is based around one thing - if you can present a valid
> certificate then you are permitted to connect.

Well my use case is not that simple :)
If you're issued a cert you can prove who you are. But then depending
on who you proved you were, you're going to be granted / denied access
to whatever you're requesting to access.


> There's no such thing as "pretending to be someone else". Yes, you
> could steal someone elses certificate and key. You could also
> steal their username and password for a different authentication
> method...

Well I used the "pretending to be someone else" because by default
everything (group membership / reply attrs / ...) is keyed off
"User-Name".
And the User-Name gets filled with the CN if not explicitly told to do
something else in the client. But without an explicit check it can be
anything.


> check-eap-tls is for the slightly less usual situation where you
> want to do additional checks on the client certifiacte presented.
> It's not a "this is how you authenticate this person" - EAP-TLS
> authenticates everyone you've issued a certificate to by
> definition.

"authenticate" yes.
"authorize" no.


> The example case of check-eap-tls (which is the reason I wrote it)

Thanks for writing it :)


> Usually you would just not issue certs to the PCs you didn't want
> to connect. That wasn't possible here, hence the possibility of an
> additional check to restrict what would normally be controlled
> elsewhere.

Same here.


> This doesn't hold for other parts of FreeRADIUS. Users can log in
> because they're in the users file, or a database, etc.

Actually I think that's this kind of simplification that's not totally
correct that surprised me at first.

My understanding ATM is that they can login because they have a
Cleartext-Password being set that allows one of the auth method to
proceed. Sure, the usual way of setting this IS to use DB/file/...
but if you have special config that sets it any other way, it'll work
just as well and the presence of the user in DB/files is not actually
strictly required. And for EAP-TLS that's kind of what happens, no
need for that attr for it to succeed, so no need for it to be in the
DB either. And yeah, NOW it looks obvious to me, just wasn't always
the case :)


> FreeRADIUS doesn't just let anyone connect when you've not
> permitted them to.

I never said it did.

All I said was that my ignorance led to a first configuration that was
allowing much more than what I thought it did. I didn't intend to
place any blame for that on FreeRADIUS at all, sorry if it sounded
that way.
I perfectly understand why things work this way now.

And that config never even went anywhere to production either, I was
just illustrating that sometimes "Testing that something that
shouldn't work does indeed _not_ work" is not a waste of time.


Cheers,

    Sylvain