> On Nov 20, 2019, at 03:54, john heasley <[email protected]> wrote: > > Wed, Nov 20, 2019 at 05:30:29AM +0000, Joe Clarke (jclarke): >> Lada replied on YANG docs with a suggestion for the T+ module authors. >> While we can’t affect the authentication-order node, the tacacsplus >> container could be defined like: >> >> augment "/sys:system" { >> container tacacs { >> must "not(derived-from-or-self(" >> + "../sys:authentication/sys:user-authentication-order, 'tacacs')" >> + "or server"; >> list server { >> ... >> } >> } >> } >> >> In this manner, T+ can provide enforcement. Lada also mentioned that this >> would have been a better way of handling RADIUS in ietf-system. Certainly >> this could be an item for a .bis, but not sure if this alone is worth taking >> on that work. > > That would be an improvement, but I still assert that this constraint is > not necessary nor desired - tacacs nor radius - if I'm reading that > correctly (XPATH often confuses me).
This XPath looks at the authentication order list to see if any node in it is “tacacs” (or tacacsplus in what we’d want). If so, it enforces at least one server to be specified. So I think you’re reading it right. I agree, it likely isn’t required. It does, however, get someone to think about properly configuring T+ if they are going to enable it in the order. So it’s a nice to have. > > ps. parens imbalanced? Yeah, yeah :-). Mac Mail caused some weirdness. Also, note, this is “pseudo-code” as we will want to use “tacacsplus” instead of just “tacacs”. Joe _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
