Re: GSSAPI for various murder component setups
On Sat, Jun 23, 2012 at 10:55 PM, Stephen Ingram sbing...@gmail.com wrote: On Thu, Jun 14, 2012 at 9:14 PM, Dan White dwh...@olp.net wrote: ...snip... You can control whether clients will get referrals via the proxyd_disable_mailbox_referrals option. When proxying, you would configure the 'cyrus-hostname' user within the proxyservers option on the backend. When the frontend authenticates to the backend, it will send an authorization identity of the previously authenticated frontend user. Like: authcid: none (derived from your kerberos identity) authzid: jsmith Then, from the backend's perspective, jsmith performed the authentication, and gets all the proper ACL permissions applied. The frontend *might* have all the appropriate service principals in place to support client gssapi authentication, however that's not necessary. The client authentication to the frontend, and the frontend's proxy authentication to the backend are distinct authentications. The frontend *will* need to have a non-service principal ticket initialized when performing gssapi authentication to the backend. Well, while I'm still not sure which way to go on the issue of where to place the service keytabs, your assertion that one *must* use a user to authenticate from the frontend to the backend in order to proxy the user authentication through seems to be correct. However, I'm not sure exactly why. When I test with imtest as user cyrus using the service principals in the same credential cache as fetched by the program, it works great. Even when testing with the service principals in place with the processes running, examining the caches, all the tickets appear to be properly granted and in the cache, however, every time there is a: couldn't authenticate to backend server: authentication failure error. Is there something specific in the cyrus-imapd code the ensures only a user principal will work? Is there some rationale to this? I've been told by everyone I've asked that there is no difference between user and service principals. Is it as something as silly as the / you alluded to omitting from your user principals before so you could satisfy libsasl2? After a little more testing, yes, it appears as though the / is disallowed. But Dave you said you are using imap/`hostname`@ANDREW.CMU.EDU. What happens if you want to use an admin instance of a user principal (e.g. steve/ad...@andrew.cmu.edu)? Has this changed and Dave, you are using a different version than Dan and I? Sorry to keep pounding on this issue, but I don't want to write documentation unless I really understand what is going on. BTW, the service principal works perfectly with the mupdate client to server auth. I have a feeling that the sync would work too. It seems to have something to do with the user proxy that Dan was describing. Maybe only a user can proxy another user and not a service? 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
Re: GSSAPI for various murder component setups
On 06/22/12 11:31 -0700, Stephen Ingram wrote: One other question though, how often do you refresh your credential cache? From the few examples I've seen, most people seem to refresh very frequently (anywhere from 6 minutes to 1 hour). Given that most tickets can last up to 10 or 12 hours, I'm guessing the shorter life is for security or some other reason? I update once per hour. Since my kinit's are done from cron, if the ticket refresh doesn't work, I get an email containing the error. It gives me up to 9 hours to fix whatever issue is causing the failure. -- Dan White 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
Re: GSSAPI for various murder component setups
On Thu, Jun 14, 2012 at 9:14 PM, Dan White dwh...@olp.net wrote: ...snip... You can control whether clients will get referrals via the proxyd_disable_mailbox_referrals option. When proxying, you would configure the 'cyrus-hostname' user within the proxyservers option on the backend. When the frontend authenticates to the backend, it will send an authorization identity of the previously authenticated frontend user. Like: authcid: none (derived from your kerberos identity) authzid: jsmith Then, from the backend's perspective, jsmith performed the authentication, and gets all the proper ACL permissions applied. The frontend *might* have all the appropriate service principals in place to support client gssapi authentication, however that's not necessary. The client authentication to the frontend, and the frontend's proxy authentication to the backend are distinct authentications. The frontend *will* need to have a non-service principal ticket initialized when performing gssapi authentication to the backend. If I'm reading this correctly, you are saying that you really don't need any of the services (imap,sieve,nntp,pop) in the keytab on the frontend, but only the backend. The frontend authenticates to the backend using it's own credentials (in my case the credential cache from imap/imap.example.com) and proxies the user ticket to the backend services (even with proxyd_disable_mailbox_referrals turned on). It looks like Dave is authenticating on the frontend instead. Is this just a different way of doing things or does each come with advantages/disadvantages? I would think that you *would* need to make the authcid to authzid determination on the backend, so I wonder how this is working for him? 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
Re: GSSAPI for various murder component setups
On Thu, Jun 14, 2012 at 9:14 PM, Dan White dwh...@olp.net wrote: ...snip... You can control whether clients will get referrals via the proxyd_disable_mailbox_referrals option. When proxying, you would configure the 'cyrus-hostname' user within the proxyservers option on the backend. When the frontend authenticates to the backend, it will send an authorization identity of the previously authenticated frontend user. Like: authcid: none (derived from your kerberos identity) authzid: jsmith Then, from the backend's perspective, jsmith performed the authentication, and gets all the proper ACL permissions applied. The frontend *might* have all the appropriate service principals in place to support client gssapi authentication, however that's not necessary. The client authentication to the frontend, and the frontend's proxy authentication to the backend are distinct authentications. The frontend *will* need to have a non-service principal ticket initialized when performing gssapi authentication to the backend. Well, while I'm still not sure which way to go on the issue of where to place the service keytabs, your assertion that one *must* use a user to authenticate from the frontend to the backend in order to proxy the user authentication through seems to be correct. However, I'm not sure exactly why. When I test with imtest as user cyrus using the service principals in the same credential cache as fetched by the program, it works great. Even when testing with the service principals in place with the processes running, examining the caches, all the tickets appear to be properly granted and in the cache, however, every time there is a: couldn't authenticate to backend server: authentication failure error. Is there something specific in the cyrus-imapd code the ensures only a user principal will work? Is there some rationale to this? I've been told by everyone I've asked that there is no difference between user and service principals. Is it as something as silly as the / you alluded to omitting from your user principals before so you could satisfy libsasl2? 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
Re: GSSAPI for various murder component setups
On Wed, Jun 20, 2012 at 6:29 AM, Dan White dwh...@olp.net wrote: On 06/19/12 19:04 -0700, Stephen Ingram wrote: Thank you for your continued help with this. I really appreciate it and am determined to get to the end of this. I think I'm getting closer. I have successfully authenticated using mupdatetest from one of the backends to the mupdate server. I'm using service principals on both ends. I've even specified the imap/imap1.example.com part of the principal in the admins: section of the configuration and after solving several configuration issues on my end, it seems to work! I came across a post from you some time ago talking about /etc/krb.equiv. Would this be an easier way to do this? I tried placing that file on the mupdate server and loaded it with imap/imap1.example.com imap1 and then placed admins: imap1 in my imapd.conf file, but I'm not sure if it works. Do I have to tell cyrus about that file somewhere? I have not used /etc/krb.equiv before, but the last time I dug into the code trying to understand it, I came away with the impression that it's used for kerberosv4 only. Apparently it would be a way to map 'imap/imap1.example.com' to 'imap1'. It might work just as well to just place 'imap/imap1.example.com' or 'imap/imap1.example@example.com' into your proxyservers/*_admins entries. I know that this format works, because it's what I currently have in my config: cyrus-mail1.example@example.net Yes, I was able to get this to work too with mupdatetest, even without the @EXAMPLE.COM piece. I'm guessing if you don't include the realm, it just adds the default one. The krb.equiv does seem to work too, although since you can just specify the entire principal, I'm not sure that it is really that useful in this instance. One other question though, how often do you refresh your credential cache? From the few examples I've seen, most people seem to refresh very frequently (anywhere from 6 minutes to 1 hour). Given that most tickets can last up to 10 or 12 hours, I'm guessing the shorter life is for security or some other reason? 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
Re: GSSAPI for various murder component setups
On 06/19/12 19:04 -0700, Stephen Ingram wrote: Thank you for your continued help with this. I really appreciate it and am determined to get to the end of this. I think I'm getting closer. I have successfully authenticated using mupdatetest from one of the backends to the mupdate server. I'm using service principals on both ends. I've even specified the imap/imap1.example.com part of the principal in the admins: section of the configuration and after solving several configuration issues on my end, it seems to work! I came across a post from you some time ago talking about /etc/krb.equiv. Would this be an easier way to do this? I tried placing that file on the mupdate server and loaded it with imap/imap1.example.com imap1 and then placed admins: imap1 in my imapd.conf file, but I'm not sure if it works. Do I have to tell cyrus about that file somewhere? I have not used /etc/krb.equiv before, but the last time I dug into the code trying to understand it, I came away with the impression that it's used for kerberosv4 only. Apparently it would be a way to map 'imap/imap1.example.com' to 'imap1'. It might work just as well to just place 'imap/imap1.example.com' or 'imap/imap1.example@example.com' into your proxyservers/*_admins entries. I know that this format works, because it's what I currently have in my config: cyrus-mail1.example@example.net -- Dan White 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
Re: GSSAPI for various murder component setups
On Sun, Jun 17, 2012 at 8:21 PM, Dan White dwh...@olp.net wrote: On 06/17/12 18:04 -0700, Stephen Ingram wrote: On Thu, Jun 14, 2012 at 9:14 PM, Dan White dwh...@olp.net wrote: ...snip... Another way to keep your principals straight is that you'll need a user principal where you will run the *test utilities, and a service principal on the server that the *test utility will connect to. The service principals will be initialized for you by libsasl2, and the user principals will need to be kinit'd via some other mechanism (like in your START/EVENTS section). ...snip... The frontend *will* need to have a non-service principal ticket initialized when performing gssapi authentication to the backend. This is *exactly* what I continue to be confused about. Can't a service principal be used on both client and server sides? To me a user should only be a physical person that would login, not a process. For example, can the authenticated (mupdate client and backend) mupdate/imap1.example@example.com connect to (mupdate server) mupdate/murder.example@example.com. Why couldn't this happen? That may work, however you'd need to kinit (or initialize by some other mechanism) on imap1 since the client GSSAPI mechanism won't do that for you. You can still authenticate from a keytab with kinit. You may end up with two different TGTs on imap1. It may be a nightmare to attempt to authenticate from the client side with different service principals, like: mupdate/imap1.example.com imap/imap1.example.com (for proxying) lmtp/imap1.example.com etc. The client side GSSAPI mechanism would need to be told which credentials cache to use for that particular type of authentication, such as with an environment variable. You could post to the cyrus-sasl list to see if someone there has a better recommendation. GS2 is a newer kerberos based authentication mechanism that may handle this in a more sensible way. Thank you for your continued help with this. I really appreciate it and am determined to get to the end of this. I think I'm getting closer. I have successfully authenticated using mupdatetest from one of the backends to the mupdate server. I'm using service principals on both ends. I've even specified the imap/imap1.example.com part of the principal in the admins: section of the configuration and after solving several configuration issues on my end, it seems to work! I came across a post from you some time ago talking about /etc/krb.equiv. Would this be an easier way to do this? I tried placing that file on the mupdate server and loaded it with imap/imap1.example.com imap1 and then placed admins: imap1 in my imapd.conf file, but I'm not sure if it works. Do I have to tell cyrus about that file somewhere? 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
Re: GSSAPI for various murder component setups
On Thu, Jun 14, 2012 at 9:14 PM, Dan White dwh...@olp.net wrote: ...snip... Another way to keep your principals straight is that you'll need a user principal where you will run the *test utilities, and a service principal on the server that the *test utility will connect to. The service principals will be initialized for you by libsasl2, and the user principals will need to be kinit'd via some other mechanism (like in your START/EVENTS section). ...snip... The frontend *will* need to have a non-service principal ticket initialized when performing gssapi authentication to the backend. This is *exactly* what I continue to be confused about. Can't a service principal be used on both client and server sides? To me a user should only be a physical person that would login, not a process. For example, can the authenticated (mupdate client and backend) mupdate/imap1.example@example.com connect to (mupdate server) mupdate/murder.example@example.com. Why couldn't this happen? 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
Re: GSSAPI for various murder component setups
On 06/17/12 18:04 -0700, Stephen Ingram wrote: On Thu, Jun 14, 2012 at 9:14 PM, Dan White dwh...@olp.net wrote: ...snip... Another way to keep your principals straight is that you'll need a user principal where you will run the *test utilities, and a service principal on the server that the *test utility will connect to. The service principals will be initialized for you by libsasl2, and the user principals will need to be kinit'd via some other mechanism (like in your START/EVENTS section). ...snip... The frontend *will* need to have a non-service principal ticket initialized when performing gssapi authentication to the backend. This is *exactly* what I continue to be confused about. Can't a service principal be used on both client and server sides? To me a user should only be a physical person that would login, not a process. For example, can the authenticated (mupdate client and backend) mupdate/imap1.example@example.com connect to (mupdate server) mupdate/murder.example@example.com. Why couldn't this happen? That may work, however you'd need to kinit (or initialize by some other mechanism) on imap1 since the client GSSAPI mechanism won't do that for you. You can still authenticate from a keytab with kinit. You may end up with two different TGTs on imap1. It may be a nightmare to attempt to authenticate from the client side with different service principals, like: mupdate/imap1.example.com imap/imap1.example.com (for proxying) lmtp/imap1.example.com etc. The client side GSSAPI mechanism would need to be told which credentials cache to use for that particular type of authentication, such as with an environment variable. You could post to the cyrus-sasl list to see if someone there has a better recommendation. GS2 is a newer kerberos based authentication mechanism that may handle this in a more sensible way. -- Dan White 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
Re: GSSAPI for various murder component setups
On Wed, 13 Jun 2012, Dan White wrote: From: Dan White dwh...@olp.net To: Stephen Ingram sbing...@gmail.com Cc: info-cyrus info-cyrus@lists.andrew.cmu.edu Date: Wed, 13 Jun 2012 21:23:57 Subject: Re: GSSAPI for various murder component setups ... 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. I suspect some of Russ Allberry's software: http://www.eyrie.org/~eagle/software/ might be useful for obtaining and renewing kerberos credentials. In particular kstart: http://www.eyrie.org/~eagle/software/kstart/ -- Dennis Davis, BUCS, University of Bath, Bath, BA2 7AY, UK d.h.da...@bath.ac.uk Phone: +44 1225 386101 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
Re: GSSAPI for various murder component setups
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@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@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@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@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@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
Re: GSSAPI for various murder component setups
On 06/13/12 21:02 -0700, Stephen Ingram wrote: On Wed, Jun 13, 2012 at 1:23 PM, Dan White dwh...@olp.net wrote: 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 Every service listed within your SERVICES section in cyrus.conf will potentially need it's own service principal, particularly on your backends and mupdate master. Your frontends may not need service principals if your users are not performing GSSAPI authentication. libsasl2 will search for for service principals starting with: imap/ lmtp/ mupdate/ csync/ pop/ nntp/ sieve/ when initialized during service startup. Within your imapd.conf, you can restrict authentication only to gssapi with: imap_sasl_mech_list: gssapi etc. The *test utilities (lmtptest, imtest, mupdatetest, etc.) are invaluable for validating the server side of your setup. Every server in your murder, except perhaps your replica server, will likely need an additional client/user principal. When proxying from the frontend to the backend, the frontend will make a gssapi connection to the backend regardless of the authentication method the client used when connecting to the frontend. If the client supports referrals, then the client will then make it's own connection to the backend using which ever authentication method it's configured to use. -- Dan White 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
Re: GSSAPI for various murder component setups
On Thu, Jun 14, 2012 at 6:20 AM, Dave McMurtrie dav...@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@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@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@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@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@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
Re: GSSAPI for various murder component setups
On Thu, Jun 14, 2012 at 7:05 AM, Dan White dwh...@olp.net wrote: On 06/13/12 21:02 -0700, Stephen Ingram wrote: On Wed, Jun 13, 2012 at 1:23 PM, Dan White dwh...@olp.net wrote: 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 Every service listed within your SERVICES section in cyrus.conf will potentially need it's own service principal, particularly on your backends and mupdate master. Your frontends may not need service principals if your users are not performing GSSAPI authentication. libsasl2 will search for for service principals starting with: imap/ lmtp/ mupdate/ csync/ pop/ nntp/ sieve/ Wouldn't the front ends need these connections worse than the backends (assuming I'm not supporting referrals)? I'm guessing the lmtp is for Postfix connecting to the frontend/proxy to backend to deliver the message? The csync is for replication? when initialized during service startup. Within your imapd.conf, you can restrict authentication only to gssapi with: imap_sasl_mech_list: gssapi etc. The *test utilities (lmtptest, imtest, mupdatetest, etc.) are invaluable for validating the server side of your setup. Every server in your murder, except perhaps your replica server, will likely need an additional client/user principal. Why wouldn't the replica server need a service principal since the backend connects to it to sync? When proxying from the frontend to the backend, the frontend will make a gssapi connection to the backend regardless of the authentication method the client used when connecting to the frontend. If the client supports referrals, then the client will then make it's own connection to the backend using which ever authentication method it's configured to use. But only if the backend is configured for that authentication method, no? 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
Re: GSSAPI for various murder component setups
On 06/14/12 17:20 -0700, Stephen Ingram wrote: On Thu, Jun 14, 2012 at 7:05 AM, Dan White dwh...@olp.net wrote: Every service listed within your SERVICES section in cyrus.conf will potentially need it's own service principal, particularly on your backends and mupdate master. Your frontends may not need service principals if your users are not performing GSSAPI authentication. libsasl2 will search for for service principals starting with: imap/ lmtp/ mupdate/ csync/ pop/ nntp/ sieve/ Wouldn't the front ends need these connections worse than the backends (assuming I'm not supporting referrals)? I'm guessing the lmtp is for Postfix connecting to the frontend/proxy to backend to deliver the message? The csync is for replication? Right. The key thing to keep in mind is that what you place in your SERVICES section is started up as a server, needing it's own service principal. In the case of a replica, the replica is the server, requiring the csync/* principal, and your backend acts as the client, requiring a kinit'd user tgt (or a non-service principal if you will). I actually name these 'cyrus-hostname' instead of 'cyrus/hostname'. There was some case in libsasl2 where the slash caused me some grief. Every server in your murder, except perhaps your replica server, will likely need an additional client/user principal. Why wouldn't the replica server need a service principal since the backend connects to it to sync? Another way to keep your principals straight is that you'll need a user principal where you will run the *test utilities, and a service principal on the server that the *test utility will connect to. The service principals will be initialized for you by libsasl2, and the user principals will need to be kinit'd via some other mechanism (like in your START/EVENTS section). When proxying from the frontend to the backend, the frontend will make a gssapi connection to the backend regardless of the authentication method the client used when connecting to the frontend. If the client supports referrals, then the client will then make it's own connection to the backend using which ever authentication method it's configured to use. But only if the backend is configured for that authentication method, no? You can control whether clients will get referrals via the proxyd_disable_mailbox_referrals option. When proxying, you would configure the 'cyrus-hostname' user within the proxyservers option on the backend. When the frontend authenticates to the backend, it will send an authorization identity of the previously authenticated frontend user. Like: authcid: none (derived from your kerberos identity) authzid: jsmith Then, from the backend's perspective, jsmith performed the authentication, and gets all the proper ACL permissions applied. The frontend *might* have all the appropriate service principals in place to support client gssapi authentication, however that's not necessary. The client authentication to the frontend, and the frontend's proxy authentication to the backend are distinct authentications. The frontend *will* need to have a non-service principal ticket initialized when performing gssapi authentication to the backend. -- Dan White 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
GSSAPI for various murder component setups
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. 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
Re: GSSAPI for various murder component setups
On 06/13/2012 03:57 PM, 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. Hi Stephen, I'm not aware of any documentation at all, but it would be nice to have that. We're running a murder configuration at CMU and we use kerberos auth between servers. Please feel free to ask any questions you need and I'll do my best to answer promptly. If you don't even know where to start, I can try to put together some basic information in an email and we can go from there. Perhaps when you get it all working you could contribute some docs back :) 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
Re: GSSAPI for various murder component setups
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. -- Dan White 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
Re: GSSAPI for various murder component setups
On Wed, Jun 13, 2012 at 1:23 PM, Dan White dwh...@olp.net 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
