After upgrading to CentOS 7.3, I found that shadowExpire attributes were not returned correctly. Searching for an account shows:
dn: UID=gmessmer,ou=People,dc=... uid: gmessmer shadowexpire: 117170
The same value is shown in the 389-ds console. The correct value, however, appears in our daily LDIF exports. After downgrading to 389-ds-base-1.3.4.0-33.el7_2.x86_64, the value appears correctly in searches again:
dn: UID=gmessmer,ou=People,dc=... uid: gmessmer shadowexpire: 17248
Before I file a bug with Red Hat, is there anything else I should look at?
On Thu, 2017-01-05 at 15:09 -0800, Gordon Messmer wrote:
After upgrading to CentOS 7.3, I found that shadowExpire attributes were not returned correctly. Searching for an account shows:
dn: UID=gmessmer,ou=People,dc=... uid: gmessmer shadowexpire: 117170
The same value is shown in the 389-ds console. The correct value, however, appears in our daily LDIF exports. After downgrading to 389-ds-base-1.3.4.0-33.el7_2.x86_64, the value appears correctly in searches again:
dn: UID=gmessmer,ou=People,dc=... uid: gmessmer shadowexpire: 17248
The shadowexpire value now is handled differently on 1.3.5 if I recall.
Instead of being "set" by you to a value, it's now calculated and derived from the ns password policy. As the account nears expiry, the values decrements.
When you export the DB with the ldif, you are bypassing the calculation code, and you get what's stored in the DB.
I hope that helps you see why the values are changing. Your best path forward is to work on and resolve the password policy configuration of your system.
On 01/05/2017 03:15 PM, William Brown wrote:
The shadowexpire value now is handled differently on 1.3.5 if I recall.
I'm unable to find documentation of this change in the release notes. Am I overlooking something?
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
If not, does it make sense to change account expiration mechanisms, automatically, without notice, to an incompatible alternative in the middle of a "stable" release (RHEL 7), potentially granting access to accounts that were expired before the change?
Can users revert this behavioral change? I certainly think Red Hat should.
On Thu, 2017-01-05 at 15:35 -0800, Gordon Messmer wrote:
On 01/05/2017 03:15 PM, William Brown wrote:
The shadowexpire value now is handled differently on 1.3.5 if I recall.
I'm unable to find documentation of this change in the release notes. Am I overlooking something?
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
If not, does it make sense to change account expiration mechanisms, automatically, without notice, to an incompatible alternative in the middle of a "stable" release (RHEL 7), potentially granting access to accounts that were expired before the change?
http://www.port389.org/docs/389ds/design/shadow-account-support.html
Well previously the shadowExpire value did nothing, it was just there for schema compat. It was a static value, that never decremented so an account was "always valid". 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.
Now, we actually update the shadowExpire to be in line with the ns password policy, so the values you are seeing, are your *true* password policy, and when the account really will expire. This way unix clients can see the expiry, rather than DS keeping it "secret". We unified our password policy, rather than allowing users and administrators to keep fragmenting it and causing themself issues.
Can users revert this behavioral change? I certainly think Red Hat should.
Sorry, I do not believe there is a configuration to allow this to be disabled.
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.
Sorry I can't be of more help,
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
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.
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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
On 01/05/2017 10:11 PM, Noriko Hosoi wrote:
Sorry about the misunderstanding. Please file a ticket with the expected behaviour.
https://fedorahosted.org/389/ticket/49080
I've included a patch to correct that behavior.
The rest of the shadow attribute implementation is buggy, too. First, shadow attributes (in /etc/shadow and in LDAP) are typically unset when no policy is in place. 389-ds will incorrectly return values (possibly set to 0) when there is no policy. I also have a patch for that, pending a fix to the second problem. The second problem is that when "password never expires" is set in 389-console, pwpolicy->pw_maxage still has a value, so shadowMax and shadowWarning still get a value. It's not obvious to me, after looking at the passwordpolicyarray struct, how to determine whether password expiration is checked. If you can give me a hint there, I can fix those bugs as well.
On 01/06/2017 08:13 AM, Gordon Messmer wrote:
If you can give me a hint there, I can fix those bugs as well.
Nevermind. I figured it out. A suggested fix for the latter bugs is attached to a ticket for those as well:
389-users@lists.fedoraproject.org
-
Gordon Messmer -
Noriko Hosoi -
William Brown