Skip to main content

βš™οΈπŸͺŸπŸ’»πŸ”“CP - Google Chrome - Enable Password Manager

The counter-policy to the block. It does not just remove the restriction, it says the opposite out loud, so the manager actually comes back on for the approved few.

βš™οΈType Configuration profile (inverse)πŸͺŸPlatform WindowsπŸ”“Action Re-enable, exception group
reference-build Β· google-chrome-enable-password-managerGolden Master reference
License tier
Business Premium (Intune)
Control plane
Intune Settings Catalog
Scope
Assigned exception group only
Reversibility
clean-revert

What this policy is about πŸ”“β€‹

This is the deliberate exception to βš™οΈπŸͺŸπŸ’»CP - Google Chrome - Disable Password Manager, and it exists because of one Intune fact that trips everyone up: exclusion is not the same as re-enabling.

Say you disable the Chrome password manager everywhere (good), and one team genuinely relies on it (fine), so you pull their devices out of the block. Still off. The policy value already applied, and simply removing the assignment does not flip it back. To actually switch the manager on again you assign a policy that sets the opposite value, explicitly. This is that policy.

It sets both settings back to Enabled, which also brings leak detection back for these devices, exactly what you want if Chrome really is their password manager.

πŸ€” This is the paired inverse

Whenever a device-scoped setting has an exception group, it needs a matching policy that resets the value. Assign this to the πŸ›‘οΈπŸͺŸπŸ’»πŸ‘ˆπŸ”“βš™οΈGroup - Chrome Password Manager Allowed group and the manager comes back cleanly, no reimaging, no registry surgery.

πŸ› οΈ Configuration​

Where: Intune admin center β†’ Devices β†’ Configuration β†’ Create β†’ Windows β†’ Settings catalog β†’ Google \ Google Chrome \ Password manager.

SettingValue
Enable saving passwords to the password managerEnabled
Enable leak detection for entered credentialsEnabled
Assignment, includeπŸ›‘οΈπŸͺŸπŸ’»πŸ‘ˆπŸ”“βš™οΈGroup - Chrome Password Manager Allowed
Assignment, excludeNone (only the approved exception group receives this)

Setting both back to Enabled is what actively overrides the disabled state, which is the only thing that truly lifts it.

Caveats βš οΈβ€‹

Assign it narrowly or you have unblocked the fleet. This belongs on the approved exception group only. Point it any wider and you have quietly re-enabled the browser vault for everyone, undoing the baseline.

It is only half the pair. This does nothing useful without the Disable baseline in place; the two are designed and reviewed together.

Governance is the real control. The technology is trivial; the risk is human. Every member of the group needs a documented reason, written customer approval, and a place in a regular review, or it becomes shadow IT with extra steps.

License and reversibility. Included in Business Premium. Clean-revert: unassign and those devices fall back under the disable baseline.


Want control? Start with the disable baseline. Want an exception? Use this, narrowly, with the paperwork to back it up. πŸ”“