Help with new setup
I'm using Cyrus-Imap for about a decade and it just works - so much that I lost most of the administration knowledge I once had. ;) However, the new setup should be different in a couple of ways, and I'm asking for best practices, howtos, and other write-ups that I should consider to achieve the following goals: 1) Users shall authenticate to Samba4 AD, ideally use Kerberos. 2) I did Kerberos authentication in the original setup already, just to find out that virtually no client (most systems run Linux) supported it. Has this improved? 3) Users, i.e. AD entities, should be able to manage several distinct mail accounts, like a private and work account. 4) Functional mailboxes, which do not exactly belong to any user, but must be accessible by multiple users. 5) Sieve support using the same authentication. Thanks for any reading pointers, - lars. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: GSSAPI authentication ceased working
Hi Michael, Shot in the dark here, but are you using AFS? If so, you can run into some nasty things if it tries to grab libraries out of AFS that you have access to when you have AFS tokens, but which become unavailable when they expire. You start up the process with the tokens, but when you log back in, you obtain tokens for yourself, but not the PAG that the process started in. There are strange things out there. Thanks for the idea, but I definitely have never used AFS and nothing is installed, which I would associate with AFS. BTW: It's still not working. I put it to PRI2, since the important ldapdb stuff is running. Kerberized imap is rarely used here, so people can do without. But still I'd like to understand, what is happening. Regards, - lars. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ldapdb auxprop configuration
Hi all! Sorry for cross-posting, but since this appears to be SASL related, I switch to the SASL list and leave this message in the cyrus-imap list for others to follow. So when answering to this, please check that you're not crossposting the answer. Summary for the SASL list subscribers, who have missed the start of this thread: I'm running cyrus-imap to authenticate users using the ldapdb auxprop against a remote ldaps: host. During the DIGEST-MD5 or CRAM-MD5 authentication of the user using imtest imapd SEGFAULTs. The ltrace suggests that it happens somewhere in the SASL layer. The setup is Debian Lenny kept current daily on an Intel Core2-Quad, i.e. amd64 build. @ Torsten Schlabach: One comment suggested that the problem might be one of the Debian specific patches! Did you try to build a package without them? Not yet, but I'm determined to get that issue resolved. One of the larger problems could be that Debian uses GnuTLS instead of OpenSSL. I had some severe issues with that kind of porting some years back with OpenLDAP. @ Dan White: I produced debugging versions of cyrus-imap , cyrus-sasl, and openldap and created a backtrace of the crash. See the end of this message. @ cyrus-imap list For some reason the method using the debug_command in /etc/imapd.conf and the -D option for imapd in /etc/cyrus.conf as described in https://langhorst.com/cgi-bin/dwww//usr/share/doc/cyrus21-common/README.Debian.debug.gz does not work, i.e. it does not produce any logs in /tmp. Am I missing something? So what I did was to use CYRUS_VERBOSE=100 in /etc/default/cyrus2.2 and used the 15 second delay to attach a gdb. The following happened and produced the backtrace of the SEGFAULT: hermod:/# imtest -u cyrus -a cyrus -v -p imap -m DIGEST-MD5 hermod.mgr S: * OK hermod.mgr Cyrus IMAP4 v2.2.13-Debian-2.2.13-14 server ready C: C01 CAPABILITY S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE STARTTLS AUTH=NTLM AUTH=DIGEST-MD5 AUTH=CRAM-MD5 SASL-IR S: C01 OK Completed C: A01 AUTHENTICATE DIGEST-MD5 S: + bm9uY2U9IjNFZzIrY2xsci84dmREdXprTkd3a1VmL25XYTRBVnRXQmMxSGpndFBiVEk9IixyZWFsbT0iaGVybW9kLm1nciIscW9wPSJhdXRoLGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAscmM0LTU2LHJjNCxkZXMsM2RlcyIsbWF4YnVmPTQwOTYsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3M= Please enter your password: C: dXNlcm5hbWU9ImN5cnVzIixyZWFsbT0iaGVybW9kLm1nciIsbm9uY2U9IjNFZzIrY2xsci84dmREdXprTkd3a1VmL25XYTRBVnRXQmMxSGpndFBiVEk9Iixjbm9uY2U9IjluczF0dmwwMUhWU095dzlNZXRXK0ltRnVyWHRINDd4TFhyUjEvcXpNZHM9IixuYz0wMDAwMDAwMSxxb3A9YXV0aC1jb25mLGNpcGhlcj1yYzQsbWF4YnVmPTEwMjQsZGlnZXN0LXVyaT0iaW1hcC9oZXJtb2QubWdyIixyZXNwb25zZT1lZmYxZjk2MjUyNzlmY2UyMDY3MmIxOTg1NjIzZmIwYw== failure: prot layer failure Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fa6ca1e3700 (LWP 5409)] 0x7fa6c72ed4aa in pthread_mutex_lock () from /lib/libpthread.so.0 (gdb) bt #0 0x7fa6c72ed4aa in pthread_mutex_lock () from /lib/libpthread.so.0 #1 0x7fa6c32b75a9 in ldap_pvt_thread_mutex_lock (mutex=0x1) at /home/admin/packages/openldap/openldap-2.4.11/libraries/libldap_r/thr_posix.c:296 #2 0x7fa6c32c112b in ldap_pvt_sasl_mutex_lock (mutex=0x1) at cyrus.c:1294 #3 0x7fa6c4b69828 in digestmd5_client_mech_step (conn_context=0x2094440, params=0x20960b0, serverin=0x0, serverinlen=0, prompt_need=0x7fffd21e8760, clientout=0x7fffd21e8748, clientoutlen=0x7fffd21e875c, oparams=0x209a510) at digestmd5.c:3955 #4 0x7fa6c9dc25e6 in sasl_client_step (conn=0x2099ca0, serverin=0x0, serverinlen=0, prompt_need=0x7fffd21e8760, clientout=0x7fffd21e8748, clientoutlen=0x7fffd21e875c) at client.c:658 #5 0x7fa6c9dc2445 in sasl_client_start (conn=0x2099ca0, mechlist=0x2041d40 DIGEST-MD5, prompt_need=0x7fffd21e8760, clientout=0x7fffd21e8748, clientoutlen=0x7fffd21e875c, mech=0x7fffd21e8778) at client.c:606 #6 0x7fa6c32bfc79 in ldap_int_sasl_bind (ld=0x2053880, dn=0x0, mechs=0x2041d40 DIGEST-MD5, sctrls=0x0, cctrls=0x0, flags=2, interact=0x7fa6c34fd704 ldapdb_interact, defaults=0x204dce0) at cyrus.c:689 #7 0x7fa6c32c3b7f in ldap_sasl_interactive_bind_s (ld=0x2053880, dn=0x0, mechs=0x2041d40 DIGEST-MD5, serverControls=0x0, clientControls=0x0, flags=2, interact=0x7fa6c34fd704 ldapdb_interact, defaults=0x204dce0) at sasl.c:464 #8 0x7fa6c34fd96c in ldapdb_connect (ctx=0x204dce0, sparams=0x20516c0, user=0x2052f71 cyrus, ulen=5, cp=0x7fffd21e8910) at ldapdb.c:106 #9 0x7fa6c34fdd45 in ldapdb_auxprop_lookup (glob_context=0x204dce0, sparams=0x20516c0, flags=0, user=0x2052f71 cyrus, ulen=5) at ldapdb.c:178 #10 0x7fa6c9dbe881 in _sasl_auxprop_lookup (sparams=0x20516c0, flags=0, user=0x2052f71 cyrus, ulen=5) at auxprop.c:898 #11 0x7fa6c9dbf309 in _sasl_canon_user (conn=0x20521d0, user=0x2052f71 cyrus, ulen=5, flags=1, oparams=0x2052a40) at canonusr.c:190 #12 0x7fa6c4b6556b in
Re: ldapdb auxprop configuration
Hi there, For some reason the method using the debug_command in /etc/imapd.conf and the -D option for imapd in /etc/cyrus.conf as described in https://langhorst.com/cgi-bin/dwww//usr/share/doc/cyrus21-common/README.Debian.debug.gz does not work, i.e. it does not produce any logs in /tmp. Am I missing something? Sorry, after dumping /etc/cyrus.conf another time I found that -D was in the wrong place on the command line. Now it works. Regards, - lars. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ldapdb auxprop configuration
_S_eems we're coming closer ...
'signaled to death by 11' is a big red flag... your imapd process is
seg faulting. It's possibly caused by an old SASL/OpenLDAP reentrant
bug (are you running an old version of libldap?).
Looking at SASL Bug 3032
http://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3032 and Debian Bug
#409495 it looks quite like that. Both bugs are not resolved according
to the bugtrackers. The install is Lenny current as per today. These are
the relevant packages:
hermod:/# dpkg -l '*cyrus*' | grep '^ii'
ii cyrus-admin-2.2 2.2.13-14 Cyrus mail
system (administration tools)
ii cyrus-clients-2.2 2.2.13-14+b3 Cyrus mail
system (test clients)
ii cyrus-common-2.22.2.13-14+b3 Cyrus mail
system (common files)
ii cyrus-imapd-2.2 2.2.13-14+b3 Cyrus mail
system (IMAP support)
ii libcyrus-imap-perl222.2.13-14+b3 Interface
to Cyrus imap client imclient libr
hermod:/# dpkg -l '*ldap*' | grep '^ii'
ii ldap-utils 2.4.11-1 OpenLDAP
utilities
ii libldap-2.4-2 2.4.11-1 OpenLDAP
libraries
hermod:/# dpkg -l '*sasl*' | grep '^ii'
ii libsasl2-2 2.1.22.dfsg1-23 Cyrus SASL
- authentication abstraction libr
ii libsasl2-modules2.1.22.dfsg1-23 Cyrus SASL
- pluggable authentication module
ii libsasl2-modules-gssapi-mit 2.1.22.dfsg1-23 Cyrus SASL
- pluggable authentication module
ii libsasl2-modules-ldap 2.1.22.dfsg1-23 Cyrus SASL
- pluggable authentication module
ii sasl2-bin 2.1.22.dfsg1-23 Cyrus SASL
- administration programs for SASL
The Debian Bugtracker has it that avoiding DIGEST-MD5 would work around
the bug. So I removed that MECH and eventually replaced it with
CRAM-MD5, but the SEGFAULT persists.
You can specify a debug_command in your imapd.conf to generate a back
trace. See:
https://langhorst.com/cgi-bin/dwww//usr/share/doc/cyrus21-common/README.Debian.debug.gz
Okay, if the error is known and open, it's worth the while to create a
debugging version of probably all the packages. Does anyone know more
about the current state of the bug? I could supply an OpenVZ Container,
which readily produces it. ;)
The strace ends in:
15:42:19.940818 poll([{fd=16, events=POLLIN}], 1, 5000) = 1 ([{fd=16,
revents=POLLIN}])
15:42:19.940883 ioctl(16, FIONREAD, [83]) = 0
15:42:19.940917 recvfrom(16,
\263\225\205\200\0\1\0\1\0\1\0\0\0013\0016\00216\003172\7in-addr\4a...,
1024, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(172.16.6.3)}, [16]) = 83
15:42:19.940973 close(16) = 0
15:42:19.941020 uname({sys=Linux, node=hermod.mgr, ...}) = 0
15:42:19.941095 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
So the last thing done successfully is a DNS query for the LDAP server.
The ltrace is a little more informative. However, it looks like the
SEGFAULT is somewhere in SASL, probably the thread should continue there ...
3922 15:46:41.771218 read(0, dXNlcm5hbWU9ImN5cnVzIixyZWFsbT0i...,
4096) = 354
3922 15:46:41.771278 strlen() = 0
3922 15:46:41.771321 strncasecmp(0x7fffc67534d0, 0x46193b, 0, 5, 22) = 0
3922 15:46:41.771380 strlen() = 0
3922 15:46:41.771423 strlen(dXNlcm5hbWU9ImN5cnVzIixyZWFsbT0i...) = 352
3922 15:46:41.771470 sasl_decode64(0x7fffc67534d0, 352, 0x7fffc67534d0,
21848, 0x7fffc6758a3c) = 0
3922 15:46:41.771520 sasl_server_step(0x1f48140, 0x7fffc67534d0, 262,
0x7fffc6758a30, 0x7fffc6758a38 unf
inished ...
3922 15:46:41.771554 malloc(250) = 0x1f4a260
3922 15:46:41.771631 malloc(263) = 0x1f4a260
3922 15:46:41.771680 malloc(6)= 0x1f4a370
3922 15:46:41.771722 malloc(11) = 0x1f4a390
3922 15:46:41.771763 malloc(45) = 0x1f4a3b0
3922 15:46:41.771805 malloc(45) = 0x1f4a3f0
3922 15:46:41.771847 malloc(10) = 0x1f4a430
3922 15:46:41.771891 malloc(4)= 0x1f4a450
3922 15:46:41.771933 malloc(16) = 0x1f4a470
3922 15:46:41.771975 malloc(33) = 0x1f49b20
3922 15:46:41.772018 malloc(1219) = 0x1f4a490
3922 15:46:41.772061 memcpy(0x1f48ee1, cyrus, 5)= 0x1f48ee1
3922 15:46:41.772105 strlen(cyrus) = 5
3922 15:46:41.772148 strlen(cyrus) = 5
3922 15:46:41.772193 strcmp(unix, unix) = 0
3922 15:46:41.772241 strlen(cyrus) = 5
3922 15:46:41.772283 memmove(0x6fc420, 0x1f48ee1, 5, 2, 1)= 0x6fc420
3922 15:46:41.772333
GSSAPI authentication ceased working
I'm currently setting up a new imap server to replace my old one.
Yesterday I had GSSAPI authentication running, today it ceased working.
I did quite some configuration in the meantime mostly on the LDAP
server, but nothing I'd readily associate with cyrus-imap authentication.
I appreciate any ideas for more systematic troubleshooting.
Regards,
- lars.
The setup:
KDC and LDAP is a sever called hel. The KDC uses LDAP as backend.
Cyrus-Imap (v2.2.13-Debian-2.2.13-14+b3) runs on hermod.
What worked yesterday:
kinit cyrus
imtest -v -u cyrus -a cyrus -p imap -r MGR hermod.mgr
cyradm --user cyrus --auth GSSAPI --server hermod.mgr
What still works today:
kinit cyrus
Diagnostics:
# kinit cyrus
hermod:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: cy...@mgr
Valid starting ExpiresService principal
01/02/09 16:41:41 01/03/09 02:41:41 krbtgt/m...@mgr
renew until 01/03/09 16:41:41
Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
hermod:~# imtest -v -u cyrus -a cyrus -p imap -r MGR hermod.mgr
S: * OK hermod.mgr Cyrus IMAP4 v2.2.13-Debian-2.2.13-14+b3 server ready
C: C01 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS ID
NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT
THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE STARTTLS AUTH=GSSAPI
AUTH=NTLM AUTH=DIGEST-MD5 AUTH=CRAM-MD5 SASL-IR
S: C01 OK Completed
Authentication failed. generic failure
Security strength factor: 0
C: Q01 LOGOUT
* BYE LOGOUT received
Q01 OK Completed
Connection closed.
hermod: /var/log/auth.log
Jan 2 17:07:54 hermod imtest: GSSAPI Error: Unspecified GSS failure. Minor
code may provide more information (Decrypt integrity check failed)
hel: /var/log/syslog
Jan 2 16:07:54 hel krb5kdc[1652]: TGS_REQ (7 etypes {18 17 16 23 1 3 2})
172.16.6.5: PROCESS_TGS: authtime 0, unknown client for imap/hermod@mgr,
Decrypt integrity check failed
Jan 2 16:07:54 hel last message repeated 3 times
What I tried:
Since Decrypt integrity check failed means wrong password I recreated the
principal imap/hermod.mgr and replaced the keytab file with the new key. I
also removed the ldapdb auxprop, which I had installed in the meantime, but
nothing helped.
If I remove the ticket for cyrus, I receive:
Jan 2 17:13:36 hermod imtest: GSSAPI Error: Unspecified GSS failure. Minor
code may provide more information (No credentials cache found)
as I would expect.
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
ldapdb auxprop configuration
I'm trying set up cyrus-imap using the ldapdb auxprop. I guess I've the LDAP part up and running, but somehow imap does not really request for authentication. So probably I still have something messed in the configuration, which apparently has changed with respect to my last install a couple of years ago. Any ideas for systematic troubleshooting are welcome. Regards, - lars. This is the sasl related part of the imap configuration: hermod:~# grep sasl /etc/imapd.conf | grep -v '^#' | grep -v '^\s*$' sasl_mech_list: PLAIN DIGEST-MD5 CRAM-MD5 sasl_pwcheck_method: auxprop sasl_auxprop_plugin: ldapdb sasl_ldapdb_uri: ldaps://hel.mgr sasl_ldapdb_id: mailadmin sasl_ldapdb_pw: * sasl_ldapdb_mech: DIGEST-MD5 sasl_auto_transition: no The following is running as expected: hermod:~# ldapwhoami -U mailadmin -X u:cyrus -W -Y DIGEST-MD5 -H ldaps://hel.mgr Enter LDAP Password: SASL/DIGEST-MD5 authentication started SASL username: u:cyrus SASL SSF: 128 SASL data security layer installed. dn:uid=cyrus,ou=mailbox,dc=mgr and of course: ldapsearch -U mailadmin -X u:cyrus -W -Y DIGEST-MD5 -b ou=mailbox,dc=mgr (uid=cyrus) returns the password of cyrus, which is kept as plaintext inside the LDAP repositiory. ldapsearch returns the base64 encoded plain password. However using this same password the following happens: hermod:~# imtest -v -u cyrus -a cyrus -p imap -m DIGEST-MD5 hermod.mgr S: * OK hermod.mgr Cyrus IMAP4 v2.2.13-Debian-2.2.13-14+b3 server ready C: C01 CAPABILITY S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE STARTTLS AUTH=DIGEST-MD5 AUTH=CRAM-MD5 SASL-IR S: C01 OK Completed C: A01 AUTHENTICATE DIGEST-MD5 S: + bm9uY2U9IlBMREhNY0JjbG1XOUt2dk5FQWQrb0R5cmZ3YjY3cHcyb1VIWHhacDE0dXc9IixyZWFsbT0iaGVybW9kLm1nciIscW9wPSJhdXRoLGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAscmM0LTU2LHJjNCxkZXMsM2RlcyIsbWF4YnVmPTQwOTYsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3M= Please enter your password: C: dXNlcm5hbWU9ImN5cnVzIixyZWFsbT0iaGVybW9kLm1nciIsbm9uY2U9IlBMREhNY0JjbG1XOUt2dk5FQWQrb0R5cmZ3YjY3cHcyb1VIWHhacDE0dXc9Iixjbm9uY2U9IkVZR2hkY1UvZy9vU0J5VkNsMkhSVWt3NWVuMTlOR3puWU9PQjZuSUpPams9IixuYz0wMDAwMDAwMSxxb3A9YXV0aC1jb25mLGNpcGhlcj1yYzQsbWF4YnVmPTEwMjQsZGlnZXN0LXVyaT0iaW1hcC9oZXJtb2QubWdyIixyZXNwb25zZT00Yjk3OWJhMTU0NWUzZDBkMTJiYWNlNjY4NTk4YjhjZA== failure: prot layer failure The detailed log of slapd has the following for this request: slap_listener_activate(10): slap_listener(ldaps:///) conn=15 fd=24 ACCEPT from IP=172.16.6.5:53956 (IP=0.0.0.0:636) connection_get(24): got connid=15 connection_read(24): checking for input on id=15 connection_get(24): got connid=15 connection_read(24): checking for input on id=15 connection_get(24): got connid=15 connection_read(24): checking for input on id=15 connection_get(24): got connid=15 connection_read(24): checking for input on id=15 connection_read(24): unable to get TLS client DN, error=49 id=15 conn=15 fd=24 TLS established tls_ssf=128 ssf=128 connection_get(24): got connid=15 connection_read(24): checking for input on id=15 ber_get_next ber_get_next on fd 24 failed errno=0 (Success) connection_closing: readying conn=15 sd=24 for close connection_close: conn=15 sd=24 conn=15 fd=24 closed (connection lost) So apparently imapd-ldapdb connects and establishes SSL. For the rest I'm unsure, but it seems like it does not talk to LDAP anymore and terminates, i.e. there is no authentication happening. The result is the same for trying telnet localhost imap2 and a login for cyrus. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ldapdb auxprop configuration
Thanks Dan, To make sure that the ldapdb plugin is installed correctly: # cat /usr/lib/sasl2/pluginview.conf # pluginviewer | grep ldapdb hermod:/# grep sasl /etc/imapd.conf | grep -v '^#' | grep -v '^\s*$' | sed 's/^sasl_//' /usr/lib/sasl2/pluginviewer.conf hermod:/# saslpluginviewer -a Installed auxprop mechanisms are: ldapdb sasldb List of auxprop plugins follows Plugin ldapdb , API version: 4 supports store: yes Plugin sasldb , API version: 4 supports store: yes Didn't know this tool so far. Should it say something different? Does your /var/log/auth.log or /var/log/syslog give you anything useful? At least it's not too useful to me ... (after setting sasl_log_level: 7) /var/log/auth.log: Jan 2 22:31:15 hermod cyrus/imap[3432]: DIGEST-MD5 server step 1 Jan 2 22:31:15 hermod imtest: DIGEST-MD5 client step 2 Jan 2 22:31:17 hermod imtest: DIGEST-MD5 client step 2 Jan 2 22:31:17 hermod cyrus/imap[3432]: DIGEST-MD5 server step 2 /var/log/syslog: Jan 2 22:31:15 hermod cyrus/master[3432]: about to exec /usr/lib/cyrus/bin/imapd Jan 2 22:31:15 hermod cyrus/imap[3432]: executed Jan 2 22:31:15 hermod cyrus/imap[3432]: accepted connection Jan 2 22:31:17 hermod cyrus/master[3425]: process 3432 exited, signaled to death by 11 Jan 2 22:31:17 hermod cyrus/master[3425]: service imap pid 3432 in BUSY state: terminated abnormally You may want to experiment with the ldapdb_starttls and ldapdb_rc options (see sasl's options.html doc). See 'man ldap.conf' for options that you can place in ldaprc. If you do choose to use starttls, you'll need to replace ldaps://hel.mgr with ldap://hel.mgr. I tried sasl_ldapdb_uri: ldap://hel.mgr sasl_ldapdb_starttls: try and it comes out the same; slapd logs a successful STARTTLS. I tried: sasl_ldapdb_rc: /etc/ldap/ldap.conf which yields sending short packages in both cases. This slapd debug output is from a STARTTLS variant: TLS: can't accept: A TLS packet with unexpected length was received.. connection_read(16): TLS accept failure error=-1 id=8, closing connection_closing: readying conn=8 sd=16 for close connection_close: conn=8 sd=16 conn=8 fd=16 closed (TLS negotiation failure) But still imtest fails with failure: prot layer failure. There is no activity in slapd before the password is entered in imtest. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAP4 v2.1.18 no login via SSL
Hi folks, the matter appears to cross-post through every module on my machine :( Intro for the LDAP specialists: I have Cyrus-Imap SASL authenticate with ldapdb auxprop. ldapdb uses ldaps:// for the LDAP server. All works well if I try with telnet mail imap, or even with openssl s_client -connect mail:imaps, if I supply the *wrong* password. If the password however is correct, Imapd hangs in sasl_checkpass() eating CPU to never return. The arguments passed to SASL are identical to the telnet case. The number of calls to the SASL auxprop-lookup() method are identical and all return. Involved: Cyrus IMAP4 v2.1.18, Cyrus SASL 2.1.19, openldap 2.1.30 (LDAP server is newer: stable-20050125, another machine) Is attaching with a debugger and getting a backtrace possible? Thanks Derrick, this was a great idea, would not have expected it so easy. I attached the backlog below. I have trouble tracing all of it in the code right away, would need another two or three nights maybe. But maybe someone has intimate knowledge of how the system is supposed to work. My candidate currently is #14: ldap_pvt_tls_init_def_ctx (), which appears to run in a mutex brace (ldap_pvt_thread_mutex_lock( tls_def_ctx_mutex )) for almost the whole time and to perform a lot of complicated stuff. Well too complicated for tonight. Still I have no idea, how the SSL connection mail-client - imapd could hold a TLS mutex, when imapd - slapd shall be established. However, the log entry in /var/log/mail.log: May 24 22:43:04 verdani cyrus/imapd[8733]: starttls: TLSv1 with cipher AES256-SHA (256/256 bits new) no authentication would not exclude that there is some authentication tried on the mail-client - imapd, which could nest with imapd - slapd, but that's more speculation than the stock forecast. ;) Is anybody aware of the big picture? #0 0x416cc436 in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0 #1 0x416c9893 in _L_mutex_lock_26 () from /lib/tls/libpthread.so.0 #2 0x402b1844 in mallopt () from /lib/tls/libc.so.6 #3 0x403231af in pthread_mutex_lock () from /lib/tls/libc.so.6 #4 0x404bdca1 in ldap_start_tls_s () from /usr/lib/libldap.so.2 #5 0x40580d03 in gcry_sexp_canon_len () from /usr/lib/libgcrypt.so.11 #6 0x40580e41 in gcry_sexp_canon_len () from /usr/lib/libgcrypt.so.11 #7 0x4058db5e in gcry_randomize () from /usr/lib/libgcrypt.so.11 #8 0x405896c5 in gcry_md_algo_name () from /usr/lib/libgcrypt.so.11 #9 0x405897c2 in gcry_md_open () from /usr/lib/libgcrypt.so.11 #10 0x4051ffbc in _gnutls_hash_init () from /usr/lib/libgnutls.so.11 #11 0x405197b1 in gnutls_handshake () from /usr/lib/libgnutls.so.11 #12 0x416bacb5 in gnutls_SSL_free () from /usr/lib/libldap_r.so.2 #13 0x416badda in gnutls_SSL_connect () from /usr/lib/libldap_r.so.2 #14 0x416b868e in ldap_pvt_tls_init_def_ctx () from /usr/lib/libldap_r.so.2 #15 0x416b9696 in ldap_int_tls_start () from /usr/lib/libldap_r.so.2 #16 0x416994a7 in ldap_int_open_connection () from /usr/lib/libldap_r.so.2 #17 0x416ab299 in ldap_new_connection () from /usr/lib/libldap_r.so.2 #18 0x41698f11 in ldap_open_defconn () from /usr/lib/libldap_r.so.2 #19 0x416aae0f in ldap_send_initial_request () from /usr/lib/libldap_r.so.2 #20 0x416a1137 in ldap_sasl_bind () from /usr/lib/libldap_r.so.2 #21 0x416a1b50 in ldap_simple_bind () from /usr/lib/libldap_r.so.2 --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAP4 v2.1.18 no login via SSL
Hi there, I tracked the issue down into the source code of imapd. Actually, its SASL or something even further downstream, which hangs. sasl_checkpass() in cmd_login() simply does not return (put syslogs immediately before and after) in case the correct password is supplied and I connected to imapd using imaps. changed the if around line 1917 in imapd.c syslog(LOG_NOTICE, attempting SASL pwd for %s with %s, canon_user, passwd); r = sasl_checkpass(imapd_saslconn,canon_user,strlen(canon_user),passwd,strlen(passwd)); syslog(LOG_NOTICE, SASL returned %d for %d, r, SASL_OK); interestingly the first syslog is exactly the same, no matter if I do telnet mail imap or openssl s_client -connect mail:imaps, but in the first case it returns well, in the latter it does only return, if the password is wrong. Otherwise, it hangs in running state eating lots of CPU time (99%). SASL uses the ldapdb backend to retrieve the password using ldaps. Is there anything prohibiting two simultaneous SSL connections for a single process? Can somebody with deeper SASL understanding give me some hint? Regards, - lars. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAP4 v2.1.18 no login via SSL
Hi there, just another info I forgot in my posting from May 17th: short: login via telnet works fine, login via SSL hangs after login command sent, if and only if, the correct password is supplied. imapd is capable of cleanly denying access, if the wrong password is supplied: # openssl s_client -connect mail:imaps [strip certificate stuff] Verify return code: 19 (self signed certificate in certificate chain) --- * OK verdani Cyrus IMAP4 v2.1.18-IPv6-Debian-2.1.18-1 server ready a001 login mgr foobar a001 NO Login failed: authentication failure instead of openssh s_client -connect verdani:imaps [stripped most of certificates and such] Verify return code: 19 (self signed certificate in certificate chain) --- * OK verdani Cyrus IMAP4 v2.1.18-IPv6-Debian-2.1.18-1 server ready a001 login mgr ** and it simply does not return anymore. I also tried all variants of -no_tls1 through -no_ssl3 yielding no different behaviour. It had worked fine before the last Debian update, but I actually do not know, which version it had been before, and if probably different stuff had been changed. I appreciate any help in troubleshooting - logs to check, manuals to read, good food for google, etc. Currently I'm running in circles and sometimes simply stare in wonder. Regards, - lars. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Cyrus IMAP4 v2.1.18 no login via SSL
Hi there, I came to a closer analysis of an issue I posted some time ago. For some very strange reason I can authenticate to imapd via imap, but the same procedure fails with imaps, although SSL appears to be sane. This is what happens: telnet verdani imap [stripped standard messages] * OK verdani Cyrus IMAP4 v2.1.18-IPv6-Debian-2.1.18-1 server ready a001 login mgr ** a001 OK User logged in a002 logout * BYE LOGOUT received a002 OK Completed Connection closed by foreign host. openssh s_client -connect verdani:imaps [stripped most of certificates and such] Verify return code: 19 (self signed certificate in certificate chain) --- * OK verdani Cyrus IMAP4 v2.1.18-IPv6-Debian-2.1.18-1 server ready a001 login mgr ** and it simply does not return anymore. There is no difference in /var/log/auth.log, which however reports all the steps it goes through by using DIGEST-MD5 with ldapdb for authentication. There is a difference in /var/log/mail.log: The telnet case: May 17 22:57:37 verdani cyrus/master[4209]: about to exec /usr/lib/cyrus/bin/imapd May 17 22:57:37 verdani cyrus/imap[4209]: executed May 17 22:57:37 verdani cyrus/imapd[4209]: accepted connection May 17 22:57:51 verdani cyrus/imapd[4209]: login: sleipnir.mgr[172.16.1.3] mgr plaintext The openssl case: May 17 22:58:27 verdani cyrus/master[4219]: about to exec /usr/lib/cyrus/bin/imapd May 17 22:58:27 verdani cyrus/imaps[4219]: executed May 17 22:58:27 verdani cyrus/imapd[4219]: accepted connection May 17 22:58:28 verdani cyrus/imapd[4219]: mystore: starting txn 2147483777 May 17 22:58:28 verdani cyrus/imapd[4219]: mystore: committing txn 2147483777 May 17 22:58:28 verdani cyrus/imapd[4219]: starttls: TLSv1 with cipher AES256-SHA (256/256 bits new) no authentication in particular there is no login line. I checked /dev/random, since all these DIGEST-MD5 etc. eat a lot of entropy. Actually I did #ln -s /dev/urandom /dev/random and checked #dd if=/dev/random bs=8 count=1 during the hanging authentication. There are random numbers available, but still the authentication hangs. I'm lost. I would appreciate some help in further troubleshooting. Regards, - lars. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
KMail won't get Mail from Imapd
Hi there, I have a strange problem. I recently made two large updates of my mail server ans of my workstation. Before everything worked fine and I did all my E-Mail with KMail SSL to Cyrus-IMAP authenticating via ldapdb to an LDAP repository on yet another server. Then I updated Debian-Sarge: now I run Cyrus 2.1.18-1 and KMail 3.3.1-3. Well, KMail hangs when trying to open any folder. I still get a denial message, if I mistype the password, thus authentication does not appear to be the major problem - but I may be in error. However, using the Mozilla Mail Client, everything appears a little slow, but it works at least. A little bit of investigation showed that KMail uses TLS, even if I disable it in the MUA. If I use SSL with Mozilla I see the same behaviour as with KMail. I've no idea of what's happening, can somebody give me a hint: /var/log/auth.log contains: May 6 18:03:28 verdani cyrus/imapd[7728]: DIGEST-MD5 server step 1 May 6 18:03:28 verdani cyrus/imapd[7728]: DIGEST-MD5 server step 2 May 6 18:03:28 verdani cyrus/imapd[7728]: DIGEST-MD5 client step 2 May 6 18:03:28 verdani cyrus/imapd[7728]: DIGEST-MD5 client step 2 May 6 18:03:28 verdani cyrus/imapd[7728]: DIGEST-MD5 client step 3 May 6 18:03:28 verdani cyrus/imapd[7728]: DIGEST-MD5 client step 1 May 6 18:03:28 verdani cyrus/imapd[7728]: DIGEST-MD5 client step 1 May 6 18:03:28 verdani cyrus/imapd[7728]: DIGEST-MD5 client step 2 May 6 18:03:28 verdani cyrus/imapd[7728]: DIGEST-MD5 client step 3 /var/log/mail.log contains: May 6 18:03:28 verdani cyrus/master[7728]: about to exec /usr/lib/cyrus/bin/imapd May 6 18:03:28 verdani cyrus/imap[7728]: executed May 6 18:03:28 verdani cyrus/imapd[7728]: accepted connection May 6 18:03:28 verdani cyrus/imapd[7728]: mystore: starting txn 2147483978 May 6 18:03:28 verdani cyrus/imapd[7728]: mystore: committing txn 2147483978 May 6 18:03:28 verdani cyrus/imapd[7728]: starttls: TLSv1 with cipher RC4-MD5(128/128 bits new) no authentication As it seems, the very important login line does not appear as with Mozilla: /var/log/mail.log: May 6 22:01:26 verdani cyrus/master[9713]: about to exec /usr/lib/cyrus/bin/imapd May 6 22:01:26 verdani cyrus/imap[9713]: executed May 6 22:01:26 verdani cyrus/imapd[9713]: accepted connection May 6 22:01:26 verdani cyrus/imapd[9713]: login: server[IP] user plaintext However, all this DIGEST-MD5 stuff relates to ldapdb, since it also appears with local imtest. It seems to be starttly causing trouble, but I currently have no idea for further troubleshooting. Any help appreciated. Regards, - lars. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Authenticating Outlook to Cyrus-Imap
Hi there, I - well not me actually - would like to use Outlook to access my Cyrus-Imap mailstore. I've setup Cyrus to use SASL auxprop for ldapdb authentication using DIGEST-MD5. If I test with: imtest -u user -a user -m NTLM server everything is fine. However, login from Outlook fails, producing the following auth.log: Mar 14 23:16:54 localhost cyrus/imapd[20511]: NTLM server step 1 Mar 14 23:16:54 localhost cyrus/imapd[20511]: client flags: b207 Mar 14 23:16:54 localhost cyrus/imapd[20511]: NTLM server step 2 Mar 14 23:16:54 localhost cyrus/imapd[20511]: client user: user Mar 14 23:16:54 localhost cyrus/imapd[20511]: client domain: UAC Mar 14 23:16:54 localhost cyrus/imapd[20511]: DIGEST-MD5 client step 2 Mar 14 23:16:54 localhost cyrus/imapd[20511]: DIGEST-MD5 client step 2 Mar 14 23:16:54 localhost cyrus/imapd[20511]: DIGEST-MD5 client step 3 Mar 14 23:16:54 localhost cyrus/imapd[20511]: calculating NT response Mar 14 23:16:54 localhost cyrus/imapd[20511]: incorrect NTLM response imtest differs in the following lines: Mar 14 23:17:42 localhost cyrus/imapd[20511]: client flags: 207 Mar 14 23:17:47 localhost cyrus/imapd[20511]: client domain: VERDANI I assume that the domain is hashed into the NTLM authentication token. The local test uses the server name, whilst the Outlook test uses the domain as supplied from my samba PDC. Is there a sensible solution for this issue? Have fun, - lars. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
