GSSAPI for various murder component setups

[Stephen Ingram]

On Sat, Jun 23, 2012 at 10:55 PM, Stephen Ingram <sbingram at gmail.com> wrote:
> On Thu, Jun 14, 2012 at 9:14 PM, Dan White <dwhite at olp.net> wrote:
>
> ...snip...
>
>> 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?

After a little more testing, yes, it appears as though the "/" is
disallowed. But Dave you said you are using
"imap/`hostname`@ANDREW.CMU.EDU". What happens if you want to use an
admin instance of a user principal (e.g. steve/admin at ANDREW.CMU.EDU)?
Has this changed and Dave, you are using a different version than Dan
and I? Sorry to keep pounding on this issue, but I don't want to write
documentation unless I really understand what is going on.

BTW, the service principal works perfectly with the mupdate client to
server auth. I have a feeling that the sync would work too. It seems
to have something to do with the user proxy that Dan was describing.
Maybe only a user can proxy another user and not a service?

Steve