On Windows Server, when using an "LDAP editor", pwdLastSet only accepts values of 0 and -1 (it cannot be manually set, even to a valid timestamp). 0 forces a password change and -1 is "auto-converted" into the current timestamp. Samba4 accepts 0, -1 or a valid timestamp, but does not "convert" the -1 into the current timestamp. When the attribute is set to -1, the account does not require a change, nor will the accout ever expire. This can be reproduced using the following steps (using RSAT): 1) Reset a user's password via RSAT and check "User must change..." pwdLastSet will be set to 0 2) Under this users's "Account" tab, uncheck "User must change..." pwdLastSet will be set to -1 At this point, the account will be allowed login and the password will never reach expiration. I set this to critical as it is a major security concern.
Are you able to change "pwdLastSet"s value with user permissions as well? The reason here is that the correct trigger in the s4 DSDB modules is missing.
Hello, I have completed some further testing on this issue: 1) I have verified that Windows 2008R2 behaves the same as Windows 2000 (it only accepts 0 and -1 when using an "LDAP editor"). A value of 0 is accepted and saved and a value of -1 is saved as the current timestamp. This appears to happen instantaneously as I save the value as -1, but my LDAP editor reports back with the current timestamp after the save operation is completed. It also behaves like W2K in that I cannot change the value from a timestamp to -1 without first setting the value to 0. Behavior also matches W2K when using ADUC, in that checking "user must change..." sets this attribute to 0 and unchecking it sets it to the current timestamp. When I do the same using ADUC and a Samba4 server, checking the box sets the value to 0 and unchecking it sets the value to -1. 2) As a normal user, I cannot alter this value via an LDAP Editor in W2K, W2K8R2 or Samba4.
Comment from Metze: https://bugzilla.samba.org/show_bug.cgi?id=9654 (pwdLastSet broken (allowing passwords that never expire) ) doesn't look to hard to fix, but we may be able to move this to 4.2 if it requires a more of work.
I would love to have this one fixed in 4.1.0. Is there a chance?
(In reply to comment #4) > I would love to have this one fixed in 4.1.0. > Is there a chance? ping
ping
Don't block 4.1.0, this is not a regression compared to 4.0.x
Any news on this one?
Nadya, can you help?
This is fixed in master and will be part of 4.5