Sorry about the misunderstanding. Please file a ticket with the expected
behaviour.
https://fedorahosted.org/389/newticket
Thanks.
On 01/05/2017 06:34 PM, Gordon Messmer wrote:
On 01/05/2017 04:00 PM, William Brown wrote:
http://www.port389.org/docs/389ds/design/shadow-account-support.html
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.
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
