I am running OpenLDAP as packaged for CentOS 5 and having problems with password expiration. Users are being told every time they login that their password has expired and to change their password. When ShadowMax is changed to 99999 their passwords are not expiring. The preferable setting is 90 days. ShadowLastChange is updating to the correct date when they input a new password. Thank you for you time and input as to why this might be occurring.
Hi Cris,
On 27/03/12 00:46, Collins, Cris L. wrote:
I am running OpenLDAP as packaged for CentOS 5 and having problems with password expiration. Users are being told every time they login that their password has expired and to change their password. When ShadowMax is changed to 99999 their passwords are not expiring. The preferable setting is 90 days. ShadowLastChange is updating to the correct date when they input a new password. Thank you for you time and input as to why this might be occurring.
shadow attributes are used by UNIX systems during authentication, depending on your system configuration (PAM, pam_ldap, login.defs...)
However, the OpenLDAP server itself will not use these attributes to prevent binds by LDAP, which is what I understand you expect. For this, check out the ppolicy overlay.
Jonathan
The problem was resolved by adding the following per the nis schema. My statement below was incorrect. shadowLastChange was not updating, as "getent shadow username" showed me.
access to attrs=shadowLastChange,shadowMax by dn="cn=Manager,dc=domain,dc=com" write by self write by * read
Thank you for your response.
On 04/03/2012 12:43 PM, Jonathan Clarke wrote:
Hi Cris,
On 27/03/12 00:46, Collins, Cris L. wrote:
I am running OpenLDAP as packaged for CentOS 5 and having problems with password expiration. Users are being told every time they login that their password has expired and to change their password. When ShadowMax is changed to 99999 their passwords are not expiring. The preferable setting is 90 days. ShadowLastChange is updating to the correct date when they input a new password. Thank you for you time and input as to why this might be occurring.
shadow attributes are used by UNIX systems during authentication, depending on your system configuration (PAM, pam_ldap, login.defs...)
However, the OpenLDAP server itself will not use these attributes to prevent binds by LDAP, which is what I understand you expect. For this, check out the ppolicy overlay.
Jonathan
On Tuesday, 3 April 2012 23:16:43 Collins, Cris wrote:
The problem was resolved by adding the following per the nis schema. My statement below was incorrect. shadowLastChange was not updating, as "getent shadow username" showed me.
access to attrs=shadowLastChange,shadowMax by dn="cn=Manager,dc=domain,dc=com" write by self write by * read
Thank you for your response.
Yes, it will work, for applications that look for shadowAccount attributes.
My approach is to remove ldap from the shadow line of nsswitch.conf, configure ppolicy on the LDAP server, and ensure PAM is setup correctly to enforce password expiration via ppolicy.
Then, even if users never login to a shell on a server configured for LDAP, they will be locked out of all other LDAP-using services (except for WiFi access points via FreeRADIUS EAP PEAP with MSCHAPv2 against samba attributes, since even if the samba attributes are updated, FreeRADIUS doesn't currently seem to respect them).
Regards, Buchan
openldap-technical@openldap.org
-
Buchan Milne -
Collins, Cris -
Collins, Cris L.
-
Jonathan Clarke