GSSAPI for various murder component setups

[Dan White]

On 06/14/12 17:20 -0700, Stephen Ingram wrote:
>On Thu, Jun 14, 2012 at 7:05 AM, Dan White <dwhite at olp.net> wrote:
>> Every service listed within your SERVICES section in cyrus.conf will
>> potentially need it's own service principal, particularly on your backends
>> and mupdate master. Your frontends may not need service principals if your
>> users are not performing GSSAPI authentication.
>>
>> libsasl2 will search for for service principals starting with:
>>
>> imap/
>> lmtp/
>> mupdate/
>> csync/
>> pop/
>> nntp/
>> sieve/
>
>Wouldn't the front ends need these connections worse than the backends
>(assuming I'm not supporting referrals)? I'm guessing the lmtp is for
>Postfix connecting to the frontend/proxy to backend to deliver the
>message?
>
>The csync is for replication?

Right.

The key thing to keep in mind is that what you place in your SERVICES
section is started up as a server, needing it's own service principal. In
the case of a replica, the replica is the server, requiring the csync/*
principal, and your backend acts as the client, requiring a kinit'd "user"
tgt (or a non-service principal if you will). I actually name these
'cyrus-<hostname>' instead of 'cyrus/<hostname>'. There was some case in
libsasl2 where the slash caused me some grief.

>> Every server in your murder, except perhaps your replica server, will
>> likely need an additional client/user principal.
>
>Why wouldn't the replica server need a service principal since the
>backend connects to it to sync?

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).

>> When proxying from the frontend to the backend, the frontend will make a
>> gssapi connection to the backend regardless of the authentication method
>> the client used when connecting to the frontend. If the client supports
>> referrals, then the client will then make it's own connection to the
>> backend using which ever authentication method it's configured to use.
>
>But only if the backend is configured for that authentication method, no?

You can control whether clients will get referrals via the
proxyd_disable_mailbox_referrals option.

When proxying, you would configure the 'cyrus-<hostname>' user within
the proxyservers option on the backend. When the frontend authenticates to
the backend, it will send an authorization identity of the previously
authenticated frontend user. Like:

authcid: none (derived from your kerberos identity)
authzid: jsmith

Then, from the backend's perspective, jsmith performed the authentication,
and gets all the proper ACL permissions applied. The frontend *might* have
all the appropriate service principals in place to support client gssapi
authentication, however that's not necessary. The client authentication to
the frontend, and the frontend's proxy authentication to the backend are
distinct authentications. The frontend *will* need to have a non-service
principal ticket initialized when performing gssapi authentication to the
backend.

-- 
Dan White