[tac_plus] Re: Issue with Cisco switch authentication against Microsoft Active Directory
Hailu Meng
hailumeng at gmail.com
Tue Nov 24 13:22:11 UTC 2009
Hi Jeroen,
I see the packets sent back from AD for the search request have 4 attributes
included:
objectclass
cn
description
sAMAccountName
And these attributes values are correct. sAMAccountName is my login user id.
cn is my Full Name, objectclass is 4 items (top, person,
organizationalperson , user)
I'm not sure is it enough for PAM to go to the next step? But it did give us
error message "Unknown User". I observed that when I input the password in
my router and hit ENTER, my wireshark captured two search requests from
TACACS and two responses from AD. Same contents as the previous one when I
input my user name in the router. I'm not sure is that possible that TACACS
didn't find the information it wants from AD although AD respond something
(4 attributes values)
By the way, I can't find any log information about PAM. I think it should be
in /var/log/secure. But nothing in this file. Do you know how to find these
log or turn it on?
Thanks for the help.
Lou
On Tue, Nov 24, 2009 at 4:11 AM, Jeroen Nijhof <jeroen at nijhofnet.nl> wrote:
>
> Hi Lou,
>
> Yes, most server application's check if a user exist by looking up the
> uid via nss before doing any authentication (i.e. sshd).
>
> Regards,
> Jeroen
>
> Op 23/11/2009 schreef "Hailu Meng" <hailumeng at gmail.com>:
>
> >Hi Jeroen,
> >
> >Thanks for helping. I modified the nssswitch.conf as below:
> >passwd: files ldap
> >shadow: files ldap
> >group: files ldap
> >
> >And leave the other settings as default.
> >
> >the user attributes you are talking about are the attributes retrieving
> from
> >AD? I do see the packets from AD server told my tacacs+ server the user
> >attributes including homedir.
> >
> >Thanks.
> >
> >Lou
> >
> >
> >On Mon, Nov 23, 2009 at 4:45 PM, Jeroen Nijhof <jeroen at nijhofnet.nl>
> wrote:
> >
> >> Hi,
> >>
> >> Did you setup the nsswitch.conf as well on your tac_plus server?
> >> Your tac_plus server needs to lookup the user attributes like homedir
> >> etc, otherwise pam will fail.
> >>
> >> Regards,
> >> Jeroen Nijhof
> >>
> >> On Mon, 2009-11-23 at 15:28 -0600, Hailu Meng wrote:
> >> > 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
> >> > _______________________________________________
> >> > 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/20091124/731c29b6/attachment.html
More information about the tac_plus
mailing list