This site will have limited functionality while we undergo maintenance to improve your experience. If an article doesn't solve your issue and you want to ask a question, we have our support community waiting to help you at @FirefoxSupport on Twitter and/r/firefox on Reddit.

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Firefox NTLM authentication not passing credentials through to IIS server running .net 4.5 based application, but works fine on .net 2.0 based application

  • 9 replies
  • 1 has this problem
  • 1 view
  • Last reply by Mike Kaply

more options

We have an intranet portal that we have been running for years that is based on .net 2.0 IIS application pool. We push firefox preferences out and a few things I think that make this work are these network.automatic-ntlm-auth.allow-non-fqdn = true network.automatic-ntlm-auth.trusted-uris = domain.com (our domain name) network.negotiate-auth.trusted-uris = domain.com (our domain name) network.automatic-ntl:m-auth.trusted-uris = .domain.com (our domain name).

Normally our original site proceeded wtihout any issue.

The new site that the vendor wants to upgrade us to has a ton of upgraded code and a slightly updated look and feel and new controls for publishing and configuring content. Like the previous portal, this also runs on IIS but uses .net 4.5 application pool. What happens is when we hit this site in Firefox we are bombarded with a username and password prompt. If you cancel a bunch of times the site will load but eventually it pops up again. If you enter your domain username and password then it goes away and you can use the site normally. IE, Chrome and Edge just go directly to the site, automatically using your current windows login identity so if you post content on the intranet portal it shows as you.

We did a remote session with the vendor of the portal and the guy basically said yeah it has something to do with this .net framework and firefox. We know it worked on the older verison but we've never been able to get it to work in firefox. You'll have to use another browser or enter your domain credentials when you visit the site in firefox.

Does anyone know if there is some sort of under the hood tweak in firefox to get the NTLM passthrough to an IIS based .net 4.5 application like it does with .net 2.0? We would love to keep Firefox as our default browser but when we go live with this portal we may have to switch to Chrome.

We have an intranet portal that we have been running for years that is based on .net 2.0 IIS application pool. We push firefox preferences out and a few things I think that make this work are these network.automatic-ntlm-auth.allow-non-fqdn = true network.automatic-ntlm-auth.trusted-uris = domain.com (our domain name) network.negotiate-auth.trusted-uris = domain.com (our domain name) network.automatic-ntl:m-auth.trusted-uris = .domain.com (our domain name). Normally our original site proceeded wtihout any issue. The new site that the vendor wants to upgrade us to has a ton of upgraded code and a slightly updated look and feel and new controls for publishing and configuring content. Like the previous portal, this also runs on IIS but uses .net 4.5 application pool. What happens is when we hit this site in Firefox we are bombarded with a username and password prompt. If you cancel a bunch of times the site will load but eventually it pops up again. If you enter your domain username and password then it goes away and you can use the site normally. IE, Chrome and Edge just go directly to the site, automatically using your current windows login identity so if you post content on the intranet portal it shows as you. We did a remote session with the vendor of the portal and the guy basically said yeah it has something to do with this .net framework and firefox. We know it worked on the older verison but we've never been able to get it to work in firefox. You'll have to use another browser or enter your domain credentials when you visit the site in firefox. Does anyone know if there is some sort of under the hood tweak in firefox to get the NTLM passthrough to an IIS based .net 4.5 application like it does with .net 2.0? We would love to keep Firefox as our default browser but when we go live with this portal we may have to switch to Chrome.

All Replies (9)

more options

I wonder whether your new site uses Kerberos ("Negotiate") authentication instead of classic NTLM authentication? You didn't mention the following preference, which may be relevant to a change like that:

network.negotiate-auth.delegation-uris

Could you test whether adding your relevant host name(s) there makes any difference?

For possible future reference, you can roll out trusted URIs through group policy:

more options

Thats a great suggestion, thank you for that. I gave it a shot and it didn't work.

I tried just putting our domain name in, like we have for my examples above. I tried putting in the entire site name website.domain.com format, and I also tried with the full https:// in front as well.

I can mention to the web developer if they support kerberos and if they do can they turn it on to try it.

