Install the extension automatically
Force-install for Chrome and Edge on Windows and macOS, automatic Microsoft sign-in, and the optional hardening.
Install the extension automatically
Windows
The forced installation works through the ExtensionInstallForcelist browser policy: the extension appears in the browser by itself and cannot be removed.
Create a configuration profile
Intune: Devices → Configuration → Create → New policy → Windows 10 and later → Settings catalog.
Add the forcelist line per browser
Search the catalog for ExtensionInstallForcelist, under Google Chrome and under Microsoft Edge. Pick the device variant of the setting each time and paste this value per browser:
cnlogmngeghlgbncagnoodfjkbaknnbo;https://clients2.google.com/service/update2/crxplnhmaecddjmliagaedlgagopdcahlgb;https://edge.microsoft.com/extensionwebstorebase/v1/crxAssign to your target group
Assign to the same group as step 1.
macOS
For macOS, the console generates a configuration profile (.mobileconfig) that handles the forced installation of the extension for the browsers in your deployment profile. Prerequisites: the Mac is enrolled in Intune and the browser is already installed; the profile does not install a browser.
Download the profile
Upload it as a custom profile
Intune: Devices → macOS → Configuration → New policy → Templates → Custom.
Pick the device channel and assign
For the deployment channel, choose the device channel, upload the profile and assign it to your target group. The channel cannot be changed after saving; if you pick the wrong one, create a new profile.
Automatic Microsoft sign-in
With steps 1 and 2 in place, the extension recognises the work account: the employee types no address and picks no account. Whether a Microsoft screen still appears depends on the browser.
This needs a recent extension. Since5.5.14 the extension recognises the work account from the sign-in script; Since5.5.17 it also tries to complete the sign-in in Edge without an account picker. Check the version on chrome://extensions or edge://extensions. When a version arrives is up to the store; an organisation cannot pin the store version.
Chrome only passes the Windows sign-in on to Microsoft with the CloudAPAuthEnabled policy; see Silent sign-in in Chrome under Optional hardening. With that policy the sign-in completes without a password or confirmation. Tested31 August 2026
Without that policy the sign-in still works; Microsoft then asks for a one-time confirmation or password. Not yet validated
Edge signs Microsoft web apps in silently by default on an Entra-joined device; no policy is needed for that.
For the BeeSensible sign-in in Edge, that silent completion has not been established: expect a Microsoft window and note while testing exactly what employees see. Do not prescribe extra Edge policies to work around this; BeeSensible's sign-in flow is the determining factor here, not the Edge configuration. Not yet validated
After a successful sign-in, BeeSensible keeps using the existing session for as long as it is valid.
Microsoft still asks to pick an account
Four causes, checked in this order:
- The hint is missing or unusable. Run the registry commands from step 1. If there is no
loginHint, if it literally says{{UserPrincipalName}}, or if the value has no @ sign, the extension ignores it; the console counts such a client under Managed configuration not filled in. - The extension is older than the version above. Check
chrome://extensionsoredge://extensionsand wait for the store. - The domain of the work address is not verified in BeeSensible.
- No identity provider is connected; there is then no business route and BeeSensible shows the regular sign-in screen. See Identity.
Edge still shows the old account picker
First check the extension version on edge://extensions. The Edge store delivers updates later than the Chrome Web Store; as long as the version is below the requirement above, the extension behaves like a plain installation without work-account recognition. Waiting is the only option; policy cannot force a version.
Optional hardening
Both measures below are optional: the extension and the sign-in work without them. Optional
Silent sign-in in Chrome (CloudAPAuthEnabled)
Chrome only passes the Windows sign-in on to Microsoft with this policy (Chrome 111 or newer):
CloudAPAuthEnabledSearch the settings catalog for the name above; that finds it faster than the full display name "Allow automatic sign-in to Microsoft cloud identity providers". Pick the device variant, set it to Enabled and assign to your target group. The policy applies to the whole device by definition, not per browser profile, and does not work in Incognito windows.
With this policy, Chrome shares device and account information with Microsoft during Microsoft sign-ins, the same exchange Edge performs by default.
The sign-in is not automatic in Chrome
Check in chrome://policy that CloudAPAuthEnabled is true, force a sync as in step 1 otherwise, and then restart Chrome completely (close all windows).
Private windows (Incognito and InPrivate)
Forced installation does not automatically apply in private windows: whether an extension may run there is a permission the user sets themselves, and browser policy cannot switch it on by design. Without an extra measure, a private window is a window without BeeSensible.
Chrome on Windows and macOS has no policy that forces an extension in Incognito; the comparable policy exists only on ChromeOS. The choice there is:
- disable Incognito browser-wide with
IncognitoModeAvailabilityset to 1 (takes effect after a browser restart), or - accept the gap and measure it.
From Edge 139, InPrivate can be made dependent on the extension: with the MandatoryExtensionsForInPrivateNavigation policy, InPrivate only works after the user has allowed BeeSensible there. Until then, InPrivate refuses to navigate.
Set the policy via the settings catalog, with the Edge extension id as the value:
plnhmaecddjmliagaedlgagopdcahlgbSince5.5.17 the extension reports at sign-in whether it may run in private windows; the deployment console counts how many clients are covered.
If you withdraw the forced installation later, remove these policies as well; see Rolling back.
