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