LDAP authentication using PAM between 2 Ubuntu machines

[Damon Getsman]

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

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

# 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

#######################################################################
# 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
-------------------------------------------------------------------------------------------------------------------------
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>
--- You are currently subscribed to ldap@... as: [lists@...] To unsubscribe send email to ldap-request@... with the word UNSUBSCRIBE as the SUBJECT of the message.

[Gavin Henry]

> 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.
>

-x     Use simple authentication instead of SASL.

your rootdn by passes all ACLs btw, so much of your "write" statements
are useless.

run slapd -d 128 for testing your acls.


--
Kind Regards,

Gavin Henry.
Managing Director.

T [phone]
M [phone]
F [phone]
E ghenry@...

Open Source. Open Solutions(tm).

http://www.suretecsystems.com/

Suretec Systems is a limited company registered in Scotland. Registered
number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie,
Aberdeenshire, AB51 4FP.

---
You are currently subscribed to ldap@... as: [lists@...]
To unsubscribe send email to ldap-request@... with the word UNSUBSCRIBE as the SUBJECT of the message.