0001421: roles support doesn't handle re-assignment properly yet - PacketFence

Bug Tracking System

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0001421

PacketFence

core

public

2012-04-11 12:16

2015-02-13 15:35

Reporter

obilodeau

Assigned To

Priority

high

Severity

minor

Reproducibility

always

Status

closed

Resolution

open

Platform

OS Version

Product Version

Target Version

3.6.1

Fixed in Version

Summary

0001421: roles support doesn't handle re-assignment properly yet

Description

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

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

Tags

No tags attached.

fixed in git revision

fixed in mtn revision

Attached Files

Relationships

Notes
(0002642) obilodeau (reporter) 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 (administrator) 2015-02-13 15:35	No longer relevant.

Issue History
Date Modified	Username	Field	Change
2012-04-11 12:16	obilodeau	New Issue
2012-04-11 12:16	obilodeau	Status	new => assigned
2012-04-11 12:16	obilodeau	Assigned To	=> obilodeau
2012-04-11 12:43	obilodeau	Note Added: 0002642
2012-10-26 16:04	fgaudreault	Assigned To	obilodeau =>
2012-10-26 16:04	fgaudreault	Target Version	general => 3.6.1
2015-02-13 15:35	lmunro	Note Added: 0003737
2015-02-13 15:35	lmunro	Status	assigned => closed