Hi all

I'm currently testing Dovecot 2.4, considering a migration from 2.3, and all
works fine except authentication against LDAP (openldap slapd) with client
certificates. Which I had no problem with on 2.3 for seven years or so.

Versions:
Linux Alpine 3.22
Dovecot 2.4.1-4 (7d8c0e5759) Alpine package, but patched with
https://github.com/dovecot/core/commit/431e328b3b035ddb187526cd13bccf29833aed90

Now, first a Dovecot configuration that does work, unencrypted simple bind
against Unix domain socket:

ldap_version = 3
ldap_uris = ldapi:///
ldap_base = ou=users,dc=mydomain,dc=internal
ldap_auth_dn = cn=dovecot,dc=mydomain,dc=internal
ldap_auth_dn_password = secret
passdb ldap {
  bind = no
  default_password_scheme = SSHA
  ldap_filter = (&(objectClass=posixAccount)(uid=%{user}))
  fields {
    user = %{ldap:uid}
    password = %{ldap:userPassword}
  }
}

Meaning I'm doing password lookups, IMAP users can authenticate against Dovecot,
Postfix correctly delivers incoming emails, everything works flawlessly.

Now the setup I'm talking about, which does not work:

ldap_version = 3
ldap_uris = ldaps://localhost.mydomain.internal
ldap_base = ou=users,dc=mydomain,dc=internal
ldap_auth_sasl_mechanisms = external
ssl_client_cert_file = /etc/ssl/ldap/dovecot.crt
ssl_client_key_file = /etc/ssl/ldap/dovecot.key
# this just as a precaution during testing, validation *does* work
ssl_client_require_valid_cert = no
ssl_client_ca_dir = /etc/ssl/certs
passdb ldap {
  bind = no
  default_password_scheme = SSHA
  ldap_filter = (&(objectClass=posixAccount)(uid=%{user}))
  fields {
    user = %{ldap:uid}
    password = %{ldap:userPassword}
  }
}

What happens here, as far as I can see, is Dovecot connects to slapd, initiates
a SASL session but then fails to send the client certificate. slapd realizes
the cert isn't coming, asserts there's no other SASL "external" method to
fall back to and disconnects Dovecot. Game over.

Now, before somebody thinks 'maybe something wrong with the certs or so', the
very same setup on the very same machine works perfectly with two other client
types, namely
- openldap standard utils
- postfix (recipient lookup)

With the utils I have this setup, with the same client cert

URI         ldaps://localhost.mydomain.internal
BASE        ou=users,dc=mydomain,dc=internal
SASL_MECH   external
TLS_REQCERT demand
TLS_CACERT  /root/ssl/ca.crt
TLS_CERT    /etc/ssl/ldap/dovecot.crt
TLS_KEY     /etc/ssl/ldap/dovecot.key

and ldapwhoami connects without problem, and with ldapsearch I can perform the
very same searches Dovecot is supposed to do.

Postfix, for recipient lookups, I have configured like this:

version = 3
server_host = ldaps://localhost.mydomain.internal
search_base = ou=users,dc=mydomain,dc=internal
query_filter = (&(mail=%s))
result_attribute = uid
bind = sasl
sasl_mechs = external
tls_require_cert = demand
tls_ca_cert_dir = /etc/ssl/certs
tls_cert = /etc/ssl/ldap/dovecot.crt
tls_key = /etc/ssl/ldap/dovecot.key

Again, no problem to authenticate agains LDAP with the very same client
certificate. The CA is correctly installed into /etc/ssl/certs , by the way,
with update-ca-certificates.

So out of 3 client types with the very same setup only Dovecot fails to
successfully negotiate the client cert SASL session, while, after a good look
through the docs, I really don't see any other settings I could tweak.

Thoughts?

Greetings, Bruno
_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to