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/html/7.3_Release_Notes/bug_fixes_servers_and_services.html > > 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx -- Sincerely, William Brown Software Engineer Red Hat, Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
