[tac_plus] Re: Issue with Cisco switch authentication against Microsoft Active Directory
Jeroen Nijhof
jeroen at nijhofnet.nl
Tue Nov 24 15:19:37 UTC 2009
Hi Lou,
Check with 'getent passwd <username>' if you get the right user with
the right information from your AD via ldap.
If not then you should probably check your /etc/ldap.conf for the right
search scope and atrribute mappings.
Nss_ldap and pam_ldap uses the /etc/ldap.conf file so if it works with a
nss lookup via getent it should work for pam_ldap as well.
You can define a debug level as well in the /etc/ldap.conf file for
logging.
It's logging to /var/log/auth.log for me..
Regards,
Jeroen
Op 24/11/2009 schreef "Hailu Meng" <hailumeng at gmail.com>:
>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
>> >>
>> >>
>> >>
>>
More information about the tac_plus
mailing list