Self compiled Cyrus 2.4.16 does not talk to self compiled Cyrus SASL 2.1.25
Folks, (hitting the same wall over and over again when upgrading) Cyrus SASL is working/looking in /var/state/saslauthd all right, but Cyrus 2.4 appears to be writing elsewhere, and we cannot find out where exactly. Have tried 'saslauthd_path' option in /etc/imapd.conf to no avail. I pretty much copied our Cyrus 2.3 configuration files over to the test environment. Eric Luyten, VUB/ULB. 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: Self compiled Cyrus 2.4.16 does not talk to self compiled Cyrus SASL 2.1.25
On Tue, 2012-06-19 at 11:17 +0200, Eric Luyten wrote: (hitting the same wall over and over again when upgrading) Cyrus SASL is working/looking in /var/state/saslauthd all right, but Cyrus 2.4 appears to be writing elsewhere, and we cannot find out where exactly. Are you sure it is loading your compiled libraries and not your distributions 'defacto' ones? [ldd /usr/lib/cyrus/bin/imapd - your should see a reference to your SASL libraries] BTW - why are you self-compiling? Really good packages exist for lots of distributions. Have tried 'saslauthd_path' option in /etc/imapd.conf to no avail. So when you run testsaslauthd it works? I pretty much copied our Cyrus 2.3 configuration files over to the test environment signature.asc Description: This is a digitally signed message part 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: Self compiled Cyrus 2.4.16 does not talk to self compiled Cyrus SASL 2.1.25
On Tue, June 19, 2012 12:05 pm, Adam Tauno Williams wrote: On Tue, 2012-06-19 at 11:17 +0200, Eric Luyten wrote: (hitting the same wall over and over again when upgrading) Cyrus SASL is working/looking in /var/state/saslauthd all right, but Cyrus 2.4 appears to be writing elsewhere, and we cannot find out where exactly. Are you sure it is loading your compiled libraries and not your distributions 'defacto' ones? [ldd /usr/lib/cyrus/bin/imapd - your should see a reference to your SASL libraries] mcs1dev# ldd /usr/local/sbin/saslauthd | fgrep sasl libsasl2.so.2 = /opt/csw/lib/libsasl2.so.2 mcs1dev# ldd /usr/cyrus/bin/imapd | fgrep sasl libsasl2.so.2 = /opt/csw/lib/libsasl2.so.2 mcs1dev# BTW - why are you self-compiling? Really good packages exist for lots of distributions. Solaris10/Intel. Have tried 'saslauthd_path' option in /etc/imapd.conf to no avail. So when you run testsaslauthd it works? Yes, it certainly does. Eric Luyten. 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
loginrealm
Hi, my servers are configured to use mailboxes without realm or domain, like user.jdoe for user jdoe, where his mail address is like john@example.com. Authentication is against LDAP, where the mail adress is in the attribute mail and an attribute maildrop stores j...@imapserver.example.com which points to the IMAPd server used and his mail user name/mailbox. This works fine. Now we try to integrate SOGo. SOGo uses LDAP too and gets the IMAP user name from LDAP, where is only the attribute maildrop with the domain part appended to the username. May 27 11:16:22 mailserver imap[8581]: badlogin: client [10.49.9.74] plaintext j...@imapserver.example.com SASL(-13): authentication failure: cross-realm login j...@imapserver.example.com denied The hint on the SOGo list was to use loginrealm with imapserver.example.com. With this jdoe can authenticate against my IMAPd server, but it does not find a maildox, because it looks for j...@imapserver.example.com / user.j...@imapserver.example.com and not for jdoe / user.jdoe. Is there any way to get around this with IMAPd? Marc 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: Self compiled Cyrus 2.4.16 does not talk to self compiled Cyrus SASL 2.1.25
On 06/19/12 11:17 +0200, Eric Luyten wrote: Folks, (hitting the same wall over and over again when upgrading) Cyrus SASL is working/looking in /var/state/saslauthd all right, but Cyrus 2.4 appears to be writing elsewhere, and we cannot find out where exactly. Have tried 'saslauthd_path' option in /etc/imapd.conf to no avail. I pretty much copied our Cyrus 2.3 configuration files over to the test environment. What does your sasl_* configuration look like in imapd.conf? Are you authenticating with an appropriate mechanism (either PLAIN or LOGIN)? On 06/19/12 13:34 +0200, Eric Luyten wrote: On Tue, June 19, 2012 12:05 pm, Adam Tauno Williams wrote: On Tue, 2012-06-19 at 11:17 +0200, Eric Luyten wrote: (hitting the same wall over and over again when upgrading) Cyrus SASL is working/looking in /var/state/saslauthd all right, but Cyrus 2.4 appears to be writing elsewhere, and we cannot find out where exactly. Are you sure it is loading your compiled libraries and not your distributions 'defacto' ones? [ldd /usr/lib/cyrus/bin/imapd - your should see a reference to your SASL libraries] mcs1dev# ldd /usr/local/sbin/saslauthd | fgrep sasl libsasl2.so.2 = /opt/csw/lib/libsasl2.so.2 mcs1dev# ldd /usr/cyrus/bin/imapd | fgrep sasl libsasl2.so.2 = /opt/csw/lib/libsasl2.so.2 mcs1dev# The location of the shared libraries for the saslauthd should not be important (unless you're using the sasldb or ldap backends), because it runs within its own process. If testsaslauthd is working then your saslauthd installation is likely ok. Try running testsaslauthd as your cyrus user to rule out any permissions problems. BTW - why are you self-compiling? Really good packages exist for lots of distributions. Solaris10/Intel. Have tried 'saslauthd_path' option in /etc/imapd.conf to no avail. So when you run testsaslauthd it works? Yes, it certainly does. Your saslauthd_path configuration should include the trailing '/mux'. I believe it should be identical to the '-f' option that you would pass to testsaslauthd. Try increasing your sasl logging to further troubleshoot. In imapd.conf: sasl_log_level: 7 And configure your syslog daemon to log 'auth.*'. -- Dan White 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: loginrealm
On 06/19/12 15:37 +0200, Marc Patermann wrote: Hi, my servers are configured to use mailboxes without realm or domain, like user.jdoe for user jdoe, where his mail address is like john@example.com. Authentication is against LDAP, where the mail adress is in the attribute mail and an attribute maildrop stores j...@imapserver.example.com which points to the IMAPd server used and his mail user name/mailbox. This works fine. Now we try to integrate SOGo. SOGo uses LDAP too and gets the IMAP user name from LDAP, where is only the attribute maildrop with the domain part appended to the username. May 27 11:16:22 mailserver imap[8581]: badlogin: client [10.49.9.74] plaintext j...@imapserver.example.com SASL(-13): authentication failure: cross-realm login j...@imapserver.example.com denied The hint on the SOGo list was to use loginrealm with imapserver.example.com. With this jdoe can authenticate against my IMAPd server, but it does not find a maildox, because it looks for j...@imapserver.example.com / user.j...@imapserver.example.com and not for jdoe / user.jdoe. Is there any way to get around this with IMAPd? Try setting: defaultdomain: imapserver.example.com -- Dan White 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 for various murder component setups
On Sun, Jun 17, 2012 at 8:21 PM, Dan White dwh...@olp.net wrote: On 06/17/12 18:04 -0700, Stephen Ingram wrote: On Thu, Jun 14, 2012 at 9:14 PM, Dan White dwh...@olp.net wrote: ...snip... Another way to keep your principals straight is that you'll need a user principal where you will run the *test utilities, and a service principal on the server that the *test utility will connect to. The service principals will be initialized for you by libsasl2, and the user principals will need to be kinit'd via some other mechanism (like in your START/EVENTS section). ...snip... The frontend *will* need to have a non-service principal ticket initialized when performing gssapi authentication to the backend. This is *exactly* what I continue to be confused about. Can't a service principal be used on both client and server sides? To me a user should only be a physical person that would login, not a process. For example, can the authenticated (mupdate client and backend) mupdate/imap1.example@example.com connect to (mupdate server) mupdate/murder.example@example.com. Why couldn't this happen? That may work, however you'd need to kinit (or initialize by some other mechanism) on imap1 since the client GSSAPI mechanism won't do that for you. You can still authenticate from a keytab with kinit. You may end up with two different TGTs on imap1. It may be a nightmare to attempt to authenticate from the client side with different service principals, like: mupdate/imap1.example.com imap/imap1.example.com (for proxying) lmtp/imap1.example.com etc. The client side GSSAPI mechanism would need to be told which credentials cache to use for that particular type of authentication, such as with an environment variable. You could post to the cyrus-sasl list to see if someone there has a better recommendation. GS2 is a newer kerberos based authentication mechanism that may handle this in a more sensible way. Thank you for your continued help with this. I really appreciate it and am determined to get to the end of this. I think I'm getting closer. I have successfully authenticated using mupdatetest from one of the backends to the mupdate server. I'm using service principals on both ends. I've even specified the imap/imap1.example.com part of the principal in the admins: section of the configuration and after solving several configuration issues on my end, it seems to work! I came across a post from you some time ago talking about /etc/krb.equiv. Would this be an easier way to do this? I tried placing that file on the mupdate server and loaded it with imap/imap1.example.com imap1 and then placed admins: imap1 in my imapd.conf file, but I'm not sure if it works. Do I have to tell cyrus about that file somewhere? Steve 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
