From daniel.schmidt at wyo.gov  Mon Mar  2 17:50:27 2015
From: daniel.schmidt at wyo.gov (Daniel Schmidt)
Date: Mon, 2 Mar 2015 10:50:27 -0700
Subject: [tac_plus] Issue: Incomplete passwords being accepted
In-Reply-To: <20150228200123.6c150337@hobbit>
References: <CAAQg-yWvJpyP04UDymXG=uO+YLFyDycV5pHX3KrDZW1GPErqvA@mail.gmail.com>
 <20150228071843.0fae8394@hobbit>
 <95CCE340-E6D5-46E6-A28A-EF3D2D83E131@shrubbery.net>
 <361FC21836C35F4DA4C9D78CC73244610251D6A5F56B@EXVMBX015-4.exch015.msoutlookonline.net>
 <20150228200123.6c150337@hobbit>
Message-ID: <CAOyMAKkji0gzJo+r_x3Jp2_y4gNgf3mi5i1W_87uBWcikzbzMg@mail.gmail.com>

To Alan's point, try your password in a better hasher, like this one I
threw up.  (Trivial python - available on request)

https://192.146.215.251/cgi-bin/gen_pass.cgi



On Sat, Feb 28, 2015 at 11:01 AM, Alan McKinnon <alan.mckinnon at gmail.com>
wrote:

> On Sat, 28 Feb 2015 08:29:42 -0800
> Matt Almgren <malmgren at skyfire.com> wrote:
>
> > I never noticed this before, but I see the same 8-character problem
> > with version F4.0.4.27a  and CentOS 6.4.
>
>
> You will see it on all versions of tac_plus on all distros. The
> password encryption is done in the crypt() system call which is where
> DES is implemented.
>
> It's not a bug it's a feature, it's just the way DES works. One more
> reason why you should not use DES for password hashing, superior types
> exist.
>
> Alan
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo/tac_plus
>


E-Mail to and from me, in connection with the transaction 
of public business, is subject to the Wyoming Public Records 
Act and may be disclosed to third parties.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150302/1049d3bd/attachment.html>

From krux at thcnet.net  Mon Mar  2 18:01:15 2015
From: krux at thcnet.net (Krux)
Date: Mon, 02 Mar 2015 10:01:15 -0800
Subject: [tac_plus] Issue: Incomplete passwords being accepted
In-Reply-To: <CAOyMAKkji0gzJo+r_x3Jp2_y4gNgf3mi5i1W_87uBWcikzbzMg@mail.gmail.com>
References: <CAAQg-yWvJpyP04UDymXG=uO+YLFyDycV5pHX3KrDZW1GPErqvA@mail.gmail.com>
 <20150228071843.0fae8394@hobbit>
 <95CCE340-E6D5-46E6-A28A-EF3D2D83E131@shrubbery.net>
 <361FC21836C35F4DA4C9D78CC73244610251D6A5F56B@EXVMBX015-4.exch015.msoutlookonline.net>
 <20150228200123.6c150337@hobbit>
 <CAOyMAKkji0gzJo+r_x3Jp2_y4gNgf3mi5i1W_87uBWcikzbzMg@mail.gmail.com>
Message-ID: <4C6E1B16-F4B3-4657-8F64-33E71C9F846E@thcnet.net>

So, I'm sure you mean well, but it's a bad security practice to send your password to a third party so they can generate a hash for you.
perl -e 's==UBER?=+y[:-o]}(;->\n{q-yp-y+k}?print:??;-p#)'

On March 2, 2015 9:50:27 AM PST, Daniel Schmidt <daniel.schmidt at wyo.gov> wrote:
>To Alan's point, try your password in a better hasher, like this one I
>threw up.  (Trivial python - available on request)
>
>https://192.146.215.251/cgi-bin/gen_pass.cgi
>
>
>
>On Sat, Feb 28, 2015 at 11:01 AM, Alan McKinnon
><alan.mckinnon at gmail.com>
>wrote:
>
>> On Sat, 28 Feb 2015 08:29:42 -0800
>> Matt Almgren <malmgren at skyfire.com> wrote:
>>
>> > I never noticed this before, but I see the same 8-character problem
>> > with version F4.0.4.27a  and CentOS 6.4.
>>
>>
>> You will see it on all versions of tac_plus on all distros. The
>> password encryption is done in the crypt() system call which is where
>> DES is implemented.
>>
>> It's not a bug it's a feature, it's just the way DES works. One more
>> reason why you should not use DES for password hashing, superior
>types
>> exist.
>>
>> Alan
>> _______________________________________________
>> tac_plus mailing list
>> tac_plus at shrubbery.net
>> http://www.shrubbery.net/mailman/listinfo/tac_plus
>>
>
>
>E-Mail to and from me, in connection with the transaction 
>of public business, is subject to the Wyoming Public Records 
>Act and may be disclosed to third parties.
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
><http://www.shrubbery.net/pipermail/tac_plus/attachments/20150302/1049d3bd/attachment.html>
>_______________________________________________
>tac_plus mailing list
>tac_plus at shrubbery.net
>http://www.shrubbery.net/mailman/listinfo/tac_plus



From daniel.schmidt at wyo.gov  Mon Mar  2 18:05:16 2015
From: daniel.schmidt at wyo.gov (Daniel Schmidt)
Date: Mon, 2 Mar 2015 11:05:16 -0700
Subject: [tac_plus] Issue: Incomplete passwords being accepted
In-Reply-To: <4C6E1B16-F4B3-4657-8F64-33E71C9F846E@thcnet.net>
References: <CAAQg-yWvJpyP04UDymXG=uO+YLFyDycV5pHX3KrDZW1GPErqvA@mail.gmail.com>
 <20150228071843.0fae8394@hobbit>
 <95CCE340-E6D5-46E6-A28A-EF3D2D83E131@shrubbery.net>
 <361FC21836C35F4DA4C9D78CC73244610251D6A5F56B@EXVMBX015-4.exch015.msoutlookonline.net>
 <20150228200123.6c150337@hobbit>
 <CAOyMAKkji0gzJo+r_x3Jp2_y4gNgf3mi5i1W_87uBWcikzbzMg@mail.gmail.com>
 <4C6E1B16-F4B3-4657-8F64-33E71C9F846E@thcnet.net>
Message-ID: <CAOyMAKmP4G0yKTStkU9E2yymTMBrQD_jE6QM5A2RdQnpZQTrhw@mail.gmail.com>

Which Y I say: Trivial python - available on request

On Mon, Mar 2, 2015 at 11:01 AM, Krux <krux at thcnet.net> wrote:

> So, I'm sure you mean well, but it's a bad security practice to send your
> password to a third party so they can generate a hash for you.
> perl -e 's==UBER?=+y[:-o]}(;->\n{q-yp-y+k}?print:??;-p#)'
>
> On March 2, 2015 9:50:27 AM PST, Daniel Schmidt <daniel.schmidt at wyo.gov>
> wrote:
> >To Alan's point, try your password in a better hasher, like this one I
> >threw up.  (Trivial python - available on request)
> >
> >https://192.146.215.251/cgi-bin/gen_pass.cgi
> >
> >
> >
> >On Sat, Feb 28, 2015 at 11:01 AM, Alan McKinnon
> ><alan.mckinnon at gmail.com>
> >wrote:
> >
> >> On Sat, 28 Feb 2015 08:29:42 -0800
> >> Matt Almgren <malmgren at skyfire.com> wrote:
> >>
> >> > I never noticed this before, but I see the same 8-character problem
> >> > with version F4.0.4.27a  and CentOS 6.4.
> >>
> >>
> >> You will see it on all versions of tac_plus on all distros. The
> >> password encryption is done in the crypt() system call which is where
> >> DES is implemented.
> >>
> >> It's not a bug it's a feature, it's just the way DES works. One more
> >> reason why you should not use DES for password hashing, superior
> >types
> >> exist.
> >>
> >> Alan
> >> _______________________________________________
> >> tac_plus mailing list
> >> tac_plus at shrubbery.net
> >> http://www.shrubbery.net/mailman/listinfo/tac_plus
> >>
> >
> >
> >E-Mail to and from me, in connection with the transaction
> >of public business, is subject to the Wyoming Public Records
> >Act and may be disclosed to third parties.
> >-------------- next part --------------
> >An HTML attachment was scrubbed...
> >URL:
> ><
> http://www.shrubbery.net/pipermail/tac_plus/attachments/20150302/1049d3bd/attachment.html
> >
> >_______________________________________________
> >tac_plus mailing list
> >tac_plus at shrubbery.net
> >http://www.shrubbery.net/mailman/listinfo/tac_plus
>
>
>


E-Mail to and from me, in connection with the transaction 
of public business, is subject to the Wyoming Public Records 
Act and may be disclosed to third parties.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150302/dfa5e573/attachment.html>

From malmgren at skyfire.com  Mon Mar  2 18:17:19 2015
From: malmgren at skyfire.com (Matt Almgren)
Date: Mon, 2 Mar 2015 10:17:19 -0800
Subject: [tac_plus] Issue: Incomplete passwords being accepted
In-Reply-To: <20150228200123.6c150337@hobbit>
References: <CAAQg-yWvJpyP04UDymXG=uO+YLFyDycV5pHX3KrDZW1GPErqvA@mail.gmail.com>
 <20150228071843.0fae8394@hobbit>
 <95CCE340-E6D5-46E6-A28A-EF3D2D83E131@shrubbery.net>
 <361FC21836C35F4DA4C9D78CC73244610251D6A5F56B@EXVMBX015-4.exch015.msoutlookonline.net>
 <20150228200123.6c150337@hobbit>
Message-ID: <D119E8AA.23F6E%malmgren@skyfire.com>

Alan, can you suggest a solution for this behavior (don?t want to call it
a problem, as it seems to be a feature.)

SSH logins to our TACACS server don?t seem to have this problem, so I
assume TACACS is calling this library some place during authentication
process?

Thanks, Matt





On 2/28/15, 10:01 AM, "Alan McKinnon" <alan.mckinnon at gmail.com> wrote:

>On Sat, 28 Feb 2015 08:29:42 -0800
>Matt Almgren <malmgren at skyfire.com> wrote:
>
>> I never noticed this before, but I see the same 8-character problem
>> with version F4.0.4.27a  and CentOS 6.4.
>
>
>You will see it on all versions of tac_plus on all distros. The
>password encryption is done in the crypt() system call which is where
>DES is implemented.
>
>It's not a bug it's a feature, it's just the way DES works. One more
>reason why you should not use DES for password hashing, superior types
>exist.
>
>Alan
>_______________________________________________
>tac_plus mailing list
>tac_plus at shrubbery.net
>http://www.shrubbery.net/mailman/listinfo/tac_plus


This message is being sent by Skyfire Labs, Inc.  It is intended exclusively for the individuals and entities to which it is addressed.  This communication, including any attachments, may contain information that is proprietary, privileged, confidential, or otherwise subject to restrictions on disclosure pursuant to applicable law.  If you are not the named addressee, you are not authorized to read, print, retain copy or disseminate this message or any part of it.  If you have received this message in error, please notify the sender immediately by email and delete all copies of this message.  This message is protected by applicable legal privileges and is confidential.

