PacketFence - BTS - PacketFence
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001421PacketFencecorepublic2012-04-11 12:162015-02-13 15:35
Reporterobilodeau 
Assigned To 
PriorityhighSeverityminorReproducibilityalways
StatusclosedResolutionopen 
PlatformOSOS Version
Product Version 
Target Version3.6.1Fixed in Version 
fixed in git revision
fixed in mtn revision
Summary0001421: roles support doesn't handle re-assignment properly yet
DescriptionDue to time constraints, this is a remaining issue of our feature/roles-experiment branch (https://github.com/inverse-inc/packetfence/pull/7 [^]).

Basically, if a node changes category but the access re-evaluation returns the same VLAN as the node is currently set to, no deauthentication will take place.

This will affect users with few production VLANs and relying on roles instead to do access control.

Possible workarounds include: asking users to disconnect / reconnect (or reboot) when re-categorized, changing one line in the code to force deauthentication under certain circumstances or changing VLAN ids in switches.conf and setting proper end-point VLAN in the role on the controller.

We could probably come up with other workarounds too if we think about it a little bit more.

Will be fixed in next release.
Steps To Reproduce1. Use roles-based access control
2. Have several categories of users which end-up in the same VLAN
3. Change an active node's category
4. access re-evaluation is performed, VLAN is compared, should be in same VLAN (but in a different role now)

Exected result:
User deauthentication, new RADIUS Access-Request from user then new role assignment.

Actual result:
Since locationlog's vlan matches the VLAN that the user should be in no action is performed.
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-04-11 12:16obilodeauNew Issue
2012-04-11 12:16obilodeauStatusnew => assigned
2012-04-11 12:16obilodeauAssigned To => obilodeau
2012-04-11 12:43obilodeauNote Added: 0002642
2012-10-26 16:04fgaudreaultAssigned Toobilodeau =>
2012-10-26 16:04fgaudreaultTarget Versiongeneral => 3.6.1
2015-02-13 15:35lmunroNote Added: 0003737
2015-02-13 15:35lmunroStatusassigned => closed

Notes
(0002642)
obilodeau   
2012-04-11 12:43   
The fix will probably involve adding a role column to the locationlog table and modifying pf::SNMP, pf::radius so that the role returned is treated as a first class citizen (instead of being simply strapped on top of VLAN assignment).

Also, we will need to be careful with AeroHive's implementation since it overrides pf::SNMP's returnRadiusAccessAccept() method.
(0003737)
lmunro   
2015-02-13 15:35   
No longer relevant.