Problem with 389-ds authentication

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

 



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

[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