GSSAPI for various murder component setups

[Dan White]

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.

-- 
Dan White