Samba "max password age" policy behavior does not match NT

[John P Janosik]

We have discovered at our site that changing the Samba "max password age"
policy does not take effect immediately but instead a "password must change
time" for each account is calculated based on the policy at password change
time.  This is not the same behavior as NT and will be a problem for sites
who want to decrease the "max password age" in a domain and don't realize
the difference.  I have opened a bugzilla and attached a patch:

       https://bugzilla.samba.org/show_bug.cgi?id=2958

Current behavior:

Samba stores 0 for "password must change time" to implement the "force
password change at next logon" option in user manager on NT.  Otherwise
Samba stores the time the password must change calculated based on the
password last changed time and the current account policy.  This means it
is possible for administrators to override the policy on an account by
account basis until the account password has changed.

With the patch:

I have moved the calculation of "password must change time" to the
functions that pull the current value from the passdb backend.  In the
backend 0 is stored to mean "force password change at next logon" but when
retrieved the "password must change time" is set to the "password last set
time" to force an expired password.  If the "password must change time"
attribute in the passdb is non-0 then the value is set to the "last
password change time" + "max password age" policy setting.

I would like comments on this change.  I don't see being able to set the
"password must change time" on an account by account basis useful as
currently implemented since it will be wiped out each time the password on
the account is changed.  I think most admins will expect Samba to match NT
behavior and will be surprised as I was when they realize the account
policy change didn't take effect immediately.

One thing I still need to look at in this patch is how Samba implements the
"password never expires" setting on each account.  I'm guessing it probably
is setting "password must change time" to the max unix time so I still need
to address that in my patch.



John Janosik
IBM Global Services Unix & Intel Servers
Rochester, MN
jpjanosi at us.ibm.com