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@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
No comments:
Post a Comment