Kevin Spicer wrote:
On Sun, 2004-11-21 at 01:11, Howard Chu wrote:
Sounds like a flaw in the ppolicy schema definition. You can work
around this by adding "NO-USER-MODIFICATION" to the definition of the operational attributes in ppolicy.c. (Seems counter-intuitive, but it
will work.)
Yes, I worked that out after I posted by reading the code. However what I couldn't work out is that although none of the operational attrs have "NO-USER-MODIFICATION" defined pwdFailureTime and pwdAccountLockedTime still manage to update. I think they are being updated using the rootdn (but I'm not familiar enough with the code to be sure), is there any reason why the other op attrs aren't updated using the rootdn instead of the users dn during a password update extended operation?
Yes.
The pwdReset attribute will only affect a normal LDAP client, because it only restricts subsequent LDAP operations. Since pam_ldap just does a Bind and nothing else, it has no effect. (And presumably pam_ldap doesn't check the response control for the Reset error code.) What I suggest instead is to create a second Policy entry that has a passwordMaxAge of 1 second (or somesuch) and set the user's policyDN to point to that entry, so you don't have to corrupt the pwdLastChanged value.My reason for not being keen on adding NO-USER-MODIFICATION into the schema is that I'm working around an issue with solaris's pam_ldap where the pwdReset attribute isn't honoured (when it is set users can login no problem) by allowing users in the sysadmin group to tweak the pwdLastChanged value to force a password change.
-- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support