Assigning Users to Groups Dynamically
martialstudy at hotmail.com
Fri Jan 1 19:19:01 CET 2016
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
>>>>> 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.
>> 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!
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
More information about the Freeradius-Users