From heas at shrubbery.net  Mon Mar  2 17:33:11 2009
From: heas at shrubbery.net (john heasley)
Date: Mon, 2 Mar 2009 17:33:11 +0000
Subject: [tac_plus] Re: Unified passwords?
In-Reply-To: <05CC562AFB5A9446A1BC3F66AD04A3BC3A2E4A@che-exch-003.uplinkdata.com>
References: <49A58406.7040807@lafayette.edu>
	<20090225214132.GO13893@shrubbery.net>
	<49A6ECA4.8070607@lafayette.edu>
	<05CC562AFB5A9446A1BC3F66AD04A3BC3A2E4A@che-exch-003.uplinkdata.com>
Message-ID: <20090302173311.GE26693@shrubbery.net>

Thu, Feb 26, 2009 at 01:54:57PM -0700, Schmidt, Daniel:
> I believe you require the enable patch.  I'm not exactly sure why this
> was not integrated into the last release.  My C skills are not nearly as
> good as John's as to allow me to say that it should go in.  However, I
> use it and it works fine.  Look at the code, it's a very small change.  

I can't just commit something without investigating what side effects it
might have, updating comments, and updating manual pages.  These things
take time that I dont always have.

anyway, this seems to be fine and I've committed it, except for the log
msg changes which I do not understand.

