Re: Issues with passwordmustchange in a local policy on 389-ds 1.4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Tue, Nov 16, 2021 at 7:29 AM Brian Collins <rbriancollins@xxxxxxxxx> 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@xxxxxxxxxx> 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@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

[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux