> Is it possible to limit a tacacs-group to only configure interfaces > and prohibit the rest of the configure options?
yes, it is -- with certain restrictions (the most important being that the "single-connection" flag needs to be set in your router's TACACS+ server definition).
Please have a look at the "CLI Contexts" chapter in the documentation. The example given there should cover your use case.
i defined already single-connection, also in the tac_plus.cfg. But I didn't understand how to put the configure-command in the context - I can configure as cmd - and then?
Thanks Robert
Am Donnerstag, 8. November 2012 07:30:50 UTC+1 schrieb Marc Huber:
> On 08.11.12 07:15, rthl wrote: > > Is it possible to limit a tacacs-group to only configure interfaces > > and prohibit the rest of the configure options? > yes, it is -- with certain restrictions (the most important being that > the "single-connection" flag needs to be set in your router's TACACS+ > server definition).
> Please have a look at the "CLI Contexts" chapter in the documentation. > The example given there should cover your use case.
> i defined already single-connection, also in the tac_plus.cfg. But I > didn't understand how to put the configure-command in the context - I > can configure as cmd - and then?
the TACACS+ protocol itself doesn't know or care about the CLI context on the router. The daemon just sees the command sequence entered by the user and sets the context variable accordingly, using the build-in minimalistic scripting language. To quote the example from the docs:
service = shell {
default cmd = permit
set priv-lvl = 15
script = {
if (cmd == "") permit # shell startup
if (cmd =~ /^interface FastEthernet 0\/1 /) {
message = "Context has been set. \"[no] shut\" should work for you."
context = FE
permit
} else if (cmd =~ /^interface/){
message = "Context has been reset."
context = ""
permit
}
if (context == FE) {
if (cmd =~ /^shutdown/) permit
if (cmd =~ /^no shutdown/) permit
deny
}
}
cmd = shutdown { deny . }
cmd = no { deny /^shutdown/ }
}
This service definition sets the current CLI session context to "FE" if Fa0/1 interface context is entered via the CLI ("interface FastEthernet 0/1") and resets context if a different interface gets selected. "(no) shut" is permitted only if context is set to "FE". The generic "cmd = shutdown..."/"cmd = no ..." statements are just there to cover the case where single-connection isn't active.
} } # end Script } # end Shell } # end group tk-admins
}
I had the "configure" command already out of the script, but either I can use "configure t" and then I can configure everything, or I don't get configure at all. But how can I permit "configure t" and then set the context to "interface"???
> But how can I permit "configure t" and then set the context to > "interface"???
you can't. The TACACS+ protocol simply doesn't provide that option. You can permit "configure terminal" and use the embedded scripting language to permit/deny commands based on context (which is based on previous authorization requests matching the CLI session). CLI commands need to be entered by the user. Very simple (single-line) commands (show ...) can be set using the "autocmd" attribute, but that won't be sufficient.
> On 08.11.12 09:43, rthl wrote: > > But how can I permit "configure t" and then set the context to > > "interface"??? > you can't. The TACACS+ protocol simply doesn't provide that option. You > can permit "configure terminal" and use the embedded scripting language > to permit/deny commands based on context (which is based on previous > authorization requests matching the CLI session). CLI commands need to > be entered by the user. Very simple (single-line) commands (show ...) > can be set using the "autocmd" attribute, but that won't be sufficient.
> OK, I keep trying, you don't have a working example?
sure, the one I've sent in my previous mail.
> Using SSHv2, logging in the NAS only the preconfigured standard motd > banner is displayed.
The banners work for telnet to stock IOS devices. Everything else (ssh, or non-IOS systems) may or may not work as expected. This pretty much depends on the client code on the router, but I've serious doubts that opening a case would help.
> On 08.11.12 15:57, rthl wrote: > > OK, I keep trying, you don't have a working example? > sure, the one I've sent in my previous mail.
> > Using SSHv2, logging in the NAS only the preconfigured standard motd > > banner is displayed. > The banners work for telnet to stock IOS devices. Everything else (ssh, > or non-IOS systems) may or may not work as expected. This pretty much > depends on the client code on the router, but I've serious doubts that > opening a case would help.
one more thing: right now I even can't get the examples to work. It get's more difficult, as the changes in the config aren't active at once, also I have no idea why (posted it already). It already has problems with the regexes. I tried to compile with PCRE, but seems not to work. It complains already at the configure-statement, when I try to give the pcre-options.
How can I check the compiled program, which regex it uses?
Thanks Robert
Am Donnerstag, 8. November 2012 07:15:02 UTC+1 schrieb rthl:
> It already has problems with the regexes. I tried to compile with > PCRE, but seems not to work. It complains already at the > configure-statement, when I try to give the pcre-options.
> How can I check the compiled program, which regex it uses?
POSIX regular expressions will be always available. Whether PCRE support is compiled in can be checked via
