Best way to deny users not matching any groups in the SQL DB
Hi, I'm using radius to control access to access points (several SSIDs) using both PEAP and EAP-TLS, control a vpn server and also 802.1x switch ports. I have one group defined per service (so one per wifi SSID, one for VPN, ...) that make sure that the correct returns attributes are in the response. What I'd like is that if either : - The user doesn't exist at all in the DB - Or the user exists but it didn't match any groups (because the user doesn't have access to the particular service he's trying to use). Then access should be denied. What's the recommended way to achieve that result ? All the ones I'm thinking of seem pretty messy so I must be missing something, and given it's pretty easy to omit something and open a big security hole, I'd rather have some expert opinion here. Cheers, Sylvain Munaut
On Feb 18, 2016, at 10:03 AM, Sylvain Munaut <s.munaut@whatever-company.com> wrote:
I have one group defined per service (so one per wifi SSID, one for VPN, ...) that make sure that the correct returns attributes are in the response.
That's good.
What I'd like is that if either : - The user doesn't exist at all in the DB - Or the user exists but it didn't match any groups (because the user doesn't have access to the particular service he's trying to use).
Then access should be denied.
What's the recommended way to achieve that result ?
Create an SQL table with 2 columns, user and SSID. Then, write a SELECT statement which looks up user and SSID. If it returns anything, the user is allowed to use that SSID. If it returns nothing, the user isn't allowed to use that SSID. if (! "%{sql:SELECT user FROM my_table WHERE user=%{User-Name} AND SSID=%{Called-Station-ID}}") { reject } # else it's OK You'll have to double-check the SQL select statement, of course. But that's the general idea. Alan DeKok.
Hi Alan, First, thanks for your reply.
What's the recommended way to achieve that result ?
Create an SQL table with 2 columns, user and SSID. Then, write a SELECT statement which looks up user and SSID. If it returns anything, the user is allowed to use that SSID. If it returns nothing, the user isn't allowed to use that SSID.
if (! "%{sql:SELECT user FROM my_table WHERE user=%{User-Name} AND SSID=%{Called-Station-ID}}") { reject } # else it's OK
You'll have to double-check the SQL select statement, of course. But that's the general idea.
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. Is there a way to recover the group that was matched ? The current options I'm using is to : - Have all users be a member of the "deny" group that sets Auth-Type := None in the radgroupcheck table. And have this group with a low prio so that it's found last. - This covers the case of existing users that try to access a non-authorized service, but not the case of a user that's not in the DB at all. - For auth modes that need a password, ClearText-Password won't be set is user doesn't exist, so auth will fail. - For EAP-TLS, the user could have a valid cert but not be in the DB ... so I added something like this in the check-eap-tls virtual server : if (!(ok || updated)) { # Not found in the DB, deny update config { &Auth-Type := Reject } return } This tests the return value of the sql module and if nothing was found, it rejects the user. But I find this a bit of a mess because : - If I forget to put the user in the "deny" group, he'll have access to everything suddenly. - The EAP-TLS checks is based on the return value of the 'sql' module and I'm not sure if that's guaranteed / specified. - 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. As improvements I was thinking either : - Change the group membership query to always return the 'deny' group, no matter the username. - Or set a default_user_profile that would include 'deny', but then in each group reply I have to add a 'Fall-Through; No' to prevent it going to the 'profiles' processing after the group processing if a group was matched. - Or maybe just never put the users into groups directly, but just set a User-Profile for them, then maps the profiles to the group (which might actually map reality more accurately since users belong to a business unit and it's that business units that determines what service they can access). Since this seems like such a common usecase, I thought there would be a "canonical / proven / recommended" way to handle this. Cheers Sylvain
On Feb 19, 2016, at 4:44 PM, Sylvain Munaut <s.munaut@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.
Hi Alan,
Is there a way to recover the group that was matched ?
SQL groups are matched via SQL-Group. This is documented.
Thanks for the pointer, but "it's documented", I'd say no, not really. It's not on the wiki page for Rlm_sql where I'd expect it. There is a reference to it in "mods-available/sql" : 'group_attribute = "SQL-Group"' but unless you know what 'group_attribute' means / is, it's not obvious. It's actually much clearer in the LDAP wiki page, but until 5 min ago, I hadn't read that page because ... I don't use LDAP so it seemed irrelevant.
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.
I thought I had, but let me try again : I have a bunch of services like VPN server, Wifi SSID, Wired port auth, ... some are on the same NAS (like several SSID on the same AP), some are on other NAS ( like VPN server, .. ). For each service, I have a bunch of checks to make sure the request is for that particular service, for instances things like : wired_private | NAS-IP-Address | == | 192.168.1.9 wired_private | NAS-Port | <= | 39 wired_private | NAS-Port | >= | 20 wired_private | NAS-Port-Type | == | Ethernet wifi_private | NAS-IP-Address | <= | 192.168.1.7 wifi_private | NAS-IP-Address | >= | 192.168.1.4 wifi_private | NAS-Port-Type | == | Wireless-802.11 wifi_private | Called-Station-SSID | == | Private And then sometimes for theses I also have some specific attributes to be added to the response : wifi_private | Cisco-AVPair | += | ssid=Private Then I have users that authenticate using either EAP-MD5 / EAP-PEAP / EAP-MSCHAPv2 / EAP-TLS (depends on the user and depend on the service, some only have certs, some only have passwords). And for each of theses users, I have a list of the services they must be able to access. If the user tries to access a service he's allowed to, he must be allowed. If the user tries to access a service he's not allowed to, he must be rejected. If the user doesn't even exist (for instance, he has a EAP-TLS cert but he's not appearing in the DB at all), then he must be rejected as well. (and wrt to EAP-TLS, yes, I'm already checking the User-Name matches the cert CN, the 'check-eap-tls' virtual server was pretty clear about what to do for this).
Exactly. You don't know what the requirements are, so you don't know if the solution meets those requirements.
Huh ... I know the functional requirements. But I don't know every detail of every messages for every authentication protocol and how they could possibly be manipulated by a malicious party to make things behave weirdly. For instance, currently I assume that if I don't set a Cleartext-Password, a user can't possibly authenitcate with MSCHAPv2. But is that true ? Or is not setting a password equivalent to an empty string ? Not something I can even test easily as most clients don't let you try an empty string as the password to attempt connection. Testing that something works when it's supposed to work is easy. Testing that something indeed fails for every case where it's supposed to fail is pretty much impossible (to be 100%). Even if I could somehow physically test everything I can think of ... that still leaves whatever I can't think of now. Which is why I'm trying to find the solution that modify the _least_ the default files that come with Freeradius because I'm relying on the fact the defaults have been written by people who know a whole lot more than me about Radius, the authentication protocols it supports and Freeradius codebase itself. And that's also consistent with the wiki that recommends to edit as little as possible. Cheers, Sylvain
On Feb 22, 2016, at 8:00 AM, Sylvain Munaut <s.munaut@whatever-company.com> wrote:
I have a bunch of services like VPN server, Wifi SSID, Wired port auth, ... some are on the same NAS (like several SSID on the same AP), some are on other NAS ( like VPN server, .. ).
For each service, I have a bunch of checks to make sure the request is for that particular service, for instances things like :
wired_private | NAS-IP-Address | == | 192.168.1.9 wired_private | NAS-Port | <= | 39 wired_private | NAS-Port | >= | 20 wired_private | NAS-Port-Type | == | Ethernet wifi_private | NAS-IP-Address | <= | 192.168.1.7 wifi_private | NAS-IP-Address | >= | 192.168.1.4 wifi_private | NAS-Port-Type | == | Wireless-802.11 wifi_private | Called-Station-SSID | == | Private
I'm not sure why this level of detail is necessary. If these are all RADIUS clients on your network, you can know in advance what function each one offers. All you need to do is to match source IP address of the packet to a "name" for that service. You could even put that name into the "client" section: client foo { type = auth ipaddr = 192.168.1.4 secret = ... # local extensions! local_type = "wifi_private" } Then, check that via "unlang: switch "%{client:local_type}" { case wifi_private { update reply { | Cisco-AVPair += ssid=Private } } ... } You could also put the service information into a special SQL table, keyed by client source IP. There's really no need to do additional checks for NAS-Port, etc. You can add them if you wish... but it makes things more complicated. 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.
Then I have users that authenticate using either EAP-MD5 / EAP-PEAP / EAP-MSCHAPv2 / EAP-TLS (depends on the user and depend on the service, some only have certs, some only have passwords). And for each of theses users, I have a list of the services they must be able to access.
Then use a separate SQL table to match user to service, as I suggested earlier. if (! "%{sql:SELECT username from service_table WHERE username = '%{User-Name}' AND service = "%{client:local_type}"}") { reject } Simple. The *logic* is in FreeRADIUS. The *data* is in a database.
If the user tries to access a service he's allowed to, he must be allowed. If the user tries to access a service he's not allowed to, he must be rejected.
See above. A 3 line "unlang" policy does this.
If the user doesn't even exist (for instance, he has a EAP-TLS cert but he's not appearing in the DB at all), then he must be rejected as well.
The 3 line unlang policy does this.
(and wrt to EAP-TLS, yes, I'm already checking the User-Name matches the cert CN, the 'check-eap-tls' virtual server was pretty clear about what to do for this).
That's good.
Huh ... I know the functional requirements.
But I don't know every detail of every messages for every authentication protocol and how they could possibly be manipulated by a malicious party to make things behave weirdly.
Don't worry about it. Honestly. You control the NAS, so the NAS can't lie to you about it's source IP, etc. You don't control the user, but you *do* control who gets authenticated. Rely on the authentication protocols to do their job, and to accept only authenticated users. You're not going to look into the hundreds of pages of TLS specs, or the hundreds of thousands of lines of OpenSSL code to see what weird things people can do. You're not an expert. Don't even try. Rely on the experts to do things correctly.
For instance, currently I assume that if I don't set a Cleartext-Password, a user can't possibly authenitcate with MSCHAPv2. But is that true ?
That's just ridiculous. Stop wasting your time, and don't worry about it.
Or is not setting a password equivalent to an empty string ? Not something I can even test easily as most clients don't let you try an empty string as the password to attempt connection.
That's also ridiculous. People get authenticated when the authentication protocol says they're authenticated. Trust that. Or, look at the MS-CHAP code, and all of the MS-CHAP RFCs to see how it works. Spend weeks (no, months) trying to break MS-CHAP security. And TLS. And EAP. And RADIUS. And IP. It's a never-ending circle of paranoia. But I think the process of trusting people works a whole lot better.
Testing that something works when it's supposed to work is easy. Testing that something indeed fails for every case where it's supposed to fail is pretty much impossible (to be 100%). Even if I could somehow physically test everything I can think of ... that still leaves whatever I can't think of now.
It's a waste of time to worry about that. Don't bother.
Which is why I'm trying to find the solution that modify the _least_ the default files that come with Freeradius because I'm relying on the fact the defaults have been written by people who know a whole lot more than me about Radius, the authentication protocols it supports and Freeradius codebase itself. And that's also consistent with the wiki that recommends to edit as little as possible.
See? You trust people. Keep that up. Alan DeKok.
Hi Alan,
wired_private | NAS-IP-Address | == | 192.168.1.9 wired_private | NAS-Port | <= | 39 wired_private | NAS-Port | >= | 20 wired_private | NAS-Port-Type | == | Ethernet wifi_private | NAS-IP-Address | <= | 192.168.1.7 wifi_private | NAS-IP-Address | >= | 192.168.1.4 wifi_private | NAS-Port-Type | == | Wireless-802.11 wifi_private | Called-Station-SSID | == | Private
I'm not sure why this level of detail is necessary. If these are all RADIUS clients on your network, you can know in advance what function each one offers.
Because one NAS can have several service. 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 ...
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. Then I have a table matching a given user to all the services it can access.
Then use a separate SQL table to match user to service, as I suggested earlier.
if (! "%{sql:SELECT username from service_table WHERE username = '%{User-Name}' AND service = "%{client:local_type}"}") { reject }
Simple. The *logic* is in FreeRADIUS. The *data* is in a database.
Ok, yes I see this would work thanks. 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 ?
Testing that something works when it's supposed to work is easy. Testing that something indeed fails for every case where it's supposed to fail is pretty much impossible (to be 100%). Even if I could somehow physically test everything I can think of ... that still leaves whatever I can't think of now.
It's a waste of time to worry about that. Don't bother.
Heh, I don't completely agree there. 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 ... 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. 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 and that's not the way it works at all in RADIUS, but at the time, I didn't know any better. Cheers, Sylvain
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.
On Mon, Feb 22, 2016 at 3:24 PM, Alan DeKok <aland@deployingradius.com> wrote:
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.
My previous mail had this _exact_ info : """ I have a bunch of services like VPN server, Wifi SSID, Wired port auth, ... some are on the same NAS (like several SSID on the same AP), """ It explicitly says "several SSID on the same AP". Not really sure how I could have been more clear on that ... Cheers, Sylvain
On Feb 22, 2016, at 9:39 AM, Sylvain Munaut <s.munaut@whatever-company.com> wrote:
My previous mail had this _exact_ info :
""" I have a bunch of services like VPN server, Wifi SSID, Wired port auth, ... some are on the same NAS (like several SSID on the same AP), """
It explicitly says "several SSID on the same AP".
Not really sure how I could have been more clear on that ...
Neither that message, nor the later ones with examples rules from SQL showed any rules which keyed off of SSID. Again, I can only go by what you say publicly. I'm not a mind reader. Alan DeKok.
""" I have a bunch of services like VPN server, Wifi SSID, Wired port auth, ... some are on the same NAS (like several SSID on the same AP), """
It explicitly says "several SSID on the same AP".
Not really sure how I could have been more clear on that ...
Neither that message, nor the later ones with examples rules from SQL showed any rules which keyed off of SSID.
Among the sample attribute matching I pasted, there was : wifi_private | Called-Station-SSID | == | Private Which was meant to illustrate the "several SSID on the same AP".
Again, I can only go by what you say publicly. I'm not a mind reader.
And apparently not an English reader either. Cheers, Sylvain
While I'm sure all of this back and forth makes you happy, the reality is your messages didn't describe everything you wanted to do. Every message had new and different information. That's a problem. I can only go by what you say publicly. If your story keeps changing, that gives me incentive to go help someone else. Stop arguing, and give a *clear* and *accurate* description of the problem. Concentrate on technical solutions, instead of nit-picking my answers in an attempt to prove me wrong. This list is for people who want technical help, not people who fight with the people trying to help them. Alan DeKok.
On Mon, Feb 22, 2016 at 03:07:13PM +0100, Sylvain Munaut wrote:
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. 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...
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 and that's not the way it works at all in RADIUS, but at the time, I didn't know any better.
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. The example case of check-eap-tls (which is the reason I wrote it) is that we have here a Microsoft domain where all domain joined PCs are issued certificates, and can therefore connect. But we want to limit the ones that can connect to a particular subset of machines. 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. This doesn't hold for other parts of FreeRADIUS. Users can log in because they're in the users file, or a database, etc. Adding them to those data sources is like issuing the certificate. Not having them in the database means they can't connect. FreeRADIUS doesn't just let anyone connect when you've not permitted them to. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
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
On Feb 22, 2016, at 10:28 AM, Sylvain Munaut <s.munaut@whatever-company.com> wrote:
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.
That has *nothing to do with EAP-TLS*. You're again confusing two unrelated issues.
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.
Which is why FreeRADIUS exposes the CN, and allows you to check it.
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.
Yes. The authentication process (PAP, CHAP, MS-CHAP) doesn't care where the Cleartext-Password came from. Because it doesn't matter.
FreeRADIUS doesn't just let anyone connect when you've not permitted them to.
I never said it did.
That's what you implied. Alan DeKok.
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.
That has *nothing to do with EAP-TLS*. You're again confusing two unrelated issues.
Do you even read what I write ? Matthew wrote : "if you can present a valid certificate then you are permitted to connect." To which I responded : """ 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. """ WHERE in that am I mixing things up ?!?
FreeRADIUS doesn't just let anyone connect when you've not permitted them to.
I never said it did.
That's what you implied.
I definitely didn't mean to imply anything of the sort. I already apologized if it sounded that way but there is really nothing I can do if you don't believe me ... Cheers, Sylvain
On Feb 22, 2016, at 10:46 AM, Sylvain Munaut <s.munaut@whatever-company.com> wrote:
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.
That has *nothing to do with EAP-TLS*. You're again confusing two unrelated issues.
Do you even read what I write ?
Carefully.
Matthew wrote :
"if you can present a valid certificate then you are permitted to connect."
To which I responded :
""" 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. """
WHERE in that am I mixing things up ?!?
*How* the user authenticated themselves is completely independent of *what* the user is allowed to do. Alan DeKok.
On Mon, Feb 22, 2016 at 4:49 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Feb 22, 2016, at 10:46 AM, Sylvain Munaut <s.munaut@whatever-company.com> wrote:
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.
That has *nothing to do with EAP-TLS*. You're again confusing two unrelated issues.
Do you even read what I write ?
Carefully.
Matthew wrote :
"if you can present a valid certificate then you are permitted to connect."
To which I responded :
""" 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. """
WHERE in that am I mixing things up ?!?
*How* the user authenticated themselves is completely independent of *what* the user is allowed to do.
!?! And where exactly in my statement do I say anything that contradicts that ? Cheers, Sylvain
participants (3)
-
Alan DeKok -
Matthew Newton -
Sylvain Munaut