GSSAPI for various murder component setups
dwhite at olp.net
Sun Jun 17 23:21:05 EDT 2012
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:
>> 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).
>> The frontend *will* need to have a non-service
>> principal ticket initialized when performing gssapi authentication to the
>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:
imap/imap1.example.com (for proxying)
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
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.
More information about the Info-cyrus