Hi Mark, Both servers are running the latest 2.2.x version from directory.fedoraproject.org:
python3-lib389-2.2.6-1.el9.noarch 389-ds-base-libs-2.2.6-1.el9.x86_64 389-ds-base-2.2.6-1.el9.x86_64 cockpit-389-ds-2.2.6-1.el9.noarch This is listed in dse.ldif regarding PBKDF2-SHA512 and that makes the password storage schema active I assume: dn: cn=PBKDF2-SHA512,cn=Password Storage Schemes,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin cn: PBKDF2-SHA512 nsslapd-pluginPath: libpwdchan-plugin nsslapd-pluginInitfunc: pwdchan_pbkdf2_sha512_plugin_init nsslapd-pluginType: pwdstoragescheme nsslapd-pluginEnabled: on nsslapd-pluginId: none nsslapd-pluginVersion: none nsslapd-pluginVendor: none nsslapd-pluginDescription: none No error messages, all are log data points to "RESULT err=0" in access logfile. I assume the problem is because the smtp server does not initiate a simple bind for checking the username & password when auth_bind is disabled in dovecot. I'd like to know, if the object in the LDAP directory is set into some kind of "protective state" when a server has first authenticated with a simple bind in order to access the object, and when another server which doesn't make a simple bind in order to access the same object in the directory, 389-ds will not validate the users credentials. BR, /MrM On Tue, Mar 7, 2023 at 4:38 PM Mark Reynolds <[email protected]> wrote: > 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 -- [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] > > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > > -- > Directory Server Development Team > >
_______________________________________________ 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] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
