[RADIATOR] Gossip and Tacacs

[Patrik Forsberg]

> > 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 ;)

Thanks,
Patrik