> On 6 May 2020, at 09:09, Alberto Viana <albertocrj@xxxxxxxxx> 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 <wbrown@xxxxxxx> wrote: > > > > On 6 May 2020, at 04:33, Alberto Viana <albertocrj@xxxxxxxxx> 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 -- 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 > _______________________________________________ > 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 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 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
