[tac_plus] Re: enable = file /etc/passwd

[Dan Schmidt]

Thanks - this appears to have worked great, I hope it makes it into the
next release.  Thanks also to Bitman for the help with the passwords.

-----Original Message-----
From: Antonin Vitecek [mailto:antoninvitecek at seznam.cz] 
Sent: Tuesday, September 11, 2007 3:00 AM
To: Dan Schmidt
Cc: tac_plus at shrubbery.net
Subject: Re: [tac_plus] enable = file /etc/passwd

Dan Schmidt wrote:
> I am having the same problem as this user:
>
> http://www.shrubbery.net/pipermail/tac_plus/2007-February/000078.html
>
>  
>
> Is this a bug?  Terribly sorry if this has been talked about before -
I
> could not seem to google it. 
>
>  
>
> Thanks, 
>
> -Dan 
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
http://www.shrubbery.net/pipermail/tac_plus/attachments/20070905/fd30a19
b/attachment.html 
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
>
>   
Hi,

Jeff Gehlbach sent me a patch solving this problem, but format of his
patch didn't work to me, so I created new. There is mail from Jeff:

========================================================================
=========================

Hi!

I just ran across this same issue.  Sorry if my reply doesn't get
properly threaded, I'm pasting your message from the mailman archive as
I was not subscribed to the list at the time you sent it.

On Wed Feb 14 14:40:16 UTC 2007, Antonin Vitecek
<AntoninVitecek at seznam.cz> wrote:


> > I have a little question. Is it possible authenticate enable
password
> > using passwd(5) file? Because I found it on Shrubbery
> > page(http://www.shrubbery.net/tac_plus/) at the bottom:
> > 
> >  user = bar {
> >         enable = file /etc/tac_enable_pwd
> > }
> > 
> > But, if I try it, I get this message: 
> > 
> > 192.168.0.1: Error cannot identify password type file /etc/passwd
for
> > john
> > 
> > For login it is ok. In pwlib.c I found: 
> > 
> >     /* Oops. No idea what kind of password this is. This should
never
> >      * happen as the parser should never create such passwords. */
> > 
> > What I want is to have same login and enable password.
>   

I believe this may be a bug in the Shrubbery code.  I applied the
attached patch to the source as obtained by extracting
tacacs+-F4.0.4.14.tar.gz from ftp.shrubbery.net.  I can now use 'enable
= file /path/foo' with no issues.  I don't have a sufficiently deep
understanding of the TACACS+ protocol to know whether this will work in
every situation, but it got me running.  If anybody sees a problem with
this patch, please let me know.

The patch also adds single quotes around the parameterized strings in
the "Error cannot identify password type" messages, so that they read
e.g.:

Error cannot identify password type 'file' for 'john'

-jeff

*** pwlib.c.orig        2007-03-08 09:58:36.000000000 -0500
--- pwlib.c     2007-03-08 09:04:07.000000000 -0500
***************
*** 207,213 ****
      /* 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",
           session.peer,
           cfg_passwd && cfg_passwd[0] ? cfg_passwd : "<NULL>",
           name ? name : "<unknown>");
--- 207,213 ----
      /* 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'",
           session.peer,
           cfg_passwd && cfg_passwd[0] ? cfg_passwd : "<NULL>",
           name ? name : "<unknown>");
***************
*** 261,270 ****
        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",
           session.peer,
           cfg_passwd && cfg_passwd[0] ? cfg_passwd : "<NULL>",
           name ? name : "<unknown>");
--- 261,281 ----
        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'",
           session.peer,
           cfg_passwd && cfg_passwd[0] ? cfg_passwd : "<NULL>",
           name ? name : "<unknown>");


========================================================================
=========================