GSSAPI for various murder component setups

Stephen Ingram sbingram at
Sun Jun 24 01:55:26 EDT 2012

On Thu, Jun 14, 2012 at 9:14 PM, Dan White <dwhite at> wrote:


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

Well, while I'm still not sure which way to go on the issue of where
to place the service keytabs, your assertion that one *must* use a
user to authenticate from the frontend to the backend in order to
proxy the user authentication through seems to be correct. However,
I'm not sure exactly why. When I test with imtest as user cyrus using
the service principals in the same credential cache as fetched by the
program, it works great. Even when testing with the service principals
in place with the processes running, examining the caches, all the
tickets appear to be properly granted and in the cache, however, every
time there is a:

couldn't authenticate to backend server: authentication failure

error. Is there something specific in the cyrus-imapd code the ensures
only a user principal will work? Is there some rationale to this? I've
been told by everyone I've asked that there is no difference between
user and service principals. Is it as something as silly as the / you
alluded to omitting from your user principals before so you could
satisfy libsasl2?


More information about the Info-cyrus mailing list