在企业中，使用FF可能是一件痛苦的事情，特别是使用windows系统的企业。因为许多内部系统使用NTLM登陆验证，如sharepoint。而FF在这一方面的体验很差。
在IE中，windows integration authentication默认是打开的，当一个site需要NTLM验证信息时，IE把当前的域用户信息发送过去，site验证通过后向用户显示授权的信息。这一切都是无缝的，用户不知道他浏览的信息是需要授权的。
而在FF下，用户会遇到一个又一个的登陆对话框，一个页面显示的对话框个数取决于该页面引用几个不同的需要authenticaiton origin。运气好的话，只需要输入一次，不好的话，可能N次。
实际上FF支持NTLM，但它不去推断哪些site可以使用NTLM，它内部有个白名单（默认为空），如果一个site在白名单中，它会根据site的验证请求（需要查阅NTLM协议来进一步求证）来决定是否使用当前的域帐号信息完成验证。最后的效果就跟IE一样。
这个白名单在about:config下的network.automatic-ntlm-auth.trusted-uris, 但这个名单需要用户收集，而且远不如IE聪明。
今天找到Integrated Authentication for firefox这个插件，只要你输入企业的域名称，同时勾上Enable pass-through on all non-FQDN sites even if they aren’t listed here. 那么FF在NTLM的体验就跟IE上差不多。
FF的白名单使得FF能识别哪些site能使用NTLM，但FF并不对待non-FQDN url指向的site。这个插件弥补了这一点。
比如有个sharepoint的site是: intern.microsoft.com, 其中microsoft.com是域名称。
在IE下，输入intern和intern.microsoft.com都能打开页面并使用NTLM验证。但FF只识别后者，因为白名单只有 microsoft.com，除非添加到http://intern白名单中。使用了这个插件，intern这个non-FQDN会使用NTLM验证。
当然这个插件只是完善FF的NTLM使用体验，并不具备IE判断一个site是否使用NTLM的完整逻辑.
在IE中，windows integration authentication默认是打开的，当一个site需要NTLM验证信息时，IE把当前的域用户信息发送过去，site验证通过后向用户显示授权的信息。这一切都是无缝的，用户不知道他浏览的信息是需要授权的。
而在FF下，用户会遇到一个又一个的登陆对话框，一个页面显示的对话框个数取决于该页面引用几个不同的需要authenticaiton origin。运气好的话，只需要输入一次，不好的话，可能N次。
实际上FF支持NTLM，但它不去推断哪些site可以使用NTLM，它内部有个白名单（默认为空），如果一个site在白名单中，它会根据site的验证请求（需要查阅NTLM协议来进一步求证）来决定是否使用当前的域帐号信息完成验证。最后的效果就跟IE一样。
这个白名单在about:config下的network.automatic-ntlm-auth.trusted-uris, 但这个名单需要用户收集，而且远不如IE聪明。
今天找到Integrated Authentication for firefox这个插件，只要你输入企业的域名称，同时勾上Enable pass-through on all non-FQDN sites even if they aren’t listed here. 那么FF在NTLM的体验就跟IE上差不多。
FF的白名单使得FF能识别哪些site能使用NTLM，但FF并不对待non-FQDN url指向的site。这个插件弥补了这一点。
比如有个sharepoint的site是: intern.microsoft.com, 其中microsoft.com是域名称。
在IE下，输入intern和intern.microsoft.com都能打开页面并使用NTLM验证。但FF只识别后者，因为白名单只有 microsoft.com，除非添加到http://intern白名单中。使用了这个插件，intern这个non-FQDN会使用NTLM验证。
当然这个插件只是完善FF的NTLM使用体验，并不具备IE判断一个site是否使用NTLM的完整逻辑.