LDAP authentication using PAM between 2 Ubuntu machines

Okay, so last week I finally got authentication to work between two
Ubuntu virtual machines through LDAP. I accomplished this with the
PADL_migrationtools package, had to edit a few of the .ldifs by hand
so that the server would accept them (removing kerberos items and the
like). It still didn't work which drove me up a wall until a helpful
soul on #ldap on freenet mentioned that nscd might be running and
messing things up (which was precisely the case). So I was pretty
elated, being as I'd been working over getting this to work for so
long.

After this I wiped the ldap database and started using the PADL
migrationtools again on the actual server cluster that we need to use
the authentication data from. Again, I had to tweak it a little bit
by hand, but managed to get it all accepted by the ldap server without
too much trouble.

When I started testing the new directory, I first realized that
nothing was working correctly because I had lost the 'admin' account
when I wiped the previous database and never made a new one. So, I
got that fixed. However I was still having issues authenticating as
the ldap admin, using ldapsearch to try to verify that the data was
correctly being served. After some further testing I realized that I
can authenticate properly when using ldapsearch with the -x flag, but
not in the standard manner.

At this point I'm starting to wonder what on earth must've changed. I
didn't tweak any of the configuration files for slapd on the server or
for openldap on either machine. All of the /etc/pam.d files are in
the same configuration that was working for me previously. TLS
configuration is the same with the proper certs in the right areas...
All of these things I confirmed by successful authentication through
pam using ssh and login previously. On the client machine getent
passwd is showing the correct information and as root, getent shadow
is showing all of the information as well. Still, I cannot bind
without the -x with ldapsearch; I can't even run the search
anonymously without the -x. The errors that I am receiving in these
cases are:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-13): user not found: no secret in
database

Why, when ldap is serving the data properly, is it all of a sudden
complaining about SASL? I really do not want to implement SASL until
I understand it, anyway.

