[SOLVED] Does OpenLDAP / NSS / PAM produce logs of failed login attempts?

peridian · 02-16-2011, 04:48 PM

Hi,

I am trying to get OpenLDAP to authenticate user logins, but running around in circles. Are there any logs produced by either client and/or server that would indicate possible reasons why it was unable to login as a user?

Below is an explanation, any ideas would be appreciated, as I think everything is setup as per the various articles on using LDAP.

---

I have a CentOS 5.5 OpenLDAP server, and several others, some host services, some are file shares (samba).

So far I have been able to successfully configure OpenLDAP to carry out all the ldap* commands from both the local server and from any of the remote servers, either via non-ssl or ssl connections. However, as soon as I try connecting any services up to it, it doesn't play ball.

Back to basics, having cleared off all previous attempts at this from all machines, I have gone through the following:

Installed OpenLDAP server/client on host (plus nss_ldap).
Configured /etc/openldap/slapd.conf (see below)
Configured /etc/openldap/ldap.conf (see below)
Configured /etc/ldap.conf (see below)
Configured /etc/sysconfig/iptables (see below)
Started up ldap service.
Ran ldapadd to input .ldif file to set up initial directory (see below)
Ran ldappasswd to set password for testuser entry.
Tested directory load with ldapsearch using both the admin and testuser accounts. Data returned okay on both LDAP server plus another machine.
Ran authconfig-tui to configure use of LDAP for login (same machine as LDAP is on).
Rechecked the above .conf files for any changes, plus /etc/nsswitch.conf (see below).
Checked /etc/pam.d/system-auth (see below) *** I think this is the step where it is not working.
Started nscd service (not sure this is needed) and restarted the server.
Tested logging in via local console as LDAP user - Msg: Login incorrect.
Tested logging in via ssh as LDAP user - Msg: Access denied.
Tested logging in via either with local account - Result: Fine.
Changed order in /etc/nsswitch.conf from 'files ldap' to 'ldap files'.
Definite delay occurs after typing in password, even for local user account, suggesting that it is attempting communication before failing over.

/etc/openldap/slapd.conf:

Code:

include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema
include         /etc/openldap/schema/samba.schema

allow bind_v2

pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args

access to attrs=userPassword,sambaLMPassword,sambaNTPassword
        by self write
        by anonymous auth
        by * none
access to *
        by self write
        by users read
        by anonymous auth

database        bdb
suffix          "dc=intbus,dc=net"
rootdn          "cn=admin,dc=intbus,dc=net"
rootpw          {SSHA}<crypto removed>

directory       /var/lib/ldap

index objectClass                       eq,pres
index ou,cn,mail,surname,givenname      eq,pres,sub
index uidNumber,gidNumber,loginShell    eq,pres
index uid,memberUid                     eq,pres,sub
index nisMapName,nisMapEntry            eq,pres,sub

/etc/openldap/ldap.conf:

Code:

# Tried the below line with and without the port number
URI ldap://intbus.net:389/
BASE dc=intbus,dc=net
TLS_CACERTDIR /etc/openldap/cacerts

/etc/ldap.conf:

Code:

base dc=intbus,dc=net
# Tried the below line with and without the port number
uri ldap://intbus.net:389/
timelimit 120
bind_timelimit 120
idle_timelimit 3600
pam_filter objectclass=posixAccount
nss_base_passwd ou=Users,dc=intbus,dc=net?one
nss_base_shadow ou=Users,dc=intbus,dc=net?one
nss_base_group  ou=Groups,dc=intbus,dc=net?one
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
ssl no
tls_cacertdir /etc/openldap/cacerts
pam_password md5

/etc/sysconfig/iptables:

Code:

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 389 -s 192.168.1.0/24 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 636 -s 192.168.1.0/24 -j ACCEPT

.ldif file:

Code:

# Domain
dn: dc=intbus,dc=net
objectClass: domain
dc: intbus
description: Home domain.

# Units
dn: ou=Users,dc=intbus,dc=net
objectClass: organizationalUnit
ou: Users
description: User group.

dn: ou=Groups,dc=intbus,dc=net
objectClass: organizationalUnit
ou: Groups
description: Domain groups.

#Groups
dn: cn=sambagroup,ou=Groups,dc=intbus,dc=net
objectClass: posixGroup
cn: sambagroup
gidNumber: 3001
description: Samba file share group.

dn: cn=jiragroup,ou=Groups,dc=intbus,dc=net
objectClass: posixGroup
cn: jiragroup
gidNumber: 3002
description: Jira user group.

#Test Data
dn: cn=testGroup,ou=Groups,dc=intbus,dc=net
objectClass: posixGroup
cn: testGroup
gidNumber: 9998

dn: uid=testuser,ou=Users,dc=intbus,dc=net
objectClass: posixAccount
objectClass: person
uid: testuser
cn: testuser
sn: testuser
uidnumber: 9999
gidNumber: 9998
homedirectory: /home/testuser

/etc/pam.d/system-auth:

Code:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_ldap.so

/etc/nsswitch.conf:

Code:

passwd:     files ldap
shadow:     files ldap
group:      files ldap

hosts:      files dns

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files

netgroup:   files ldap

publickey:  nisplus

automount:  files ldap
aliases:    files nisplus

acid_kewpie · 02-16-2011, 04:56 PM

ok, well the closest part to the user login attempt is /var/log/secure on the server in question, this is pam's output, not ldaps so covers the generic act of logging in. Or not. On the ldap side, then you should have /var/log/ldap or something similar on the ldap server, although tbh I needed to add a syslog entry for local4.* to tell it to write to the ldap log file (nothing else on my servers use local4, and it's slapd's default so works fine...) In there you'd then be able to see all communications, and you've got two "normal" error codes to look for on a bind attempt for authentication purposes, err=49 which is "invalid credentials" which principally means a wrong password, but also covers expired ones and a few other subtleties, and also err=19 which is "constraint violation" which is locked out accounts from successive failed attempts etc. Plenty of other reasons, e.g. broken / malformed accounts etc, but those two are from my experience, the main user level codes. Also in terms of troubleshooting, wireshark is so so useful to capture the network traffic (disable TLS / SSL temporarily first) so you can actually see the full breakdown of the comms between client and ldap server, which can shed huge amounts of information too. A further demarcation thang is to ensure that "getent passwd" also works for user information. It's no good giving the right password if the system doens't even know the account exists, and that's directly using nsswitch.conf and /etc/ldap.conf and (afaik) nothing else significant at all, so can easily help localise an issue.

peridian · 02-17-2011, 03:51 PM

Thanks a lot, that pointed me exactly where I needed.

A bit of trial and error, some research, and I got it working.

The problem was that I had not specified a rootbinddn (despite some articles saying it is not required). My previous attempts to add a rootbinddn had failed because I had left out the ou=Users part of the dn, or at one point because I had reset the ldif file entries without setting the password.

Onwards and upwards... hopefully.

Cheers,
Rob.