I suspect that once it has expired, it can't be used (it fails auth as it has expired - and can't be used to auth even to change password)

For that reason, I have password expiration warning set to a few seconds less than the password expiration time - although, as it returns '0' for the last 24 hours, they won't be warned then. :-/

You'll need to update the password with an account that has those privileges, and set whatever the setting is that requires users to reset their password now.

- chris

Chris Jacobs, Systems Administrator
Apollo Group | Apollo Marketing | Aptimus
2001 6th Ave Ste 3200 | Seattle, WA 98121
phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661
email: chris.jacobs@apollogrp.edu

From: openldap-technical-bounces@OpenLDAP.org <openldap-technical-bounces@OpenLDAP.org>
To: openldap-technical@openldap.org <openldap-technical@openldap.org>
Sent: Mon Jul 19 12:07:35 2010
Subject: Problems with slapd and access rules

 

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

 

 

 


This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.