What's weird is in Firefox if I dismiss the username and password modal pop up dialog box twice, the site loads anyway and it knows who I am, just like if I visited the site in IE, Edge or Chrome.

In group policy we have this new intranet site software set to trusted sites. That seems to make things work for IE and the others. We have the GPO's in our domain controllers for Firefox and had network.negotiate-auth.delegation-uris worked, I would update that as well to match our ntlm fields.

Basically we are ok with passing credentials to sites in our domain name. Its internal only. We have another (.org) that is internet facing. We just don't want credentials leaking out to the internet, but were ok with a blanket statement to our internal managed domain. We have many other sites internally, especially IT (things like network graphing and monitoring software, vmware vcenter servers, exchange administration and much more.)

more options

The vendor has a diagnostic page that shows the authorization account and type.

Here is some interesting information: Old portal Chrome no prompt: Authorized Account Type: Negotiate

Firefox no prompt: Authorized Account Type: NTLM

New portal Chrome no prompt: Authorized Account Type: Negotiate

Firefox canceled out of username and password prompt twice Authorized Account Type: Negotiate

Firefox, supplied valid active directory credentials Authorized Account Type: Basic


So in the new portal NTLM isn't used at all. It does Negotiate if you cancel out of the prompts. If you fill in the username and password it does Basic.

Is this something we can tweak with firefox preferences, or do you think this is more of an IIS setting?

more options

You could check the dev tools in Firefox or Chrome (F12) to see what files are used in the page from what host names. (After opening the dev tools, activate the Network panel and reload the page.)

At least for classic NTLM (network.automatic-ntlm-auth.trusted-uris), I only need to enter the host names and no protocols.

You also can compare the response headers on the requests to see the specific authorization methods listed. To get a clearer picture of the flow, and have better control over settings experiments, is it possible to load a single file that doesn't immediately try to load other assets which also trigger authorization prompts? That might have to be a .js, .css, .png, or .jpg file because most HTML files will link in other files.

I think the ranking of authorization type(s) is set in IIS, and each "site" can have its own setting. That said, I don't know how you set fallback from one type to another (two failures, try next?).

more options

I have been using Fiddler web debugger and one thing I notice unique between the old web portal and the new web portal is that the new one shows 3 authentication headers on its HTTP 401 page: No Proxy-Authenticate Header is present.

WWW-Authenticate Header is present: Basic Realm="The Portal"

WWW-Authenticate Header is present: Negotiate

WWW-Authenticate Header is present: NTLM

If I cancel out the authentication prompt, the next line in fiddler is status code 200 and the page proceeds to load and the authentication shows a valid Kerberos ticket exchange.

I also verified running in command prompt klist tickets shows one of the many entries is the proper kerberos SPN I set in active directory for the service account running this website in IIS.

I do not see any Kerberos auth issue, the ticket exchange is fine. What I do see is the WWW-Authenticate headers seem to be offering all three types of authentication. It seems Chrome (and subsequenty chromium based Edge) and IE (with the site in our "trusted sites" via GPO) take an overview of all the WWW-Authenticate headers and instead of trying them in order from top down, try them in order from most secure to least secure.

more options

Interesting, that sounds like a bug. Would you be willing to open a bugzilla bug for that at bugzilla.mozilla.org and post the bug number here?

more options

I wonder why "Basic" authentication is listed in the first WWW-Authenticate header -- is there some advantage to that? It looks like that is not the default order of IIS:

https://docs.microsoft.com/en-us/windows/win32/http/authentication-with-multiple-known-headers

If there isn't a specific reason for it, perhaps the vendor can update the IIS settings to change the order and see whether that works around it. I'm not sure where that is configured.

more options

Mike Kaply said

Interesting, that sounds like a bug. Would you be willing to open a bugzilla bug for that at bugzilla.mozilla.org and post the bug number here?

Hey Mike,

If you think this could be a bug, I submitted it here for review (Bug 1699283) https://bugzilla.mozilla.org/show_bug.cgi?id=1699283

We have 78.8.0 ESR 64-bit deployed company wide.

more options

Thanks! The conversation should move over there, so we can probably mark opening the bug as the solution.

thanks for your great research!