On 06/14/12 17:20 -0700, Stephen Ingram wrote: >On Thu, Jun 14, 2012 at 7:05 AM, Dan White <dwhite@xxxxxxx> 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 ---- 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
