Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

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.

Minimum KEPM Version: 2.1.1.2 introduces headless macOS MDM install support, including automatic system extension activation when the pre-approval profile is present and suppression of the Post Install Steps window on a compliant MDM deploy.

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.

#
Profile
Payload Type
Purpose

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

Item
Requirement

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

PayloadIdentifier is not product-matched. Outer and inner identifiers must be unique in your MDM tenant, and GUID-style values (common with Intune) are supported. Keeper EPM detects the system extension and FDA profiles by payload content, not by a Keeper-specific profile ID string.

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:

  1. Registration Key profile

  2. System Extension profile

  3. FDA (PPPC) profile

  4. InstallEnterpriseApplication (.pkg)

  5. RestartDevice (optional, recommended on first deploy)

Rule
Why It Matters

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.

Note: The three profiles (Registration Key, System Extension, FDA) are shown separately for clarity, but there is no requirement to deliver them as three distinct .mobileconfig files. All three payloads can be combined into a single configuration profile if that better suits your MDM workflow. Keeper EPM detects the System Extension and FDA payloads by content, not by which profile carries them.

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

MDM pre-approval alone does not register the extension. Keeper EPM 2.1.1.2 and later automatically submits OSSystemExtensionRequest when a system-extension-policy profile approving this Team ID and bundle ID is installed and the host app launches. Detection is by that payload content; the profile's PayloadIdentifier may be any unique value, including an Intune-assigned GUID.

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 Allowed only (<integer>1</integer> or <true/>). Do not combine Allowed and Authorization on the same entry — macOS rejects the payload.

  • CodeRequirement identifier "..." must match codesign -dv Identifier= for that binary. Team ID 234QNB7GCA for production (Callpod Inc.).

  • Set outer profile PayloadScope to System.

  • Generate unique PayloadUUID and PayloadIdentifier values when creating your own profile. GUIDs are supported.

  • MDMOverrides.plist listing Allowed=1 is necessary but not sufficient — a mismatched CodeRequirement still 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:

#
Where
Must Equal

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

AssociatedBundleIdentifiers was introduced in macOS 13.0 (Ventura). It is silently ignored on older macOS versions and causes no error. The Keeper EPM minimum system version is macOS 13.0, so this key is safe to include unconditionally.

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: InstallEnterpriseApplication

  • Manifest: 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

MDM returning Acknowledged for InstallEnterpriseApplication does not guarantee the package installed. Check device logs or on-disk paths if install appears to fail.

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:

Check
Expected Result

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

Symptom
Likely Cause
Action

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

PreviousKeeper Trash
NextProtected Path Design Intent

Last updated

Was this helpful?