URL Block Works on Windows but Not on Chromebooks
An administrator sets a Chrome policy to block https://filesharing.example.net/* for all users. The policy is configured in the Google Admin console under Chrome Browser > User & Browser Settings for the root OU, because the company also manages 900 Windows and macOS laptops with Chrome Browser Cloud Management. On Chromebooks, users can still reach the file-sharing site; on managed Windows laptops, the block works. The administrator also force-installs an extension that opens the site, and on Chromebooks the extension is installed but its navigation is not blocked. There are 2,000 Chromebooks in a child OU called Education, and 900 browser-managed laptops in a child OU called Corporate. The block should apply to everyone, but the Education OU has an inherited exception that allows filesharing.example.net for a legacy lesson. No one knows when the exception was added. The admin wants a fix that does not break the legacy lesson for the 40 devices that still need it.
1. Why does the block work on Windows but not on Chromebooks?
Read the worked answer
Chrome Browser Cloud Management policies and ChromeOS user policies are separate policy surfaces even though both appear in the Admin console. A URL block set under Chrome Browser settings applies to Chrome browser instances managed through CBCM, such as the Windows and macOS laptops. It does not automatically become a ChromeOS user policy for Chromebooks. On ChromeOS, URL blocking must be configured in the ChromeOS user and browser settings for the relevant user OU, with the URL blocklist applied there and inherited by child OUs.
The second symptom supports this: the extension is installed on Chromebooks, but its navigation is not blocked, which is consistent with the ChromeOS-side URL policy not being in force. The extension's host permissions do not bypass URLBlocklist; they only affect what the extension is permitted to access. The fix is not to loosen the extension policy but to place the URL block on the ChromeOS policy surface that governs those users.
2. How should policy inheritance and the Education exception be diagnosed and corrected?
Read the worked answer
On ChromeOS, URLAllowlist entries take precedence over URLBlocklist entries. If the Education OU inherited an allowlist entry for filesharing.example.net, that exception can override the root block for users in Education. Diagnose by checking the effective policy on a sample Chromebook at chrome://policy, filtering for URL blocking and allowlisting, and noting the source OU. Then inspect each OU from root to Education for the allowlist entry.
Remove the broad exception from Education so the root block applies to the main population. Create a small child OU, for example LegacyLesson, containing only the 40 users or devices that still need the legacy lesson. Apply the URLAllowlist exception there, not at Education. Keep the URLBlocklist at the root or at a level above both. Verify on one legacy device and one ordinary Education device: the legacy device should reach the site, and the ordinary device should be blocked. Refresh policy and retest after sign-out or reboot.
3. What validation and change-control steps should accompany the fix?
Read the worked answer
Document which policy surface each rule belongs to: ChromeOS user policy for Chromebooks, CBCM policy for Windows and macOS. Do not assume one console rule covers both. Before changing the Education OU, capture the current effective policy from a representative device and export the relevant OU settings so the exception can be restored if the legacy lesson breaks.
After the change, test four cases: an ordinary Education Chromebook, a LegacyLesson Chromebook, a Corporate Windows laptop, and an unmanaged or guest session if applicable. Confirm that the extension still installs but cannot navigate to the blocked site outside LegacyLesson. Check that the block is enforced for both typed navigation and extension-initiated navigation. Record the 40 legacy devices by asset tag or user group, set a review date, and require a new exception request if the lesson continues. Finally, audit other child OUs for undocumented allowlist entries that may be silently overriding root blocks.