macOS Deployment via MDM

This page describes how to deploy Keeper Endpoint Privilege Manager (Keeper EPM) to managed Macs through an MDM platform (Jamf, Intune, Kandji, Mosyle, or equivalent) without user interaction. A correct MDM deployment delivers three configuration profiles, installs the signed .pkg, and optionally triggers a reboot so the system extension and Full Disk Access (FDA) grants take effect.
This guide focuses on what Keeper EPM requires from your MDM. It assumes you already know how to upload profiles, assign device groups, and push InstallEnterpriseApplication (or equivalent) commands in your MDM product. For interactive install steps, service management, and manual registration, see Deploy with macOS.
What MDM Must Deliver
A compliant MDM deployment consists of three configuration profiles, the signed installer package, and an optional restart command. All profiles must be scoped to the System (device) channel.
1
Registration Key
com.apple.ManagedClient.preferences
Writes the registration token so the agent registers automatically after install
2
System Extension Pre-Approval
com.apple.system-extension-policy
Pre-approves the Endpoint Security extension for silent activation
3
Full Disk Access (PPPC)
com.apple.TCC.configuration-profile-policy
Grants Full Disk Access to KEPM binaries and the system extension
Package
Signed keeper-privilege-manager.<version>.<arch>.pkg (Developer ID Installer)
Team ID
234QNB7GCA (Callpod Inc. / Keeper Security production builds)
Profile Scope
All profiles at System scope (device channel)
Reboot
Recommended after first install so extension activation and TCC settle
When all three profiles are installed, the package is on disk, the extension reports [activated enabled], and the activated build matches the embedded system extension version, Keeper EPM does not display the Post Install Steps window. After an in-place PKG upgrade with a newer embedded extension that is already activated, com.keeper.keeperse silently submits a replace request for both MDM and Manual installs. First-time silent activation still requires the system extension MDM profile.
Deployment Order
Push all configuration profiles before the install package. The profiles must be present on the device before the package runs, but they can be pushed well in advance — even hours or days earlier as part of a device's baseline configuration. The order below reflects a typical single-session deployment:
Registration Key profile
System Extension profile
FDA (PPPC) profile
InstallEnterpriseApplication(.pkg)RestartDevice(optional, recommended on first deploy)
Profiles present before the package runs
macOS evaluates the System Extension and PPPC payloads against Keeper EPM's Team ID and bundle identifiers, not against files on disk. As long as the profiles are installed before the package executes, TCC grants and system extension activation apply cleanly when the binaries land.
Reboot after first deploy
The system extension host app (com.keeper.keeperse LaunchDaemon) auto-submits the extension activation request when the system extension profile is present. A reboot ensures activation, FDA application, and registration startup jobs all run in a clean boot sequence.
Brief pause between MDM commands
A short delay (typically one to two seconds) lets the device check in and apply each payload before the next command arrives. The exact interval is environment-dependent — network conditions, MDM platform, and device hardware all affect check-in timing, so tune this to what works reliably in your environment.
Profile 1 — Registration Key
Payload Type: com.apple.ManagedClient.preferences
Writes To: /Library/Managed Preferences/com.keeper.keeper-privilege-manager.plist
Key: KEEPERREGCODE — your deployment registration token, formatted as hostname:deployment-uid:private-key
Example Payload
After install and service start, Keeper EPM reads the managed preference and registers automatically. No registration dialog is shown in MDM mode.
Verify on Device
Profile 2 — System Extension Pre-Approval
Payload Type: com.apple.system-extension-policy
Extension Bundle ID: com.keeper.keeper-privilege-manager.monitor
Team ID: 234QNB7GCA
Extension Type: EndpointSecurityExtension
Example Payload
Verify on Device
Profile 3 — Full Disk Access (PPPC)
Payload Type: com.apple.TCC.configuration-profile-policy
Service: SystemPolicyAllFiles (TCC key kTCCServiceSystemPolicyAllFiles)
Keeper EPM needs FDA on the wrapper app, daemon, host app, and system extension. Each PPPC entry's CodeRequirement must use the binary's real codesign Identifier — not a parent or prefix ID.
Required FDA Targets
UI Name (System Settings)
Bundle ID / Path
Codesign Identifier in CodeRequirement
KeeperPrivilegeManager
com.keeper.endpoint-privilege-manager.launcher
com.keeper.endpoint-privilege-manager.launcher
(wrapper path)
/Library/Keeper/KeeperPrivilegeManager.app
same as launcher
(daemon signing ID)
com.keeper.endpoint-privilege-manager.privilege-manager
com.keeper.endpoint-privilege-manager.privilege-manager
(daemon path)
/Library/Keeper/sbin/KeeperPrivilegeManager
same as daemon
Keeper Endpoint Privilege Manager
com.keeper.keeper-privilege-manager
com.keeper.keeper-privilege-manager
Keeper Endpoint Privilege Manager Extension
com.keeper.keeper-privilege-manager.monitor
com.keeper.keeper-privilege-manager.monitor
(embedded extension path)
path under host app Contents/Library/SystemExtensions/...
same as monitor
Do not use bare com.keeper.endpoint-privilege-manager or .service — production builds use .launcher (wrapper) and .privilege-manager (daemon). Do not assume the daemon inherits FDA from the wrapper after exec; grant the daemon explicitly.
PPPC Rules
Use
Allowedonly (<integer>1</integer>or<true/>). Do not combineAllowedandAuthorizationon the same entry — macOS rejects the payload.CodeRequirementidentifier "..."must matchcodesign -dvIdentifier=for that binary. Team ID234QNB7GCAfor production (Callpod Inc.).Set outer profile
PayloadScopeto System.Generate unique
PayloadUUIDandPayloadIdentifiervalues when creating your own profile. GUIDs are supported.MDMOverrides.plistlistingAllowed=1is necessary but not sufficient — a mismatchedCodeRequirementstill leaves runtime FDA ineffective (for example, Downloads returns EPERM).
Three-Way Identifier Alignment
For an MDM PPPC grant to apply silently — without prompting the user in System Settings — three identifiers must all match for each target process:
1
App bundle code signature (codesign -dvvvv … | grep ^Identifier)
The bundle ID in the PPPC profile entry
2
CFBundleIdentifier in the app's Info.plist
Same as above
3
AssociatedBundleIdentifiers array in the LaunchDaemon plist that launches the app
Same as above
If any of the three is missing or mismatched, macOS cannot correlate the PPPC grant to the running process. The user will be prompted to approve FDA manually in System Settings → Privacy & Security → Full Disk Access, even though the MDM profile shows as installed.
Verify KeeperPrivilegeManager Alignment
Verify FDA Profile Application
For deep TCC verification, inspect MDMOverrides.plist. The calling application (for example, Terminal) must itself have FDA to read this file:
Package Installation
Host the signed .pkg on HTTPS reachable from managed Macs, then push via MDM:
Request Type:
InstallEnterpriseApplicationManifest: software-package asset with pkg URL and optional SHA-256 chunk manifest
Requirements
Valid Developer ID Installer signature (Callpod Inc.)
The Mac can resolve DNS, complete TLS, and reach the URL through any firewall
The web server returns HTTP 200 and directory permissions allow the server to read the file
Verify on Device
Expected launchd entries include:
com.keeper.keeper-privilege-manager(main service)234QNB7GCA.com.keeper.keeper-privilege-manager.monitor(system extension)com.keeper.keeperse(host app for extension activation)
Expected End State
After a successful MDM deploy and reboot:
All three Keeper profiles
Installed (profiles show -type configuration)
System extension
[activated enabled] in systemextensionsctl list
Post Install Steps window
Not shown
Agent registration
IsRegistered: true from /api/Keeper/registration
FDA in System Settings
Toggles may show OFF even when MDM grants are active — this is normal for MDM-managed FDA
Quick Verification Checklist
Run on a managed Mac after deployment:
All checks should pass before rolling out to production groups.
Troubleshooting
FDA profile installed but no TCC grants
FDA pushed before package
Re-push FDA profile after install
FDA profile installed, user still prompted to approve FDA manually
AssociatedBundleIdentifiers missing from LaunchDaemon plist, or identifiers mismatch
Verify three-way alignment: codesign ID = CFBundleIdentifier in Info.plist = AssociatedBundleIdentifiers[0] in /Library/LaunchDaemons/com.keeper.keeper-privilege-manager.plist; use KEPM 2.1.0.1789 or later
FDA profile rejected by Mac
Invalid PPPC payload (Allowed + Authorization, bad UUIDs)
Validate the payload with profiles show; ensure a single control keyword per entry
Extension not [activated enabled]
System extension profile missing or host app not run
Confirm sysext policy content (Team ID + monitor bundle ID); reboot or re-run deploy
Post Install Steps window shown (FDA only)
FDA PPPC content missing at host app launch
Confirm PPPC SystemPolicyAllFiles grants; re-push FDA
Agent not registered
Regcode managed preference missing or old KEPM build
Confirm /Library/Managed Preferences/com.keeper.keeper-privilege-manager.plist; use KEPM 2.1.1.2 or later
Package Acknowledged but not installed
HTTP 403, bad signature, hash mismatch
Fix hosting; verify signature with pkgutil --check-signature
Post Install Steps window after Intune deploy
Profile identifiers are GUIDs (expected)
Verify payload content with profiles … -output stdout-xml, not Keeper reverse-DNS identifiers
Related Pages
Last updated
Was this helpful?