From krux at thcnet.net  Mon Mar  2 18:58:21 2015
From: krux at thcnet.net (Krux)
Date: Mon, 02 Mar 2015 10:58:21 -0800
Subject: [tac_plus] Issue: Incomplete passwords being accepted
In-Reply-To: <D119E8AA.23F6E%malmgren@skyfire.com>
References: <CAAQg-yWvJpyP04UDymXG=uO+YLFyDycV5pHX3KrDZW1GPErqvA@mail.gmail.com>
 <20150228071843.0fae8394@hobbit>
 <95CCE340-E6D5-46E6-A28A-EF3D2D83E131@shrubbery.net>
 <361FC21836C35F4DA4C9D78CC73244610251D6A5F56B@EXVMBX015-4.exch015.msoutlookonline.net>
 <20150228200123.6c150337@hobbit> <D119E8AA.23F6E%malmgren@skyfire.com>
Message-ID: <E334A740-00E4-47E6-85D3-E45891E69472@thcnet.net>

If you use PAM for tacacs auth, then it tire ties back to however you have configured PAM for tacacs.  You can also reference a passwd file.
perl -e 's==UBER?=+y[:-o]}(;->\n{q-yp-y+k}?print:??;-p#)'

On March 2, 2015 10:17:19 AM PST, Matt Almgren <malmgren at skyfire.com> wrote:
>Alan, can you suggest a solution for this behavior (don?t want to call
>it
>a problem, as it seems to be a feature.)
>
>SSH logins to our TACACS server don?t seem to have this problem, so I
>assume TACACS is calling this library some place during authentication
>process?
>
>Thanks, Matt
>
>
>
>
>
>On 2/28/15, 10:01 AM, "Alan McKinnon" <alan.mckinnon at gmail.com> wrote:
>
>>On Sat, 28 Feb 2015 08:29:42 -0800
>>Matt Almgren <malmgren at skyfire.com> wrote:
>>
>>> I never noticed this before, but I see the same 8-character problem
>>> with version F4.0.4.27a  and CentOS 6.4.
>>
>>
>>You will see it on all versions of tac_plus on all distros. The
>>password encryption is done in the crypt() system call which is where
>>DES is implemented.
>>
>>It's not a bug it's a feature, it's just the way DES works. One more
>>reason why you should not use DES for password hashing, superior types
>>exist.
>>
>>Alan
>>_______________________________________________
>>tac_plus mailing list
>>tac_plus at shrubbery.net
>>http://www.shrubbery.net/mailman/listinfo/tac_plus
>
>
>This message is being sent by Skyfire Labs, Inc.  It is intended
>exclusively for the individuals and entities to which it is addressed. 
>This communication, including any attachments, may contain information
>that is proprietary, privileged, confidential, or otherwise subject to
>restrictions on disclosure pursuant to applicable law.  If you are not
>the named addressee, you are not authorized to read, print, retain copy
>or disseminate this message or any part of it.  If you have received
>this message in error, please notify the sender immediately by email
>and delete all copies of this message.  This message is protected by
>applicable legal privileges and is confidential.
>_______________________________________________
>tac_plus mailing list
>tac_plus at shrubbery.net
>http://www.shrubbery.net/mailman/listinfo/tac_plus



From malmgren at skyfire.com  Mon Mar  2 19:15:00 2015
From: malmgren at skyfire.com (Matt Almgren)
Date: Mon, 2 Mar 2015 11:15:00 -0800
Subject: [tac_plus] Issue: Incomplete passwords being accepted
In-Reply-To: <E334A740-00E4-47E6-85D3-E45891E69472@thcnet.net>
References: <CAAQg-yWvJpyP04UDymXG=uO+YLFyDycV5pHX3KrDZW1GPErqvA@mail.gmail.com>
 <20150228071843.0fae8394@hobbit>
 <95CCE340-E6D5-46E6-A28A-EF3D2D83E131@shrubbery.net>
 <361FC21836C35F4DA4C9D78CC73244610251D6A5F56B@EXVMBX015-4.exch015.msoutlookonline.net>
 <20150228200123.6c150337@hobbit> <D119E8AA.23F6E%malmgren@skyfire.com>
 <E334A740-00E4-47E6-85D3-E45891E69472@thcnet.net>
Message-ID: <D119F69E.23FA6%malmgren@skyfire.com>

Ah yes, I see the problem now.  I have a static DES password in the
tac_plus.cfg file, versus other operations people who use the local system
for authentication.

I?ve had other users test this out and only I seem to be affected. :)

Thanks, Matt




On 3/2/15, 10:58 AM, "Krux" <krux at thcnet.net> wrote:

>If you use PAM for tacacs auth, then it tire ties back to however you
>have configured PAM for tacacs.  You can also reference a passwd file.
>perl -e 's==UBER?=+y[:-o]}(;->\n{q-yp-y+k}?print:??;-p#)'
>
>On March 2, 2015 10:17:19 AM PST, Matt Almgren <malmgren at skyfire.com>
>wrote:
>>Alan, can you suggest a solution for this behavior (don?t want to call
>>it
>>a problem, as it seems to be a feature.)
>>
>>SSH logins to our TACACS server don?t seem to have this problem, so I
>>assume TACACS is calling this library some place during authentication
>>process?
>>
>>Thanks, Matt
>>
>>
>>
>>
>>
>>On 2/28/15, 10:01 AM, "Alan McKinnon" <alan.mckinnon at gmail.com> wrote:
>>
>>>On Sat, 28 Feb 2015 08:29:42 -0800
>>>Matt Almgren <malmgren at skyfire.com> wrote:
>>>
>>>> I never noticed this before, but I see the same 8-character problem
>>>> with version F4.0.4.27a  and CentOS 6.4.
>>>
>>>
>>>You will see it on all versions of tac_plus on all distros. The
>>>password encryption is done in the crypt() system call which is where
>>>DES is implemented.
>>>
>>>It's not a bug it's a feature, it's just the way DES works. One more
>>>reason why you should not use DES for password hashing, superior types
>>>exist.
>>>
>>>Alan
>>>_______________________________________________
>>>tac_plus mailing list
>>>tac_plus at shrubbery.net
>>>http://www.shrubbery.net/mailman/listinfo/tac_plus
>>
>>
>>This message is being sent by Skyfire Labs, Inc.  It is intended
>>exclusively for the individuals and entities to which it is addressed.
>>This communication, including any attachments, may contain information
>>that is proprietary, privileged, confidential, or otherwise subject to
>>restrictions on disclosure pursuant to applicable law.  If you are not
>>the named addressee, you are not authorized to read, print, retain copy
>>or disseminate this message or any part of it.  If you have received
>>this message in error, please notify the sender immediately by email
>>and delete all copies of this message.  This message is protected by
>>applicable legal privileges and is confidential.
>>_______________________________________________
>>tac_plus mailing list
>>tac_plus at shrubbery.net
>>http://www.shrubbery.net/mailman/listinfo/tac_plus
>
>


This message is being sent by Skyfire Labs, Inc.  It is intended exclusively for the individuals and entities to which it is addressed.  This communication, including any attachments, may contain information that is proprietary, privileged, confidential, or otherwise subject to restrictions on disclosure pursuant to applicable law.  If you are not the named addressee, you are not authorized to read, print, retain copy or disseminate this message or any part of it.  If you have received this message in error, please notify the sender immediately by email and delete all copies of this message.  This message is protected by applicable legal privileges and is confidential.

From nicotine at warningg.com  Mon Mar  2 19:45:47 2015
From: nicotine at warningg.com (Brandon Ewing)
Date: Mon, 2 Mar 2015 13:45:47 -0600
Subject: [tac_plus] Issue: Incomplete passwords being accepted
In-Reply-To: <D119E8AA.23F6E%malmgren@skyfire.com>
References: <CAAQg-yWvJpyP04UDymXG=uO+YLFyDycV5pHX3KrDZW1GPErqvA@mail.gmail.com>
 <20150228071843.0fae8394@hobbit>
 <95CCE340-E6D5-46E6-A28A-EF3D2D83E131@shrubbery.net>
 <361FC21836C35F4DA4C9D78CC73244610251D6A5F56B@EXVMBX015-4.exch015.msoutlookonline.net>
 <20150228200123.6c150337@hobbit> <D119E8AA.23F6E%malmgren@skyfire.com>
Message-ID: <20150302194547.GA17922@radiological.warningg.com>

On Mon, Mar 02, 2015 at 10:17:19AM -0800, Matt Almgren wrote:
> Alan, can you suggest a solution for this behavior (don?t want to call it
> a problem, as it seems to be a feature.)
> 
> SSH logins to our TACACS server don?t seem to have this problem, so I
> assume TACACS is calling this library some place during authentication
> process?
> 
> Thanks, Matt
> 

tac_plus is calling your system's crypt() function to compare the submitted
password to the stored, correct hash, if you're storing them in your config
file.  It uses the salt format of the stored hash to determine what hashing 
algorithm was utilized to compute it.  See the man(3) page for crypt for 
more information.

Long story short, if you store DES hashes in your config, it's an issue.
MD5 (hash starting with $1$) hashes are what I use in production today, but
newer systems probably also have access to SHA-256 and SHA-512 in their
crypt() implementation.

