Enable/Disable Location Services

What the macOS Location Services baseline Worklet does

This Automox Worklet™ sets macOS Location Services to a known state on every endpoint under management. The Worklet branches on the locPref variable, reads the current LocationServicesEnabled value from the per-host locationd preference plist, and writes the target value with the defaults command when the endpoint has drifted from the configured baseline.

Both branches of the policy are supported. Set locPref to enabled when a Mac fleet needs location-aware time zones, Find My, or asset tracking; set locPref to disabled when the privacy baseline forbids any application from sampling Wi-Fi triangulation or GPS data. The Worklet writes only the LocationServicesEnabled key and does not touch per-application authorization, so apps that were previously granted location access keep that authorization the next time the service is turned back on.

Per the script header, the underlying preference change is immediate at the daemon level, but the System Settings toggle and the menu bar arrow icon reflect the new state after the next reboot. Plan policy windows accordingly when you need a visible state change at the GUI.

Why hold a Location Services privacy baseline

Location data on a managed Mac is in scope for GDPR Article 9 sensitive-data handling, CIS Benchmark for macOS section 2.5, and most internal privacy policies that treat geolocation as personally identifiable information. A laptop that wakes up in a coffee shop or an airport with locationd enabled can leak coarse geofence data to any application granted access.

The opposite drift is just as costly. A security team disables Location Services on a kiosk image, a user re-enables it through System Settings, and the audit screenshot from last quarter no longer matches the running state. The LocationServicesEnabled bit under /var/db/locationd/Library/Preferences/ByHost/ is volatile by design: major macOS upgrades rebuild the per-host ByHost plist against a new hardware UUID, and a Migration Assistant restore from a personal Mac will bring the source machine’s preference along with it.

Running this Worklet on a recurring policy rewrites the desired LocationServicesEnabled value on every macOS endpoint in scope so the locationd state is corrected before it shows up in the next privacy audit.

How Location Services enforcement works

1. Evaluation phase: The current evaluation script always reports the endpoint as non-compliant (exit 1), so the policy hands control to remediation on every run. Treat the remediation step as the source of truth for state checking and convergence.

2. Remediation phase: The remediation script reads LocationServicesEnabled from /var/db/locationd/Library/Preferences/ByHost/com.apple.locationd with defaults read, resolves the hardware UUID with /usr/sbin/system_profiler SPHardwareDataType, and inspects the locPref variable. If the current value already matches the target state, the script logs a no-op message and exits 0. If it does not, the script writes the new integer to two keys under the same ByHost plist (com.apple.locationd and com.apple.locationd.<UUID>) using defaults write.

Location Services baseline requirements

• macOS endpoint with the Automox agent installed and running as root (the default agent context already meets this; locationd plists require root to write)

• Set the locPref policy variable to enabled or disabled before scheduling the Worklet; the current script hardcodes locPref="enabled", so edit the remediation script to read the variable from the environment, or replace the literal with disabled when you need the opposite state

• /usr/sbin/system_profiler available at its default path so the script can resolve the Hardware UUID used in the ByHost plist key

• No conflicting MDM configuration profile that pins LocationServicesEnabled; an MDM profile takes precedence over defaults writes and will cause the policy to flip back on the next sync

• Reboot window available when an end user needs to see the new state reflected in System Settings under Privacy and Security and in the menu bar status area

Expected state after baseline enforcement

When locPref is set to disabled, the LocationServicesEnabled key in the per-host plist holds 0, locationd no longer answers new CLLocationManager requests after the next reboot, and the Location Services toggle in System Settings under Privacy and Security shows off with the menu bar arrow icon cleared. When locPref is set to enabled, the same key holds 1, the toggle in System Settings shows on after reboot, and previously authorized applications regain location access without re-prompting the user.

Validate by reading the key directly with sudo defaults read /var/db/locationd/Library/Preferences/ByHost/com.apple.locationd LocationServicesEnabled and confirming the integer matches the locPref target. For audit evidence, capture the defaults read output alongside the Worklet run identifier so the two artifacts pin the endpoint to the policy run that produced the state. Because the evaluation script always exits 1, the policy will re-run the remediation on each cycle; the remediation is idempotent and short-circuits with an already-enabled or already-disabled log line when the state is already correct.