> diff -ruN tacacs+-F4.0.4.15/pwlib.c tacacs+-F4.0.4.15.new/pwlib.c
> --- tacacs+-F4.0.4.15/pwlib.c	2007-12-13 20:18:39.000000000 +0100
> +++ tacacs+-F4.0.4.15.new/pwlib.c	2008-04-22 11:05:11.000000000
> +0200
> @@ -206,7 +206,7 @@
>      /* Oops. No idea what kind of password this is. This should never
>       * happen as the parser should never create such passwords.
>       */
> -    report(LOG_ERR, "%s: Error cannot identify password type %s for
> %s",
> +    report(LOG_ERR, "%s: Error cannot identify password type '%s' for
> '%s'",
>  	   session.peer,
>  	   cfg_passwd && cfg_passwd[0] ? cfg_passwd : "<NULL>",
>  	   name ? name : "<unknown>");
> @@ -260,10 +260,22 @@
>  	return(data->status == TAC_PLUS_AUTHEN_STATUS_PASS);
>      }
>  
> +    p = tac_find_substring("file ", cfg_passwd);
> +    if (p) {
> +        if (!passwd_file_verify(name, passwd, data, p)) {
> +            data->status = TAC_PLUS_AUTHEN_STATUS_FAIL;
> +            return(0);
> +        } else {
> +            data->status = TAC_PLUS_AUTHEN_STATUS_PASS;
> +        }
> +      
> +        return(data->status == TAC_PLUS_AUTHEN_STATUS_PASS);
> +    }
> +
>      /* Oops. No idea what kind of password this is. This should never
>       * happen as the parser should never create such passwords. */
>  
> -    report(LOG_ERR, "%s: Error cannot identify password type %s for
> %s",
> +    report(LOG_ERR, "%s: Error cannot identify password type '%s' for
> '%s'",
>  	   session.peer,
>  	   cfg_passwd && cfg_passwd[0] ? cfg_passwd : "<NULL>",
>  	   name ? name : "<unknown>");
> 
> -----Original Message-----
> From: tac_plus-bounces at shrubbery.net
> [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Jason Frisvold
> Sent: Thursday, February 26, 2009 12:25 PM
> To: john heasley
> Cc: tac_plus at shrubbery.net
> Subject: [tac_plus] Re: Unified passwords?
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> john heasley wrote:
> >                   user = bart {
> >                       enable = <password_spec>
> >                   }
> > 
> >               enable specifies the enable password.  The
> <password_spec>  may
> >               only  be  of  type cleartext or des.  If the daemon was
> compiled
> >               with per-user enable support (--enable-uenable), the
> host enable
> >               password will be evaluated iff the user does not have a
> personal
> >               enable password.
> 
> I was looking to use /etc/password for both login and enable passwords.
>  If I understand your reply, you're saying that's not possible, correct?
> 
> - --
> - ---------------------------
> Jason Frisvold
> Network Engineer
> frisvolj at lafayette.edu
> - ---------------------------
> "What I cannot create, I do not understand"
>    - Richard Feynman
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org
> 
> iD8DBQFJpuykO80o6DJ8UvkRAjYJAJ0SDzbt80Y5rGuIVAFNJXSjlIsY6gCfZv7r
> zUWW6YDfvhIYdvE164K3O8g=
> =NAId
> -----END PGP SIGNATURE-----
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus



From dan.schmidt at uplinkdata.com  Mon Mar  2 18:28:36 2009
From: dan.schmidt at uplinkdata.com (Schmidt, Daniel)
Date: Mon, 2 Mar 2009 11:28:36 -0700
Subject: [tac_plus] Re: Unified passwords?
In-Reply-To: <20090302173311.GE26693@shrubbery.net>
References: <49A58406.7040807@lafayette.edu>
	<20090225214132.GO13893@shrubbery.net>
	<49A6ECA4.8070607@lafayette.edu>
	<05CC562AFB5A9446A1BC3F66AD04A3BC3A2E4A@che-exch-003.uplinkdata.com>
	<20090302173311.GE26693@shrubbery.net>
Message-ID: <05CC562AFB5A9446A1BC3F66AD04A3BC3A2E7E@che-exch-003.uplinkdata.com>

They are for just for clarity in the logs.   

Example:
Error cannot identify password type file for dans
vs
Error cannot identify password type 'file' for 'dans'

Not necessary, but not bad either.  I believe the author of the patch
may have been Jeff Gehlbach


-----Original Message-----
From: john heasley [mailto:heas at shrubbery.net] 
Sent: Monday, March 02, 2009 10:33 AM
To: Schmidt, Daniel
Cc: Jason Frisvold; john heasley; tac_plus at shrubbery.net
Subject: Re: [tac_plus] Re: Unified passwords?

Thu, Feb 26, 2009 at 01:54:57PM -0700, Schmidt, Daniel:
> I believe you require the enable patch.  I'm not exactly sure why this
> was not integrated into the last release.  My C skills are not nearly
as
> good as John's as to allow me to say that it should go in.  However, I
> use it and it works fine.  Look at the code, it's a very small change.


I can't just commit something without investigating what side effects it
might have, updating comments, and updating manual pages.  These things
take time that I dont always have.

anyway, this seems to be fine and I've committed it, except for the log
msg changes which I do not understand.

> diff -ruN tacacs+-F4.0.4.15/pwlib.c tacacs+-F4.0.4.15.new/pwlib.c
> --- tacacs+-F4.0.4.15/pwlib.c	2007-12-13 20:18:39.000000000 +0100
> +++ tacacs+-F4.0.4.15.new/pwlib.c	2008-04-22 11:05:11.000000000
> +0200
> @@ -206,7 +206,7 @@
>      /* Oops. No idea what kind of password this is. This should never
>       * happen as the parser should never create such passwords.
>       */
> -    report(LOG_ERR, "%s: Error cannot identify password type %s for
> %s",
> +    report(LOG_ERR, "%s: Error cannot identify password type '%s' for
> '%s'",
>  	   session.peer,
>  	   cfg_passwd && cfg_passwd[0] ? cfg_passwd : "<NULL>",
>  	   name ? name : "<unknown>");
> @@ -260,10 +260,22 @@
>  	return(data->status == TAC_PLUS_AUTHEN_STATUS_PASS);
>      }
>  
> +    p = tac_find_substring("file ", cfg_passwd);
> +    if (p) {
> +        if (!passwd_file_verify(name, passwd, data, p)) {
> +            data->status = TAC_PLUS_AUTHEN_STATUS_FAIL;
> +            return(0);
> +        } else {
> +            data->status = TAC_PLUS_AUTHEN_STATUS_PASS;
> +        }
> +      
> +        return(data->status == TAC_PLUS_AUTHEN_STATUS_PASS);
> +    }
> +
>      /* Oops. No idea what kind of password this is. This should never
>       * happen as the parser should never create such passwords. */
>  
> -    report(LOG_ERR, "%s: Error cannot identify password type %s for
> %s",
> +    report(LOG_ERR, "%s: Error cannot identify password type '%s' for
> '%s'",
>  	   session.peer,
>  	   cfg_passwd && cfg_passwd[0] ? cfg_passwd : "<NULL>",
>  	   name ? name : "<unknown>");
> 
> -----Original Message-----
> From: tac_plus-bounces at shrubbery.net
> [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Jason Frisvold
> Sent: Thursday, February 26, 2009 12:25 PM
> To: john heasley
> Cc: tac_plus at shrubbery.net
> Subject: [tac_plus] Re: Unified passwords?
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> john heasley wrote:
> >                   user = bart {
> >                       enable = <password_spec>
> >                   }
> > 
> >               enable specifies the enable password.  The
> <password_spec>  may
> >               only  be  of  type cleartext or des.  If the daemon
was
> compiled
> >               with per-user enable support (--enable-uenable), the
> host enable
> >               password will be evaluated iff the user does not have
a
> personal
> >               enable password.
> 
> I was looking to use /etc/password for both login and enable
passwords.
>  If I understand your reply, you're saying that's not possible,
correct?
> 
> - --
> - ---------------------------
> Jason Frisvold
> Network Engineer
> frisvolj at lafayette.edu
> - ---------------------------
> "What I cannot create, I do not understand"
>    - Richard Feynman
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org
> 
> iD8DBQFJpuykO80o6DJ8UvkRAjYJAJ0SDzbt80Y5rGuIVAFNJXSjlIsY6gCfZv7r
> zUWW6YDfvhIYdvE164K3O8g=
> =NAId
> -----END PGP SIGNATURE-----
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus



From heas at shrubbery.net  Mon Mar  2 20:07:14 2009
From: heas at shrubbery.net (john heasley)
Date: Mon, 2 Mar 2009 20:07:14 +0000
Subject: [tac_plus] Re: Unified passwords?
In-Reply-To: <05CC562AFB5A9446A1BC3F66AD04A3BC3A2E7E@che-exch-003.uplinkdata.com>
References: <49A58406.7040807@lafayette.edu>
	<20090225214132.GO13893@shrubbery.net>
	<49A6ECA4.8070607@lafayette.edu>
	<05CC562AFB5A9446A1BC3F66AD04A3BC3A2E4A@che-exch-003.uplinkdata.com>
	<20090302173311.GE26693@shrubbery.net>
	<05CC562AFB5A9446A1BC3F66AD04A3BC3A2E7E@che-exch-003.uplinkdata.com>
Message-ID: <20090302200714.GN26693@shrubbery.net>

Mon, Mar 02, 2009 at 11:28:36AM -0700, Schmidt, Daniel:
> They are for just for clarity in the logs.   
> 
> Example:
> Error cannot identify password type file for dans
> vs
> Error cannot identify password type 'file' for 'dans'
> 
> Not necessary, but not bad either.  I believe the author of the patch
> may have been Jeff Gehlbach

I'll skip that, as I feel compelled that if I apply it there, it must be
applied to all instances for consistency.

From frisvolj at lafayette.edu  Thu Mar  5 14:07:03 2009
From: frisvolj at lafayette.edu (Jason Frisvold)
Date: Thu, 05 Mar 2009 09:07:03 -0500
Subject: [tac_plus]  Very Odd Behavior
Message-ID: <49AFDC87.9090001@lafayette.edu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

	This is ....  odd, at best.  And I'm not sure that tac_plus is the
cause, but it's the only variable that has changed in the last day, so
I'm taking a stab in the dark here...

	We use rancid for configuration backups.  Rancid has worked wonderfully
for a few years now and we're quite happy with it.  Yesterday, we
ditched our ACS server and moved over to the open-source tac_plus server
(4.0.4.15).

	Since the move, we have noticed that a number of our Cisco switches
have spontaneously added "privilege level 15" to their configuration
under "line vty 0 4" ...  We removed the offending line as it prevented
rancid from running correctly, and re-ran rancid.  Again, the line was
re-added.

	A sampling of these switches seems to indicate that all the affected
switches are model 3750G, though I did run across one 3750G that was not
affected.

	Has anyone seen anything like this?  Any suggestions on how to track
down the cause?

Thanks,

- --
- ---------------------------
Jason Frisvold
Network Engineer
frisvolj at lafayette.edu
- ---------------------------
"What I cannot create, I do not understand"
   - Richard Feynman
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org

iD8DBQFJr9yHO80o6DJ8UvkRAk16AJ9/Oc+YXCvSf5iTbhsfjJNCPR3Q7QCfQMBf
upDmI7CqEHFcfEnbu0sWfv4=
=5Yqt
-----END PGP SIGNATURE-----

From heas at shrubbery.net  Thu Mar  5 18:43:16 2009
From: heas at shrubbery.net (john heasley)
Date: Thu, 5 Mar 2009 18:43:16 +0000
Subject: [tac_plus] Re: Very Odd Behavior
In-Reply-To: <49AFDC87.9090001@lafayette.edu>
References: <49AFDC87.9090001@lafayette.edu>
Message-ID: <20090305184316.GF22082@shrubbery.net>

Thu, Mar 05, 2009 at 09:07:03AM -0500, Jason Frisvold:
> All,
> 
> 	This is ....  odd, at best.  And I'm not sure that tac_plus is the
> cause, but it's the only variable that has changed in the last day, so
> I'm taking a stab in the dark here...
> 
> 	We use rancid for configuration backups.  Rancid has worked wonderfully
> for a few years now and we're quite happy with it.  Yesterday, we
> ditched our ACS server and moved over to the open-source tac_plus server
> (4.0.4.15).
> 
> 	Since the move, we have noticed that a number of our Cisco switches
> have spontaneously added "privilege level 15" to their configuration
> under "line vty 0 4" ...  We removed the offending line as it prevented
> rancid from running correctly, and re-ran rancid.  Again, the line was
> re-added.
> 
> 	A sampling of these switches seems to indicate that all the affected
> switches are model 3750G, though I did run across one 3750G that was not
> affected.
> 
> 	Has anyone seen anything like this?  Any suggestions on how to track
> down the cause?

I haven't, but its not uncommon for ciscos to add things to their configs
spontaneously (STP-related stuff is very common) that will appear in the
output.  my guess is that you have priv-lvl in your tacacs config and its
causing this silly config change.  could also be a bug or caused by the
aaa config on the switches.

anyway, this should not cause rancid to fail.  you probably just need to
adjust autoenable in your cloginrc, see cloginrc(5).

From eric at atlantech.net  Mon Mar  9 14:05:50 2009
From: eric at atlantech.net (Eric Van Tol)
Date: Mon, 9 Mar 2009 10:05:50 -0400
Subject: [tac_plus]  Authenticating on MRV Switch
Message-ID: <2C05E949E19A9146AF7BDF9D44085B86351EE71A2C@exchange.aoihq.local>

Hi,
I am attempting to set up MRV Optiswitch devices to use TACACS+ for authentication and I'm having a problem getting the user to drop right into enable mode upon a successful login.  The MRV documentation states:

       "To allow a user attempting to enter enable mode of the 
       OS900 immediately after successfully logging onto the 
       OS900 using the admin password, set the 'Service Type' 
       parameter on the AAA Server to the value 'administrative 
       user."

This looks more like instructions for RADIUS than for TACACS+, but I figured I'd email the list and see if someone can point me in the right direction.

thanks,
evt 

From heas at shrubbery.net  Mon Mar  9 16:38:40 2009
From: heas at shrubbery.net (john heasley)
Date: Mon, 9 Mar 2009 16:38:40 +0000
Subject: [tac_plus] Re: Authenticating on MRV Switch
In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B86351EE71A2C@exchange.aoihq.local>
References: <2C05E949E19A9146AF7BDF9D44085B86351EE71A2C@exchange.aoihq.local>
Message-ID: <20090309163840.GC24793@shrubbery.net>

Mon, Mar 09, 2009 at 10:05:50AM -0400, Eric Van Tol:
> Hi,
> I am attempting to set up MRV Optiswitch devices to use TACACS+ for authentication and I'm having a problem getting the user to drop right into enable mode upon a successful login.  The MRV documentation states:
> 
>        "To allow a user attempting to enter enable mode of the 
>        OS900 immediately after successfully logging onto the 
>        OS900 using the admin password, set the 'Service Type' 
>        parameter on the AAA Server to the value 'administrative 
>        user."
> 
> This looks more like instructions for RADIUS than for TACACS+, but I figured I'd email the list and see if someone can point me in the right direction.

you're probably right, but there may be an equivalent AV pair that tacacs
can use.  you'd have to ask the manufacturer or you may be able to gleen
it from the O/S image with strings(1).

From john at sackheads.org  Mon Mar 16 13:53:02 2009
From: john at sackheads.org (John Payne)
Date: Mon, 16 Mar 2009 09:53:02 -0400
Subject: [tac_plus]  opt_G broken again :(
Message-ID: <A9D10152-6746-47BB-AB30-5F1B99A772C1@sackheads.org>

The opt_G timeline:

First patch: http://www.shrubbery.net/pipermail/tac_plus/2007-October/000158.html
Second patch to fix defunct processes: http://www.shrubbery.net/pipermail/tac_plus/2007-October/000163.html
Third patch to make it work: http://www.shrubbery.net/pipermail/tac_plus/2008-June/000246.html

Unfortunately, the third patch has started causing defunct processes  
again.

Now I'm really confused :)

From john at sackheads.org  Mon Mar 16 18:06:40 2009
From: john at sackheads.org (John Payne)
Date: Mon, 16 Mar 2009 14:06:40 -0400
Subject: [tac_plus] Re: opt_G broken again :(
In-Reply-To: <A9D10152-6746-47BB-AB30-5F1B99A772C1@sackheads.org>
References: <A9D10152-6746-47BB-AB30-5F1B99A772C1@sackheads.org>
Message-ID: <6FB5CBD0-CBC3-4E5C-8871-B14E820753EA@sackheads.org>


On Mar 16, 2009, at 9:53 AM, John Payne wrote:

> The opt_G timeline:
>
> First patch: http://www.shrubbery.net/pipermail/tac_plus/2007-October/000158.html
> Second patch to fix defunct processes: http://www.shrubbery.net/pipermail/tac_plus/2007-October/000163.html
> Third patch to make it work: http://www.shrubbery.net/pipermail/tac_plus/2008-June/000246.html
>
> Unfortunately, the third patch has started causing defunct processes
> again.

This seems to resolve the defunct process issue:

*** tac_plus.c.orig	2009-03-16 14:05:29.000000000 -0400
--- tac_plus.c	2009-03-16 14:05:49.000000000 -0400
***************
*** 447,452 ****
--- 447,457 ----
   	     */
   	    open_logfile();
   	}
+ #ifndef REAPCHILD
+         signal(SIGCHLD, reapchild);
+ #else
+         signal(SIGCHLD, SIG_IGN);
+ #endif /* REAPCHILD */
       }

       ostream = NULL;


Probably a cleaner way, but... it works for me :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20090316/7f2a6494/attachment.html 

From heas at shrubbery.net  Tue Mar 17 07:36:46 2009
From: heas at shrubbery.net (john heasley)
Date: Tue, 17 Mar 2009 07:36:46 +0000
Subject: [tac_plus] Re: opt_G broken again :(
In-Reply-To: <6FB5CBD0-CBC3-4E5C-8871-B14E820753EA@sackheads.org>
References: <A9D10152-6746-47BB-AB30-5F1B99A772C1@sackheads.org>
	<6FB5CBD0-CBC3-4E5C-8871-B14E820753EA@sackheads.org>
Message-ID: <20090317073646.GH2257@shrubbery.net>

Mon, Mar 16, 2009 at 02:06:40PM -0400, John Payne:
> 
> On Mar 16, 2009, at 9:53 AM, John Payne wrote:
> 
> > The opt_G timeline:
> >
> > First patch: http://www.shrubbery.net/pipermail/tac_plus/2007-October/000158.html
> > Second patch to fix defunct processes: http://www.shrubbery.net/pipermail/tac_plus/2007-October/000163.html
> > Third patch to make it work: http://www.shrubbery.net/pipermail/tac_plus/2008-June/000246.html
> >
> > Unfortunately, the third patch has started causing defunct processes
> > again.
> 
> This seems to resolve the defunct process issue:
> 
> *** tac_plus.c.orig	2009-03-16 14:05:29.000000000 -0400
> --- tac_plus.c	2009-03-16 14:05:49.000000000 -0400
> ***************
> *** 447,452 ****
> --- 447,457 ----
>    	     */
>    	    open_logfile();
>    	}
> + #ifndef REAPCHILD
> +         signal(SIGCHLD, reapchild);
> + #else
> +         signal(SIGCHLD, SIG_IGN);
> + #endif /* REAPCHILD */
>        }
> 
>        ostream = NULL;
> 
> 
> Probably a cleaner way, but... it works for me :)

What O/S is this?

From john at sackheads.org  Tue Mar 17 11:27:49 2009
From: john at sackheads.org (John Payne)
Date: Tue, 17 Mar 2009 07:27:49 -0400
Subject: [tac_plus] Re: opt_G broken again :(
In-Reply-To: <20090317073646.GH2257@shrubbery.net>
References: <A9D10152-6746-47BB-AB30-5F1B99A772C1@sackheads.org>
	<6FB5CBD0-CBC3-4E5C-8871-B14E820753EA@sackheads.org>
	<20090317073646.GH2257@shrubbery.net>
Message-ID: <2119BA02-DD42-4133-BD64-087DCF52773B@sackheads.org>



On Mar 17, 2009, at 3:36 AM, john heasley <heas at shrubbery.net> wrote:

> Mon, Mar 16, 2009 at 02:06:40PM -0400, John Payne:
>>
>> On Mar 16, 2009, at 9:53 AM, John Payne wrote:
>>
>>> The opt_G timeline:
>>>
>>> First patch: http://www.shrubbery.net/pipermail/tac_plus/2007-October/000158.html
>>> Second patch to fix defunct processes: http://www.shrubbery.net/pipermail/tac_plus/2007-October/000163.html
>>> Third patch to make it work: http://www.shrubbery.net/pipermail/tac_plus/2008-June/000246.html
>>>
>>> Unfortunately, the third patch has started causing defunct processes
>>> again.
>>
>> This seems to resolve the defunct process issue:
>>
>> *** tac_plus.c.orig    2009-03-16 14:05:29.000000000 -0400
>> --- tac_plus.c    2009-03-16 14:05:49.000000000 -0400
>> ***************
>> *** 447,452 ****
>> --- 447,457 ----
>>            */
>>           open_logfile();
>>       }
>> + #ifndef REAPCHILD
>> +         signal(SIGCHLD, reapchild);
>> + #else
>> +         signal(SIGCHLD, SIG_IGN);
>> + #endif /* REAPCHILD */
>>       }
>>
>>       ostream = NULL;
>>
>>
>> Probably a cleaner way, but... it works for me :)
>
> What O/S is this?
>

