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)
Jim, is this another result of the "Cannot change password" feature?
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.
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 ...
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.