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 at 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 at 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 at 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 at 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
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.x where 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.