Hi,
I´m trying to figure out how to practically use RADIUS to authenticate users.
So far, I have only found documentation explaining that the idea is that users somehow magically need to authenticate against a RADIUS server via a device like a switch or a wireless access point before they are given or being denied access to a network. I understand that I have to refer to the documentation of the switch or access point to figure out how to set up RADIUS authentication with the particular device.
But how is this achieved in practice? Let´s say I have a couple laptops and a couple phones and a couple computers which connect either to a switch or to a wireless access point. Both the switch and the access point support RADIUS, and I would set them up to talk to the RADIUS server and require every device that wants to connect to the network through them to authenticate first. I also have a couple thin clients and a couple computers which use PXE-boot, and the users of those would have to provide authentication before the machines could even boot.
Then what? How do I make it so that the users are actually able to authenticate?
Is there any documentation about this? Or am I not supposed to use RADIUS but something else?
Hi,
Radius is a AAA protocol (Authorization, Aurhentication and Accounting) you can use rhe three methods or only one of them.
Authentication can be done by usong a Freeradius Server, aitvorization will give a userr profile with certain privileges for example In a network connection, and accounting (user connection details) can be registered In a MySQL database if needed.
Check for guodes con how to install and use Freeradiua on CentOS.
Regards,
El miércoles, 14 de febrero de 2018, hw hw@gc-24.de escribió:
Hi,
I´m trying to figure out how to practically use RADIUS to authenticate users.
So far, I have only found documentation explaining that the idea is that users somehow magically need to authenticate against a RADIUS server via a device like a switch or a wireless access point before they are given or being denied access to a network. I understand that I have to refer to the documentation of the switch or access point to figure out how to set up RADIUS authentication with the particular device.
But how is this achieved in practice? Let´s say I have a couple laptops and a couple phones and a couple computers which connect either to a switch or to a wireless access point. Both the switch and the access point support RADIUS, and I would set them up to talk to the RADIUS server and require every device that wants to connect to the network through them to authenticate first. I also have a couple thin clients and a couple computers which use PXE-boot, and the users of those would have to provide authentication before the machines could even boot.
Then what? How do I make it so that the users are actually able to authenticate?
Is there any documentation about this? Or am I not supposed to use RADIUS but something else? _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Javier Romero wrote:
Hi,
Radius is a AAA protocol (Authorization, Aurhentication and Accounting) you can use rhe three methods or only one of them.
Authentication can be done by usong a Freeradius Server, aitvorization will give a userr profile with certain privileges for example In a network connection, and accounting (user connection details) can be registered In a MySQL database if needed.
Check for guodes con how to install and use Freeradiua on CentOS.
Thanks, this is what I already know. Installing RADUIS isn´t a problem, either.
But what do I do then?
On 02/14/2018 08:37 AM, hw wrote:
Then what? How do I make it so that the users are actually able to authenticate?
Look for documentation on 802.11x authentication for the specific client you want to authenticate.
WiFi is pretty straightforward. You're probably accustomed to authenticating with WPA2 Personal. With RADIUS, you'll use WPA2 Enterprise. Users will be asked for their RADIUS credentials when you select that option.
Ethernet is fairly similar to WPA2 Enterprise for WiFi. Under GNOME, for instance, you can open the Network configuration tool, click on the configuration gear for the wired connection, and then select the Security tab. Tun on 802.1x Security, and then you'll have the option to select an authentication type that matches your switch and RADIUS configuration. This will vary from client platform to client platform, but it's basically the same as WiFi authentication:
Gordon Messmer wrote:
On 02/14/2018 08:37 AM, hw wrote:
Then what? How do I make it so that the users are actually able to authenticate?
Look for documentation on 802.11x authentication for the specific client you want to authenticate.
Thanks, I figured it is what I might need to look into. How about a client that uses PXE boot?
WiFi is pretty straightforward. You're probably accustomed to authenticating with WPA2 Personal. With RADIUS, you'll use WPA2 Enterprise. Users will be asked for their RADIUS credentials when you select that option.
That seems neither useful, nor feasible for customers wanting to use the wireless network we would set up for them with their cell phones. Are cell phones even capable of this kind of authentication?
Ethernet is fairly similar to WPA2 Enterprise for WiFi. Under GNOME, for instance, you can open the Network configuration tool, click on the configuration gear for the wired connection, and then select the Security tab. Tun on 802.1x Security, and then you'll have the option to select an authentication type that matches your switch and RADIUS configuration. This will vary from client platform to client platform, but it's basically the same as WiFi authentication:
I´m not using gnome; I recently tried it, and it´s totally bloated, yet doesn´t even have a usable window manager.
Anyway, there are some clients that can probably authenticate, which leaves the ones that use PXE boot. I tried things out with a switch, and it would basically work. If it makes sense to go any further with this and how now needs to be determined ...
https://en.wikipedia.org/wiki/IEEE_802.1X#Supplicants
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Thu, 22 Feb 2018, hw wrote:
That seems neither useful, nor feasible for customers wanting to use the wireless network we would set up for them with their cell phones. Are cell phones even capable of this kind of authentication?
Yes, entirely capable. WPA2-Enterprise isn't some freakish and unusual solution.
I configure wireless once on my device (phone/tablet/laptop) and then can travel to institutions all round the world and use their networks seamlessly. How useless and infeasible indeed.
Anyway, there are some clients that can probably authenticate, which leaves the ones that use PXE boot. I tried things out with a switch, and it would basically work. If it makes sense to go any further with this and how now needs to be determined ...
A client that can't authenticate gets the network it's provided with by being unauthenticated. If an unauthenticated client can't have any network access, that's what they get. Presumably you could drop an unauthenticated machine into a different VLAN.
jh
John Hodrien wrote:
On Thu, 22 Feb 2018, hw wrote:
That seems neither useful, nor feasible for customers wanting to use the wireless network we would set up for them with their cell phones. Are cell phones even capable of this kind of authentication?
Yes, entirely capable. WPA2-Enterprise isn't some freakish and unusual solution.
Ok, so it would at least be possible.
I configure wireless once on my device (phone/tablet/laptop) and then can travel to institutions all round the world and use their networks seamlessly. How useless and infeasible indeed.
Well, this country is almost the worst of all countries around the world when it comes to internet access. Though they list a few locations here where you supposedly could use their service, I wouldn´t expect anything. Then there´s the question of protecting your privacy. For example, how much do they pay you for allowing them to keep track of your travels?
In any case, it wouldn´t do our customers any good because there aren´t places all over the world where they could use our network.
Anyway, there are some clients that can probably authenticate, which leaves the ones that use PXE boot. I tried things out with a switch, and it would basically work. If it makes sense to go any further with this and how now needs to be determined ...
A client that can't authenticate gets the network it's provided with by being unauthenticated. If an unauthenticated client can't have any network access, that's what they get. Presumably you could drop an unauthenticated machine into a different VLAN.
That would be a problem because clients using PXE-boot require network access, and it wouldn´t contribute to security if unauthorized clients were allwed to PXE-boot.
John Hodrien wrote:
On Fri, 23 Feb 2018, hw wrote:
That would be a problem because clients using PXE-boot require network access, and it wouldn´t contribute to security if unauthorized clients were allwed to PXE-boot.
What problem are you actually trying to solve?
There are multiple problems like providing employees and customers with LAN and/or internet access and making the network more secure: When using RADIUS for keeping track of employees and customers, why not use it for more security as well.
Network access is not the only thing authentication is needed for. Perhaps RADIUS can be used for other things as well; I don´t know what all you can use it for.
On Fri, Feb 23, 2018 at 10:33 AM, hw hw@gc-24.de wrote:
That would be a problem because clients using PXE-boot require network access, and it wouldn´t contribute to security if unauthorized clients were allwed to PXE-boot.
Two solutions to this:
1. Enable "exception by MAC address": only known MAC addresses get put onto the PXE boot VLAN. Other unauthenticated client goes onto a "no access" VLAN (many places make this the same VLAN as the guest WiFi VLAN with internet access only, sometimes with a captive portal). Authenticated clients go onto the corporate VLAN. 2. (this can be in addition or instead of 1). The PXE server itself will only serve known MAC addresses and/or requires a token/password to initiate the install. Regardless, there's not huge utility to installing your personal machine with a corporate build from a PXE server, which you then can't use because you don;t have corporate credentials, but I suppose it may have some risk with regards to software licensing or builds containing other stuff you don't want strangers to access, so lockdowns can't hurt.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Richard Grainger wrote:
On Fri, Feb 23, 2018 at 10:33 AM, hw hw@gc-24.de wrote:
That would be a problem because clients using PXE-boot require network access, and it wouldn´t contribute to security if unauthorized clients were allwed to PXE-boot.
Two solutions to this:
- Enable "exception by MAC address": only known MAC addresses get put
onto the PXE boot VLAN. Other unauthenticated client goes onto a "no access" VLAN (many places make this the same VLAN as the guest WiFi VLAN with internet access only, sometimes with a captive portal). Authenticated clients go onto the corporate VLAN. 2. (this can be in addition or instead of 1). The PXE server itself will only serve known MAC addresses and/or requires a token/password to initiate the install. Regardless, there's not huge utility to installing your personal machine with a corporate build from a PXE server, which you then can't use because you don;t have corporate credentials, but I suppose it may have some risk with regards to software licensing or builds containing other stuff you don't want strangers to access, so lockdowns can't hurt.
But MAC addresses can be faked, can´t they?
On Fri, Feb 23, 2018 at 11:25 AM, hw hw@gc-24.de wrote:
But MAC addresses can be faked, can´t they?
Yes, someone can go to the trouble of obtaining a known corporate MAC address and MAC-spoofing their personal device so they can PXE-boot a corporate build on a VLAN that is otherwise useless. If your corporate build on it's own is precious enough in itself that you worry about this eventuality, then make the build server insist on authentication before the build initiates.
Richard Grainger wrote:
On Fri, Feb 23, 2018 at 11:25 AM, hw hw@gc-24.de wrote:
But MAC addresses can be faked, can´t they?
Yes, someone can go to the trouble of obtaining a known corporate MAC address and MAC-spoofing their personal device so they can PXE-boot a corporate build on a VLAN that is otherwise useless. If your corporate build on it's own is precious enough in itself that you worry about this eventuality, then make the build server insist on authentication before the build initiates.
What´s the point in designing a security measure intended to prevent unauthorized network access in such a way that it can be as easily circumvented as it is to fake MAC addresses?
I configure wireless once on my device (phone/tablet/laptop) and then can travel to institutions all round the world and use their networks seamlessly. How useless and infeasible indeed.
Well, this country
"this country"?
is almost the worst of all countries around the world when it comes to internet access. Though they list a few locations here where you supposedly could use their service, I wouldn´t expect anything. Then there´s the question of protecting your privacy. For example, how much do they pay you for allowing them to keep track of your travels?
I think you've got the wrong idea about eduroam. John Hodrien was just using it as a real world example of WPA2-enterprise in action. It's a private network for academic institutions - it allows members of Universities around the world to gain access to the wifi at a local University they are visiting. It's not a public wifi service.
It's a convenience - a very, very convenient convenience. If you don't want someone tracking where you are, then don't use it. But TBH if you are visiting another university, then in general your location is known!
In any case, it wouldn´t do our customers any good because there aren´t places all over the world where they could use our network.
Your customers wouldn't be able to use it anyway
A client that can't authenticate gets the network it's provided with by being unauthenticated. If an unauthenticated client can't have any network access, that's what they get. Presumably you could drop an unauthenticated machine into a different VLAN.
That would be a problem because clients using PXE-boot require network access, and it wouldn´t contribute to security if unauthorized clients were allwed to PXE-boot.
So restrict based on MAC address at the PXE boot stage.
The PXE protocol, as far as I can see, has no concept of authorisation - although its certainly possible to introduce it after PXE has done its bit (but before imaging or whatever).
You may be better off with authenticating the DHCP using RADIUS, but it's a complex process which, by its very nature, requires some form of non-authenticated network access.
P.
Pete Biggs wrote:
I configure wireless once on my device (phone/tablet/laptop) and then can travel to institutions all round the world and use their networks seamlessly. How useless and infeasible indeed.
Well, this country
"this country"?
Germany
is almost the worst of all countries around the world when it comes to internet access. Though they list a few locations here where you supposedly could use their service, I wouldn´t expect anything. Then there´s the question of protecting your privacy. For example, how much do they pay you for allowing them to keep track of your travels?
I think you've got the wrong idea about eduroam. John Hodrien was just using it as a real world example of WPA2-enterprise in action. It's a private network for academic institutions - it allows members of Universities around the world to gain access to the wifi at a local University they are visiting. It's not a public wifi service.
It isn´t really private, either.
It's a convenience - a very, very convenient convenience. If you don't want someone tracking where you are, then don't use it. But TBH if you are visiting another university, then in general your location is known!
Without wireless, your general location may be known as in "visiting university X"; with wireless, your location is known as in "is currently in room X of building Z". That is quite a difference, and in either case, what about your privacy?
In any case, it wouldn´t do our customers any good because there aren´t places all over the world where they could use our network.
Your customers wouldn't be able to use it anyway
If there were places all over the world where they could use our network, they could.
A client that can't authenticate gets the network it's provided with by being unauthenticated. If an unauthenticated client can't have any network access, that's what they get. Presumably you could drop an unauthenticated machine into a different VLAN.
That would be a problem because clients using PXE-boot require network access, and it wouldn´t contribute to security if unauthorized clients were allwed to PXE-boot.
So restrict based on MAC address at the PXE boot stage.
MAC addresses could be faked.
The PXE protocol, as far as I can see, has no concept of authorisation
- although its certainly possible to introduce it after PXE has done
its bit (but before imaging or whatever).
You may be better off with authenticating the DHCP using RADIUS, but it's a complex process which, by its very nature, requires some form of non-authenticated network access.
So the solution might have to be not to use PXE-boot anymore. That would be a pity because it´s so convenient.
MAC addresses could be faked.
The PXE protocol, as far as I can see, has no concept of authorisation
- although its certainly possible to introduce it after PXE has done
its bit (but before imaging or whatever).
You may be better off with authenticating the DHCP using RADIUS, but it's a complex process which, by its very nature, requires some form of non-authenticated network access.
So the solution might have to be not to use PXE-boot anymore. That would be a pity because it´s so convenient.
PXE booting is nothing to do with installing or imaging machines. That process is done *after* PXE booting. All the PXE does is to tell the ethernet chip where to retrieve the PXE information from and what to retrieve, which is then downloaded by TFTP.
A prerequisite for PXE is DHCP - by the time your device does anything with PXE it's already accessed the network and got an IP address and so on. There is absolutely no way to prohibit access to your network without first allowing the device some access to your network in order to authenticate. The normal way around this is to use VLANs to segregate "dirty" unauthenticated machines - once it's authenticated it is moved onto a different VLAN and a new DHCP request initiated.
There's lots of information on this on the net - Google for something like 'PXE RADIUS' or 'PXE 802.1x' (hint: everyone uses VLANs).
P.
Pete Biggs wrote:
MAC addresses could be faked.
The PXE protocol, as far as I can see, has no concept of authorisation
- although its certainly possible to introduce it after PXE has done
its bit (but before imaging or whatever).
You may be better off with authenticating the DHCP using RADIUS, but it's a complex process which, by its very nature, requires some form of non-authenticated network access.
So the solution might have to be not to use PXE-boot anymore. That would be a pity because it´s so convenient.
PXE booting is nothing to do with installing or imaging machines. That process is done *after* PXE booting. All the PXE does is to tell the ethernet chip where to retrieve the PXE information from and what to retrieve, which is then downloaded by TFTP.
I know, and it´s still convenient.
A prerequisite for PXE is DHCP - by the time your device does anything with PXE it's already accessed the network and got an IP address and so on. There is absolutely no way to prohibit access to your network without first allowing the device some access to your network in order to authenticate. The normal way around this is to use VLANs to segregate "dirty" unauthenticated machines - once it's authenticated it is moved onto a different VLAN and a new DHCP request initiated.
Suddenly moving the client to a different VLAN would have the same effect as unplugging the network cable: it would freeze until the connection is restored. Otherwise, the server would have to be reachable via several VLANs, which would make it pointless to use these VLANs.
There's lots of information on this on the net - Google for something like 'PXE RADIUS' or 'PXE 802.1x' (hint: everyone uses VLANs).
Ok.
A prerequisite for PXE is DHCP - by the time your device does anything with PXE it's already accessed the network and got an IP address and so on. There is absolutely no way to prohibit access to your network without first allowing the device some access to your network in order to authenticate. The normal way around this is to use VLANs to segregate "dirty" unauthenticated machines - once it's authenticated it is moved onto a different VLAN and a new DHCP request initiated.
Suddenly moving the client to a different VLAN would have the same effect as unplugging the network cable: it would freeze until the connection is restored. Otherwise, the server would have to be reachable via several VLANs, which would make it pointless to use these VLANs.
It depends on at which point you switch VLANs. If you use authenticated DHCP then the process is to get an IP address on a dirty VLAN, authenticate, switch VLAN, get a new IP address, boot to PXE. There are extensions in the DHCP protocol to accommodate this.
It's also possible that the PXE environment can deal with the authentication - PXE runs solely on the local machine, so it doesn't care about VLANs changing so long as when it wants to do something it has a valid IP address for the VLAN it is assigned to.
And at this point, I think this is no longer CentOS related. If you can't find out what you need on the net, you need to hire a network consultant to deal with it. Asking a zillion random questions on a mailing list just because you can't find or understand the information elsewhere and fighting against the answers you are given is not very productive for anyone.
P.
Pete Biggs wrote:
A prerequisite for PXE is DHCP - by the time your device does anything with PXE it's already accessed the network and got an IP address and so on. There is absolutely no way to prohibit access to your network without first allowing the device some access to your network in order to authenticate. The normal way around this is to use VLANs to segregate "dirty" unauthenticated machines - once it's authenticated it is moved onto a different VLAN and a new DHCP request initiated.
Suddenly moving the client to a different VLAN would have the same effect as unplugging the network cable: it would freeze until the connection is restored. Otherwise, the server would have to be reachable via several VLANs, which would make it pointless to use these VLANs.
It depends on at which point you switch VLANs. If you use authenticated DHCP then the process is to get an IP address on a dirty VLAN, authenticate, switch VLAN, get a new IP address, boot to PXE. There are extensions in the DHCP protocol to accommodate this.
Like using MAC addresses?
It's also possible that the PXE environment can deal with the authentication - PXE runs solely on the local machine, so it doesn't care about VLANs changing so long as when it wants to do something it has a valid IP address for the VLAN it is assigned to.
And at this point, I think this is no longer CentOS related. If you can't find out what you need on the net, you need to hire a network consultant to deal with it. Asking a zillion random questions on a mailing list just because you can't find or understand the information elsewhere and fighting against the answers you are given is not very productive for anyone.
This hasn´t been Centos related to begin with, and I didn´t ask for a discussion but only for a pointer to documentation. My questions are not random, and perhaps the mailing list should better be closed so noone can ask anything.
On 02/22/2018 03:22 AM, hw wrote:
Gordon Messmer wrote:
Look for documentation on 802.11x authentication for the specific client you want to authenticate.
Thanks, I figured it is what I might need to look into. How about a client that uses PXE boot?
Provide PXE (dhcp, dns, tftp) on an unauthenticated VLAN. Your original email suggested that you'd want users to auth before a system would boot, but that's probably not possible. If you want to authenticate users via username and password using RADIUS, then there has to be an OS running to provide an interface in which they provide credentials. It's not really clear how else you'd imagine that working.
WiFi is pretty straightforward. You're probably accustomed to authenticating with WPA2 Personal. With RADIUS, you'll use WPA2 Enterprise. Users will be asked for their RADIUS credentials when you select that option.
That seems neither useful, nor feasible for customers wanting to use the wireless network we would set up for them with their cell phones. Are cell phones even capable of this kind of authentication?
Well, I guess I'm confused because having explained where you'd find the interface in which users will provide their RADIUS username and password, you think this process is unfeasible. Perhaps you could explain what you're looking for, more precisely?
Ethernet is fairly similar to WPA2 Enterprise for WiFi. Under GNOME, for instance, you can open the Network configuration tool, click on the configuration gear for the wired connection, and then select the Security tab. Tun on 802.1x Security, and then you'll have the option to select an authentication type that matches your switch and RADIUS configuration. This will vary from client platform to client platform, but it's basically the same as WiFi authentication:
I´m not using gnome; I recently tried it, and it´s totally bloated, yet doesn´t even have a usable window manager.
OK. I'm not sure how your opinion of GNOME is really relevant. I'm describing it because it's an example that's probably within reach for both you and me, given that you and I are communicating via a GNU/Linux focused mailing list.
I'm sorry my voluntary attempt to help you out wasn't to your liking.
Gordon Messmer wrote:
On 02/22/2018 03:22 AM, hw wrote:
Gordon Messmer wrote:
Look for documentation on 802.11x authentication for the specific client you want to authenticate.
Thanks, I figured it is what I might need to look into. How about a client that uses PXE boot?
Provide PXE (dhcp, dns, tftp) on an unauthenticated VLAN. Your original email suggested that you'd want users to auth before a system would boot, but that's probably not possible. If you want to authenticate users via username and password using RADIUS, then there has to be an OS running to provide an interface in which they provide credentials. It's not really clear how else you'd imagine that working.
I´m not sure how to imagine it. It would be nice if every device connecting to the network, wirelessly or otherwise, had to be authenticated --- and not only the device, but also the user(s) using it.
There are devices that are using PXE-boot and require access to the company LAN. If I was to allow PXE-boot for unauthenticated devices, the whole thing would be pointless because it would defeat any security advantage that could be gained by requiring all devices and users to be authenticated: Anyone could bring a device capable of PXE-booting and get network access.
WiFi is pretty straightforward. You're probably accustomed to authenticating with WPA2 Personal. With RADIUS, you'll use WPA2 Enterprise. Users will be asked for their RADIUS credentials when you select that option.
That seems neither useful, nor feasible for customers wanting to use the wireless network we would set up for them with their cell phones. Are cell phones even capable of this kind of authentication?
Well, I guess I'm confused because having explained where you'd find the interface in which users will provide their RADIUS username and password, you think this process is unfeasible. Perhaps you could explain what you're looking for, more precisely?
As a customer visting a store, would you go to the lengths of configuring your cell phone (or other wireless device) to authenticate with a RADIUS server in order to gain internet access through the wirless network of the store?
From what I´m being told, everyone already has internet access with their cell phones from their phone service provider and is apparently happy with that even though the amount of data they can transmit is ridiculously low. So why would anyone do any configuring and have to worry about protecting ther privacy when and for using the wireless network of a shop they´re visting?
I have no idea what the lengths of configuring might be other than that anything you try to do with a cell phone or a tablet is so extremely painful or outright impossible that I only touch them when I get paid for it. Perhaps RADIUS authentication is easy with such devices.
Ethernet is fairly similar to WPA2 Enterprise for WiFi. Under GNOME, for instance, you can open the Network configuration tool, click on the configuration gear for the wired connection, and then select the Security tab. Tun on 802.1x Security, and then you'll have the option to select an authentication type that matches your switch and RADIUS configuration. This will vary from client platform to client platform, but it's basically the same as WiFi authentication:
I´m not using gnome; I recently tried it, and it´s totally bloated, yet doesn´t even have a usable window manager.
OK. I'm not sure how your opinion of GNOME is really relevant. I'm describing it because it's an example that's probably within reach for both you and me, given that you and I are communicating via a GNU/Linux focused mailing list.
I'm sorry my voluntary attempt to help you out wasn't to your liking.
Don´t be sorry, there´s nothing wrong with your help, and I appreciate it.
Just keep in mind when you say that the opinions of users of software X are irrelevant, software X itself is as irrelevant as the opinions.
On Fri, Feb 23, 2018 at 11:22 AM, hw hw@gc-24.de wrote:
As a customer visting a store, would you go to the lengths of configuring your cell phone (or other wireless device) to authenticate with a RADIUS server in order to gain internet access through the wirless network of the store?
From what I´m being told, everyone already has internet access with their cell phones from their phone service provider and is apparently happy with that even though the amount of data they can transmit is ridiculously low. So why would anyone do any configuring and have to worry about protecting ther privacy when and for using the wireless network of a shop they´re visting?
I have no idea what the lengths of configuring might be other than that anything you try to do with a cell phone or a tablet is so extremely painful or outright impossible that I only touch them when I get paid for it. Perhaps RADIUS authentication is easy with such devices.
Corporate mobile devices are typically configured using MDM to already have the company 802.1x profile so they "just work" on the corporate WiFi. Guest mobile devices will connect to another SSID, which usually only allows access to the internet (sometimes after agreeing to a AUP via a captive web portal).
Richard Grainger wrote:
On Fri, Feb 23, 2018 at 11:22 AM, hw hw@gc-24.de wrote:
As a customer visting a store, would you go to the lengths of configuring your cell phone (or other wireless device) to authenticate with a RADIUS server in order to gain internet access through the wirless network of the store?
From what I´m being told, everyone already has internet access with their cell phones from their phone service provider and is apparently happy with that even though the amount of data they can transmit is ridiculously low. So why would anyone do any configuring and have to worry about protecting ther privacy when and for using the wireless network of a shop they´re visting?
I have no idea what the lengths of configuring might be other than that anything you try to do with a cell phone or a tablet is so extremely painful or outright impossible that I only touch them when I get paid for it. Perhaps RADIUS authentication is easy with such devices.
Corporate mobile devices are typically configured using MDM to already have the company 802.1x profile so they "just work" on the corporate WiFi.
MDM? I´ve never heared that before; might be worthwhile to look into.
Guest mobile devices will connect to another SSID, which usually only allows access to the internet (sometimes after agreeing to a AUP via a captive web portal).
Yes, that´s one of the ideas. Another idea is to allow unregistered customers access for a limited amount of time and allowing registered customers (like regular customers having a customer card) an unlimited amount of time. I have no idea yet how I would limit the time.
That requires some way to distinguish between customers, and it means that distinguishing between devices is not sufficient for registered customers.
On Fri, Feb 23, 2018 at 12:56 PM, hw hw@gc-24.de wrote:
That requires some way to distinguish between customers, and it means that distinguishing between devices is not sufficient for registered customers.
Once the customer logs into the captive web portal on the guest WiFi SSID you know who they are and can set limits accordingly.
Richard Grainger wrote:
On Fri, Feb 23, 2018 at 12:56 PM, hw hw@gc-24.de wrote:
That requires some way to distinguish between customers, and it means that distinguishing between devices is not sufficient for registered customers.
Once the customer logs into the captive web portal on the guest WiFi SSID you know who they are and can set limits accordingly.
How do I deploy such a captive portal? It seems that a wireless controller can do that, but I don´t have one (yet).
On Fri, Feb 23, 2018 at 1:57 PM, hw hw@gc-24.de wrote:
Richard Grainger wrote:
On Fri, Feb 23, 2018 at 12:56 PM, hw hw@gc-24.de wrote:
That requires some way to distinguish between customers, and it means that distinguishing between devices is not sufficient for registered customers.
Once the customer logs into the captive web portal on the guest WiFi SSID you know who they are and can set limits accordingly.
How do I deploy such a captive portal? It seems that a wireless controller can do that, but I don´t have one (yet).
I can't recommend a particular commercial product or free solution, sorry.
There are devices that are using PXE-boot and require access to the company LAN. If I was to allow PXE-boot for unauthenticated devices, the whole thing would be pointless because it would defeat any security advantage that could be gained by requiring all devices and users to be authenticated: Anyone could bring a device capable of PXE-booting and get network access.
So authenticate before imaging. Lots of imaging solutions allow that - even the MS WDS does it.
As a customer visting a store, would you go to the lengths of configuring your cell phone (or other wireless device) to authenticate with a RADIUS server in order to gain internet access through the wirless network of the store?
Yes, I do it frequently with my phone. You do it once and it remembers it. My phone is more often on wifi than on 4G when I'm in a town.
From what I´m being told, everyone already has internet access with their cell phones from their phone service provider and is apparently happy with that even though the amount of data they can transmit is ridiculously low. So why would anyone do any configuring and have to worry about protecting ther privacy when and for using the wireless network of a shop they´re visting?
Because you get faster data rates and in the middle of a big shop you don't get a phone signal.
I have no idea what the lengths of configuring might be other than that anything you try to do with a cell phone or a tablet is so extremely painful or outright impossible that I only touch them when I get paid for it. Perhaps RADIUS authentication is easy with such devices.
In general the user knows nothing about RADIUS - you are presented with a username/password box when you first connect to the wifi and that is it.
I´m not using gnome; I recently tried it, and it´s totally bloated, yet doesn´t even have a usable window manager.
OK. I'm not sure how your opinion of GNOME is really relevant. I'm describing it because it's an example that's probably within reach for both you and me, given that you and I are communicating via a GNU/Linux focused mailing list.
I'm sorry my voluntary attempt to help you out wasn't to your liking.
Don´t be sorry, there´s nothing wrong with your help, and I appreciate it.
Just keep in mind when you say that the opinions of users of software X are irrelevant, software X itself is as irrelevant as the opinions.
Exactly. "Software X" was an example of how it could be done. It doesn't matter what your opinions are about it. Other software is available. You seem to be taking the examples that people give you as the only possible way of doing things.
RADIUS is a very mature technology and as such there are lots of ways of using it.
P.
Pete Biggs wrote:
There are devices that are using PXE-boot and require access to the company LAN. If I was to allow PXE-boot for unauthenticated devices, the whole thing would be pointless because it would defeat any security advantage that could be gained by requiring all devices and users to be authenticated: Anyone could bring a device capable of PXE-booting and get network access.
So authenticate before imaging. Lots of imaging solutions allow that - even the MS WDS does it.
Well, I don´t have an imaging solution and no idea how to do that.
As a customer visting a store, would you go to the lengths of configuring your cell phone (or other wireless device) to authenticate with a RADIUS server in order to gain internet access through the wirless network of the store?
Yes, I do it frequently with my phone. You do it once and it remembers it. My phone is more often on wifi than on 4G when I'm in a town.
And you need to install certificates or enter a password or something?
From what I´m being told, everyone already has internet access with their cell phones from their phone service provider and is apparently happy with that even though the amount of data they can transmit is ridiculously low. So why would anyone do any configuring and have to worry about protecting ther privacy when and for using the wireless network of a shop they´re visting?
Because you get faster data rates and in the middle of a big shop you don't get a phone signal.
How do you get faster data rates? In a shop that even has a 100Mbit internet connection and 50 customers using it, you would get only 2Mbit.
How do the shops prevent you from getting a phone signal?
I have no idea what the lengths of configuring might be other than that anything you try to do with a cell phone or a tablet is so extremely painful or outright impossible that I only touch them when I get paid for it. Perhaps RADIUS authentication is easy with such devices.
In general the user knows nothing about RADIUS - you are presented with a username/password box when you first connect to the wifi and that is it.
Those are particularly painful to enter, but I guess it could be used for some customers.
I´m not using gnome; I recently tried it, and it´s totally bloated, yet doesn´t even have a usable window manager.
OK. I'm not sure how your opinion of GNOME is really relevant. I'm describing it because it's an example that's probably within reach for both you and me, given that you and I are communicating via a GNU/Linux focused mailing list.
I'm sorry my voluntary attempt to help you out wasn't to your liking.
Don´t be sorry, there´s nothing wrong with your help, and I appreciate it.
Just keep in mind when you say that the opinions of users of software X are irrelevant, software X itself is as irrelevant as the opinions.
Exactly. "Software X" was an example of how it could be done. It doesn't matter what your opinions are about it. Other software is available. You seem to be taking the examples that people give you as the only possible way of doing things.
RADIUS is a very mature technology and as such there are lots of ways of using it.
Well, I don´t know about any of this. I found out that RADIUS is probably what I could or should use to get things working as intended, so I tried to find documentation on /how/ to use it and found nothing but documentation which says that it could be used, which I already know.
So I tried it to a limited extend and found that it could and probably should be used.
Yes, I do it frequently with my phone. You do it once and it remembers it. My phone is more often on wifi than on 4G when I'm in a town.
And you need to install certificates or enter a password or something?
Yes. Just once, then things are remembered and you can seemlessly roam between various APs and networks.
Because you get faster data rates and in the middle of a big shop you don't get a phone signal.
How do you get faster data rates? In a shop that even has a 100Mbit internet connection and 50 customers using it, you would get only 2Mbit.
4G isn't ubiquitous, 3G/EDGE is still common - and phone networks are patchy and slow.
How do the shops prevent you from getting a phone signal?
Why "prevent"? I never said that. Shops are essentially big metal boxes covered in wires and fluorescent lights, with the phone transmitter outside and an indeterminate distance away. Phone signals are weak and attenuated by the big metal box so your phone gives up on the network. Shops provide a "free" wifi as a service to its customers (nothing is free, they get the chance to harvest information about your presence in the store - if you don't like it, don't use their wifi, it's not compulsory).
In general the user knows nothing about RADIUS - you are presented with a username/password box when you first connect to the wifi and that is it.
Those are particularly painful to enter, but I guess it could be used for some customers.
<sigh> yes, mobile devices can be awkward to type on. If they had full size keyboards they wouldn't be easy to fit in your pocket.
RADIUS is a very mature technology and as such there are lots of ways of using it.
Well, I don´t know about any of this. I found out that RADIUS is probably what I could or should use to get things working as intended, so I tried to find documentation on /how/ to use it and found nothing but documentation which says that it could be used, which I already know.
RADIUS is just the authentication mechanism. Often that is a backend process and comes along with something that says "authentication can be provided by LDAP, RADIUS or ....". All the other things like PXE or WPA or 802.1x or VPN or whatever is frontend technology and use a RADIUS server to authenticate.
P.
Pete Biggs wrote:
Yes, I do it frequently with my phone. You do it once and it remembers it. My phone is more often on wifi than on 4G when I'm in a town.
And you need to install certificates or enter a password or something?
Yes. Just once, then things are remembered and you can seemlessly roam between various APs and networks.
What do you need internet access so urgently for while you´re in a shop?
Because you get faster data rates and in the middle of a big shop you don't get a phone signal.
How do you get faster data rates? In a shop that even has a 100Mbit internet connection and 50 customers using it, you would get only 2Mbit.
4G isn't ubiquitous, 3G/EDGE is still common - and phone networks are patchy and slow.
Then why do ppl pay so much for it?
How do the shops prevent you from getting a phone signal?
Why "prevent"?
They somehow have to prevent you, or you would get a signal.
I never said that. Shops are essentially big metal boxes covered in wires and fluorescent lights, with the phone transmitter outside and an indeterminate distance away. Phone signals are weak and attenuated by the big metal box so your phone gives up on the network.
Phone signals are fine here. We would need to somehow block the signals.
Shops provide a "free" wifi as a service to its customers (nothing is free, they get the chance to harvest information about your presence in the store - if you don't like it, don't use their wifi, it's not compulsory).
right
In general the user knows nothing about RADIUS - you are presented with a username/password box when you first connect to the wifi and that is it.
Those are particularly painful to enter, but I guess it could be used for some customers.
<sigh> yes, mobile devices can be awkward to type on. If they had full size keyboards they wouldn't be easy to fit in your pocket.
RADIUS is a very mature technology and as such there are lots of ways of using it.
Well, I don´t know about any of this. I found out that RADIUS is probably what I could or should use to get things working as intended, so I tried to find documentation on /how/ to use it and found nothing but documentation which says that it could be used, which I already know.
RADIUS is just the authentication mechanism. Often that is a backend process and comes along with something that says "authentication can be provided by LDAP, RADIUS or ....".
Something like?
All the other things like PXE or WPA or 802.1x or VPN or whatever is frontend technology and use a RADIUS server to authenticate.
I thought PXE doesn´t?
On Fri, 23 Feb 2018, hw wrote:
There are devices that are using PXE-boot and require access to the company LAN. If I was to allow PXE-boot for unauthenticated devices, the whole thing would be pointless because it would defeat any security advantage that could be gained by requiring all devices and users to be authenticated: Anyone could bring a device capable of PXE-booting and get network access.
I'd hope that you could involve TPM in this game. PXE to unauthenticated VLAN, boot an OS that could then use TPM to pull out a credential to authenticate to the network and switch to another VLAN.
As a customer visting a store, would you go to the lengths of configuring your cell phone (or other wireless device) to authenticate with a RADIUS server in order to gain internet access through the wirless network of the store?
No, I'd never offer wireless network access this way. Typically, you either offer it unauthenticated, or you provide it via a captive web portal.
jh
John Hodrien wrote:
On Fri, 23 Feb 2018, hw wrote:
There are devices that are using PXE-boot and require access to the company LAN. If I was to allow PXE-boot for unauthenticated devices, the whole thing would be pointless because it would defeat any security advantage that could be gained by requiring all devices and users to be authenticated: Anyone could bring a device capable of PXE-booting and get network access.
I'd hope that you could involve TPM in this game. PXE to unauthenticated VLAN, boot an OS that could then use TPM to pull out a credential to authenticate to the network and switch to another VLAN.
Besides that I have no idea how to do this: When switching over to a different VLAN, access to the server the client has booted from would go away, and the client would freeze until the connection is back. It would be the same effect as unplugging the network cable.
Those clients are x2go clients, and they boot from the same VM the users work on via these clients. I don´t think the clients will continue to work when pulling the connection to the boot device while leaving them connected to the x2go server, and it would require the x2go server to be reachable via a VLAN that provides unauthenticated access.
I never used TPM. Apparently it requires machines supporting it because some have an entry in their BIOS for it, and you need some sort of unknown hardware module nobody has.
As a customer visting a store, would you go to the lengths of configuring your cell phone (or other wireless device) to authenticate with a RADIUS server in order to gain internet access through the wirless network of the store?
No, I'd never offer wireless network access this way. Typically, you either offer it unauthenticated, or you provide it via a captive web portal.
Would you consider a captive portal as user friendly?
On 02/23/2018 03:22 AM, hw wrote:
I´m not sure how to imagine it. It would be nice if every device connecting to the network, wirelessly or otherwise, had to be authenticated --- and not only the device, but also the user(s) using it.
https://www.networkworld.com/article/2940463/it-skills-training/machine-auth...
I've never seen anyone actually do this, but there's an article discussing it. It is noteworthy that this requires enforcement in the client OS, as well as the switch.
There are devices that are using PXE-boot and require access to the company LAN. If I was to allow PXE-boot for unauthenticated devices, the whole thing would be pointless because it would defeat any security advantage that could be gained by requiring all devices and users to be authenticated: Anyone could bring a device capable of PXE-booting and get network access.
You don't seem to understand the suggestions you're being given.
An unauthenticated device should be placed on a VLAN with appropriate access. If you have devices that need to PXE boot before authenticating, then you should have a VLAN that gives them DHCP service, DNS, and tftp to boot an OS. That VLAN shouldn't have access to the protected company resources, and it doesn't have to have Internet access either.
Once the system boots, the users can authenticate themselves, which will move the device onto a VLAN with access appropriate for an authenticated user.
Well, I guess I'm confused because having explained where you'd find the interface in which users will provide their RADIUS username and password, you think this process is unfeasible. Perhaps you could explain what you're looking for, more precisely?
As a customer visting a store, would you go to the lengths of configuring your cell phone (or other wireless device) to authenticate with a RADIUS server in order to gain internet access through the wirless network of the store?
Where do your hypothetical customers in a store get the user credentials that you want to authenticate via RADIUS?
I'm not sure I understand the use case you're describing. I'm not sure you do, either.
Gordon Messmer wrote:
On 02/23/2018 03:22 AM, hw wrote:
I´m not sure how to imagine it. It would be nice if every device connecting to the network, wirelessly or otherwise, had to be authenticated --- and not only the device, but also the user(s) using it.
https://www.networkworld.com/article/2940463/it-skills-training/machine-auth...
I've never seen anyone actually do this, but there's an article discussing it. It is noteworthy that this requires enforcement in the client OS, as well as the switch.
The article itself says that what it is describing only works within a Windoze world. It doesn´t apply at all here.
There are devices that are using PXE-boot and require access to the company LAN. If I was to allow PXE-boot for unauthenticated devices, the whole thing would be pointless because it would defeat any security advantage that could be gained by requiring all devices and users to be authenticated: Anyone could bring a device capable of PXE-booting and get network access.
You don't seem to understand the suggestions you're being given.
An unauthenticated device should be placed on a VLAN with appropriate access. If you have devices that need to PXE boot before authenticating, then you should have a VLAN that gives them DHCP service, DNS, and tftp to boot an OS. That VLAN shouldn't have access to the protected company resources, and it doesn't have to have Internet access either.
I understand that it is suggested that I should give all unauthorized devices network access (so that they can PXE boot or whatever), which is what I don´t want to do.
IIUC, when using RADIUS, devices can be denied network access before they get any because the switch or wirless access point the devices use to get network access negotiates access rights for the devices on behalf of the devices with the RADIUS server rather than that the devices are given network access to negotiate thier access rights themselves. That´s supposed to provide better security, and it makes sense to me.
Hence allowing unauthorized devices network access (to PXE boot and then to negotiate further access rights --- or whatever) doesn´t make any sense.
I also understand that it may be possible that there is a variety of PXE boot which addresses this problem by allowing devices to authenticate before they boot. However, some of the devices in question are likely to old to support this.
Once the system boots, the users can authenticate themselves, which will move the device onto a VLAN with access appropriate for an authenticated user.
Like I said in other posts, that´s probably not possible because when you cut the clients off from access to the server they booted from by moving them into a different VLAN, they will simply freeze until the connection is restored.
Well, I guess I'm confused because having explained where you'd find the interface in which users will provide their RADIUS username and password, you think this process is unfeasible. Perhaps you could explain what you're looking for, more precisely?
As a customer visting a store, would you go to the lengths of configuring your cell phone (or other wireless device) to authenticate with a RADIUS server in order to gain internet access through the wirless network of the store?
Where do your hypothetical customers in a store get the user credentials that you want to authenticate via RADIUS?
They might get it from employees of the store or read it from signs inside the store, perhaps depending on what kind of access rights they are supposed to have.
I'm not sure I understand the use case you're describing. I'm not sure you do, either.
Right --- that´s why I was asking for documentation about how RADIUS can be actually used rather than documentation only saying that it can be used but not how. You can´t very well design a use case for a particular software when you do not know what the software is capable of and if it is applicable at all, and you can not very well design the use case when you don´t even know if what you might want is possible. Yet you need to start somewhere to get somewhere.
Imagine you want to ride a horse and don´t know anything about horses. You look for documentation about horses, and the only documentations you can find are telling you that horses exist, how to get one and that they can be used for riding. How helpful is that?
I´m merely asking how to ride the darn horses. Perhaps I´m better off with a car, but I can´t tell before I know how to ride horses.
On 02/27/2018 08:21 AM, hw wrote:
Gordon Messmer wrote:
I've never seen anyone actually do this, but there's an article discussing it. It is noteworthy that this requires enforcement in the client OS, as well as the switch.
The article itself says that what it is describing only works within a Windoze world.
That's what I said.
(Also, "Windoze"? Can we at least pretend to be a community of professionals?)
I understand that it is suggested that I should give all unauthorized devices network access (so that they can PXE boot or whatever), which is what I don´t want to do.
It is illogical to lump all network access together into a single category.
If your device can communicate with a switch, even for the purpose of authenticating, then it has network access.
A device cannot authenticate if the processor is idle. The processor needs software in order to authenticate. If that software resides on an TFTP server, rather than a locally attached storage device, then the device needs limited network access to retrieve the software (after which it runs the software, authenticates the user or the device, and receives greater levels of network access.)
Providing a VLAN on which there are no private resources, and no Internet access, may be a required component if you have devices that boot via PXE. Honestly, people are trying to help you, but you are placing logically contradictory requirements on the project.
I also understand that it may be possible that there is a variety of PXE boot which addresses this problem by allowing devices to authenticate before they boot. However, some of the devices in question are likely to old to support this.
The device needs to have software adequate to authenticate itself or its user. It's logically possible to run software from some local storage, authenticate, retrieve a new software image from PXE, and then chainload that. If you don't have a device that does that, specifically, then you need to provide a VLAN that supports the devices you DO have.
Where do your hypothetical customers in a store get the user credentials that you want to authenticate via RADIUS?
They might get it from employees of the store or read it from signs inside the store, perhaps depending on what kind of access rights they are supposed to have.
If you're sharing passwords, then you don't need RADIUS. Set up separate SSIDs that are attached to VLANs with appropriate access levels, and continue using WPA2 Personal. Using RADIUS will be no more secure than that. It's not magic.
Imagine you want to ride a horse and don´t know anything about horses. You look for documentation about horses, and the only documentations you can find are telling you that horses exist, how to get one and that they can be used for riding. How helpful is that?
Imagine that someone is trying to help you learn to ride horses, and you spend all of your time complaining that you think animals are dirty. How helpful is that?
Gordon Messmer wrote:
On 02/27/2018 08:21 AM, hw wrote:
Gordon Messmer wrote:
I've never seen anyone actually do this, but there's an article discussing it. It is noteworthy that this requires enforcement in the client OS, as well as the switch.
The article itself says that what it is describing only works within a Windoze world.
That's what I said.
Well, it is not applicable here.
(Also, "Windoze"? Can we at least pretend to be a community of professionals?)
I understand that it is suggested that I should give all unauthorized devices network access (so that they can PXE boot or whatever), which is what I don´t want to do.
It is illogical to lump all network access together into a single category.
That depends on your point of view. When you have access to a network, you have better chances of being able to do something you´re not supposed to than you have when you don´t have any access at all. That doesn´t say anything about how it is logical or makes sense or not to create different categories of network access.
If your device can communicate with a switch, even for the purpose of authenticating, then it has network access.
The device has access to the switch which, depending on what answer to an authentication request it gets from a RADIUS server, decides if and how it lets the device access the network. Maybe that´s not how it works; it´s only what I´ve been reading.
A device cannot authenticate if the processor is idle. The processor needs software in order to authenticate. If that software resides on an TFTP server, rather than a locally attached storage device, then the device needs limited network access to retrieve the software (after which it runs the software, authenticates the user or the device, and receives greater levels of network access.)
Providing a VLAN on which there are no private resources, and no Internet access, may be a required component if you have devices that boot via PXE. Honestly, people are trying to help you, but you are placing logically contradictory requirements on the project.
You mean I´m not allowed to say that I don´t want to allow unauthorized devices to access the network and having some that use PXE boot because it makes ppl trying to help think that this is contradictory. I can´t help that because it is the situation I have to deal with. Live is generally full of contradictions, and everyone has to deal with that.
I don´t see what the problem is other than ppl trying to decide for me what I am allowed to say or to think or to have to deal with, and that is something I very much dislike. It isn´t helpful, either.
If PXE boot is not possible because it would require to allow network access to unauthorized devices, or if it is not reasonably feasible because switching the device to a different VLAN after allowing unauthorized access for booting and then providing credentials to authenticate the device (or the user) will result in the device freezing and thus being useless, then that just is so, and I have to deal with it.
I also understand that it may be possible that there is a variety of PXE boot which addresses this problem by allowing devices to authenticate before they boot. However, some of the devices in question are likely to old to support this.
The device needs to have software adequate to authenticate itself or its user. It's logically possible to run software from some local storage, authenticate, retrieve a new software image from PXE, and then chainload that. If you don't have a device that does that, specifically, then you need to provide a VLAN that supports the devices you DO have.
Other options would be not to use PXE boot or to allow the devices network access as needed.
Where do your hypothetical customers in a store get the user credentials that you want to authenticate via RADIUS?
They might get it from employees of the store or read it from signs inside the store, perhaps depending on what kind of access rights they are supposed to have.
If you're sharing passwords, then you don't need RADIUS. Set up separate SSIDs that are attached to VLANs with appropriate access levels, and continue using WPA2 Personal. Using RADIUS will be no more secure than that. It's not magic.
Right, but what about keeping track of customers? Apparently RADIUS has some accounting features, and it might be an advantage to use those.
Imagine you want to ride a horse and don´t know anything about horses. You look for documentation about horses, and the only documentations you can find are telling you that horses exist, how to get one and that they can be used for riding. How helpful is that?
Imagine that someone is trying to help you learn to ride horses, and you spend all of your time complaining that you think animals are dirty. How helpful is that?
This analogy doesn´t apply. It´s more like I´m wondering if the horse can be fast enough or haul the load I might need to get hauled or if it requires too much upkeep.
And when I say "I would need the horse to haul 1/4 ton while I can´t feed it more grain than I have", ppl trying to help are getting pissed because they think it´s somehow illogical having to deal with the given requirements. Yeah, well, logic can be pretty irrelevant in most situations.
This is really nothing to do with CentOS anymore, if it ever was.
On Thu, 1 Mar 2018, hw wrote:
If PXE boot is not possible because it would require to allow network access to unauthorized devices, or if it is not reasonably feasible because switching the device to a different VLAN after allowing unauthorized access for booting and then providing credentials to authenticate the device (or the user) will result in the device freezing and thus being useless, then that just is so, and I have to deal with it.
Why would that *have* to result in the device freezing? You can PXE boot to a kernel and initrd that after it's downloaded runs just fine without any network access at all.
There's no requirement for a PXE client to have network access to anything other than a VLAN with a boot server that provides it with a boot image. You can obviously add on frippery that only recognises approved MACs for even this if you feel the need.
Right, but what about keeping track of customers? Apparently RADIUS has some accounting features, and it might be an advantage to use those.
I really don't get why you want WPA2 Enterprise for this setup. There's a reason why almost everyone uses captive portals for providing access to lots of external users.
jh
John Hodrien wrote:
This is really nothing to do with CentOS anymore, if it ever was.
right
On Thu, 1 Mar 2018, hw wrote:
If PXE boot is not possible because it would require to allow network access to unauthorized devices, or if it is not reasonably feasible because switching the device to a different VLAN after allowing unauthorized access for booting and then providing credentials to authenticate the device (or the user) will result in the device freezing and thus being useless, then that just is so, and I have to deal with it.
Why would that *have* to result in the device freezing? You can PXE boot to a kernel and initrd that after it's downloaded runs just fine without any network access at all.
Like I said, they are x2go clients booting from the x2go server. Switching them to another VLAN from where they can´t reach the server is basically the same as unplugging the network cable, in which case they freeze until the connection is restored, and giving them access to the server so that they can boot before they are authorized is useless when I don´t want to allow network access for unauthorized clients, and it is pointless because they would already have the access they are supposed to have only after they are authorized.
There's no requirement for a PXE client to have network access to anything other than a VLAN with a boot server that provides it with a boot image. You can obviously add on frippery that only recognises approved MACs for even this if you feel the need.
Sure, but how great may the lengths be you can go before it is not reasonably feasible to do what you´re doing?
Right, but what about keeping track of customers? Apparently RADIUS has some accounting features, and it might be an advantage to use those.
I really don't get why you want WPA2 Enterprise for this setup. There's a reason why almost everyone uses captive portals for providing access to lots of external users.
I didn´t say I want that, and I don´t know yet what I want. A captive portal may be nice, but I haven´t found a way to set one up yet, and I don´t have an access point controller which would provide one, so I can´t tell if that´s the right solution.
On 1 March 2018 at 08:42, hw hw@gc-24.de wrote:
I didn´t say I want that, and I don´t know yet what I want. A captive portal may be nice, but I haven´t found a way to set one up yet, and I don´t have an access point controller which would provide one, so I can´t tell if that´s the right solution.
This is the problem with this entire thread in a nutshell. You don't know what you want but what you have articulated at various points is that you do know what you want. You then state something that won't work because of some factor or another. People then correct you on that, and you then get hostile because you were just thinking out loud but no one knew that. Thinking out loud works ok in real life because we give special queues like looking abstractly or being able to say "Oh no I am just thinking out loud" right away. Instead in email none of that happens and people get more and more hostile and angry thinking the other side is trying to make them do completely opposite.
Let us try starting over. You may have answered these in other places, but people need to see them in one place at one time versus trying to look through cache of other emails.
What do you want? What are your constraints? [AKA what have you been told to do.] When do you need it? What is the environment that it is to run in? What research have you done (with references)?
Then people will have a better ability to answer: What have others done to meet those needs? How have they implemented it?
Then ask What other things do you need for me to help?
People can then ask questions about things you didn't fully explain. This is helpful because going from the previous emails your phrasing made it sound like you needed unknown people to not be able to get onto the network until they were authenticated, but authentication requires them to be on a network, but you can't allow them to be on any network until they are authenticated. That may not be what you mean (on the other hand, I have had that conundrum given to me at a job and we had to spend 3 months convincing the boss(es) that was impossible with the tools we had (and probably impossible without)).
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Stephen John Smoogen wrote:
On 1 March 2018 at 08:42, hw hw@gc-24.de wrote:
I didn´t say I want that, and I don´t know yet what I want. A captive portal may be nice, but I haven´t found a way to set one up yet, and I don´t have an access point controller which would provide one, so I can´t tell if that´s the right solution.
This is the problem with this entire thread in a nutshell. You don't know what you want but what you have articulated at various points is that you do know what you want. You then state something that won't work because of some factor or another. People then correct you on that, and you then get hostile because you were just thinking out loud but no one knew that. Thinking out loud works ok in real life because we give special queues like looking abstractly or being able to say "Oh no I am just thinking out loud" right away. Instead in email none of that happens and people get more and more hostile and angry thinking the other side is trying to make them do completely opposite.
Let us try starting over. You may have answered these in other places, but people need to see them in one place at one time versus trying to look through cache of other emails.
What do you want?
I was asking for documentation telling me how RADIUS can be used, not only that it can be used.
What are your constraints? [AKA what have you been told to do.]
The task is to provide wireless coverage for employees and customers on company premises. It is desirable to be able to keep track of customers, as in knowing where exactly on the premises they currently are (within like 3--5 feet, which is apparently tough), and simpler things like knowing how long they stay and if they have been on the premises before. To avoid legal issues, it is probably advisable that customers need to agree to some sort of terms of usage.
It is desirable to be able to know where employees currently are, though it doesn´t neeed to be as precise.
When do you need it?
There´s no given time frame; it´s as soon as possible and preferably this year.
It is necessary to (re-)do the entire network infrastructure before wireless coverage can be achieved, one of the reasons being that it is currently impossible to use VLANs all over the place.
What is the environment that it is to run in?
a shopping area
Some of the wireless access points may need to take part in what is apparently called a mesh to be able to supply remote parts of the premises.
What research have you done (with references)?
I searched for documenation about how to actually use RADIUS and didn´t find any. I´ve asked for pointers to such documentation here. I´ve read the RADUIS admin guide. I´ve done a test setup by installing RADIUS and configuring a switch to use it to authenticate users logging into the switch via ssh and found it works fine. I have set up a couple access points in a test setup which currently provide wireless access for employees and wireless internet access for customers around some points of the premises. I found out what a captive portal is.
Then people will have a better ability to answer: What have others done to meet those needs? How have they implemented it?
Then ask What other things do you need for me to help?
People can then ask questions about things you didn't fully explain. This is helpful because going from the previous emails your phrasing made it sound like you needed unknown people to not be able to get onto the network until they were authenticated, but authentication requires them to be on a network, but you can't allow them to be on any network until they are authenticated. That may not be what you mean (on the other hand, I have had that conundrum given to me at a job and we had to spend 3 months convincing the boss(es) that was impossible with the tools we had (and probably impossible without)).
That is what using RADIUS apparently leads to when you have devices using PXE boot. Maybe they need to be considered as a security risk and be replaced.
Unauthenticated people are easier to handle because people can provide credentials for authentication without PXE booting them first and do not access the network without a device (unless they mess with the very network hardware, using cables to create loops or accidentially cutting them or unplugging them or whatever --- people do all kinds of things, with authentication and without ...).
Devices with network access are much more dangerous than unauthenticated people because such devices could be used by such people to also gain network access, or they could try to have bad effects on the network.
So everthing is dangerous, authenticated or not.
On 1 March 2018 at 12:26, hw hw@gc-24.de wrote:
Stephen John Smoogen wrote:
On 1 March 2018 at 08:42, hw hw@gc-24.de wrote:
I didn´t say I want that, and I don´t know yet what I want. A captive portal may be nice, but I haven´t found a way to set one up yet, and I don´t have an access point controller which would provide one, so I can´t tell if that´s the right solution.
This is the problem with this entire thread in a nutshell. You don't know what you want but what you have articulated at various points is that you do know what you want. You then state something that won't work because of some factor or another. People then correct you on that, and you then get hostile because you were just thinking out loud but no one knew that. Thinking out loud works ok in real life because we give special queues like looking abstractly or being able to say "Oh no I am just thinking out loud" right away. Instead in email none of that happens and people get more and more hostile and angry thinking the other side is trying to make them do completely opposite.
Let us try starting over. You may have answered these in other places, but people need to see them in one place at one time versus trying to look through cache of other emails.
What do you want?
I was asking for documentation telling me how RADIUS can be used, not only that it can be used.
What are your constraints? [AKA what have you been told to do.]
The task is to provide wireless coverage for employees and customers on company premises. It is desirable to be able to keep track of customers, as in knowing where exactly on the premises they currently are (within like 3--5 feet, which is apparently tough), and simpler things like knowing how long they stay and if they have been on the premises before. To avoid legal issues, it is probably advisable that customers need to agree to some sort of terms of usage.
Oh yeah. Who ever gave you those marching orders needs to talk with all kinds of lawyers... even researching for it might be problematic in some countries due to a multitude of laws. You are walking out of setting up a wireless environment into full-scale surveillance.
That said, what you are looking for is not going to be accomplished with simple radius without a large amount of development. It is also going to need a lot of wireless sensors running at different frequencies through out the building. Most of that is done usually with special commercial hardware/software and falls outside of scope of this list by a mile.
RADIUS may be something that is done with all of this but only far way back in the chain of tools needed. It might be something that the specialized hardware, scanners, sensors, etc might tie into if they don't have their own specialized tool. Worrying about it before those are researched, etc is to use an English idiom: putting the cart before the horse.
It is desirable to be able to know where employees currently are, though it doesn´t neeed to be as precise.
When do you need it?
There´s no given time frame; it´s as soon as possible and preferably this year.
It is necessary to (re-)do the entire network infrastructure before wireless coverage can be achieved, one of the reasons being that it is currently impossible to use VLANs all over the place.
What is the environment that it is to run in?
a shopping area
Some of the wireless access points may need to take part in what is apparently called a mesh to be able to supply remote parts of the premises.
What research have you done (with references)?
I searched for documenation about how to actually use RADIUS and didn´t find any. I´ve asked for pointers to such documentation here. I´ve read the RADUIS admin guide. I´ve done a test setup by installing RADIUS and configuring a switch to use it to authenticate users logging into the switch via ssh and found it works fine. I have set up a couple access points in a test setup which currently provide wireless access for employees and wireless internet access for customers around some points of the premises. I found out what a captive portal is.
Then people will have a better ability to answer: What have others done to meet those needs? How have they implemented it?
Then ask What other things do you need for me to help?
People can then ask questions about things you didn't fully explain. This is helpful because going from the previous emails your phrasing made it sound like you needed unknown people to not be able to get onto the network until they were authenticated, but authentication requires them to be on a network, but you can't allow them to be on any network until they are authenticated. That may not be what you mean (on the other hand, I have had that conundrum given to me at a job and we had to spend 3 months convincing the boss(es) that was impossible with the tools we had (and probably impossible without)).
That is what using RADIUS apparently leads to when you have devices using PXE boot. Maybe they need to be considered as a security risk and be replaced.
OK I think this is where we are also getting confusion. PXE booting is a multistep process to get a hardware device onto the network and running a provided kernel. It is also something which usually only works on wireless in controlled situations (aka magic).
So people aren't sure why you are wanting to PXE boot something a customer would carry (aka a cell phone/tablet) since that does not PXE boot at all. You might be meaning DHCP instead but maybe you are meaning something else.
So the normal tools are to set up different LANs for different access. On wired or wireless this is usually done with a dedicated network which only devices which a) have a proven mac, b) use WPA-Enterprise with radius to log in. For untrusted devices that might be looking for any open lan, you have an open net which has a captive portal which can 'kick' certain devices to a semi-trusted lan. [This is device dependent so don't expect it to work for everyone.] Then you have a semi-trusted lan which may have a guest password. It is still a captive portal so that people on it are only able to get out after they provided a second allowed password. The captive portals may be backed by Radius, but it will depend on what software they are using.
[The above comes from doing this a decade ago.. things have changed so please follow any new guidance/books on commercial wireless design.]
Unauthenticated people are easier to handle because people can provide credentials for authentication without PXE booting them first and do not access the network without a device (unless they mess with the very network hardware, using cables to create loops or accidentially cutting them or unplugging them or whatever --- people do all kinds of things, with authentication and without ...).
Devices with network access are much more dangerous than unauthenticated people because such devices could be used by such people to also gain network access, or they could try to have bad effects on the network.
So everthing is dangerous, authenticated or not.
Everything is always dangerous :). It is good to recognize that because a lot of times people just assume there is a magical non-dangerous way and then spend all their time trying to find it. The best we can do is find how to respond to the danger.
Stephen John Smoogen wrote:
On 1 March 2018 at 12:26, hw hw@gc-24.de wrote:
Stephen John Smoogen wrote:
On 1 March 2018 at 08:42, hw hw@gc-24.de wrote:
I didn´t say I want that, and I don´t know yet what I want. A captive portal may be nice, but I haven´t found a way to set one up yet, and I don´t have an access point controller which would provide one, so I can´t tell if that´s the right solution.
This is the problem with this entire thread in a nutshell. You don't know what you want but what you have articulated at various points is that you do know what you want. You then state something that won't work because of some factor or another. People then correct you on that, and you then get hostile because you were just thinking out loud but no one knew that. Thinking out loud works ok in real life because we give special queues like looking abstractly or being able to say "Oh no I am just thinking out loud" right away. Instead in email none of that happens and people get more and more hostile and angry thinking the other side is trying to make them do completely opposite.
Let us try starting over. You may have answered these in other places, but people need to see them in one place at one time versus trying to look through cache of other emails.
What do you want?
I was asking for documentation telling me how RADIUS can be used, not only that it can be used.
What are your constraints? [AKA what have you been told to do.]
The task is to provide wireless coverage for employees and customers on company premises. It is desirable to be able to keep track of customers, as in knowing where exactly on the premises they currently are (within like 3--5 feet, which is apparently tough), and simpler things like knowing how long they stay and if they have been on the premises before. To avoid legal issues, it is probably advisable that customers need to agree to some sort of terms of usage.
Oh yeah. Who ever gave you those marching orders needs to talk with all kinds of lawyers... even researching for it might be problematic in some countries due to a multitude of laws. You are walking out of setting up a wireless environment into full-scale surveillance.
That´s not my problem to solve, but think about it: You can get a lot more information using CCTV cameras, and those are everywhere. Unfortunately, nobody cares, and it´s not like you have a choice. So why would there be any legal issues?
That said, what you are looking for is not going to be accomplished with simple radius without a large amount of development. It is also going to need a lot of wireless sensors running at different frequencies through out the building. Most of that is done usually with special commercial hardware/software and falls outside of scope of this list by a mile.
RADIUS would only be a tool to use for authentication and perhaps accounting. Figuring out where users are is an entirely different problem.
RADIUS may be something that is done with all of this but only far way back in the chain of tools needed. It might be something that the specialized hardware, scanners, sensors, etc might tie into if they don't have their own specialized tool. Worrying about it before those are researched, etc is to use an English idiom: putting the cart before the horse.
I´m surprised that wireless access point controllers, by default, do not use the strength of the signal received from a device by three or more access points to simply triangulate the position of the device. Of course, you only get the positions of devices relative to access points, but once you have that, you only need to use a map of the place that shows all the access points and the positions of devices relative to them to figure out where everyone is.
That´s a rather simple thing to do, isn´t it? Some documentation of HPs MSRs stated that the controller can distribute the wireless devices between access points to even out the bandwidth, and if it can do that, it could as well distribute them for triangulation.
It is desirable to be able to know where employees currently are, though it doesn´t neeed to be as precise.
When do you need it?
There´s no given time frame; it´s as soon as possible and preferably this year.
It is necessary to (re-)do the entire network infrastructure before wireless coverage can be achieved, one of the reasons being that it is currently impossible to use VLANs all over the place.
What is the environment that it is to run in?
a shopping area
Some of the wireless access points may need to take part in what is apparently called a mesh to be able to supply remote parts of the premises.
What research have you done (with references)?
I searched for documenation about how to actually use RADIUS and didn´t find any. I´ve asked for pointers to such documentation here. I´ve read the RADUIS admin guide. I´ve done a test setup by installing RADIUS and configuring a switch to use it to authenticate users logging into the switch via ssh and found it works fine. I have set up a couple access points in a test setup which currently provide wireless access for employees and wireless internet access for customers around some points of the premises. I found out what a captive portal is.
Then people will have a better ability to answer: What have others done to meet those needs? How have they implemented it?
Then ask What other things do you need for me to help?
People can then ask questions about things you didn't fully explain. This is helpful because going from the previous emails your phrasing made it sound like you needed unknown people to not be able to get onto the network until they were authenticated, but authentication requires them to be on a network, but you can't allow them to be on any network until they are authenticated. That may not be what you mean (on the other hand, I have had that conundrum given to me at a job and we had to spend 3 months convincing the boss(es) that was impossible with the tools we had (and probably impossible without)).
That is what using RADIUS apparently leads to when you have devices using PXE boot. Maybe they need to be considered as a security risk and be replaced.
OK I think this is where we are also getting confusion. PXE booting is a multistep process to get a hardware device onto the network and running a provided kernel. It is also something which usually only works on wireless in controlled situations (aka magic).
Oh I never thought of using it for wireless devices.
So people aren't sure why you are wanting to PXE boot something a customer would carry (aka a cell phone/tablet) since that does not PXE boot at all. You might be meaning DHCP instead but maybe you are meaning something else.
When there´s a RADIUS server on the network, not only wireless devices could/should use it.
So the normal tools are to set up different LANs for different access. On wired or wireless this is usually done with a dedicated network which only devices which a) have a proven mac, b) use WPA-Enterprise with radius to log in. For untrusted devices that might be looking for any open lan, you have an open net which has a captive portal which can 'kick' certain devices to a semi-trusted lan. [This is device dependent so don't expect it to work for everyone.] Then you have a semi-trusted lan which may have a guest password. It is still a captive portal so that people on it are only able to get out after they provided a second allowed password. The captive portals may be backed by Radius, but it will depend on what software they are using.
[The above comes from doing this a decade ago.. things have changed so please follow any new guidance/books on commercial wireless design.]
Well, I don´t want to trust MAC addresses because they can be faked.
Unauthenticated people are easier to handle because people can provide credentials for authentication without PXE booting them first and do not access the network without a device (unless they mess with the very network hardware, using cables to create loops or accidentially cutting them or unplugging them or whatever --- people do all kinds of things, with authentication and without ...).
Devices with network access are much more dangerous than unauthenticated people because such devices could be used by such people to also gain network access, or they could try to have bad effects on the network.
So everthing is dangerous, authenticated or not.
Everything is always dangerous :). It is good to recognize that because a lot of times people just assume there is a magical non-dangerous way and then spend all their time trying to find it. The best we can do is find how to respond to the danger.
hm
Is sleeping dangerous?
On 2 March 2018 at 12:07, hw hw@gc-24.de wrote:
Oh yeah. Who ever gave you those marching orders needs to talk with all kinds of lawyers... even researching for it might be problematic in some countries due to a multitude of laws. You are walking out of setting up a wireless environment into full-scale surveillance.
That´s not my problem to solve, but think about it: You can get a lot more information using CCTV cameras, and those are everywhere. Unfortunately, nobody cares, and it´s not like you have a choice. So why would there be any legal issues?
1) Devices which omit radio frequency wavelength radiation are covered by different laws and agencies than those which emit light based radiation. This means that the agency that says you can put in a cctv may not be the same as the one that allows you to put in a RF sensor. 2) There are laws using where monitoring of the public can happen and where the monitoring devices can be placed and what information can be kept on them. These are covered from everything from local to EU laws. The laws can also be conflicting and need careful consideration. 3) Depending on the location this occurs, it is your problem to bring up if you are aware that it could be a problem. The "I was only following orders" defense has been thrown out for people and the engineers/custodians who put the stuff in were found liable for damages as much as the boss who said to do it.
That is all I am going to say on this as it is up to your location and situation. Other people coming into this conversation years later will be on different laws and rules.
That said, what you are looking for is not going to be accomplished with simple radius without a large amount of development. It is also going to need a lot of wireless sensors running at different frequencies through out the building. Most of that is done usually with special commercial hardware/software and falls outside of scope of this list by a mile.
RADIUS would only be a tool to use for authentication and perhaps accounting.
Depending on the hardware used. If the hardware bought only works with AD, RADIUS isn't going to help at all.
Figuring out where users are is an entirely different problem.
RADIUS may be something that is done with all of this but only far way back in the chain of tools needed. It might be something that the specialized hardware, scanners, sensors, etc might tie into if they don't have their own specialized tool. Worrying about it before those are researched, etc is to use an English idiom: putting the cart before the horse.
I´m surprised that wireless access point controllers, by default, do not use the strength of the signal received from a device by three or more access points to simply triangulate the position of the device. Of course, you only get the positions of devices relative to access points, but once you have that, you only need to use a map of the place that shows all the access points and the positions of devices relative to them to figure out where everyone is.
That´s a rather simple thing to do, isn´t it? Some documentation of HPs MSRs stated that the controller can distribute the wireless devices between access points to even out the bandwidth, and if it can do that, it could as well distribute them for triangulation.
It isn't. Wireless is much noisier and uses longer wavelengths than light. It is like walking through a hall of mirrors with sunglasses on. You are only able to see certain things, lots of things reflect, everything within sensor range which is broadcasting is showing up even if it is a different SSID, and a ton of other items. This means that where you might only need 2 sensors for light, you need dozens to hundreds for radio waves. However the more sensors you have, they also may reflect, rebroadcast, dampen, ghost echo signals. Then you have the fact that RF is absorbed by water and people are giant bags of water. You need to put sensors at different heights, etc etc.
This is where the 3rd parts hardware and software comes in. You need to map the empty room, map the room with noise, map the room with people in it without sensors and then map the room with how you want it to work. The software then does a huge data dump and lots of Fourier transforms and trig to figure out where a 'live' feed may look like. You still have to go in and massage it at times because all it takes is some metal object being walked through the room and it is all off for N minutes.
In any case, this is a different problem and completely tangential to either CentOS or RADIUS.
Stephen John Smoogen wrote:
On 2 March 2018 at 12:07, hw hw@gc-24.de wrote:
Oh yeah. Who ever gave you those marching orders needs to talk with all kinds of lawyers... even researching for it might be problematic in some countries due to a multitude of laws. You are walking out of setting up a wireless environment into full-scale surveillance.
That´s not my problem to solve, but think about it: You can get a lot more information using CCTV cameras, and those are everywhere. Unfortunately, nobody cares, and it´s not like you have a choice. So why would there be any legal issues?
- Devices which omit radio frequency wavelength radiation are covered
by different laws and agencies than those which emit light based radiation. This means that the agency that says you can put in a cctv may not be the same as the one that allows you to put in a RF sensor. 2) There are laws using where monitoring of the public can happen and where the monitoring devices can be placed and what information can be kept on them. These are covered from everything from local to EU laws. The laws can also be conflicting and need careful consideration.
Ok, those are considerations for the lawyers. If they can´t figure out that it can be much worse filming someone who doesn´t even have a choice about being filmed than it can be to use wireless access points to determine the whereabouts of someone who has a choice to either use the access points or not, someone needs to do something about those lawyers.
- Depending on the location this occurs, it is your problem to bring
up if you are aware that it could be a problem. The "I was only following orders" defense has been thrown out for people and the engineers/custodians who put the stuff in were found liable for damages as much as the boss who said to do it.
Prove that I was aware of something and aware that I should bring it up and that I then didn´t bring it up.
If someone made a law saying that nobody can say anymore that they were only doing what they were supposed to do, I´d like to know where to find this law. I would also like to know how that law is enforced.
"Following orders" has apparently been a problem with the Nazis a long time ago, and when the law suits after WW2 were performed, claiming that one of the intentions was to show how following orders may not always be the right thing to do and that people might be punished for doing so, the outcome was a total failure because nothing has changed. There are still people making decisions without being held responsible for what they are doing, and other people who carry them out, also without being held responsible for what they are doing, and since they control all the powers that are, what they are doing crushes anything and anyone that or who might get into their way, and these people don´t care and don´t even blink when they harm millions. This is called democracy, and noone is responsible because it isn´t called "following orders" anymore. The same principles that did a great deal to make it possible to murder so many people a long time ago are entirely unbroken and still in effect, and thanks to advances in technology, nowadays the means at their disposal are ridiculously more powerful than they were.
Unfortunately, we aren´t told this, and I´m afraid almost noone understands this. You can imagine why we aren´t told. What I don´t understand is why they didn´t change anything back then. Perhaps they didn´t understand what the real danger is and where it comes from.
Now tell me: Who am I to question the orders and what power could I possibly have to refuse them without it being to my disadvantage?
[...]
I´m surprised that wireless access point controllers, by default, do not use the strength of the signal received from a device by three or more access points to simply triangulate the position of the device. Of course, you only get the positions of devices relative to access points, but once you have that, you only need to use a map of the place that shows all the access points and the positions of devices relative to them to figure out where everyone is.
That´s a rather simple thing to do, isn´t it? Some documentation of HPs MSRs stated that the controller can distribute the wireless devices between access points to even out the bandwidth, and if it can do that, it could as well distribute them for triangulation.
It isn't. Wireless is much noisier and uses longer wavelengths than light. It is like walking through a hall of mirrors with sunglasses on. You are only able to see certain things, lots of things reflect, everything within sensor range which is broadcasting is showing up even if it is a different SSID, and a ton of other items. This means that where you might only need 2 sensors for light, you need dozens to hundreds for radio waves. However the more sensors you have, they also may reflect, rebroadcast, dampen, ghost echo signals. Then you have the fact that RF is absorbed by water and people are giant bags of water. You need to put sensors at different heights, etc etc.
This is where the 3rd parts hardware and software comes in. You need to map the empty room, map the room with noise, map the room with people in it without sensors and then map the room with how you want it to work. The software then does a huge data dump and lots of Fourier transforms and trig to figure out where a 'live' feed may look like. You still have to go in and massage it at times because all it takes is some metal object being walked through the room and it is all off for N minutes.
You mean the signal strength is way too unrelated to the distance between an access point and a device to give meaningful results when used for triangulations?
That makes perfect sense to me.
In any case, this is a different problem and completely tangential to either CentOS or RADIUS.
That´s not my problem to solve, but think about it: You can get a lot more information using CCTV cameras, and those are everywhere. Unfortunately, nobody cares, and it´s not like you have a choice. So why would there be any legal issues?
It's called "A Law". Different places have different laws. Different places have different attitudes towards being lawful.
I´m surprised that wireless access point controllers, by default, do not use the strength of the signal received from a device by three or more access points to simply triangulate the position of the device. Of course, you only get the positions of devices relative to access points, but once you have that, you only need to use a map of the place that shows all the access points and the positions of devices relative to them to figure out where everyone is.
I'm surprised you didn't find anything about this on Google - you did try Google didn't you?
top hit
or this paper
https://www.technologyreview.com/s/542561/wi-fi-trick-gives-devices-super-ac...
OK. I know I said before it was basically impossible - but I hadn't googled for it then. It just goes to show that asking CentOS admins about cutting edge WiFi issues is not going to get you very far.
P.
Pete Biggs wrote:
That´s not my problem to solve, but think about it: You can get a lot more information using CCTV cameras, and those are everywhere. Unfortunately, nobody cares, and it´s not like you have a choice. So why would there be any legal issues?
It's called "A Law". Different places have different laws. Different places have different attitudes towards being lawful.
I´m surprised that wireless access point controllers, by default, do not use the strength of the signal received from a device by three or more access points to simply triangulate the position of the device. Of course, you only get the positions of devices relative to access points, but once you have that, you only need to use a map of the place that shows all the access points and the positions of devices relative to them to figure out where everyone is.
I'm surprised you didn't find anything about this on Google - you did try Google didn't you?
http://bfy.tw/GtiP
You´ve cheated by using different search terms than I did ...
top hit
They use video or bluetooth, not wireless.
or this paper
https://www.technologyreview.com/s/542561/wi-fi-trick-gives-devices-super-ac...
They are doing it the other way round by having the device use the signal strengths of access points to triangulate its own position by using specialized hard- and software to solve accuracy problems.
Anyway, these are both interesting references.
OK. I know I said before it was basically impossible - but I hadn't googled for it then. It just goes to show that asking CentOS admins about cutting edge WiFi issues is not going to get you very far.
Well, we asked someone who might know how to do it and they never responded, so asking people who don´t know gets you even farther than asking people who do.
What do you want?
I was asking for documentation telling me how RADIUS can be used, not only that it can be used.
RADIUS is just an authentication (plus a bit more) protocol - what you are asking is like asking how LDAP can be used. Usually it's treated like a magic black box by applications in that one of the configuration options is to "use a RADIUS server" and then you just configure the necessary information in the client so it talks to the correct box. The reason RADIUS is used rather than some other authentication protocol is that it is designed to be used in a network authentication role.
Rather than focussing on the RADIUS aspect, you would probably be better looking at the configuration and technology around how you want the network to operate. The way the RADIUS server is used will be obvious once you've sorted that out.
What are your constraints? [AKA what have you been told to do.]
The task is to provide wireless coverage for employees and customers on company premises. It is desirable to be able to keep track of customers, as in knowing where exactly on the premises they currently are (within like 3--5 feet, which is apparently tough),
Tough? I would say basically impossible. The only way of getting that sort of accuracy is to either have lots of pico cells so you know which AP a device is connected to, or be able to triangulate. WiFi has a reasonable range and devices like to hang on to an AP for as long as possible, even if they can pass off on to a closer more powerful one.
I know retailers are looking at targeting customers via their location, but I think that currently needs the co-operation of the customer's device via a downloaded app.
and simpler things like knowing how long they stay and if they have been on the premises before.
I can see now why you wanted to stop customers/employees from using their 4G connection.
That is what using RADIUS apparently leads to when you have devices using PXE boot. Maybe they need to be considered as a security risk and be replaced.
You mentioned X2Go and that your PXE booting clients used it. I know X2Go and the client is a standalone app that uses ssh to login to the server to initiate a remote desktop type environment. There's nothing in X2Go per se that requires a persistent network connection before they connect. So, am I right in assuming that your PXE clients are actually diskless machines that get all of their environment from the network?
P.
On 3/1/18 10:02 AM, Pete Biggs wrote:
What are your constraints? [AKA what have you been told to do.]
The task is to provide wireless coverage for employees and customers on company premises. It is desirable to be able to keep track of customers, as in knowing where exactly on the premises they currently are (within like 3--5 feet, which is apparently tough),
Tough? I would say basically impossible. The only way of getting that sort of accuracy is to either have lots of pico cells so you know which AP a device is connected to, or be able to triangulate. WiFi has a reasonable range and devices like to hang on to an AP for as long as possible, even if they can pass off on to a closer more powerful one.
I know retailers are looking at targeting customers via their location, but I think that currently needs the co-operation of the customer's device via a downloaded app.
There ARE companies that specialize in this type of thing. It's really NOT a quicky-homebrew thing... Especially if one is staring with "tell me how to use <blank> AAA protocol".
and simpler things like knowing how long they stay and if they have been on the premises before.
I can see now why you wanted to stop customers/employees from using their 4G connection.
One thing to keep in mind if this is in the US... Blocking cellular bands (and publicly accessible radio in general) is grossly illegal and a serious felony. Marriott corporation tried it with WiFi and got smacked with a VERY large fine and I heard that some of the licensed radio engineers involved were also personally fined... They should have known better.
The commonly used technique is Bluetooth beacons... But the victims (er customers) HAVE to co operate.
That is what using RADIUS apparently leads to when you have devices using PXE boot. Maybe they need to be considered as a security risk and be replaced.
You mentioned X2Go and that your PXE booting clients used it. I know X2Go and the client is a standalone app that uses ssh to login to the server to initiate a remote desktop type environment. There's nothing in X2Go per se that requires a persistent network connection before they connect. So, am I right in assuming that your PXE clients are actually diskless machines that get all of their environment from the network?
P.
Pete Biggs wrote:
What do you want?
I was asking for documentation telling me how RADIUS can be used, not only that it can be used.
RADIUS is just an authentication (plus a bit more) protocol - what you are asking is like asking how LDAP can be used. Usually it's treated like a magic black box by applications in that one of the configuration options is to "use a RADIUS server" and then you just configure the necessary information in the client so it talks to the correct box. The reason RADIUS is used rather than some other authentication protocol is that it is designed to be used in a network authentication role.
Rather than focussing on the RADIUS aspect, you would probably be better looking at the configuration and technology around how you want the network to operate. The way the RADIUS server is used will be obvious once you've sorted that out.
When I figure out how the network is supposed to operate, RADIUS might not be needed, and useful functionality it could provide would not exist because I couldn´t figure it in for I didn´t know any better. I´d be doing a bad job.
What are your constraints? [AKA what have you been told to do.]
The task is to provide wireless coverage for employees and customers on company premises. It is desirable to be able to keep track of customers, as in knowing where exactly on the premises they currently are (within like 3--5 feet, which is apparently tough),
Tough? I would say basically impossible. The only way of getting that
Apparently Cisco can do it:
https://www.cisco.com/c/en/us/products/collateral/wireless/wireless-location...
sort of accuracy is to either have lots of pico cells so you know which AP a device is connected to, or be able to triangulate. WiFi has a reasonable range and devices like to hang on to an AP for as long as possible, even if they can pass off on to a closer more powerful one.
I know retailers are looking at targeting customers via their location, but I think that currently needs the co-operation of the customer's device via a downloaded app.
and simpler things like knowing how long they stay and if they have been on the premises before.
I can see now why you wanted to stop customers/employees from using their 4G connection.
There is no point in offering wireless to customers when they aren´t going to use it.
That is what using RADIUS apparently leads to when you have devices using PXE boot. Maybe they need to be considered as a security risk and be replaced.
You mentioned X2Go and that your PXE booting clients used it. I know X2Go and the client is a standalone app that uses ssh to login to the server to initiate a remote desktop type environment. There's nothing in X2Go per se that requires a persistent network connection before they connect. So, am I right in assuming that your PXE clients are actually diskless machines that get all of their environment from the network?
They are, and they boot to where a user needs to enter a username and a password to log in. Perhaps that can be changed, but I´m glad that it works as well as it does and am not inclined to touch it. It seems rather fragile, the documentation isn´t too great and you are left to your magic guesswork about how it might work.
There are things that bother me like that you can not set a screen resolution based on the user that logs in, and I had to set it to a fixed resolution for all clients. Replacing these devices rather than messing with them would have some advantages --- and disadvantages.
On Wed, Mar 7, 2018 at 11:57 AM hw hw@gc-24.de wrote:
Apparently Cisco can do it:
https://www.cisco.com/c/en/us/products/collateral/wireless/wireless-location...
I was going to mention Cisco WCS which uses wireless “controllers” and “lightweight” access points, but seems you’ve found it. Personally used Cisco WCS a decade ago . . . being able to give law enforcement a detailed map of a building (from autocad file) with a potential stolen wireless device triangulated within 5 feet is pretty impressive.
Don’t know if this can handle all of your other/security/guest requirements but can 100% handle physical location.
Steven Tardy wrote:
On Wed, Mar 7, 2018 at 11:57 AM hw hw@gc-24.de wrote:
Apparently Cisco can do it:
https://www.cisco.com/c/en/us/products/collateral/wireless/wireless-location...
I was going to mention Cisco WCS which uses wireless “controllers” and “lightweight” access points, but seems you’ve found it. Personally used Cisco WCS a decade ago . . . being able to give law enforcement a detailed map of a building (from autocad file) with a potential stolen wireless device triangulated within 5 feet is pretty impressive.
Don’t know if this can handle all of your other/security/guest requirements but can 100% handle physical location.
So it would actually work, that´s good to know, thanks :)
Beyond their access points and the controller and a support contract, is there anything else we would have to get from Cisco to get this to work?
To me, Cisco is basically out of the question because you can´t even get a firmware image for a new device that arrives DOA because the firmware image is damaged without having a support contract with them. That shows they do not stand behind their products, and they are on the no-buy list. That doesn´t even consider the question of how to get a contract and how much it would cost. They didn´t even tell me that much.
However, it might be a solution, so I have to bring it to consideration.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Once upon a time, hw hw@gc-24.de said:
The task is to provide wireless coverage for employees and customers on company premises. It is desirable to be able to keep track of customers, as in knowing where exactly on the premises they currently are (within like 3--5 feet, which is apparently tough), and simpler things like knowing how long they stay and if they have been on the premises before. To avoid legal issues, it is probably advisable that customers need to agree to some sort of terms of usage.
What you are talking about requires very specialized wifi setups, which AFAIK no freely-available tools implement. You need to be talking to enterprise wifi hardware vendors to get that kind of thing.
RADIUS is an AAA (Authentication, Authorization, and Accounting) protocol. It might be one small tool used in authorization, like letting employees on the network, but that would be up to the wifi vendor's controller system (some can use RADIUS, some can use AD, some use their own systems, etc.).
On 03/01/2018 09:26 AM, hw wrote:
I was asking for documentation telling me how RADIUS can be used, not only that it can be used.
RADIUS is a backend component of 802.1x and WPA2 Enterprise. You appear to be looking for information on how to use those two. If you look for documentation on those, you should be able to find what you're looking for.
The task is to provide wireless coverage for employees and customers on company premises. It is desirable to be able to keep track of customers, as in knowing where exactly on the premises they currently are (within like 3--5 feet, which is apparently tough), and simpler things like knowing how long they stay and if they have been on the premises before.
You probably want to capture the WAP logs. Their location will be best correlated with the specific WAP they connect to, assuming you have multiple. The client MAC address will be your best indication of whether or not they've been there before.
Gordon Messmer wrote:
On 03/01/2018 09:26 AM, hw wrote:
I was asking for documentation telling me how RADIUS can be used, not only that it can be used.
RADIUS is a backend component of 802.1x and WPA2 Enterprise. You appear to be looking for information on how to use those two. If you look for documentation on those, you should be able to find what you're looking for.
ok
The task is to provide wireless coverage for employees and customers on company premises. It is desirable to be able to keep track of customers, as in knowing where exactly on the premises they currently are (within like 3--5 feet, which is apparently tough), and simpler things like knowing how long they stay and if they have been on the premises before.
You probably want to capture the WAP logs. Their location will be best correlated with the specific WAP they connect to, assuming you have multiple. The client MAC address will be your best indication of whether or not they've been there before.
The location of customers would remain a problem because they could be anywhere within a radius of about 100m around an access point they are connected to.
Employees could use a program on their phones to help locating them, but I have no idea how to program a phone. It´s not like you could find good documentation about that ...
On 03/01/2018 03:06 AM, hw wrote:
It is illogical to lump all network access together into a single category.
...
If your device can communicate with a switch, even for the purpose of authenticating, then it has network access.
The device has access to the switch which, depending on what answer to an authentication request it gets from a RADIUS server, decides if and how it lets the device access the network.
You're still lumping networks into a single category.
Not "the" network, but "a" network.
Unauthenticated clients are, by definition connected to A network consisting of the device and the switch. They might also be connected to a network consisting of the device, a switch, and a TFTP server that provides the boot image to the client. And since there is nothing else on that network, other than a read-only TFTP server that your devices require in order to boot, it's difficult to understand why you think there is a security risk here.
Security is the process of restricting access to a resource to only the devices and persons that require it. If your devices require a boot image before they can authenticate, then restricting their access to that resource can no longer be described as "security."
Where do your hypothetical customers in a store get the user credentials that you want to authenticate via RADIUS?
They might get it from employees of the store or read it from signs inside the store, perhaps depending on what kind of access rights they are supposed to have.
If you're sharing passwords, then you don't need RADIUS. Set up separate SSIDs that are attached to VLANs with appropriate access levels, and continue using WPA2 Personal. Using RADIUS will be no more secure than that. It's not magic.
Right, but what about keeping track of customers? Apparently RADIUS has some accounting features, and it might be an advantage to use those.
It does, but you will get exactly the same information using WPA2 Personal that you will from WPA2 Enterprise and RADIUS. "A client connected to the WAP at such and such time. It disconnected at such and such time."
If you're sharing passwords, RADIUS is the most complex way to get the information. You can get the same info by simply logging WAP events to a log server.
Gordon Messmer wrote:
On 03/01/2018 03:06 AM, hw wrote:
It is illogical to lump all network access together into a single category.
...
If your device can communicate with a switch, even for the purpose of authenticating, then it has network access.
The device has access to the switch which, depending on what answer to an authentication request it gets from a RADIUS server, decides if and how it lets the device access the network.
You're still lumping networks into a single category.
Not "the" network, but "a" network.
There is only one network here.
Unauthenticated clients are, by definition connected to A network consisting of the device and the switch. They might also be connected to a network consisting of the device, a switch, and a TFTP server that provides the boot image to the client. And since there is nothing else on that network, other than a read-only TFTP server that your devices require in order to boot, it's difficult to understand why you think there is a security risk here.
Let me quote:
"the RADIUS protocol serves three primary functions:
• Authenticates users or devices before allowing them access to a network"[1]
Why would I give access to a network consisting of an unauthorized device, a switch and a TFTP server to such device and thereby possibly to an attacker? Can you guarantee that there is no way for an attacker who can have such a network connection will not find a way to proceed with an attack? They can bring a device that does not PXE boot and is equipped with everything they might need to perform their attack.
When the only things the devices of attackers can communicate with are switches or wireless access points which do not give them access to a network (other than the devices and the switches or access points themselves), it is likely to be more difficult to perform a sucessful attack than it is when they get access to a wider network, like one that involves a server.
[1]: http://networkradius.com/doc/FreeRADIUS%20Technical%20Guide.pdf
Security is the process of restricting access to a resource to only the devices and persons that require it. If your devices require a boot image before they can authenticate, then restricting their access to that resource can no longer be described as "security."
That´s kinda what I said.
Where do your hypothetical customers in a store get the user credentials that you want to authenticate via RADIUS?
They might get it from employees of the store or read it from signs inside the store, perhaps depending on what kind of access rights they are supposed to have.
If you're sharing passwords, then you don't need RADIUS. Set up separate SSIDs that are attached to VLANs with appropriate access levels, and continue using WPA2 Personal. Using RADIUS will be no more secure than that. It's not magic.
Right, but what about keeping track of customers? Apparently RADIUS has some accounting features, and it might be an advantage to use those.
It does, but you will get exactly the same information using WPA2 Personal that you will from WPA2 Enterprise and RADIUS. "A client connected to the WAP at such and such time. It disconnected at such and such time."
It might be possible to find out how much data was transferred with accounting.
If you're sharing passwords, RADIUS is the most complex way to get the information. You can get the same info by simply logging WAP events to a log server.
Yes, it´s very simple to use the same password on all phones of employees and no password on the wireless for customers. Logging the events might be enough then.
Somehow that doesn´t feel like it is a good solution, but I don´t know.
-
Bruce Ferrell -
Chris Adams -
Gordon Messmer -
hw -
Javier Romero -
John Hodrien -
Pete Biggs -
Richard Grainger -
Stephen John Smoogen -
Steven Tardy