[tac_plus] DCNM tacacs roles

heasley heas at shrubbery.net
Fri Jun 25 20:37:31 UTC 2021


Wed, Jun 23, 2021 at 12:04:54PM -0400, Munroe Sollog:
> I don't want to get distracted from my actual problem, but after reading
> this:
> https://shrubbery.net/pipermail/tac_plus/2012-January/001048.html
> I thought the optional AVPs are not sent unless requested.  Either way, I'm
> trying to figure out why <cisco-av-pair:shell:roles= "network-admin"> works
> but <optional shell:roles = "network-admin"> does not work.

I went through the code, and it indeed does not return any AVPs that
were not received, though it may change their value.  My recollection
was that it returned them; sorry.

Without code changes, there is currently no way to force sending an
AVP from the config that was not received, except by using a before
or after authoritzation script.  eg:

#! /bin/sh
while read x; do
 case $x in
 cmd*)
   continue;
 ;;
 *)
   echo $x
 esac
done
# send/add the unsolicited avp
echo 'idletime=2'
exit 2

However, what I have discovered is that the rfc is vague about what the
client should do if it receives an optional AVP that it does not support.
It say ignore optionals, but does not say MUST, and at another point it
vaguely says that it must use replaced AVPs without specifing what to do
with optionals.  In my mind, it should ignore it, but IOS classic and XE
fail, unless it is one of the AVPs specified in rfc8907 S8.2.

For this reason, one of these scripts is probably the best solution
compared to code changes, as it allows the response to more easily be
tailored to the client, and do_auth.py might work for you.

YMMV, you will have to test your particular client.

It seems unlikely for this unspecificity to be corrected due to the history
of this rfc and implementations.



More information about the tac_plus mailing list