Assigning Users to Groups Dynamically

J Kephart jkephart at safetynetaccess.com
Wed Dec 30 20:35:46 CET 2015


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


More information about the Freeradius-Users mailing list