[tac_plus] Re: Working Command Authorization Script
Gibbs, Michael
mgibbs at verisign.com
Tue Jun 9 18:46:16 UTC 2009
Your right. I can't believe I missed that and tested on the only pair
without those commands on. Thanks for the quick correction.
Mike
> -----Original Message-----
> From: Schmidt, Daniel [mailto:dan.schmidt at uplinkdata.com]
> Sent: Tuesday, June 09, 2009 2:39 PM
> To: Gibbs, Michael; tac_plus at shrubbery.net
> Subject: RE: [tac_plus] Re: Working Command Authorization Script
>
> Works fine for me. Haven't seen your script though. You
> could just use mine on tacacs.org.
>
> Or, one thing I am noticing, you aren't authorizing commands.
>
> aaa authorization config-commands
> aaa authorization commands 1 default group tacacs+ none aaa
> authorization commands 15 default group tacacs+ none
>
> -----Original Message-----
> From: tac_plus-bounces at shrubbery.net
> [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Gibbs, Michael
> Sent: Tuesday, June 09, 2009 12:34 PM
> To: tac_plus at shrubbery.net
> Subject: [tac_plus] Re: Working Command Authorization Script
>
> Greetings,
>
> I have been playing with after authorization using Barry's
> script as an example. What I have seen is that TACACS never
> calls the script after the initial authentication and
> authorization is done during login. This means that the
> command control feature used in the script or for after
> authorization can't work. Is this expected or am I missing a
> configuration?
>
> Tacacs 4.0.18:
> group = LimitedAccess {
> default service = permit
> service = exec {
> priv-lvl=15
> idletime=15
> timeout=0
> }
> after authorization "/app/tacacs/etc/auth.pl $user
> $name $address /app/tacacs/etc/allow"
> }
>
> aaa new-model
> aaa authentication login default group tacacs+ line aaa
> authorization exec default group tacacs+ if-authenticated
>
> Thanks,
> Mike
>
> Fri, Apr 03, 2009 at 05:58:32PM +0100, Barry Stephen (YDD08)
> Derwent Shared Services:
> > I posted the other day about providing some users different
> levels of
> > access depending on the specific device they logged onto,
> in my case
> > Access versus Distribution & Core switches.
> >
> > Having read previous responses from various people I have
> managed to
> > create a working authorization script which checks what NAS a user
> > logged onto and if the NAS/Switch is in a specific list the commands
> are
> > checked against a list and only those commands are
> permitted. For all
> > other NASes (those not in the list) all commands are allowed.
> >
> > It took me a while to realise that the script is
> effectively taking on
> > the role of the tacacs+ deamon to some extent, that is to
> say that it
> is
> > not returning config/options to the tac_plus deamon in config file
> > format but direct to the NAS/switch. In any case, in this
> example we
> > simply say allow or deny rather than passing any AV pairs
> back to the
> > NAS.
> >
> > It is important to parse STDIN to see what command the NAS is
> requesting
> > auth for.
> >
> > I am using the after authorization method as the before
> authorization
> > method seemed a little harder to get working.
> >
> > This is my tac_plus.conf definition for these group of people:
> >
> > # Read/Write Access to non distribution devices - All commands
> > authorised group = rw-except-distribution {
> > default service = permit
> > service = exec {
> > priv-lvl=15
> > idletime=15
> > timeout=0
> > }
> > after authorization "/usr/bin/perl
> /etc/tac_plus_auth.pl $user
> > $name $address"
> > }
> >
> > I pass username, nas ip address and client ip address to my
> script but
> > only use nas address ($name) in my script. In my case $name
> is the NAS
> > IP address but possibly may not be in all cases.
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
>
More information about the tac_plus
mailing list