Le 19-07-04 à 03 h 05, E.P. a écrit :

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)

Yes ntlm_auth worked and packetfence return the vlan 2.

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.

It looks that your ssid/port is mapped to the vlan 10 and there is no dynamic vlan assignment or maybe the vlan 2 is not defined (check the AP/controller/switch config).

What equipment are you using ?

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 ?

Ok so for 802.1x you need to choose between having the captive portal to register or auto register the device and assign the role based on the rule.

So let's says your ssid name is BOB , then create a connection profile with inside a filter SSID = BOB and add the OPTIONS-AD-SOURCE and check autoregister device.

In this case any device that successfully authenticate with 802.1x  will be autoreg and the role will be computed by the source  OPTIONS-AD-SOURCE.

Now let's take the case that you want to see the portal to register, you just have to uncheck the option autoreg devces.


Now regarding the registration vlan, this vlan is managed by packetfence (pf is the dhcp/dns/default GW) and packetfence needs to have a interface in this vlan and this vlan needs to be spanned on the network.

So when packetfence reply with the vlan 2 then the device will do a dhcp discover and it will be the packetfence's dhcp server that will reply (it's not managed by your dhcp/dns/...).


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. <ype...@gmail.com> <mailto: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' <n...@inverse.ca>
    <mailto: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
    <mailto: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

    n...@inverse.ca <mailto:n...@inverse.ca> ::  +1.514.447.4918 *140 
    :: https://inverse.ca Inverse inc. :: Leaders behind SOGo
    (https://sogo.nu), PacketFence

    (https://packetfence.org) and Fingerbank (http://fingerbank.org)

    _______________________________________________

    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  
<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

Reply via email to