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
