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 [email protected] as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the
SUBJECT of the message.
