From fred.richards at matrix-ibs.com Mon Mar 10 15:13:13 2008 From: fred.richards at matrix-ibs.com (Richards, Fred) Date: Mon, 10 Mar 2008 11:13:13 -0400 Subject: [tac_plus] tac_plus & AD authentication Message-ID: I don't think your version of tac_plus was compiled with LDAP support, but over the weekend I helped a friend add his Samba server to his AD domain, using Kerberos and modifying nsswitch.conf to take advantage of winbind. Then I thought, wouldn't it be cool to do the same thing, to allow "local" account access via tac_plus? Viola, instant single sign on. I've checked but can't find what options are available for "default authentication" other than "file". Is "local" or "pam" possible? Fred Richards | Sr Network Engineer | Matrix | 803-254-4221 | frichards at matrix-ibs.com I n t e g r a t i n g B u s i n e s s S o l u t i o n s -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20080310/54a383af/attachment.html From joe.moore at holidaycompanies.com Mon Mar 10 21:01:46 2008 From: joe.moore at holidaycompanies.com (Joe Moore) Date: Mon, 10 Mar 2008 16:01:46 -0500 Subject: [tac_plus] tac_plus with PAM on FreeBSD Message-ID: I've been ports of running tac_plus4 in production for a few years on FreeBSD 4.x, 5.x, 6.x and now 7.0. Somewhere during a 6.x "build world" update, authenticating to "file /etc/passwd" stopped working. I didn't have time to troubleshoot so I went with DES passwords which are now too cumbersome to use with our newer, stricter corporate password policies. I had no luck fixing the "files /etc/passwd" authentication so I tried using PAM on a new FBSD 7.0 box. All was well with this tac_plus.conf : # /usr/local/etc/tac_plus.conf key = "zoomzoomzoom" accounting file = "/var/log/tac.log" user = daman { member = admin login = PAM } user = billy { member = grunts login = PAM } group = grunts { default service = permit service = exec { priv-lvl = 0 } } group = admin { default service = permit service = exec { priv-lvl = 15 } } And this /etc/pam.d/tac_plus : # auth auth sufficient pam_tacplus.so # account account sufficient pam_tacplus.so # session session sufficient pam_tacplus.so But when I put it on a production box (that I am always ssh'd into), I got in to routers with just a valid username. I was never even prompted for a password. I have had no luck finding any docs about configuring PAM for this. The "pam_tacplus.so" on my test box links to pam_tac_plus.so4, my production box links it to pam_tac_plus.so3. Here is the output of /usr/local/bin/tac_plus -v on my prod box. tac_plus version F4.0.4.14 ACLS FIONBIO FREEBSD LIBWRAP LITTLE_ENDIAN LOG_DAEMON PAM NO_PWAGE RETSIGTYPE RETSIGTYPE SIGTSTP SIGTTIN SIGTTOU SO_REUSEADDR STRERROR TACPLUS_GROUPID TAC_PLUS_PORT TACPLUS_USERID UENABLE __STDC__ I updated ports and installed this version today. The prod box is "6.2-STABLE #0". Any clues would be much appreciated. ...jgm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20080310/755a0852/attachment.html From heas at shrubbery.net Mon Mar 10 21:21:35 2008 From: heas at shrubbery.net (john heasley) Date: Mon, 10 Mar 2008 21:21:35 +0000 Subject: [tac_plus] Re: tac_plus with PAM on FreeBSD In-Reply-To: References: Message-ID: <20080310212135.GD24346@shrubbery.net> Mon, Mar 10, 2008 at 04:01:46PM -0500, Joe Moore: > I've been ports of running tac_plus4 in production for a few years on > FreeBSD 4.x, 5.x, 6.x and now 7.0. Somewhere during a 6.x "build world" > update, authenticating to "file /etc/passwd" stopped working. I didn't > have time to troubleshoot so I went with DES passwords which are now too > cumbersome to use with our newer, stricter corporate password policies. > > > > I had no luck fixing the "files /etc/passwd" authentication so I tried is your /etc/passwd using md5 pwds? > And this /etc/pam.d/tac_plus : > > # auth > auth sufficient pam_tacplus.so > > # account > account sufficient pam_tacplus.so > > # session > session sufficient pam_tacplus.so I'm not a PAM wizard, but I don't think that you want pam_tacplux.so. That resembles a loop. You want something like password required pam_unix.so no_warn try_first_pass ie: tacplusd->pam->unix_pwd_file. IIRC, when I tested PAM support, I just copied ssh's config. From joe.moore at holidaycompanies.com Wed Mar 12 15:31:17 2008 From: joe.moore at holidaycompanies.com (Joe Moore) Date: Wed, 12 Mar 2008 10:31:17 -0500 Subject: [tac_plus] Re: tac_plus with PAM on FreeBSD In-Reply-To: <20080311220658.GI4499@shrubbery.net> References: <20080310212135.GD24346@shrubbery.net> <20080311220658.GI4499@shrubbery.net> Message-ID: John, The hashes in /etc/master.passwd start with $1$ and then there are 30 characters after that. I did try running tac_plus as root on the FreeBSD box last night with "login = file /etc/passwd" and still no joy. You are right about the pam_tacpus.so PAM module. It is used to authenticate login requests against a tacacs+ server, not for authenticating tacacs users. I believe it was looping to the local tac_plus service. I think the only reason it worked was that the "auth" line in /etc/pam.d/tac_plus was "sufficient" which doesn't actually require the password to be correct as long as one of the remaining lines (account or password) succeeded. Oddly enough though, one of those remaining lines was letting me in but only if the password was correct. I did get pam_unix.so to let me in too as long as auth wasn't "required" in the pam file. One other odd thing I've noticed with tac_plus on FreeBSD when using DES passwords in the config file: Only the first 8 characters of the password matter. If your password is longer than 8 characters, and you type the first 8 correctly, you can just hit or type add a few random characters before hitting and you get in just fine. I installed Centos5 on a clean box last night and installed tac_plus4. It worked fine against /etc/passwd. With "login = PAM" in the config file tac_plus refused to load because PAM was an unrecognized "token". If I can get my password synching utility to run on Centos I'll be OK authenticating to /etc/passwd for now, but ideally I'd like to use an OS where tac_plus doesn't run as root (like it does on Centos) and supports PAM. Centos definitely supports PAM. I don't know if the tac_plus configure didn't detect PAM or if I'm supposed to do something to force the build to include it. If you have any recommendations for a Linux/*nix distribution that'll do this out of the box, please let me know. I'll be building a box just for this in the next few days. I hope to run two instances of tac_plus on the box, (each instance with it own config) either on different ports or bound to different IP addresses. TIA ...jgm -----Original Message----- From: john heasley [mailto:heas at shrubbery.net] Sent: Tuesday, March 11, 2008 5:07 PM To: Joe Moore Subject: Re: [tac_plus] tac_plus with PAM on FreeBSD Mon, Mar 10, 2008 at 04:36:20PM -0500, Joe Moore: > John, > > Thanks for the response! > > My /etc/passwd file doesn't actually have any passwords in it. That's > been standard on FreeBSD for a very long time. The actual (salted and > hashed) passwords are in "/etc/master.passwd" which is readable ONLY by > root, so I suppose it's possible that it broke when tac_plus started > running as the "tacacs" user instead of root. right, but getpwent() should return the right bits from master.password, and that should be used if the file is set to /etc/passwd. > I don't know if the hashes are MD5 or not. They're whatever FBSD md5 begins with $1$ in the hash. > normally does. I did see in a debug last night what tac_plus thought the > password should encrypt to, and it wasn't anything like the hash in > /etc/master.passwd. > > I'll try copying the PAM file from ssh and see if that works. Is your > PAM file just that single line? My /etc/pam.d/sshd is more than that: the point was that the module is like pam_unix.so, not pam_tacplus.so. mine/NetBSDs is: # $NetBSD: sshd,v 1.8 2005/09/22 01:02:12 tsarna Exp $ # # PAM configuration for the "sshd" service # # auth auth required pam_nologin.so no_warn #auth sufficient pam_krb5.so no_warn try_first_pass #auth optional pam_afslog.so no_warn try_first_pass # pam_ssh has potential security risks. See pam_ssh(8). #auth sufficient pam_ssh.so no_warn try_first_pass auth required pam_unix.so no_warn try_first_pass # account #account required pam_krb5.so account required pam_login_access.so account required pam_unix.so # session # pam_ssh has potential security risks. See pam_ssh(8). #session optional pam_ssh.so session required pam_permit.so # password #password sufficient pam_krb5.so no_warn try_first_pass password required pam_unix.so no_warn try_first_pass again, i THINK that is what I tested with. From kissg at ssg.ki.iif.hu Wed Mar 12 15:51:47 2008 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Wed, 12 Mar 2008 16:51:47 +0100 (CET) Subject: [tac_plus] Re: tac_plus with PAM on FreeBSD In-Reply-To: References: <20080310212135.GD24346@shrubbery.net> <20080311220658.GI4499@shrubbery.net> Message-ID: > The hashes in /etc/master.passwd start with $1$ and then there are 30 > characters after that. > > I did try running tac_plus as root on the FreeBSD box last night with > "login = file /etc/passwd" and still no joy. You need a libcrypt.so with GNU extensions where crypt(3) supports md5 password hashes. Gabor From heas at shrubbery.net Wed Mar 12 16:48:47 2008 From: heas at shrubbery.net (john heasley) Date: Wed, 12 Mar 2008 09:48:47 -0700 Subject: [tac_plus] Re: tac_plus with PAM on FreeBSD In-Reply-To: References: <20080310212135.GD24346@shrubbery.net> <20080311220658.GI4499@shrubbery.net> Message-ID: <20080312164847.GG18313@shrubbery.net> Wed, Mar 12, 2008 at 04:51:47PM +0100, Kiss Gabor (Bitman): > > The hashes in /etc/master.passwd start with $1$ and then there are 30 > > characters after that. > > > > I did try running tac_plus as root on the FreeBSD box last night with > > "login = file /etc/passwd" and still no joy. > > You need a libcrypt.so with GNU extensions where crypt(3) > supports md5 password hashes. For the record, there is nothing GNU about this. GNU stuff might support it now, but it originated with BSD and AFAIK FBSD, NBSD and OBSD all support DES and MD5 hashes and FBSD and NBSD also support blowfish, IIRC. From kissg at ssg.ki.iif.hu Wed Mar 12 17:17:44 2008 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Wed, 12 Mar 2008 18:17:44 +0100 (CET) Subject: [tac_plus] Re: tac_plus with PAM on FreeBSD In-Reply-To: <20080312164847.GG18313@shrubbery.net> References: <20080310212135.GD24346@shrubbery.net> <20080311220658.GI4499@shrubbery.net> <20080312164847.GG18313@shrubbery.net> Message-ID: > > You need a libcrypt.so with GNU extensions where crypt(3) > > supports md5 password hashes. > > For the record, there is nothing GNU about this. GNU stuff might support > it now, but it originated with BSD and AFAIK FBSD, NBSD and OBSD all support > DES and MD5 hashes and FBSD and NBSD also support blowfish, IIRC. You must be right. I just read this on crypt(3) man page a few days ago: GNU EXTENSION The glibc2 version of this function has the following additional fea- tures. If salt is a character string starting with the three charac- ters "$1$" followed by at most eight characters, and optionally termi- nated by "$", then instead of using the DES machine, the glibc crypt function uses an MD5-based algorithm, ... but I did not make any effort to research the origin of md5 password handling. :-) Gabor From joe.moore at holidaycompanies.com Wed Mar 12 17:56:48 2008 From: joe.moore at holidaycompanies.com (Joe Moore) Date: Wed, 12 Mar 2008 12:56:48 -0500 Subject: [tac_plus] Re: tac_plus with PAM on FreeBSD In-Reply-To: References: <20080310212135.GD24346@shrubbery.net><20080311220658.GI4499@shrubbery.net><20080312164847.GG18313@shrubbery.net> Message-ID: I'm not a developer, but when I run tac_plus with /etc/passwd auth, debug output shows my (correct) password in plain text. Debug also shows what the plain-text password "encrypts to", which does not resemble the hash in /etc/master.passwd. The hashed pw in master.passwd is MD5 and has an 8 character salt prepended to the hash. I'm guessing (and that's all it is) that maybe tac_plus is using a different method to encrypt the plain-text password than FBSD is using, or maybe it's just not aware of the salt. I know this used to work on FBSD 4.x and 5.x. No dice with 6 or 7 though... ...jgm -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Kiss Gabor (Bitman) Sent: Wednesday, March 12, 2008 12:18 PM To: john heasley Cc: tac_plus at shrubbery.net Subject: [tac_plus] Re: tac_plus with PAM on FreeBSD > > You need a libcrypt.so with GNU extensions where crypt(3) > > supports md5 password hashes. > > For the record, there is nothing GNU about this. GNU stuff might support > it now, but it originated with BSD and AFAIK FBSD, NBSD and OBSD all support > DES and MD5 hashes and FBSD and NBSD also support blowfish, IIRC. You must be right. I just read this on crypt(3) man page a few days ago: GNU EXTENSION The glibc2 version of this function has the following additional fea- tures. If salt is a character string starting with the three charac- ters "$1$" followed by at most eight characters, and optionally termi- nated by "$", then instead of using the DES machine, the glibc crypt function uses an MD5-based algorithm, ... but I did not make any effort to research the origin of md5 password handling. :-) Gabor _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From kissg at ssg.ki.iif.hu Wed Mar 12 18:18:01 2008 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Wed, 12 Mar 2008 19:18:01 +0100 (CET) Subject: [tac_plus] Re: tac_plus with PAM on FreeBSD In-Reply-To: References: <20080310212135.GD24346@shrubbery.net><20080311220658.GI4499@shrubbery.net><20080312164847.GG18313@shrubbery.net> Message-ID: > I'm not a developer, but when I run tac_plus with /etc/passwd auth, > debug output shows my (correct) password in plain text. Debug also shows > what the plain-text password "encrypts to", which does not resemble the > hash in /etc/master.passwd. > > The hashed pw in master.passwd is MD5 and has an 8 character salt > prepended to the hash. I'm guessing (and that's all it is) that maybe > tac_plus is using a different method to encrypt the plain-text password > than FBSD is using, or maybe it's just not aware of the salt. I know pwlib.c contains this: des_verify(...) { ... ep = (char *) crypt(users_passwd, encrypted_passwd); ... if (strcmp(ep, encrypted_passwd) == 0) { if (debug & DEBUG_PASSWD_FLAG) report(LOG_DEBUG, "Password is correct"); return(1); } } It just passes old stored hash as 'encrypted_passwd' to crypt(). It works because hash begins with the salt. I suggest you to compile a 5 line test program like this: #include #include main(int argc, char **argv) { printf("%s\n",crypt(argv[1], argv[2])); } Assuming source file is called p.c $ make CFLAGS='-lcrypt' p Then run it with plain password and old hash as arguments. Assuming your password is 'plaintext' $ ./p plaintext '$1$2K1JYNC3$qik58Zlm5tccXeZJ4v0Xm.' $1$2K1JYNC3$qik58Zlm5tccXeZJ4v0Xm. It works for me on Debian Etch Linux, i386 architecture. What can you see on stdout on different platforms? Gabor From carl at nerd.com Wed Mar 12 16:41:13 2008 From: carl at nerd.com (carl) Date: Wed, 12 Mar 2008 09:41:13 -0700 Subject: [tac_plus] PAM enable authorization Message-ID: <003d01c8845f$e3c90220$ab5b0660$@com> >From the documentation I see that enable authorization is not implemented for PAM, but I was wondering if anyone has ever tried to get PAM to support enable authorization, if so have any tips? No virus found in this outgoing message. Checked by AVG. Version: 7.5.518 / Virus Database: 269.21.7/1325 - Release Date: 3/11/2008 1:41 PM From joe.moore at holidaycompanies.com Thu Mar 13 04:09:22 2008 From: joe.moore at holidaycompanies.com (Joe Moore) Date: Wed, 12 Mar 2008 23:09:22 -0500 Subject: [tac_plus] Re: tac_plus with PAM on FreeBSD In-Reply-To: References: <20080310212135.GD24346@shrubbery.net><20080311220658.GI4499@shrubbery.net><20080312164847.GG18313@shrubbery.net> Message-ID: OK, I tried compiling on FBSD 6.2 and it couldn't find "crypt.h". I found a few copies scattered around the system so I copied on from /usr/src/lib/libcrypt/. The compile then failed due to a syntax error in crypt.h. p.c compiled fine on Centos5 Linux. It worked correctly there too. I had the same problems on the FBSD 7 box that I had on the 6.2 box initially. Then, I noticed that the crypt.h I used was dated June 2, 2003! So, I copied the one from /usr/include/rpcsvc/ to /usr/include/. That one was dated Feb 24 2008. Then p.c compiled fine and worked on the FBSD 7 box. Does this get me any closer to fixing this? Just for grins I de-installed tac_plus, did a "make clean", another compile and install with the crypt.h file still in /usr/include. It still doesn't work with '/etc/passwd" or "PAM". TIA ...jgm -----Original Message----- From: Kiss Gabor (Bitman) [mailto:kissg at ssg.ki.iif.hu] Sent: Wednesday, March 12, 2008 1:18 PM To: Joe Moore Cc: tac_plus at shrubbery.net Subject: Re: [tac_plus] Re: tac_plus with PAM on FreeBSD > I'm not a developer, but when I run tac_plus with /etc/passwd auth, > debug output shows my (correct) password in plain text. Debug also shows > what the plain-text password "encrypts to", which does not resemble the > hash in /etc/master.passwd. > > The hashed pw in master.passwd is MD5 and has an 8 character salt > prepended to the hash. I'm guessing (and that's all it is) that maybe > tac_plus is using a different method to encrypt the plain-text password > than FBSD is using, or maybe it's just not aware of the salt. I know pwlib.c contains this: des_verify(...) { ... ep = (char *) crypt(users_passwd, encrypted_passwd); ... if (strcmp(ep, encrypted_passwd) == 0) { if (debug & DEBUG_PASSWD_FLAG) report(LOG_DEBUG, "Password is correct"); return(1); } } It just passes old stored hash as 'encrypted_passwd' to crypt(). It works because hash begins with the salt. I suggest you to compile a 5 line test program like this: #include #include main(int argc, char **argv) { printf("%s\n",crypt(argv[1], argv[2])); } Assuming source file is called p.c $ make CFLAGS='-lcrypt' p Then run it with plain password and old hash as arguments. Assuming your password is 'plaintext' $ ./p plaintext '$1$2K1JYNC3$qik58Zlm5tccXeZJ4v0Xm.' $1$2K1JYNC3$qik58Zlm5tccXeZJ4v0Xm. It works for me on Debian Etch Linux, i386 architecture. What can you see on stdout on different platforms? Gabor From joe.moore at holidaycompanies.com Thu Mar 13 06:41:23 2008 From: joe.moore at holidaycompanies.com (Joe Moore) Date: Thu, 13 Mar 2008 01:41:23 -0500 Subject: [tac_plus] FW: Re: tac_plus with PAM on FreeBSD Message-ID: It is now working! Apparently, something that gets "patched" or altered in the FreeBSD "ports" build breaks system and PAM auth. I downloaded the source directly from ftp.shrubbery.net, built it without doing anything special, and suddenly, authenticating to both PAM (I copied the /etc/pam.d/sshd file to /etc/pam.d/tac_plus) and /etc/passwd works fine! I had been using the "ports" process all along with FBSD and a plain old "./configure, make, make install" on Linux. Maybe I'll get really lucky and those annoying "expecting continue" console logs will go away too :-) Thanks for your support! ...jgm -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Joe Moore Sent: Wednesday, March 12, 2008 11:09 PM To: tac_plus at shrubbery.net Subject: [tac_plus] Re: tac_plus with PAM on FreeBSD OK, I tried compiling on FBSD 6.2 and it couldn't find "crypt.h". I found a few copies scattered around the system so I copied on from /usr/src/lib/libcrypt/. The compile then failed due to a syntax error in crypt.h. p.c compiled fine on Centos5 Linux. It worked correctly there too. I had the same problems on the FBSD 7 box that I had on the 6.2 box initially. Then, I noticed that the crypt.h I used was dated June 2, 2003! So, I copied the one from /usr/include/rpcsvc/ to /usr/include/. That one was dated Feb 24 2008. Then p.c compiled fine and worked on the FBSD 7 box. Does this get me any closer to fixing this? Just for grins I de-installed tac_plus, did a "make clean", another compile and install with the crypt.h file still in /usr/include. It still doesn't work with '/etc/passwd" or "PAM". TIA ...jgm -----Original Message----- From: Kiss Gabor (Bitman) [mailto:kissg at ssg.ki.iif.hu] Sent: Wednesday, March 12, 2008 1:18 PM To: Joe Moore Cc: tac_plus at shrubbery.net Subject: Re: [tac_plus] Re: tac_plus with PAM on FreeBSD > I'm not a developer, but when I run tac_plus with /etc/passwd auth, > debug output shows my (correct) password in plain text. Debug also shows > what the plain-text password "encrypts to", which does not resemble the > hash in /etc/master.passwd. > > The hashed pw in master.passwd is MD5 and has an 8 character salt > prepended to the hash. I'm guessing (and that's all it is) that maybe > tac_plus is using a different method to encrypt the plain-text password > than FBSD is using, or maybe it's just not aware of the salt. I know pwlib.c contains this: des_verify(...) { ... ep = (char *) crypt(users_passwd, encrypted_passwd); ... if (strcmp(ep, encrypted_passwd) == 0) { if (debug & DEBUG_PASSWD_FLAG) report(LOG_DEBUG, "Password is correct"); return(1); } } It just passes old stored hash as 'encrypted_passwd' to crypt(). It works because hash begins with the salt. I suggest you to compile a 5 line test program like this: #include #include main(int argc, char **argv) { printf("%s\n",crypt(argv[1], argv[2])); } Assuming source file is called p.c $ make CFLAGS='-lcrypt' p Then run it with plain password and old hash as arguments. Assuming your password is 'plaintext' $ ./p plaintext '$1$2K1JYNC3$qik58Zlm5tccXeZJ4v0Xm.' $1$2K1JYNC3$qik58Zlm5tccXeZJ4v0Xm. It works for me on Debian Etch Linux, i386 architecture. What can you see on stdout on different platforms? Gabor _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From heas at shrubbery.net Thu Mar 13 16:49:03 2008 From: heas at shrubbery.net (john heasley) Date: Thu, 13 Mar 2008 09:49:03 -0700 Subject: [tac_plus] Re: FW: Re: tac_plus with PAM on FreeBSD In-Reply-To: References: Message-ID: <20080313164903.GG13989@shrubbery.net> Thu, Mar 13, 2008 at 01:41:23AM -0500, Joe Moore: > It is now working! > > Apparently, something that gets "patched" or altered in the FreeBSD > "ports" build breaks system and PAM auth. I downloaded the source > directly from ftp.shrubbery.net, built it without doing anything > special, and suddenly, authenticating to both PAM (I copied the > /etc/pam.d/sshd file to /etc/pam.d/tac_plus) and /etc/passwd works fine! > I had been using the "ports" process all along with FBSD and a plain old > "./configure, make, make install" on Linux. so, there are no problems at all, freebsd or centos; right? > Maybe I'll get really lucky and those annoying "expecting continue" > console logs will go away too :-) That is a cisco bug, afaict. It started just a few IOS revisions ago. I have not yet spent the time to trace it precisely and raise a bug with Cisco. > Thanks for your support! > > ...jgm > > > > > -----Original Message----- > From: tac_plus-bounces at shrubbery.net > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Joe Moore > Sent: Wednesday, March 12, 2008 11:09 PM > To: tac_plus at shrubbery.net > Subject: [tac_plus] Re: tac_plus with PAM on FreeBSD > > OK, I tried compiling on FBSD 6.2 and it couldn't find "crypt.h". I > found a few copies scattered around the system so I copied on from > /usr/src/lib/libcrypt/. The compile then failed due to a syntax error in > crypt.h. > > p.c compiled fine on Centos5 Linux. It worked correctly there too. > > I had the same problems on the FBSD 7 box that I had on the 6.2 box > initially. Then, I noticed that the crypt.h I used was dated June 2, > 2003! So, I copied the one from /usr/include/rpcsvc/ to /usr/include/. > That one was dated Feb 24 2008. Then p.c compiled fine and worked on the > FBSD 7 box. > > Does this get me any closer to fixing this? > > Just for grins I de-installed tac_plus, did a "make clean", another > compile and install with the crypt.h file still in /usr/include. It > still doesn't work with '/etc/passwd" or "PAM". > > TIA ...jgm > > > > > > -----Original Message----- > From: Kiss Gabor (Bitman) [mailto:kissg at ssg.ki.iif.hu] > Sent: Wednesday, March 12, 2008 1:18 PM > To: Joe Moore > Cc: tac_plus at shrubbery.net > Subject: Re: [tac_plus] Re: tac_plus with PAM on FreeBSD > > > I'm not a developer, but when I run tac_plus with /etc/passwd auth, > > debug output shows my (correct) password in plain text. Debug also > shows > > what the plain-text password "encrypts to", which does not resemble > the > > hash in /etc/master.passwd. > > > > The hashed pw in master.passwd is MD5 and has an 8 character salt > > prepended to the hash. I'm guessing (and that's all it is) that maybe > > tac_plus is using a different method to encrypt the plain-text > password > > than FBSD is using, or maybe it's just not aware of the salt. I know > > pwlib.c contains this: > des_verify(...) > { > ... > ep = (char *) crypt(users_passwd, encrypted_passwd); > ... > if (strcmp(ep, encrypted_passwd) == 0) { > if (debug & DEBUG_PASSWD_FLAG) > report(LOG_DEBUG, "Password is correct"); > return(1); > } > } > > It just passes old stored hash as 'encrypted_passwd' to crypt(). > It works because hash begins with the salt. > > I suggest you to compile a 5 line test program like this: > > #include > #include > main(int argc, char **argv) { > printf("%s\n",crypt(argv[1], argv[2])); > } > > Assuming source file is called p.c > > $ make CFLAGS='-lcrypt' p > > Then run it with plain password and old hash as arguments. > Assuming your password is 'plaintext' > > $ ./p plaintext '$1$2K1JYNC3$qik58Zlm5tccXeZJ4v0Xm.' > $1$2K1JYNC3$qik58Zlm5tccXeZJ4v0Xm. > > It works for me on Debian Etch Linux, i386 architecture. > What can you see on stdout on different platforms? > > Gabor > _______________________________________________ > 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 Andy_Ziegelbein at hawkerbeechcraft.com Wed Mar 12 22:22:39 2008 From: Andy_Ziegelbein at hawkerbeechcraft.com (Andy Ziegelbein) Date: Wed, 12 Mar 2008 17:22:39 -0500 Subject: [tac_plus] Enable authentication using local passwd file not working Message-ID: To Whom It May Concern: I have successfully configured our TACACS+ daemon with a handful of users and a group but am having a bit of difficulty getting the enable authentication to work the way I'd like. The user configuration contains nothing more than a group member reference and the group configuration reads as follows: group = admins { default service = permit login = file /etc/passwd enable = des tl9ayrG/iJDwM service = exec { default attribute = permit priv-lvl = 15 } } We are running the TACACS+ daemon on Solaris 9 and are authenticating against the local UNIX database (note: I had to reference /etc/passwd instead of /etc/shadow for this to work). The TACACS+ process runs as root. As you can see, we are currently using a shared group enable password. I would like to change this to have users authenticate against the local UNIX database just as they do for login authentication. However, when I configure 'enable = file /etc/passwd', I get the following error message: Wed Mar 12 16:59:17 2008 [14725]: Error 199.46.201.38: Error cannot identify password type file /etc/passwd for username Wed Mar 12 16:59:17 2008 [14725]: enable query for 'username' tty2 from 199.46.201.38 rejected Is this something that should work, and if so, can you offer any guidance as to what I'm doing wrong? ________________________________ Andy Ziegelbein Computer Sciences Corporation Managed Network Services w: (316) 676-7539 m: (512) 694-0345 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20080312/b5c0f8af/attachment.html From tom_mccormack at excite.com Fri Mar 21 23:08:22 2008 From: tom_mccormack at excite.com (Tom Mccormack) Date: Fri, 21 Mar 2008 19:08:22 -0400 (EDT) Subject: [tac_plus] How do I enable logging of failed login attempts to the accounting log ? Message-ID: <20080321230822.5E2D099DE4@xprdmxin.myway.com> Hi, How do I enable logging of failed login attempts to the accounting log ? Ive read that unless the network access server (NAS) is configured to do so, failed login attempts are not logged to the accounting server but I cant find what I need to do to enable this. On my Cisco router I added the command aaa accounting send stop-record authentication failure Rgds From heas at shrubbery.net Sat Mar 22 18:10:04 2008 From: heas at shrubbery.net (john heasley) Date: Sat, 22 Mar 2008 18:10:04 +0000 Subject: [tac_plus] Re: How do I enable logging of failed login attempts to the accounting log ? In-Reply-To: <20080321230822.5E2D099DE4@xprdmxin.myway.com> References: <20080321230822.5E2D099DE4@xprdmxin.myway.com> Message-ID: <20080322181004.GE4352@shrubbery.net> Fri, Mar 21, 2008 at 07:08:22PM -0400, Tom Mccormack: > > Hi, > > How do I enable logging of failed login attempts to the accounting log ? > > Ive read that unless the network access server (NAS) is configured to do so, failed login attempts are not logged to the accounting server but I cant find what I need to do to enable this. > > On my Cisco router I added the command > > aaa accounting send stop-record authentication failure > It works for me. but, it doesnt send a record until , which is usually 3. tac_plus >= F4.0.4.14 logs each failure itself.