GSSAPI for various murder component setups

[Dave McMurtrie]

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.

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

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


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.



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


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


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

Thanks!

Dave