Re: GSSAPI for various murder component setups

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 13, 2012 at 1:23 PM, Dan White <dwhite@xxxxxxx> wrote:
> On 06/13/12 12:57 -0700, Stephen Ingram wrote:
>>
>> There seems to be quite a bit of information on the Website about
>> setting up a murder configuration. Most of the documentation, however,
>> seems to be centered on basic authentication. Is there a good resource
>> somewhere to using Kerberos to setup the communication between the
>> mupdate, frontend and backend servers for mupdate, imap and
>> replication processes? I see some configs in the distribution conf
>> directory from CMU setups, but they are only partially complete and
>> based on Kerberos 4.
>
>
> There are two differences that come to mind:
>
> When configuring authentication, you can simply leave the authname and
> password out of your configuration, such as:
>
> mupdate_server: mupdate.example.net
> # mupdate_port
> # mupdate_username:
> # mupdate_authname
> # mupdate_realm
> # mupdate_password
> # mupdate_retry_delay
> mupdate_config: standard
>
> The other issue is that where your systems are acting as clients (such as
> when a frontend server is connecting to an mupdate server), your client
> will need to initialize a kerberos ticket cache, and in my experience
> cannot use the kerberos credentials used to accept connections. Or in other
> words, your frontends might have an imap/mail.example.net service ticket
> for accepting client imap connections, but then may need a separate ticket,
> such as cyrus/mail.example.net, for backend/mupdate connections. I use
> cronjobs, running as the cyrus user, to initialize those crendential
> caches.

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.
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? And then
there is replication....

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

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



[Index of Archives]     [Cyrus SASL]     [Squirrel Mail]     [Asterisk PBX]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux