[RADIATOR] Multiple user groups for tacacs authorization possible

[Alexander Hartmaier]

Hi Heikki and Mike,

@Mike: that sounds like what I'm currently doing and what I also wrote
to the list some month ago.
@Heikki: yes, i've also thought about that. A first match logic would be
the easiest to implement like a firewall ruleset. So if the user is
member of two groups and there is no AuthorizeGroup statement for the
first group the next is tried. That will at least enable to simply map
ldap groups to AuthorizeGroups even if not all of them are used.

How would one implement AuthorizeGroups per device groups?
We have multiple teams each mainly responsible for a group of devices
e.g. the switching team accessing switches. They should have admin
rights, some of the other teams limited access.
I already get the support group from a db using ClientListSQL and put it
into the OSC-Group-Identifier attribute.

Cheers, Alex

Am 2011-07-09 01:02, schrieb Mike McCauley:
> Hi Heikki,
>
> I did something similar to this at NBNCo (you have the configs I think).
> In that one we used the LDAP to get the groups the users is a member of, and
> used the device group the request cam from to to do a lookup in SQL, From
> there we get AuthorizeGroupAttr rules.
>
> Cheers.
>
> On Friday 08 July 2011 09:51:08 pm Heikki Vatiainen wrote:
>> On 07/07/2011 01:26 PM, Alexander Hartmaier wrote:
>>> we have the need to map users with membership in multiple groups into
>>> tacacs groups to decide if the user is allowed to login (authentication)
>>> and what the user is allowed to do (authorization).
>>> We solved the authentication by multiple authby ldap2's  for the
>>> different ldap groups in an authby group.
>>> The first matched group populates the OSC-Group-Identifier attribute
>>> which is used for the GroupMemberAttr.
>>> Because some users are in multiple groups we're looking for a way to add
>>> all of them to the GroupMemberAttr, is this possible?
>> This does not sound possible. Please see this example. Is this what you
>> are looking for?
>>
>> <Server TACACSPLUS>
>>    GroupMemberAttr OSC-Group-Identifier
>>    AuthorizeGroup group1 ...
>>    # more rules for group1
>>    AuthorizeGroup group2 ...
>>    # more rules for group2
>>
>> And the Access-Reply messages would look like these
>>
>> User a:
>>    OSC-Group-Identifier = group1
>> User b:
>>    OSC-Group-Identifier = group2
>> User c:
>>    OSC-Group-Identifier = group1
>>    OSC-Group-Identifier = group2
>>
>> The user c would be allowed (group1 + group2).
>>
>> The above is not currently possible since Radiator currently only picks
>> up one attribute and uses its value. The second will not be used.
>>
>> Also, there's the question if both group1 and group2 contain permit and
>> deny rules how they would relate to each other.
>>
>> If the above is not what you are after, please tell us more.
>>
>> Thanks!
>
>

*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH   Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*