[Dovecot] Dovecot+LDAP issues
Dear list members,
I am having some problems with a LDAP passdb authentication on Dovecot. Before I forget, the specs: it's a Ubuntu 7.10 server running Dovecot 1.0.5 connecting to 2 different machines running LDAP servers: gold with OpenLDAP 2.4.19 and extra with OpenLDAP 2.4.9 (extra is a replication slave of gold).
The initial setup of dovecot was with a MySQL passdb, which is still the first passdb, now followed by my new LDAP passdb, all with a static userdb.
Here is my dovecot-ldap.conf (the LDAP passdb) (I switched the domain with example.com for privacy sake):
#Servidor hosts = gold.example.com extra.example.com tls = yes ldap_version = 3 base = ou=people,dc=example,dc=com scope = onelevel
#uid/gid user_global_uid = 5000 user_global_gid = 5000
#Bind para ler coisas dn = cn=dovecot,ou=people,dc=example,dc=com dnpass = secret sasl_bind = no sasl_mech =
#passdb: usar password lookups para autenticar utilizadores auth_bind = no pass_attrs = userPassword=password #, =userdb_home=/home/vmail/%d/%n pass_filter = (&(maildrop=%u)(mailacceptinguser=1))
default_pass_scheme = PLAIN-MD5
This setup is currently working for some tests users (the others are still being auth'ed with the old MySQL passdb).
Unfortunately, I seemed to have run into a big problem on an occasion when dovecot was unable to connect my first server (gold) and hence went to the second one (extra). Backtracking from the logs (starting with dovecot-error.log):
Mar 31 13:11:50 bunker dovecot: auth(default): LDAP: ldap_result() failed: Can't contact LDAP server Mar 31 13:11:50 bunker dovecot: auth-worker(default): LDAP: ldap_result() failed: Can't contact LDAP server
This is when the users stopped being able to login via imap, with the following message being shown on dovecot-info.log:
Mar 31 13:13:00 bunker dovecot: auth(default): ldap(user@domain.com,xxx.xxx.xxx.xxx): unknown user
(I know, an auth_debug log would be handy here, but it wasn't activated at the time). I went on to investigate and from the slapd logs I noticed that the second LDAP server (extra) was being contacted for the passdb lookups, thus proving that dovecot considered the gold to be dead (it wasn't, but that's a different matter). Anyway, the problem is that dovecot doesn't seem to be able to retrieve the user information from extra. As the slapd log shows:
Mar 31 13:41:37 extra slapd[31473]: conn=4 op=140 SRCH base="ou=people,dc=example,dc=com" scope=1 deref=0 filter="(&(?=undefined)(?=undefined))" Mar 31 13:41:37 extra slapd[31473]: conn=4 op=140 SRCH attr=userPassword Mar 31 13:41:37 extra slapd[31473]: conn=4 op=140 SEARCH RESULT tag=101 err=0 nentries=0 text=
For some reason, dovecot sends an undefined filter to extra, even though the same filter works without issues with gold (and remember they are "clones"). I just can't see how this is caused by any of my configurations!
Any ideas?
Thanks in advance,
-- Daniel Gomes
On 03/31/2010 02:59 PM, Daniel Gomes wrote:
Dear list members,
I am having some problems with a LDAP passdb authentication on Dovecot. Before I forget, the specs: it's a Ubuntu 7.10 server running Dovecot 1.0.5 connecting to 2 different machines running LDAP servers: gold with OpenLDAP 2.4.19 and extra with OpenLDAP 2.4.9 (extra is a replication slave of gold).
The initial setup of dovecot was with a MySQL passdb, which is still the first passdb, now followed by my new LDAP passdb, all with a static userdb.
Here is my dovecot-ldap.conf (the LDAP passdb) (I switched the domain with example.com for privacy sake):
#Servidor hosts = gold.example.com extra.example.com tls = yes ldap_version = 3 base = ou=people,dc=example,dc=com scope = onelevel
#uid/gid user_global_uid = 5000 user_global_gid = 5000
#Bind para ler coisas dn = cn=dovecot,ou=people,dc=example,dc=com dnpass = secret sasl_bind = no sasl_mech =
#passdb: usar password lookups para autenticar utilizadores auth_bind = no pass_attrs = userPassword=password #, =userdb_home=/home/vmail/%d/%n pass_filter = (&(maildrop=%u)(mailacceptinguser=1))
default_pass_scheme = PLAIN-MD5
This setup is currently working for some tests users (the others are still being auth'ed with the old MySQL passdb).
Unfortunately, I seemed to have run into a big problem on an occasion when dovecot was unable to connect my first server (gold) and hence went to the second one (extra). Backtracking from the logs (starting with dovecot-error.log):
Mar 31 13:11:50 bunker dovecot: auth(default): LDAP: ldap_result() failed: Can't contact LDAP server Mar 31 13:11:50 bunker dovecot: auth-worker(default): LDAP: ldap_result() failed: Can't contact LDAP server
This is when the users stopped being able to login via imap, with the following message being shown on dovecot-info.log:
Mar 31 13:13:00 bunker dovecot: auth(default): ldap(user@domain.com,xxx.xxx.xxx.xxx): unknown user
(I know, an auth_debug log would be handy here, but it wasn't activated at the time). I went on to investigate and from the slapd logs I noticed that the second LDAP server (extra) was being contacted for the passdb lookups, thus proving that dovecot considered the gold to be dead (it wasn't, but that's a different matter). Anyway, the problem is that dovecot doesn't seem to be able to retrieve the user information from extra. As the slapd log shows:
Mar 31 13:41:37 extra slapd[31473]: conn=4 op=140 SRCH base="ou=people,dc=example,dc=com" scope=1 deref=0 filter="(&(?=undefined)(?=undefined))" Mar 31 13:41:37 extra slapd[31473]: conn=4 op=140 SRCH attr=userPassword Mar 31 13:41:37 extra slapd[31473]: conn=4 op=140 SEARCH RESULT tag=101 err=0 nentries=0 text=
For some reason, dovecot sends an undefined filter to extra, even though the same filter works without issues with gold (and remember they are "clones"). I just can't see how this is caused by any of my configurations!
Any ideas?
Thanks in advance,
Hi Daniel,
Are you using by any chance the slapo-rwm overlay? There is mention in openldap 2.4.13 changelog that prior versions would rewrite an undefined filter.
Have you tried issuing the exact search on both servers, using ldapseach for instance, and see if they both return the same information?
Regards,
Hugo Monteiro.
-- fct.unl.pt:~# cat .signature
Hugo Monteiro Email : hugo.monteiro@fct.unl.pt Telefone : +351 212948300 Ext.15307 Web : http://hmonteiro.net
Divisão de Informática Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa Quinta da Torre 2829-516 Caparica Portugal Telefone: +351 212948596 Fax: +351 212948548 www.fct.unl.pt apoio@fct.unl.pt
fct.unl.pt:~# _
On Wed, Mar 31, 2010 at 02:59:28PM +0100, Daniel Gomes wrote:
I am having some problems with a LDAP passdb authentication on Dovecot. Before I forget, the specs: it's a Ubuntu 7.10 server running Dovecot 1.0.5 connecting to 2 different machines running LDAP servers: gold with OpenLDAP 2.4.19 and extra with OpenLDAP 2.4.9 (extra is a replication slave of gold).
If you can replicate this problem on a test IMAP box pointing to the same two LDAP servers, it might be worth checking whether dovecot-1.2.11 has the same problem. At least, there are more people on this list who would be able to replicate it using current code.
Also, you could try swapping master and slave around in the dovecot-ldap.conf (i.e. try extra first, then gold). You state that the two LDAP databases are clones, but they are running different versions of openldap, so may behave differently.
Regards,
Brian.
P.S. Unrelated, but I hope you're aware that Ubuntu 7.10 went out of support on Apr 18th last year? https://wiki.ubuntu.com/Releases
Hey there,
first of all, sorry for the late reply, the long easter weekend got in the way... Answering your questions:
Em 31-03-2010 17:13, Hugo Monteiro escreveu:
Hi Daniel,
Are you using by any chance the slapo-rwm overlay? There is mention in openldap 2.4.13 changelog that prior versions would rewrite an undefined filter.
No, but I'm using the dynlist overlay.
Have you tried issuing the exact search on both servers, using ldapseach for instance, and see if they both return the same information?
Yes, I tried it often and they always return the same information (provided the changes aren't very recent, since the extra server updates itself every 6 hours). Like I mentioned, the extra server got an undefined filter, so it really looks like a client side (ie. dovecot) issue and not a server issue.
Regards,
Hugo Monteiro.
Em 01-04-2010 08:55, Brian Candler escreveu:
On Wed, Mar 31, 2010 at 02:59:28PM +0100, Daniel Gomes wrote:
I am having some problems with a LDAP passdb authentication on Dovecot. Before I forget, the specs: it's a Ubuntu 7.10 server running Dovecot 1.0.5 connecting to 2 different machines running LDAP servers: gold with OpenLDAP 2.4.19 and extra with OpenLDAP 2.4.9 (extra is a replication slave of gold).
If you can replicate this problem on a test IMAP box pointing to the same two LDAP servers, it might be worth checking whether dovecot-1.2.11 has the same problem. At least, there are more people on this list who would be able to replicate it using current code.
I set up my test box (Ubuntu 9.04) with dovecot 1.1.11 (it's the one available on repositories) and with the same configuration as the production server**, and everything seems to work fine. I tried:
- Both LDAP servers up: as expected, no troubles here
- I stopped the first LDAP server (gold) and verified that after losing the connection, dovecot went to the second server (extra) and I was also able to authenticate (I verified extra's slapd logs to make sure it was really querying it).
- I restarted gold's LDAP and killed extra's, and dovecot went back to (successfully) authenticating users against gold's LDAP.
**: the only difference in the server's configurations is the use of TLS: I had my main dovecot server with TLS activated (that is, it would use safe connections to the LDAP servers) but it seems to fail randomly on some occasions (even with other tools such as phpLDAPadmin, although it seems to work fine with the ldap* tools). So in my main dovecot server I set "tls = no" when I first had these issues, whereas on the test machine I decided to try it with tls ("tls = yes"). But like I mentioned, the troubles came when using TLS, so trying it on the test machine with TLS enabled just helps proving it ain't its fault.
Also, you could try swapping master and slave around in the dovecot-ldap.conf (i.e. try extra first, then gold). You state that the two LDAP databases are clones, but they are running different versions of openldap, so may behave differently.
I tried this too, and it also worked. I then killed extra's LDAP (now the first on the list) and dovecot successfully authenticated against gold's ldap. I then also killed that server, after which I obviously couldn't login. As expected, bringing extra's LDAP back on restored functionality. As a final test, I re-did these steps (logging in with both LDAPs on, killing the first and then logging in again) with my production server, and it also worked fine.
It really just looks like a random error (I almost wrote "bug" here but I don't want to blame it on dovecot itself just yet ;-) ) which won't be so easy to reproduce. My fear here is that it will randomly (even if not often) happen while in production and basically bring down the mail system with it (you can imagine the angry "costumers" hehe). Of course I will leave the MySQL passdb after the LDAP one as a safeguard, so that setup should minimize the chances of a total service failure...
Regards,
Brian.
P.S. Unrelated, but I hope you're aware that Ubuntu 7.10 went out of support on Apr 18th last year? https://wiki.ubuntu.com/Releases
Thanks for the heads up! We (and by "we" I mean "me") are slowly upgrading our servers for the latest LTS version (Hardy), but it's still a work in progress.... You reckon the old Ubuntu/dovecot version is contributing to the issue here?
Cheers,
-- Daniel Gomes (SysAdmin) dgomes@ipfn.ist.utl.pt Ext. 3487 - 218419487
Instituto de Plasmas e Fusão Nuclear Instituto Superior Técnico - UTL Av. Rovisco Pais - 1049-001 Lisboa - Portugal
On Mon, Apr 05, 2010 at 11:16:04AM +0100, Daniel Gomes wrote:
P.S. Unrelated, but I hope you're aware that Ubuntu 7.10 went out of support on Apr 18th last year? https://wiki.ubuntu.com/Releases
Thanks for the heads up! We (and by "we" I mean "me") are slowly upgrading our servers for the latest LTS version (Hardy), but it's still a work in progress.... You reckon the old Ubuntu/dovecot version is contributing to the issue here?
Probably not the old Ubuntu, but quite possibly the old dovecot.
There's Lucid LTS just around the corner, although your old Gutsy will need to be updated to Hardy first anyway.
On Wed, Mar 31, 2010 at 02:59:28PM +0100, Daniel Gomes wrote:
Unfortunately, I seemed to have run into a big problem on an occasion when dovecot was unable to connect my first server (gold) and hence went to the second one (extra).
I set up a simple test by configuring
hosts = 10.1.1.1 x.x.x.xwhere x.x.x.x is the real ldap server, and 10.1.1.1 is a non-existent host, and then restarted dovecot.
It took dovecot a minute or two to timeout connecting to the first one (during which time an incoming POP3 connection just waited), and then it connected to the second one and from then on authenticated happily.
This is dovecot-1.2.11 under FreeBSD 7.2
So I would suspect that your second LDAP server really is behaving differently.
Actually I forgot the obvious test: just put a single entry in your dovecot-ldap.conf, firstly hosts = gold and secondly hosts = extra, restarting dovecot after each change of course. Then see how the authentication goes. If it works consistently with one and fails consistently with the other, then clearly it's not an issue with failover.
Regards,
Brian.
participants (3)
-
Brian Candler
-
Daniel Gomes
-
Hugo Monteiro