On Sun, Jun 17, 2012 at 8:21 PM, Dan White <dwhite@xxxxxxx> wrote: > On 06/17/12 18:04 -0700, Stephen Ingram wrote: >> >> On Thu, Jun 14, 2012 at 9:14 PM, Dan White <dwhite@xxxxxxx> 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.com@xxxxxxxxxxx connect to (mupdate server) >> mupdate/murder.example.com@xxxxxxxxxxx. 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
