Overview

This guide explains how to allow users to optionally (not force-installed) install the Firefox Multi-Account Containers extension in an environment where a CIS-hardened Firefox baseline blocks all extension installs by default via Intune’s Settings Catalog.

• Extension name: Firefox Multi-Account Containers
• Extension ID: @testpilot-containers
• AMO listing: https://addons.mozilla.org/en-US/firefox/addon/multi-account-containers/

Background / Problem

In a CIS-hardened Firefox configuration, extension installation is disabled by default via the InstallAddonsPermission policy (Default: false). The goal was to make exactly one extension installable by end users on demand, without forcing it on everyone and without opening up installs for any other extension.

First approach (did not work)

The initial attempt was to:

1. Keep InstallAddonsPermission.Default = false
2. Add https://addons.mozilla.org to the Allowed Sites exception list
3. Whitelist the extension ID in ExtensionSettings

This resulted in an “unexpected error occurred during installation” message on the AMO website, even though the site itself was allowed.

Root cause

This is a known limitation of Firefox’s policy engine, confirmed in an official Mozilla Bugzilla discussion (bug 1498745): when InstallAddonsPermission.Default is set to false, installation is still blocked even for origins listed in Allow, because that setting only governs whether the install prompt can be shown — not whether the underlying installation is permitted. Mozilla’s own guidance is to avoid using InstallAddonsPermission for this purpose entirely, and to manage site restrictions through ExtensionSettings instead.

Working solution

Use ExtensionSettings as the single source of truth for both which extensions are allowed and which sites may serve as an install source. Leave InstallAddonsPermission permissive.

Settings Catalog configuration (Device-scoped policies)

1. “Allow add-on installs from websites” (Device) Set to Enabled (this maps to InstallAddonsPermission.Default = true).

2. “Allowed Sites” (Device) Not needed — leave as Not configured.

3. “Extension Management” (Device) Set to Enabled, with the following JSON:

{
  "*": {
    "installation_mode": "blocked",
    "install_sources": ["https://addons.mozilla.org/*"],
    "blocked_install_message": "Contact IT for approved extensions"
  },
  "@testpilot-containers": { "installation_mode": "allowed" }
}

How it works

• InstallAddonsPermission.Default: true allows any website to show the browser’s install prompt in principle.
• The ExtensionSettings wildcard ("*") blocks all extensions by default and restricts any install attempt to originate only from addons.mozilla.org (install_sources).
• The explicit entry for @testpilot-containers overrides the wildcard and allows only this one extension to be installed.
• Result: users can voluntarily install Multi-Account Containers from AMO; every other extension — from AMO or anywhere else — is blocked with a custom message, and nothing is force-installed.

Testing

1. Assign the updated profile to a pilot device.
2. Force an Intune sync on the device (Settings → Accounts → Access work or school → Sync), then fully restart Firefox (close all firefox.exe processes via Task Manager, not just the window).
3. Go to about:policies → Active policies tab and confirm:
   • ExtensionSettings shows the JSON above without parse errors.
   • InstallAddonsPermission.Default is true.
4. Try installing Multi-Account Containers from its AMO page → should succeed.
5. Try installing a different, arbitrary extension from AMO (e.g. Dark Reader) → should be blocked with the custom message defined in blocked_install_message.

Troubleshooting

• Still getting “unexpected error” after applying the fix: confirm InstallAddonsPermission.Default is actually true in about:policies — if it still shows false, the policy sync hasn’t landed yet or the wrong setting was edited.
• A colleague/device still doesn’t have ExtensionSettings at all in about:policies: this usually means the profile hasn’t synced to that device yet, or the device isn’t in scope of the profile assignment. Force a sync, fully restart Firefox, and confirm the device/user is included in the profile’s Assignments.
• Devtools/Browser Console unavailable for debugging: if DisableDeveloperTools is enforced, use MOZ_LOG environment variables instead to capture logs without needing devtools: set MOZ_LOG=addons:5,extensions:5set MOZ_LOG_FILE=C:\temp\firefox_log.txt"<path to firefox.exe>" Remember to unset these afterwards (setx MOZ_LOG "" / setx MOZ_LOG_FILE "") so logging doesn’t stay enabled indefinitely.

Rollout

Once verified on a pilot device, assign the updated Settings Catalog profile to the broader target group/device collection.