[tac_plus] DCNM tacacs roles

[Daniel Schmidt]

That sounds a lot like the Nexus, which worked as so:
https://www.tacacs.org/tacacsplus/2011/10/27/cisco-nexus

You may have luck with my after-authentication script:
https://github.com/helpdeskdan/do_auth

Let me know if you find it useful.

On Fri, Jun 25, 2021 at 3:37 PM heasley <heas at shrubbery.net> wrote:

> 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.
>
> _______________________________________________
> tac_plus mailing list
> tac_plus at www.shrubbery.net
> https://www.shrubbery.net/mailman/listinfo/tac_plus
>

-- 

E-Mail to and from me, in connection with the transaction 
of public 
business, is subject to the Wyoming Public Records 
Act and may be 
disclosed to third parties.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20210625/125d5a31/attachment.htm>