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@xxxxxxxxx> 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@xxxxxxxxxx> 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/html-single/administration_guide/index#User_Account_Management-Managing_the_Password_Policy
>
> Sincerely,
> Simon
>
> On Mon, Nov 15, 2021 at 8:37 AM Brian Collins <rbriancollins@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
>> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxxxxxxxxxx
>> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
