Hello,
I've configured a RHEL3 as LDAP client to my FedoraDS 1.0.2 on RHEL4. When I login via ssh with an LDAP account on the ldapclient I immediately get You are required to change your password immediately (password aged) Your password has expired, the session cannot proceed. You must change your password now and login again!
After that I change the password and login again and I get the same error again. Any idea what's causing this? Is it an ACL that's preventing some attributes to be updates? Which attributes? If I just for testing delete these attributes I should get rid of this message, shouldn't I?
Thanks in advance, Jo
I've configured a RHEL3 as LDAP client to my FedoraDS 1.0.2 on RHEL4. When I login via ssh with an LDAP account on the ldapclient I immediately get You are required to change your password immediately (password aged) Your password has expired, the session cannot proceed. You must change your password now and login again!
After that I change the password and login again and I get the same error again. Any idea what's causing this? Is it an ACL that's preventing some attributes to be updates? Which attributes? If I just for testing delete these attributes I should get rid of this message, shouldn't I?
Assuming you're using shadowAccount attributes for your password expiry, you are seeing just what I saw until "write for self" access was given to users to up the shadowLastChange attribute. Here's how I fixed it in admin console.
In Directory tab, select root domain
Right click and select "Set Access Permissions"
Select "Enable self-write for common attributes" and click on Edit
After "userPassword", insert "|| shadowLastChange " and click on OK and again on OK on the parent window.
On Tue, 2006-12-05 at 12:28 -0500, Kyle Tucker wrote:
Assuming you're using shadowAccount attributes for your password expiry, you are seeing just what I saw until "write for self" access was given to users to up the shadowLastChange attribute. Here's how I fixed it in admin console.
In Directory tab, select root domain
Right click and select "Set Access Permissions"
Select "Enable self-write for common attributes" and click on Edit
After "userPassword", insert "|| shadowLastChange " and click on OK and again on OK on the parent window.
The problem we had with using the shadow attributes is that not all platforms honor them (I don't recall seeing Solaris update shadowLastChange). You'd also need to remember to update the shadowLastChange attribute manually if you reset a user's password by some mechanism outside of PAM (from the Administrator's Console, for example).
-Steve
After "userPassword", insert "|| shadowLastChange " and click on OK and again on OK on the parent window.
The problem we had with using the shadow attributes is that not all platforms honor them (I don't recall seeing Solaris update shadowLastChange).
Well that's unsettling. I'd have thought the nss_ldap would provide adherence to RFC2307, where I believe shadowAccount to be outlined, across platforms. And I'd have thought Solaris to support it foremost. My implementations have been all Linux, but I know what I am going to test next.
You'd also need to remember to update the shadowLastChange attribute manually if you reset a user's password by some mechanism outside of PAM (from the Administrator's Console, for example).
Yes, I set this to today's date in my management scripts for command line account maintenance.
FWIW, these scripts, and their templates, are here if anyone finds any use for them.
http://www.panix.com/~kylet/ldap
On Tue, 2006-12-05 at 13:31 -0500, Kyle Tucker wrote:
The problem we had with using the shadow attributes is that not all platforms honor them (I don't recall seeing Solaris update shadowLastChange).
Well that's unsettling. I'd have thought the nss_ldap would provide adherence to RFC2307, where I believe shadowAccount to be outlined, across platforms. And I'd have thought Solaris to support it foremost. My implementations have been all Linux, but I know what I am going to test next.
I was testing in conjunction with password policies enforced by the directory since I don't consider using the shadow attributes a full- proof means of handling password aging (nothing to stop the user from updating shadowLastChange if they don't feel like changing their password every x days). IIRC, Solaris wanted every account to be a shadowAccount, but it didn't seem to care about any of the values that shadow provides. Maybe it ignores shadow if their is a password policy in place...
All of the platforms I've tested (RHEL 3, RHEL 4, Solaris 8/9, and Irix) were happy with the password policies enforced by the directory.
-Steve
389-users@lists.fedoraproject.org
-
Jo De Troy -
Kyle Tucker -
Steve Rigler