On Sat, Jun 23, 2012 at 10:55 PM, Stephen Ingram <sbingram@xxxxxxxxx> wrote: > On Thu, Jun 14, 2012 at 9:14 PM, Dan White <dwhite@xxxxxxx> 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@xxxxxxxxxxxxxx)? 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 ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus