On 01/05/2017 04:00 PM, William Brown wrote:
I feel like I must be missing something, because this makes *no* sense
at all. When a search is performed, shadowExpire will reflect the
current time plus the maximum password age? Why the current time and
not the time the password is set? How could this value possibly be
useful? I looked at the code because I couldn't believe the document
referenced above, but that document appears to accurately describe the code.
This goes beyond simply being a bug in implementation. Whoever wrote
this code fundamentally misunderstands the purpose of the shadowExpire
attribute. It isn't an expiration date for the password, and shouldn't
be affected in any way by password policies. The shadow expiration date
is an expiration date on the account itself. For example, I work in a
university where our student accounts are valid only while they are
enrolled in classes. shadowExpire is set to the end date for their
enrolled courses. It does not change when they set their password, and
shouldn't depend on whether or not passwords expire.
Please see "man 5 shadow". The new behavior is wrong. I think it
should be reverted for several reasons: Primarily, the behavior is
incorrect according to the documentation. The standard behavior for
this attribute provides a fixed date on which an account will no longer
be valid. Additionally, a change of this type is in appropriate in
RHEL. The proposition of a "stable" system is that features and
functionality will not change in incompatible ways without notice. This
is an incompatible change, and was not documented in the release notes
as far as I can see. Finally, this change quietly allows accounts which
were previously expired to be considered to now be considered valid.
Almost no one will notice that their existing security policies are no
longer being enforced as a result of this change.
Well previously the shadowExpire value did nothing
Yes, it did. It indicated to client systems when the account should no
longer be considered valid. It was used by our user management tools to
notify students before their accounts were terminated.
, it was just there
for schema compat. It was a static value, that never decremented so an
account was "always valid".
Why would it decrement?
At worst, we just lock accounts that would
have been locked out anyway due to the expiry of the password within ds
- Nothing is prematurely locked out, not activated.
No, at worst accounts that should be locked out are now allowed in
forever because we don't expire passwords (because those ages are
relative to the most recent change) but we do expire accounts (because
that occurs on a fixed date).
This is a positive change, allowing synchronisation of policy between
ns
and unix clients. Issues you see, are because of an inconsistent
management of password policy on directory server and shadow values. I
don't think we will revert or back out of this change, given the
positive benefits we perceive that it brings on a bigger scale to many
installations.
My advice would be to alter your password policy to match what you
expect shadow to contain.
That doesn't appear to be possible.