Сразу договоримся про термины, иначе будет каша. MDM (Mobile Device Management) - это и протокол Apple, и класс продуктов (Jamf, Mosyle, Intune). ABM - Apple Business Manager, портал, где живут твои устройства и аккаунты. ADE (Automated Device Enrollment) - механизм, благодаря которому купленный через ABM Mac знает свой MDM ещё до первого включения. DDM - новая декларативная модель поверх MDM-протокола. Дальше - по слоям.
Как вообще Mac оказывается под управлением: MDM-протокол на пальцах
Под капотом MDM - это HTTPS плюс APNs (Apple Push Notification service). Сервер не держит постоянное соединение с каждым Mac. Когда админу нужно что-то сделать, он шлёт пуш через APNs, устройство просыпается, стучится на свой MDM-сервер за командами, выполняет их и рапортует. Это классический imperative-подход: сервер диктует пошаговые команды (InstallProfile, InstallApplication, EraseDevice), а устройство их послушно исполняет.
Доверие строится на профилях конфигурации - это подписанные .mobileconfig (по сути plist). Профиль может нести что угодно: настройки Wi-Fi, сертификаты, ограничения, полезную нагрузку MDM-enrollment. Посмотреть, что навешано на твою машину, можно так:
Код: Выделить всё
profiles status -type enrollment
# Enrolled via DEP: Yes
# MDM enrollment: Yes (User Approved)
# MDM server: https://yourorg.jamfcloud.com/mdm/ServerURL
# Список всех установленных профилей (нужны права)
sudo profiles list
Zero touch для Mac: ADE и ABM, устройство настраивается само из коробки
Zero touch (он же zero-touch deployment) - это сценарий, когда ты достаёшь Mac из коробки, подключаешь к сети, и дальше он сам записывается в MDM, ставит супервизию, накатывает профили и приложения - без того, чтобы админ хоть раз к нему прикоснулся. Боль, которую это решает: представь приёмку 200 ноутбуков для нового офиса. Без zero touch это 200 раз руками. С zero touch - распаковал, раздал, дальше Setup Assistant и MDM всё доделают.
Механика такая:
- Устройство куплено через канал, привязанный к ABM (Apple/авторизованный реселлер), или добавлено вручную через Apple Configurator.
- В ABM ты назначаешь серийники на свой MDM-сервер (assignment).
- При первом включении Mac в Setup Assistant обращается к Apple-серверам активации, те говорят "твой MDM вот тут", и устройство тянет enrollment-профиль.
- Поскольку запись идёт через ADE, Mac становится supervised, а enrollment - non-removable (пользователь не снимет управление вручную).
Declarative Device Management: почему DDM в 2026 - это стандарт, а не опция
Теперь главное. Старый MDM - это imperative: сервер шлёт команды, ждёт ответа, опрашивает статус, снова шлёт. Проблема в том, что устройство пассивно. Слетела настройка между опросами - сервер узнает об этом только на следующем цикле, который мог отложиться (Mac спал, был офлайн, APNs задержал пуш). Масштабирование тоже страдает: тысячи устройств, которые надо периодически опрашивать, - это нагрузка и задержки.
Declarative Device Management переворачивает модель. Самая честная аналогия, если ты знаешь Kubernetes: imperative MDM - это kubectl exec по очереди на каждую ноду, а DDM - это reconcile loop. Сервер не диктует шаги. Он отдаёт устройству декларацию - описание желаемого состояния (declarative device management в чистом виде). Дальше устройство само:
- применяет декларацию и поддерживает это состояние локально, без участия сервера;
- следит за условиями (активациями) и реагирует асинхронно, без постоянного опроса;
- когда что-то меняется - само шлёт серверу StatusReport, а не ждёт, пока его спросят.
- Declarations (декларации) - бывают четырёх типов: configurations (что применить, аналог профиля), activations (когда/при каких условиях это включить), assets (данные, например учётка), management (метаданные сервера).
- Activations - логика "если выполнен такой-то predicate, активируй такую-то конфигурацию". Устройство вычисляет это само. Это даёт условную конфигурацию без round-trip к серверу.
- Status - устройство проактивно публикует свой статус по подписанным каналам (StatusItems). Сервер всегда видит актуальную картину, а не снимок месячной давности.
Как это выглядит на практике - управление обновлениями ОС через DDM. Ты создаёшь декларацию software update enforcement: целевая версия и дедлайн. Дальше устройство само показывает пользователю обратный отсчёт, само скачивает апдейт заранее и само ставит его к дедлайну, даже если в этот момент оно офлайн от сервера. Никакого "сервер послал команду установки и надеется". Состояние устройства можно подсмотреть локально:
Код: Выделить всё
# Текущее состояние процесса обновления, который ведёт ОС
softwareupdate --list-full-installers
mdmclient QuerySecurityInfo 2>/dev/null | head -40
# Лог демона управления - тут видно прилёт деклараций и их применение
log show --predicate 'subsystem == "com.apple.ManagedClient"' --last 1h --info
Что выбирают для парка: Jamf, Mosyle, Kandji/Iru, Intune, Addigy
Протокол один (Apple MDM + DDM), но продукты разные. Коротко по тому, кого реально берут в 2026:
- Jamf Pro - исторический лидер и самый глубокий по фичам инструмент в Apple-сегменте. Платишь за глубину самой высокой стоимостью владения и сложностью. Берут крупные парки и там, где нужна максимальная тонкость (Jamf - почти синоним корпоративного Apple-управления).
- Mosyle - Apple-специализированный игрок, который раскрутился, подрезав Jamf по цене. Чистый, надёжный продукт с хорошей автоматизацией деплоя приложений и обновлений. Популярен у малого и среднего бизнеса.
- Kandji - в октябре 2025 ребрендировался в Iru и стал шире: не только MDM, а связка identity + endpoint + EDR + vulnerability + compliance. Сильная сторона - готовые compliance-блюпринты (CIS и т.п.) и автоматическое исправление дрейфа, плюс поддержка новых ОС Apple в день релиза.
- Microsoft Intune - не Apple-специалист, а кросс-платформа (Windows, macOS, iOS, Android, Linux) с нативной завязкой на Entra ID и Defender. Часто уже оплачен в составе лицензий Microsoft 365 - и это главный аргумент. По глубине Apple-фич уступает Jamf/Iru.
- Addigy - облачное Apple-управление с реальным live-агентом (живой real-time доступ к машине) и нативной мульти-тенант архитектурой. Любят MSP, которые обслуживают много заказчиков.
Скрипты в MDM, Platform SSO и миграция без стирания
Скрипты. DDM закрывает декларативные задачи, но не всё описывается декларацией. Поэтому в любом серьёзном MDM есть запуск скриптов на устройствах - обычно zsh/bash, выполняются от root. Это твой императивный кулак: починить нестандартное, собрать инвентарь, дёрнуть конфиг приложения. Грабли тут классические для macOS: скрипт от MDM-агента не имеет твоего пользовательского окружения и контекста, а часть действий упирается в TCC (приватность) и в то, что у демона нет доступа к экрану. Простой паттерн - выполнять что-то от имени залогиненного пользователя:
Код: Выделить всё
#!/bin/zsh
# Узнаём активного пользователя консоли (не root)
loggedInUser=$(/usr/bin/stat -f%Su /dev/console)
uid=$(/usr/bin/id -u "$loggedInUser")
# Запуск команды в пользовательской сессии
launchctl asuser "$uid" sudo -u "$loggedInUser" defaults read com.apple.dock
Миграция между MDM без стирания. Раньше сменить MDM на supervised/ADE-устройстве означало wipe и переразвёртывание - то есть простой и нервы. С macOS 26 Tahoe (и iOS/iPadOS 26) Apple завезла нативную миграцию: устройство переезжает с одного MDM на другой без стирания и без участия пользователя. Условия жёсткие, держи чеклист:
- устройство уже в ABM/ASM и записано через ADE;
- ОС не ниже macOS 26 (Tahoe);
- оба MDM (старый и новый) поддерживают Apple Migration API и DDM;
- новый MDM привязан в ABM как целевой сервер, серийники переназначены на него.
Грабли, которые ловят почти всех
- Путают User-Approved и supervised. Машина записана, профиль висит, а удалённое стирание/жёсткое управление обновлениями не работает - потому что это не supervised. Лечится только через ADE/ABM, ретроспективно руками - нет (или wipe и переразвёртывание).
- Ждут от DDM мгновенного отклика как от ssh. DDM асинхронен. Декларация прилетает на следующем чек-ине или по пушу APNs, а не "прямо сейчас". Если APNs зарезан фаерволом (порт 5223), всё разваливается тихо.
- Рулят обновлениями по-старому. После апгрейда на новую мажорную ОС legacy-управление апдейтами отваливается, парк "разбредается" по версиям. Перенеси enforcement в DDM-декларации заранее.
- Скрипт работает у тебя в терминале, но падает из MDM. Нет $HOME, нет пользовательского контекста, нет TCC-разрешений. Тестируй именно как root и через launchctl asuser, а не из своей сессии.
- Закупка мимо ABM. Машины, купленные в рознице не через привязанный канал, в zero touch не попадают. Их можно затащить через Apple Configurator, но это ручная операция на каждую.
Даже на личном Mac без MDM можно потрогать механику. Сделай по шагам:
- Проверь свой статус записи: - пойми, supervised ты или нет и есть ли MDM.
Код: Выделить всё
profiles status -type enrollment - Посмотри установленные профили конфигурации: открой Системные настройки -> Основные -> Управление устройствами (если пусто - значит профилей нет, это нормально для личной машины).
- Понаблюдай за демоном управления в реальном времени: - и в соседнем окне дёрни
Код: Выделить всё
log stream --predicate 'subsystem == "com.apple.ManagedClient"' --info, смотри, что пишется в лог.Код: Выделить всё
sudo profiles list - Изучи, какие обновления видит сама ОС (это то, чем рулит DDM-enforcement на управляемой машине): и
Код: Выделить всё
softwareupdate --list.Код: Выделить всё
softwareupdate --list-full-installers - Если есть тестовый Mac - заведи триал любого Apple-MDM (Mosyle/Jamf дают пробные), запиши машину вручную и найди в его консоли раздел Declarations/Software Updates. Создай декларацию обновления с дедлайном и посмотри, как ОС начинает показывать обратный отсчёт.
- Чем декларативное управление (DDM) принципиально отличается от классических MDM-команд, и почему аналогия с reconcile-циклом Kubernetes уместна?
- Почему zero touch для Mac невозможен без ADE и ABM, и какой статус устройство получает именно благодаря ADE?
- Какие четыре условия должны совпасть, чтобы выполнить миграцию между MDM на macOS 26 без стирания?
- Почему откладывание перехода на DDM-управление обновлениями опасно при апгрейде парка на новую мажорную ОС?
Управление парком Mac в 2026 - это сдвиг от "сервер командует, устройство ждёт" к "сервер декларирует, устройство держит состояние само". ADE и ABM дают zero touch и супервизию, без которых ничего серьёзного не работает. DDM стал стандартом не на словах: на нём держатся обновления ОС, статусы и бесшовная миграция без стирания, а legacy-механизмы Apple убирает. Вендоры (Jamf, Mosyle, Kandji/Iru, Intune, Addigy) различаются глубиной и ценой, но единый вопрос к любому из них - насколько хорошо поддержан declarative device management. Ответишь на этот вопрос правильно при выборе - и парк будет управляться сам, а не тобой ногами.
