Bug 4811 - no login possible if pass_last_set_time==0
Summary: no login possible if pass_last_set_time==0
Status: NEW
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Domain Control (show other bugs)
Version: 3.0.25b
Hardware: All All
: P3 major
Target Milestone: none
Assignee: Jim McDonough
QA Contact: Samba QA Contact
Depends on:
Reported: 2007-07-24 09:50 UTC by Peter Daum
Modified: 2007-07-25 07:57 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Peter Daum 2007-07-24 09:50:56 UTC
Around v 3.0.25 the follwowing change in auth/auth_sam.c:sam_account_ok()
was introduced:

@@ -170,3 +170,3 @@
                /* check for immediate expiry "must change at next logon" */
-               if (must_change_time == 0 && last_set_time != 0) {
+               if (last_set_time == 0) {
                        DEBUG(1,("sam_account_ok: Account for user '%s' password must change!.\n", pdb_get_username(sampass)));

On systems, that don't use the corresponding field in the account database
(LDAP: sambaPwdLastSet) which should be perfectly legal because the attribute
is not mandatory, this will keep all users from connecting to a samba server.
Windows clients will ask for a new password (but if the local setup does
not allow changing passwords that way, it won't do any good) and on other clients it probably won't work anyway

Furthermore it is pretty ugly that the attribute is not used in a way that
corresponds with its name (see Bug # 4682)
Comment 1 Gerald (Jerry) Carter (dead mail address) 2007-07-24 09:52:34 UTC
Jim, is this another result of the "Cannot change password" feature?
Comment 2 Jim McDonough 2007-07-24 14:25:08 UTC
I've got a few questions about this.  A couple of points, though: First, the old behavior was broken, since changing policy didn't change behavior, so making the password expiration time shorter didn't actually affect anything until someone changed a password, meaning that if a password time was ever set to infinite, those users would never again have to change passwords, despite the policy change.  Second, the declaration that fields are being misused and weren't before is jsut not valid.  Before, a 0 time of must change meant now, rather than 0 meaning it didn't have to change.  This is not any more logical.  I do agree that last_set_time of 0 is an odd way to say "change at next logon", but in this case, we are behaving as the MS SAM does.  All other times about password change are calculated from this one, and the case of 0 equates to "must change at next logon".  

However, in terms of the usage of this field in your case, I'm curious.  You're not setting passwords via windows or any samba code, so how are you changing them?  Is it possible to change the code that you use to properly fill out this field?  This is the way that the SAM is supposed to behave...you indicate when a password has been changed.  If you're using some samba code to change them and this field isn't getting updated, please point it out and I'd be happy to fix that.

Comment 3 Peter Daum 2007-07-25 06:20:31 UTC
Many (if not most) people use LDAP directories to store user accounts,
configuration data, and similar things not because it is somehow
technically superior, but because it is pretty much the only feasible
way to unify otherwise scattered information from different
applications and make them easier to maintain. Applications should
IMHO try to facilitate this and be aware that configuration data
stored this way might not be purely "private" anymore.

The samba LDAP schema declares only 2 Attributes as mandatory.
"sambaPwdLastSet" is one of a whole bunch of Attributes that are
(not only according to their names but also according to the
documentation) only relevant for things like password aging, so
it should be perfectly okay not to use them unless you actually
want this feature. So far this also has been the way that samba
handled this.

The really disastrous thing about this changed usage of
pass_last_set_time is not that the name is misleading, but that the
default value that is used if the attribute is missing also is 0,
(so far probably a good choice for a "neutral" default)  which now
effectitvely locks out people.

My suggestion would be to at least document this changed attribute
usage and use some innocuous default value ...
Comment 4 Jim McDonough 2007-07-25 07:57:24 UTC
Ok, very good point.  Let me take a look at changing how the ldap backend works, so that undefined doesn't equate to zero.  I think we really do want zero to mean 'must change now' so that we are operating as windows does, but explicitly set to zero could be different than undefined.