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