-- 
Brandon Ewing                                     (nicotine at warningg.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150302/9ddd97b2/attachment.sig>

From heas at shrubbery.net  Wed Mar  4 08:48:37 2015
From: heas at shrubbery.net (heasley)
Date: Wed, 4 Mar 2015 08:48:37 +0000
Subject: [tac_plus] Issue: Incomplete passwords being accepted
In-Reply-To: <20150302194547.GA17922@radiological.warningg.com>
References: <CAAQg-yWvJpyP04UDymXG=uO+YLFyDycV5pHX3KrDZW1GPErqvA@mail.gmail.com>
 <20150228071843.0fae8394@hobbit>
 <95CCE340-E6D5-46E6-A28A-EF3D2D83E131@shrubbery.net>
 <361FC21836C35F4DA4C9D78CC73244610251D6A5F56B@EXVMBX015-4.exch015.msoutlookonline.net>
 <20150228200123.6c150337@hobbit>
 <D119E8AA.23F6E%malmgren@skyfire.com>
 <20150302194547.GA17922@radiological.warningg.com>
Message-ID: <20150304084837.GD20046@shrubbery.net>

Mon, Mar 02, 2015 at 01:45:47PM -0600, Brandon Ewing:
> On Mon, Mar 02, 2015 at 10:17:19AM -0800, Matt Almgren wrote:
> > Alan, can you suggest a solution for this behavior (don?t want to call it
> > a problem, as it seems to be a feature.)
> > 
> > SSH logins to our TACACS server don?t seem to have this problem, so I
> > assume TACACS is calling this library some place during authentication
> > process?
> > 
> > Thanks, Matt
> > 
> 
> tac_plus is calling your system's crypt() function to compare the submitted
> password to the stored, correct hash, if you're storing them in your config
> file.  It uses the salt format of the stored hash to determine what hashing 
> algorithm was utilized to compute it.  See the man(3) page for crypt for 
> more information.

exactly.  a user provided patch for SHA512 with tac_pwd is included here:
ftp://ftp.shrubbery.net/pub/tacacs/tacacs-F4.0.4.29a.tar.gz
it needs an autoconf check for SHA512 support, so if you do not have it
in your crypt(), dont use this alpha ball.


From adam at fullspansolutions.com  Fri Mar  6 23:32:09 2015
From: adam at fullspansolutions.com (Adam Schaeffer)
Date: Fri, 6 Mar 2015 23:32:09 +0000
Subject: [tac_plus] Possible Bug
Message-ID: <94eebbe72d7c4aad8e0853cc0897590c@mbx080-w3-co-2.exch080.serverpod.net>

I am not a sophisocated software / linux guy by any means so this may already be a known bug or issue with the system OR even an error on my part:

I was using tac plus in a lab and noticed that accounting packets are not properly received when the pre shared key is 5 or fewer characters.


tac_plus -C /etc/tac_plus.conf -d 32768

Fri Mar  6 18:23:58 2015 [9694]: Reading config
Fri Mar  6 18:23:58 2015 [9694]: Version F4.0.4.28 Initialized 1
Fri Mar  6 18:23:58 2015 [9694]: tac_plus server F4.0.4.28 starting
Fri Mar  6 18:23:58 2015 [9694]: socket FD 5 AF 2
Fri Mar  6 18:23:58 2015 [9694]: socket FD 7 AF 10
Fri Mar  6 18:23:58 2015 [9694]: uid=0 euid=0 gid=0 egid=0 s=164214912
Fri Mar  6 18:24:04 2015 [9695]: connect from 192.168.130.1 [192.168.130.1]
Fri Mar  6 18:24:04 2015 [9695]: Error 192.168.130.1: acct minimum payload: 183, got: 112




Cisco version information:


R1-2811#sh version
Cisco IOS Software, 2800 Software (C2800NM-ADVENTERPRISEK9-M), Version 12.4(24)T8, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
Compiled Sun 09-Sep-12 04:01 by prod_rel_team

ROM: System Bootstrap, Version 12.4(1r) [hqluong 1r], RELEASE SOFTWARE (fc1)

R1-2811 uptime is 1 week, 1 day, 22 hours, 52 minutes
System returned to ROM by reload at 01:31:19 UTC Thu Feb 26 2015
System image file is "flash:c2800nm-adventerprisek9-mz.124-24.T8.bin"


This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export at cisco.com.

Cisco 2811 (revision 53.50) with 772096K/14336K bytes of memory.
Processor board ID FTX1002C2RX
6 FastEthernet interfaces
32 terminal lines
1 Channelized (E1 or T1)/PRI port
1 Virtual Private Network (VPN) Module
4 Voice FXO interfaces
DRAM configuration is 64 bits wide with parity enabled.
239K bytes of non-volatile configuration memory.
500472K bytes of ATA CompactFlash (Read/Write)

Configuration register is 0x2102



Config snips:

aaa accounting exec default
action-type start-stop
group tacacs+
!
aaa accounting commands 0 default
action-type start-stop
group tacacs+
!
aaa accounting commands 1 default
action-type start-stop
group tacacs+
!
aaa accounting commands 15 default
action-type start-stop
group tacacs+


tacacs-server host 192.168.130.3 key cisco

I have access to a large array of Cisco hardware and unlimited access to IOS versions if you would like me to test against any other hardware and provide results in this matter or any others.

Thanks,

Adam Schaeffer
Owner / Sr. Engineer
Full Span Solutions LLC
717-715-9223

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150306/357ff1c7/attachment.html>

From heas at shrubbery.net  Fri Mar 13 22:48:03 2015
From: heas at shrubbery.net (heasley)
Date: Fri, 13 Mar 2015 22:48:03 +0000
Subject: [tac_plus] Possible Bug
In-Reply-To: <94eebbe72d7c4aad8e0853cc0897590c@mbx080-w3-co-2.exch080.serverpod.net>
References: <94eebbe72d7c4aad8e0853cc0897590c@mbx080-w3-co-2.exch080.serverpod.net>
Message-ID: <20150313224803.GF4459@shrubbery.net>

Fri, Mar 06, 2015 at 11:32:09PM +0000, Adam Schaeffer:
> I am not a sophisocated software / linux guy by any means so this may already be a known bug or issue with the system OR even an error on my part:
> 
> I was using tac plus in a lab and noticed that accounting packets are not properly received when the pre shared key is 5 or fewer characters.
> 
> 
> tac_plus -C /etc/tac_plus.conf -d 32768
> 
> Fri Mar  6 18:23:58 2015 [9694]: Reading config
> Fri Mar  6 18:23:58 2015 [9694]: Version F4.0.4.28 Initialized 1
> Fri Mar  6 18:23:58 2015 [9694]: tac_plus server F4.0.4.28 starting
> Fri Mar  6 18:23:58 2015 [9694]: socket FD 5 AF 2
> Fri Mar  6 18:23:58 2015 [9694]: socket FD 7 AF 10
> Fri Mar  6 18:23:58 2015 [9694]: uid=0 euid=0 gid=0 egid=0 s=164214912
> Fri Mar  6 18:24:04 2015 [9695]: connect from 192.168.130.1 [192.168.130.1]
> Fri Mar  6 18:24:04 2015 [9695]: Error 192.168.130.1: acct minimum payload: 183, got: 112
> 

can't reproduce this.  you'll have to provide more info.  your system, the
origin of the tacacs daemon, etc.

From sambill at netcourrier.com  Tue Mar 10 10:42:15 2015
From: sambill at netcourrier.com (sambill at netcourrier.com)
Date: Tue, 10 Mar 2015 11:42:15 +0100 (CET)
Subject: [tac_plus] need to inteface tac_plus with openldap
Message-ID: <ea-mime-54feca87-f94-305568be@www-1.netcourrier.com>


Hello;
I'm working on tac_plus in order to limite certain access to network equipment, then I need to interface tac_plus with our openldap, is there any tuto showing step by step how this can be done.
note that my tac_plus is running in different machine with openldap.

Thanks in advance for your any suggestion.

Best regards;
Landry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150310/306b388e/attachment.html>

From john at op-sec.us  Sat Mar 21 23:18:13 2015
From: john at op-sec.us (John Fraizer)
Date: Sat, 21 Mar 2015 16:18:13 -0700
Subject: [tac_plus] need to inteface tac_plus with openldap
In-Reply-To: <ea-mime-54feca87-f94-305568be@www-1.netcourrier.com>
References: <ea-mime-54feca87-f94-305568be@www-1.netcourrier.com>
Message-ID: <CALxrgMGmwkjs6WeDe0LcCH+Wg1T++czfpdMMU9ZLMYZgyv_FSg@mail.gmail.com>

Linux box configured to do ldap Auth running tac_plus with PAM
authentication.  Let PAM do the heavy lifting.  Just an aside though,
you're adding a point of failure. Ldap goes down you're locked out of your
tacacs server and any devices that use it for aaa.

John Fraizer
--Sent from my Android phone.
Please excuse any typos.
On Mar 21, 2015 7:19 AM, <sambill at netcourrier.com> wrote:

>
> Hello;
> I'm working on tac_plus in order to limite certain access to network
> equipment, then I need to interface tac_plus with our openldap, is there
> any tuto showing step by step how this can be done.
> note that my tac_plus is running in different machine with openldap.
>
> Thanks in advance for your any suggestion.
>
> Best regards;
> Landry
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.shrubbery.net/pipermail/tac_plus/attachments/20150310/306b388e/attachment.html
> >
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo/tac_plus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150321/a3d1fff8/attachment.html>

From matta at surveymonkey.com  Mon Mar 30 18:36:52 2015
From: matta at surveymonkey.com (Matt Almgren)
Date: Mon, 30 Mar 2015 18:36:52 +0000
Subject: [tac_plus] Authentication using Likewise and AD
Message-ID: <D13EE5D3.84C%matta@surveymonkey.com>


Hello all, I?ve recently joined another company that uses Likewise for authentication against AD.   Does anyone have any experience working with Likewise and using it with TAC+?  I?m assuming that if I configure PAM with TAC+, it will pass those authentication requests on to the AD server?

We?re running Ubuntu 14.04.1 LTS and the latest version of tac_plus, if that helps.

Thanks, Matt


--
Matt Almgren
Sr. Networking Engineer | SurveyMonkey




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150330/8a6e9d43/attachment.html>

From john at op-sec.us  Mon Mar 30 19:53:44 2015
From: john at op-sec.us (John Fraizer)
Date: Mon, 30 Mar 2015 12:53:44 -0700
Subject: [tac_plus] Authentication using Likewise and AD
In-Reply-To: <D13EE5D3.84C%matta@surveymonkey.com>
References: <D13EE5D3.84C%matta@surveymonkey.com>
Message-ID: <CALxrgMEVE1aMTzJtkUGe_ffq0jKi02CLHJOM04R8SXX+MXN8pw@mail.gmail.com>

Configure tac_plus to use password = PAM and it will authenticate via
whatever mechanism(s) PAM is configured to use.  With that said, bear in
mind that using LDAP for network auth isn't exactly the best idea.  When
you have a problem with your LDAP server, tac_plus doesn't know.  It just
acts as if your credentials are wrong and you're unable to log into network
devices.  It is even MORE fun because you can't even log into your tac_plus
server and shut down tac_plus so your network devices will use "local"
authentication because the server is ALSO using LDAP to authenticate.

Just some things to keep in mind.

--
John Fraizer
LinkedIn profile: http://www.linkedin.com/in/johnfraizer/



On Mon, Mar 30, 2015 at 11:36 AM, Matt Almgren <matta at surveymonkey.com>
wrote:

>
> Hello all, I?ve recently joined another company that uses Likewise for
> authentication against AD.   Does anyone have any experience working with
> Likewise and using it with TAC+?  I?m assuming that if I configure PAM with
> TAC+, it will pass those authentication requests on to the AD server?
>
> We?re running Ubuntu 14.04.1 LTS and the latest version of tac_plus, if
> that helps.
>
> Thanks, Matt
>
>
> --
> Matt Almgren
> Sr. Networking Engineer | SurveyMonkey
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.shrubbery.net/pipermail/tac_plus/attachments/20150330/8a6e9d43/attachment.html
> >
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo/tac_plus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150330/37a69be4/attachment.html>

From matta at surveymonkey.com  Mon Mar 30 20:17:54 2015
From: matta at surveymonkey.com (Matt Almgren)
Date: Mon, 30 Mar 2015 20:17:54 +0000
Subject: [tac_plus] Authentication using Likewise and AD
In-Reply-To: <auto-000025328758@inbound.appriver.com>
References: <D13EE5D3.84C%matta@surveymonkey.com>
 <auto-000025328758@inbound.appriver.com>
Message-ID: <D13EFC16.864%matta@surveymonkey.com>

Hi John, thanks for the information.  We have a fairly robust and redundant AD env here, so I?m not worried about it .  Plus we have other workarounds if the entire AAA infrastructure goes to hell that I can?t discuss on a public list.

My main goal is just to get as close to SSO as we can at this point.  I?ll try out the PAM method and report back my findings.

Thanks, Matt








From: John Fraizer <john at op-sec.us<mailto:john at op-sec.us>>
Date: Monday, March 30, 2015 at 12:53 PM
To: Matt Almgren <matta at surveymonkey.com<mailto:matta at surveymonkey.com>>
Cc: "tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>" <tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>>
Subject: Re: [tac_plus] Authentication using Likewise and AD

Configure tac_plus to use password = PAM and it will authenticate via whatever mechanism(s) PAM is configured to use.  With that said, bear in mind that using LDAP for network auth isn't exactly the best idea.  When you have a problem with your LDAP server, tac_plus doesn't know.  It just acts as if your credentials are wrong and you're unable to log into network devices.  It is even MORE fun because you can't even log into your tac_plus server and shut down tac_plus so your network devices will use "local" authentication because the server is ALSO using LDAP to authenticate.

Just some things to keep in mind.

--
John Fraizer
LinkedIn profile: http://www.linkedin.com/in/johnfraizer/



On Mon, Mar 30, 2015 at 11:36 AM, Matt Almgren <matta at surveymonkey.com<mailto:matta at surveymonkey.com>> wrote:

Hello all, I?ve recently joined another company that uses Likewise for authentication against AD.   Does anyone have any experience working with Likewise and using it with TAC+?  I?m assuming that if I configure PAM with TAC+, it will pass those authentication requests on to the AD server?

We?re running Ubuntu 14.04.1 LTS and the latest version of tac_plus, if that helps.

Thanks, Matt


--
Matt Almgren
Sr. Networking Engineer | SurveyMonkey




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150330/8a6e9d43/attachment.html>
_______________________________________________
tac_plus mailing list
tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>
http://www.shrubbery.net/mailman/listinfo/tac_plus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150330/5d36e240/attachment.html>

From john at op-sec.us  Mon Mar 30 21:56:50 2015
From: john at op-sec.us (John Fraizer)
Date: Mon, 30 Mar 2015 14:56:50 -0700
Subject: [tac_plus] Authentication using Likewise and AD
In-Reply-To: <D13F134B.876%matta@surveymonkey.com>
References: <D13EE5D3.84C%matta@surveymonkey.com>
 <auto-000025328758@inbound.appriver.com>
 <D13F134B.876%matta@surveymonkey.com>
Message-ID: <CALxrgMFV=-=y2C2jffwCs3tgcTz5FaG6d_F7g+MB4g7rDd5rSg@mail.gmail.com>

Make sure you've got PAM development libs installed.

John Fraizer
--Sent from my Android phone.
Please excuse any typos.
On Mar 30, 2015 2:53 PM, "Matt Almgren" <matta at surveymonkey.com> wrote:

>  It looks like pam libraries aren?t installed correctly and I can?t find
> the proper one to install, if it even matters:
>
>  My install says ?no? to this output message.  But the PAM_guide on the
> shrubbery site says it should be saying ?yes"
>
> *      checking for pam_start in -lpam... yes
>
> If that says yes, then the daemon will compile with pam support. If it
> says no, then configure is unable to find your pam libraries. Make sure
> you performed Step 1.*
>
> I assume this is important, or should I skip it and try to install without it?
>
>
> Thanks, Matt
>
>
>
>
>
>
>
>   From: John Fraizer <john at op-sec.us>
> Date: Monday, March 30, 2015 at 12:53 PM
> To: Matt Almgren <matta at surveymonkey.com>
> Cc: "tac_plus at shrubbery.net" <tac_plus at shrubbery.net>
> Subject: Re: [tac_plus] Authentication using Likewise and AD
>
>   Configure tac_plus to use password = PAM and it will authenticate via
> whatever mechanism(s) PAM is configured to use.  With that said, bear in
> mind that using LDAP for network auth isn't exactly the best idea.  When
> you have a problem with your LDAP server, tac_plus doesn't know.  It just
> acts as if your credentials are wrong and you're unable to log into network
> devices.  It is even MORE fun because you can't even log into your tac_plus
> server and shut down tac_plus so your network devices will use "local"
> authentication because the server is ALSO using LDAP to authenticate.
>
>  Just some things to keep in mind.
>
>   --
> John Fraizer
> LinkedIn profile: http://www.linkedin.com/in/johnfraizer/
>
>
>
> On Mon, Mar 30, 2015 at 11:36 AM, Matt Almgren <matta at surveymonkey.com>
> wrote:
>
>>
>> Hello all, I?ve recently joined another company that uses Likewise for
>> authentication against AD.   Does anyone have any experience working with
>> Likewise and using it with TAC+?  I?m assuming that if I configure PAM with
>> TAC+, it will pass those authentication requests on to the AD server?
>>
>> We?re running Ubuntu 14.04.1 LTS and the latest version of tac_plus, if
>> that helps.
>>
>> Thanks, Matt
>>
>>
>> --
>> Matt Almgren
>> Sr. Networking Engineer | SurveyMonkey
>>
>>
>>
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://www.shrubbery.net/pipermail/tac_plus/attachments/20150330/8a6e9d43/attachment.html
>> >
>> _______________________________________________
>> tac_plus mailing list
>> tac_plus at shrubbery.net
>> http://www.shrubbery.net/mailman/listinfo/tac_plus
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150330/04ed350a/attachment.html>

From matta at surveymonkey.com  Mon Mar 30 22:01:29 2015
From: matta at surveymonkey.com (Matt Almgren)
Date: Mon, 30 Mar 2015 22:01:29 +0000
Subject: [tac_plus] Authentication using Likewise and AD
In-Reply-To: <D13F134B.876%matta@surveymonkey.com>
References: <D13EE5D3.84C%matta@surveymonkey.com>
 <auto-000025328758@inbound.appriver.com>
 <D13F134B.876%matta@surveymonkey.com>
Message-ID: <D13F15B8.87C%matta@surveymonkey.com>

Ah found it?


  sudo apt-get install libpam0g-dev

Thanks, Matt





From: Matt Almgren <matta at surveymonkey.com<mailto:matta at surveymonkey.com>>
Date: Monday, March 30, 2015 at 2:53 PM
To: John Fraizer <john at op-sec.us<mailto:john at op-sec.us>>
Cc: "tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>" <tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>>
Subject: Re: [tac_plus] Authentication using Likewise and AD

It looks like pam libraries aren?t installed correctly and I can?t find the proper one to install, if it even matters:

My install says ?no? to this output message.  But the PAM_guide on the shrubbery site says it should be saying ?yes"

      checking for pam_start in -lpam... yes

If that says yes, then the daemon will compile with pam support. If it
says no, then configure is unable to find your pam libraries. Make sure
you performed Step 1.

I assume this is important, or should I skip it and try to install without it?


Thanks, Matt






From: John Fraizer <john at op-sec.us<mailto:john at op-sec.us>>
Date: Monday, March 30, 2015 at 12:53 PM
To: Matt Almgren <matta at surveymonkey.com<mailto:matta at surveymonkey.com>>
Cc: "tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>" <tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>>
Subject: Re: [tac_plus] Authentication using Likewise and AD

Configure tac_plus to use password = PAM and it will authenticate via whatever mechanism(s) PAM is configured to use.  With that said, bear in mind that using LDAP for network auth isn't exactly the best idea.  When you have a problem with your LDAP server, tac_plus doesn't know.  It just acts as if your credentials are wrong and you're unable to log into network devices.  It is even MORE fun because you can't even log into your tac_plus server and shut down tac_plus so your network devices will use "local" authentication because the server is ALSO using LDAP to authenticate.

Just some things to keep in mind.

--
John Fraizer
LinkedIn profile: http://www.linkedin.com/in/johnfraizer/



On Mon, Mar 30, 2015 at 11:36 AM, Matt Almgren <matta at surveymonkey.com<mailto:matta at surveymonkey.com>> wrote:

Hello all, I?ve recently joined another company that uses Likewise for authentication against AD.   Does anyone have any experience working with Likewise and using it with TAC+?  I?m assuming that if I configure PAM with TAC+, it will pass those authentication requests on to the AD server?

We?re running Ubuntu 14.04.1 LTS and the latest version of tac_plus, if that helps.

Thanks, Matt


--
Matt Almgren
Sr. Networking Engineer | SurveyMonkey




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150330/8a6e9d43/attachment.html>
_______________________________________________
tac_plus mailing list
tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>
http://www.shrubbery.net/mailman/listinfo/tac_plus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150330/f191009f/attachment.html>

From matta at surveymonkey.com  Mon Mar 30 21:53:17 2015
From: matta at surveymonkey.com (Matt Almgren)
Date: Mon, 30 Mar 2015 21:53:17 +0000
Subject: [tac_plus] Authentication using Likewise and AD
In-Reply-To: <auto-000025328758@inbound.appriver.com>
References: <D13EE5D3.84C%matta@surveymonkey.com>
 <auto-000025328758@inbound.appriver.com>
Message-ID: <D13F134B.876%matta@surveymonkey.com>

It looks like pam libraries aren?t installed correctly and I can?t find the proper one to install, if it even matters:

My install says ?no? to this output message.  But the PAM_guide on the shrubbery site says it should be saying ?yes"

      checking for pam_start in -lpam... yes

If that says yes, then the daemon will compile with pam support. If it
says no, then configure is unable to find your pam libraries. Make sure
you performed Step 1.

I assume this is important, or should I skip it and try to install without it?


Thanks, Matt






From: John Fraizer <john at op-sec.us<mailto:john at op-sec.us>>
Date: Monday, March 30, 2015 at 12:53 PM
To: Matt Almgren <matta at surveymonkey.com<mailto:matta at surveymonkey.com>>
Cc: "tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>" <tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>>
Subject: Re: [tac_plus] Authentication using Likewise and AD

Configure tac_plus to use password = PAM and it will authenticate via whatever mechanism(s) PAM is configured to use.  With that said, bear in mind that using LDAP for network auth isn't exactly the best idea.  When you have a problem with your LDAP server, tac_plus doesn't know.  It just acts as if your credentials are wrong and you're unable to log into network devices.  It is even MORE fun because you can't even log into your tac_plus server and shut down tac_plus so your network devices will use "local" authentication because the server is ALSO using LDAP to authenticate.

Just some things to keep in mind.

--
John Fraizer
LinkedIn profile: http://www.linkedin.com/in/johnfraizer/



On Mon, Mar 30, 2015 at 11:36 AM, Matt Almgren <matta at surveymonkey.com<mailto:matta at surveymonkey.com>> wrote:

Hello all, I?ve recently joined another company that uses Likewise for authentication against AD.   Does anyone have any experience working with Likewise and using it with TAC+?  I?m assuming that if I configure PAM with TAC+, it will pass those authentication requests on to the AD server?

We?re running Ubuntu 14.04.1 LTS and the latest version of tac_plus, if that helps.

Thanks, Matt


--
Matt Almgren
Sr. Networking Engineer | SurveyMonkey




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150330/8a6e9d43/attachment.html>
_______________________________________________
tac_plus mailing list
tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>
http://www.shrubbery.net/mailman/listinfo/tac_plus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150330/e6d47e3f/attachment.html>

From john at op-sec.us  Mon Mar 30 20:31:42 2015
From: john at op-sec.us (John Fraizer)
Date: Mon, 30 Mar 2015 13:31:42 -0700
Subject: [tac_plus] Authentication using Likewise and AD
In-Reply-To: <D13EFC16.864%matta@surveymonkey.com>
References: <D13EE5D3.84C%matta@surveymonkey.com>
 <auto-000025328758@inbound.appriver.com>
 <D13EFC16.864%matta@surveymonkey.com>
Message-ID: <CALxrgMH8qvn6Kod_8eKY2jBsPFd_-tztbzA3mLtdrpQ8sC-H1w@mail.gmail.com>

We have a fairly robust and redundant LDAP infrastructure at [insert very
large public company] too but, that doesn't mean that I'll accept a SPOF
(the LDAP infrastructure) in my network AAA.

I do a hybrid approach.  I have several TACACS+ servers that user LOCAL
accounts unix and password = PAM in tac_plus to auth.  The accounts are
replicated automagically on all all TACACS+ servers.  I validate the local
accounts against LDAP once/hour.  There *must* be a corresponding account
in LDAP - otherwise, the "local" account is locked.  Account creation is
also tied to there being an LDAP account.  I enforce password complexity,
age and reuse via PAM_cracklib and I've got a script that runs daily to
send out reminder emails to users every day for 14 days leading up to their
password expiring.  If they fail to log into the TACACS+ server and change
their password before it expires, the script locks the account.

I don't know about your company but, for SOX compliance, this works best
for mine.  I don't want the password they use for the local intranet or
email to be the same password that they use to log into network
infrastructure for a multitude of reasons.  BUT, I had to make
account-locking automatic in the event that someone is terminated (their
account is removed from LDAP as part of that process - which causes their
TACACS+ account to be locked) or their password expires (they refuse to log
in and change their password.)    This also keeps the "keys to the kingdom"
in the hands of those who should hold them.  It doesn't matter if you have
an LDAP account.  That doesn't let you log into the network
infrastructure.  You must ALSO have an account on the TACACS+
infrastructure - which can only be created by my team.

--
John Fraizer
LinkedIn profile: http://www.linkedin.com/in/johnfraizer/



On Mon, Mar 30, 2015 at 1:17 PM, Matt Almgren <matta at surveymonkey.com>
wrote:

>  Hi John, thanks for the information.  We have a fairly robust and
> redundant AD env here, so I?m not worried about it .  Plus we have other
> workarounds if the entire AAA infrastructure goes to hell that I can?t
> discuss on a public list.
>
>  My main goal is just to get as close to SSO as we can at this point.
> I?ll try out the PAM method and report back my findings.
>
>  Thanks, Matt
>
>
>
>
>
>
>
>
>   From: John Fraizer <john at op-sec.us>
> Date: Monday, March 30, 2015 at 12:53 PM
> To: Matt Almgren <matta at surveymonkey.com>
> Cc: "tac_plus at shrubbery.net" <tac_plus at shrubbery.net>
> Subject: Re: [tac_plus] Authentication using Likewise and AD
>
>   Configure tac_plus to use password = PAM and it will authenticate via
> whatever mechanism(s) PAM is configured to use.  With that said, bear in
> mind that using LDAP for network auth isn't exactly the best idea.  When
> you have a problem with your LDAP server, tac_plus doesn't know.  It just
> acts as if your credentials are wrong and you're unable to log into network
> devices.  It is even MORE fun because you can't even log into your tac_plus
> server and shut down tac_plus so your network devices will use "local"
> authentication because the server is ALSO using LDAP to authenticate.
>
>  Just some things to keep in mind.
>
>   --
> John Fraizer
> LinkedIn profile: http://www.linkedin.com/in/johnfraizer/
>
>
>
> On Mon, Mar 30, 2015 at 11:36 AM, Matt Almgren <matta at surveymonkey.com>
> wrote:
>
>>
>> Hello all, I?ve recently joined another company that uses Likewise for
>> authentication against AD.   Does anyone have any experience working with
>> Likewise and using it with TAC+?  I?m assuming that if I configure PAM with
>> TAC+, it will pass those authentication requests on to the AD server?
>>
>> We?re running Ubuntu 14.04.1 LTS and the latest version of tac_plus, if
>> that helps.
>>
>> Thanks, Matt
>>
>>
>> --
>> Matt Almgren
>> Sr. Networking Engineer | SurveyMonkey
>>
>>
>>
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://www.shrubbery.net/pipermail/tac_plus/attachments/20150330/8a6e9d43/attachment.html
>> >
>> _______________________________________________
>> tac_plus mailing list
>> tac_plus at shrubbery.net
>> http://www.shrubbery.net/mailman/listinfo/tac_plus
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150330/ff7cff9d/attachment.html>

From matta at surveymonkey.com  Tue Mar 31 04:45:30 2015
From: matta at surveymonkey.com (Matt Almgren)
Date: Tue, 31 Mar 2015 04:45:30 +0000
Subject: [tac_plus] Authentication using Likewise and AD
In-Reply-To: <auto-000025328758@inbound.appriver.com>
References: <D13EE5D3.84C%matta@surveymonkey.com>
 <auto-000025328758@inbound.appriver.com>
Message-ID: <D13F73A5.897%matta@surveymonkey.com>


Hey John/list,

I?ve been banging my head on this all day.  I?m hoping that since you replied you might have some insight into getting TAC+, Likewise, and PAM to play nice together.

I?m assuming that you have a modified pam.d module that handles the tac_plus authentication?   I?ve tried to use different variations in my PAM module, with no success.  Can you give me some tips on what you have working, if you have experience working with Likewise?

Thanks, Matt





From: John Fraizer <john at op-sec.us<mailto:john at op-sec.us>>
Date: Monday, March 30, 2015 at 12:53 PM
To: Matt Almgren <matta at surveymonkey.com<mailto:matta at surveymonkey.com>>
Cc: "tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>" <tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>>
Subject: Re: [tac_plus] Authentication using Likewise and AD

Configure tac_plus to use password = PAM and it will authenticate via whatever mechanism(s) PAM is configured to use.  With that said, bear in mind that using LDAP for network auth isn't exactly the best idea.  When you have a problem with your LDAP server, tac_plus doesn't know.  It just acts as if your credentials are wrong and you're unable to log into network devices.  It is even MORE fun because you can't even log into your tac_plus server and shut down tac_plus so your network devices will use "local" authentication because the server is ALSO using LDAP to authenticate.

Just some things to keep in mind.

--
John Fraizer
LinkedIn profile: http://www.linkedin.com/in/johnfraizer/



On Mon, Mar 30, 2015 at 11:36 AM, Matt Almgren <matta at surveymonkey.com<mailto:matta at surveymonkey.com>> wrote:

Hello all, I?ve recently joined another company that uses Likewise for authentication against AD.   Does anyone have any experience working with Likewise and using it with TAC+?  I?m assuming that if I configure PAM with TAC+, it will pass those authentication requests on to the AD server?

We?re running Ubuntu 14.04.1 LTS and the latest version of tac_plus, if that helps.

Thanks, Matt


--
Matt Almgren
Sr. Networking Engineer | SurveyMonkey




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150330/8a6e9d43/attachment.html>
_______________________________________________
tac_plus mailing list
tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>
http://www.shrubbery.net/mailman/listinfo/tac_plus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150331/4653f76e/attachment.html>

From john at op-sec.us  Tue Mar 31 06:26:31 2015
From: john at op-sec.us (John Fraizer)
Date: Mon, 30 Mar 2015 23:26:31 -0700
Subject: [tac_plus] Authentication using Likewise and AD
In-Reply-To: <D13F73A5.897%matta@surveymonkey.com>
References: <D13EE5D3.84C%matta@surveymonkey.com>
 <auto-000025328758@inbound.appriver.com>
 <D13F73A5.897%matta@surveymonkey.com>
Message-ID: <CALxrgME6P4RduTQNvQgp95ZKmUmUERNm+0dMKRa=WTF0i2i0GA@mail.gmail.com>

I didn't modify my Pam modules. If you can log in, you can authenticate via
tacacs on my systems.

John Fraizer
--Sent from my Android phone.
Please excuse any typos.
On Mar 30, 2015 9:45 PM, "Matt Almgren" <matta at surveymonkey.com> wrote:

>
>  Hey John/list,
>
>  I?ve been banging my head on this all day.  I?m hoping that since you
> replied you might have some insight into getting TAC+, Likewise, and PAM to
> play nice together.
>
>  I?m assuming that you have a modified pam.d module that handles the
> tac_plus authentication?   I?ve tried to use different variations in my PAM
> module, with no success.  Can you give me some tips on what you have
> working, if you have experience working with Likewise?
>
>  Thanks, Matt
>
>
>
>
>
>   From: John Fraizer <john at op-sec.us>
> Date: Monday, March 30, 2015 at 12:53 PM
> To: Matt Almgren <matta at surveymonkey.com>
> Cc: "tac_plus at shrubbery.net" <tac_plus at shrubbery.net>
> Subject: Re: [tac_plus] Authentication using Likewise and AD
>
>   Configure tac_plus to use password = PAM and it will authenticate via
> whatever mechanism(s) PAM is configured to use.  With that said, bear in
> mind that using LDAP for network auth isn't exactly the best idea.  When
> you have a problem with your LDAP server, tac_plus doesn't know.  It just
> acts as if your credentials are wrong and you're unable to log into network
> devices.  It is even MORE fun because you can't even log into your tac_plus
> server and shut down tac_plus so your network devices will use "local"
> authentication because the server is ALSO using LDAP to authenticate.
>
>  Just some things to keep in mind.
>
>   --
> John Fraizer
> LinkedIn profile: http://www.linkedin.com/in/johnfraizer/
>
>
>
> On Mon, Mar 30, 2015 at 11:36 AM, Matt Almgren <matta at surveymonkey.com>
> wrote:
>
>>
>> Hello all, I?ve recently joined another company that uses Likewise for
>> authentication against AD.   Does anyone have any experience working with
>> Likewise and using it with TAC+?  I?m assuming that if I configure PAM with
>> TAC+, it will pass those authentication requests on to the AD server?
>>
>> We?re running Ubuntu 14.04.1 LTS and the latest version of tac_plus, if
>> that helps.
>>
>> Thanks, Matt
>>
>>
>> --
>> Matt Almgren
>> Sr. Networking Engineer | SurveyMonkey
>>
>>
>>
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://www.shrubbery.net/pipermail/tac_plus/attachments/20150330/8a6e9d43/attachment.html
>> >
>> _______________________________________________
>> tac_plus mailing list
>> tac_plus at shrubbery.net
>> http://www.shrubbery.net/mailman/listinfo/tac_plus
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150330/cd3f55bf/attachment.html>

From vadud3 at gmail.com  Tue Mar 31 10:50:50 2015
From: vadud3 at gmail.com (Asif Iqbal)
Date: Tue, 31 Mar 2015 06:50:50 -0400
Subject: [tac_plus] Authentication using Likewise and AD
In-Reply-To: <D13EE5D3.84C%matta@surveymonkey.com>
References: <D13EE5D3.84C%matta@surveymonkey.com>
Message-ID: <CAOHBbgX_t7HJYUMRuBFy9kXN8mTjLZToUfdtz=ShOmaiKTNrmQ@mail.gmail.com>

On Mon, Mar 30, 2015 at 2:36 PM, Matt Almgren <matta at surveymonkey.com>
wrote:

>
> Hello all, I?ve recently joined another company that uses Likewise for
> authentication against AD.   Does anyone have any experience working with
> Likewise and using it with TAC+?  I?m assuming that if I configure PAM with
> TAC+, it will pass those authentication requests on to the AD server?
>
> We?re running Ubuntu 14.04.1 LTS and the latest version of tac_plus, if
> that helps.
>
> Thanks, Matt
>
>

Have you looked at the PAM_guide.txt and the notes on page
http://www.shrubbery.net/tac_plus/ ? That should cover most of it.




> --
> Matt Almgren
> Sr. Networking Engineer | SurveyMonkey
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.shrubbery.net/pipermail/tac_plus/attachments/20150330/8a6e9d43/attachment.html
> >
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo/tac_plus
>



-- 
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150331/bf315c9a/attachment.html>

From matta at surveymonkey.com  Tue Mar 31 13:29:12 2015
From: matta at surveymonkey.com (Matt Almgren)
Date: Tue, 31 Mar 2015 13:29:12 +0000
Subject: [tac_plus] Authentication using Likewise and AD
In-Reply-To: <auto-000071846366@inbound.appriver.com>
References: <D13EE5D3.84C%matta@surveymonkey.com>
 <auto-000071846366@inbound.appriver.com>
Message-ID: <D13FEEB8.8B6%matta@surveymonkey.com>

I?ve been over that guide several times.  When I use the entire library stack as shown in that guide, I get errors that some modules aren?t found ? I assumed it?s a RHEL vs Ubuntu difference.  I can try and track down the missing modules?but I don?t want it to conflict the rest of the PAM auth system.

Thanks, Matt





From: Asif Iqbal <vadud3 at gmail.com<mailto:vadud3 at gmail.com>>
Date: Tuesday, March 31, 2015 at 3:50 AM
To: Matt Almgren <matta at surveymonkey.com<mailto:matta at surveymonkey.com>>
Cc: "tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>" <tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>>
Subject: Re: [tac_plus] Authentication using Likewise and AD



On Mon, Mar 30, 2015 at 2:36 PM, Matt Almgren <matta at surveymonkey.com<mailto:matta at surveymonkey.com>> wrote:

Hello all, I?ve recently joined another company that uses Likewise for authentication against AD.   Does anyone have any experience working with Likewise and using it with TAC+?  I?m assuming that if I configure PAM with TAC+, it will pass those authentication requests on to the AD server?

We?re running Ubuntu 14.04.1 LTS and the latest version of tac_plus, if that helps.

Thanks, Matt



Have you looked at the PAM_guide.txt and the notes on page http://www.shrubbery.net/tac_plus/ ? That should cover most of it.




--
Matt Almgren
Sr. Networking Engineer | SurveyMonkey




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150330/8a6e9d43/attachment.html>
_______________________________________________
tac_plus mailing list
tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>
http://www.shrubbery.net/mailman/listinfo/tac_plus



--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu<http://pgp.mit.edu>
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150331/d2c80342/attachment.html>

From matta at surveymonkey.com  Tue Mar 31 14:22:58 2015
From: matta at surveymonkey.com (Matt Almgren)
Date: Tue, 31 Mar 2015 14:22:58 +0000
Subject: [tac_plus] Authentication using Likewise and AD
In-Reply-To: <D13FEEB8.8B6%matta@surveymonkey.com>
References: <D13EE5D3.84C%matta@surveymonkey.com>
 <auto-000071846366@inbound.appriver.com>
 <D13FEEB8.8B6%matta@surveymonkey.com>
Message-ID: <D13FFB2D.8C5%matta@surveymonkey.com>

One thing I?m not sure of, and I?m going to try this morning?

Since we have Likewise installed, is filling out the ldap.conf necessary?
 Perhaps that?s the problem, but I figured Likewise would be the connector
and the LDAP config wouldn?t be needed.

I see there?s an /etc/ldap.conf and also a /etc/ldap/ldap.conf.  Does it
matter which one is filled out?

Thanks, Matt






On 3/31/15, 6:29 AM, "Matt Almgren" <matta at surveymonkey.com> wrote:

>I?ve been over that guide several times.  When I use the entire library
>stack as shown in that guide, I get errors that some modules aren?t found
>? I assumed it?s a RHEL vs Ubuntu difference.  I can try and track down
>the missing modules?but I don?t want it to conflict the rest of the PAM
>auth system.
>
>Thanks, Matt
>
>
>
>
>
>From: Asif Iqbal <vadud3 at gmail.com<mailto:vadud3 at gmail.com>>
>Date: Tuesday, March 31, 2015 at 3:50 AM
>To: Matt Almgren <matta at surveymonkey.com<mailto:matta at surveymonkey.com>>
>Cc: "tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>"
><tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>>
>Subject: Re: [tac_plus] Authentication using Likewise and AD
>
>
>
>On Mon, Mar 30, 2015 at 2:36 PM, Matt Almgren
><matta at surveymonkey.com<mailto:matta at surveymonkey.com>> wrote:
>
>Hello all, I?ve recently joined another company that uses Likewise for
>authentication against AD.   Does anyone have any experience working with
>Likewise and using it with TAC+?  I?m assuming that if I configure PAM
>with TAC+, it will pass those authentication requests on to the AD server?
>
>We?re running Ubuntu 14.04.1 LTS and the latest version of tac_plus, if
>that helps.
>
>Thanks, Matt
>
>
>
>Have you looked at the PAM_guide.txt and the notes on page
>http://www.shrubbery.net/tac_plus/ ? That should cover most of it.
>
>
>
>
>--
>Matt Almgren
>Sr. Networking Engineer | SurveyMonkey
>
>
>
>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: 
><http://www.shrubbery.net/pipermail/tac_plus/attachments/20150330/8a6e9d43
>/attachment.html>
>_______________________________________________
>tac_plus mailing list
>tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>
>http://www.shrubbery.net/mailman/listinfo/tac_plus
>
>
>
>--
>Asif Iqbal
>PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu<http://pgp.mit.edu>
>A: Because it messes up the order in which people normally read text.
>Q: Why is top-posting such a bad thing?
>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: 
><http://www.shrubbery.net/pipermail/tac_plus/attachments/20150331/d2c80342
>/attachment.html>
>_______________________________________________
>tac_plus mailing list
>tac_plus at shrubbery.net
>http://www.shrubbery.net/mailman/listinfo/tac_plus


From heas at shrubbery.net  Tue Mar 31 14:25:19 2015
From: heas at shrubbery.net (heasley)
Date: Tue, 31 Mar 2015 14:25:19 +0000
Subject: [tac_plus] Authentication using Likewise and AD
In-Reply-To: <D13FEEB8.8B6%matta@surveymonkey.com>
References: <D13EE5D3.84C%matta@surveymonkey.com>
 <auto-000071846366@inbound.appriver.com>
 <D13FEEB8.8B6%matta@surveymonkey.com>
Message-ID: <20150331142519.GA20047@shrubbery.net>

Tue, Mar 31, 2015 at 01:29:12PM +0000, Matt Almgren:
> I?ve been over that guide several times.  When I use the entire library stack as shown in that guide, I get errors that some modules aren?t found ? I assumed it?s a RHEL vs Ubuntu difference.  I can try and track down the missing modules?but I don?t want it to conflict the rest of the PAM auth system.
> 
> Thanks, Matt

Looking at debian and redhat, both have numerous optional packages containing
additional modules.  you may need some of these, but certainly you must be
missing those files or they're not in the right location
(/lib/x86_64-linux-gnu/security/ on debian, but can be a FQPN).

That said, it seems that both are missing manpages - surprise.  On Solaris
or BSD, there is a debugging option.  If you can figure out if linux has
one - and what it is; that may help you unravel the PAM chaining.  You may
also look at the fbsd manpages for more thorough information, which may or
may not be applicable to linux.

eg: from fbsd:

MODULE OPTIONS
     Some PAM library functions may alter their behavior when called by a ser?
     vice module if certain module options were specified, regardless of
     whether the module itself accords them any importance.  One such option
     is debug, which causes the dispatcher to enable debugging messages before
     calling each service function, and disable them afterwards (unless they
     were already enabled).  Other special options include:

	...

You may also wish to begin with a simple pam config which authenticates
against /etc/passwd (or none) and build upon that, piece by piece.

Lastly, you mentioned errors but did not include them in your email, so we
are just guessing.  and, unless I've missed it, you also haven't shared your
pam conf for tac_plus.

From matta at surveymonkey.com  Tue Mar 31 14:32:37 2015
From: matta at surveymonkey.com (Matt Almgren)
Date: Tue, 31 Mar 2015 14:32:37 +0000
Subject: [tac_plus] Authentication using Likewise and AD
In-Reply-To: <20150331142519.GA20047@shrubbery.net>
References: <D13EE5D3.84C%matta@surveymonkey.com>
 <auto-000071846366@inbound.appriver.com>
 <D13FEEB8.8B6%matta@surveymonkey.com> <20150331142519.GA20047@shrubbery.net>
Message-ID: <D13FFCD5.8CE%matta@surveymonkey.com>

Hey there Heasley, 

I have been successful with local authentication using /etc/passwd and
DES.  So I know that TACACS and the switch are talking to each other well.

As for the contents of my pam config, well I?ve tried numerous things.

Here?s a few examples:

1)
auth       include      common-auth
account    required     pam_nologin.so
account    include      common-auth
password   include      common-auth
session    optional     pam_keyinit.so force revoke
session    include      common-auth
session    required     pam_loginuid.so


