Am I understanding correctly that the auth_bind option, regardless of whether it is set to yes or no, and even if anonymous access to the LDAP directory is blocked, must be used with dn=cn=manager,dc=example,dc=com and dnpass=password to enable authentication? Forget about using manager, always create a different entity so you can create acl's specific for this entity and change passwords etc.
cn=dovecot,cn=mail,ou=hosts,dc=example,dc=com
It seems to me that there are no other cases where Dovecot can query the I think it queries to get file locations (home dir) and maybe searches for uid's so you need something like this
to dn.subtree="ou=mailaccounts,ou=mail,dc=example,dc=com" by ssf=256 dn.exact="cn=dovecot,cn=mail,ou=hosts,dc=example,dc=com" read by ssf=256 self read by anonymous auth by * none
But this is something old that I had and am not using. This allows the cn=dovecot to also access the password field. I am not sure if that is necessary/wanted. No it is not necessary and dangerous. That is a setup from the past which mimic the limitations of SQL databases.
LDAP server directly using the login and password provided by the client. To perform authentication, it must execute a BIND by an intermediate user, regardless of where the password check takes place - in LDAP or in Dovecot. No, you're mixing things. You could use flat file user database, or no user database at all with fixed parameters. In this case for the
Le 28/05/2023 à 21:36, Marc a écrit : password database on the LDAP server, the password check will be a simple bind. Yes you should use double bind for the user/password database case and the most flexibility. But you should never directly access or have read access to the password attribute with the dovecot or with the user credential. Not using LDAP bind to check the password defeat most of the LDAP advantages and security. You loose lots of openldap functionality like sasl password forwarding, change password extended operation and others. The double bind will never cause performance problems in your case, and for extreme ops scenario in very very huge setups, you could use Unix socket to locally replicated ldap database and SASL EXTERNAL mechanism for the dovecot bind and normal bind for user password checks.
Are there any other ways for the client to log in directly with their credentials on the Dovecot server?
Yes forget about using ldap in dovecot, and configure ldap for the os and let dovecot authenticate against the os. Don't do that if the users have no shell access to the system, you're opening a worm hole ... And dovecot is more flexible with a LDAP native user and password database. Learn how to properly use LDAP in any case or don't use it. Emmanuel.