Firefox 30 blocks access on non-Windows platforms to Sharepoint and IIS sites
As part of Firefox 30’s release, Mozilla made a change to disable support for NT LAN Manager version 1 (NTLMv1) network authentication. This change affects sites using Microsoft’s SharePoint or IIS services. The Windows version of Firefox 30 should switch to using NTLMv2 authentication automatically, but NTLMv2 is not supported by Firefox on non-Windows platforms.
Update – 7-22-2014: Mozilla has released Firefox 31, which now allows access on non-Windows platforms to Sharepoint and IIS sites using HTTPS. For more details, see this post.
The result for non-Windows platforms is that access may be blocked when Firefox 30 users try to access those kinds of sites.
Mozilla has provided a workaround to non-Windows users of Firefox, in the form of a setting that can be toggled to allow NTLMv1 authentication. This workaround should allow Mac and Linux users to continue using NTLMv1 authentication, which will allow access again to SharePoint-based or IIS-backed web applications. For more details, see below the jump.
Enabling NTLMv1 in Firefox 30
1. Open Firefox
2. In the address bar, enter the following:
about:config
3. If prompted, click on the I’ll be careful, I promise! button.
4. Search for the following:
network.negotiate-auth.allow-insecure-ntlm-v1
5. Once the network.negotiate-auth.allow-insecure-ntlm-v1 setting is located, double-click on the setting. That should change the entry in the Value column from false to true.
6. Once the network.negotiate-auth.allow-insecure-ntlm-v1 setting has been set to true, close the Firefox browser window.
7. Open a new browser window and attempt to access the SharePoint-based or IIS-backed site. You should now be able to log in.
Another option is to use Firefox ESR (currently 24.6.0), which does not yet have this problem. Hopefully, they will have a fix for Firefox 31, which will be the basis of the next ESR.
Do we know if there is an option to change this setting via the command line? Just realized we now have about 100 users whom are affected by this…
I got a ticket from someone today with this exact problem. He recently changed his password so we were thinking it could be that. Then I saw this post and everything makes sense. Turns out he updated his Firefox and that’s when the problem started. Thanks so much for these posts. Very helpful!!!!
Surely the real fix is to work with the people hosting the sites and get them to switch to kerberos.
So we are using kerberos and still seeing this issue with FireFox 30. We aren’t quite sure why yet. Apparently it might have something to do with kinit being run at logon. There is an old post here: https://support.mozilla.org/en-US/questions/959282. We are testing this on OSX 10.9.3 and Firefox 30.
Thank you! Our SharePoint presence would be effected by this. Appreciate the detail.
Great finding!
thanks
Thanks this just bit me this morning, now I can access the sharepoint sites again.
Awesome post. I have been trying to troubleshoot this for a couple of days, and this seems to have done the trick!
Thanks, very helpful! Been beating my head on the desk trying to figure this out.
The unfortunate part is that the user gets no warning or information whatever — just a blank page. I had to use Live HTTPHeaders to even determine that NTLM might be the problem. While Mozilla has a point about NTLMv1 being insecure, and I understand that supporting Microsoft protocols on non-Windows OS’s is hard, the silent treatment is NOT the way to go, IMO.
Thanks, this was driving me crazy. Quick fix.
Very Helpful this is..It helped me in troubleshooting a issue raised by customer….Thanks
This begs the question – is there a plist or terminal command we can deploy en masse to fix this issue remotely?
Test this and use at your own risk
echo “//\nlockPref(\”network.negotiate-auth.allow-insecure-ntlm-v1\”, true)” >> /Applications/Firefox.app/Contents/MacOS/mozilla.cfg
echo “pref(\”general.config.obscure_value\”, 0);\npref(\”general.config.filename\”, \”mozilla.cfg\”);” >> /Applications/Firefox.app/Contents/MacOS/defaults/pref/local-settings.js
That command works for me, just remember to fix quotation (“) as usual when copypasting from wiki.
However, lockPref does not allow user changing the setting temporarily.
pref(“network.negotiate-auth.allow-insecure-ntlm-v1”, true) allows user to change the setting while Firefox is running.
After Firefox is relaunched the pref is set to that value defined in mozilla.cfg.
defaultPref(); // set new default value, user’s changes are saved
pref(); // set pref, but allow changes in current session
lockPref(); // lock pref, disallow changes
http://kb.mozillazine.org/Locking_preferences
For this setting I prefer to leave user a choice to disable it.
That command does not work, no file called mozilla,cfg or local-settings.js in locations mentioned.
USC’s Office 360 Exchange has this issue in an updated Mac OS X 10.8.5 and Debian (Iceweasel). đŸ˜¦
Just creating a user.js file in ~/Library/Application\ Support/Firefox/Profiles/xxxxxxx.default with the one line:
user_pref(“network.negotiate-auth.allow-insecure-ntlm-v1”, true);
seems to work as well. Here is a script to create it in all local users:
#!/bin/sh
localUsers=$( dscl . list /Users UniqueID | awk ‘$2 >= 501 {print $1}’ | grep -v admin )
echo “user_pref(\”network.negotiate-auth.allow-insecure-ntlm-v1\”, true);” >> /private/tmp/user.js
for userName in “$localUsers”; do
cp /private/tmp/user.js /Users/$userName/Library/Application\ Support/Firefox/Profiles/*.default/
done
exit 0
I’ve been going crazy all week trying to reconfigure and troubleshoot so many errors regarding getting access to Sharepoint / Office 365 at work. Thanks a lot to Firefox for notifying of such a major change. (NOT!) You saved me a lot more grief by reporting this! Thanks!
Thank you, thank you !
Any tips for how to incorporate this into a package deployable with Munki, preferably via an autopkg recipe?
Please check this:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
firefox_enable_ntlm_v1_auth_common
hosted with ❤ by GitHub
I wrote it as a nopkg item for Munki.
All functionality is directly within the installcheck_script and it always exits “gracefully”.
It tries to fix all Firefox.app instances found in /Applications.
One other way would be to use a LaunchAgent for creating the setting for user logging in but that solution I do not have (yet, this is a little more complicated).
Awesome, the fix works, can anyone explain what is happening by making this changes. I’m I vulnerable when using Firefox NTLMv1 enabled on the world wide web? then not disabling it?