On 3/22/17 1:26 PM, Fabrice Durand wrote: > So what you can do is to trigger a violation when the device try to > reach the wrong ssid and remove it when it go back on the good ssid.
I had played around with that. I was able to trigger the violation, but
I wasn't able to figure out how to remove the violation when they moved
to the correct SSID. I have other use cases that I'm going to want to do
something like this.
> Regards
>
> Fabrice
>
>
>
> Le 2017-03-21 à 22:33, Charles Rumford a écrit :
>> I had thought about doing something like this, but the registration is
>> the part that I'm concerned about. If we have a user accidentally
>> connect to the wrong network, the user is going to have to go through
>> the entire registration again.
>>
>> I could do an auto-registration thing in the VLAN filters, but the
>> unregistration date is lost after you unregistered a device. When the
>> user returns to the correct SSID, the device needs to be auto registered
>> the same date as before.
>>
>> In playing with ways to preserve the unregdate, I though about storing
>> it in the notes field temporarily, and then using it later to register
>> the device, but I seem to have run into an issue.
>>
>> If I do something like:
>>
>> [not_apng:PennDevice_dev&PennDevice_Roles]
>> scope = RegisteredRole
>> action = modify_node
>> action_param = mac = $mac, notes = $node_info.unregdate
>>
>> All I get in the notes field is: HASH(0x7f480d7f8990).unregdate
>> In the VLAN filters file, there is an example for getting data from
>> radius requests by doing:
>> $radius_request->{'Called-Station-Id'}
>> But this results in something similar.
>>
>> I can get around the unregdate issue if $node_info.unregdate worked.
>>
>>
>> On 3/21/17 9:50 PM, Durand fabrice wrote:
>>> Hello Charles,
>>>
>>> i will do something like that:
>>>
>>> VLAN Filters:
>>> [Guest]
>>> filter = ssid
>>> operator = is
>>> value = Guest
>>>
>>> [IoT]
>>> filter = ssid
>>> operator = is
>>> value = IoT
>>>
>>> [IoT_Roles]
>>> filter = node_info.category
>>> operator = regex
>>> value = ^IoT.*
>>>
>>> [Guest_Roles]
>>> filter = node_info.category
>>> operator = regex
>>> value = ^Guest.*
>>>
>>> [not_guest:Guest&IoT_Roles]
>>> scope = RegisteredRole
>>> role = Guest-Reg #Tells the WLAN controller to do captive portaling
>>> action = modify_node
>>> action_param = mac = $mac, status = unreg
>>>
>>>
>>> [not_apnd:IoT&Guest_Roles]
>>> scope = RegisteredRole
>>> role = IoT-Reg #Tells the WLAN controller to do captive portaling
>>> action = modify_node
>>> action_param = mac = $mac, status = unreg
>>>
>>>
>>> You need to change the status of the device in the database because when
>>> the device will hit the portal PacketFence test the status of the device
>>> and if it's reg then it will revaluate the access.
>>>
>>> Btw you will need to register the device again.
>>>
>>> Regards
>>>
>>> Fabrice
>>>
>>>
>>>
>>>
>>>
>>> Le 2017-03-21 à 18:29, Charles Rumford a écrit :
>>>> Hey -
>>>>
>>>> I'm currently in the process of setting up PacketFence to handle our
>>>> Guest Networking. Down the line, we are going to be adding more services
>>>> to this server.
>>>>
>>>> This server will eventually be handling two different SSIDs: Guest and
>>>> IoT. I have a number of different roles associated with the two SSIDs:
>>>> Guest-Reg, Guest-Auth, IoT-Reg, and IoT-Auth. What I want to do is if a
>>>> node has a role of IoT and connects to Guest to present them with a
>>>> captive portal telling they aren't allowed there, and vice versa.
>>>>
>>>> I have the following in place:
>>>>
>>>> VLAN Filters:
>>>> [Guest]
>>>> filter = ssid
>>>> operator = is
>>>> value = Guest
>>>>
>>>> [IoT]
>>>> filter = ssid
>>>> operator = is
>>>> value = IoT
>>>>
>>>> [node_is_registered]
>>>> filter = node_info.status
>>>> operator = is
>>>> value = reg
>>>>
>>>> [IoT_Roles]
>>>> filter = node_info.category
>>>> operator = regex
>>>> value = ^IoT.*
>>>>
>>>> [Guest_Roles]
>>>> filter = node_info.category
>>>> operator = regex
>>>> value = ^Guest.*
>>>>
>>>> [not_guest:Guest&IoT_Roles&node_is_registered]
>>>> scope = RegisteredRole
>>>> role = Guest-Reg #Tells the WLAN controller to do captive portaling
>>>>
>>>> [not_apnd:IoT&Guest_Roles&node_is_registered]
>>>> scope = RegisteredRole
>>>> role = IoT-Reg #Tells the WLAN controller to do captive portaling
>>>>
>>>> profiles.conf:
>>>> [Guest-Violation]
>>>> filter_match_style=all
>>>> preregistration=disabled
>>>> locale=
>>>> root_module=Guest-Violation
>>>> filter=ssid:Guest
>>>> sources=null
>>>> advanced_filter=category == "IoT-Auth"
>>>> dot1x_recompute_role_from_portal=0
>>>>
>>>> [Guest]
>>>> dot1x_recompute_role_from_portal=0
>>>> preregistration=disabled
>>>> locale=
>>>> filter=ssid:Guest
>>>> reuse_dot1x_credentials=enabled
>>>> sources=email-only
>>>> always_use_redirecturl=enabled
>>>> redirecturl=http://www.upenn.edu
>>>> root_module=Guest-Root
>>>>
>>>> I'm able to get a the captive portal generated by the profile
>>>> Guest-Violation, the problem is the captive portal doesn't present the
>>>> message I have configured in the module. It presents a error message
>>>> saying the network will be available shortly, and then PacketFence does
>>>> a re-eval of the node and sends role IoT-Auth to the controller.
>>>>
>>>> Is there any way to prevent the re-eval in the captive portal and to
>>>> force it into the message? The major thing is if the device returns to
>>>> the IoT SSID then I want it to connect successfully.
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>
>>>>
>>>> _______________________________________________
>>>> PacketFence-users mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>
>>>
>>>
>>> _______________________________________________
>>> PacketFence-users mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>> _______________________________________________
>> PacketFence-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>
> --
> Fabrice Durand
> [email protected] :: +1.514.447.4918 (x135) :: www.inverse.ca
> Inverse inc. :: Leaders behind SOGo (http://www.sogo.nu) and PacketFence
> (http://packetfence.org)
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> PacketFence-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>
--
Charles Rumford
Senior Network Engineer
ISC Tech Services
University of Pennsylvania
OpenPGP Key ID: 0xF3D8215A
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ PacketFence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
