GSSAPI for various murder component setups

[Stephen Ingram]

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