Which produces this common error in /var/log/auth.log:

Mar 31 07:12:44 sjc-tools01 tac_plus[8384]: pam_unix(tac_plus:auth): check
pass; user unknown
Mar 31 07:12:44 sjc-tools01 tac_plus[8384]: pam_unix(tac_plus:auth):
authentication failure; logname=DOMAIN\matta uid=0 euid=0 tty= ruser=
rhost=

2)
# here are the per-package modules (the "Primary" block)
auth	[success=2 default=ignore]	pam_unix.so nullok_secure
auth	[success=1 default=ignore]	pam_lsass.so try_first_pass
# here's the fallback if no module succeeds
auth	requisite			pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success
code
# since the modules above will each just jump around
auth	required			pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth	optional			pam_cap.so
# end of pam-auth-update config


Same errors in the auth.log


3)
# here are the per-package modules (the "Primary" block)
account	[success=3 new_authtok_reqd=done default=ignore]	pam_unix.so
account	[success=ok new_authtok_reqd=ok default=ignore]		pam_lsass.so
unknown_ok
account	[success=1 new_authtok_reqd=done default=ignore]	pam_lsass.so
# here's the fallback if no module succeeds
account	requisite			pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success
code
# since the modules above will each just jump around
account	required			pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config


Same errors in the auth.log