Linux 

From nathan at schrenk.org  Tue Mar 17 14:59:05 2009
From: nathan at schrenk.org (Nathan Schrenk)
Date: Tue, 17 Mar 2009 07:59:05 -0700
Subject: [tac_plus] Re: opt_G broken again :(
In-Reply-To: <6FB5CBD0-CBC3-4E5C-8871-B14E820753EA@sackheads.org>
References: <A9D10152-6746-47BB-AB30-5F1B99A772C1@sackheads.org>
	<6FB5CBD0-CBC3-4E5C-8871-B14E820753EA@sackheads.org>
Message-ID: <6121a88b0903170759n2d6b304ajf4c1d9c2da01bb50@mail.gmail.com>

I have something similar in the patch that I apply locally to
tacacs+-F4.0.4.15, which I've attached to this message.  I am also using
Linux and just as you observed, without the adjustment to the SIGCHLD
handling you end up with a defunct process per connection.

Nathan

On 3/16/09, John Payne <john at sackheads.org> wrote:
>
>
> On Mar 16, 2009, at 9:53 AM, John Payne wrote:
>
> > The opt_G timeline:
> >
> > First patch:
> http://www.shrubbery.net/pipermail/tac_plus/2007-October/000158.html
> > Second patch to fix defunct processes:
> http://www.shrubbery.net/pipermail/tac_plus/2007-October/000163.html
> > Third patch to make it work:
> http://www.shrubbery.net/pipermail/tac_plus/2008-June/000246.html
> >
> > Unfortunately, the third patch has started causing defunct processes
> > again.
>
>
> This seems to resolve the defunct process issue:
>
> *** tac_plus.c.orig     2009-03-16 14:05:29.000000000 -0400
> --- tac_plus.c  2009-03-16 14:05:49.000000000 -0400
> ***************
> *** 447,452 ****
> --- 447,457 ----
>              */
>             open_logfile();
>         }
> + #ifndef REAPCHILD
> +         signal(SIGCHLD, reapchild);
> + #else
> +         signal(SIGCHLD, SIG_IGN);
> + #endif /* REAPCHILD */
>        }
>
>        ostream = NULL;
>
>
> Probably a cleaner way, but... it works for me :)
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://www.shrubbery.net/pipermail/tac_plus/attachments/20090316/7f2a6494/attachment.html
>
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20090317/eafd9b39/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tacacs+-F4.0.4.15-foreground.patch
Type: application/octet-stream
Size: 2873 bytes
Desc: not available
Url : http://www.shrubbery.net/pipermail/tac_plus/attachments/20090317/eafd9b39/attachment.obj 

