Re: GSSAPI for various murder component setups
Dave McMurtrie <dave64 <at> andrew.cmu.edu>
2012-06-14 13:20:38 GMT
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` <at> 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` <at> 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` <at> 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
----
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
RSS Feed