Le 28/05/2023 à 21:36, Marc a écrit :
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
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.
_______________________________________________
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
