Re: [Dovecot] [PATCH] Allow GSSAPI to work with multihomed hosts
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? PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] [PATCH] Allow GSSAPI to work with multihomed hosts
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
[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.0 -0700
+++ dovecot-1.0.13-jgg/src/auth/mech-gssapi.c 2008-08-11
23:52:15.0 -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. */
