468334 - NTLM authentication does not work with IIS7 error 0x80090308

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Paul Marston]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4 (.NET CLR 3.5.30729)

Firefox does not authenticate to IIS7 using integrated authentication when network.automatic-ntlm-auth.trusted-uris is set.

The following error is logged in event viewer on the server:
An account failed to log on.

Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Logon Type:			3

Account For Which Logon Failed:
	Security ID:		NULL SID
	Account Name:		Paul
	Account Domain:		<domain name>

Failure Information:
	Failure Reason:		An Error occured during Logon.
	Status:			0x80090308
	Sub Status:		0x0

Process Information:
	Caller Process ID:	0x0
	Caller Process Name:	-

Network Information:
	Workstation Name:	PAUL-PC
	Source Network Address:	192.168.0.10
	Source Port:		5162

Detailed Authentication Information:
	Logon Process:		NtLmSsp 
	Authentication Package:	NTLM
	Transited Services:	-
	Package Name (NTLM only):	-
	Key Length:		0



System 

  - Provider 

   [ Name]  Microsoft-Windows-Security-Auditing 
   [ Guid]  {54849625-5478-4994-a5ba-3e3b0328c30d} 
 
   EventID 4625 
 
   Version 0 
 
   Level 0 
 
   Task 12544 
 
   Opcode 0 
 
   Keywords 0x8010000000000000 
 
  - TimeCreated 

   [ SystemTime]  2008-12-07T14:18:58.780Z 
 
   EventRecordID 11364 
 
   Correlation 
 
  - Execution 

   [ ProcessID]  616 
   [ ThreadID]  740 
 
   Channel Security 
 
   Computer <server name>
 
   Security 
 

- EventData 

  SubjectUserSid S-1-0-0 
  SubjectUserName - 
  SubjectDomainName - 
  SubjectLogonId 0x0 
  TargetUserSid S-1-0-0 
  TargetUserName Paul 
  TargetDomainName <domain name>
  Status 0x80090308 
  FailureReason %%2304 
  SubStatus 0x0 
  LogonType 3 
  LogonProcessName NtLmSsp  
  AuthenticationPackageName NTLM 
  WorkstationName PAUL-PC 
  TransmittedServices - 
  LmPackageName - 
  KeyLength 0 
  ProcessId 0x0 
  ProcessName - 
  IpAddress 192.168.0.10 
  IpPort 5162 


The following users also experienced this problem (your support area errors when trying to view the original thread so it is a link to the google cache intead)
http://74.125.77.132/search?q=cache:xKSVxgRfGbkJ:support.mozilla.com/tiki-view_forum_thread.php%3Flocale%3Den-US%26comments_parentId%3D136027%26forumId%3D1+firefox+ntlm+iis7&hl=en&ct=clnk&cd=1&gl=uk


Reproducible: Always

Steps to Reproduce:
1. Set up IIS7 to use window's authentication or basic authentication
2. Add server name/ip address to network.automatic-ntlm-auth.trusted-uris
3. Attempt to view website in Firefox.
Actual Results:  
You receive the "enter password" box.
Internet Explorer has no problem connecting to the website and authenticating without prompting for credentials

Expected Results:  
No password box, automatic authentication.

Server runs self-signed SSL certificate.

Comment 1

[cprivite]

We've noticed this as well on Vista boxes talking to IIS7 sites.

Comment 2

[cprivite]

6 months later, still not working on any of our intranet sites properly, all of which now use IIS7.  This is surely going to have negative impacts on Firefox adoption in corporate environments that are moving their intranet servers to Windows 2008. 

My whining aside, I can add that the passthrough authentication DOES work if you disable NTLMv2 on the Vista SP1 client (you can test that by setting "LAN Manager authentication level" to "Send NTLM response only" in secpol.msc). This isn't a solution, of course, as NTLMv1 is terribly insecure, but it does help narrow down the issues to having something to do with NTLMv2, so I hope that helps some.

Comment 3

[cprivite]

Firefox 3.6 Beta 5 seems to resolve this bug, I'm only able to test on Windows 7 at the moment, but the beta seems to fix whatever the issue was.

Comment 4

[Jim Mathies [:jimm]]

(In reply to comment #3)
> Firefox 3.6 Beta 5 seems to resolve this bug, I'm only able to test on Windows
> 7 at the moment, but the beta seems to fix whatever the issue was.

I was able to reproduce this while working on the patches for bug 520607, so it's good to hear someone else has been able to confirm.

If anyone still has this issue with 3.6, please re-open and if possible, post ntlm logs:

https://developer.mozilla.org/en/HTTP_Logging

NSPR_LOG_MODULES=nsHttp:3,negotiateauth:4,NTLM:4