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: [email protected] ________________________________ From: [email protected] <[email protected]> To: [email protected] <[email protected]> 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 ld...@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.
