Possible Bug: Dovecot LDAP userdb search ignores DN template
Hello Dovecot Team,
I am currently using *Dovecot 2.4.1* with *Windows Active Directory* via LDAPS (self-signed certificate).
I have configured a *bind DN template* for authentication.
Authentication works perfectly. However, when Dovecot tries to perform the *userdb lookup*, it seems to *ignore the DN template*. Instead, it attempts to perform a search using the *ldap_base and filter* I configured...
According to the documentation, the *bind DN template should be sufficient*, and Dovecot should not need to perform this search.
Additionally, if I *remove the ldap_base or filter fields*, Dovecot fails with an error and cannot perform the lookup at all.
This results in doveadm user failing, even though authentication succeeds.
Could this be a bug in the way Dovecot handles bind_userdn for LDAP userdb lookups?
I would appreciate any guidance or confirmation on this behavior.
Thank you for your help.
Hello Dovecot Team,
I am currently using Dovecot 2.4.1 with Windows Active Directory via LDAPS (self-signed certificate).
I have configured a bind DN template for authentication.
Authentication works perfectly. However, when Dovecot tries to perform the userdb lookup, it seems to ignore the DN template. Instead, it attempts to perform a search using the ldap_base and filter I configured...
According to the documentation, the bind DN template should be sufficient, and Dovecot should not need to perform this search.
Additionally, if I remove the ldap_base or filter fields, Dovecot fails with an error and cannot perform the lookup at all.
This results in doveadm user failing, even though authentication succeeds.
Could this be a bug in the way Dovecot handles bind_userdn for LDAP userdb lookups?
I would appreciate any guidance or confirmation on this behavior.
Thank you for your help.
I would recommend configuring a service user to AD and using LDAP userdb, but if you do not, for whatever reason want to do this, change
userdb static { allow_all_users = yes fields { gid = vmail uid = vmail } }
to skip passdb check.
See https://doc.dovecot.org/2.4.2/core/config/auth/userdb.html#userdb_static_all...
Aki
On 25/01/2026 12:30 EET Esteban Heschung via dovecot <dovecot@dovecot.org> wrote:
Hello Dovecot Team,
I am currently using *Dovecot 2.4.1* with *Windows Active Directory* via LDAPS (self-signed certificate).
I have configured a *bind DN template* for authentication.
Authentication works perfectly. However, when Dovecot tries to perform the *userdb lookup*, it seems to *ignore the DN template*. Instead, it attempts to perform a search using the *ldap_base and filter* I configured...
According to the documentation, the *bind DN template should be sufficient*, and Dovecot should not need to perform this search.
Additionally, if I *remove the ldap_base or filter fields*, Dovecot fails with an error and cannot perform the lookup at all.
This results in doveadm user failing, even though authentication succeeds.
Could this be a bug in the way Dovecot handles bind_userdn for LDAP userdb lookups?
I would appreciate any guidance or confirmation on this behavior.
Thank you for your help. Hello Dovecot Team,
I am currently using Dovecot 2.4.1 with Windows Active Directory via LDAPS (self-signed certificate).
I have configured a bind DN template for authentication.
Authentication works perfectly. However, when Dovecot tries to perform the userdb lookup, it seems to ignore the DN template. Instead, it attempts to perform a search using the ldap_base and filter I configured...
According to the documentation, the bind DN template should be sufficient, and Dovecot should not need to perform this search.
Additionally, if I remove the ldap_base or filter fields, Dovecot fails with an error and cannot perform the lookup at all.
This results in doveadm user failing, even though authentication succeeds.
Could this be a bug in the way Dovecot handles bind_userdn for LDAP userdb lookups?
I would appreciate any guidance or confirmation on this behavior.
Thank you for your help.
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Hello,
Thank you, that works now!
However, I’m a bit puzzled: why do I have to skip the lookup using allow_all_users = yes? It feels like this might be a bug.
Also, I don’t quite understand the recommendation to use a service account. In my setup, we authenticate directly with the user’s own credentials, so why would a service account be necessary?
Finally, should I be using LDAP userdb in this scenario, or is keeping a static userdb fine when authenticating with the user credentials?
Thank you for your guidance!
Best regards,
Do you also know how to retrieve the user's sAMAccountName instead of the cn? Because when I do sAMAccountName=user,cn=Users,dc=gr4,dc=lan, it doesn't find the user...
On January 25, 2026 4:42:24 PM GMT+02:00, ByteWave via dovecot <dovecot@dovecot.org> wrote:
Do you also know how to retrieve the user's sAMAccountName instead of the cn? Because when I do sAMAccountName=user,cn=Users,dc=gr4,dc=lan, it doesn't find the user...
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Yes. And it requires service user because bind_dn can only bind by distinguishedName (dn).
This works by looking up user's dn with filter and then doing bind, which requires that service user.
You can utilize the same service user in userdb to avoid problem of getting mail for nonexistent accounts.
You could also get a properly signed cert from your AD, or switch to gssapi.
Aki
participants (3)
-
Aki Tuomi
-
ByteWave
-
Esteban Heschung