[RADIATOR] Tacacs Authentication to survive reloads ?

[David Heinz]

Thanks Heikki,

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'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? :)

Thanks!

Dave Heinz




On 7/10/12 3:56 PM, "Heikki Vatiainen" <hvn at open.com.au> wrote:

>On 07/05/2012 07:25 PM, David Heinz wrote:
>
>> Not to bring this back up, but I too am having this "No context found.
>> Expired?" issue.
>
>We have thought about some possibilities solving this. There is no patch
>yet, but I thought I'd let you and the other list members know we are
>looking for a good solution.
>
>> The main reason for Radius restart on my side is permission changes to
>>the
>> AuthorizeGroup. This is the ONLY piece of my configuration I can't put
>> into a Db.
>> 
>> If you make a change to an AuthorizeGroup (say deny a command, or
>>permit a
>> command) you must rehup the process to re-read the AuthorizeGroup
>> configuration files.
>> This causes all current sessions to be "expired" and those folks now
>>must
>> log back into the router/switch they were on.
>
>Yes, Radiator is now more strict requiring the user is known to have
>previosly authenticated. This also enables returning AuthorizeGroupAttr
>and cisco-avpairs during authentication to be returned with authorization.
>
>> Is there a solution for this issue? Perhaps a new way of doing things?
>>I'm
>> open to any suggestions.
>
>I'll get back to this a bit later. Some code changes are likely to be
>needed, but even if there are no patches or patch candidates yet, I
>thought I'd at least break the silence :)
>
>Thanks,
>Heikki
>
>
>> -Dave
>> 
>> 
>> 
>> On 5/11/12 4:55 PM, "Heikki Vatiainen" <hvn at open.com.au> wrote:
>> 
>>> On 05/11/2012 09:38 PM, James wrote:
>>>> I can't seem to get this working.
>>>
>>> Try this instead:
>>>
>>>>     ClientAttrDef device-type,Identifier
>>>
>>>     ClientAttrDef device-type,Name
>>>
>>>>     ClientAttrDef tacacs-key,TACACSPLUSKey
>>>> </ClientListLDAP>
>>>>
>>>> --8<--
>>>>
>>>> Since we use different TACACS+ keys for different types of network
>>>> devices, it is important that I be able to grab the key for a
>>>> particular Client from each LDAP entry.
>>>
>>> The above suggestion is based on the guess that device-type has the IP
>>> address or name that would go into <Client IP/name> when doing a static
>>> configuration.
>>>
>>> Heikki
>>>
>>> -- 
>>> 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,
>>> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
>>> DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
>>> NetWare etc.
>>> _______________________________________________
>>> radiator mailing list
>>> radiator at open.com.au
>>> http://www.open.com.au/mailman/listinfo/radiator
>> 
>
>
>-- 
>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,
>TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
>DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
>NetWare etc.
>
>