ChromeOS Administrator study materials
ChromeOS Administrator study resources

Shared Warehouse Chromebooks and Accountability

ChromeOS Administrator · Put your knowledge to work in context.

All case studies

Shared Warehouse Chromebooks and Accountability

Warehouse operations has 120 shared HP Chromebooks used by 300 seasonal associates across three shifts. Associates do not receive corporate Google accounts; they need access to an inventory web app, a label-printing web app, and occasional email through a shared mailbox. Today all devices are signed in with one shared Google account, [email protected], and the password is posted in each shift office. The security team found that the shared account has Drive access to older inventory exports, and audit logs cannot distinguish who printed a shipping label or viewed a customer address. The company uses SAML SSO for all employee accounts, but the shared account is a Google-only account that bypasses SSO. Operations wants to keep sign-in fast and avoid managing 300 identities, but security requires accountability and no persistent local data. Devices are in a child OU called Warehouse, and the inventory app supports SAML and has an API.

1. Compare a shared Google account, Managed Guest Session, and kiosk mode for this warehouse workflow. Which should be selected, and why?

Read the worked answer

The shared Google account is the weakest option. It defeats SAML, gives every associate the same Drive and email identity, leaves a persistent profile on the device, and makes audit logs non-attributable. It also turns a posted password into a lateral-movement risk if the account can reach anything beyond the warehouse apps.

Kiosk mode is appropriate only if the device runs one dedicated app with no general browser or multi-app workflow. Here associates need inventory, label printing, and occasional email, so a single-app kiosk would force a poor workaround.

Managed Guest Session is the best fit for the multi-app, shared-device requirement. It provides a temporary session without a persistent user profile, can auto-launch approved apps, and can be constrained by device-level policy. It does not, by itself, identify the associate. If accountability is a hard requirement, pair it with app-level SAML authentication using individual IdP accounts, or issue lightweight per-associate identities through the IdP. If operations truly refuses individual identities, document that accountability is limited to device and session logs; do not claim the shared account provides non-repudiation.

2. What policy settings should be applied to the Warehouse OU for the chosen session type?

Read the worked answer

Apply Managed Guest Session as a device-level policy on the Warehouse OU, not as a user policy. Configure an idle timeout and a maximum session length that match shift patterns, force sign-out at end of session, and disable local data persistence where the session type allows it. Auto-launch only the approved inventory and label-printing web apps; do not auto-launch a general browser start page that invites arbitrary navigation.

Restrict navigation with URL allowlists and blocklists, block downloads unless the label printer requires a specific file type, restrict printing to the approved printers, and disable developer tools and guest browsing where available. Disable external storage and restrict clipboard sharing if customer data is involved. Configure the label-printing app through policy rather than letting users install extensions. Set update and power policies so devices reboot and update outside shift hours.

Finally, remove the shared Google account from the devices, rotate its password, transfer or delete its Drive contents, and review recent audit logs. Test one device through a full shift: session timeout, app launch, print job, sign-out, and next-user sign-in. Verify that no previous user's browser history, cookies, or downloads are visible.

3. How can the organization satisfy audit requirements without issuing 300 full Google Workspace identities?

Read the worked answer

Separate identity for application access from identity for ChromeOS device sign-in. The inventory app already supports SAML, so require each associate to authenticate to the app through the IdP. The IdP can issue lightweight accounts or use an existing workforce identity source, and the app can log the individual behind each label print or customer-record view. The Chromebook remains a shared Managed Guest Session, so no persistent ChromeOS profile is created.

For email, do not let all associates use one shared mailbox with a posted password. Use a shared mailbox with delegated access through the IdP, or provide a kiosk-style mail web app that requires individual authentication. If seasonal associates genuinely cannot receive identities, restrict the shared mailbox to a supervised station and log physical access, but treat that as an exception with a documented risk acceptance.

Retain IdP logs and app audit logs together, because ChromeOS device logs will show the device and session but not necessarily the human. Test that a label print can be traced from app log to IdP user to device serial. That is the accountability chain auditors will expect.