Assigning Users to Groups Dynamically

[J Kephart]

On 12/28/2015 09:00 AM, J Kephart wrote:
> Thanks Mark and Matthew.  We did come across the huntgroup
> documentation, and that sounds as if it might work; we're just going to
> have to dig into it--and experiment liberally--to see how it will work. 
> I'll let you know what we find!
>
>
> On 12/18/2015 01:05 PM, Matthew Newton wrote:
>> On Fri, Dec 18, 2015 at 12:36:11PM -0500, Mark Williams wrote:
>>> I could be very wrong, but it seems like what you really want is
>>> access defined, not per user, or even user group, but rather by
>>> device class/group. That has it’s own issues, but… if I were to
>>> implement something like this in my own environment… I would
>>> start with records/nodes for the users, some radiusProfiles that
>>> bundle VSA’s for different classes of devices, and then records
>>> for the clients themselves, each with a virtual-server attribute
>>> that matches a virtual-server in FreeRadius. A virtual-server
>>> specific to that group/class of devices.
>>> I’m still new to FreeRADIUS (really new), and the above was
>>> right off the top of my head, so there's surely a better way to
>>> do it. Actually you don’t even need multiple v-servers, just a
>> Sounds sensible. But I wouldn't split it into different virtual
>> servers without a good reason to.
>>
>> Just need to do two lookups. First, user to hardware type, then
>> secondly hardware type to group. If you want to fit into the
>> "traditional" way of doing this you might want to use huntgroups,
>> otherwise any sort of SQL or LDAP etc database lookup could be
>> used.
>>
>>>> So, for example, if any user wants to connect to Vendor A's gateway, we
>>>> might have a group defined for that type of device containing:
>>>>
>>>> vendor_a_gateway    Idle-Timeout    =    900
>>>> vendor_a_gateway    VSA_1           =    xxx
>>>> vendor_a_gateway    VSA_2           =    xxx
>>>> vendor_a_gateway    VSA_3           =    xxx
>>>>
>>>> Likewise, for Vendor B, we might have the following:
>>>>
>>>> vendor_b_switch     Idle-Timeout    =    600
>>>> vendor_b_switch     VSA_1           =    xxx
>>>> vendor_b_switch     VSA_2           =    xxx
>>>> vendor_b_switch     VSA_3           =    xxx
>>>>
>>>> Ultimately, then, if a user logs on to a device that we can categorize
>>>> as being Vendor A's gateway, we'd automatically associate that user with
>>>> the group "vendor_a_gateway", and so on.  In that way, we hope to limit
>> Yeah, so you're looking up something like the "NAS-IP-Address" in
>> one table to get "Group", then look up "Group" in another table to
>> get the reply attributes.
>>
>> Matthew
>>
>>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Matthew / Mark,

As it turns out, the simplest approach for us was to use cascading
entries in radgroupcheck.  After several fitful starts, we seem to have
it working.  An example:

+-----------+-------------------+----+----------------------+
| groupname | attribute         | op | value                |
+-----------+-------------------+----+----------------------+
| group_1   | Called-Station-Id | =~ | ^(xx-xx-xx|yy-yy-yy) |
| group_2   | Called-Station-Id | =~ | ^(xx-xx-xx|yy-yy-yy) |
| group_1   | User-Name         | == | smith                |
| group_1   |User-Name         | == | jones                |
| group_2   |User-Name         | == | johnson              |
+-----------+-------------------+----+----------------------+

In this way, when smith logs on from a device that matches the vendor
prefix of the called station ID fro group_1, he gets assigned the
attributes for group_1.  Likewise, johnson get the attributes for
group_2, and so on.  In our testing, this is working as it should.  Is
there anything we're missing that might bite us?

Thanks for the assist.  Much appreciated!

Jim