I?m open for any ideas. :)

Thanks, Matt









On 3/31/15, 7:25 AM, "heasley" <heas at shrubbery.net> wrote:

>Tue, Mar 31, 2015 at 01:29:12PM +0000, Matt Almgren:
>> I?ve been over that guide several times.  When I use the entire library
>>stack as shown in that guide, I get errors that some modules aren?t
>>found ? I assumed it?s a RHEL vs Ubuntu difference.  I can try and track
>>down the missing modules?but I don?t want it to conflict the rest of the
>>PAM auth system.
>> 
>> Thanks, Matt
>
>Looking at debian and redhat, both have numerous optional packages
>containing
>additional modules.  you may need some of these, but certainly you must be
>missing those files or they're not in the right location
>(/lib/x86_64-linux-gnu/security/ on debian, but can be a FQPN).
>
>That said, it seems that both are missing manpages - surprise.  On Solaris
>or BSD, there is a debugging option.  If you can figure out if linux has
>one - and what it is; that may help you unravel the PAM chaining.  You may
>also look at the fbsd manpages for more thorough information, which may or
>may not be applicable to linux.
>
>eg: from fbsd:
>
>MODULE OPTIONS
>     Some PAM library functions may alter their behavior when called by a
>ser-
>     vice module if certain module options were specified, regardless of
>     whether the module itself accords them any importance.  One such
>option
>     is debug, which causes the dispatcher to enable debugging messages
>before
>     calling each service function, and disable them afterwards (unless
>they
>     were already enabled).  Other special options include:
>
>	...
>
>You may also wish to begin with a simple pam config which authenticates
>against /etc/passwd (or none) and build upon that, piece by piece.
>
>Lastly, you mentioned errors but did not include them in your email, so we
>are just guessing.  and, unless I've missed it, you also haven't shared
>your
>pam conf for tac_plus.


