MAVIS/RADIUS - Load Balancing with spawnd

[Dmitriy Ivanisko]

Hi Marc

My current TACACS+ test setup uses RADIUS as MAVIS authentication backend where RADIUS sends the name of the group (as a Radius Attribute in Access-Accept packet) to indicate which group this particular user is a member of. (Groups are locally configured in TACACS+ but users aren't.)

So far so good but when multiple worker processes (with spawnd) come into picture, things in my understanding are bound to go awry as to do load balancing spawnd will launch (and kill!) more instances of tac_plus as and when required; however, when an instance will terminate so will the information about the authenticated users and their associated group(s).

I've looked through the code and the documentation but I'm afraid I don't see a way as to if and how a handover of information can be made from one server instance to the other to aid in the above scenario. Wondering if I am overlooking something really obvious or if there is currently no way to accomplish the above mentioned.

Looking forward to your response. Cheers!

[Marc Huber]

Hi Dmitriy,

yes, there's no synchronization at all between the tac_plus worker
processes.

RADIUS is supported for authentication only. Possible workarounds might
include a combination of a) single-connection, b) a high mavis cache
timeout and c) using the spawnd "sticky" feature.

Cheers,

Marc

[Marc Huber]

On 16.03.21 19:01, Marc Huber wrote:
> RADIUS is supported for authentication only. Possible workarounds might
> include a combination of a) single-connection, b) a high mavis cache
> timeout and c) using the spawnd "sticky" feature.

To add to that: snapshot 202103192040 introduces a "tacinfo_cache" MAVIS
module that caches authentication attributes to disk. This de-couples
authentication and authorization for the back-end and should make using
RADIUS as a user back-end somewhat more feasible.

Cheers,

Marc


 

[Dmitriy Ivanisko]

Thank you, Marc. 

Till date, I have relied on the holy combination of sticky cache, single-connection and fairly high value of mavis cache timeout for using RADIUS as a reliable user backend for MAVIS but looking at the March 20 and 21, 2021 snapshots, I believe those changes can provide a different/better way to accomplish the same.

Having said that, I know you left a note on radmavis changes that those changes are untested and I haven't tested them either (yet) but looking at the diff I believe the logic is to iterate over a list of AV pairs returned by RADIUS authentication and extracting the values for the chosen group attribute but I'm afraid, may be I'm terribly missing something, or "mc" really is missing value manipulation.

Cheers!

[Marc Huber]

Hi Dmitriy,

On 22.03.21 02:38, Dmitriy Ivanisko wrote:

Till date, I have relied on the holy combination of sticky cache, single-connection and fairly high value of mavis cache timeout for using RADIUS as a reliable user backend for MAVIS but looking at the March 20 and 21, 2021 snapshots, I believe those changes can provide a different/better way to accomplish the same.

yes, adding the tacinfo_cache module makes some other features obsolete. Group memberships will be saved to file and are available to all worker processes, at least on the same system. This:

mavis module = tacinfo_cache {
    directory = /tmp/tacinfo
}
mavis module = external {
    exec = /usr/local/sbin/radmavis ...
}

should be sufficient (but keep in mind that the daemon will not remove any files from the directory specified, so a cleanup cron job might be advisable).

Having said that, I know you left a note on radmavis changes that those changes are untested and I haven't tested them either (yet) but looking at the diff I believe the logic is to iterate over a list of AV pairs returned by RADIUS authentication and extracting the values for the chosen group attribute but I'm afraid, may be I'm terribly missing something, or "mc" really is missing value manipulation.

The "untested" radmavis part is the group retrieval code. Running radmavis with the "group_attribute=class" or "group_attribute=25" should now map the returned value to TAC_MEMBER, but I currently don't have a RADIUS server at home to test this.

Cheers,

Marc