Closed Bug 307788 Opened 19 years ago Closed 19 years ago

if Kerberos tickets don't exist when launching T-Bird, get Krb Ticket Manager to prompt for them

Categories

(Thunderbird :: Security, enhancement)

Product:
Thunderbird
Component:
Security
Platform:
PowerPC
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: dautermann, Assigned: darin.moz)

References

Details

(Keywords: fixed1.8.1.8)

Attachments

(1 file, 2 obsolete files)

a one line patch...
1.29 KB, patch
Bienvenu
: review+
Bienvenu
: superreview+
mscott
: approval1.8.1.8+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: 1.6a1 (20050908)

THANKS for getting the Kerberos / GSSAPI mail enhancements into Mozilla.  

The #1 comment I've been hearing from people testing out these excellent changes
is that: if Kerberos credentials don't exist (or are expired), the user is
expecting Thunderbird to bring up the Kerberos Ticket Manager to prompt for the
Kerberos password to generate new tickets.  

Every other mail client that does GSSAPI does this.  TBird should as well.  

One way to fix this problem is to back the change from bug 240643 out (look for
the lines in nsAuthGSSAPI.cpp), but this would certainly reintroduce the problem
that particular patch fixed.  Another possible solution would be to only apply
the bug 240643 patch if mServiceName did not start with the prefix of "smtp@",
"imap@" and "pop@".  There are other possible solutions and I'm willing and
eager to write a patch.

Reproducible: Always

Steps to Reproduce:
This assumes you have a mail server that knows how to authenticate the GSSAPI way.

1.  Make sure the Kerberos ticket cache is clear.
2.  Launch Thunderbird.
2.  Connect to any of your GSSAPI-configured mail servers.
3.

Actual Results:  
you'll get the standard Thunderbird "Password?" popup alert.

Expected Results:  
The Kerberos Ticket Manager should automatically pop up, requesting for the user
to type in their Kerberos password (which generates the tickes that Thunderbird
needs to access the mail servers).
I imaging this is a core networking bug that affects Firefox as well, but I'll
let Darin move it if so.
Assignee: dveditz → darin
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Here is the message I sent to Micheal about why we originally disabled
auto-prompting for kerberos in OS X for SPNEGO (Negotiate) Authentication.

>The problem is that with spnego HTTP authentication, if a user didn't have
>kerberos configured, or were traveling remotely and had no real way of talking
to >their KDC, they would just cancel the prompt and then fail over to some
other >form of authentication.  The problem with doing this with HTTP was that
every >page which used SPNEGO prompted them, and then they'd cancel it again. In
some >situations they were even getting prompted with every new connection to
the same >server.  It would be less of a problem with mail.  Maybe no problem at
all, if >you can save your password and with it your associate authentication type.
Thunderbird keeps seperate prefs than firefox, correct? If so you could just set
network.negotiate-auth.using-native-gsslib to false and the prompting will be
enabled again and not interfere with firefox.  Kind of a hack, but a quick fix
at least for the branch.
How about my idea of looking for "pop@", "smtp@" or "imap@" in the service name
(passed in to the auth module in the init call) and if that prefix was found,
ignoring the code for bug 240643?

Presumably the spnego problem only manifested with URLs that would bring up a
service name of "http@" or "https@"?  

This would allow the auth module to co-exist peacefully with Firefox AND
Thunderbird.

