Reformatted:
On 03/17/2017 04:27 PM, info@gwarband.de wrote:
Hello guys,
actually I'm trying to configure dovecot to access openldap for passwordcheck.
All datalinks:
Mar 11 11:18:26 s1 dovecot: auth: Debug: Read auth token secret from /var/run/dovecot/auth-token-secret.dat Mar 11 11:18:26 s1 dovecot: auth: Error: LDAP: ldap_start_tls_s() failed: Connect error Mar 11 11:18:26 s1 dovecot: auth: Error: LDAP: ldap_start_tls_s() failed: Connect error Mar 11 11:18:26 s1 dovecot: auth: Debug: auth client connected (pid=27177) Mar 11 11:18:33 s1 dovecot: imap-login: Disconnected (no auth attempts in 7 secs): user=<>, rip=149.172.171.148, lip=188.68.37.50, session=<gcDtzHFKbwCVrKuU>
uris = ldap://ldap.gwarband.de dn = cn=T000000002,ou=tech,dc=gwarband,dc=de dnpass = secret tls = yes tls_ca_cert_file = /etc/ssl/certs/LetsEncrypt.pem auth_bind = yes ldap_version = 3 base = dc=gwarband,dc=de scope = subtree user_attrs = mail=maildir:/var/vmail/%{ldap:mailbox},uid=vmail,gid=vmail user_filter = (&(email=%u)(memberOf=cn=mailbox,ou=application,ou=groups,dc=gwarband,dc=de)) pass_attrs = email=user pass_filter = (&(email=%u)(memberOf=cn=mailbox,ou=application,ou=groups,dc=gwarband,dc=de))
Mar 11 10:48:38 s1 slapd[26962]: conn=1001 fd=14 ACCEPT from IP=188.68.37.50:60814 (IP=188.68.37.50:389)
Mar 11 10:48:38 s1 slapd[26962]: conn=1001 op=0 STARTTLS
Mar 11 10:48:38 s1 slapd[26962]: conn=1002 fd=15 ACCEPT from IP=188.68.37.50:60815 (IP=188.68.37.50:389)
Mar 11 10:48:38 s1 slapd[26962]: conn=1002 op=0 STARTTLS
Mar 11 10:49:42 s1 slapd[26962]: connection_get(14): got connid=1001 Mar 11 10:49:42 s1 slapd[26962]: connection_read(14): checking for input on id=1001 Mar 11 10:49:42 s1 slapd[26962]: connection_read(14): TLS accept failure error=-1 id=1001, closing
Mar 11 10:49:42 s1 slapd[26962]: connection_get(15): got connid=1002 Mar 11 10:49:42 s1 slapd[26962]: connection_read(15): checking for input on id=1002 Mar 11 10:49:42 s1 slapd[26962]: connection_read(15): TLS accept failure error=-1 id=1002, closing
Mar 11 10:49:42 s1 slapd[26962]: conn=1001 fd=14 closed (TLS negotiation failure) Mar 11 10:49:42 s1 slapd[26962]: conn=1002 fd=15 closed (TLS negotiation failure)
It appears that the client is sending an unbind request after the server sends a successful starttls response.
The bugreportinglink from openldap:
Am 2017-03-17 22:48, schrieb Tomas Habarta:
been running Dovecot 2.2.27 against OpenLDAP 2.4.40 normally over the unix socket on the same machine, but tried over inet with STARTTLS and it's working ok... I would suggest double-checking key/certs setup on OpenLDAP side; for the test I have used LE certs, utilizing following cn=config attributes:
olcTLSCertificateKeyFile contains private key olcTLSCertificateFile contains certificate olcTLSCACertificateFile contains both certs (DST Root CA X3 and Let's Encrypt Authority X3)
and used the same CA file in Dovecot's tls_ca_cert_file Is ldapsearch working ok (-ZZ) and only Dovecot has troubles or ... ?
On 03/18/2017 09:41 AM, info@gwarband.de wrote:
I have also installed LE certs. But nothing helps, I have double-checking all certs. ldapsearch with -ZZ works see:
ldapsearch -x -ZZ -D "cn=admin,dc=gwarband,dc=de" -W "cn=mailbox"
I have also uploaded the TLSCACertificateFile, maybe I have a failure in the merge of the two fiels:
https://gwarband.de/openldap/LetsEncrypt.crt
And also I have uploaded my complete openldap configuration:
# Certificate TLSCACertificateFile /etc/ssl/certs/LetsEncrypt.pem TLSCertificateFile /etc/ssl/certs/gwarbandDE_LDAP.pem TLSCertificateKeyFile /etc/ssl/certs/gwarbandDE_LDAP.key TLSCipherSuite SECURE128:-ARCFOUR-128:-CAMELLIA-128-CBC:-3DES-CBC:-CAMELLIA-128-GCM TLSProtocolMin 3.1 TLSVerifyClient never
All other components can work and communicate with my openldap server. The components are postfix, openxchange, apache (phpldapadmin). My installated software is:
Debian 8 OpenLDAP 2.4.40 Dovecot 2.2.13
Am 2017-03-18 12:30, schrieb Tomas Habarta:
Well, if ldapsearch works, try to replicate its settings for dovecot client. It's not obvious what settings ldapsearch uses, have a look at default client settings in /etc/openldap/ldap.conf, there may be something set a slightly different way. Also double check permissions for files used by dovecot, I mean mainly the file listed for tls_ca_cert_file as dovecot may not have an access for reading... I cannot see anything downright bad, just posted CA cert (which is ok, tested) is *.crt and your config mentions *.pem but I consider it's the same file. Finally, I would recommend to enable debug option for dovecot's client
debug_level = -1 (which logs all available) in your dovecot-ldap.conf
to see what the library reports and work further on that. You can compare with output from ldapsearch by adding -d-1 switch to it. Hard to tell more at the moment.
What are the contents of /etc/ldap/ldap.conf?
On 03/18/2017 01:31 PM, info@gwarband.de wrote:
I've replicate the settings from ldapsearch to dovecot but no success.
To the certificate:
Yes it's a *.crt file but I have linked the *.pem file to it and dovecot has read access to that file. I have enabled the debugging in dovecot and have uploaded the output:
Mar 18 12:43:31 s1 dovecot: auth: Error: ldap_extended_operation_s Mar 18 12:43:31 s1 dovecot: auth: Error: ldap_extended_operation
Mar 18 12:43:31 s1 dovecot: auth: Error: ldap_connect_to_host: TCP ldap.gwarband.de:389
Mar 18 12:43:31 s1 dovecot: auth: Error: connect success
Mar 18 12:43:31 s1 dovecot: auth: Error: LDAP: ldap_start_tls_s() failed: Connect error
And the other site with ldapsearch:
https://gwarband.de/openldap/ldapsearch-connect.log
I'm pretty sure that there is a problem with the sslhandshaking between openldap and dovecot, but I can't find the source of the problem. One of the steps in the sslhandshaking is not success but in the debugging output I can't find any line with a hit to it.
Am 2017-03-18 14:01, schrieb Tomas Habarta:
Increase log level on server side as well to see what the server says... You may remove anything in TLSCipherSuite for the purpose of testing too. Hopefully anyone knowing OpenLDAP internals could help you analyse it more deeply.
Your ldapsearch command should reference your ldap.conf config (ldap.conf(5)), and your dovecot-ldap.conf (assuming that it uses libldap) will also, but overwrite any settings using dovecot-ldap.conf. Compare any differences.
Look for permissions problems. Run your ldapsearch command as the same user dovecot runs under.