MDM Rollout

Every MDM rollout has the same three steps:

1. Install the binary — Homebrew tap, signed .pkg/.msi/.deb, or pre-built artifact.
2. Drop the enrollment manifest — at the system path so every user on the machine inherits the binding.
3. Verify — tokenshift doctor reports back.

Paths used below:

• macOS / Linux system manifest: /etc/tokenshift/enrollment.json
• Windows system manifest: %PROGRAMDATA%\tokenshift\enrollment.json

See Enrollment for what’s in the manifest and why the per-user path takes precedence when both exist.

Jamf

Two policies, scoped to the same smart group:

1. Install — push the signed TokenShift .pkg from the customer portal. Or push a wrapper script that runs brew install pointfiveinc/tap/tokenshift after seeding HOMEBREW_GITHUB_API_TOKEN from a Jamf secret payload.
2. Configure — push the enrollment manifest as a file to /etc/tokenshift/enrollment.json (mode 0644, owned by root).

Run tokenshift doctor as a self-service “verify” policy so users (and your support team) can confirm the binding without admin help.

JumpCloud

JumpCloud Commands work well for both steps:

1. Push a shell command that installs the binary (Homebrew with a pre-seeded token, or a curl | tar step downloading a signed release artifact).
2. Push the manifest contents via a second Command that writes /etc/tokenshift/enrollment.json with tee.

Verify with a third Command that runs tokenshift doctor and captures output.

Intune

Windows-side: package the .msi and assign it to a device group. Manifest goes to %PROGRAMDATA%\tokenshift\enrollment.json — push it via an Intune Win32 app that drops the file in a post-install script, or via a separate configuration profile.

macOS-side: same as Jamf — .pkg install + manifest drop. Intune for Mac runs scripts as root, so writing /etc/tokenshift/enrollment.json is straightforward.

Ansible

- name: install tokenshift
  community.general.homebrew:
    name: pointfiveinc/tap/tokenshift
    state: present
  environment:
    HOMEBREW_GITHUB_API_TOKEN: "{{ vault_brew_token }}"

- name: drop enrollment manifest
  ansible.builtin.copy:
    content: "{{ tokenshift_enrollment | to_nice_json }}"
    dest: /etc/tokenshift/enrollment.json
    owner: root
    group: wheel
    mode: '0644'

- name: verify
  ansible.builtin.command: tokenshift doctor
  register: doctor_out
  changed_when: false

Tip

Run tokenshift doctor --verify (not just doctor) on the first deployment per fleet. It ships one synthetic record through the live ingest path so you catch network policy / TLS interception problems before users hit them.

Updating the manifest

The manifest is read once at session start and cached for the lifetime of the process. Pushing a new manifest takes effect on the next agent session (or the next tokenshift invocation). No restart required for already-running shells beyond the agent itself.

Removing

# remove the binary via your package manager
brew uninstall tokenshift             # macOS / Linux Homebrew
# or msiexec, or `apt remove`, etc.

# remove the system manifest
rm /etc/tokenshift/enrollment.json    # macOS / Linux
del %PROGRAMDATA%\tokenshift\enrollment.json   # Windows

tokenshift uninstall --purge removes hooks and per-user state but never touches the system-deployed manifest — that stays your MDM’s responsibility.

Next

• Enrollment — manifest shape and field meaning.
• Installation & distribution — the full security model: pinning, transport, threat surface.