Re: Question: How to specify path to saslauthd mux socket inimapd.conf?
On Mon, 9 Dec 2002, Kevin M. Myer wrote: What I still need to figure out is how to specify which saslauthd mux socket for each domain's imap process to connect to. [...] I can't seem to find that documented anywhere (probably because its only in this special case scenario that you'd even need to use it :) What you're describing sounds almost like a solution to a problem I'm grappling with, but I suspect not quite - any suggestions on the Right Way to proceed here would be welcomed: I'm upgrading an inherited 1.5.19 installation to 2.1.11, but have to cope with some local authentication madness. For historical reasons we authenticate to different LDAP servers depending upon the usercode (staff and students), and the 1.5 code has been horribly hacked to support this. Taking the LDAP madness as read, it sounds like the way to solve this in Cyrus is to go to impad-2_2 in CVS and use named virtual domains, with users logging in as user@staff or user@student. Alas, that's not a realistic short-term option for me (as a Cyrus newbie I'd rather stay away from CVS, and the upgrade has to be invisible to users wherever possible). So what I've been considering is applying a similar patch to saslauthd/lak.c to choose an LDAP config based on the usercode. Obviously I'd prefer not to mutilate the code if I could avoid it - if I instead ran two saslauthd instances with their own configs, is there a way to make imapd 2.1 dynamically choose a socket based on some per-user property? (This property needn't be the usercode - for example, we keep staff and students in separate partitions.) Like I said, any advice would be gratefully received! Also, is it reasonable to think that most major IMAP clients could handle talking to a server that only listens on imaps (basically my forcing of TLS idea above)? I know my webmail client, IMP, can handle that but can most other standalone clients handle imaps well and will they barf over self-signed certificates? Following up on Rob's list, my tests show that Outlook 2000, Pine 4.44 and Mozillia 1.0.1 complain about self-signed certs but let you use them. Eudora 5.2 is more interesting: they've fixed the broken STARTTLS support that plagued 5.0/5.1 so that it really does start TLSv1 on port 143 (their IMAPS (port 993) support is for TLSv1 with an SSLv2 hello). However, it will fail the connection if you're using a self-signed cert, and Qualcomm support doc 2323HQ tells you to go into Certificate Manager and add the cert to your trusted list. Which is all nice and sensible, except that running it in Light mode you have to open the Last SSL Info dialog to get to Cert Manager, and you can't open that dialog until you've had a successful SSL connection. Hmm... -- Simon Brady mailto:[EMAIL PROTECTED] ITS Technical Services University of Otago, Dunedin, New Zealand
Re: Question: How to specify path to saslauthd mux socket inimapd.conf?
On Mon, 9 Dec 2002, Kevin M. Myer wrote: conversation (via , I don't give anything up security-wise. In other words, I can rely on the transport layer to provide encryption, instead of a higher layer and that way email can't be sniffed either. You do of course realize that email is transmitted plaintext to your MX server anyway from the rest of the world, right? So I upgraded to the latest versions of Cyrus SASL (2.1.10) and Cyrus IMAP (2.1.11) today on my test server. I got saslauthd working fine with LDAP for one Cyrus IMAP virtual domain (the altconfig type meaning I specify a full set of services per domain, bound to a unique IP address and I have a unique imapd.conf for each domain, I'm not talking about the newer virtual domain support). What I still need to figure out is how to specify which saslauthd mux socket for each domain's imap process to connect to. I know how to start multiple saslauthd's and specify which socket for them to create but I need to know how to specify in /etc/imapd.conf which of those sockets to connect to. I can't seem to find that documented anywhere (probably because its only in this special case scenario that you'd even need to use it :) From SASL's doc/options.html: saslauthd_path is the SASL option you want, so sasl_saslauthd_path is the imapd.conf option. Leave off the /mux You're right, this is really the only case I've ever heard of this support actually being useful ;) Also, is it reasonable to think that most major IMAP clients could handle talking to a server that only listens on imaps (basically my forcing of TLS idea above)? I know my webmail client, IMP, can handle that but can most other standalone clients handle imaps well and will they barf over self-signed certificates? Pine, Mulberry, Outlook, Mozilla, Netscape, etc should all have no trouble with TLS. There may be a certificate warning about your self-signed certificate. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Question: How to specify path to saslauthd mux socket inimapd.conf?
On Mon, 9 Dec 2002, Kevin M. Myer wrote: Including the mux named pipe causes this to work so I think the documentation should read that you DO need to include the mux named pipe or maybe the saslauthd_path option should be changed to saslauthd_mux_path. Yes. This is what I get for believing my own documentation. I'm updating this now. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Question: How to specify path to saslauthd mux socket inimapd.conf?
On Mon, 9 Dec 2002, Kevin M. Myer wrote: Hi, With the recent Cyrus IMAP buffer overflow exploit, its time to upgrade our mail server. I've been sitting on a Cyrus IMAP 2.1.X CVS install from right before the SASL2 requirement went into effect and have been holding off on upgrading until I can figure out a decent path to go from SASL1 - SASL2 and still keep LDAP authentication working. Currently, I'm using Simon's LDAP authentication patch for SASLv1. I have four different domains, all being served out of different trees on the same directory server. With sasl_auto_transition turned on, CRAM-MD5 and DIGEST-MD5 authentication works after an initial plaintext login (done at account setup on a local network). Since saslauthd only supports plaintext passwords for LDAP authentication, I'm thinking that if I trade the stronger SASL authentication off for requiring TLS for the entire IMAP conversation (via , I don't give anything up security-wise. In other words, I can rely on the transport layer to provide encryption, instead of a higher layer and that way email can't be sniffed either. So I upgraded to the latest versions of Cyrus SASL (2.1.10) and Cyrus IMAP (2.1.11) today on my test server. I got saslauthd working fine with LDAP for one Cyrus IMAP virtual domain (the altconfig type meaning I specify a full set of services per domain, bound to a unique IP address and I have a unique imapd.conf for each domain, I'm not talking about the newer virtual domain support). What I still need to figure out is how to specify which saslauthd mux socket for each domain's imap process to connect to. I know how to start multiple saslauthd's and specify which socket for them to create but I need to know how to specify in /etc/imapd.conf which of those sockets to connect to. I can't seem to find that documented anywhere (probably because its only in this special case scenario that you'd even need to use it :) Also, is it reasonable to think that most major IMAP clients could handle talking to a server that only listens on imaps (basically my forcing of TLS idea above)? I know my webmail client, IMP, can handle that but can most other standalone clients handle imaps well and will they barf over self-signed certificates? As always, if there's a simpler way to do this whole thing, I'd like to hear about it. What I have now works extremely well, so I'm not inclined to change it too much but I could be missing something very obvious too. I know there's supposedly an OpenLDAP 2.X internal auxprop plugin in the works but that won't help me too much since our directory server is iPlanet DS. Maybe its time to bite the bullet and migrate directory server platforms too... OpenLDAP internal auxprop plugin works for OpenLDAP only. You will need to build your own or try a few plugins available on the web. One is available in the contrib directory of the latest OpenLDAP tarball. -- Igor
