Open Bug 1177752 Opened 5 years ago Updated 1 year ago

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

Categories

(Core :: Networking, defect, P3)

38 Branch
defect

Tracking

()

People

(Reporter: traterjr, Unassigned)

References

Details

(Whiteboard: [necko-backlog][ntlm])

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.
This sounds like it could be a regression, adding a qa-wanted tag to further investigate this bug.
Keywords: qawanted
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.
Flags: needinfo?(traterjr)
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.
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking
Ever confirmed: true
Product: Firefox → Core
Blocks: 423758
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
(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.
Flags: needinfo?(traterjr)
What is the target server and the directory service backing it (presumably IIS on Windows and Active Directory)?
Flags: needinfo?(traterjr)
It is a SharePoint 2007 site running on Windows, with Active Directory providing the authentication.
Flags: needinfo?(traterjr)
Whiteboard: [necko-backlog][ntlm]
This is fixed on the desktop, but still an issue in Firefox for Android.
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.