Home > Linux, Mac administration, Mac OS X > Firefox 30 blocks access on non-Windows platforms to Sharepoint and IIS sites

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.

Screen Shot 2014-06-13 at 1.12.57 PM

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:


3. If prompted, click on the I’ll be careful, I promise! button.

Screen Shot 2014-06-13 at 1.13.12 PM

4. Search for the following:


Screen Shot 2014-06-13 at 1.13.48 PM

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.

Screen Shot 2014-06-13 at 1.13.48 PM

Screen Shot 2014-06-13 at 1.13.56 PM

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.

Screen Shot 2014-06-13 at 1.23.34 PM

  1. June 13, 2014 at 6:11 pm

    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.

  2. Jayson Kish
    June 13, 2014 at 7:08 pm

    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…

  3. June 13, 2014 at 8:01 pm

    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!!!!

  4. John
    June 14, 2014 at 4:34 pm

    Surely the real fix is to work with the people hosting the sites and get them to switch to kerberos.

    • Pamela James
      June 19, 2014 at 3:35 pm

      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.

  5. adamg
    June 16, 2014 at 1:15 pm

    Thank you! Our SharePoint presence would be effected by this. Appreciate the detail.

  6. TamsA
    June 18, 2014 at 5:10 am

    Great finding!

  7. June 18, 2014 at 3:27 pm

    Thanks this just bit me this morning, now I can access the sharepoint sites again.

  8. Larry
    June 19, 2014 at 12:18 am

    Awesome post. I have been trying to troubleshoot this for a couple of days, and this seems to have done the trick!

  9. June 19, 2014 at 4:42 pm

    Thanks, very helpful! Been beating my head on the desk trying to figure this out.

  10. June 20, 2014 at 12:23 am

    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.

  11. Affinity9
    June 20, 2014 at 1:38 pm

    Thanks, this was driving me crazy. Quick fix.

  12. Parul
    June 23, 2014 at 4:03 am

    Very Helpful this is..It helped me in troubleshooting a issue raised by customer….Thanks

  13. Dave
    June 24, 2014 at 4:42 pm

    This begs the question – is there a plist or terminal command we can deploy en masse to fix this issue remotely?

    • itface
      June 25, 2014 at 7:05 pm

      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

      • MiqViq
        June 28, 2014 at 8:48 pm

        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


        For this setting I prefer to leave user a choice to disable it.

  14. June 27, 2014 at 8:16 pm

    That command does not work, no file called mozilla,cfg or local-settings.js in locations mentioned.

  15. Ant
    June 30, 2014 at 5:58 pm

    USC’s Office 360 Exchange has this issue in an updated Mac OS X 10.8.5 and Debian (Iceweasel). 😦

  16. Eric
    July 2, 2014 at 8:34 pm

    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:


    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/

    exit 0

  17. cliftonclassroom
    July 16, 2014 at 9:04 pm

    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!

  18. July 23, 2014 at 7:00 am

    Thank you, thank you !

  19. Joe Carroll
    July 24, 2014 at 8:26 am

    Any tips for how to incorporate this into a package deployable with Munki, preferably via an autopkg recipe?

    • July 28, 2014 at 9:22 am

      Please check this:

      <?xml version="1.0" encoding="UTF-8"?>
      <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
      <plist version="1.0">
      <string>Enables insecure NTLM v1 authentication protocol in Firefox.</string>
      <string>Enable NTLMv1 for Firefox</string>
      # This setting applies to all users
      # Allows user to change the setting, setting is reverted to the value defined in mozilla.config after restarting Firefox
      # functions
      function setAuthPrefs () {
      # if setting is already enabled then exit
      if grep -q 'pref("network.negotiate-auth.allow-insecure-ntlm-v1", true);' "${FoxPrefsFile}" 2&gt;/dev/null; then
      if [ ! -d "${FFAppPath}" ] || [ "${FFAppPath}" == '/Applications/Firefox*.app' ] ; then
      echo "Firefox.app not found at '${FFAppPath}'"
      # if setting is disabled then enable it
      if grep -q 'pref("network.negotiate-auth.allow-insecure-ntlm-v1", false);' "${FoxPrefsFile}" 2&gt;/dev/null; then
      # fix the file using perl's in-place edit
      perl -pi -w -e 's/network.negotiate-auth.allow-insecure-ntlm-v1", false/network.negotiate-auth.allow-insecure-ntlm-v1", true/g' "${FoxPrefsFile}"
      elif ! grep -q 'pref("network.negotiate-auth.allow-insecure-ntlm-v1",' "${FoxPrefsFile}" 2&gt;/dev/null; then
      printf "//\npref(\"network.negotiate-auth.allow-insecure-ntlm-v1\", true)\n" &gt;&gt; "${FoxPrefsFile}"
      chmod a+r "${FoxPrefsFile}" 2&gt;/dev/null
      function setCustomPrefs () {
      if [ ! -d "${FFAppPath}" ] || [ "${FFAppPath}" == '/Applications/Firefox*.app' ] ; then
      if [ ! -d "${FoxEnablePrefsDir}" ]; then
      mkdir -p -m 0755 "${FoxEnablePrefsDir}" 2&gt;/dev/null
      # tell Firefox to look for a specific file for custom settings
      if ! grep -q 'pref("general.config.obscure_value", 0);' "${FoxEnablePrefsFile}" 2&gt;/dev/null || ! grep -q 'pref("general.config.filename", "mozilla.cfg");' "${FoxEnablePrefsFile}" 2&gt;/dev/null; then
      printf "pref(\"general.config.obscure_value\", 0);\npref(\"general.config.filename\", \"mozilla.cfg\");\n" &gt;&gt; "${FoxEnablePrefsFile}"
      chmod a+r "${FoxEnablePrefsFile}" 2&gt;/dev/null
      # actions
      for item in /Applications/Firefox*.app ; do
      exit 1</string>
      exit 0</string>

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

  20. I
    September 25, 2014 at 9:17 pm

    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?

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: