On Feb 22, 2016, at 9:07 AM, Sylvain Munaut <s.munaut@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.