Project Atlas AetherDev project hub
Atlas project production

Munki Client Configurator

Use login-time support automation to map Active Directory context to a Munki ClientIdentifier and keep managed Macs aligned with district software targeting rules.

Internal-only entry. Do not publish externally without review.
Type
Component
Lifecycle
Active
Last touched
2026-03-26
Visibility
Internal

Purpose

Keep managed Macs pointed at the right Munki catalog and baseline configuration with minimal technician intervention.

Current state

The registry now makes this workflow more operationally concrete: login-time automation reads AD OU context (with username mapping or override paths when applicable), maps to a ClientIdentifier, updates ManagedInstalls only when necessary, enforces baseline defaults, and logs prior/new values plus Munki exit codes with rotation.

Next step

Document deployment inventory, mapping governance ownership, override precedence, and baseline browser-enforcement scope, and keep this workflow linked to broader asset-sync and refresh operations.

Interfaces

Inputs
  • clientid-mapping.json
  • LaunchDaemon plist
  • Munki preferences
  • local AD context
Outputs
  • ManagedInstalls ClientIdentifier values
  • enforced defaults
  • /var/log/munki-client-configurator.log

Reality to Action trace

Reality Ingestion

Contributes in this stage.

Canonical Storage

Not in scope.

Automation Engines

Not in scope.

Human Interfaces

Not in scope.

Operational Adoption

Contributes in this stage.

Core workflow

TBD. Document the 5-10 steps that define the core workflow.

Data integrity and contracts

Source of truth rules

  • Active Directory OU and username context are canonical for local ClientIdentifier mapping decisions.
  • Local Munki preferences are the endpoint execution surface, not the long-term source of truth for device ownership or asset state.

Safe handling

  • Restrict mapping files and local logs.
  • Document who approves OU-to-ClientIdentifier mapping changes.
  • Coordinate changes with adjacent inventory and refresh workflows to avoid targeting drift.

Operational notes

Reliability posture

The workflow is safe to rerun and logs changes clearly, but bad mappings can still mis-target software if governance is weak.

Observability

  • UTC log at /var/log/munki-client-configurator.log
  • log rotation after 1 MB with up to three retained copies
  • LaunchDaemon status and Munki exit codes

Security and privacy

Local logs and mapping files include user or OU context and should remain restricted to device-management administrators.

Dependencies

Upstream
  • Active Directory binding or local dscl lookups
  • Munki infrastructure
  • mapping governance
Downstream
  • software targeting
  • endpoint readiness
  • adjacent asset-sync workflows

Ownership

Owners

Technology Services, Josh Barton

Users

Technology Services, Mac management operators

Munki Client Configurator

Operational Notes

  • The registry now gives this page a more concrete runtime picture. Login-time automation uses dscl lookups and mapping JSON to derive a Munki ClientIdentifier, updates preferences only when needed, and logs prior and new values plus Munki exit codes to a rotated local log.
  • Documented behavior now includes: AD OU or username mapping paths, optional user-level override conventions, prerequisite bootstrap checks (for example managed-client readiness and directory context), and baseline default enforcement that can include browser-default policy behavior.
  • This remains an endpoint-management support automation layer, not a standalone system-of-record workflow. Its operational value comes from reducing drift between local device context and the software-targeting rules expected by central management.
  • Atlas now links it more clearly to the broader refresh and inventory ecosystem because mapping mistakes here can surface later as refresh or support noise rather than immediate script failure.

Registry Alignment

  • Mapped registry entry: INT-031; adjacent connector context: INT-045.
  • Registry clarified: this is a concrete production login-time automation with documented dscl lookup behavior, log rotation, optional MDM checks, and a real relationship to broader device-operations workflows.
  • Validation gaps: active deployment inventory, mapping governance ownership, and relationship to broader asset-sync workflows still need documentation.