From heas at shrubbery.net  Tue Mar 17 16:45:19 2009
From: heas at shrubbery.net (john heasley)
Date: Tue, 17 Mar 2009 16:45:19 +0000
Subject: [tac_plus] Re: opt_G broken again :(
In-Reply-To: <2119BA02-DD42-4133-BD64-087DCF52773B@sackheads.org>
References: <A9D10152-6746-47BB-AB30-5F1B99A772C1@sackheads.org>
	<6FB5CBD0-CBC3-4E5C-8871-B14E820753EA@sackheads.org>
	<20090317073646.GH2257@shrubbery.net>
	<2119BA02-DD42-4133-BD64-087DCF52773B@sackheads.org>
Message-ID: <20090317164519.GD16566@shrubbery.net>

Tue, Mar 17, 2009 at 07:27:49AM -0400, John Payne:
>
>
> On Mar 17, 2009, at 3:36 AM, john heasley <heas at shrubbery.net> wrote:
>
>> Mon, Mar 16, 2009 at 02:06:40PM -0400, John Payne:
>>>
>>> On Mar 16, 2009, at 9:53 AM, John Payne wrote:
>>>
>>>> The opt_G timeline:
>>>>
>>>> First patch: http://www.shrubbery.net/pipermail/tac_plus/2007-October/000158.html
>>>> Second patch to fix defunct processes: http://www.shrubbery.net/pipermail/tac_plus/2007-October/000163.html
>>>> Third patch to make it work: http://www.shrubbery.net/pipermail/tac_plus/2008-June/000246.html
>>>>
>>>> Unfortunately, the third patch has started causing defunct processes
>>>> again.
>>>
>>> This seems to resolve the defunct process issue:
>>>
>>> *** tac_plus.c.orig    2009-03-16 14:05:29.000000000 -0400
>>> --- tac_plus.c    2009-03-16 14:05:49.000000000 -0400
>>> ***************
>>> *** 447,452 ****
>>> --- 447,457 ----
>>>            */
>>>           open_logfile();
>>>       }
>>> + #ifndef REAPCHILD
>>> +         signal(SIGCHLD, reapchild);
>>> + #else
>>> +         signal(SIGCHLD, SIG_IGN);
>>> + #endif /* REAPCHILD */
>>>       }
>>>
>>>       ostream = NULL;
>>>
>>>
>>> Probably a cleaner way, but... it works for me :)
>>
>> What O/S is this?
>>
>
> Linux 

Grumble.  The default position of SIGCHLD should be SIG_IGN.

