From owner-freebsd-questions@FreeBSD.ORG Thu Apr 23 16:09:27 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25F821065673 for ; Thu, 23 Apr 2009 16:09:27 +0000 (UTC) (envelope-from pckizer@nostrum.com) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by mx1.freebsd.org (Postfix) with ESMTP id E6B108FC19 for ; Thu, 23 Apr 2009 16:09:26 +0000 (UTC) (envelope-from pckizer@nostrum.com) Received: from [172.16.3.69] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3NG9PTZ008316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 23 Apr 2009 11:09:26 -0500 (CDT) (envelope-from pckizer@nostrum.com) Message-Id: <44093E53-7496-423C-AE76-F5BBEA07D346@nostrum.com> From: Philip Kizer To: freebsd-questions@freebsd.org In-Reply-To: <49F0813C.1050301@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 23 Apr 2009 11:09:24 -0500 References: <49E8EEF9.5090801@gmail.com> <49E96265.7050808@gmail.com> <49E9C4E1.6030908@gmail.com> <49F0813C.1050301@gmail.com> X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: Re: PAM-SSH-LDAP problem X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 16:09:27 -0000 You had said: O/H Panos =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5: > the strange thing is that the ldapsearch command gives me this: > ldapsearch -x -b 'ou=3Dusers,dc=3Dsomething,dc=3Dsomething,dc=3Dsomethin= g' =20 > '(&(objectClass=3D*)(uid=3Dldap_test))' > > # extended LDIF > # > # LDAPv3 > # base with = scope =20 > subtree > # filter: (&(objectClass=3D*)(uid=3Dldap_test)) > # requesting: ALL > > dn: cn=3Dldap_test,dc=3Dsomething,dc=3Dsomething,dc=3Dsomething > cn: ldap_test > [...] > gecos: ldap_test > homeDirectory: /home/ldap/ldap_test > loginShell: /bin/sh > [...] > uidNumber: 1003 > uid: ldap_test > gidNumber: 1000 > userPassword:: XXXXXX And then later: O/H Panos =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5: > I think I found what is the problem but I don't kow how to fix it. > from the error messages err=3D49 means that the password is wrong. > I'm sure that I type it correctly. > So I captured traffic using whireshark > > when the manager tires toy bind everything is normal and the bind is =20= > succeful. In the field authentication simple of the packet the =20 > password was the correct > but when ldap_test tries to bind the password that it send to ldap =20 > server is INCORECT (0000 08 0a 0d 7f 49 4e 43 4f 52 52 45 43 54 =20= > the hex field), so ldap server returns invalid credentials. > > I think that this is the problem but I don't have a clue how to =20 > solve it. > I can't understand why it sends an incorect password, and most =20 > important which of ssh, pam, pam_ldap has the problem. > > Any ideas? On 2009, Apr 23, at 09:54, Panos wrote: > Anyone????? With the "later" message where you say you found a message that the =20 bind attempt resulted in the password reported as "INCORRECT", I do =20 not see you describe how you initiated the BIND attempt, only that you =20= captured it with wireshark. When you login as "cn=3Dmanager,[...]" that you say works, is that via =20= ssh, or your admin tool you mentioned in a previous message, or more =20 directly using something like ldapsearch(1)? I highly recommend you test things from the ground-up to try and find =20= at which level the failure is occurring: network (already covered, you know you can talk to the LDAP = server =20 from the client you are testing) LDAP: Try performing the LDAP searches "manually" using =20 ldapsearch(1), more on that below Account: getent passwd ldap_test SSH: If those work, try more logging in the PAM or SSH layers For doing the direct LDAP test, you've already checked that the entry =20= is in your database: ldapsearch -x -b = 'ou=3Dusers,dc=3Dsomething,dc=3Dsomething,dc=3Dsomething' =20 '(&(objectClass=3D*)(uid=3Dldap_test))' next, make sure you can actually bind as that user: % ldapsearch -x -b = 'ou=3Dusers,dc=3Dsomething,dc=3Dsomething,dc=3Dsomething' -=20 D 'cn=3Dldap_test,dc=3Dsomething,dc=3Dsomething,dc=3Dsomething' -W =20 '(&(objectClass=3D*)(uid=3Dldap_test))' Enter LDAP Password: xxxxx [...] If that fails, bump up the logging on either the client and/or server =20= side of the LDAP server and see what clues you get from those logs. =20 If it works, move on to the next layer and see if it can properly =20 access the information you could get manually. -philip