[Dovecot] Internal login failure
I have discovered an odd problem; some users are able to connect to Dovecot either via pop3 or imap without any problems. Other users, however, aren't, and the following message appears in /var/log/mail.log:
dovecot-auth: Login process 13 connected dovecot-auth: Login process 13 sent handshake: PID 1313 pop3-login: Internal login failure: user@mydomain.tld [195.242.16.30] dovecot: child 1311 (auth) killed with signal 11
I'm using Dovecot 0.99.11 (Debian Sarge), and all user information is stored in an LDAP database. Any suggestions? Thanks, :Peter
Hello,
From: Peter Clark peter-clark@bethel.edu Subject: [Dovecot] Internal login failure Date: Wed, 5 Jan 2005 06:29:47 +0300
I'm using Dovecot 0.99.11 (Debian Sarge), and all user information is stored in an LDAP database. Any suggestions?
Some bugs are fixed at ldap module after dovecot-0.99.11. Please check dovecot-0.99.12 or dovecot-1.0-test59.
regards,
Kazuo Moriwaka moriwaka@valinux.co.jp
On Wednesday 05 January 2005 07:09, Kazuo Moriwaka wrote:
I'm using Dovecot 0.99.11 (Debian Sarge), and all user information is stored in an LDAP database. Any suggestions?
Some bugs are fixed at ldap module after dovecot-0.99.11. Please check dovecot-0.99.12 or dovecot-1.0-test59. Out of curiosity, what exactly were the nature of the bugs? I'm stumped because it's so random; half of the users don't have any problems, while the other half does. As far as Dovecot is concerned, the only fields are uid, userPassword, mailAddress, and status. I've been over those, and can't see anything wrong. I even deleted the account for a user that wasn't able to log in, took the LDIF for a user that worked, and changed only the uid, password, and mailAddress for the first user, and got the same results. It's like the users have been mysteriously blacklisted by Dovecot, only because of their name! :Peter
Hello,
From: Peter Clark peter-clark@bethel.edu Subject: Re: [Dovecot] Internal login failure Date: Wed, 5 Jan 2005 15:09:07 +0300
On Wednesday 05 January 2005 07:09, Kazuo Moriwaka wrote:
I'm using Dovecot 0.99.11 (Debian Sarge), and all user information is stored in an LDAP database. Any suggestions?
Some bugs are fixed at ldap module after dovecot-0.99.11. Please check dovecot-0.99.12 or dovecot-1.0-test59. Out of curiosity, what exactly were the nature of the bugs? I'm stumped
It was lack and excess of i_free().
because it's so random; half of the users don't have any problems, while the other half does. As far as Dovecot is concerned, the only fields are uid, userPassword, mailAddress, and status. I've been over those, and can't see anything wrong. I even deleted the account for a user that wasn't able to log in, took the LDIF for a user that worked, and changed only the uid, password, and mailAddress for the first user, and got the same results. It's like the users have been mysteriously blacklisted by Dovecot, only because of their name!
This maybe a new bug.
Please make a backtrace log as this page: http://www.dovecot.org/bugreport.html And please show some sample LDIF entries which does and doesn't cause this problem. It may be a help.
best regards,
Kazuo Moriwaka moriwaka@valinux.co.jp
On Thursday 06 January 2005 06:29, Kazuo Moriwaka wrote:
Please make a backtrace log as this page: http://www.dovecot.org/bugreport.html And please show some sample LDIF entries which does and doesn't cause this problem. It may be a help. When I ran 'gdb /usr/lib/dovecot/imap-login' I got "No debugging symbols found". Then I realized that since it's a Debian package, it's already been stripped. So let's try LDIF before I attempt to recompile the whole thing. The output of slapcat, first for a virtual account that works:
dn: uid=peter,ou=mailAccounts,dc=mydomain,dc=tld objectClass: userAccount objectClass: mailAccount uid: peter sn: Clark cn: Peter Clark userPassword:: <Removed> status: active mailAddress: peter@mydomain.tld mailDir: peter/Maildir/ structuralObjectClass: userAccount entryUUID: fc2c9e7e-f3f2-1028-858c-8ebe993cc366 creatorsName: cn=admin,dc=mydomain,dc=tld createTimestamp: 20050106055308Z entryCSN: 2005010605:53:08Z#0x0001#0#0000 modifiersName: cn=admin,dc=mydomain,dc=tld modifyTimestamp: 20050106055308Z
and now for an account that doesn't work:
dn: uid=natashia,ou=mailAccounts,dc=forrussia,dc=org objectClass: userAccount objectClass: mailAccount uid: natashia sn: Lastname cn: Natashia Lastname status: active mailAddress: natashia@mydomain.tld mailDir: natashia/Maildir/ structuralObjectClass: userAccount entryUUID: ad280f4a-f3f5-1028-9c71-f50f432a581f creatorsName: cn=admin,dc=mydomain,dc=tld createTimestamp: 20050106061224Z userPassword:: <Removed> entryCSN: 2005010606:14:20Z#0x0001#0#0000 modifiersName: cn=admin,dc=mydomain,dc=tld modifyTimestamp: 20050106061420Z
:Peter
Hello,
From: Peter Clark peter-clark@bethel.edu Subject: Re: [Dovecot] Internal login failure Date: Thu, 6 Jan 2005 09:39:14 +0300
stripped. So let's try LDIF before I attempt to recompile the whole thing. The output of slapcat, first for a virtual account that works:
dn: uid=peter,ou=mailAccounts,dc=mydomain,dc=tld ... and now for an account that doesn't work:
dn: uid=natashia,ou=mailAccounts,dc=forrussia,dc=org
I found dc fields are different between them.
- What is your LDAP server's root dn?
- Can you find natashia's entry by ldapsearch? (slapadd and slapcat doesn't mind which entry dn is match for tree or not)
- Can you find natashia's entry by ldapsearch?
regards,
Kazuo Moriwaka moriwaka@valinux.co.jp
On Thursday 06 January 2005 10:01, Kazuo Moriwaka wrote:
I found dc fields are different between them. - What is your LDAP server's root dn? - Can you find natashia's entry by ldapsearch? (slapadd and slapcat doesn't mind which entry dn is match for tree or not) - Can you find natashia's entry by ldapsearch? Oops, my bad, I was trying to hide the original root dn. I wiped out the LDAP database and started over,adding one account at a time, and somehow in the process everything corrected itself. For the life of me, I can't figure out what I changed, since I entered in the same information. I'll investigate further, and if I can pin the blame more specifically on something, I'll let you know. :Peter
On Thursday 06 January 2005 11:35, Peter Clark wrote:
I'll investigate further, and if I can pin the blame more specifically on something, I'll let you know. Ok, the problem was actually in the LDAP schema that was being used. (It was taken from an obscure project; I'll email the authors and let them know.) It used the SUP keyword incorrectly, refering to an attribute, rather than an object. I don't know why it threw Dovecot off, since SASL and Postfix seemed to have handled it gracefully, but correcting the schema fixed everything. If anyone wants to know more details, I would be willing to provide them, but otherwise, case closed. :Peter
participants (2)
-
Kazuo Moriwaka
-
Peter Clark