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" <[email protected]> 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" <[email protected]> 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 <[email protected]> >>> >>> 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 >>> [email protected] >>> http://www.open.com.au/mailman/listinfo/radiator >> > > >-- >Heikki Vatiainen <[email protected]> > >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 [email protected] http://www.open.com.au/mailman/listinfo/radiator
