Behavior monitoring is off by default and the repair script never
checked it, so on devices without the image's managed config (another
distro, a plain install) it stayed off and the compliance rule failed.
Enable it, and cloud-delivered protection, when they're off and not
managed.
Only start mdatp-firstboot where the image installed it; elsewhere every
run logged that first-boot setup hadn't completed and tried to start a
unit that doesn't exist.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The health snapshot's temp directory, chmod and mv in /run every 5
minutes showed up in Defender's timeline as "Data Staged" and
"Executable permissions were added". Drop the snapshot service and
timer. The compliance script now runs `mdatp health` through
systemd-run, so systemd starts mdatp and Defender answers it even when
the script runs inside himmelblaud-tasks. Without systemd-run access it
asks mdatp directly, as before. No image support needed, so the script
works on other distros as is.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Himmelblau runs the custom compliance script inside himmelblaud-tasks,
and Defender refuses to answer `mdatp health` there: the daemon can't
read /proc/<himmelblaud_tasks>/cmdline while checking the caller
("Permission denied" in microsoft_defender_err.log). The script saw no
daemon, and every Defender rule failed although Defender was healthy.
Add mdatp-health-snapshot.timer, which saves the health fields to
/run/mdatp-health every 5 minutes as root, outside that service. The
compliance script reads the snapshot when it's under 20 minutes old and
otherwise asks mdatp directly, so it still works on other distros.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Defender's defaults left behavior monitoring off and every setting
unmanaged. Ship /etc/opt/microsoft/mdatp/managed/mdatp_managed.json:
real-time protection, behavior monitoring, PUA blocking, cloud-delivered
protection at the high block level, automatic definition updates and
sample submission, and scheduled scans (daily quick at 12:00, weekly full
on Wednesday 12:30, low priority). Users can't change managed settings.
The build fails if the file isn't valid JSON.
Network protection (Insiders channels only) and tamper protection
(audit-only preview on Linux) are left out.
The compliance script and rules now also check behavior monitoring and
cloud-delivered protection.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A paste into Intune that lost the first "{" line produced an unreadable
mdatp_onboard.json, and Defender reported "No license found". Check that
the pasted JSON parses and has onboardingInfo before writing it, and log
what to fix otherwise.
The placeholder also appeared twice, so a find-and-replace of it broke
the script; match it by prefix so it appears only once.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Himmelblau installs Intune Linux custom configuration scripts as
/etc/cron.d jobs, and the image had no cron, so a script policy failed to
apply. Add cronie and enable crond.
Add a custom configuration script that repairs Microsoft Defender on its
schedule: finishes first-boot setup, restarts a stopped daemon, onboards with
the tenant's mdatp_onboard.json (pasted into the script in Intune), and
re-enables real-time protection and updates definitions when needed.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Himmelblau reports VERSION_ID from /etc/os-release as the device OS version,
so Intune showed "44". Give himmelblaud and himmelblaud-tasks their own
os-release (bind-mounted in their mount namespace only) with VERSION_ID set to
OSTREE_VERSION, e.g. 44.20261019.0. The rest of the system keeps the stock
VERSION_ID that toolbox, flatpak and dnf expect.
Add an Intune custom compliance discovery script and rules for Microsoft
Defender for Endpoint (installed, running, onboarded, licensed, healthy,
real-time protection, definitions up to date). These are uploaded to Intune,
not shipped in the image.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Wesley van TilburgandClaude Opus 5.5