From heas at shrubbery.net  Tue Mar 31 16:19:18 2015
From: heas at shrubbery.net (heasley)
Date: Tue, 31 Mar 2015 16:19:18 +0000
Subject: [tac_plus] Authentication using Likewise and AD
In-Reply-To: <D13FFCD5.8CE%matta@surveymonkey.com>
References: <D13EE5D3.84C%matta@surveymonkey.com>
 <auto-000071846366@inbound.appriver.com>
 <D13FEEB8.8B6%matta@surveymonkey.com>
 <20150331142519.GA20047@shrubbery.net>
 <D13FFCD5.8CE%matta@surveymonkey.com>
Message-ID: <20150331161918.GF20047@shrubbery.net>

Tue, Mar 31, 2015 at 02:32:37PM +0000, Matt Almgren:
> Hey there Heasley, 
> 
> I have been successful with local authentication using /etc/passwd and
> DES.  So I know that TACACS and the switch are talking to each other well.
> 
> As for the contents of my pam config, well I?ve tried numerous things.
> 
> Here?s a few examples:
> 
> 1)
> auth       include      common-auth
> account    required     pam_nologin.so
> account    include      common-auth
> password   include      common-auth
> session    optional     pam_keyinit.so force revoke
> session    include      common-auth
> session    required     pam_loginuid.so
> 
> 
> Which produces this common error in /var/log/auth.log:
> 
> Mar 31 07:12:44 sjc-tools01 tac_plus[8384]: pam_unix(tac_plus:auth): check
> pass; user unknown
> Mar 31 07:12:44 sjc-tools01 tac_plus[8384]: pam_unix(tac_plus:auth):
> authentication failure; logname=DOMAIN\matta uid=0 euid=0 tty= ruser=
> rhost=

