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.
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?
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