(In reply to comment #4)
> How about my idea of looking for "pop@", "smtp@" or "imap@" in the service name
> (passed in to the auth module in the init call) and if that prefix was found,
> ignoring the code for bug 240643?

I'm fine with that as well.   Unless Darin disagrees, I say code that up for
review.  But please make sure that users which cancel the kerb dialog are not
constantly re-prompted.
Comment on attachment 195674 [details] [diff] [review]
only ignore prompting for Kerberos password if we're NOT doing mail stuff

I coded up one solution and am attaching it.  

Unfortunately, if the user clicks "cancel" on the Kerberos prompt, if they try
to reopen/reconnect to the server they will continue to be prompted for a
Kerberos password unless they have another secure way of authenticating saved
in
the prefs (because the "secure" checkbox has to always be set for POP & IMAP to
use Kerberos authentication).  

This behavior is the same as what I see in other mail clients (e.g. Apple's
Mail.app).  If I click cancel in the Kerberos prompt, the account is considered
"offline" and when I try to bring it back online, it prompts me again to get
valid Kerberos tickets.

I am also a little worried about this solution as it's within a #ifdef MACOSX
block... so I wonder if Windows users will still continue to have the problem
of
the Kerberos ticket manager not appearing to do the password prompt.
(In reply to comment #7)
> (From update of attachment 195674 [details] [diff] [review] [edit])
> I coded up one solution and am attaching it.  
> 
> Unfortunately, if the user clicks "cancel" on the Kerberos prompt, if they try
> to reopen/reconnect to the server they will continue to be prompted for a
> Kerberos password unless they have another secure way of authenticating saved
> in
> the prefs (because the "secure" checkbox has to always be set for POP & IMAP to
> use Kerberos authentication).  

I would have hoped that that option meant REQUIRE secure authentication as
opposed to ALLOW secure authentication. But that would be a discussion for
another bug. What other authentication types are supported in the "secure" mode?
Something users can fail over to, or is Kerberos the only option?

> I am also a little worried about this solution as it's within a #ifdef MACOSX
> block... so I wonder if Windows users will still continue to have the problem
> of
> the Kerberos ticket manager not appearing to do the password prompt.

AFAIK only the MAC verion of MIT kerberos which comes with Mac's auto prompts
users for credentials no other version does this.

I don't know what will happen if a windows user using SSPI rather than MIT has
no credentials.  Unfortunatly the new SSPI kerberos code which was put there for
mail to use (Wrap, Wrap), and using using pure kerberos rather than negotiate
has received little to no testing to my knowledge.  But again that would be a
separate bug if a problem exists.
please use something like -pu7 as diff options... also, don't use tabs.
resubmitting patch with the correct "cvs diff" options, minus the tabs.  thanks
for the reminder.
Attachment #195674 - Attachment is obsolete: true
I'm not that familiar when Mac OS X will (and won't) prompt, but I've got some
concerns here.

Many, many, servers advertise GSSAPI support when they don't actually have any -
this is mainly because Cyrus SASL will claim to support GSSAPI if its GSSAPI
plugin is installed, regardless of whether Kerberos is configured at all on the
server in question. So, I'm concerned that prompting will result in a large
number of nuisance prompts when users are accessing services which don't have
Kerberos support at all.

(In reply to comment #11)

My gut feeling (which I'll have to do a bit of research to prove) is that if
there is no entry for the matching realm in the
/Library/Preferences/edu.mit.Kerberos KDC list, then the Kerberos ticket manager
will not come up.

In other words, if I set up an account for a mail server at "goober.com" where
there is no "goober.com" realm found in the list of KDC servers, there's no
reason to expect that the Kerberos ticket manager is going to appear with a
prompt to create credentials when it can't really authenticate.  

Now this might be a real problem if a student sets up a mail server in his dorm
room at "upenn.edu" and it's CAPA list includes "GSSAPI" when the student's
server isn't really talking to a KDC.  

I don't believe this patch is going to bring up any nuisance prompts except in
edge cases like that upenn.edu dorm room case.  


Comment on attachment 195684 [details] [diff] [review]
only ignore prompting for Kerberos password if NOT doing mail stuff

Assuming that the mac will only prompt if the server domain is known to the
KDC, is this patch OK with you, Christoper?
Attachment #195684 - Flags: review?(cneberg)
Comment on attachment 195684 [details] [diff] [review]
only ignore prompting for Kerberos password if NOT doing mail stuff

(In reply to comment #13)
> (From update of attachment 195684 [details] [diff] [review] [edit])
> Assuming that the mac will only prompt if the server domain is known to the
> KDC, is this patch OK with you, Christoper?
> 

From what I've heard from users running Mac OS X computers with no kerberos
configuration besides the default configuration files which come with the OS's,
they were getting prompted with the Kerberos dialog with every SPNEGO enabled
web site they hit. So I assume the same would be true for mail.  This also may
be caused by Active Directory publishing some Kerberos information to DNS,
which MIT kerberos may be picking up (but without the default domain being
written anywhere I don't remember if the prompts were usable or not).  

Also, since SMTP on Exchange announces that it uses kerberos and I'm not sure
that it works with our configuration these users will get prompted whenever
they send an email.

I'm plussing the patch because the code itself is fine and maybe we need to get
to on the trunk for people to test to decide if there really is a problem or
not.
Attachment #195684 - Flags: review?(cneberg) → review+
Comment on attachment 195684 [details] [diff] [review]
only ignore prompting for Kerberos password if NOT doing mail stuff

how about just

PRBool doingMailTask = mServiceName.Find("imap@") || mServiceName.Find("pop@")
|| mServiceName.Find("smtp@"));

other than that, I'm willing to check this into the trunk, and as Christoper
said, see what happens.
(In reply to comment #15)

> other than that, I'm willing to check this into the trunk, and as Christoper
> said, see what happens.

cool!  Does the status of (or a flag in) this bug change when it's checked in?


I was hoping you could compile and test a patch that made the change I
suggested, then attach it, and then I would check it in to the trunk.
this was David B.'s suggestion... appears to work great!
Attachment #195684 - Attachment is obsolete: true
Comment on attachment 200634 [details] [diff] [review]
a one line patch...

thx, I'll check this in to the trunk, with one more small change, !doingMailTask instead of doingMailTask == PR_FALSE.
fix checked into trunk, mac-only.
Can this patch be checked in to the 1.5 (mozilla1.8) tree as well? I'd really like to see in in the next 1.5 beta release, as well at the final version of 1.5
No, sorry, I think it's way too late for that. Did we get any feedback from users about the trunk builds with this change? Maybe we can get it into a point release at some point.

marking fixed, since it's fixed on the trunk.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Um, can I ask why not? This is a serious usability problem on the Mac OS X platform, the patch is pretty trivial, and 1.5 has not been released yet. Why not make a push to get kerberos support fully working for the 1.5 release?
Sorry Jim, we're long past the lock down point for the 1.5 releases. We're only evaluating critical issues that would require us to respin and re-verify the release at this point. 

This patch hasn't even been reviewed and landed on the trunk yet. I'd suggest focusing on those steps. 

This can be a good candidate to get into the next release for sure! 
Comment on attachment 200634 [details] [diff] [review]
a one line patch...

retroactively marking reviewed,and carrying over cneberg's r=. This was checked into the trunk.
Attachment #200634 - Flags: superreview+
Attachment #200634 - Flags: review+
I've used Thunderbird with this patch applied quite a bit, I thought I should report that there is still some quirkiness in when the Kerberos ticket manager is or is not invoked. Very frequently, for instance, the ticket manager comes up even though there is still an unexpired TGT in the cache. This is most likely to happen when Thunderbird is first started up, or if it has been idle for a while (for instance, if the system has been sleeping). This erroneous password prompt does not always happen, however - it seems to be a function of how old the TGT is: the older it is, the more likely I am to get prompted.

Another common problem is that sometimes Thunderbird will trigger two instances of the ticket manager at the same time, but the ticket manager seems to be smart enough to identify this occurence and quits the second instance.

Another, much rarer, annoying behavior is that the ticket manager is not always triggered when it should be. Sometimes when I launch Thunderbird, it will lock-up, displaying Mac OS X's beachball cursor. When it gets in this state, if I launch the ticket manager by hand and authenticate, Thunderbird will come back to life and operate normally. This has only happened to me a few times - I haven't yet found a trigger for it.

I would like to try to pin these glitches down better, but I don't have a good understanding of when and where the auth module is called. For instance, I suspect that the extra calls to the ticket manager are triggered whenever the timer controlled by mail.check_time expires, but I haven't been able to identify the relevant source files. If there's a relevant design document somewhere, or if someone is willing to answer a few questions, that would help a lot in getting these annoyances debugged.
Comment on attachment 200634 [details] [diff] [review]
a one line patch...

nominating for 2.07, per bailey@newman.upenn.edu 's request.
Attachment #200634 - Flags: approval1.8.1.7?
Attachment #200634 - Flags: approval1.8.1.7? → approval1.8.1.7+
landed for 1.8.1.8
Keywords: checkin-needed → fixed1.8.1.8
YEAH works in 2.007pre (20071004)! Thanks!

Looking forward to seeing this added to Eudora tree :)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: