CentOS - Mar 2018 - RADIUS

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 at 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 at centos.org
> https://lists.centos.org/mailman/listinfo/centos


-- 
Stephen J Smoogen.

Stephen John Smoogen wrote:
> On 1 March 2018 at 08:42, hw <hw at 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.