199644 - [NTLM] Auth dialog doesn't show Realm

Status: VERIFIED INVALID

(Core :: Networking: HTTP, defect)

Description

[Olivier Cahagne]

build ID: 2003032804 (trunk) on Win2k.

Just tried accessing a host using HTTP NTLM authentication after final checkins
for NTLM landed on trunk yesterday.

Trying to access par-fs1 gets a popup window where the realm is missing (see
attachment), which didn't occur with previous builds (I could see the full realm).
Then, the authentication doesn't work, login is refused.

It works fine with IE6 (no auth dialog).

Comment 1

[Olivier Cahagne]

Attachment: Auth dialog screenshot

Comment 2

[Olivier Cahagne]

Attachment: HTTP Sniffer trace (shows the Realm)

Comment 3

[Olivier Cahagne]

Attachment: Mozilla HTTP log (nsHttp:5)

par-fs1 fileserver is a NetApp 6.2.1.

Comment 4

[Darin Fisher]

olivier:  several things you should know:

1- the server is offering two challenges:

  WWW-Authenticate: NTLM
  WWW-Authenticate: Basic realm="Windows(tm) Authentication"

the first is NTLM and the second is Basic.  only the Basic auth challenge
includes a realm parameter.

2- RFC2617 says that a useragent should select the first challenge it
understands.  mozilla for windows now understands NTLM, so it selects that
challenge.  therefore, the fact that a realm string is sent with a basic auth
challenge is irrelevant.

3- NTLM support is not entirely complete.  we need to prompt the user to enter
not only username and password, but also domain.  for the time being the correct
way to enter your NT domain is to enter you username as "domain\username".  this
will be corrected in a future release.

4- IE6 when confronted with a NTLM challenge will automatically try sending your
windows logon {domain,username,password} without asking your permission.  this
is in my opinion a great security risk, so mozilla does not do the same.  if you
see no auth dialog with IE, then i suspect IE is sending your default windows
logon... and i suspect the server is happy to accept that.  to make this work
with mozilla, you should try entering your domain\username, password in the
prompt given by mozilla.

so, technically, this bug is invalid because NTLM challenges do not include a
realm.  however, maybe we should morph this bug to be able making NTLM UI better.

Comment 5

[Olivier Cahagne]

Darin, thanks for these informations. You're right on all points.
I'm ok to mark it INVALID unless you want to keep it as a NTLM UI bug report.

The auth dialog is broken anyway, see bug 195780.

Comment 6

[Darin Fisher]

marking INVALID, filed bug 199674 for improving NTLM auth UI.

Comment 7

[benc]

VERIFIED/invalid:

I'm sure this discussion will be very helpful for future bug filers.

I wish every bug had clear problem -> explaination exchanges...

Comment 8

[adem baba]

I have read all the comments, including Darin's.
http://bugzilla.mozilla.org/show_bug.cgi?id=199644#c4

While what Darin says may be fully applicable elsewhere, I am afraid he seems to
overlook the simpler and more important case: NTLM usage on the Local network.

We use Windows Terminal Server. This means *one* single IP for n number of
users. Which, then, means I can not, unequivocally and transparently,
authenticate the users based on their IP addresses.

In our case, the fact that Moz brings up a popup to be filled by the user is not
acceptable to at all. I want all this to take place without users involvement
(just like an ordinary user would not be able to alter his/her IP info). 

IOW, as long as Moz allows the user to feed any info against an NTLM challenge,
my options are limited: Either not let anyone use Moz, or not let anyone use any
of the services that require NTLM.

My solution proposal: Do not display a id/password popup for those NTLM
challenges that originate from *within* the local network. Just send the
information in the background. If the request is coming from an outside network,
then display the popup for the user to fill in.

Comment 9

[Darin Fisher]

adem: i agree with your suggestion.  the issue is that it is not easy to
implement.  we have to be very careful how we determine "inside the intranet"