Hi,
> On 23 May 2018, at 16.49, Patrik Forsberg <[email protected]> wrote: > >>> I was wondering if the Gossip framework will make any difference for >>> Tacacs Authorization vs. Authentication ? That is if the radiator >>> process is killed for whatever reason will the Gossip framework help >>> it Authorize new requests ? or even help another server to authorize >>> the request(which would be preferred) ? >> >> Yes, this could be handled with Gossip (or by some other storage too). >> There's some functionality already implemented that may already be >> useful to this case. See the reference manual and >> goodies/tacacsplusserver.cfg and look for AllowAuthorizeOnly flag >> parameter. >> >> A more general approach would be to make Radius::Context storable. This >> which means a context could be stored and retrieved from Gossip, SQL, >> etc. and could be shared, when applicable, between processes. One >> possibility would be context created during TACACS+ authentication. >> >> In addition to your examples above, AllowAuthorizeOnly parameter is >> useful when the authentication is done with RADIUS, Kerberos, local or >> by some other means. In other words, when there's no TACACS+ >> authentication and servicing an authorization request without the >> respective authentication is deemed acceptable. > > We already have AllowAuthorizeOnly with the issue it has.. but the problem > still persist when the processes are restarted. > > I'm thinking this might have to do with the amount of requests the tacacs > server has to handle.. if I remember correctly the tacacs server runs a > single thread only so it would backup if several requests(say 50) would enter > at about the same time and might suffer from timeouts. The issue actually > shows up already at the password prompt as we set the password prompt in the > tacacs config and at times there seem to be no response back from the tacacs > server with the "new" prompt aka. no response at all so ofc an authorization > request that were to be sent during this time would also fail.. > > I'm also looking at using a Farm to amend this issue and ofc then Gossip > would again play it's role.. > > Authentication and Authorization is done by PAM atm, that in turn asks Active > Directory in the backend. > > I'll have to find a nice way to implement Gossip then I guess.. and as I > understand it UDP is still experimental so has to be Redis then.. oh well.. > fun fun ;) > Cache::FastMmap (used currently by a shared duplicate RADIUS request cache) would be useful for sharing TACACS+ contexts between FarmSize processes. Ref: https://metacpan.org/pod/Cache::FastMmap BR -- Tuure Vartiainen <[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://lists.open.com.au/mailman/listinfo/radiator
