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:

• Customize Firefox using Group Policy (Windows)
• https://github.com/mozilla/policy-templates#authentication

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.)

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?

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?).

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.

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?

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.

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.

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

thanks for your great research!