GSSAPI for various murder component setups

[Stephen Ingram]

On Thu, Jun 14, 2012 at 6:20 AM, Dave McMurtrie <dave64 at andrew.cmu.edu> wrote:
> On 06/14/2012 12:02 AM, Stephen Ingram wrote:
>
>> This is exactly the part I'm really confused about. For murder, I see
>> connections from the frontends and backends to the mupdate server. I
>> also see connections from the frontends to the backends. The
>> connections to the mupdate server are, in a very simplistic sense, to
>> spread information about the mailboxes. I was thinking these should be
>> machine to machine connections using Kerberos service accounts.
>
> Let me try to run through which keys exist on various servers in our
> environment.  I think that will possibly clear things up a bit.
>
> In the keytab on our Cyrus frontend servers:
> --------------------------------------------
> * imap/cyrus.andrew.cmu.edu at ANDREW.CMU.EDU service principal.  This is
> used for end-user client authentication to the imap service running on
> cyrus.andrew.cmu.edu hosts.
>
> * pop/cyrus.andrew.cmu.edu at ANDREW.CMU.EDU service principal.  This is
> used for end-user client authentication to the pop service running on
> cyrus.andrew.cmu.edu hosts.
>
> * sieve/cyrus.andrew.cmu.edu at ANDREW.CMU.EDU service principal.  This is
> used for end-user client authentication to the sieve service running on
> cyrus.andrew.cmu.edu hosts.
>
> * nntp/cyrus.andrew.cmu.edu at ANDREW.CMU.EDU service principal.  This is
> used for end-user client authentication to the nntp service running on
> cyrus.andrew.cmu.edu hosts.

I notice for these 4 service principals you are using
cyrus.andrew.cmu.edu for the fqdn. Does this mean that you are using
the same principals/keys for each of your frontend systems, your
frontend systems are all called cyrus with some sort of load balancing
or do you actually place a host name in front of cyrus?

> * imap/`hostname`@ANDREW.CMU.EDU.  The Cyrus master process runs
> authenticated as this principal.  We accomplish this by having a simple
> cyrus.auth script run on startup from cyrus.conf, and also as a
> recurring event in cyrus.conf.  It does nothing more than set KRB5CCNAME
> and run kinit.  These credentials are used to authenticate to our
> mupdate server and to each of our Cyrus backend servers.

So since this service principal is always authenticated, you can use
it without further intervention to connect to the mupdate and backend
servers?

> * host/cyrus.andrew.cmu.edu at ANDREW.CMU.EDU.  This could really use some
> documentation.  It's used by saslauthd when saslauthd is configured to
> use kerberos5.  The idea is that saslauthd takes the user credentials
> via a socket and uses those to request a tgt.  To make sure it wasn't
> talking to a spoofed KDC, it then uses that tgt to request a "host"
> service ticket.  "host" is hard-coded in saslauthd.

I already have this setup. It was the easiest for me to understand
since it starts with an authenticated service principal and is more
like the user-login kerberos I'm used to setting up. I'm sure this
will take on a whole new light once I fully understand the
always-authenticated service principals.

> In the keytab on our Cyrus backend servers:
> -------------------------------------------
>
> * imap/`hostname`@ANDREW.CMU.EDU.  The Cyrus master process runs
> authenticated as this principal.  We accomplish this by having a simple
> cyrus.auth script run on startup from cyrus.conf, and also as a
> recurring event in cyrus.conf.  It does nothing more than set KRB5CCNAME
> and run kinit.  These credentials are used to authenticate to our
> mupdate server.  If a client were to connect directly to one of our
> backends, it would use this service principal to authenticate.  If you
> disable referrals, you won't need to account for clients connecting
> directly to your backends and you therefore won't need any service
> principals for client authentication.

Again, this is running authenticated so that it can connect to the
mupdate server? I don't think we want users logging directly into the
backends, but if we did, then we would also need imap, pop (if using),
sieve and nntp principals too, right?

>> However, I'm not really sure, should only the mupdate server have an
>> mupdate service principals and then the frontend clients and backend
>> clients connect to mupdate using "user" kerberos principals, or if all
>> servers involved have service principals. Also when proxying a mail
>> connection from frontend to backend, how should this be done?
>
> The frontends authenticate to the backends using their
> imap/`hostname`@ANDREW.CMU.EDU credentials (remember, our master process
> runs authenticated).  Proxy authentication is supported in Cyrus-SASL
> for GSSAPI, so the imap/`hostname` credentials are used for
> authentication, but the connection is authorized as the "real" user, or
> the user who authenticated to the frontend.  Hence, in the Cyrus logs on
> the backend you'll see the real username as having logged in, not your
> imap/`hostname` principal.

And is it correct that this is where the warning comes in about being
careful of the admins: setting on the backends? No front end has admin
privileges per say, but simply ends up having proxy permissions so it
can deliver the message?

The cyrus user that would have admin privileges on the backend servers
would simply be another kerberos user that would have to kinit and
then be able to use cyradm to perform administration tasks?

>> And then there is replication....
>
> This works much the same.  Our replicas are all configured with our
> imap/`hostname` principals as "admins:".  sync_client runs with the same
> imap/`hostname` credentials and authenticates to sync_server thusly.

You can specify a principal in the admins: setting? Would it be like:

admins: cyrus at ANDREW.CMU.EDU, imap/imap1.cyrus.andrew.cmu.edu at ANDREW.CMU.EDU

or something else?

>> I guess I'm mostly confused about whether and where to use user and/or
>> service principals and how does the other end know that it is being
>> connected to correctly.
>
> The backends all look at "proxyservers" in imapd.conf to know if the
> authenticated user is a frontend or not.  The mupdate server uses the
> "admins:" option in imapd.conf.

Would the mupdate server need a service principal? I'm guessing
mupdate/fqdn at REALM, but not authenticated.

>> For instance is the mupdate server expecting a
>> user in the admins group to connect to retrieve the mailbox list or
>> simply a machine and where is that specified in the configuration
>> files?
>
> Correct.  mupdate uses "admins" in imapd.conf to determine who may
> authenticate.
>
>> I've found a couple of configuration files floating around in
>> the mailing list archives and was confused even more after looking at
>> it for they only seem to cache credentials for service principal type
>> accounts by inserting lines into the cyrus.conf file to create and
>> then renew credentials on a regular basis.
>>
>> I'm really shocked that there is no good documentation on this. Am I
>> going down a road that hardly anyone travels on? Or, are those who
>> have ventured there simply too exhausted to write about it?
>> Considering how great this all seems, I can't believe more people
>> don't deploy this type of setup as it seems much more secure than
>> using plain text passwords.
>
> Documentation is usually the last thing that a busy sysadmin or
> developer has time for so it usually doesn't get done.  I'd love to see
> the state of documentation for Project Cyrus improve, and I'd welcome
> any documentation you'd be willing to create on this topic.  Jeroen has
> been busy putting together some very excellent docs, and this would
> probably fit in with that nicely.

Thank you for taking the time to provide such detailed information to
me. Provided I can get everything working, I would be thrilled to
start putting together some documentation for this. Now that the
developers have really kicked everything into high gear (the switch to
2.4 blew me away), I think the lack of documentation is going to
become more and more critical. Perhaps more people would use Cyrus in
some of the possible advanced configurations if they simply understood
how it worked!

Steve