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: [email protected] mailRoutingAddress: [email protected] 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 [email protected] 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 <[email protected]> wrote: > --On Tuesday, February 22, 2011 5:52 PM -0500 Tim Dunphy > <[email protected]> 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
