dovecot - Aug 2008 - [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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20080813/55703f2b/attachment-0002.bin>

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