gen/os — Blog

Auto-assigning Macs to a Jamf site from an Entra ID smart group

hello@genos.blog (Philippe Boucher) — Sun, 21 Jun 2026 00:00:00 GMT

I wanted something that sounds like it should be a checkbox: Macs whose user belongs to a particular Entra ID group should land in a specific Jamf site, automatically, so the regional admins only see their own machines. It isn't a checkbox. A Jamf site is a static attribute on the computer record, and smart groups don't move records into sites — they scope policies and profiles, nothing more. So "automatically added to a site" really means: something runs on a schedule, reads the group's members, and writes the site onto each one through the API.

Here's the routine I use to do exactly that.

Step 1: the Entra-tied smart group

First you need a smart group whose membership reflects an Entra ID group. Two ways to get there — confirm which one matches your setup:

Jamf connected to Entra as a cloud identity provider, with an assigned user on each computer. The smart group criterion then keys off the assigned user's Entra group membership. This is the cleanest path if you've already wired Jamf to Entra.
An extension attribute that surfaces the user's Entra group — populated by a script (a Microsoft Graph lookup, or reading what Platform SSO / the Company Portal already knows locally). The smart group criterion keys off that EA's value.

Either way you end up with a smart group — say "Entra – Marketing" — that fills and empties as people move in and out of the Entra group. Note its group ID (it's in the URL when you open the group in Jamf). That ID is the only handle the routine needs.

Step 2: why this needs a routine at all

Worth saying plainly, because it's the thing that trips people up: there is no native "members of this smart group go in this site" setting. Site is assigned per-record, by hand or by API. So the job is a small loop — get the group's members, PUT the site onto each — that you run on a schedule. That loop is the "routine."

Step 3: the routine

A bash version you can drop into cron, a LaunchDaemon, or an Azure Function:

#!/bin/bash
# Sync Jamf site assignment from an Entra-tied smart group.
# Run on a schedule. Idempotent — re-running just re-asserts the same state.

set -euo pipefail

JAMF_URL="https://yourorg.jamfcloud.com"
CLIENT_ID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
CLIENT_SECRET="…"           # from an API Role/Client (see privileges below)
SMART_GROUP_ID="42"          # the Entra-tied smart group
TARGET_SITE="Marketing"      # the Jamf site to drop members into

# --- 1. bearer token (modern OAuth client-credentials) ---------------------
token=$(curl -fsS -X POST "$JAMF_URL/api/oauth/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "client_id=$CLIENT_ID" \
  -d "client_secret=$CLIENT_SECRET" \
  -d "grant_type=client_credentials" \
  | plutil -extract access_token raw -)

auth=(-H "Authorization: Bearer $token")

# --- 2. read smart group membership (Classic API — bearer works here) ------
ids=$(curl -fsS "${auth[@]}" -H "Accept: application/xml" \
  "$JAMF_URL/JSSResource/computergroups/id/$SMART_GROUP_ID" \
  | xmllint --xpath '//computers/computer/id/text()' - 2>/dev/null)

# --- 3. assign each member to the target site ------------------------------
for id in $ids; do
  echo "Assigning computer $id → site '$TARGET_SITE'"
  curl -fsS -X PUT "${auth[@]}" -H "Content-Type: application/xml" \
    "$JAMF_URL/JSSResource/computers/id/$id" \
    -d "<computer><general><site><name>${TARGET_SITE}</name></site></general></computer>" \
    >/dev/null
done

echo "Done — $(echo "$ids" | wc -w | tr -d ' ') computers reconciled."

What's going on:

Modern auth. Basic auth is gone on recent Jamf Pro, so the routine gets an OAuth bearer token from an API Role/Client at /api/oauth/token.
Bearer tokens work on the Classic API. Membership and site assignment are still cleanest on the Classic endpoints, and the modern token authorizes them fine — so you get one auth model across both.
GET /JSSResource/computergroups/id/<id> returns the group's members; the xmllint --xpath pulls out just the computer IDs.
PUT /JSSResource/computers/id/<id> with a minimal <computer><general><site> body sets the site. You only send the field you're changing.

The API role privileges

Keep the client least-privilege. It needs exactly:

Read on Smart Computer Groups (to list members)
Update on Computers (to set the site)

Nothing else.

The same thing as a Claude Code routine

If you've already stood up a Jamf MCP server, you don't need the bash at all. Schedule a Claude Code routine that runs every few hours and tells the MCP, in plain language: "find the members of the 'Entra – Marketing' smart group and set each one's site to Marketing." Same loop, same API calls underneath — but the routine is a sentence, and you get a readable run log instead of cron output. It's the natural follow-on to wiring an assistant to Jamf in the first place.

Caveats worth knowing

A computer lives in exactly one site. Assigning a new site replaces the old one — make sure your groups don't overlap, or decide which wins.
This is one-way. When someone leaves the Entra group the Mac drops out of the smart group, but nothing moves it back out of the site. If you need that, add reconciliation: compare current site members against group members and reset the strays to your default site.
It's idempotent. Re-running re-asserts the same assignment, so a frequent schedule is safe — the PUTs are no-ops when nothing changed.

Takeaway

Site assignment can't be driven by a smart group directly, but it's a short hop with the API: read the Entra-tied group, PUT the site onto each member, run it on a schedule. Whether that schedule is cron or a Claude routine, the Macs sort themselves into the right site as people move around the org — and the regional admins only ever see what's theirs.

A self-updating pkg: install the latest app version from Azure Blob in a postinstall

hello@genos.blog (Philippe Boucher) — Sun, 21 Jun 2026 00:00:00 GMT

Re-packaging an app every time the vendor ships an update gets old fast: download the new version, build the pkg, upload it to Jamf, fix the scope, test. Do that across a dozen apps and you spend real time pushing bytes around.

Here's the pattern I use instead. I build one pkg that contains no application at all — just a postinstall script. When that pkg runs on a Mac, the script reaches out to Azure Blob Storage, pulls down the current installer, and runs it. The pkg I upload to Jamf never changes. To ship a new version of the app, I overwrite a single blob in the container. Every deployment after that gets the latest build, with no re-packaging and no touching Jamf.

The shape of the trick

Two pieces:

A payload-free pkg — a package with zero files, whose only job is to run a script.
A postinstall script that downloads the real installer from blob storage and installs it.

That's it. The "latest version" lives in the bucket, not in the package.

Building the payload-free pkg

Put the script in a scripts/ folder named exactly postinstall, make it executable, and hand the folder to pkgbuild with --nopayload:

mkdir -p scripts
# (write the postinstall below into scripts/postinstall first)
chmod +x scripts/postinstall

pkgbuild --nopayload \
  --scripts scripts \
  --identifier com.yourorg.acme-bootstrap \
  --version 1.0 \
  Acme-Bootstrap.pkg

--nopayload tells pkgbuild there are no files to lay down — the package exists only to run the scripts in scripts/. The postinstall runs as root at install time, which is exactly what you want for dropping an app into /Applications.

If you deploy this outside Jamf as well, sign it so Gatekeeper and installer trust it:

productsign --sign "Developer ID Installer: Your Org (TEAMID)" \
  Acme-Bootstrap.pkg Acme-Bootstrap-signed.pkg

Inside Jamf, signing isn't strictly required — the management framework installs it directly — but it's good hygiene.

The postinstall script

#!/bin/bash
# postinstall — download the current installer from Azure Blob and install it.
# Ships inside a payload-free "bootstrap" pkg.
# Replace the blob in Azure = ship a new version. This pkg never changes.

set -euo pipefail

# --- config -----------------------------------------------------------------
# Read-only, container-scoped, expiring SAS. It only grants pulling an
# installer we'd hand out anyway — low sensitivity, but keep it read-only.
BLOB_URL="https://YOURACCOUNT.blob.core.windows.net/installers/Acme-latest.pkg"
SAS="?sv=2024-11-04&ss=b&srt=o&sp=r&se=2027-01-01T00:00:00Z&sig=REDACTED"
# ----------------------------------------------------------------------------

workdir="$(mktemp -d)"
trap 'rm -rf "$workdir"' EXIT
pkg="$workdir/installer.pkg"

echo "Downloading the current installer…"
if ! curl -fsSL "${BLOB_URL}${SAS}" -o "$pkg"; then
  echo "ERROR: download failed" >&2
  exit 1
fi

# A failed/expired SAS returns an XML error page, not a pkg. Catch that before
# handing garbage to installer.
if ! file "$pkg" | grep -qi 'xar archive'; then
  echo "ERROR: downloaded file is not a valid pkg (check the SAS/URL)" >&2
  exit 1
fi

echo "Installing…"
installer -pkg "$pkg" -target /

exit 0

A few deliberate choices in there:

mktemp -d + a trap so the download lands in a unique temp dir and gets cleaned up no matter how the script exits.
curl -fsSL — -f fails the command on an HTTP error instead of happily saving the error body; quote the whole URL because the SAS string is full of & and =.
The file … xar archive check. This is the one that saves you a support ticket: when a SAS expires or the URL is wrong, Azure hands back an XML error document. Without the check you'd pass that to installer and get a confusing failure. The check turns it into a clear log line.

Hosting the installer in Azure Blob

Create a private container (don't make it public unless you mean to), then overwrite one fixed blob name on every release:

az storage blob upload \
  --account-name YOURACCOUNT \
  --container-name installers \
  --name Acme-latest.pkg \
  --file ./Acme-3.4.1.pkg \
  --overwrite

The Macs always pull Acme-latest.pkg; you decide what that name points at. Shipping 3.4.2 next month is one upload --overwrite away.

The SAS token

Generate a read-only, container-scoped SAS with an expiry — never an account key:

az storage container generate-sas \
  --account-name YOURACCOUNT \
  --name installers \
  --permissions r \
  --expiry 2027-01-01 \
  --auth-mode login --as-user \
  --output tsv

Yes, that token ships inside the pkg. I'm comfortable with that because it grants exactly one thing — reading an installer I'd otherwise hand to anyone on the fleet — and nothing else: no write, no listing the account, no other container. To rotate it without rebuilding the pkg, back the SAS with a stored access policy and revoke the policy server-side. Otherwise, rotating means issuing a new SAS and rebuilding the bootstrap pkg once.

Deploying it

Upload Acme-Bootstrap.pkg to Jamf once and scope a policy to it however you like — at enrollment, in Self Service, on a schedule. From then on the package is frozen. The only thing that ever changes is the blob.

Not on Azure?

The pattern is storage-agnostic — only the URL and the auth differ:

AWS S3 — host the installer in a bucket and download via a presigned URL (or a public object). Same curl … | installer shape.
Any HTTPS host — Backblaze B2, Cloudflare R2, even a plain web server. If curl can reach it, the script doesn't care.

And if you outgrow a single fixed name — say you want version history and rollback — upload versioned files (Acme-3.4.1.pkg) plus a tiny Acme.json manifest that names the current one. The script reads the manifest first, then downloads what it points to. More moving parts, but you keep every build.

Takeaway

Packaging doesn't have to mean re-packaging. Build the wrapper once — payload-free pkg, a postinstall that pulls from blob storage — and your "update the app" workflow shrinks to a single az storage blob upload --overwrite. The pkg in Jamf becomes a stable pointer, and the latest version lives where it's easy to replace.

Why Jamf encrypted script parameters break on modern macOS

hello@genos.blog (Philippe Boucher) — Thu, 18 Jun 2026 00:00:00 GMT

A policy that had run fine for a year started failing on freshly-upgraded Macs. The script used Jamf's Encrypted Script Parameters to stash an API account password, and on the new machines every Jamf API call came back as the "Unauthorized" HTML login page — so the script blew up trying to parse XML. The real culprit was one line of openssl output buried at the top: bad magic number.

The setup

Encrypted Script Parameters is the standard way to keep a secret out of a Jamf script in cleartext. You encrypt the secret once with openssl, store the encrypted string, the salt, and the passphrase as script parameters, and the script decrypts the secret at runtime. The decrypt line looks like this:

pass=$(echo "$4" | openssl enc -aes256 -d -a -A -S "$5" -k "$6")

Parameter positions vary from script to script — the log-collection script I hit this on used different ones — but the shape is always the same: -S "$salt" -k "$passphrase".

The symptom

On macOS Ventura and later, that same decrypt returns:

bad magic number

prepended to (or instead of) the password. So $pass ends up empty or garbage. Every authenticated curl to the Jamf API then returns the login/Unauthorized HTML page instead of XML, and any xmllint / xpath parsing dies with something like mismatched tag from the XML parser.

This is what makes the bug a time-sink: it looks like an API or permissions problem, but it's a decryption problem. The credentials were never the issue.

Why it breaks

Check your openssl version on an old machine and a new one:

openssl version

The encrypted blob in my case was generated years earlier on LibreSSL 2.8.3 (Monterey). Back then, passing an explicit salt with -S wrote the raw ciphertext without the Salted__ header that openssl normally puts at the front. LibreSSL 3.x (Ventura and up — I was on 3.3.6) expects that Salted__ header at decryption time, even when you also pass -S. No header, no decryption: bad magic number.

You can confirm it directly. Decode the blob and look at the first eight bytes:

echo "$ENCRYPTED" | openssl base64 -d -A | xxd | head -1

If they aren't 53 61 6c 74 65 64 5f 5f — that's Salted__ in ASCII — your blob has no header, and modern LibreSSL won't decrypt it with -S.

The fix: stop using -S

The robust, version-independent approach is to let openssl manage the salt itself. Encrypt without -S, so the salt and header are embedded in the output:

echo "my-secret" | openssl enc -aes256 -a -A -k "$PASSPHRASE"

and decrypt without -S, reading the salt back from that embedded header:

pass=$(echo "$ENCRYPTED" | openssl enc -aes256 -d -a -A -k "$6")

The separate salt parameter is now unnecessary — you can drop it entirely. Because the salt travels inside the ciphertext, this behaves the same on every LibreSSL version you'll meet in the field. Re-encrypt your secrets once in this format, update the script and the policy's parameters, and upgrade-day breakage goes away for good.

If you can't re-encrypt right now

Maybe that blob is wired into a dozen policies and you just need today's run to work. As long as you still have the salt and passphrase, you can rebuild the header openssl is looking for and decrypt the old blob as-is:

{ printf 'Salted__'; printf '%s' "$SALT" | xxd -r -p; \
  echo "$ENCRYPTED" | openssl base64 -d -A; } \
  | openssl enc -aes256 -d -k "$PASSPHRASE"

That prepends Salted__ plus the 8-byte salt to the header-less ciphertext — exactly what modern LibreSSL wants. Treat it as a bridge, then migrate to the no--S format when you have a moment.

Takeaway

bad magic number from openssl enc almost always means the ciphertext header doesn't match what your current openssl expects — usually because it was encrypted on a different version. In Jamf land, the fix is to stop pinning the salt with -S and let openssl embed it. Encrypt once in the portable format, and your encrypted parameters stop being a macOS-upgrade landmine.

Zero-touch deployment, explained for non-IT people

hello@genos.blog (Philippe Boucher) — Mon, 08 Jun 2026 00:00:00 GMT

The best onboarding experience I can build for a client looks like this: a new employee receives a sealed MacBook box at home, opens it, connects to Wi-Fi, signs in with their work account — and twenty minutes later the machine is encrypted, secured, and loaded with every app they need. Nobody from IT touched it.

That's zero-touch deployment, and it's not magic. Here's what's happening behind the scenes.

The three pieces

Apple Business Manager

When your organization buys devices from Apple or an authorized reseller, those devices can be automatically registered to your Apple Business Manager (ABM) account at the time of purchase. ABM is the bridge between Apple and your management system: it knows which devices belong to your company before they're even unboxed.

The MDM

Your MDM — Jamf, Intune, or Mosyle — is linked to ABM. The moment a registered device starts up and touches the internet, Apple tells it: "You belong to this organization; enroll yourself with their MDM before doing anything else." The employee can't skip this, and a thief can't bypass it. Even wiped, the device re-enrolls.

The configuration

This is where the real work lives — and where setups succeed or fail. The MDM pushes everything the device needs:

Disk encryption (FileVault) enforced from first boot
Security baseline: passcode rules, firewall, automatic OS updates
Identity: sign-in with the employee's existing work account
Apps: deployed silently, licensed through Apple's volume purchasing
The welcome experience: what the employee actually sees during setup

Why it pays for itself

The math is straightforward. Manually setting up a Mac takes IT one to three hours per machine — imaging, app installs, settings, the works. With zero-touch, marginal device setup time drops to roughly zero, and every machine is configured identically, which is what auditors and cyber-insurance questionnaires actually want to see.

Offboarding gets the same upgrade: when someone leaves, one click locks or wipes the device remotely, and re-issuing it to the next hire is just another unboxing.

What it takes to set up

For a typical small or mid-sized organization, a zero-touch foundation is a short, fixed-scope project: ABM enrollment and domain verification, MDM configuration, security baseline, app catalog, and a test run with a pilot device before the rollout. After that, it just runs.

If your IT person is still spending afternoons setting up laptops by hand, that's the project to do next.

Jamf, Intune, or Mosyle? Choosing the right MDM for your Apple fleet

hello@genos.blog (Philippe Boucher) — Mon, 01 Jun 2026 00:00:00 GMT

When an organization asks me which MDM they should use for their Macs, iPhones, and iPads, they usually expect a one-word answer. The honest answer is: it depends on three questions, and none of them are about the MDM itself.

The three questions that actually matter

1. What does the rest of your stack look like?

If your organization lives in Microsoft 365 — Entra ID for identity, conditional access policies, a Windows fleet alongside the Macs — then Intune deserves a serious look. You already pay for it in most Microsoft 365 plans, your security team already knows the console, and compliance signals flow straight into conditional access.

If you're Apple-first or Google Workspace-based, Intune's advantages shrink quickly, and the friction of its Apple support (slower profile delivery, a weaker macOS story) starts to show.

2. How much depth do you need?

Jamf is the deepest Apple management platform, full stop. If you need complex smart groups, sophisticated deployment workflows, identity-based login with Jamf Connect, or endpoint security with Jamf Protect, nothing else matches it. The trade-off is cost and the need for someone who knows it well.

Mosyle covers the most common 80% of needs at a fraction of the price, and its automation is genuinely good. For a 30-person startup that needs solid security baselines and zero-touch enrollment, Mosyle is often the rational choice.

3. Who will run it after I leave?

This is the question consultants skip, and it's the most important one. A perfectly configured Jamf instance that nobody on your team understands becomes shelf-ware within a year. Part of my job is matching the platform to the people who will own it — and leaving documentation they'll actually use.

My short version

Microsoft-centric org, mixed fleet → Intune
Apple-heavy org that needs depth and polish → Jamf
Smaller team, strong value focus → Mosyle

There are exceptions to all three, which is exactly what an intro call is for.