The errors I'm receiving from pam when trying to login using pam_ldap
(taken from /var/log/auth.log) are:
May 14 16:52:18 URtr login[4322]: pam_unix(login:auth): authentication
failure; logname=dgetsman uid=0 euid=0 tty=tty2 ruser= rhost=
user=dgetsman
May 14 16:52:18 URtr login[4322]: pam_ldap: ldap_search_s No such
object
May 14 16:52:20 URtr login[4322]: FAILED LOGIN (1) on 'tty2' FOR
`dgetsman', Authentication failure

(configuration files to follow)

Here is my slapd.conf:
# This is the main slapd configuration file. See slapd.conf(5) for
more
# info on the configuration options.

################################################## #####################
# Global Directives:

# Features to permit
#allow bind_v2

# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema

# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile /var/run/slapd/slapd.pid

# List of arguments that were passed to the server
argsfile /var/run/slapd/slapd.args

# Read slapd.conf(5) for possible values
loglevel 0

## TLS options for slapd
TLSCipherSuite HIGH
TLSCertificateFile /etc/ldap/servercrt.pem
TLSCertificateKeyFile /etc/ldap/serverkey.pem
TLSCACertificateFile /etc/ldap/cacert.pem

#test
idassert-bind bindmethod=none

# Where the dynamically loaded modules are stored
modulepath /usr/lib/ldap
moduleload back_bdb

# The maximum number of entries that is returned for a search
operation
sizelimit 500

# The tool-threads parameter sets the actual amount of cpu's that is
used
# for indexing.
tool-threads 1

################################################## #####################
# Specific Backend Directives for bdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend bdb
checkpoint 512 30

################################################## #####################
# Specific Backend Directives for 'other':
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
#backend <other>

################################################## #####################
# Specific Directives for database #1, of type bdb:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database bdb

# The base of your directory in database #1
suffix "dc=ouah,dc=net"

# rootdn directive for specifying a superuser on the database. This is
needed
# for syncrepl.
# rootdn "cn=admin,dc=ouah,dc=net"
rootdn "cn=admin,dc=ouah,dc=net"
rootpw {SSHA}*snip*

# Where the database file are physically stored for database #1
directory "/var/lib/ldap"

# For the Debian package we use 2MB as default but be sure to update
this
# value if you have plenty of RAM
dbconfig set_cachesize 0 2097152 0

# Sven Hartge reported that he had to set this value incredibly high
# to get slapd running at all. See http://bugs.debian.org/303057
# for more information.

# Number of objects that can be locked at the same time.
dbconfig set_lk_max_objects 1500
# Number of locks (both requested and granted)
dbconfig set_lk_max_locks 1500

# Indexing options for database #1
index objectClass eq
index cn,sn,mail pres,eq #added by Damon

# Save the time that the entry gets modified, for database #1
lastmod on

(more to follow)

(slapd.conf continues)
# Where to store the replica logs for database #1
# replogfile /var/lib/ldap/replog

# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
access to attrs=userPassword,shadowLastChange
by dn="cn=admin,dc=ouah,dc=net" write
by anonymous auth
by self write
by * none

# Ensure read access to the base for things like
# supportedSASLMechanisms. Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work
# happily.
access to dn.base="" by * read

# The admin dn has full write access, everyone else
# can read everything.
access to *
by dn="cn=admin,dc=ouah,dc=net" write
by * read

# For Netscape Roaming support, each user gets a roaming
# profile for which they have write access to
#access to dn=".*,ou=Roaming,o=morsnet"
# by dn="cn=admin,dc=ouah,dc=net" write
# by dnattr=owner write

(more to follow-this max posting length is ridiculous)

(slapd.conf continued)

################################################## #####################
# Specific Directives for database #2, of type 'other' (can be bdb
too):
# Database specific directives apply to this databasse until another
# 'database' directive occurs
#database <other>

# The base of your directory for database #2
#suffix "dc=debian,dc=org"

------------------------------------------------------------------------------------------------------------------------
And here is my ldap.conf:
host kerb-ldap.ouah.net
base dc=ouah,dc=net
scope sub
suffix "dc=ouah,dc=net"



## when you want to change user's password by root
rootbinddn cn=admin,dc=ouah,dc=net

#uri ldap://192.168.1.168/

## there are needed when your ldap dies
timelimit 5
bind_timelimit 5

##cacert for the host location
TLS_CACERT /etc/ldap/cacert.pem

#disable SASL, por dios
sasl_secprops maxssf=0

#uri ldapi://192.168.1.168/
pam_password md5

ldap_version 3
pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_member_attribute memberuid

nss_base_passwd ou=Computers,dc=ouah,dc=net
nss_base_passwd ou=People,dc=ouah,dc=net
nss_base_shadow ou=People,dc=ouah,dc=net
nss_base_group ou=Group,dc=ouah,dc=net
nss_base_hosts ou=Hosts,dc=ouah,dc=net

(1 more to follow)

-------------------------------------------------------------------------------------------------------------------------
And last, but not least, all of the files in my pam.d directory are
loaded with:
auth required pam_env.so
auth sufficient pam_unix.so likeauth nullok
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so

account sufficient pam_unix.so
account sufficient pam_ldap.so
account required pam_ldap.so

password required pam_cracklib.so difok=2 minlen=8 dcredit=2
ocredit=2 retry=3
password sufficient pam_unix.so nullok md5 shadow use_authtok
password sufficient pam_ldap.so use_first_pass
password required pam_deny.so

session required pam_limits.so
session required pam_unix.so
session optional pam_ldap.so
-------------------------------------------------------------------------------------------------------------------------

All of this was working for me just fine before, but now I just can't
bind without that -x on the command line utilities, and when I login
on the machine, I can't do it if it's trying to get the shadowed
password information from ldap. Everything else is handled correctly,
but looking for that one particular entry it will not take it through
ldap, only from the files...

I would really appreciate if somebody could clue me in a little bit
more about why this is all of a sudden trying to use SASL, how I can
disable it, and how I can resume binding again so that I can get those
shadowed passwords served so that I can start authenticating with this
non-testing data now. I'm not having any luck finding documentation
on this as of right now.

Thanks in advance!

<a href="http://www.unixadmintalk.com/f5/">
-Damon A. Getsman
Linux/Solaris Sysadmin
</a>