Assigning Users to Groups Dynamically
Hi! I've been looking through the wiki, but thus far, I've not found anything that describes what I'd like to be able to do. We manage on-site hardware for our clients, and that hardware includes routers, gateways, switches, etc. What I'd like to be able to do is assign a user to a group dynamically, based on some identifying parameter received in the access request, and then have the group's attributes passed back in the access accept packet. 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 the number of attributes we need to manage for each user, instead having a short list of groups with attributes that can be assigned on the fly. I don't know if I've explained this in a way that makes sense (I hope it makes sense to someone!), but I wonder if there's a way to do what I've described. Hopefully, Jim
It doesn’t appear anyone else has tried tackling this one (good reasons for that). FreeRadius does in fact provide the tools to help you accomplish what you are looking for. The solution, however, requires you to have a properly designed datastore in your AAA system. Indeed, the vast majority of work to implement any solution will be on the datastore, not FreeRadius. I imagine most other users here employ either a sql database, ldap directory, or both in there own system. I use OpenLDAP. I strongly recommend you do some research on how to implement role/group based access in LDAP. 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. Within that virtual server I’d call an ldap module defined to query for the radiusProfile which bundles the VSA’s that device class cares about. The virtual-server can then attached those VSA’s to the reply… 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 control structure that calls the appropriate ldap module. But again, the work is largely in the datastore design, not the radius config. The more granular the access you need, the more complicated your data design will become. It’s not a fitting conversation for this list, so you need to do some reading. But I hope I’ve given you some direction.
On Dec 16, 2015, at 4:23 PM, J Kephart <jkephart@safetynetaccess.com> wrote:
Hi!
I've been looking through the wiki, but thus far, I've not found anything that describes what I'd like to be able to do.
We manage on-site hardware for our clients, and that hardware includes routers, gateways, switches, etc. What I'd like to be able to do is assign a user to a group dynamically, based on some identifying parameter received in the access request, and then have the group's attributes passed back in the access accept packet.
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 the number of attributes we need to manage for each user, instead having a short list of groups with attributes that can be assigned on the fly.
I don't know if I've explained this in a way that makes sense (I hope it makes sense to someone!), but I wonder if there's a way to do what I've described.
Hopefully,
Jim - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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 -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
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
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
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
participants (3)
-
J Kephart -
Mark Williams -
Matthew Newton