What rpm version of 389-ds-base are you using? Is it the same on both
systems?
In newer versions the standard storage scheme is PBKDF2-SHA512. Is your
client trying to read or add already hashed passwords? Not sure why
dovecot, or any client, would be complaining about an unknown password
storage scheme since it should not know anything about the password
storage scheme as it's supposed to be handled by the Directory Server
internally.
Anything in the DS errors log?
Is PBKDF2-SHA512 in your DS config?
Anyway I'm not sure what is going on or what version of 389 you are
using. I suspect you have two different versions of 389-ds-base, one
which is newer and supports PBKDF2-SHA512, and one that is older and
does not. Otherwise, I guess your clients are processing/using the
userpassword value, and they just might not support PBKDF2-SHA512? So
that means you have entries that already have PBKDF2-SHA512 (before you
changed the password policy to PBKDF2_SHA256?). So those entries need
to have their passwords reset to use the updated global password policy
scheme.
FYI - you should avoid using SSHA512. It's very insecure as the hash
can be cracked in 20 minutes or something like that.
Mark
On 3/7/23 8:22 AM, Mr Mysteron wrote:
Hi.
I'm running two 389-ds instances on Centos9 servers, one master and
one readonly slave server.
Global pwpolicy is PBKDF2_SHA256 and local pwpolicy is SSHA512.
The mail-servers are querying the readonly slave server for LDAP data.
All servers are using TLS for encryption.
I'm running a two mail servers, one for incoming mail with Dovecot as
an imap frontend and one for Postfix smtp with Dovecot as a SASL
authentication backend.
The Dovecot imap server has been running LDAP authentication
flawlessly, but I recently switched the Postfix smtp server over to
Dovecot SASL authentication.
Here's when everything started taking an interesting turn.
The incoming Dovecot imap server is set to do an authentication bind:
auth_bind = yes
while the smtp server with Postfix + Dovecot SASL authentication does
not do an auth_bind.
The authentication process started failing on the smtp server with the
following error message for every authenticated user:
dovecot[721505]: auth: Error: ldap(USERNAME): Unknown scheme PBKDF2-SHA512
Changing password for a user will allow authentication against the
LDAP from the smtp server, but when the imap server authenticates and
use auth_bind, then no LDAP authentication is possible do on the smtp
server and the above error message appears again for the user.
I found out, that when I also use auth_bind for Dovecot on the smtp
server everything works.
What I hope someone could explain for me is, what's happening with the
slave queries against the 389-ds ro server instance when the imap
server authenticates the user with auth_bind enabled and the smtp
server cannot authenticate the user when auth_bind is not enabled.
The servers are binding prior to auth_bind with a
dn = cn=binduser,ou=bindaccount,dc=example,dc=com
user so that part is working as intended.
Thank you.
BR,
/MrM
_______________________________________________
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, report it: https://pagure.io/fedora-infrastructure/new_issue
--
Directory Server Development Team
_______________________________________________
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, report it: https://pagure.io/fedora-infrastructure/new_issue
