Bug 9654 - pwdLastSet broken (allowing passwords that never expire)
Summary: pwdLastSet broken (allowing passwords that never expire)
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.0.0
Hardware: All All
: P5 critical (vote)
Target Milestone: ---
Assignee: Nadezhda Ivanova
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-12 13:41 UTC by Thomas Simmons
Modified: 2016-06-28 18:27 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Simmons 2013-02-12 13:41:42 UTC
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.
Comment 1 Matthias Dieter Wallnöfer 2013-02-13 08:55:05 UTC
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.
Comment 2 Thomas Simmons 2013-02-20 18:20:29 UTC
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 3 Karolin Seeger 2013-08-30 09:53:18 UTC
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.
Comment 4 Karolin Seeger 2013-09-06 09:21:14 UTC
I would love to have this one fixed in 4.1.0.
Is there a chance?
Comment 5 Karolin Seeger 2013-09-16 07:56:44 UTC
(In reply to comment #4)
> I would love to have this one fixed in 4.1.0.
> Is there a chance?

ping
Comment 6 Karolin Seeger 2013-09-19 08:28:24 UTC
ping
Comment 7 Karolin Seeger 2013-09-20 07:12:33 UTC
ping
Comment 8 Stefan Metzmacher 2013-09-27 07:59:29 UTC
Don't block 4.1.0, this is not a regression compared to 4.0.x
Comment 9 Karolin Seeger 2013-12-10 15:48:42 UTC
Any news on this one?
Comment 10 Andreas Schneider 2014-10-28 10:52:15 UTC
Nadya, can you help?
Comment 11 Stefan Metzmacher 2016-06-28 18:27:08 UTC
This is fixed in master and will be part of 4.5