Closed Bug 238316 Opened 20 years ago Closed 18 years ago

Exchange server authentication displays Kerberos dialog then crashes

Categories

(SeaMonkey :: General, defect)

PowerPC
macOS
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: mstockman, Unassigned)

Details

(Keywords: crash)

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040322
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040322

When I try to log on to my company's Exchange server's Outlook Web Access (OWA)
securely (using HTTPS), I get a Kerberos authentication dialog. When I cancel, I
then see the standard login, which gets me in, but then I see the Kerberos
dialog again. Cancelling leaves me logged in to OWA, but if I read mail the
Kerberos dialog keeps showing up until Mozilla eventually crashes.

Reproducible: Always
Steps to Reproduce:




I have also crashed recent nightlies of Camino and Firefox on the Mac. This bug
does not appear to happen on Windows -- I don't have a recent Linux nightly to
try, but will soon.

This worked up until a few (?) days ago.
Forgot to attach this initially. Hope it's useful.
Keywords: crash
can someone track down when this regressed? this is pretty bad.
Flags: blocking1.7?
Are the Kerberos dialogs thrown up using Java?
In case this is helpful, the application running that pops up this alert is
called "Kerberos Login Server" in the OS X process list, and "ps" on the
command line shows the following entry when it's running:

/System/Library/Frameworks/Kerberos.framework/Servers/KerberosLoginServer.app/Contents/MacOS/


Hope this is useful.
darin or benc, can either of you help us figure out what's going on here?
this sounds like it might be related to the recent support that was added for
Kerberos auth via GSSAPI (which exists on MacOSX).

nknegotiateauth is on the stack in the crash, so it definitely looks to be related.

the Kerberos dialog is not from Mozilla.  that is from the local Kerberos
installation.
You can workaround this problem by deleting libnknegotiateauth.dylib in the
Firefox or Camino "components" directory.
> I have also crashed recent nightlies of Camino and Firefox on the Mac. This bug
> does not appear to happen on Windows -- I don't have a recent Linux nightly to
> try, but will soon.
> 
> This worked up until a few (?) days ago.

Unless Bug 237572 is wrong negotiateauth hasn't been checked into Firefox yet. 
I have no idea if Camino includes it.

It sounds like if you don't have kerbereros cred's calling gss_init_sec_context
on a Mac will prompt you for your kerberos password. (Can someone who uses a Mac
confirm this?)  That is not necessarily a bad reaction (just strange), the
question is why does it bring up the kerberos dialog again after basic auth
succeeds? I would think the auth cache would remember that you typed your http
basic auth password in correctly previously and just keep re-using your password
underneath but for whatever reason, Negotiate auth is being processed multiple
times even when a subsequent auth type succeeds.
The stack trace doesn't show any of the negotiateauth functions being used, Im
skeptical that this is from the new extension.  The prompt for the password is
strange since the negotiateauth extension does not prompt for name and password. 

This seems to be a bug relating to how the Mac browser interacts with the Mac
kerberos libraries.  It seems that the Mac Kerberos implementation is
automatically Is there a setting on the system that enables/disables the
automatic prompting for name/password when the user needs to refresh their
Kerberos tickets?  
OOps, I cut off part of my comment above, what I meant to say is:

This seems to be a bug relating to how the Mac browser interacts with the Mac
kerberos libraries.  It seems that the Mac Kerberos implementation is
automatically trying to create a ticket if one is not present and this is
causing a problem for Mozilla.

Is there a setting on the system that enables/disables the
automatic prompting for name/password when the user needs to refresh their
Kerberos tickets?  

I ran a Mozilla test tonight (since Mozilla brings up the Kerberos auth and
Firefox and Camino just crash). If I remove
/Applications/Mozilla.app/Contents/MacOS/components/libnegotiateauth.dylib (not
the libnknegotiateauth.dylib file mentioned for the other two apps), Mozilla now
behaves just like the other two apps... it logs me in to the OWA, but then crashes.

Not sure what this means, but I'm hoping it means something to someone here. Is
it possible that something in OWA is crashing the apps that is unrelated to the
authentication?
Status: UNCONFIRMED → NEW
Ever confirmed: true
1.  If you have valid AD kerberos credentials to start with (run kinit before
staring Mozilla), does the crash still occur?  

2.  If you put proper username and password into the kerberos dialog are you
able to log in?

3. Is the Kerberos pop up dialog not modal to mozilla?

4.  When you enter your password into the normal Mozilla window, is it using
NTLM or Basic auth?