this seems to be your issue; it looks like pam_unix is receiving a ldap-like
username, but thats not something it can handle, afaik.  if Likewise is
ldap-like and you want to verify that the user exists in the local unix
password file, then you would need a pam module that strips the "DOMAIN\\"
portion of the username before calling the passwd handling library functions.

From matta at surveymonkey.com  Tue Mar 31 16:23:12 2015
From: matta at surveymonkey.com (Matt Almgren)
Date: Tue, 31 Mar 2015 16:23:12 +0000
Subject: [tac_plus] Authentication using Likewise and AD
In-Reply-To: <20150331161918.GF20047@shrubbery.net>
References: <D13EE5D3.84C%matta@surveymonkey.com>
 <auto-000071846366@inbound.appriver.com>
 <D13FEEB8.8B6%matta@surveymonkey.com> <20150331142519.GA20047@shrubbery.net>
 <D13FFCD5.8CE%matta@surveymonkey.com> <20150331161918.GF20047@shrubbery.net>
Message-ID: <D1401781.8EF%matta@surveymonkey.com>


>you want to verify that the user exists in the local unix password file

But I don?t want it to use the local password file.  I want it to pass the
login name to the configured LDAP server that Likewise already knows
about. I *think* this is the way it should work.





On 3/31/15, 9:19 AM, "heasley" <heas at shrubbery.net> wrote:

>Tue, Mar 31, 2015 at 02:32:37PM +0000, Matt Almgren:
>> Hey there Heasley,
>> 
>> I have been successful with local authentication using /etc/passwd and
>> DES.  So I know that TACACS and the switch are talking to each other
>>well.
>> 
>> As for the contents of my pam config, well I?ve tried numerous things.
>> 
>> Here?s a few examples:
>> 
>> 1)
>> auth       include      common-auth
>> account    required     pam_nologin.so
>> account    include      common-auth
>> password   include      common-auth
>> session    optional     pam_keyinit.so force revoke
>> session    include      common-auth
>> session    required     pam_loginuid.so
>> 
>> 
>> Which produces this common error in /var/log/auth.log:
>> 
>> Mar 31 07:12:44 sjc-tools01 tac_plus[8384]: pam_unix(tac_plus:auth):
>>check
>> pass; user unknown
>> Mar 31 07:12:44 sjc-tools01 tac_plus[8384]: pam_unix(tac_plus:auth):
>> authentication failure; logname=DOMAIN\matta uid=0 euid=0 tty= ruser=
>> rhost=
>
>this seems to be your issue; it looks like pam_unix is receiving a
>ldap-like
>username, but thats not something it can handle, afaik.  if Likewise is
>ldap-like and you want to verify that the user exists in the local unix
>password file, then you would need a pam module that strips the "DOMAIN\\"
>portion of the username before calling the passwd handling library
>functions.


From matta at surveymonkey.com  Tue Mar 31 17:02:28 2015
From: matta at surveymonkey.com (Matt Almgren)
Date: Tue, 31 Mar 2015 17:02:28 +0000
Subject: [tac_plus] Authentication using Likewise and AD
In-Reply-To: <CALxrgMFAyX7PMbrqHcdugUhPc3hkHncjFd9ZTS=1WQyhP39+GA@mail.gmail.com>
References: <D13EE5D3.84C%matta@surveymonkey.com>
 <auto-000071846366@inbound.appriver.com>
 <D13FEEB8.8B6%matta@surveymonkey.com> <20150331142519.GA20047@shrubbery.net>
 <D13FFCD5.8CE%matta@surveymonkey.com> <20150331161918.GF20047@shrubbery.net>
 <D1401781.8EF%matta@surveymonkey.com>
 <CALxrgMFAyX7PMbrqHcdugUhPc3hkHncjFd9ZTS=1WQyhP39+GA@mail.gmail.com>
Message-ID: <D1401F8B.8F7%matta@surveymonkey.com>

John, I would love for it to be that simple.

Correct, we can login to the box using AD credentials and it works just fine.

i.e. "ssh matt at domain@hostname"  works just fine ..

I?m waiting on a domain account in AD to try out straight LDAP authentication.

Just to be sure, you don?t use a /etc/pam.d/tac_plus file?   If you do, what are it?s contents?

Thanks, Matt





From: John Fraizer <john at op-sec.us<mailto:john at op-sec.us>>
Date: Tuesday, March 31, 2015 at 9:50 AM
To: Matt Almgren <matta at surveymonkey.com<mailto:matta at surveymonkey.com>>
Cc: heasley <heas at shrubbery.net<mailto:heas at shrubbery.net>>, "tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>" <tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>>
Subject: Re: [tac_plus] Authentication using Likewise and AD

If you can authenticate to the local box using LDAP (as in, you can log in via SSH using a username/pw pair that is authenticated against LDAP), you should be able to just tell tac_plus password = PAM.



--
John Fraizer
LinkedIn profile: http://www.linkedin.com/in/johnfraizer/



On Tue, Mar 31, 2015 at 9:23 AM, Matt Almgren <matta at surveymonkey.com<mailto:matta at surveymonkey.com>> wrote:

>you want to verify that the user exists in the local unix password file

But I don?t want it to use the local password file.  I want it to pass the
login name to the configured LDAP server that Likewise already knows
about. I *think* this is the way it should work.





On 3/31/15, 9:19 AM, "heasley" <heas at shrubbery.net<mailto:heas at shrubbery.net>> wrote:

>Tue, Mar 31, 2015 at 02:32:37PM +0000, Matt Almgren:
>> Hey there Heasley,
>>
>> I have been successful with local authentication using /etc/passwd and
>> DES.  So I know that TACACS and the switch are talking to each other
>>well.
>>
>> As for the contents of my pam config, well I?ve tried numerous things.
>>
>> Here?s a few examples:
>>
>> 1)
>> auth       include      common-auth
>> account    required     pam_nologin.so
>> account    include      common-auth
>> password   include      common-auth
>> session    optional     pam_keyinit.so force revoke
>> session    include      common-auth
>> session    required     pam_loginuid.so
>>
>>
>> Which produces this common error in /var/log/auth.log:
>>
>> Mar 31 07:12:44 sjc-tools01 tac_plus[8384]: pam_unix(tac_plus:auth):
>>check
>> pass; user unknown
>> Mar 31 07:12:44 sjc-tools01 tac_plus[8384]: pam_unix(tac_plus:auth):
>> authentication failure; logname=DOMAIN\matta uid=0 euid=0 tty= ruser=
>> rhost=
>
>this seems to be your issue; it looks like pam_unix is receiving a
>ldap-like
>username, but thats not something it can handle, afaik.  if Likewise is
>ldap-like and you want to verify that the user exists in the local unix
>password file, then you would need a pam module that strips the "DOMAIN\\"
>portion of the username before calling the passwd handling library
>functions.

_______________________________________________
tac_plus mailing list
tac_plus at shrubbery.net<mailto:tac_plus at shrubbery.net>
http://www.shrubbery.net/mailman/listinfo/tac_plus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150331/3c748051/attachment.html>

From john at op-sec.us  Tue Mar 31 17:14:10 2015
From: john at op-sec.us (John Fraizer)
Date: Tue, 31 Mar 2015 10:14:10 -0700
Subject: [tac_plus] Authentication using Likewise and AD
In-Reply-To: <D1401F8B.8F7%matta@surveymonkey.com>
References: <D13EE5D3.84C%matta@surveymonkey.com>
 <auto-000071846366@inbound.appriver.com>
 <D13FEEB8.8B6%matta@surveymonkey.com> <20150331142519.GA20047@shrubbery.net>
 <D13FFCD5.8CE%matta@surveymonkey.com> <20150331161918.GF20047@shrubbery.net>
 <D1401781.8EF%matta@surveymonkey.com>
 <CALxrgMFAyX7PMbrqHcdugUhPc3hkHncjFd9ZTS=1WQyhP39+GA@mail.gmail.com>
 <D1401F8B.8F7%matta@surveymonkey.com>
