[RADIATOR] Tacacs Authentication to survive reloads ?

Heikki Vatiainen hvn at open.com.au
Tue Jul 10 15:50:35 CDT 2012

On 07/10/2012 11:31 PM, David Heinz wrote:

> I'm willing to move to a method that allows the reloads, however I don't
> see any example of how to accomplish the same functionality utilizing the
> AuthorizeGroupAttr.

I guess I was a bit unclear. What I meant is e.g., AuthorizeGroupAttr
requires the current functionality where more strict tracking of active
sessions is needed. Pre 4.8 versions did not have AuthorizeGroupAttr, so
reloading did not cause the problems you are currently seeing.

> I'm going to stand up a new lab device and start testing with it however
> and see if I can figure it out. Do I just set the Attribute and things
> magically start working? :)

If you want to try this, this is how it goes: In the config you have this:

   GroupMemberAttr    tacacsgroup
   AuthorizeGroupAttr authrorizegroupattr

In the user DB, FILE in this example, you have this:

mikem User-Password = fred
        tacacsgroup = group1,
        authrorizegroupattr = "permit service=shell cmd=show cmd-arg=.*"

Whatever is returned with authorizegroupattr attribute is checked before
'AuthorizeGroup group1 ...' entries. This is useful for doing per user
customisation. You could have the basic settings for a group of people
with specific rules as needed without the need to set lots of groups
that only differ a little.

However, when Radiator is reloaded, the knowledge about
authrorizegroupattr is lost.

But as I mentioned, we are currently considering options that make
reloading less problematic.


Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.

More information about the radiator mailing list