If you are leaving the dialog in the background for a long period of time, I'm
wondering if the channel still exists when you push cancel or the dialog times
out (not sure if it times out or not, don't currently have a Mac to test with).

I believe the double prompting to be http networking issues, since the two auth
types we are probably discussing are Negotiate and NTLM they are both set up so
they don't cache the challenge or creds, so with every new connection, Negotiate
is retried, then NTLM is re-tried. So new connection == new kerberos prompt.
I'm working on a patch to get rid of the kerberos prompt.  Hopefully this will
get rid of the crash as well.
(In reply to comment #13)
> 1.  If you have valid AD kerberos credentials to start with (run kinit before
> staring Mozilla), does the crash still occur?  

I don't have such credentials, but I'm guessing "yes" because Firefox and Camino
both crash even without asking for Kerberos credentials.

> 2.  If you put proper username and password into the kerberos dialog are you
> able to log in?

Don't have valid credentials.
 
> 3. Is the Kerberos pop up dialog not modal to mozilla?

No, it does not appear to be. Mozilla is firing off a separate application
provided by OS X to handle this.

> 4.  When you enter your password into the normal Mozilla window, is it using
> NTLM or Basic auth?

NTLM
(In reply to comment #12)
> I ran a Mozilla test tonight (since Mozilla brings up the Kerberos auth and
> Firefox and Camino just crash). If I remove
> /Applications/Mozilla.app/Contents/MacOS/components/libnegotiateauth.dylib (not
> the libnknegotiateauth.dylib file mentioned for the other two apps), Mozilla now
> behaves just like the other two apps... it logs me in to the OWA, but then
crashes.
> 
> Not sure what this means, but I'm hoping it means something to someone here. Is
> it possible that something in OWA is crashing the apps that is unrelated to the
> authentication?

From this comment I agree that is probably not negotiateauth causing the crash.
I'm still working on a patch to disable prompting, but I don't think it has
anything to do with this bug. 

What Version of OWA are you using?
Does it only crash when OWA loads an applet?
Do you have to do something in particular to crash Mozilla? (Look at the
calender, compose a new email, set up a new appointnment, etc?)

Can you tell what day it quit working? (try a couple of nightlies from a few
days ago)
To turn off NegotiateAuth without having to delete the shared lib, go to
about:config and change network.negotiate-auth.trusted-uri to an empty string "".
I went back to a bunch of previous nightly builds, all the way back to the
nightly from March 16 (which is the oldest available on the site), and the crash
still occurs. I know this worked without crashing in the past, but clearly
before Mar. 16.

Just to be safe, I used that nightly to create a new profile, although on the
same machine. Same crash happens.

The sequence of events is this:

1) Connect using https connection to the OWA server. See Kerberos dialog and cancel.
2) NTLM authentication comes up. Authenticate and click OK. See Kerberos dialog
and cancel again.
3) Read some mail... eventually, see Kerberos dialog one or two more times...
after cancelling each time, the crash happens. No calendar, no compose, no applets.

The Outlook Web Access provided is from Exchange Server 2000. I'm sorry I can't
provide any more details about when this broke.
Bug 240643 deals with the Kerberos prompting


OWA Crash bugs

Bug 237809
Bug 199193
Mike, can you try previous releases? maybe 1.6 and 1.7 alpha?
http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/  If you can get it down
to a window of time between releases, then you can use the nightly archived
builds to do a binary search and hopefully narrow it down to a small enough
window that we can see something in the checkins from that time period. Archived
builds going back to august of last year are available at
http://archive.mozilla.org/pub/mozilla/nightly/
Such an obvious thing, I'm sorry I didn't try it earlier. All of the 1.7b
nightlies exhibited the problem, and I didn't even think to try a previous release.

The result is that 1.7a (build ID 2004021810) does *not* exhibit this bug, so it
was introduced after that build but before the oldest nightly binary build found
in <ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/>. With 1.7a, there
was no Kerberos authentication, and there was no crash, no matter how long I
bounced around the site. Just a standard NTLM authentication dialog, a single time.

Hope this helps to narrow it down.
All right, narrowed it down slightly. Neither bug (Kerberos authentication or
the OWA crash) appears in the Feb 18 (2004021810) build. Then there was a long
dry spell without any Mac builds. The next Mac build is Mar 01 (2004030105), and
the Kerberos authentication bug does *not* exist, but the authentication crash does.

So, to summarize:

The OWA crash after authenticating appeared sometime between Feb 18 and Mar 01.
I can't be more specific because there were no Mac builds during that time.

The Kerberos authentication bug appeared some time between Mar 01 and Mar 22,
although I don't have time to pin it down right now. Perhaps tomorrow night, if
needed. Let me know.
Darin, anyone else, is there an easy way to disable Kerberos auth via GSSAPI on
Mac? 
Flags: blocking1.7? → blocking1.7-
Comment 18 tells how to disable negotiateauth.

Disabling negotiateauth will NOT fix the crash. I believe the crasher part of
this bug is one of the bugs marked unconfirmed in comment 20.

Bug 240643 has been split off for the prompting issue.

I recommend someone look closer to see if the crasher part bug is a dup, and
close it as necessary. 

Asa, if you decide this to keep this bug (or one of its possible dups) as not
blocking the release, it needs to at least be in the release notes that Moz 1.7
on the Mac will not likely work with OWA.
Can you look at bug 248887 ? Eventhough it's not MacOSX, it's very similar,
involves OWA, NTLM and crash only when cancelling.
Maybe there's an underlying root cause that's not MacOSX-only ?
Product: Browser → Seamonkey
This bug went away a long time ago, but nobody ever marked it fixed. As the originator, I'm marking it works for me... let me know if that's not the right way to handle it.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: