1177752 - domain\username authentication fails if domain is entered in lower case

Status: NEW

(Core :: Networking, defect, P3)

Description

[traterjr]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150525141253

Steps to reproduce:

We have a SharePoint 2007 server that uses standard Windows domain authentication to password protect some pages. When a user visits the page in Firefox, they are required to enter domain\username and their password.


Actual results:

If the user enter lowercase domain\username the authentication fails (the server acts like it didn't even get the credentials) and the user is re-prompted to authenticate. The only way to make it work is for the user to enter capital DOMAIN\username


Expected results:

Authentication using lowercase domain\username should work. This worked fine in Firefox 36 and prior. Other current browsers (such as Safari, IE and Chrome) work fine if the user enters the domain\username as all lowercase.

Comment 1

[Kate Glazko]

This sounds like it could be a regression, adding a qa-wanted tag to further investigate this bug.

Comment 2

[Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]]

Hi reporter,

Can you please share more information about this issue? Maybe the link and some test credentials in order to test this on my end? In order to find the regression build I will need them. 

Also, can you please try to reproduce this on the latest release version(42.0) and latest Nightly(45.0a1) and provide the results? The issue could have been fixed along the way.
When you try this please use a new clean Firefox profile or maybe even in safe mode(https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems).

Thanks,
Paul.

Comment 3

[Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]]

After the reporter sent me a private email with the necessarily details in order to test, I've managed to reproduce this on the latest release(42.0) and latest Nightly(46.0a1) on OS X 10.10.4. On Windows, the log in works even if the domain is typed in with lower case characters.

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151029151421

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20151214122242

Considering this, I will mark this bug as New and assign the appropriate component.
If anyone considers that the component is not the right one, please change it to a more appropriate one.

Comment 4

[Andrew Bartlett]

Are there any special characters in the domain?

Does forcing NTLMv1 help (to narrow this down to the NTLMv2 hashing calculation)?

That is, set network.negotiate-auth.allow-insecure-ntlm-v1 to true

Comment 5

[traterjr]

(In reply to Andrew Bartlett from comment #4)
> Are there any special characters in the domain?
> 
No, no special characters.



> Does forcing NTLMv1 help (to narrow this down to the NTLMv2 hashing
> calculation)?
> 
> That is, set network.negotiate-auth.allow-insecure-ntlm-v1 to true

I have not observed any noticeable difference with this option set.

Comment 6

[Andrew Bartlett]

What is the target server and the directory service backing it (presumably IIS on Windows and Active Directory)?

Comment 7

[traterjr]

It is a SharePoint 2007 site running on Windows, with Active Directory providing the authentication.

Comment 8

[gserg.g]

This is fixed on the desktop, but still an issue in Firefox for Android.

Comment 9

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 10

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258