Return Access-Accept/-Reject depending on other active sessions during post-authentication
matthias.h.nagel at gmail.com
Sun Dec 16 16:11:12 CET 2012
my NAS supports used-based authentication, this means it is possible to have multiple sessions on the same ethernet port (same user multiple times and/or different users). Each attached supplicant must authenticate itsself. The switch prohibits a supplicant to use piggy-backing on top of some other already authenticated supplicant.
Moreover I use RADIUS-assigned VLANs. If the same user or different users that are assigned to the same VLAN are authenticated on the same port, everything is fine.
The trouble starts, if an additional user with a different VLAN than the VLAN that is already assigned to the port is sucessfully authenticated. In the past an additional user was denied access by the switch, if such a VLAN mismatch occured. This means is was impossible to have serveral different untagged VLANs on the same port.
But my current NAS also grants access to the addtional user and assignes this user's VLAN to the port, too. This means there are more than one untagged VLAN on the same port at the same time and the result is some kind of "short-circuit fault" between the affected VLANs.
Now, I would like to write some kind of RADIUS policy to prevent this behaviour. This policy is supposed to do the following during the post-authentication phase:
1) If there is no active session on the NAS port, just return Access-Accept
2) If there is at least one active session on the NAS port and the 'Tunnel-Private-Group-ID' of that session equals the 'Tunnel-Private-Group-ID' of the new request, return Access-Accept.
3) If there is at least one active session on the NAS port and the 'Tunnel-Private-Group-ID' of that session DOES NOT equal the 'Tunnel-Private-Group-ID' of the new request, return Access-Reject.
Is this possible to do? I have the accounting information in a SQL database, hence I know, if there are active sessions on some port. But I do not know, which would be the correct RADIUS configuration section and I do not know if "unlang" or some other configuration directive can perform such a check.
Best regards, Matthias
Willy-Andreas-Allee 1, Zimmer 506
e-Mail: matthias.h.nagel at gmail.com
More information about the Freeradius-Users