[Dovecot] [PATCH] Allow GSSAPI to work with multihomed hosts
I saw some past chatter on this in the list archives, but here is another stab and another rational. This patch follows a similar patch to openssh in that it allows any key in the specified keytab to match the incoming host key. This is necessary for multihomed hosts. See: https://bugzilla.mindrot.org/show_bug.cgi?id=928 IMAP/POP seem to be a strong candidate to be multihomed because they are very likely to have an internal to a firewall and external to a firewall name. Due to the way MIT kerberos handles host name resolution via reverse IP lookup this can often result in multiple principle names and there is simply nothing to be done about it. This is my situation.. When you add windows into the mix, which uses a totally different set of rules to determine the principle all hope seems to be lost to have a single service principle name for an imap server :( I was able to make things work for my environment using only the auth_gssapi_hostname feature if only MIT kerberos was used, but as soon as windows SSPI was involved it choose a different hostname. Thus we want to have GSSAPI to match any service principle in the keytab. As far as security concerns go, the admin can configure the keytab for dovecot to be seperate from the system key tab and contain only valid imap SPNs, but in truth it probably doesn't matter. I choose to just use the magic configurable: auth_gssapi_hostname = $ALL rather than introduce more configurables FWIW, after applying this I now am happy to say I have an Active Directory KDC, with dovecot providing gssapi auth to thunderbird on both linux (mit kerb 1.6) and windows (sspi).. --- dovecot-1.0.13/src/auth/mech-gssapi.c 2007-12-11 11:52:08.000000000 -0700 +++ dovecot-1.0.13-jgg/src/auth/mech-gssapi.c 2008-08-11 23:52:15.000000000 -0600 @@ -101,6 +101,13 @@ gss_name_t gss_principal; const char *service_name; + if (strcmp(request->auth->gssapi_hostname,"$ALL") == 0) { + auth_request_log_info(request, "gssapi", + "Using all keytab entires"); + *ret = GSS_C_NO_CREDENTIAL; + return GSS_S_COMPLETE; + } + if (strcasecmp(request->service, "POP3") == 0) { /* The standard POP3 service name with GSSAPI is called just "pop". */
On Aug 12, 2008, at 2:28 AM, Jason Gunthorpe wrote:
I choose to just use the magic configurable: auth_gssapi_hostname = $ALL rather than introduce more configurables
Yes, the less different settings there are the better. :) Committed to
v1.2 tree:
http://hg.dovecot.org/dovecot-1.2/rev/9ca5e8f66d10
auth_request_log_info(request, "gssapi","Using all keytab entires");
I'm beginning to wonder about the logging in the code though. To me it
looks like all of these should rather be log_debug instead of
log_info. And I don't see any log_infos for logging why the user login
actually failed (does gssapi even tell anything about it?). Or debug
logging about what the usernames are when trying to log in. And the
GSSAPI errors probably should be logged with log_info instead of
log_error, because they probably aren't errors that the sysadmin can
do anything about, but rather some client misconfiguration or a client
bug (at least after the initial configuration is done and working).
Any thoughts on those issues?
On Wed, Aug 13, 2008 at 03:07:55PM -0400, Timo Sirainen wrote:
auth_request_log_info(request, "gssapi","Using all keytab entires");I'm beginning to wonder about the logging in the code though. To me it looks like all of these should rather be log_debug instead of log_info. And I don't see any log_infos for logging why the user login actually failed (does gssapi even tell anything about it?). Or debug logging about what the usernames are when trying to log in. And the GSSAPI errors probably should be logged with log_info instead of log_error, because they probably aren't errors that the sysadmin can do anything about, but rather some client misconfiguration or a client bug (at least after the initial configuration is done and working).
Well, I am not an expert on gssapi, but there are definately failures due to administrator misconfiguration and some are the users fault.
For instance any failure from obtain_service_credentials is a configuration error. Failures due to service credential mismatch, encryption type mismatch, etc are also configuration errors, but they occure later in the process..
To be honest nobody seems to do a super job of logging kerberos messages. The erro messages from the library are terse and contain no information from the packet. Debugging a service principle name mismatch is a royal pain.
The log in my patch probably should be log debug, I just copied the log level from the existing 'Obtaining credentials' message. They are not important unles someone is debugging.
Thanks, Jason
participants (2)
-
Jason Gunthorpe
-
Timo Sirainen