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@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