Hi Fabrice,
I’ll definitely try this method. For now I want to understand the logic of an
endpoint authentication and authorization via RADIUS/801.x as there’s something
that works different from how I expected (or rather doesn’t work)
Here’s a story. A user successfully authenticates against AD and I see this
event in radius.log
Jul 4 06:34:25 PacketFence-ZEN auth[11338]: [mac:c4:9d:ed:8c:11:03] Accepted
user: OPTIONS\it.tech and returned VLAN 2
Jul 4 06:34:25 PacketFence-ZEN auth[11338]: (177) Login OK: [OPTIONS\it.tech]
(from client 172.19.254.2 port 0 cli c4:9d:ed:8
c:11:03)
This VLAN 2 is set in registration under Roles in the switch. Ok, may be this
is how it supposed to work before the endpoint is registered as opposed to the
VLAN 10 which should be assigned upon device registration.
But can anyone explain me why the endpoint receives an IP address from the
local DHCP server. This DHCP server listens on the sub-interface for this VLAN
10.
So what I see is that an endpoint receives an IP address but it can’t reach an
IP address of its default gateway.
Ok once again, I don’t have any problem to manually register this endpoint and
assign a specific role.
Having it done the endpoint gets online only after I reconnect it on the
endpoint itself or via the wireless controller.
This behavior is observed on Windows 10 and it took quite a long time (about a
minute) to authenticate and get an IP address without getting online.
But it doesn’t work at all for Mac OS and mobile devices (Apple iPads and
Android tabs), namely, same registration VLAN 2 is assigned as per radius.log
but an endpoint can’t receive an IP address via DHCP.
If it is OS specific behavior and I can’t do anything about it then it’s OK
again but I want to make it work smooth and fast.
The target role for all endpoints that should be allowed to connect via this
specific SSID is Staff and I’m assigning this role in the authentication rule
for a specific authentication source.
The result of the test authentication for a user confirm it:
./pftest authentication it.tech XXXXXXXX
Authenticating against 'OPTIONS-AD-SOURCE' in context 'admin'
Authentication SUCCEEDED against OPTIONS-AD-SOURCE (Authentication
successful.)
Matched against OPTIONS-AD-SOURCE for 'authentication' rules
set_unreg_date : 2019-12-31 11:53:24
set_role : Staff
What’s the point of assigning this role by a rule if in reality an endpoint
doesn’t get assigned the required VLAN ID upon successful authentication
against a specific SSID ?
Should I forget about VLAN 10 that is assigned to Staff role and only assign
VLAN 10 to registration ?
Eugene
From: Durand fabrice via PacketFence-users
<packetfence-users@lists.sourceforge.net>
Sent: Wednesday, July 03, 2019 5:52 PM
To: packetfence-users@lists.sourceforge.net
Cc: Durand fabrice <fdur...@inverse.ca>
Subject: Re: [PacketFence-users] Manual device registration to allow it to the
network
Hello Eugene,
it's something really easy to do.
First in the switch config assign -1 to the registration role (it will reject
the device that is not reg) and assign the correct vlan id for the other roles.
Next create a connection profile with a filter that match the ssid and don't
assign any sources.
And at the end register the device you want and assign a role manually.
That's it.
Regards
Fabrice
Le 19-07-03 à 14 h 44, E.P. via PacketFence-users a écrit :
Now I’m getting confused after trying to understand RADIUS enforcement.
Reading the document that says:
Using RADIUS enforcement, everytime a device connects to the network, a
matching production VLAN will be assigned, depending on the rules in
Configuration→Policies and Access Control→Authentication Sources
The only place (or rather configuration component) to assign VLAN is in Roles
under the switch (or switch group) where I add VLAN ID in “Role mapping by VLAN
ID”. Am I correct ?
So, for example, I have Staff role with VLAN 10 added to it in the switch
group.
Then upon a user successful authentication and a condition matching in the
authentication rule the action is assigned, namely unregistration date and role
assignment.
It all works and the endpoint gets connected but its status shows as
unregistered and role unassigned under Nodes section in PacketFence Web UI. But
as it seems to me an endpoint gets connected because VLAN ID assignment is
pushed from the Wireless system controller for a specific SSID. If I remove it
and assign this duty to RADIUS then it doesn’t work.
An endpoint can’t connect because it doesn’t receive an IP address because the
AP doesn’t put it to the required VLAN
Eugene
From: E.P. <mailto:ype...@gmail.com> <ype...@gmail.com>
Sent: Wednesday, July 03, 2019 10:11 AM
To: packetfence-users@lists.sourceforge.net
<mailto:packetfence-users@lists.sourceforge.net>
Cc: 'Nicolas Quiniou-Briand' <mailto:n...@inverse.ca> <n...@inverse.ca>
Subject: RE: [PacketFence-users] Manual device registration to allow it to the
network
Hi Nicolas,
Yes, I of course mean dot1x 😉
My RADIUS authorization part is limited at this point, RADIUS doesn't assign
the VLAN to the endpoint session.
Should I interpret your advice as I have to implement authorization via RADIUS
and only then an unregistered/unassigned endpoint won't have access until the
manual assignment ?
Eugene
-----Original Message-----
From: Nicolas Quiniou-Briand via PacketFence-users
<packetfence-users@lists.sourceforge.net>
Sent: Wednesday, July 3, 2019 12:13 AM
To: packetfence-users@lists.sourceforge.net
<mailto:packetfence-users@lists.sourceforge.net>
Cc: Nicolas Quiniou-Briand <n...@inverse.ca <mailto:n...@inverse.ca> >
Subject: Re: [PacketFence-users] Manual device registration to allow it to the
network
Hello Eugene,
On 2019-07-03 8:10 a.m., E.P. via PacketFence-users wrote:
> Does it seem doable ?
Yes. When you say (via WPA2-Enterprise/RADIUS), you mean with 802.1X ?
> I compared two endpoints, one of them is registered with a role and
> the other one is unregistered without a role and both have normal
> access once they successfully authenticated
When you add a node to PF by hand, device will be automatically registered with
the role you assigned. Consequently, RADIUS authorization step will not occur
when device is plugged on the network, only authentication.
--
Nicolas Quiniou-Briand
<mailto:n...@inverse.ca> n...@inverse.ca :: +1.514.447.4918 *140 ::
<https://inverse.ca> https://inverse.ca Inverse inc. :: Leaders behind SOGo (
<https://sogo.nu> https://sogo.nu), PacketFence
( <https://packetfence.org> https://packetfence.org) and Fingerbank (
<http://fingerbank.org> http://fingerbank.org)
_______________________________________________
PacketFence-users mailing list
<mailto:PacketFence-users@lists.sourceforge.net>
PacketFence-users@lists.sourceforge.net
<https://lists.sourceforge.net/lists/listinfo/packetfence-users>
https://lists.sourceforge.net/lists/listinfo/packetfence-users
_______________________________________________
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
<mailto:PacketFence-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/packetfence-users
_______________________________________________
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users
