Assigning Users to Groups Dynamically

[Mark Williams]

Awesome! The huntgroups are not something I have ever used, so I don’t know much about them. Matthew could probably speak more to the pitfalls. I’ll have to do some research into that module soon. Might come in handy this summer.

> On Dec 30, 2015, at 2:35 PM, J Kephart <jkephart at safetynetaccess.com> wrote:
> 
> 
> 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
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html