[tac_plus] Re: Issue with Cisco switch authentication against Microsoft Active Directory
Hailu Meng
hailumeng at gmail.com
Mon Nov 23 21:12:53 UTC 2009
I just saw some posts saying pam_krb winbind could be needed to get pam work
against active directory. Is this true? The post I was following actually is
for a LDAP server not Active Directory.
On Mon, Nov 23, 2009 at 2:49 PM, Hailu Meng <hailumeng at gmail.com> wrote:
> I think I need put my pam configuration here:
>
> I followed this post
> http://www.shrubbery.net/pipermail/tac_plus/2009-January/000332.html to
> configure my pam module:
>
> /etc/pam.d/tacacs
>
> auth include system-auth
> account required pam_nologin.so
> account include system-auth
> password include system-auth
> session optional pam_keyinit.so force revoke
> session include system-auth
> session required pam_loginuid.so
>
> /etc/pam.d/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_unix.so broken_shadow
> 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 try_first_pass 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 [success=1 default=ignore] pam_succeed_if.so service in crond
> quiet use_uid
> session required pam_unix.so
> session optional pam_ldap.so
>
>
>
>
> On Mon, Nov 23, 2009 at 2:33 PM, Hailu Meng <hailumeng at gmail.com> wrote:
>
>> Hi John,
>>
>> You mean issue commands like tac_plus -C /etct/tac_plus.conf -L -p 49 -d
>> 16 -d 256 -g ? -d 16 -d 256 side by side? It didn't make any change. I got
>> same log info. By the way, I also saw the log info in /var/log/message:
>> Nov 23 14:24:25 NMS tac_plus[3676]: Reading config
>> Nov 23 14:24:25 NMS tac_plus[3676]: Version F4.0.4.19 Initialized 1
>> Nov 23 14:24:29 NMS tac_plus[3676]: connect from 10.1.69.89 [10.1.69.89]
>> Nov 23 14:24:37 NMS tac_plus[3676]: login query for 'myuser' tty0 from
>> 10.1.69.89 rejected
>> Nov 23 14:24:37 NMS tac_plus[3676]: login failure: myuser 10.1.69.89
>> (10.1.69.89) tty0
>>
>> Do we have option to see the log about PAM? I haven't found where it is.
>> if we can check the log of PAM, then we could find something useful. Right
>> now the log of tac_plus didn't tell too much about why login got failure.
>>
>> Lou
>>
>> On Mon, Nov 23, 2009 at 2:20 PM, john heasley <heas at shrubbery.net> wrote:
>>
>>> Mon, Nov 23, 2009 at 12:43:00PM -0600, Hailu Meng:
>>> > Thanks John for helping me check this issue.
>>> >
>>> > I just run tac_plus -C /path/to/tac_plus.conf -L -p 49 -d256 -g to see
>>> the
>>>
>>> try -d 16 -d 256. which i think will log the pwd that pam received from
>>> the device. make its correct. the logs below do appear to be a
>>> reject/fail
>>> returned from pam.
>>>
>>> > log in stdout and in log file. I can't see any suspicious log
>>> information
>>> > here. I paste the log below:
>>> >
>>> >
>>> > Sat Nov 21 22:28:22 2009 [3393]: Waiting for packet
>>> > Sat Nov 21 22:28:27 2009 [3393]: Read AUTHEN/CONT size=23
>>> > Sat Nov 21 22:28:27 2009 [3393]: PACKET: key=mykey
>>> > Sat Nov 21 22:28:27 2009 [3393]: version 192 (0xc0), type 1, seq no 5,
>>> flags
>>> > 0x1
>>> > Sat Nov 21 22:28:27 2009 [3393]: session_id 3295176910 (0xc46868ce),
>>> Data
>>> > length
>>> > 11 (0xb)
>>> > Sat Nov 21 22:28:27 2009 [3393]: End header
>>> > Sat Nov 21 22:28:27 2009 [3393]: type=AUTHEN/CONT
>>> > Sat Nov 21 22:28:27 2009 [3393]: user_msg_len 6 (0x6), user_data_len 0
>>> (0x0)
>>> > Sat Nov 21 22:28:27 2009 [3393]: flags=0x0
>>> > Sat Nov 21 22:28:27 2009 [3393]: User msg:
>>> > Sat Nov 21 22:28:27 2009 [3393]: myusername
>>> > Sat Nov 21 22:28:27 2009 [3393]: User data:
>>> > Sat Nov 21 22:28:27 2009 [3393]: End packet
>>> > Sat Nov 21 22:28:27 2009 [3393]: choose_authen chose default_fn
>>> > Sat Nov 21 22:28:27 2009 [3393]: Calling authentication function
>>> > Sat Nov 21 22:28:27 2009 [3393]: Writing AUTHEN/GETPASS size=28
>>> > Sat Nov 21 22:28:27 2009 [3393]: PACKET: key=mykey
>>> > Sat Nov 21 22:28:27 2009 [3393]: version 192 (0xc0), type 1, seq no 6,
>>> flags
>>> > 0x1
>>> > Sat Nov 21 22:28:27 2009 [3393]: session_id 3295176910 (0xc46868ce),
>>> Data
>>> > length
>>> > 16 (0x10)
>>> > Sat Nov 21 22:28:27 2009 [3393]: End header
>>> > Sat Nov 21 22:28:27 2009 [3393]: type=AUTHEN status=5 (AUTHEN/GETPASS)
>>> > flags=0x1
>>> > Sat Nov 21 22:28:27 2009 [3393]: msg_len=10, data_len=0
>>> > Sat Nov 21 22:28:27 2009 [3393]: msg:
>>> > Sat Nov 21 22:28:27 2009 [3393]: Password:
>>> > Sat Nov 21 22:28:27 2009 [3393]: data:
>>> > Sat Nov 21 22:28:27 2009 [3393]: End packet
>>> > Sat Nov 21 22:28:27 2009 [3393]: Waiting for packet
>>> > Sat Nov 21 22:28:34 2009 [3393]: Read AUTHEN/CONT size=30
>>> > Sat Nov 21 22:28:34 2009 [3393]: PACKET: key=mykey
>>>
>>> > Sat Nov 21 22:28:34 2009 [3393]: version 192 (0xc0), type 1, seq no 7,
>>> flags
>>> > 0x1
>>> > Sat Nov 21 22:28:34 2009 [3393]: session_id 3295176910 (0xc46868ce),
>>> Data
>>> > length
>>> > 18 (0x12)
>>> > Sat Nov 21 22:28:34 2009 [3393]: End header
>>> > Sat Nov 21 22:28:34 2009 [3393]: type=AUTHEN/CONT
>>> > Sat Nov 21 22:28:34 2009 [3393]: user_msg_len 13 (0xd), user_data_len 0
>>> > (0x0)
>>> > Sat Nov 21 22:28:34 2009 [3393]: flags=0x0
>>> > Sat Nov 21 22:28:34 2009 [3393]: User msg:
>>> > Sat Nov 21 22:28:34 2009 [3393]: mypassword
>>> > Sat Nov 21 22:28:34 2009 [3393]: User data:
>>> > Sat Nov 21 22:28:34 2009 [3393]: End packet
>>> > Sat Nov 21 22:28:36 2009 [3393]: login query for 'myusername' tty0 from
>>> > 10.1.69.89 r
>>> > ejected
>>> > Sat Nov 21 22:28:36 2009 [3393]: login failure: myusername 10.1.69.89
>>> > (10.1.69.89) t
>>> > ty0
>>> > Sat Nov 21 22:28:36 2009 [3393]: Writing AUTHEN/FAIL size=18
>>> > Sat Nov 21 22:28:36 2009 [3393]: PACKET: key=mykey
>>> > Sat Nov 21 22:28:36 2009 [3393]: version 192 (0xc0), type 1, seq no 8,
>>> flags
>>> > 0x1
>>> > Sat Nov 21 22:28:36 2009 [3393]: session_id 3295176910 (0xc46868ce),
>>> Data
>>> > length
>>> > 6 (0x6)
>>> > Sat Nov 21 22:28:36 2009 [3393]: End header
>>> > Sat Nov 21 22:28:36 2009 [3393]: type=AUTHEN status=2 (AUTHEN/FAIL)
>>> > flags=0x0
>>> > Sat Nov 21 22:28:36 2009 [3393]: msg_len=0, data_len=0
>>> > Sat Nov 21 22:28:36 2009 [3393]: msg:
>>> > Sat Nov 21 22:28:36 2009 [3393]: data:
>>> > Sat Nov 21 22:28:36 2009 [3393]: End packet
>>> > Sat Nov 21 22:28:36 2009 [3393]: 10.1.69.89: disconnect
>>> >
>>> >
>>> >
>>> > On Mon, Nov 23, 2009 at 12:23 PM, john heasley <heas at shrubbery.net>
>>> wrote:
>>> >
>>> > > Mon, Nov 23, 2009 at 12:12:58PM -0600, Hailu Meng:
>>> > > > Hi Adam,
>>> > > >
>>> > > > If the ldapsearch -D "" -w "" runs successfully, what do we suppose
>>> to
>>> > > get
>>> > > > from the output? I just got all of the user information in that
>>> group.
>>> > > Does
>>> > > > that means my password and username got authenticated successfully
>>> > > against
>>> > > > AD?
>>> > > >
>>> > > > This thing drives me crazy. I need solve it through this week
>>> before the
>>> > > > holiday...
>>> > >
>>> > > i havent followed this thread, as i know nearly zero about ldap.
>>> but,
>>> > > have you enabled authentication debugging in the tacacas daemon and
>>> > > checked the logs to determine what is coming back from pam? it very
>>> > > well may be that the ldap client is working just fine, but there is a
>>> > > pam module bug or a bug in the tacplus daemon or that your device
>>> > > simply doesnt like something about the replies.
>>> > >
>>> > > > Thanks a lot for the help.
>>> > > >
>>> > > > Lou
>>> > > >
>>> > > > On Fri, Nov 20, 2009 at 7:26 AM, Hailu Meng <hailumeng at gmail.com>
>>> wrote:
>>> > > >
>>> > > > > Still no clue how to turn on the log. binding seems good. See my
>>> > > findings
>>> > > > > below. Thanks a lot.
>>> > > > >
>>> > > > > On Thu, Nov 19, 2009 at 9:26 PM, adam <prozaconstilts at gmail.com>
>>> > > wrote:
>>> > > > >
>>> > > > >> Hailu Meng wrote:
>>> > > > >>
>>> > > > >>> Adam,
>>> > > > >>>
>>> > > > >>> I tried the su - "userid" in my tacacs+ server but I don't have
>>> that
>>> > > > >>> userid in CentOS. So the CentOS just don't want me log in. I
>>> think
>>> > > this will
>>> > > > >>> not ask tacacs server to authenticate against AD.
>>> > > > >>>
>>> > > > >>
>>> > > > >> You shouldn't need to have to define the user in CentOS, that's
>>> the
>>> > > point
>>> > > > >> of using ldap for authentication. The user is defined in ldap,
>>> not in
>>> > > > >> CentOS. Now that I think about it, su - <user> probably wouldn't
>>> work
>>> > > > >> anyway, as AD doesn't by default have the data needed by a linux
>>> box
>>> > > to
>>> > > > >> allow login...but see below for more options.
>>> > > > >>
>>> > > > >>
>>> > > > >>
>>> > > > >>> Is there any other way to test ldap authentication against AD
>>> with
>>> > > the
>>> > > > >>> userid in AD? I tried ldapsearch. It did find my user id
>>> without
>>> > > problem.
>>> > > > >>> But I haven't found any option to try with password and
>>> authenticate
>>> > > against
>>> > > > >>> AD.
>>> > > > >>>
>>> > > > >>
>>> > > > >> Try using -D:
>>> > > > >>
>>> > > > >> from `man ldapsearch`:
>>> > > > >>
>>> > > > >> -D binddn
>>> > > > >> Use the Distinguished Name binddn to bind to the LDAP
>>> directory.
>>> > > > >>
>>> > > > >> so -D cn=username,ou=my_ou,dc=my_dc should let you try to
>>> authenticate
>>> > > > >> using whatever user you want to define. Just check and double
>>> check
>>> > > you get
>>> > > > >> the right path in that dn.
>>> > > > >>
>>> > > > >>
>>> > > > >> I tried -D " cn=username,ou=my_ou,dc=my_dc " but it just
>>> returned lots
>>> > > of
>>> > > > > users' information. It means successful?
>>> > > > >
>>> > > > >
>>> > > > >> Do you have ldap server setup or only the openldap library and
>>> > > openldap
>>> > > > >>> client? I don't understand why the log is not turned on. There
>>> must
>>> > > be some
>>> > > > >>> debugging info in the log which can help solve this issue.
>>> > > > >>>
>>> > > > >>
>>> > > > >> only the libs and client. You should not need the server. In the
>>> > > > >> ldapsearch, you can use -d <integer> to get debugging info for
>>> that
>>> > > search.
>>> > > > >> As before, higher number = more debug
>>> > > > >>
>>> > > > >>
>>> > > > >> If the user can authenticate, does ethereal capture some
>>> packets
>>> > > about
>>> > > > >>> password verification? Right now I only see the packets when
>>> ldap
>>> > > search for
>>> > > > >>> my user id and gets results back from AD.
>>> > > > >>>
>>> > > > >>
>>> > > > >> Ethereal should catch all data flowing between the client and
>>> server.
>>> > > If
>>> > > > >> you can search out the user in your AD right now, then one of
>>> two
>>> > > things is
>>> > > > >> happening:
>>> > > > >>
>>> > > > >> 1. You are performing anonymous searches. In this case, no
>>> username
>>> > > and pw
>>> > > > >> is provided, and your AD is happy to hand over info to anyone
>>> who asks
>>> > > for
>>> > > > >> it. If this is the case, you will _not_ see authentication
>>> > > information. The
>>> > > > >> following MS KB article should probably help you determine on
>>> your AD
>>> > > if
>>> > > > >> anonymous queries are allowed:
>>> > > > >>
>>> > > > >> http://support.microsoft.com/kb/320528
>>> > > > >>
>>> > > > >> It has exact instructions for how to get it going, but you can
>>> follow
>>> > > > >> along with it to check your current settings without making any
>>> > > changes.
>>> > > > >>
>>> > > > >
>>> > > > > I checked our setting. Permission type for normal user is "Read &
>>> > > Execute".
>>> > > > > I click edit to check the detail about permission. I think it
>>> only
>>> > > allow the
>>> > > > > user to read the attributes, permission something and can't
>>> modify the
>>> > > > > AD.There is "Everyone" setting is also set as "Read & Execute".
>>> By the
>>> > > way,
>>> > > > > the AD is Win2003 R2.
>>> > > > >
>>> > > > >
>>> > > > >>
>>> > > > >> 2. Authentication is happening. It will be the _very_ first
>>> thing the
>>> > > > >> client and server perform, after basic connection establishment.
>>> Look
>>> > > for it
>>> > > > >> at the very beginning of a dump.
>>> > > > >>
>>> > > > >>
>>> > > > >>
>>> > > > >> Also, it's a bit overkill, but the following article is
>>> extremely
>>> > > > >> informative about all the different ways you can plug linux into
>>> AD
>>> > > for
>>> > > > >> authentication. It might offer some hints...
>>> > > > >>
>>> > > > >>
>>> > > > >>
>>> > > > >>
>>> > > > >>> Maybe I need dig into ldap.conf more. If you have any idea, let
>>> me
>>> > > know.
>>> > > > >>>
>>> > > > >>> Thank you very much.
>>> > > > >>>
>>> > > > >>> Lou
>>> > > > >>>
>>> > > > >>
>>> > > > >>
>>> > > > >>
>>> > > > >
>>> > > > -------------- next part --------------
>>> > > > An HTML attachment was scrubbed...
>>> > > > URL:
>>> > >
>>> http://www.shrubbery.net/pipermail/tac_plus/attachments/20091123/bba3d7fb/attachment.html
>>> > > > _______________________________________________
>>> > > > tac_plus mailing list
>>> > > > tac_plus at shrubbery.net
>>> > > > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
>>> > >
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20091123/1d5db6ba/attachment.html
More information about the tac_plus
mailing list