From heas at shrubbery.net  Tue Mar 17 22:12:39 2009
From: heas at shrubbery.net (john heasley)
Date: Tue, 17 Mar 2009 22:12:39 +0000
Subject: [tac_plus] Re: opt_G broken again :(
In-Reply-To: <20090317164519.GD16566@shrubbery.net>
References: <A9D10152-6746-47BB-AB30-5F1B99A772C1@sackheads.org>
	<6FB5CBD0-CBC3-4E5C-8871-B14E820753EA@sackheads.org>
	<20090317073646.GH2257@shrubbery.net>
	<2119BA02-DD42-4133-BD64-087DCF52773B@sackheads.org>
	<20090317164519.GD16566@shrubbery.net>
Message-ID: <20090317221239.GA19328@shrubbery.net>

This should fix it; from your patch and autoconf'g REAPCHILD.

ftp://ftp.shrubbery.net/pub/tac_plus/tacacs+-F4.0.4.17.tar.gz

From heas at shrubbery.net  Wed Mar 18 23:33:31 2009
From: heas at shrubbery.net (john heasley)
Date: Wed, 18 Mar 2009 16:33:31 -0700
Subject: [tac_plus] Re: single connection
In-Reply-To: <05CC562AFB5A9446A1BC3F66AD04A3BC1BD6D8@che-exch-003.uplinkdata.com>
References: <05CC562AFB5A9446A1BC3F66AD04A3BC1BD6CE@che-exch-003.uplinkdata.com>
	<20080529210331.GE24141@shrubbery.net>
	<05CC562AFB5A9446A1BC3F66AD04A3BC1BD6D8@che-exch-003.uplinkdata.com>
Message-ID: <20090318233331.GA3200@shrubbery.net>

Thu, May 29, 2008 at 03:32:18PM -0600, Dan Schmidt:
> Thanks for kindly for your reply.
> 
> The symptoms are that, if multiple sessions are opened - one right after
> the other, exactly every other session fails to contact the tacacs
> server (defaults to local authentication) spitting out that debug
> message.  Perhaps it is a bug on the 7600's, as the 6500's in that city
> are completely fine.  (And 3750's, ect.)
> 
> Single-connection was implemented in CiscoSecure Release 1.0.1 - is it
> fully supported in tac_plus?  
> 
> Obviously, the work around is to disable single connection, but that
> creates more connections to the tacacs server. 

I FINALLY researched this extensively.  The problem is that, except for
IOS-XR, single-connection does not work, period.  And, Cisco told me that
they would not fix it.

Note that the tac_plus daemon does not support it anyway; I'd just jammed
basic debugging code into it.  I don't know if I'll add it in the future.

From dan.schmidt at uplinkdata.com  Thu Mar 19 15:03:21 2009
From: dan.schmidt at uplinkdata.com (Schmidt, Daniel)
Date: Thu, 19 Mar 2009 09:03:21 -0600
Subject: [tac_plus] Re: single connection
In-Reply-To: <20090318233331.GA3200@shrubbery.net>
References: <05CC562AFB5A9446A1BC3F66AD04A3BC1BD6CE@che-exch-003.uplinkdata.com>
	<20080529210331.GE24141@shrubbery.net>
	<05CC562AFB5A9446A1BC3F66AD04A3BC1BD6D8@che-exch-003.uplinkdata.com>
	<20090318233331.GA3200@shrubbery.net>
Message-ID: <05CC562AFB5A9446A1BC3F66AD04A3BC70D012@che-exch-003.uplinkdata.com>

Thank you kindly for your reply again. 

I have hundreds of devices that I put it on.  Are we to understand that
Cisco recommends single-connection on one hand, and then on the other
hand tells us that single-connection does not work and they won't fix
it?  I suppose I had better start work on removing it.  

Rather than removing your debug code, perhaps a warning would be in
order?  It would be a shame to have an upgrade break tacacs for those
who have been following their lousy CCNP book.  As I mentioned,
single-connection does work, just not well.  If you check tacacs, you
will note aborts and errors.  

Funny that it seems to work right in IOS-XR yet they did such a terrible
job of implementing SSH in IOS-XR.  

-----Original Message-----
From: john heasley [mailto:heas at shrubbery.net] 
Sent: Wednesday, March 18, 2009 5:34 PM
To: Schmidt, Daniel
Cc: tac_plus at shrubbery.net
Subject: Re: [tac_plus] single connection

Thu, May 29, 2008 at 03:32:18PM -0600, Dan Schmidt:
> Thanks for kindly for your reply.
> 
> The symptoms are that, if multiple sessions are opened - one right
after
> the other, exactly every other session fails to contact the tacacs
> server (defaults to local authentication) spitting out that debug
> message.  Perhaps it is a bug on the 7600's, as the 6500's in that
city
> are completely fine.  (And 3750's, ect.)
> 
> Single-connection was implemented in CiscoSecure Release 1.0.1 - is it
> fully supported in tac_plus?  
> 
> Obviously, the work around is to disable single connection, but that
> creates more connections to the tacacs server. 

I FINALLY researched this extensively.  The problem is that, except for
IOS-XR, single-connection does not work, period.  And, Cisco told me
that
they would not fix it.

Note that the tac_plus daemon does not support it anyway; I'd just
jammed
basic debugging code into it.  I don't know if I'll add it in the
future.

From heas at shrubbery.net  Thu Mar 19 21:17:02 2009
From: heas at shrubbery.net (john heasley)
Date: Thu, 19 Mar 2009 14:17:02 -0700
Subject: [tac_plus] Re: single connection
In-Reply-To: <05CC562AFB5A9446A1BC3F66AD04A3BC70D012@che-exch-003.uplinkdata.com>
References: <05CC562AFB5A9446A1BC3F66AD04A3BC1BD6CE@che-exch-003.uplinkdata.com>
	<20080529210331.GE24141@shrubbery.net>
	<05CC562AFB5A9446A1BC3F66AD04A3BC1BD6D8@che-exch-003.uplinkdata.com>
	<20090318233331.GA3200@shrubbery.net>
	<05CC562AFB5A9446A1BC3F66AD04A3BC70D012@che-exch-003.uplinkdata.com>
Message-ID: <20090319211702.GV22385@shrubbery.net>

Thu, Mar 19, 2009 at 09:03:21AM -0600, Schmidt, Daniel:
> Thank you kindly for your reply again. 
> 
> I have hundreds of devices that I put it on.  Are we to understand that
> Cisco recommends single-connection on one hand, and then on the other
> hand tells us that single-connection does not work and they won't fix
> it?  I suppose I had better start work on removing it.  
> 
> Rather than removing your debug code, perhaps a warning would be in
> order?  It would be a shame to have an upgrade break tacacs for those

i think it *appears* to work.  for starters, the client does not set the
single-connection flag in the header, so either the daemon would refuse
single-connection behavior or not be able to concurrently support both
clients that had the support and those that didnt.  secondly, afaict, it
always closes the connection, which may be why it appears to work.

the daemon does not support it, but I was going to add support.  The code
was simply to figure out how it worked.

> who have been following their lousy CCNP book.  As I mentioned,
> single-connection does work, just not well.  If you check tacacs, you
> will note aborts and errors.  
> 
> Funny that it seems to work right in IOS-XR yet they did such a terrible
> job of implementing SSH in IOS-XR.  
> 
> -----Original Message-----
> From: john heasley [mailto:heas at shrubbery.net] 
> Sent: Wednesday, March 18, 2009 5:34 PM
> To: Schmidt, Daniel
> Cc: tac_plus at shrubbery.net
> Subject: Re: [tac_plus] single connection
> 
> Thu, May 29, 2008 at 03:32:18PM -0600, Dan Schmidt:
> > Thanks for kindly for your reply.
> > 
> > The symptoms are that, if multiple sessions are opened - one right
> after
> > the other, exactly every other session fails to contact the tacacs
> > server (defaults to local authentication) spitting out that debug
> > message.  Perhaps it is a bug on the 7600's, as the 6500's in that
> city
> > are completely fine.  (And 3750's, ect.)
> > 
> > Single-connection was implemented in CiscoSecure Release 1.0.1 - is it
> > fully supported in tac_plus?  
> > 
> > Obviously, the work around is to disable single connection, but that
> > creates more connections to the tacacs server. 
> 
> I FINALLY researched this extensively.  The problem is that, except for
> IOS-XR, single-connection does not work, period.  And, Cisco told me
> that
> they would not fix it.
> 
> Note that the tac_plus daemon does not support it anyway; I'd just
> jammed
> basic debugging code into it.  I don't know if I'll add it in the
> future.

From czane at hawaii.edu  Sat Mar 21 00:21:21 2009
From: czane at hawaii.edu (Chris Zane)
Date: Fri, 20 Mar 2009 14:21:21 -1000
Subject: [tac_plus]  tac_plus & HP Procurve switches
Message-ID: <42EFE792-67B0-4F9E-94C8-2D80B8141E1E@hawaii.edu>

We've been using tac_plus with groups, acl's and different enable  
passwords per group/per for a few years on our cisco gear. Recently we  
have been looking into HP procurve switches mainly due to the lower  
cost points and lifetime warrantly/software upgrades.

While I can get the user login working with groups, acls, etc. with no  
problems, I cannot figure out how to get different enable passwords to  
work based on the group with these switches.

Currently the only way to enable yourself is to create a $enab15$ user  
- but this enable password is now global as far as I can tell.

Anyone gotten this to work?

I'm running the latest tac_plus 4.0.4.18 and the ProCurve is running  
K11.11 (HP 3500yl-24G)

thanks!
chris


From heas at shrubbery.net  Sat Mar 21 04:16:47 2009
From: heas at shrubbery.net (john heasley)
Date: Sat, 21 Mar 2009 04:16:47 +0000
Subject: [tac_plus] Re: tac_plus & HP Procurve switches
In-Reply-To: <42EFE792-67B0-4F9E-94C8-2D80B8141E1E@hawaii.edu>
References: <42EFE792-67B0-4F9E-94C8-2D80B8141E1E@hawaii.edu>
Message-ID: <20090321041647.GB6039@shrubbery.net>

Fri, Mar 20, 2009 at 02:21:21PM -1000, Chris Zane:
> We've been using tac_plus with groups, acl's and different enable  
> passwords per group/per for a few years on our cisco gear. Recently we  
> have been looking into HP procurve switches mainly due to the lower  
> cost points and lifetime warrantly/software upgrades.
> 
> While I can get the user login working with groups, acls, etc. with no  
> problems, I cannot figure out how to get different enable passwords to  
> work based on the group with these switches.
> 
> Currently the only way to enable yourself is to create a $enab15$ user  
> - but this enable password is now global as far as I can tell.
> 
> Anyone gotten this to work?
> 
> I'm running the latest tac_plus 4.0.4.18 and the ProCurve is running  
> K11.11 (HP 3500yl-24G)
> 
> thanks!
> chris
> 
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus

you can do autoenable/priv-lvl.

if it doesnt work the same as for the ciscos, then the user is not being
sent in the enable packet.  call them and open a bug report.

From czane at hawaii.edu  Sat Mar 21 04:40:39 2009
From: czane at hawaii.edu (Chris Zane)
Date: Fri, 20 Mar 2009 18:40:39 -1000
Subject: [tac_plus] Re: tac_plus & HP Procurve switches
In-Reply-To: <20090321041647.GB6039@shrubbery.net>
References: <42EFE792-67B0-4F9E-94C8-2D80B8141E1E@hawaii.edu>
	<20090321041647.GB6039@shrubbery.net>
Message-ID: <D244AEFC-BC68-41A1-9FBD-5DF2DB6DB6EC@hawaii.edu>

Thanks john. Was running more debugging and tac_plus saw the user as  
unknown. Hence the problem. Will look into the autoenable priv level  
and also newer procurve releases.

Chris



On Mar 20, 2009, at 6:16 PM, john heasley <heas at shrubbery.net> wrote:

> Fri, Mar 20, 2009 at 02:21:21PM -1000, Chris Zane:
>> We've been using tac_plus with groups, acl's and different enable
>> passwords per group/per for a few years on our cisco gear. Recently  
>> we
>> have been looking into HP procurve switches mainly due to the lower
>> cost points and lifetime warrantly/software upgrades.
>>
>> While I can get the user login working with groups, acls, etc. with  
>> no
>> problems, I cannot figure out how to get different enable passwords  
>> to
>> work based on the group with these switches.
>>
>> Currently the only way to enable yourself is to create a $enab15$  
>> user
>> - but this enable password is now global as far as I can tell.
>>
>> Anyone gotten this to work?
>>
>> I'm running the latest tac_plus 4.0.4.18 and the ProCurve is running
>> K11.11 (HP 3500yl-24G)
>>
>> thanks!
>> chris
>>
>> _______________________________________________
>> tac_plus mailing list
>> tac_plus at shrubbery.net
>> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
>
> you can do autoenable/priv-lvl.
>
> if it doesnt work the same as for the ciscos, then the user is not  
> being
> sent in the enable packet.  call them and open a bug report.

From john at sackheads.org  Mon Mar 23 20:58:15 2009
From: john at sackheads.org (John Payne)
Date: Mon, 23 Mar 2009 16:58:15 -0400
Subject: [tac_plus] Re: ScreenOS hints
In-Reply-To: <16EBA388-6543-41BC-A1E9-84E692AC1B93@sackheads.org>
References: <71EE407C-A9E6-498D-892D-25683A09015A@sackheads.org>
	<20081014223532.GS5528@corp.aol.com>
	<16EBA388-6543-41BC-A1E9-84E692AC1B93@sackheads.org>
Message-ID: <8EF83C38-311F-47B6-8C8D-1A8C2AE63615@sackheads.org>


On Oct 14, 2008, at 7:22 PM, John Payne wrote:

>
>
> On Oct 14, 2008, at 6:35 PM, Mark Ellzey Thomas <mark.thomas at corp.aol.com
>> wrote:
>
>> On Tue, Oct 14, 2008 at 06:26:30PM -0400, John Payne wrote:
>>> This took a while to find, so sending here to document.  ScreenOS 6+
>>> will authenticate via TACACS+.
>>>
>>> Necessary tac_plus.cfg snippet:
>>>
>>>        service = netscreen {
>>>                vsys = root
>>>                privilege = read-write
>>>                }
>>>
>>>
>>
>> Greetings John,
>>
>> Thank you very much for posting this. Do you know whether
>> authorization
>> is supported with 6.0 (or will be)? I remember seeing that it is
>> only read or
>> read/write.
>
> I'm only looking at 6.1 at this point. Authorization is not yet
> available, but there is read-only, read-write and something else... I
> think admin or superuser (basically read-write but a few extra privs
> like setting up nsrp and local user maintenance).
>
> I will say that tacacs+ support is not complete yet. The biggest issue
> for me right now is that failover isn't working between primary and
> backup servers.  I did get a patch for remote address in about 2 weeks
> though, so engineering is invested.

6.1.0r5 seems to be doing failover now. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20090323/007c118e/attachment.html 

From steve at dss.nhs.uk  Mon Mar 30 16:11:29 2009
From: steve at dss.nhs.uk (Barry Stephen (YDD08) Derwent Shared Services)
Date: Mon, 30 Mar 2009 17:11:29 +0100
Subject: [tac_plus]  Query
Message-ID: <21AF5C86B8DBA2489D136BD3AF5801901EE348@lhmail03.xDerwentSharedServices.nhs.uk>

Hello, sorry if this is explained somewhere, but I have tried to look
through the docs.
 
Is it possible to have a user who would get full access to my access
switches but only read access to my distribution switches somehow, if so
how?
 
Many Thanks for the great product.
Steve
 
Stephen Barry
Senior IT Service Designer  |  IT Operations  |  Derbyshire Health
Informatics Service  |  Derwent Shared Services
t: 01332 622444  |  m: 07919 173353  |  f: 01332 222256  |  e:
steve at dss.nhs.uk <mailto:steve at dss.nhs.uk> 
 


DISCLAIMER - This email and any file transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.  Any views or opinions expressed are those of the author and do not represent the views of Derwent Shared Services, unless otherwise explicitly stated. The information contained in this email may be subject to public disclosure under the Freedom of Information Act 2000. Unless the information is legally exempt from disclosure, the confidentiality of this email cannot be guaranteed.

Derwent Shared Services is an NHS Shared Services Organisation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20090330/9103dcff/attachment.html 

From heas at shrubbery.net  Mon Mar 30 17:39:28 2009
From: heas at shrubbery.net (john heasley)
Date: Mon, 30 Mar 2009 17:39:28 +0000
Subject: [tac_plus] Re: Query
In-Reply-To: <21AF5C86B8DBA2489D136BD3AF5801901EE348@lhmail03.xDerwentSharedServices.nhs.uk>
References: <21AF5C86B8DBA2489D136BD3AF5801901EE348@lhmail03.xDerwentSharedServices.nhs.uk>
Message-ID: <20090330173928.GM3066@shrubbery.net>

Mon, Mar 30, 2009 at 05:11:29PM +0100, Barry Stephen (YDD08) Derwent Shared Services:
> Hello, sorry if this is explained somewhere, but I have tried to look
> through the docs.
>  
> Is it possible to have a user who would get full access to my access
> switches but only read access to my distribution switches somehow, if so
> how?

see authorization scripts

> Many Thanks for the great product.
> Steve
>  
> Stephen Barry
> Senior IT Service Designer  |  IT Operations  |  Derbyshire Health
> Informatics Service  |  Derwent Shared Services
> t: 01332 622444  |  m: 07919 173353  |  f: 01332 222256  |  e:
> steve at dss.nhs.uk <mailto:steve at dss.nhs.uk> 
>  
> 
> 
> DISCLAIMER - This email and any file transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.  Any views or opinions expressed are those of the author and do not represent the views of Derwent Shared Services, unless otherwise explicitly stated. The information contained in this email may be subject to public disclosure under the Freedom of Information Act 2000. Unless the information is legally exempt from disclosure, the confidentiality of this email cannot be guaranteed.
> 
> Derwent Shared Services is an NHS Shared Services Organisation.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20090330/9103dcff/attachment.html 
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus

From dan.schmidt at uplinkdata.com  Mon Mar 30 16:25:13 2009
From: dan.schmidt at uplinkdata.com (Schmidt, Daniel)
Date: Mon, 30 Mar 2009 10:25:13 -0600
Subject: [tac_plus] Re: Query
In-Reply-To: <21AF5C86B8DBA2489D136BD3AF5801901EE348@lhmail03.xDerwentSharedServices.nhs.uk>
References: <21AF5C86B8DBA2489D136BD3AF5801901EE348@lhmail03.xDerwentSharedServices.nhs.uk>
Message-ID: <05CC562AFB5A9446A1BC3F66AD04A3BC70D0DF@che-exch-003.uplinkdata.com>

Not currently, though it would be nice.  I seem to remember Bitman had
been working on something like that.  The only way to do it now is to
have two different users.  Or, have local enable passwords, but have the
password on the dist. switches be different.  

-----Original Message-----
From: tac_plus-bounces at shrubbery.net
[mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Barry Stephen
(YDD08) Derwent Shared Services
Sent: Monday, March 30, 2009 10:11 AM
To: tac_plus at shrubbery.net
Subject: [tac_plus] Query

Hello, sorry if this is explained somewhere, but I have tried to look
through the docs.
 
Is it possible to have a user who would get full access to my access
switches but only read access to my distribution switches somehow, if so
how?
 
Many Thanks for the great product.
Steve
 
Stephen Barry
Senior IT Service Designer  |  IT Operations  |  Derbyshire Health
Informatics Service  |  Derwent Shared Services
t: 01332 622444  |  m: 07919 173353  |  f: 01332 222256  |  e:
steve at dss.nhs.uk <mailto:steve at dss.nhs.uk> 
 


DISCLAIMER - This email and any file transmitted with it are
confidential and intended solely for the use of the individual or entity
to whom they are addressed.  Any views or opinions expressed are those
of the author and do not represent the views of Derwent Shared Services,
unless otherwise explicitly stated. The information contained in this
email may be subject to public disclosure under the Freedom of
Information Act 2000. Unless the information is legally exempt from
disclosure, the confidentiality of this email cannot be guaranteed.

Derwent Shared Services is an NHS Shared Services Organisation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.shrubbery.net/pipermail/tac_plus/attachments/20090330/9103dcf
f/attachment.html 
_______________________________________________
tac_plus mailing list
tac_plus at shrubbery.net
http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus

From tacplus at gheek.net  Mon Mar 30 17:45:37 2009
From: tacplus at gheek.net (Lance Vermilion)
Date: Mon, 30 Mar 2009 10:45:37 -0700
Subject: [tac_plus] Re: Query
In-Reply-To: <20090330173928.GM3066@shrubbery.net>
References: <21AF5C86B8DBA2489D136BD3AF5801901EE348@lhmail03.xDerwentSharedServices.nhs.uk>
	<20090330173928.GM3066@shrubbery.net>
Message-ID: <8423e7bb0903301045q7920cdfalc35e7a3c3894fddb@mail.gmail.com>

John,

Can you point us to the doc that talks about authorization scripts?

On Mon, Mar 30, 2009 at 10:39 AM, john heasley <heas at shrubbery.net> wrote:
> Mon, Mar 30, 2009 at 05:11:29PM +0100, Barry Stephen (YDD08) Derwent Shared Services:
>> Hello, sorry if this is explained somewhere, but I have tried to look
>> through the docs.
>>
>> Is it possible to have a user who would get full access to my access
>> switches but only read access to my distribution switches somehow, if so
>> how?
>
> see authorization scripts
>
>> Many Thanks for the great product.
>> Steve
>>
>> Stephen Barry
>> Senior IT Service Designer ?| ?IT Operations ?| ?Derbyshire Health
>> Informatics Service ?| ?Derwent Shared Services
>> t: 01332 622444 ?| ?m: 07919 173353 ?| ?f: 01332 222256 ?| ?e:
>> steve at dss.nhs.uk <mailto:steve at dss.nhs.uk>
>>
>>
>>
>> DISCLAIMER - This email and any file transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. ?Any views or opinions expressed are those of the author and do not represent the views of Derwent Shared Services, unless otherwise explicitly stated. The information contained in this email may be subject to public disclosure under the Freedom of Information Act 2000. Unless the information is legally exempt from disclosure, the confidentiality of this email cannot be guaranteed.
>>
>> Derwent Shared Services is an NHS Shared Services Organisation.
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20090330/9103dcff/attachment.html
>> _______________________________________________
>> tac_plus mailing list
>> tac_plus at shrubbery.net
>> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
>

From heas at shrubbery.net  Mon Mar 30 20:20:43 2009
From: heas at shrubbery.net (john heasley)
Date: Mon, 30 Mar 2009 20:20:43 +0000
Subject: [tac_plus] Re: Query
In-Reply-To: <8423e7bb0903301045q7920cdfalc35e7a3c3894fddb@mail.gmail.com>
References: <21AF5C86B8DBA2489D136BD3AF5801901EE348@lhmail03.xDerwentSharedServices.nhs.uk>
	<20090330173928.GM3066@shrubbery.net>
	<8423e7bb0903301045q7920cdfalc35e7a3c3894fddb@mail.gmail.com>
Message-ID: <20090330202043.GJ8627@shrubbery.net>

Mon, Mar 30, 2009 at 10:45:37AM -0700, Lance Vermilion:
> John,
> 
> Can you point us to the doc that talks about authorization scripts?

its in the tac_plus.conf manual page.

> On Mon, Mar 30, 2009 at 10:39 AM, john heasley <heas at shrubbery.net> wrote:
> > Mon, Mar 30, 2009 at 05:11:29PM +0100, Barry Stephen (YDD08) Derwent Shared Services:
> >> Hello, sorry if this is explained somewhere, but I have tried to look
> >> through the docs.
> >>
> >> Is it possible to have a user who would get full access to my access
> >> switches but only read access to my distribution switches somehow, if so
> >> how?
> >
> > see authorization scripts
> >
> >> Many Thanks for the great product.
> >> Steve
> >>
> >> Stephen Barry
> >> Senior IT Service Designer ?| ?IT Operations ?| ?Derbyshire Health
> >> Informatics Service ?| ?Derwent Shared Services
> >> t: 01332 622444 ?| ?m: 07919 173353 ?| ?f: 01332 222256 ?| ?e:
> >> steve at dss.nhs.uk <mailto:steve at dss.nhs.uk>
> >>
> >>
> >>
> >> DISCLAIMER - This email and any file transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. ?Any views or opinions expressed are those of the author and do not represent the views of Derwent Shared Services, unless otherwise explicitly stated. The information contained in this email may be subject to public disclosure under the Freedom of Information Act 2000. Unless the information is legally exempt from disclosure, the confidentiality of this email cannot be guaranteed.
> >>
> >> Derwent Shared Services is an NHS Shared Services Organisation.
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20090330/9103dcff/attachment.html
> >> _______________________________________________
> >> tac_plus mailing list
> >> tac_plus at shrubbery.net
> >> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
> > _______________________________________________
> > tac_plus mailing list
> > tac_plus at shrubbery.net
> > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
> >

From dan.schmidt at uplinkdata.com  Tue Mar 31 21:44:01 2009
From: dan.schmidt at uplinkdata.com (Schmidt, Daniel)
Date: Tue, 31 Mar 2009 15:44:01 -0600
Subject: [tac_plus] Re: Query
In-Reply-To: <20090330202043.GJ8627@shrubbery.net>
References: <21AF5C86B8DBA2489D136BD3AF5801901EE348@lhmail03.xDerwentSharedServices.nhs.uk><20090330173928.GM3066@shrubbery.net><8423e7bb0903301045q7920cdfalc35e7a3c3894fddb@mail.gmail.com>
	<20090330202043.GJ8627@shrubbery.net>
Message-ID: <05CC562AFB5A9446A1BC3F66AD04A3BC70D0FF@che-exch-003.uplinkdata.com>

I've never been able to make it work... if anybody has a working example
they could provide, that would be greatly appreciated.  

-----Original Message-----
From: tac_plus-bounces at shrubbery.net
[mailto:tac_plus-bounces at shrubbery.net] On Behalf Of john heasley
Sent: Monday, March 30, 2009 2:21 PM
To: Lance Vermilion
Cc: tac_plus at shrubbery.net
Subject: [tac_plus] Re: Query

Mon, Mar 30, 2009 at 10:45:37AM -0700, Lance Vermilion:
> John,
> 
> Can you point us to the doc that talks about authorization scripts?

its in the tac_plus.conf manual page.

> On Mon, Mar 30, 2009 at 10:39 AM, john heasley <heas at shrubbery.net>
wrote:
> > Mon, Mar 30, 2009 at 05:11:29PM +0100, Barry Stephen (YDD08) Derwent
Shared Services:
> >> Hello, sorry if this is explained somewhere, but I have tried to
look
> >> through the docs.
> >>
> >> Is it possible to have a user who would get full access to my
access
> >> switches but only read access to my distribution switches somehow,
if so
> >> how?
> >
> > see authorization scripts
> >
> >> Many Thanks for the great product.
> >> Steve
> >>
> >> Stephen Barry
> >> Senior IT Service Designer ?| ?IT Operations ?| ?Derbyshire Health
> >> Informatics Service ?| ?Derwent Shared Services
> >> t: 01332 622444 ?| ?m: 07919 173353 ?| ?f: 01332 222256 ?| ?e:
> >> steve at dss.nhs.uk <mailto:steve at dss.nhs.uk>
> >>
> >>
> >>
> >> DISCLAIMER - This email and any file transmitted with it are
confidential and intended solely for the use of the individual or entity
to whom they are addressed. ?Any views or opinions expressed are those
of the author and do not represent the views of Derwent Shared Services,
unless otherwise explicitly stated. The information contained in this
email may be subject to public disclosure under the Freedom of
Information Act 2000. Unless the information is legally exempt from
disclosure, the confidentiality of this email cannot be guaranteed.
> >>
> >> Derwent Shared Services is an NHS Shared Services Organisation.
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL:
http://www.shrubbery.net/pipermail/tac_plus/attachments/20090330/9103dcf
f/attachment.html
> >> _______________________________________________
> >> tac_plus mailing list
> >> tac_plus at shrubbery.net
> >> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
> > _______________________________________________
> > tac_plus mailing list
> > tac_plus at shrubbery.net
> > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
> >
_______________________________________________
tac_plus mailing list
tac_plus at shrubbery.net
http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus