Initial testing shows this working with an “unregistered” device and this is 
what shows in the Radius audit logs.

Reply-Message = "This node is not allowed to use this service”

Louis Scaringella
Security Systems Engineer
Yellow Dog Networks, Inc
785-342-7903

> On Jun 4, 2020, at 10:40 PM, Louis Scaringella 
> <lscaringe...@yellowdognetworks.com> wrote:
>
> Ok, thank you. I think I have it setup and will test as soon as I can.
>
> I think most of the filter you mentioned is self-explanatory, but wanted to 
> clarify on the “scope”. Is the scope just the area of PacketFence where this 
> determination is being made, in my case it would be the registration role or 
> registration of the device?
>
> I just want to understand completely what this is.
>
> Louis Scaringella
> Security Systems Engineer
> Yellow Dog Networks, Inc
> 785-342-7903
>
>> On Jun 4, 2020, at 9:56 PM, Durand fabrice via PacketFence-users 
>> <packetfence-users@lists.sourceforge.net> wrote:
>>
>> Hello Louis,
>>
>> my answer bellow.
>>
>> Le 20-06-04 à 21 h 53, Louis Scaringella via PacketFence-users a écrit :
>>> Hello,
>>>
>>> Thank you for your time in helping.
>>>
>>> I am working with a client and the goal is to build upon the current 802.1X 
>>> PEAP environment they have with Windows NPS and expand this to use 
>>> PacketFence and to limit BYOD by using MAC address authentication in 
>>> conjunction with 802.1X PEAP.
>>>
>>> Ideally, I would like to use PacketFence to maintain this MAC address 
>>> database and authenticate against Active Directory for user auth. The 
>>> 802.1X PEAP side of things works well and I have had success multiple times 
>>> in deploying this with Active Directory as the authenticate source just 
>>> fine. MAC auth is the portion i’m struggling with getting to work properly.
>>>
>>> The MAC addresses would be populated manually and imported into PacketFence 
>>> by my client’s IT team.
>>>
>>> Ideally, what the flow of authentication would be is to have the user 
>>> attempt to connect to the wireless network. Their Aruba controller would be 
>>> setup to handle both MAC auth and 802.1X and pass that to PacketFence via 
>>> Radius. PacketFence would then check it’s database for the MAC address and 
>>> if found move to 802.1X user auth. If the user authenticates to Active 
>>> Directory successfully, the connection is allowed.
>>
>> No, i don't think this is the correct approach.
>>
>> What you can do is simple, if the IT team import the mac then it mean that 
>> the list of mac they import become "registered".
>>
>> So what you can do, is to create a connection profile with:
>>
>> Autoregister disabled
>>
>> Recompute from portal enabled
>>
>> Then create a vlan filter like this:
>>
>>
>> node.status =unreg
>>
>> scope=RegistrationRole
>>
>> role = REJECT
>>
>>
>> So it mean that even if your 802.1x authentication succeed if your device is 
>> not register in packetfence then reject the authentication.
>>
>>> I don’t want to use any concept of registered vs unregistered devices and 
>>> don’t want self registration or captive portal of any kind. I just simply 
>>> want to make sure the MAC address of the supplicant is a member of 
>>> PacketFence’s database.
>>
>> You will need the concept of registered vs unregistered but the IT team 
>> decide who is reg vs unreg.
>>
>>
>>> I already have set this up and what is happening is 802.1X is working fine 
>>> and the user is authenticating, but it isn’t limiting the connection by MAC 
>>> address. In other words, devices which are not in the database are allowed 
>>> to connect if they provide valid user credentials. I can’t seem to restrict 
>>> new “BYOD” devices.
>>>
>>> Do any of you have experience or some insight that would help here?
>>>
>>> Louis Scaringella
>>> Security Systems Engineer
>>> Yellow Dog Networks, Inc
>>> 785-342-7903
>>>
>>> The information transmitted, including any attachments, is intended only 
>>> for the person or entity to which it is addressed and may contain 
>>> confidential and/or privileged material. Any review, retransmission, 
>>> dissemination or other use of, or taking of any action in reliance upon, 
>>> this information by persons or entities other than the intended recipient 
>>> is prohibited, and all liability arising therefrom is disclaimed. If you 
>>> received this in error, please contact the sender and delete the material 
>>> from any computer.
>>>
>>> _______________________________________________
>>> PacketFence-users mailing list
>>> PacketFence-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>>
>> Regards
>>
>> Fabrice
>>
>>
>>
>>
>> _______________________________________________
>> PacketFence-users mailing list
>> PacketFence-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>

The information transmitted, including any attachments, is intended only for 
the person or entity to which it is addressed and may contain confidential 
and/or privileged material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon, this information by persons 
or entities other than the intended recipient is prohibited, and all liability 
arising therefrom is disclaimed. If you received this in error, please contact 
the sender and delete the material from any computer.

_______________________________________________
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users

Reply via email to