[tac_plus] Re: Issue with Cisco switch authentication against Microsoft Active Directory
Hailu Meng
hailumeng at gmail.com
Mon Nov 23 21:28:56 UTC 2009
Ok. With -d 32, I got some more info about pam as red color log.
There is "Unknown user" log info following the input of my user password.
Feel confused since ldap is able to get user info from Active directory, why
it turns out "Unknown user" here.
Mon Nov 23 15:21:16 2009 [3806]: Read AUTHEN/CONT size=23
Mon Nov 23 15:21:16 2009 [3806]: PACKET: key=mykey
Mon Nov 23 15:21:16 2009 [3806]: version 192 (0xc0), type 1, seq no 3, flags
0x1
Mon Nov 23 15:21:16 2009 [3806]: session_id 3197597252 (0xbe977644), Data
length 11 (0xb)
Mon Nov 23 15:21:16 2009 [3806]: End header
Mon Nov 23 15:21:16 2009 [3806]: type=AUTHEN/CONT
Mon Nov 23 15:21:16 2009 [3806]: user_msg_len 6 (0x6), user_data_len 0 (0x0)
Mon Nov 23 15:21:16 2009 [3806]: flags=0x0
Mon Nov 23 15:21:16 2009 [3806]: User msg:
Mon Nov 23 15:21:16 2009 [3806]: myusername
Mon Nov 23 15:21:16 2009 [3806]: User data:
Mon Nov 23 15:21:16 2009 [3806]: End packet
Mon Nov 23 15:21:16 2009 [3806]: choose_authen chose default_fn
Mon Nov 23 15:21:16 2009 [3806]: Calling authentication function
Mon Nov 23 15:21:16 2009 [3806]: pam_verify myusername
Mon Nov 23 15:21:16 2009 [3806]: pam_tacacs received 1 pam_messages
Mon Nov 23 15:21:16 2009 [3806]: Error 10.1.69.89 tty0: PAM_PROMPT_ECHO_OFF
Mon Nov 23 15:21:16 2009 [3806]: Writing AUTHEN/GETPASS size=28
Mon Nov 23 15:21:16 2009 [3806]: PACKET: key=mykey
Mon Nov 23 15:21:16 2009 [3806]: version 192 (0xc0), type 1, seq no 4, flags
0x1
Mon Nov 23 15:21:16 2009 [3806]: session_id 3197597252 (0xbe977644), Data
length 16 (0x10)
Mon Nov 23 15:21:16 2009 [3806]: End header
Mon Nov 23 15:21:16 2009 [3806]: type=AUTHEN status=5 (AUTHEN/GETPASS)
flags=0x1
Mon Nov 23 15:21:16 2009 [3806]: msg_len=10, data_len=0
Mon Nov 23 15:21:16 2009 [3806]: msg:
Mon Nov 23 15:21:16 2009 [3806]: Password:
Mon Nov 23 15:21:16 2009 [3806]: data:
Mon Nov 23 15:21:16 2009 [3806]: End packet
Mon Nov 23 15:21:16 2009 [3806]: Waiting for packet
Mon Nov 23 15:21:21 2009 [3806]: Read AUTHEN/CONT size=30
Mon Nov 23 15:21:21 2009 [3806]: PACKET: key=mykey
Mon Nov 23 15:21:21 2009 [3806]: version 192 (0xc0), type 1, seq no 5, flags
0x1
Mon Nov 23 15:21:21 2009 [3806]: session_id 3197597252 (0xbe977644), Data
length 18 (0x12)
Mon Nov 23 15:21:21 2009 [3806]: End header
Mon Nov 23 15:21:21 2009 [3806]: type=AUTHEN/CONT
Mon Nov 23 15:21:21 2009 [3806]: user_msg_len 13 (0xd), user_data_len 0
(0x0)
Mon Nov 23 15:21:21 2009 [3806]: flags=0x0
Mon Nov 23 15:21:21 2009 [3806]: User msg:
Mon Nov 23 15:21:21 2009 [3806]: mypassword
Mon Nov 23 15:21:21 2009 [3806]: User data:
Mon Nov 23 15:21:21 2009 [3806]: End packet
Mon Nov 23 15:21:22 2009 [3806]: Unknown user
Mon Nov 23 15:21:22 2009 [3806]: login query for 'myusername' tty0 from
10.1.69.89 rejected
Mon Nov 23 15:21:22 2009 [3806]: login failure: myusername10.1.69.89
(10.1.69.89) tty0
Mon Nov 23 15:21:22 2009 [3806]: Writing AUTHEN/FAIL size=18
Mon Nov 23 15:21:22 2009 [3806]: PACKET: key=mykey
Mon Nov 23 15:21:22 2009 [3806]: version 192 (0xc0), type 1, seq no 6, flags
0x1
Mon Nov 23 15:21:22 2009 [3806]: session_id 3197597252 (0xbe977644), Data
length 6 (0x6)
Mon Nov 23 15:21:22 2009 [3806]: End header
Mon Nov 23 15:21:22 2009 [3806]: type=AUTHEN status=2 (AUTHEN/FAIL)
flags=0x0
Mon Nov 23 15:21:22 2009 [3806]: msg_len=0, data_len=0
Mon Nov 23 15:21:22 2009 [3806]: msg:
Mon Nov 23 15:21:22 2009 [3806]: data:
Mon Nov 23 15:21:22 2009 [3806]: End packet
Mon Nov 23 15:21:22 2009 [3806]: 10.1.69.89: disconnect
On Mon, Nov 23, 2009 at 3:16 PM, john heasley <heas at shrubbery.net> wrote:
> Mon, Nov 23, 2009 at 03:12:53PM -0600, Hailu Meng:
> > 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.
>
> i dont know; each pam implementation seems to be [at least] slightly
> different. seems silly to need kerberos for ldap.
>
> > 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.htmlto
> > > 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.
>
> add -d 32. -d x -d y ... will be logically OR'd together.
>
> > >> 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/4e65d4d2/attachment.html
More information about the tac_plus
mailing list