William, I'm just a little bit confused about pwadmin concept vs nsslapd-allow-hashed-passwords. Once I turned on nsslapd-allow-hashed-passwords, it's no supposed to only users in my pwadmin(group/users) to be allowed to add pre-hashed password?
Thanks Alberto Viana On Wed, May 6, 2020 at 7:56 PM William Brown <[email protected]> wrote: > Remember to *unset* it after you make your change, else anyone with write > to userPassword can bypass your password policy. Generally this means a > userc that is able to change their own password through a self mod, can > then bypass pwpolicy. > > > On 7 May 2020, at 01:49, Alberto Viana <[email protected]> wrote: > > > > William, > > > > Set nsslapd-allow-hashed-passwords and pwadmin in global policy works as > expected. > > > > Thanks again. > > > > Alberto Viana > > > > On Tue, May 5, 2020 at 9:22 PM Alberto Viana <[email protected]> > wrote: > > William, > > > > I will try it tomorrow, but a reference about > "nsslapd-allow-hashed-passwords" in > https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/password_administrators > make senses to me. > > > > > > Thanks anyway. > > > > Alberto Viana > > > > On Tue, May 5, 2020 at 8:58 PM William Brown <[email protected]> wrote: > > > > > > > On 6 May 2020, at 09:09, Alberto Viana <[email protected]> wrote: > > > > > > William > > > > > > I want to let this user bypass the policy and add a pre-hashed > password, > > > > If you want to add a pre-hashed password here, you'll need to change the > password-migrate flag in cn=config, load that password, then unset the > password migrate flag. > > > > > https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/configuration_command_and_file_reference/core_server_configuration_reference#nsslapd-allow-hashed-passwords > > > > > > > > > I also have a global policy and some OU policies level. On this OU > OU=POP-PA,dc=my,dc=domain I have a local policy set. > > > > > > Should I set pwadmin in local policy level? global policy level is not > enough? > > > > I think the ou policies over-ride the global policy, but regardless, > password hash loading is a seperate issues - as mentioned a pre-hashed PW > bypasses pwpolicy regardless of it's level, and is disallowed unless the > above config value is set. It's not recommended to allow pre-hashed > password upload in production long term, so as mentioned enable it, load > the one password, then disable it. > > > > > > > > > > > > Thanks > > > > > > Alberto Viana > > > > > > On Tue, May 5, 2020 at 7:57 PM William Brown <[email protected]> wrote: > > > > > > > > > > On 6 May 2020, at 04:33, Alberto Viana <[email protected]> wrote: > > > > > > > > additional info: invalid password syntax - passwords with storage > scheme are not allowed > > > > > > > > > > > > > This line here is saying that you have a userPassword: {SCHEME}<Hash> > in your ldif (I think). By default we don't allow this, but there is a > migrate password hash option in cn=config. > > > > > > Of course, loading a hash this way bypasses the password policy checks > .... > > > > > > So you may want to check your ldif, and set the userPassword as > cleartext for the modify, and the server-side will apply pwpolicy and > perform proper hashing. > > > > > > Hope that helps, > > > > > > — > > > Sincerely, > > > > > > William Brown > > > > > > Senior Software Engineer, 389 Directory Server > > > SUSE Labs > > > _______________________________________________ > > > 389-users mailing list -- [email protected] > > > To unsubscribe send an email to > [email protected] > > > 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/[email protected] > > > _______________________________________________ > > > 389-users mailing list -- [email protected] > > > To unsubscribe send an email to > [email protected] > > > 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/[email protected] > > > > — > > Sincerely, > > > > William Brown > > > > Senior Software Engineer, 389 Directory Server > > SUSE Labs > > _______________________________________________ > > 389-users mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > 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/[email protected] > > _______________________________________________ > > 389-users mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > 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/[email protected] > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs > _______________________________________________ > 389-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] >
_______________________________________________ 389-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
