I am having problems with access control in slapd.conf.

 

If I leave all access control commented in slapd.conf, the ssh user can login and id works.

 

But if the users password expires though the use of the ppolicy directives, they are

prompted to change the password but cannot due to an Insufficient access error:

 

# ssh -l ldap1 localhost

ldap1@localhost's password:

You are required to change your LDAP password immediately.

Last login: Mon Jul 19 10:06:53 2010 from localhost

WARNING: Your password has expired.

You must change your password now and login again!

Changing password for user ldap1.

Enter login(LDAP) password:

New password:

Retype new password:

LDAP password information update failed: Insufficient access

passwd: Authentication token manipulation error

Connection to localhost closed.

 

These are the openldap components installed on the system:

 

# rpm -qa | grep ldap

compat-openldap-2.4.19_2.3.43-11.el6.i686

krb5-server-ldap-1.8.1-6.el6.i686

apr-util-ldap-1.3.9-3.el6.i686

mozldap-6.0.5-6.2.el6.i686

openldap-servers-2.4.19-11.el6.i686

python-ldap-2.3.10-1.el6.i686

openldap-clients-2.4.19-11.el6.i686

mozldap-devel-6.0.5-6.2.el6.i686

bind-dyndb-ldap-0.1.0-0.9.b.el6.i686

nss-pam-ldapd-0.7.5-3.el6.i686

pam_ldap-185-5.el6.i686

openldap-devel-2.4.19-11.el6.i686

openldap-2.4.19-11.el6.i686

 

 

This is a beta release of Red Hat Enterprise v6, but it would seem the Openldap components

should work regardless of the OS components.    I am working with this version of Red Hat

to get some experience with the V2.4* Openldap stream, realizing that this is not the latest

version of openldap.

 

I have tried various access control in slapd.conf that worked quite well in V2.3* of openldap

and released versions of Red Hat OS but any attempt to comment any of the follow lines

from slapd.conf, results in a complete failure of the ldap client to talk to the server.

 

#access to attrs=userPassword

#        by self write

#        by anonymous auth

#        by dn.base="cn=Manager,dc=osn,dc=cxo,dc=cpqcorp,dc=net" write

#        by * none

#        by * auth

 

I would like to understand the rules comfortably before moving to interactive rulesets

and slapd configuration so I am working with slapd.conf.

 

I have read through the attribute section of the v2.4 Admin guide and believe I understand

the concepts and syntax, but perhaps I am missing something.

 

I donf't know if Red Hat may have added something unique to this mix.   When you run their

authconfig utility to get a base set of ldap configuration attributes, it no longer updates

/etc/ldap.conf but instead it updates /etc/pam_ldap.conf.    It also attempts to configure

and start something called nslcd.conf and it's corresponding daemon, nslcd.

 

nslcd - local LDAP name service daemon.   This daemon has it's own configuration file which

looks just like the contents of ldap.conf.    If this daemon is not runing, it also appears

that the ldap service does not exist and id and ssh both fail.....id can't find the user and

ssh is denied login access as though the passwords are invalid.

 

I copied the contents of pam_ldap.conf to /etc/ldap.conf to see if that makes a difference:

 

/etc/ldap.conf:

base dc=osn,dc=cxo,dc=cpqcorp,dc=net

binddn cn=Manager,dc=osn,dc=cxo,dc=cpqcorp,dc=net

bindpw secret

ssl no

pam_lookup_policy yes

pam_password exop

uri ldap://16.112.240.253/

 

 

Is Red Hat doing something unique here ?   Have they bypassed the client's /etc/ldap.conf file

in favor of this new nslcd daemon and pam_ldap.conf file ?

 

Strings on pam_ldap.so does show a reference to /etc/pam_ldap.conf but nothing for /etc/ldap.conf

 

I've tried reading through the various README and other docs supplied with this stuff but

nothing seems to indicate a major change in how the ldap client accesses the ldap server

in this version of Red Hat.   Can anyone shed some light on this ?

 

Can I assume that generic openldap clients still expect to use /etc/ldap.conf as the one

and only ldap configuration file and nothing else ?

 

Al Licause