Один Mac ты настроишь руками за полчаса: Wi-Fi корпоративный, сертификат, запретить смену пароля раз в сто лет, выдать приложению доступ к экрану. А теперь представь пятьдесят машин. Или двести. И каждую неделю кто-то увольняется, кто-то приходит, кто-то сам залез в настройки и сломал Wi-Fi. Делать это руками - путь в ад, плюс пользователь в любой момент откатит твою настройку обратно.
Тут на сцену выходят две связанные вещи: профиль конфигурации mac (файл .mobileconfig) и MDM - система управления устройствами. Профиль - это контейнер с настройками, который накладывается поверх системы и который обычный пользователь не правит. MDM - это сервер, который раздаёт такие профили и шлёт устройствам команды по сети. В этом уроке разберём механику обоих: из чего реально состоит mobileconfig, чем установка вручную отличается от MDM, что такое Apple Business Manager и zero-touch, и в каком случае правильнее не профиль, а старый добрый defaults из предыдущих глав. И подведём к DDM - стандарту 2026 года.
Что такое .mobileconfig изнутри
Профиль конфигурации - это XML property list (тот самый plist из главы про defaults), только с расширением .mobileconfig. Структура жёсткая: на верхнем уровне один словарь с метаданными профиля, а внутри ключ PayloadContent - массив словарей-полезных нагрузок (payload). Каждый payload настраивает одну подсистему: Wi-Fi, сертификат, ограничения, доступ к приватным данным.
Метаданные профиля - это PayloadIdentifier (уникальный обратный домен, по нему система отличает профили друг от друга), PayloadUUID, PayloadType со значением Configuration, PayloadDisplayName (что увидит пользователь) и флаг PayloadRemovalDisallowed. Вот скелет с двумя payload - корпоративный Wi-Fi и запрет менять имя компьютера:
Код: Выделить всё
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadDisplayName</key><string>Corp Baseline</string>
<key>PayloadIdentifier</key><string>ru.cyberlake.baseline</string>
<key>PayloadType</key><string>Configuration</string>
<key>PayloadUUID</key><string>0E5B...A1</string>
<key>PayloadVersion</key><integer>1</integer>
<key>PayloadRemovalDisallowed</key><true/>
<key>PayloadScope</key><string>System</string>
<key>PayloadContent</key>
<array>
<dict>
<key>PayloadType</key><string>com.apple.wifi.managed</string>
<key>PayloadIdentifier</key><string>ru.cyberlake.baseline.wifi</string>
<key>PayloadUUID</key><string>9A2C...44</string>
<key>PayloadVersion</key><integer>1</integer>
<key>SSID_STR</key><string>CYBERLAKE-CORP</string>
<key>EncryptionType</key><string>WPA2</string>
<key>Password</key><string>...</string>
</dict>
</array>
</dict>
</plist>
Подписанный mobileconfig. Профиль можно (и нужно) подписать сертификатом - тогда система покажет имя организации с зелёной пометкой Verified, а не пугающее Unsigned. Подпись доказывает происхождение, а шифрование (CMS по RFC 5652) прячет содержимое - пароли Wi-Fi в открытом виде лежать не должны. После подписи XML превращается в бинарный CMS-контейнер, plutil его уже как чистый plist не прочитает.
PPPC - почему это вообще только профилем. В главах про TCC ты видел: дать приложению Доступ к экрану или Полный доступ к диску можно только кликом пользователя, и tccutil умеет только сбрасывать, но не выдавать. Так вот, payload com.apple.TCC.configuration-profile-policy - единственный легальный способ выдать TCC-разрешение заранее, без клика. Но есть жёсткое условие: PPPC-payload принимается системой только если профиль пришёл от MDM, которому устройство доверяет. Руками поставленный PPPC-профиль macOS проигнорирует. Это и есть граница между ручной установкой и MDM.
Вручную против MDM: где проходит граница
Раньше профиль ставили из терминала командой profiles -I. Забудь: начиная с macOS 11 эту лавочку прикрыли, install через CLI больше не работает и API для этого нет. Ставить вручную теперь можно ровно одним способом - дважды кликнуть по .mobileconfig (или открыть из Safari/Почты), после чего идти в Системные настройки -> Основные -> Управление устройствами (раньше это была панель Профили) и нажать Установить.
А вот смотреть установленные профили из терминала всё ещё можно, и это твой основной диагностический инструмент:
Код: Выделить всё
$ sudo profiles list -all
There are 2 configuration profiles installed
attribute: profileIdentifier: ru.cyberlake.baseline
attribute: profileIdentifier: com.apple.mdm.cyberlake.ru...
$ sudo profiles show -type configuration
Теперь ключевое различие. Поставленный вручную профиль - это разовая статичная штука: пользователь с правами админа снесёт его, обновить централизованно ты его не можешь, PPPC и FileVault-с-эскроу он не примет. Профиль от MDM - живой: сервер видит, стоит он или нет, может переустановить, обновить, удалить удалённо, и принимает привилегированные payload. Грубо: вручную - для своей одной машины или лабы, MDM - для парка.
Что такое mdm mac и протокол Apple
MDM (Mobile Device Management) - это не магия, а конкретный протокол поверх HTTPS, который Apple описала в Device Management спецификации. Схема такая. На устройстве лежит специальный MDM-профиль (com.apple.mdm payload) с адресом твоего сервера и клиентским сертификатом. Когда серверу надо что-то сделать, он не лезет на устройство напрямую - он шлёт короткий пинг через APNs (Apple Push Notification service). Устройство, получив пуш, само ходит на сервер за командой - забирает её, выполняет, отчитывается. Поэтому MDM работает и за NAT: входящих соединений к Mac не нужно, всё инициирует само устройство.
Команды устройству - это XML-плунжеры (plist): InstallProfile, RemoveProfile, DeviceInformation (отдать инвентарь - модель, серийник, версию ОС), InstallApplication, EraseDevice (удалённый стереть), DeviceLock. Сам MDM-сервер ты обычно не пишешь - берёшь готовый: Jamf Pro, Kandji, Mosyle, Microsoft Intune, SimpleMDM, open-source Fleet или MicroMDM. Все они говорят на одном протоколе Apple, отличаются интерфейсом и ценой.
Классический MDM - реактивный: сервер спрашивает - устройство отвечает, опросы по расписанию, задержки, лишний трафик. Это важная деталь, к которой мы вернёмся в финале про DDM.
Apple Business Manager и zero-touch enrollment
Ручная установка MDM-профиля - всё ещё ручная: кто-то должен кликнуть, и пользователь теоретически может отказаться или потом снести управление. Для парка это не годится. Решение - Apple Business Manager (для школ - Apple School Manager) и механизм ADE (Automated Device Enrollment), он же исторически DEP, он же zero-touch.
Идея. Mac, купленный через авторизованный канал (Apple или реселлер, привязанный к твоему ABM), Apple на своей стороне помечает как принадлежащий твоей организации - по серийному номеру. Ты в портале business.apple.com связываешь эти серийники со своим MDM-сервером. Дальше коробку можно слать сотруднику напрямую, ты её даже не распаковываешь. Сотрудник включает Mac, проходит первичную настройку, подключается к сети - и на этапе Setup Assistant устройство само идёт в ABM, узнаёт свой MDM и тихо в него заворачивается. Ноль касаний админом отсюда и zero-touch.
Два жирных бонуса ADE. Первый - supervised. Устройство, заехавшее через ADE, становится supervised (под надзором), и вот тут наконец-то по-настоящему работают жёсткие ограничения: запрет снять MDM-профиль, отключить AirDrop, заблокировать стирание контента. Тот самый PayloadRemovalDisallowed становится непробиваемым. Второй - enrollment можно сделать обязательным: пользователь не пропустит шаг управления, не отвертится. Это и отличает корпоративный Mac от личного, на котором профиль - дело добровольное.
Проверить статус enrollment на самой машине:
Код: Выделить всё
$ profiles status -type enrollment
Enrolled via DEP: Yes
MDM enrollment: Yes (User Approved)
MDM server: https://mdm.cyberlake.ru/...
Когда профиль, а когда скрипт defaults
Частый и больной вопрос для Mac-админа: управление mac профилем или скриптом с defaults из прошлых глав? Граница простая, держи её в голове.
- Профиль, когда настройку нужно навязать и удержать: пользователь не должен её менять. Профиль накладывается поверх системы как защищённый слой, многие managed-ключи становятся серыми (недоступными) в интерфейсе. Сменишь профиль - настройка вернётся к твоему значению. Сними профиль - настройка чисто откатится. Это декларативно: ты описываешь желаемое состояние, система его держит.
- defaults (и любой скрипт), когда нужно один раз проставить дефолт, который пользователю не грех потом поменять: предпочтения по умолчанию, мелкие косметические штуки. Минусы: пользователь тут же это перепишет, удаление настройки придётся писать руками (она не откатывается сама), и многое из защищённого (PPPC, FileVault-эскроу, расширения ядра) через defaults в принципе недоступно.
Типичные грабли
- PayloadRemovalDisallowed на неуправляемой машине. Поставил профиль с этим флагом вручную, думаешь - защита. Нет: на не-supervised машине профиль всё равно снимается из интерфейса управления устройством. Флаг кусается только под ADE/supervised.
- PPPC поставили вручную и удивляются, что не работает. Payload com.apple.TCC.* система принимает только от доверенного MDM. Двойной клик по такому профилю даст разрешения на TCC, которые просто не применятся.
- Дубликат PayloadIdentifier. Идентификатор - первичный ключ профиля. Поставишь второй профиль с тем же PayloadIdentifier - он перезатрёт первый, а не добавится рядом. Удобно для обновления, но легко отстрелить ногу, если идентификаторы скопипастил не думая.
- profiles -I больше нет. Гайды из интернета пятилетней давности велят ставить из терминала - на macOS 11+ и тем более на Tahoe это не работает. Только двойной клик или MDM.
- Профиль не подписан - пользователь видит Unsigned. Технически работает, но красный Unsigned пугает людей и провоцирует отказ от установки. Для любой раздачи вне MDM подписывай профиль.
- Забыл, что профиль наложен, и долго дебажишь настройку. Серая (недоступная) опция в Системных настройках почти всегда означает managed-ключ. Первым делом sudo profiles show, а не пляски с defaults.
Делай на своей машине, MDM не нужен - смотрим и читаем, ничего опасного не ставим.
- 1. Посмотри, что уже стоит: На личной машине часто пусто или один-два профиля. На рабочей увидишь MDM.
Код: Выделить всё
sudo profiles list -all - 2. Полный разбор: Найди в выводе installSource и removable у каждого профиля. Отличи mdm от ручного.
Код: Выделить всё
sudo profiles show -type configuration - 3. Проверь enrollment: Прочитай: приехала ли машина через DEP, состоит ли в MDM.
Код: Выделить всё
profiles status -type enrollment - 4. Сделай свой безобидный mobileconfig руками. Возьми скелет из урока, оставь один payload com.apple.dock или com.apple.applicationaccess, задай свой PayloadIdentifier. Прогони через чтобы убедиться, что XML валидный. Это и есть основа любого профиля - чистый, проверенный plist.
Код: Выделить всё
plutil -lint baseline.mobileconfig - 5. (Если есть доступ) загляни в business.apple.com под пробным аккаунтом и найди раздел привязки серийников к MDM. Просто посмотри логику ADE глазами.
- 1. Почему PPPC-разрешение нельзя выдать профилем, который ты поставил двойным кликом, и что для этого нужно?
- 2. Чем отличается удержание настройки профилем от проставления её через defaults - что произойдёт с настройкой, когда ты снимешь профиль, и что будет, если пользователь её поменяет?
- 3. Зачем в схеме MDM нужен APNs, если у сервера и так есть адрес устройства, - почему сервер не ходит на Mac напрямую?
- 4. Что даёт устройству заезд через ADE по сравнению с ручной установкой MDM-профиля, и при чём здесь слово supervised?
Профиль конфигурации - это подписанный plist с payload, защищённый слой настроек поверх системы, который пользователь не правит. Вручную (двойным кликом) ставится разовый профиль для своей машины; привилегированные вещи вроде PPPC и FileVault-эскроу принимает только MDM. MDM - протокол Apple поверх APNs: сервер будит устройство пушем, устройство само забирает команды. Apple Business Manager плюс ADE дают zero-touch и supervised - тогда ограничения становятся непробиваемыми, а enrollment обязательным. Политику держи профилем, преференцию - скриптом defaults. А реактивный опрос классического MDM в 2026-м постепенно вытесняет DDM (Declarative Device Management): устройство получает JSON-декларации и само проактивно держит заданное состояние, без постоянных опросов сервера - именно с DDM мы продолжим в следующих главах про управление парком.
