[tac_plus] Re: Unified passwords?
Schmidt, Daniel
dan.schmidt at uplinkdata.com
Thu Feb 26 20:54:57 UTC 2009
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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tac_enab_new.patch
Type: application/octet-stream
Size: 1487 bytes
Desc: tac_enab_new.patch
Url : http://www.shrubbery.net/pipermail/tac_plus/attachments/20090226/344b2406/attachment.obj
More information about the tac_plus
mailing list