Hello, Yes, I'm aware of that option. But despite setting it and seeing it being in use, aka. I see that it gets updated, the authentication doesn't survive the reload/restart.
Trace 4 Log info: -- the authentication - Fri Apr 13 09:21:46 2012: DEBUG: New TacacsplusConnection created for <equipment-ip>:50393 Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection request 192, 1, 1, 0, 536499257, 35 Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection Authentication START 1, 1, 1 for <username>, telnet261, <user-ip> Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection Authentication REPLY 5, 1, Password:, Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection request 192, 1, 3, 0, 536499257, 14 Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection Authentication CONTINUE 0, **obscured**, Fri Apr 13 09:21:46 2012: DEBUG: TACACSPLUS derived Radius request packet dump: Code: Access-Request Identifier: UNDEF Authentic: <163><31><160><245><140><7><134>J^<178><173><170><157>J@l Attributes: NAS-IP-Address = <equipment-ip> NAS-Port-Id = "telnet261" Calling-Station-Id = "<user-ip>" Service-Type = Login-User NAS-Identifier = "TACACS" User-Name = "<username>" User-Password = "**obscured**" cisco-avpair = "action=1" cisco-avpair = "authen_type=1" cisco-avpair = "priv-lvl=15" cisco-avpair = "service=1" OSC-Version-Identifier = "192" Fri Apr 13 09:21:46 2012: DEBUG: Handling request with Handler 'Realm=', Identifier 'HandlerMAINIdentUser' Fri Apr 13 09:21:46 2012: DEBUG: SessionDBM Deleting session for <username>, <equipment-ip>, Fri Apr 13 09:21:46 2012: DEBUG: Handling with Radius::AuthGROUP: AuthenticateMainUsers Fri Apr 13 09:21:46 2012: DEBUG: Handling with Radius::AuthGROUP: AuthenticateLuser1 Fri Apr 13 09:21:46 2012: DEBUG: Handling with Radius::AuthGROUP: Fri Apr 13 09:21:46 2012: DEBUG: Handling with Radius::AuthFILE: Fri Apr 13 09:21:46 2012: DEBUG: Reading users file /etc/radiator/mix/manager Fri Apr 13 09:21:46 2012: DEBUG: Radius::AuthFILE looks for match with <username> [<username>] Fri Apr 13 09:21:46 2012: DEBUG: Radius::AuthFILE ACCEPT: : <username> [<username>] Fri Apr 13 09:21:46 2012: DEBUG: Radius::AuthGROUP: result: ACCEPT, Fri Apr 13 09:21:46 2012: DEBUG: Radius::AuthGROUP:AuthenticateLuser1 result: ACCEPT, Fri Apr 13 09:21:46 2012: DEBUG: Handling with PAM service radiusd Fri Apr 13 09:21:46 2012: DEBUG: PAM is asking for 1: 'Password' Fri Apr 13 09:21:46 2012: DEBUG: Radius::AuthGROUP:AuthenticateLuser1 result: ACCEPT, Fri Apr 13 09:21:46 2012: DEBUG: Radius::AuthGROUP:AuthenticateMainUsers AuthenticateLuser1 result: ACCEPT, Fri Apr 13 09:21:46 2012: DEBUG: AuthBy GROUP result: ACCEPT, Fri Apr 13 09:21:46 2012: DEBUG: Access accepted for <username> Fri Apr 13 09:21:46 2012: DEBUG: Packet dump: *** Reply to TACACSPLUS request: Code: Access-Accept Identifier: UNDEF Authentic: <163><31><160><245><140><7><134>J^<178><173><170><157>J@l Attributes: Service-Type = Administrative-User Mikrotik-Group = "full" AuthGroup = "manager" Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection result Access-Accept Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection Authentication REPLY 1, 0, , Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection disconnected from <equipment-ip>:50393 Fri Apr 13 09:21:46 2012: DEBUG: New TacacsplusConnection created for <equipment-ip>:50787 Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection request 192, 2, 1, 0, 373655910, 54 Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection Authorization REQUEST 6, 15, 1, 1, <username>, telnet261, <user-ip>, 2, service=shell cmd= Fri Apr 13 09:21:46 2012: DEBUG: AuthorizeGroup rule match found: permit service=shell cmd= { priv-lvl=15 } Fri Apr 13 09:21:46 2012: INFO: Authorization permitted for <username> at <equipment-ip>, group manager, args service=shell cmd= Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection Authorization RESPONSE 1, , , priv-lvl=15 Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection disconnected from <equipment-ip>:50787 Fri Apr 13 09:21:46 2012: DEBUG: New TacacsplusConnection created for <equipment-ip>:36884 Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection request 192, 3, 1, 0, 2069353695, 72 Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection Accounting REQUEST 2, 6, 15, 1, 1, <username>, telnet261, <user-ip>, 2, start_time=1334330908 service=shell Fri Apr 13 09:21:46 2012: DEBUG: TACACSPLUS derived Radius request packet dump: Code: Accounting-Request Identifier: UNDEF Authentic: <1><193>fw<227><139><142><209>:<167>]<195><214><131><19><7> Attributes: NAS-IP-Address = <equipment-ip> NAS-Port-Id = "telnet261" Calling-Station-Id = "<user-ip>" NAS-Identifier = "TACACS" User-Name = "<username>" Acct-Status-Type = Start Acct-Session-Id = "2069353695" cisco-avpair = "start_time=1334330908" cisco-avpair = "service=shell" OSC-Version-Identifier = "192" Fri Apr 13 09:21:46 2012: DEBUG: Handling request with Handler 'Realm=', Identifier 'HandlerMAINIdentUser' Fri Apr 13 09:21:46 2012: DEBUG: SessionDBM Adding session for <username>, <equipment-ip>, Fri Apr 13 09:21:46 2012: DEBUG: Handling with Radius::AuthGROUP: AuthenticateMainUsers Fri Apr 13 09:21:46 2012: DEBUG: Handling with Radius::AuthGROUP: AuthenticateLuser1 Fri Apr 13 09:21:46 2012: DEBUG: Handling with Radius::AuthGROUP: Fri Apr 13 09:21:46 2012: DEBUG: Handling with Radius::AuthFILE: Fri Apr 13 09:21:46 2012: DEBUG: Radius::AuthGROUP: result: ACCEPT, Fri Apr 13 09:21:46 2012: DEBUG: Radius::AuthGROUP:AuthenticateLuser1 result: ACCEPT, Fri Apr 13 09:21:46 2012: DEBUG: Handling with PAM service radiusd Fri Apr 13 09:21:46 2012: DEBUG: Radius::AuthGROUP:AuthenticateLuser1 result: ACCEPT, Fri Apr 13 09:21:46 2012: DEBUG: Radius::AuthGROUP:AuthenticateMainUsers AuthenticateLuser1 result: ACCEPT, Fri Apr 13 09:21:46 2012: DEBUG: AuthBy GROUP result: ACCEPT, Fri Apr 13 09:21:46 2012: DEBUG: Accounting accepted Fri Apr 13 09:21:46 2012: DEBUG: Packet dump: *** Reply to TACACSPLUS request: Code: Accounting-Response Identifier: UNDEF Authentic: <1><193>fw<227><139><142><209>:<167>]<195><214><131><19><7> Attributes: Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection result Accounting-Response Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection Accounting REPLY 1, , Fri Apr 13 09:21:46 2012: DEBUG: TacacsplusConnection disconnected from <equipment-ip>:36884 -- reload of Radiator - Fri Apr 13 09:22:33 2012: NOTICE: SIGHUP received: restarting Fri Apr 13 09:22:34 2012: NOTICE: Server started: Radiator 4.9 on netauth-labb1 - kill usr1 to get trace level 4 again Fri Apr 13 09:22:36 2012: INFO: Trace level changed to 4 Fri Apr 13 09:22:36 2012: INFO: Trace level increased to 4 -- authorization being asked for after a reload has been done - Fri Apr 13 09:22:55 2012: DEBUG: New TacacsplusConnection created for <equipment-ip>:46162 Fri Apr 13 09:22:55 2012: DEBUG: TacacsplusConnection request 192, 2, 1, 0, 655684940, 70 Fri Apr 13 09:22:55 2012: DEBUG: TacacsplusConnection Authorization REQUEST 6, 15, 1, 1, <username>, telnet261, <user-ip>, 3, service=shell cmd=show cmd-arg=log Fri Apr 13 09:22:55 2012: INFO: Authorization denied for <username> at <equipment-ip>: No context found. Expired? Fri Apr 13 09:22:55 2012: DEBUG: TacacsplusConnection Authorization RESPONSE 16, Authentication expired, , Fri Apr 13 09:22:55 2012: DEBUG: TacacsplusConnection disconnected from <equipment-ip>:46162 -- info from the GroupCacheFile - <user>:<equipment-ip> manager -- Mvh, Patrik Forsberg > -----Original Message----- > From: Hugh Irvine [mailto:h...@open.com.au] > Sent: Thursday, April 12, 2012 11:55 PM > To: Patrik Forsberg > Cc: radiator@open.com.au > Subject: Re: [RADIATOR] Tacacs Authentication to survive reloads ? > > > Hello Patrick - > > See the following in "doc/ref.pdf": > > > 5.88.12 GroupCacheFile > > ServerTACACSPLUS can maintain a cache of username- > >tacacacs_group_name for use if Radiator is restarted between Tacacs > authorization and authentication. Defaults to /tmp/radiator-tacacs- > usergroup.cache. > > > regards > > Hugh > > > On 13 Apr 2012, at 00:49, Patrik Forsberg wrote: > > > Hi, > > > > Is there a way to make tacacs+ authentications to survive radiator > reload/restart ? > > > > As we're using Radiator to authenticate/account and authorize commands > on various equipment it gets quite annoying when a restart/reload is done > and the users have to re-login to be able to continue working. > > The current implementation seem to forget about the authentication and > simply reply with a deny and log > > " > > INFO: Authorization denied for <user> at <host>: No context found. > Expired? > > " > > which from my reading means that the authentication has timed out - it's > not but radiator thinks so as it can't find an active authentication from the > user(?). > > > > I remember that in a previous version of Radiator, not sure about version.. > think it was 3.something, there were no problem reloading/restarting > Radiator. > > > > Would it be possible to make a CacheReplyHook(or if there is a > PreShutdownHook?)/StartupHook that save/restore the sessions or > something ? :) > > > > > > (I'm currently using latest 4.9 with patch set from 2/4-2012) > > Regards, > > Patrik Forsberg > > > > _______________________________________________ > > radiator mailing list > > radiator@open.com.au > > http://www.open.com.au/mailman/listinfo/radiator > > > -- > > Hugh Irvine > h...@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@open.com.au http://www.open.com.au/mailman/listinfo/radiator