Message-ID: <CALxrgMGK=eigUJrQHkVorBYz6Ay6OGOAgX25JT2R1tLhbQyi=w@mail.gmail.com>

No.  I don't use a tac_plus file in pam.d.

I think your issue right now is that your config is expecting to see
userid at domain rather than just userid.

My TACACS+ is not dependent on LDAP.  I do have access to an environment
that is authenticating against LDAP though.

Login to the local box is done with simple username/pw pair.  No need to
specify domain.

This is the contents of their /etc/pam.d/tac_plus

[root@#### pam.d]# cat tac_plus
#%PAM-1.0
auth       required     pam_nologin.so
auth       include      system-auth
account    include      system-auth
password   include      system-auth
session    include      system-auth

And since it simply points to system-auth for everything, here is the
contents of system-auth:

[root@#### pam.d]# cat system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so

account     required      pam_access.so
account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass
use_authtok
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     optional      pam_oddjob_mkhomedir.so skel=/etc/skel umask=0077
session     [success=1 default=ignore] pam_succeed_if.so service in crond
quiet use_uid
session     required      pam_unix.so
session     optional      pam_ldap.so


This particular box is running Centos 6.3.


Note that since tac_plus simply points to system-auth, it doesn't really
have any impact at all.  I use password = PAM on my tac_plus setup without
any specific tac_plus PAM configuration file.


--
John Fraizer
LinkedIn profile: http://www.linkedin.com/in/johnfraizer/



On Tue, Mar 31, 2015 at 10:02 AM, Matt Almgren <matta at surveymonkey.com>
wrote:

>  John, I would love for it to be that simple.
>
>  Correct, we can login to the box using AD credentials and it works just
> fine.
>
>  i.e. "ssh matt at domain@hostname"  works just fine ..
>
>  I?m waiting on a domain account in AD to try out straight LDAP
> authentication.
>
>  Just to be sure, you don?t use a /etc/pam.d/tac_plus file?   If you do,
> what are it?s contents?
>
>  Thanks, Matt
>
>
>
>
>
>   From: John Fraizer <john at op-sec.us>
> Date: Tuesday, March 31, 2015 at 9:50 AM
> To: Matt Almgren <matta at surveymonkey.com>
> Cc: heasley <heas at shrubbery.net>, "tac_plus at shrubbery.net" <
> tac_plus at shrubbery.net>
> Subject: Re: [tac_plus] Authentication using Likewise and AD
>
>   If you can authenticate to the local box using LDAP (as in, you can log
> in via SSH using a username/pw pair that is authenticated against LDAP),
> you should be able to just tell tac_plus password = PAM.
>
>
>
>   --
> John Fraizer
> LinkedIn profile: http://www.linkedin.com/in/johnfraizer/
>
>
>
> On Tue, Mar 31, 2015 at 9:23 AM, Matt Almgren <matta at surveymonkey.com>
> wrote:
>
>>
>> >you want to verify that the user exists in the local unix password file
>>
>> But I don?t want it to use the local password file.  I want it to pass the
>> login name to the configured LDAP server that Likewise already knows
>> about. I *think* this is the way it should work.
>>
>>
>>
>>
>>
>> On 3/31/15, 9:19 AM, "heasley" <heas at shrubbery.net> wrote:
>>
>> >Tue, Mar 31, 2015 at 02:32:37PM +0000, Matt Almgren:
>> >> Hey there Heasley,
>> >>
>> >> I have been successful with local authentication using /etc/passwd and
>> >> DES.  So I know that TACACS and the switch are talking to each other
>> >>well.
>> >>
>> >> As for the contents of my pam config, well I?ve tried numerous things.
>> >>
>> >> Here?s a few examples:
>> >>
>> >> 1)
>> >> auth       include      common-auth
>> >> account    required     pam_nologin.so
>> >> account    include      common-auth
>> >> password   include      common-auth
>> >> session    optional     pam_keyinit.so force revoke
>> >> session    include      common-auth
>> >> session    required     pam_loginuid.so
>> >>
>> >>
>> >> Which produces this common error in /var/log/auth.log:
>> >>
>> >> Mar 31 07:12:44 sjc-tools01 tac_plus[8384]: pam_unix(tac_plus:auth):
>> >>check
>> >> pass; user unknown
>> >> Mar 31 07:12:44 sjc-tools01 tac_plus[8384]: pam_unix(tac_plus:auth):
>> >> authentication failure; logname=DOMAIN\matta uid=0 euid=0 tty= ruser=
>> >> rhost=
>> >
>> >this seems to be your issue; it looks like pam_unix is receiving a
>> >ldap-like
>> >username, but thats not something it can handle, afaik.  if Likewise is
>> >ldap-like and you want to verify that the user exists in the local unix
>> >password file, then you would need a pam module that strips the
>> "DOMAIN\\"
>> >portion of the username before calling the passwd handling library
>> >functions.
>>
>> _______________________________________________
>> tac_plus mailing list
>> tac_plus at shrubbery.net
>> http://www.shrubbery.net/mailman/listinfo/tac_plus
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150331/31c7c65c/attachment.html>

From john at op-sec.us  Tue Mar 31 16:50:48 2015
From: john at op-sec.us (John Fraizer)
Date: Tue, 31 Mar 2015 09:50:48 -0700
Subject: [tac_plus] Authentication using Likewise and AD
In-Reply-To: <D1401781.8EF%matta@surveymonkey.com>
References: <D13EE5D3.84C%matta@surveymonkey.com>
 <auto-000071846366@inbound.appriver.com>
 <D13FEEB8.8B6%matta@surveymonkey.com> <20150331142519.GA20047@shrubbery.net>
 <D13FFCD5.8CE%matta@surveymonkey.com> <20150331161918.GF20047@shrubbery.net>
 <D1401781.8EF%matta@surveymonkey.com>
Message-ID: <CALxrgMFAyX7PMbrqHcdugUhPc3hkHncjFd9ZTS=1WQyhP39+GA@mail.gmail.com>

If you can authenticate to the local box using LDAP (as in, you can log in
via SSH using a username/pw pair that is authenticated against LDAP), you
should be able to just tell tac_plus password = PAM.



--
John Fraizer
LinkedIn profile: http://www.linkedin.com/in/johnfraizer/



On Tue, Mar 31, 2015 at 9:23 AM, Matt Almgren <matta at surveymonkey.com>
wrote:

>
> >you want to verify that the user exists in the local unix password file
>
> But I don?t want it to use the local password file.  I want it to pass the
> login name to the configured LDAP server that Likewise already knows
> about. I *think* this is the way it should work.
>
>
>
>
>
> On 3/31/15, 9:19 AM, "heasley" <heas at shrubbery.net> wrote:
>
> >Tue, Mar 31, 2015 at 02:32:37PM +0000, Matt Almgren:
> >> Hey there Heasley,
> >>
> >> I have been successful with local authentication using /etc/passwd and
> >> DES.  So I know that TACACS and the switch are talking to each other
> >>well.
> >>
> >> As for the contents of my pam config, well I?ve tried numerous things.
> >>
> >> Here?s a few examples:
> >>
> >> 1)
> >> auth       include      common-auth
> >> account    required     pam_nologin.so
> >> account    include      common-auth
> >> password   include      common-auth
> >> session    optional     pam_keyinit.so force revoke
> >> session    include      common-auth
> >> session    required     pam_loginuid.so
> >>
> >>
> >> Which produces this common error in /var/log/auth.log:
> >>
> >> Mar 31 07:12:44 sjc-tools01 tac_plus[8384]: pam_unix(tac_plus:auth):
> >>check
> >> pass; user unknown
> >> Mar 31 07:12:44 sjc-tools01 tac_plus[8384]: pam_unix(tac_plus:auth):
> >> authentication failure; logname=DOMAIN\matta uid=0 euid=0 tty= ruser=
> >> rhost=
> >
> >this seems to be your issue; it looks like pam_unix is receiving a
> >ldap-like
> >username, but thats not something it can handle, afaik.  if Likewise is
> >ldap-like and you want to verify that the user exists in the local unix
> >password file, then you would need a pam module that strips the "DOMAIN\\"
> >portion of the username before calling the passwd handling library
> >functions.
>
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo/tac_plus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150331/ad00ecaa/attachment.html>

From heas at shrubbery.net  Tue Mar 31 18:19:05 2015
From: heas at shrubbery.net (heasley)
Date: Tue, 31 Mar 2015 18:19:05 +0000
Subject: [tac_plus] Authentication using Likewise and AD
In-Reply-To: <CALxrgMFAyX7PMbrqHcdugUhPc3hkHncjFd9ZTS=1WQyhP39+GA@mail.gmail.com>
References: <D13EE5D3.84C%matta@surveymonkey.com>
 <auto-000071846366@inbound.appriver.com>
 <D13FEEB8.8B6%matta@surveymonkey.com>
 <20150331142519.GA20047@shrubbery.net>
 <D13FFCD5.8CE%matta@surveymonkey.com>
 <20150331161918.GF20047@shrubbery.net>
 <D1401781.8EF%matta@surveymonkey.com>
 <CALxrgMFAyX7PMbrqHcdugUhPc3hkHncjFd9ZTS=1WQyhP39+GA@mail.gmail.com>
Message-ID: <20150331181905.GI20047@shrubbery.net>

Tue, Mar 31, 2015 at 09:50:48AM -0700, John Fraizer:
> If you can authenticate to the local box using LDAP (as in, you can log in
> via SSH using a username/pw pair that is authenticated against LDAP), you
> should be able to just tell tac_plus password = PAM.

I'm no pam expert, but I do not think that is necessarily true; it could be,
but it is entiredly dependent upon the modules used, their implementation,
and control flags and options used for each.

if you can log into the host with ssh using the same username, with the
domain, and that is used for tacacs - and, there is no special handling
occuring in /bin/login or sshd - then, assuming that you use the same
config for tac_plus as with ssh, it *should* work.

but, in pam_unix(8) on redhat, i do not see anything indicating special
handling of the domain prefix.

> > >> Mar 31 07:12:44 sjc-tools01 tac_plus[8384]: pam_unix(tac_plus:auth):
> > >>check
> > >> pass; user unknown
> > >> Mar 31 07:12:44 sjc-tools01 tac_plus[8384]: pam_unix(tac_plus:auth):
> > >> authentication failure; logname=DOMAIN\matta uid=0 euid=0 tty= ruser=
> > >> rhost=

so, when pam_unix starts walking through passwd, getpwent(), its never going
to find DOMAIN\matta.  how pam goes from DOMAIN\matta to matta for pam_unix
is not something that i can answer.

given http://linux.die.net/man/5/pam_ldap pam_login_attribute and pam_filter
appear to play a role in this...but beyond that, ???

again, not a pam expert and don't know anything about Likewise and little
about ldap.