Kerberize MS Exchange?

[paul]

Ken Hornstein schrieb:
>> Luke Scharf schrieb:
>>> I use Thunderbird with GSSAPI with Dovecot on my home-network.  It works 
>>> nicely.  The only weird thing was that they used the term "Secure 
>>> Authentication" -- instead of "GSSAPI" or "Kerberos5" or "krb5".
>> Thats by design. Technically GSSAPI is only one of the SASL mechanisms 
>> offered by the server. "secure authentication" just enables the SASL 
>> negotiation procedure which might result in something completely 
>> different than GSSAPI (DIGEST-MD5 in my case, or NTLM for Outlook, etc). 
>> Besides: "GSSAPI" or "Kerberos5" in a general purpose UI? WTF!
> 
> Urrrrk.  I STRONGLY disagree with you on this!  
Thats always a good start ;)

> Here are my reasons:
> 
> - From the programmer/network protocol perspective, being able to write one
>   program or define one protocol that negotiates a whole group of SASL
>   mechanisms is great.  But from an administrator perspective, it
>   bites.  I don't want to have users fall back to DIGEST-MD5 if
>   Kerberos fails, I want to fix the Kerberos problem! 
As you probably know, you can do that with the sasl mechlist server side.

> (And very likely
>   if GSSAPI fails, DIGEST-MD5 isn't going to work for that user anyway;
>   of course that depends on your site, but I think that's more true
>   than not). 
I's not common put possible (you'd have to have credentials in more than 
one place (not so good)), however DIGEST-MD5 and others might still work 
where GSSAPI will fail (e.g. roadwarriors with broken time sync, no 
ticket, KDC not reacheable from the client, etc.)

>   If the user explicitly picks a mechanism to use, these
>   problems are eliminated.  
My point is that SASL mechanisms are all greek to average users, it is 
pointless to force a choice on them they can't reasonably make.

>   Since many mainstream apps have each SASL
>   mechanism coded explicitly (Thunderbird among them) there's not even
>   a programming reason to obfuscate the choice of SASL mechanism (and
>   explicitly picking the mechanism prevents a downgrade attack).
Again, you can configure SASL server side to prevent this. Postfix for 
example has options to allow different mechanisms over TLS secured 
connections vs. plain SMTP.

[snip]
>   I've helped a number of people get GSSAPI with Thunderbird working.
>   The general flow of questions looks like this:
> 
>   - Uh, does it support Kerberos?  I don't see anything where I can enable
>     it under Preferences.
> 
>   - So, uh, if it supports Kerberos, how do I turn it on?
> 
>   - Okay, I checked "Secure Authentication", but that didn't work, and
>     it asked me for a password.  I typed in my Kerberos password, but that
>     failed.
Yes, it would be nice if TB had some log/status window to check what was 
negotiated.

> 
>   First off, "Secure Authentication" is a SHITTY checkbox.  What this
>   means is not clear, even to me.  Does this mean "Use TLS?"  Does this
>   mean "Negotiate SASL?"  Does it mean both?  It's confusing to the
>   user.  If it was one user, I would say that this confusion is an
>   anomaly, but it seems like EVERYONE that tries to use Thunderbird
>   here has problems with this.
You have very educated users ;)

> 
>   Secondly, the "attempt to negotiate all mechanisms" problem generates
>   a number of practical issues.  The first is error reporting - let's
>   say you try GSSAPI, and that fails.  Should you then report GSSAPI
>   errors back to the user?  Well, in Thunderbird that doesn't happen; I
>   can sort-of understand why Thunderbird doesn't do that, because most
>   of the users don't use GSSAPI and any GSSAPI errors would be the
>   "wrong" errors, but this illustrates the problem with multi-mechanism
>   negotiation: which errors do you report to the user when you try
>   multiple mechanisms?
As I said, a log would be nice. IMO if the site policy *allows* GSSAPI 
and say NTLM fallback there should be no error if GSSAPI fails and NTLM 
succeeds. A user visible failure is only required if all allowed 
mechanisms failed because this ultimately results in a failed service 
(reading email).

>   
>   Another problem with multi-mechanism negotiation is that they have
>   different user interactions.  For example, CRAM-MD5 and DIGEST-MD5
>   likely want to prompt the user for a password, but of course for
>   GSSAPI/Kerberos you normally wouldn't have the app do that; it would
>   be done via a Kerberos application (or perhaps the GSSAPI library
>   would do that).  So should an application prompt for a password no
>   matter what the mechanism?  Probably not, but I've seen cases where
>   that happens; again, more confusion for the user.
Well, afaik if GSSAPI is the only mechanism advertised by the server 
there will be no password prompt. If the fallback is allowed you'd get a 
prompt. It's pretty much the same thing as you get with HTTP-Negotiate 
where NTLM will prompt but kerberos will not. It's the admins choice...


>   Part of the confusion may be historical; many of our users were
>   previously using Eudora, and that had a weird dance where you in some
>   cases EXPLICITLY had to not turn on the "Use secure authentication"
>   dialog (but it also had an explicit Kerberos configuration dialog).
> 
> I can contrast this with people who use Apple Mail, which has a very
> clear configuration dialog which explicitly says, "Use Kerberos 5
> (GSSAPI)".  No one ever asks me if Apple Mail supports Kerberos, or how
> to turn it on.  The Kerberos errors (in most cases) are presented to
> the user.  It just works better.  Presenting the SASL mechanism to the
> user is a clear win.  A lot has to happen under the scenes to make
> it all work, but I cannot see any reason why presenting this to the
> user is bad.
Hmm, I can see where you are coming from... You say TB is hard to debug 
wrt. failures because you don't get error messages? Granted, if TB had a 
"use kerberos" checkbox you'd at least know that it was kerberos that 
failed (but still no error messages, no?). And with proper error 
messages you'd get all the info in the "secure authentication" case as well.

cheers
  Paul
> 
> --Ken
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>