Hallvard B Furuseth wrote:

Howard Chu writes:

...

h.b.furuseth@usit.uio.no wrote:

...

Thanks. Applied a similar patch to cvs HEAD, after fixing a memory leak.

Reproducing the bug:

userPassword can exist without pwdChangedTime if you bypass
ppolicy: Use slapadd to add an entry with userPassword, or add
it to a subtree with no policy and then configure a policy.

Then set up ppolicy and use ldapmodify to delete userPassword.

In that case the correct fix is to skip the pwdChangedTime attribute completely.

Well, that's what this fix does in this particular code chunk: Don't try to delete pwdChangedTime if it isn't there.

...

The ppolicy spec says that entries without pwdChangedTime are not subject to password expiration at all.

Sounds like a different issue, but I don't see where it says that. What I did find is

8.2.7. Policy State Updates

If the value of either pwdMaxAge or pwdMinAge is non-zero, the server
updates the pwdChangedTime attribute on the entry to the current
time.

See the definition of pwdChangedTime, section 5.3.2:

5.3.2. pwdChangedTime

This attribute specifies the last time the entry's password was changed. This is used by the password expiration policy. If this attribute does not exist, the password will never expire.