On Tue, Nov 16, 2021 at 7:29 AM Brian Collins rbriancollins@gmail.com wrote:
Hi Simon,
Yes, that worked! Thanks.
Feel like I should've caught that one myself. Thanks for the quick response and help!
Hi Brian, Glad to help!
Have fun! :) Simon
--Brian
On Tue, Nov 16, 2021 at 9:57 AM Simon Pichugin spichugi@redhat.com wrote:
Hi Brian, Thank you!
For some reason, you have 'nsslapd-pwpolicy-local: off'. If this attribute has a value of off, all entries (except for
cn=Directory Manager) in the directory are subjected to the global password policy; the server ignores any defined subtree/user level password policy.
If this attribute has a value of on, the server checks for password
policies at the subtree- and user-level and enforces those policies.
Could you please enable it and try to test your issue again?
Hope that helps, Simon
On Tue, Nov 16, 2021 at 6:37 AM Brian Collins rbriancollins@gmail.com
wrote:
Sure thing, Simon. I believe the queries I did below gave me what you're requested. Please let me know if you need more information. Thanks!
Global: # dsconf -y dirman.txt -D "cn=Directory Manager" pro02 pwpolicy get Global Password Policy: cn=config
nsslapd-pwpolicy-local: off passwordstoragescheme: PBKDF2_SHA256 passwordchange: on passwordmustchange: off passwordhistory: off passwordinhistory: 6 passwordadmindn: passwordtrackupdatetime: off passwordwarning: 86400 passwordisglobalpolicy: on passwordexp: off passwordmaxage: 8640000 passwordminage: 0 passwordgracelimit: 0 passwordsendexpiringtime: off passwordlockout: off passwordunlock: on passwordlockoutduration: 3600 passwordmaxfailure: 3 passwordresetfailurecount: 600 passwordchecksyntax: off passwordminlength: 8 passwordmindigits: 0 passwordminalphas: 0 passwordminuppers: 0 passwordminlowers: 0 passwordminspecials: 0 passwordmin8bit: 0 passwordmaxrepeats: 0 passwordpalindrome: off passwordmaxsequence: 0 passwordmaxseqsets: 0 passwordmaxclasschars: 0 passwordmincategories: 3 passwordmintokenlength: 3 passwordbadwords: passworduserattributes: passworddictcheck: off passworddictpath: nsslapd-allow-hashed-passwords: off nsslapd-pwpolicy-inherit-global: off
Local: # dsconf -y ~/dirman.txt -D "cn=Directory Manager" pro02 localpwp get ou=People,dc=example,dc=com Local User Policy Policy for "ou=People,dc=example,dc=com":
cn=cn\3DnsPwPolicyEntry\2Cou\3DPeople\2Cdc\3Dexample\2Cdc\3Dcom,cn=nsPwPolicyContainer,ou=People,dc=example,dc=com
passwordstoragescheme: ssha512 passwordchange: on passwordmustchange: on passwordhistory: off passwordadmindn: cn=siteops sa,ou=sa groups,dc=example,dc=com passwordexp: off passwordminage: 0
On Tue, Nov 16, 2021 at 12:36 AM Simon Pichugin spichugi@redhat.com
wrote:
Hi Brian, could you please provide your full Password Policy setup (but global
and local, entries and attributes)?
Please, check this chapter for the details:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/ht...
Sincerely, Simon
On Mon, Nov 15, 2021 at 8:37 AM Brian Collins <
rbriancollins@gmail.com> wrote:
Good day all.
We recently updated our 389-ds infrastructure from 1.3.8.4 on RHEL 7 to 1.4.4.16, installed via epel-modular, on RHEL 8.
Since that time, it appears that our local password policy setting of "pwdmustchange" is not working. If I apply a global policy, it does seem to work, but we prefer to keep it as a local policy applied to a subtree (ou=People,dc=example,dc=com).
# dsconf -y ~/dirman.txt -D "cn=Directory Manager" pro02 localpwp get ou=People,dc=example,dc=com
Local User Policy Policy for "ou=People,dc=example,dc=com":
cn=cn\3DnsPwPolicyEntry\2Cou\3DPeople\2Cdc\3Dexample\2Cdc\3Dcom,cn=nsPwPolicyContainer,ou=People,dc=example,dc=com
passwordstoragescheme: ssha512 passwordchange: on passwordmustchange: on passwordhistory: off passwordadmindn: cn=siteops sa,ou=sa groups,dc=example,dc=com passwordexp: off passwordminage: 0
With the above settings, but the global policy for passwordmustchange set to "off", an administratively-changed password (done by Directory Manager) does not require a change on first login. If I change the global policy to on and reset the user's password again, it does require a change.
Again, time-wise, this seems to have begun with our move from 1.3 to 1.4. To do the upgrade, we introduced 1.4 servers then created replication agreements with them. Then we removed the 1.3 servers (I hope that was the right way to do it; didn't think much about it at the time).
It would not surprise me if I am doing (or have done) something wrong here, but I'm unable to pinpoint what.
Thank you in advance, Brian _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to
389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
389-users@lists.fedoraproject.org