search for: habarta

....conf and dovecot-ldap.conf should have no differences, that is correct no differences. Here is a link to the ldap.conf https://gwarband.de/openldap/ldap.conf And the output of ldapsearch under dovecot: https://gwarband.de/openldap/ldapsearch-dovecot.log Tobias Am 2017-03-20 11:00, schrieb Tomas Habarta: > I've finally managed that running on Debian 8 test machine by > commenting > tls_ca_cert_file = > option from dovecot-ldap.conf, so only > tls = yes > tls_require_cert = demand > > Not sure why is that as on my CentOS6 Dovecot works even with that > commented...

...ttps://gwarband.de/openldap/openldap-connect.log Note: openldap waits 1 Minute before he says "TLS negotiation failure" after the connect. and dovecot says direct "Connect error" I've also delete the TLSCipherSuite from openldap. Tobias 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. > > Tomas > > On...

...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. Tobias 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...

...gt; differences, that is correct no differences. > Here is a link to the ldap.conf > https://gwarband.de/openldap/ldap.conf > And the output of ldapsearch under dovecot: > https://gwarband.de/openldap/ldapsearch-dovecot.log > > Tobias > > Am 2017-03-20 11:00, schrieb Tomas Habarta: >> I've finally managed that running on Debian 8 test machine by commenting >> tls_ca_cert_file = >> option from dovecot-ldap.conf, so only >> tls = yes >> tls_require_cert = demand >> >> Not sure why is that as on my CentOS6 Dovecot works...

....log > Note: openldap waits 1 Minute before he says "TLS negotiation failure" > after the connect. > and dovecot says direct "Connect error" > > I've also delete the TLSCipherSuite from openldap. > > Tobias > > 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. >> >> Tomas...

...nldap.conf 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 I hope you can find the issue. Thanks, Tobias Am 2017-03-17 22:48, schrieb Tomas Habarta: > Hi, > > 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 us...

...andshaking 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. > > Tobias > > 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. >...

...openldap server. > The components are postfix, openxchange, apache (phpldapadmin). > > My installated software is: > Debian 8 > OpenLDAP 2.4.40 > Dovecot 2.2.13 > > I hope you can find the issue. > > Thanks, > Tobias > > Am 2017-03-17 22:48, schrieb Tomas Habarta: >> Hi, >> >> 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; f...

Hi, The question can perhaps be made more generic like this: Can dovecot generate a *specific* NDR (or an autoreply) for accounts that meet a specific criterium, such as: - user account was found under OU=to-delete,CN=company... contrary to the regular location CN=Users,CN=company... We would like to move to-be-deleted users to this container, before actually deleting them. That gives us an

Hello guys, actually I'm trying to configure dovecot to access openldap for passwordcheck. My openldap is only allow access over "secure ldap". The dovecot can communicate with the openldap server but there is maybe a failure in the sslhandshake. Additional information you can find in the logs or in the dump below. Also I have my ldap config from dovecot in the links below. I

Hi, 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

That's something you probably want to do on the edge instead of message store, so a better place might be relocated_maps if you use Postfix. With that you can easily customize your ldap search base for accounts-to-be-deleted OU... T. On Mon, Jan 29, 2018 at 06:53:20PM +0100, lists wrote: > Hi, > > The question can perhaps be made more generic like this: > > Can dovecot

Hello, just want to report a slightly confusing log entry on auth-debug level I have encountered while setting up Kerberos auth. Users are stored in ldap, Kerberos makes use of the same ldap as its backend, goal was to enable users to use their principals in addition to simple login with mailAddress/userPassword combination. Sample entry relevant attrs: --- mailAddress: sn.gn at example.com

Hello, my IdP is kind of progressive and implemented RFC9068, where all access tokens now come with typ "at+JWT". Since the setup has used local validation, I had to switch and currently use introspection endpoint. Looked around at the src and there seems to be relatively simple check of the token typ checking the only fixed value of "JWT" -- do you think you could consider