Re: openldap problems authenticating

[Tim Dunphy <bluethundr@gmail.com>]

Hey guys

I took Quanah's advice and put the clear text password into
/etc/lapd.conf on the client.

I also noticed that the user account it was looking for was of a
posixAccount class. And I was missing the nis.shema. So I added
nis.schema to slapd.conf and restarted slapd and I was seeing the same
pattern. ldapsearches on the client were working just as they were
before and getents on the client were not. But I was seeing a new
error in the logs at this point:

Feb 23 01:16:45 LBSD2 slapd[52517]: conn=1471 op=1 SRCH
base="ou=staff,dc=summitnjhome,dc=com" scope=2 deref=0
filter="(objectClass=posixAccount)"
Feb 23 01:16:45 LBSD2 slapd[52517]: conn=1471 op=1 SRCH attr=uid
userPassword uidNumber gidNumber cn homeDirectory loginShell gecos
description objectClass
Feb 23 01:16:45 LBSD2 slapd[52517]: conn=1471 op=1 SEARCH RESULT
tag=101 err=32 nentries=0 text=
Feb 23 01:16:45 LBSD2 slapd[52517]: daemon: activity on 1 descriptor
Feb 23 01:16:45 LBSD2 slapd[52517]: daemon: activity on:
Feb 23 01:16:45 LBSD2 slapd[52517]:  12r
Feb 23 01:16:45 LBSD2 slapd[52517]:
Feb 23 01:16:45 LBSD2 slapd[52517]: daemon: read activity on 12
Feb 23 01:16:45 LBSD2 slapd[52517]: daemon: select: listen=6
active_threads=0 tvp=NULL
Feb 23 01:16:45 LBSD2 slapd[52517]: daemon: select: listen=7
active_threads=0 tvp=NULL
Feb 23 01:16:45 LBSD2 slapd[52517]: connection_read(12): input
error=-2 id=1471, closing.
Feb 23 01:16:45 LBSD2 slapd[52517]: connection_closing: readying
conn=1471 sd=12 for close
Feb 23 01:16:45 LBSD2 slapd[52517]: daemon: activity on 1 descriptor
Feb 23 01:16:45 LBSD2 slapd[52517]: daemon: waked
Feb 23 01:16:45 LBSD2 slapd[52517]: daemon: select: listen=6
active_threads=0 tvp=NULL
Feb 23 01:16:45 LBSD2 slapd[52517]: daemon: select: listen=7
active_threads=0 tvp=NULL
Feb 23 01:16:45 LBSD2 slapd[52517]: daemon: removing 12

Which from what I've googled means basically "object not found".

Now just to clarify a point of possible confusion... my user accounts
are unix posixAccounts that were migrated using the padl tools. Here's
what one of the user accounts looks like:

43 uid=bluethundr,cn=summitnjops,ou=staff,ou=Group,dc=summitnjhome,dc=com
uid: bluethundr
cn: Timothy P. Dunphy
givenName: Timothy P.
sn: Dunphy
mail: bluethundr@gmail.com
mailRoutingAddress: bluethundr@mail.summitnjhome.com
mailHost: mail.summitnjhome.com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: inetLocalMailRecipient
objectClass: ldapPublicKey
uidNumber: 1001
gidNumber: 10000
homeDirectory: /home/bluethundr
gecos: Timothy Dunphy
loginShell: /bin/bash
sshPublicKey: ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQDQ0zYn6FhQ1lKnvQ1K1GbXh8hdsXlXnnUYjLcNUqv7uMjjy0xDv03bnPU0Iyl1HcQcVFYPgcjB7mo3FZjZHd9bsHRwnY688FjPv/xE78+B
M8aDTuzb6czVA1X9ztc6Y6eNGYy1U4b3dseVFS+L2APkjaV5/RYPRH4mxJ8aNnrf+APaZvjtwPPEnxZST58QYdwtBvalLbgpDRTmGHrSEP2bJvUSR+iS3zC9xp90R0hFSVjd6jauXcxhkFLyG0nnmjc5sS5271
uxsXTfVFC1bHBasXL5ITFS63SpZErDWIVNwfVoR2tentddD6qJFd5ewTojRFDua3iqU4EJUl80RjmF
bluethundr@LCENT01.summitnjhome.com
sshPublicKey: ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQDlhRvFkT6wUAR3jw2h2Z0KV2/WsHPFkuXBD1BgzOQfR+PFhZDnt/zp44cLGwxa55RKEtFC+n/sjgmj99hKbn+0pPlGUGDuGqmWtMG45s+S
oDm9pRd8uzFccNYDLQ3POhfD2EbOarR45m7X42r821YO3ZeWnn3E1rCHarXrHXFX13sp9Jh8htNlWBCEjvs37S8VC9v5XW95BY8rhqrDGJrobmzDplUlHjgYjyBWx/BQxxgvmqQfKyS8i26+IelHcqRT5cgCSU
bFlPR3ouVu8eAgIE6gwKTuElIaTwJQ4QjBlaGaohEQRei0FWsfb7EzH1ikE34gJTdoaSnozU9MWc+f
tim@dunphy
userPassword: {CRYPT}crHJs4YTxefJE

I am trying to search the directory using the pam_ldap account which
is an inetOrgPerson account and looks like this:

3 cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com
cn: pam_ldap
objectClass: top
objectClass: inetOrgPerson
sn: PAM
userPassword: {SSHA}Cbk8VNyWQsXNmqt6n9GYDRcR0cnuA2sJ


This command does find the bluethundr account:

ldapsearch -xH 'ldap://LBSD2.summitnjhome.com' -D
'cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com' -w 'secret' -b
'dc=summitnjhome,dc=com' '(uid=bluethundr)'

(currently I'm not using TLS until I get this mess sorted out)

And I am using this /etc/ldap.conf on the client which as I've
mentioned is centos 5.5

host 192.168.1.44
base ou=staff,ou=Group,dc=summitnjhome,dc=com
sudoers_base ou=staff,ou=Group,dc=summitnjhome,dc=com
binddn cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com
bindpw secret
scope sub
pam_password exop
nss_base_passwd ou=staff,dc=summitnjhome,dc=com
nss_base_shadow ou=staff,dc=summitnjhome,dc=com



I am definitely looking forward to an end to this vexing situation.
But once again let me state that I genuinely appreciate any time and
input you may be able to provide.



On Tue, Feb 22, 2011 at 6:02 PM, Quanah Gibson-Mount <quanah@zimbra.com> wrote:
> --On Tuesday, February 22, 2011 5:52 PM -0500 Tim Dunphy
> <bluethundr@gmail.com> wrote:
>
>> Hello list,
>>
>> I am running an openldap 2.4 server under FreeBSD that was working
>> well until the config was tweaked by someone on the team without
>> properly documenting their work
>
>> bindpw {crypt}secret
>
> A few things:
>
> a) Crypt is non-portable
> b) That doesn't look like a valid crypt'd password
> c) You're going to need to set a plain text password to bind, regardless
>
> Try just changing "bindpw" to be "secret" and see what happens.  If you want
> better security, use SASL/EXTERNAL or SASL/GSSAPI etc.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> --------------------
> Zimbra ::  the leader in open source messaging and collaboration
>



-- 
GPG me!!

gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B