Включили MFA в Veeam 13 — и PowerShell-отчёты замолчали: как завести сервисную учётку

Классическая история после аудита ИБ: включили в Veeam многофакторную аутентификацию, консоль честно спрашивает шестизначный код, все довольны. А через неделю выясняется, что задание по базе 1С на SQL падает уже шестые сутки — просто отчёт о бэкапах перестал приходить, и этого никто не заметил. Ниже — почему PowerShell в Veeam 13 принципиально не умеет работать с MFA, как правильно завести служебную учётку, чем это опасно и что я делаю, чтобы «тишина» больше никогда не выглядела как «всё хорошо».

Симптом: консоль пускает, а скрипт — нет

Выглядит это так. Вы включили MFA, зашли в консоль Veeam Backup & Replication, ввели одноразовый код из мобильного аутентификатора, всё работает. Проверили под вторым администратором — работает. Разошлись. На следующее утро в почте нет привычного отчёта о заданиях. Лезете в планировщик задач на бэкап-сервере: задача отработала, время выполнения — полторы секунды вместо обычных сорока, код возврата 1. В транскрипте одна строка:

Connect-VBRServer : Unable to connect to the server with MFA-enabled user account.

Первая реакция — «сломали при обновлении» или «учётку заблокировали». Ни то, ни другое. Это задокументированное поведение. В пользовательском руководстве Veeam Backup & Replication 13, раздел Multi-Factor Authentication, написано прямым текстом: MFA is not supported for PowerShell (either interactive logon or non-interactive connections). Обратите внимание на «either interactive logon» — это значит, что даже если вы сядете за консоль руками, введёте код и оттуда запустите PowerShell, Connect-VBRServer всё равно откажет. Дело не в том, что скрипту негде взять OTP. Дело в том, что MFA в Veeam рассчитана на две точки входа людей — удалённую консоль и web UI, — а неинтерактивные подключения и PowerShell под учёткой с включённой MFA получают отказ. Исключение одно: Veeam Explorers, запущенные из уже авторизованной консоли, повторного кода не просят, но на модуль Veeam Backup PowerShell это исключение прямо не распространяется.

И PowerShell тут не одинок. Вместе с ним по той же причине отваливается целый список компонентов, которые ходят на бэкап-сервер неинтерактивно. Ниже — перечень из раздела Requirements and Considerations руководства пользователя; для каждого пункта нужна учётка с отключённой MFA.

• Veeam Backup & Replication REST API — любые неинтерактивные подключения;
• Veeam Backup Enterprise Manager — в части связи с самим backup-сервером (нативно MFA для EM не поддерживается вообще, только через сторонний IdP в настройках SAML);
• агент Veeam ONE — связь с backup-сервером;
• Veeam Backup Validator;
• восстановление конфигурационной базы: консоль VBR или Veeam Backup Configuration Restore нужно запускать под учёткой с отключённой MFA;
• сценарий сервис-провайдера с Veeam Service Provider Console — на SP-сервере тоже требуется service account.

Как это выглядит в жизни: полиграфический центр на 23 рабочих места

Расскажу про стенд, который разбирали недавно. Условно — полиграфический центр «Цветной тираж», 23 рабочих места: менеджеры заказов, препресс, печатный цех, бухгалтерия. Небольшой серверный шкаф в подсобке, два хоста ESXi, 12 виртуалок — контроллер домена, файловый сервер с макетами, 1С на SQL Server, сервер цветопроб и RIP. Veeam Backup & Replication 13.1 на Windows Server 2022, основной репозиторий — hardened Linux с immutability, вторая копия уезжает на NAS. Резервное копирование настроено нормально, к нему претензий не было.

Обвязка тоже была нормальной. На бэкап-сервере лежал скрипт report-backup.ps1, задача в планировщике каждый день в 07:40 под доменной учёткой CORP\svc_veeamrep. Скрипт подключался к серверу, забирал состояние заданий за сутки, собирал табличку и отправлял её письмом директору, главбуху и приходящему администратору, а дублем — в Telegram. Работало это без единого сбоя больше двух лет, пережило даже переезд с 12-й версии.

11 августа по требованию страховой компании, которая страхует типографию, провели проверку ИБ, по итогам — предписание включить двухфакторку везде, где она есть. Включили MFA в Veeam: Users & Roles → Security → убрали из списка доменную группу, добавили трёх администраторов поимённо → галка Enable multi-factor authentication (MFA) → OK. Проверили вход под всеми тремя учётками, коды из аутентификатора принимаются. Задача закрыта, галочка в отчёте поставлена.

Отчёт перестал приходить уже на следующее утро. Заметили это 20 августа — случайно, когда бухгалтерия попросила восстановить удалённую накануне обработку в 1С. Оказалось, что задание по виртуалке с базой 1С падает с 14 августа: сорвался квиесцинг через VSS внутри гостевой ОС, ошибка воспроизводилась каждую ночь. Классически это ловится за одно утро — приходит отчёт, в нём красная строка, админ идёт разбираться. Здесь отчёта не было девять дней, и реальный RPO по базе, где живут все заказы и расчёты с клиентами типографии, тихо уехал с суток до шести. Резервные копии при этом лежали в репозитории и выглядели свежими: последняя удачная точка была от 13-го, а глазами в консоль никто не смотрел, потому что «отчёт же настроен».

Диагностика заняла минут двадцать. В планировщике — Last Run Result 0x1, включили транскрипт (Start-Transcript) в начале скрипта, прогнали задачу руками, получили ту самую строку про MFA-enabled user account. Дальше уже понятно. Учётку CORP\svc_veeamrep пометили как service account, отчёт поехал с первого же запуска. Сама починка — четыре минуты. Шесть суток без свежей копии базы 1С, где у типографии заказы на полмесяца вперёд, — вот это дорого: восстанавливать пришлось бы из точки 13-го и вбивать заказы руками по почте клиентов.

• 11.08 — включена MFA, три администратора внесены в Users & Roles поимённо, группа удалена;
• 12.08, 07:40 — задача report-backup.ps1 завершается с кодом 0x1, письмо не уходит;
• 14.08 — первое ночное падение задания по ВМ с 1С (ошибка VSS в гостевой ОС), отчёта нет;
• 20.08 — проблема обнаружена при просьбе о восстановлении, найдена причина в транскрипте;
• 20.08 — служебная учётка помечена как service account, задание по 1С починено, внеплановый активный фулл сделан в тот же день.

Правильное решение: отдельная сервисная учётка, а не «временно сниму с себя»

KB4535 предлагает два варианта: либо запускать PowerShell под выделенной служебной учёткой без MFA, либо временно пометить свою собственную учётку как service account, выполнить команды и снять отметку обратно. Второй вариант годится ровно для одного случая — когда вам прямо сейчас, руками, надо выполнить пару cmdlet и вы никуда не уходите от клавиатуры. Для постоянной автоматизации он не годится вообще: «снять обратно» забудут в первый же раз, и вы получите администратора домена с постоянно выключенной двухфакторкой, о чём никто не будет знать.

Я делаю так: на каждую неинтерактивную интеграцию — своя учётная запись. Отчёты — одна, мониторинг через REST API — вторая, Veeam ONE — третья. Не одна общая «svc_veeam на всё», а именно по одной на потребителя. Это не паранойя: когда у вас три отдельные учётки, вы в любой момент можете отозвать одну, не уронив остальные две, и по журналу видно, кто именно ходил.

Сама процедура в Veeam 13 короткая и описана в руководстве в разделе Disabling MFA for Service Accounts. Учётка должна быть уже заведена в Users & Roles — если её там нет, сначала добавьте её с нужной ролью, а уже потом ставьте отметку. Учтите: когда MFA включена, перед любым изменением в Users and Roles консоль сама попросит подтвердить личность одноразовым кодом — держите телефон под рукой.

1. Открыть консоль Veeam под учётной записью с ролью Backup Administrator
2. Меню → Users & Roles → вкладка Security
3. Выбрать нужную учётную запись → Edit
4. Поставить галку:
   [x] This is a service account (disables two-factor authentication)
5. OK  (закрыть окно Edit User)
6. OK  (закрыть окно Users & Roles)

Шестой шаг — это не формальность, а именно то место, где чаще всего спотыкаются. В KB4535 прямо сказано: пока оба окна — Edit User и Users & Roles — не закрыты кнопкой OK, MFA для учётки не отключается. Человек ставит галку, жмёт OK в карточке пользователя, потом закрывает Users & Roles крестиком или Cancel, идёт проверять скрипт — и получает ту же ошибку. После чего делает вывод, что «отметка не помогает», и начинает выключать MFA целиком. Приятная деталь оттуда же: окно PowerShell, открытое до изменения, переоткрывать не нужно.

Ещё пара ограничений из мануала, о которые легко удариться. Первое: MFA включается только для отдельных пользователей, группы не поддерживаются — при включении функции вас попросят убрать группы из списка Users & Roles и оставить только конкретные учётные записи. Если у вас доступ в Veeam роздан через доменную группу «Администраторы Veeam» (а так почти у всех), включение MFA потребует сначала перебрать список руками. Второе: управлять MFA может только пользователь с ролью Backup Administrator. Третье: в Community Edition MFA нет вовсе. И четвёртое, о котором вспоминают постфактум: если при включённой MFA перевыпустить сертификат бэкап-сервера, все подключённые консоли Veeam нужно перезапустить, иначе начнутся ошибки подключения.

• учётка скрипта добавлена в Users & Roles поимённо, а не через доменную группу — группы при включённой MFA не поддерживаются;
• отметка This is a service account (disables two-factor authentication) стоит именно на ней, а не на личной учётке администратора;
• оба окна — Edit User и Users & Roles — закрыты кнопкой OK;
• в журнале изменений записано, кто и когда поставил отметку и зачем;
• задача планировщика прогнана вручную, код возврата 0x0, отчёт дошёл.

Права и риск: чем компенсировать дырку, которую вы сами сделали

Давайте называть вещи своими именами. Сервисная учётка с отметкой service account — это учётная запись, для которой вы намеренно отключили второй фактор. Если её пароль утечёт, MFA вас не спасёт, и весь смысл предписания пропадает. А в 13-й версии всё ещё неприятнее, чем хочется: урезать такой учётке права ролью не получится.

В документации Veeam PowerShell Reference 13 (разделы про запуск сессий на Windows и Linux) прямо сказано: для выполнения cmdlet Veeam Backup PowerShell нужна роль Backup Administrator. То есть совет «дайте отчётной учётке роль только на просмотр» для PowerShell в 13.1 не работает — скрипт под Backup Viewer до данных не доберётся. Честно говоря, раньше я сам пытался резать права ролью; сейчас исхожу из того, что учётка скрипта — это полноценный администратор бэкапа без второго фактора, и защищаю её всем остальным. Если автоматизации достаточно только чтения, присмотритесь к REST API: там роли назначаются иначе, и это стоит проверить на своём билде по REST API Reference, прежде чем закладываться.

Раз роль урезать нельзя, компенсируем окружением. Ниже — минимальный набор мер, который я ставлю каждой такой учётке, без исключений.

Отдельно про соблазн переиспользовать уже существующую учётку. У многих на бэкап-сервере живёт учётная запись, под которой работает служба Veeam Backup Service, или учётка, которой Veeam ходит в vCenter и в гостевые ОС. Не надо вешать на неё ещё и автоматизацию отчётов. Это разные роли с разным сроком жизни пароля и разной зоной поражения при компрометации: учётка гостевой обработки видит внутренности всех ваших виртуалок, включая базу 1С и архив макетов. Смешаете — получите одну учётку, которая может всё, и её пароль будет лежать в трёх местах сразу.

И ещё одна вещь, которую я прошу заказчиков зафиксировать письменно: список служебных учёток Veeam с отметкой service account должен лежать в том же документе, где у вас описана схема резервного копирования. Не в голове администратора и не в переписке. Через год, когда придёт следующий аудит или сменится человек, вопрос «а почему у этих двух учёток отключена двухфакторка» должен иметь готовый ответ с датой, обоснованием и фамилией того, кто это согласовал. Иначе вас заставят выключить отметку — и всё сломается снова, только уже без понимания, почему.

• пароль — 24+ символа из генератора, лежит в парольном менеджере, а не в теле скрипта и не в комментарии к задаче;
• учётке запрещён интерактивный и RDP-вход куда-либо, кроме бэкап-сервера (Deny log on locally / Deny log on through Remote Desktop Services в групповой политике для всех остальных компьютеров), а на самом бэкап-сервере ей оставлено только право входа как пакетного задания;
• учётка не входит ни в одну административную группу домена — ни в Domain Admins, ни в локальные администраторы бэкап-сервера: роль Backup Administrator в Veeam и права администратора Windows — разные вещи;
• ротация пароля по календарю, а не «когда вспомним»: раз в полгода, с записью в журнал изменений;
• раз в квартал — глазами открыть Users & Roles и проверить, что учёток с отметкой service account ровно столько, сколько вы заводили, и ни одной лишней (в первую очередь — что там нет чьей-то личной админской, помеченной «на пять минут» полгода назад).
• на входы этой учётки в консоль Veeam стоит алерт: скрипт никогда не ходит через GUI, поэтому любой интерактивный вход под ней — повод немедленно разбираться.

Запуск: где ломается уже сам скрипт, а не MFA

Допустим, учётку вы завели и отметили. Дальше начинается вторая серия граблей — уже не про MFA, а про то, как именно скрипт запускается. Разберу по порядку то, что встречается чаще всего.

Планировщик задач. Задача должна стоять на «Run whether user is logged on or not» и запускаться от вашей служебной учётки — тогда пароль хранится в системном хранилище, а не в открытом виде. И главное изменение 13-й версии: модуль Veeam PowerShell требует PowerShell 7 (в Global Changes v13 это названо минимальной версией, а страница про запуск на Windows для билда 13.1.1.18 указывает 7.6.3). Если в действии задачи со времён 12-й версии осталось powershell.exe — это Windows PowerShell 5.1, и модуль там не загрузится. Действие должно запускать pwsh.exe. Отдельно предупреждение из KB4535, которое я считаю недооценённым: часть скриптов некорректно отрабатывает при запуске через «Run as different user». Если вы отлаживаете скрипт через «Запуск от имени другого пользователя», а он ведёт себя иначе, чем из планировщика, — это описанное поведение. Отлаживайте так же, как оно будет работать в бою.

# действие задачи планировщика (Program/script и Arguments)
"C:\Program Files\PowerShell\7\pwsh.exe" -NoProfile -NonInteractive -ExecutionPolicy RemoteSigned -File C:\Scripts\report-backup.ps1

# проверить, что модуль виден именно в pwsh
pwsh -NoProfile -Command "Get-Module -Name Veeam.Backup.PowerShell -ListAvailable"

Политика выполнения. Свежепоставленный Windows Server по умолчанию не даст запустить .ps1. Ставим RemoteSigned — локальные скрипты идут без подписи, скачанные из интернета требуют доверенной подписи. Это разумный компромисс, Unrestricted на бэкап-сервере ставить не надо. Имейте в виду, что у PowerShell 7 своя настройка политики, независимая от Windows PowerShell 5.1, поэтому команду выполняем именно в pwsh, из-под администратора:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine
Get-ExecutionPolicy -List

Порт подключения. Вот это неочевидная штука для тех, кто приехал с двенадцатой ветки. В документации по Connect-VBRServer для версии 13 параметр Port описан со значением по умолчанию 443, тогда как в 12-й версии консоль и PowerShell подключались к серверу по 9392. Если в старых скриптах жёстко прописан -Port 9392 или межсетевой экран между машиной со скриптом и бэкап-сервером настроен под старую схему, подключение будет отваливаться уже по другой причине, и вы полдня будете думать на MFA. Проверьте это до того, как начнёте ломать голову.

Учётные данные. Connect-VBRServer принимает либо пару -User/-Password, либо объект PSCredential через -Credential. Имя пользователя — строго в формате DOMAIN\Username или UPN. И отдельно, важное: для PowerShell поддерживаются только локальные и доменные учётные записи, учётки с аутентификацией через SAML не поддерживаются. Если вы завели вход в Veeam через корпоративный IdP и думаете автоматизировать под такой учёткой — не выйдет, нужна обычная доменная. Ещё один параметр, полезный после смены сертификата: -ForceAcceptTlsCertificate заставляет cmdlet принять TLS-сертификат бэкап-сервера — но ставить его в боевой скрипт навсегда я бы не стал, это отключение проверки.

# пароль кладём один раз, из-под ТОЙ ЖЕ учётки и на ТОЙ ЖЕ машине,
# где потом будет работать задача планировщика — иначе DPAPI не расшифрует
Get-Credential | Export-Clixml -Path 'C:\Scripts\svc_veeamrep.cred'

# в самом скрипте
Import-Module Veeam.Backup.PowerShell -ErrorAction Stop
$cred = Import-Clixml -Path 'C:\Scripts\svc_veeamrep.cred'
Connect-VBRServer -Server 'vbr01.corp.local' -Port 443 -Credential $cred

try {
    $jobs = Get-VBRJob | Sort-Object Name
    # ...сборка отчёта...
}
finally {
    Disconnect-VBRServer
}

Про Export-Clixml скажу отдельно, потому что тут регулярно наступают. Шифрование завязано на DPAPI конкретного пользователя конкретной машины. Сгенерировали файл под своей учёткой — задача под svc_veeamrep его не прочитает и упадёт с «Ключ не соответствует». Генерировать надо из сеанса той самой служебной учётки на том самом сервере. Если хочется красивее — есть модуль Microsoft.PowerShell.SecretManagement с SecretStore, но для одного сервера и одного скрипта это, на мой взгляд, лишний слой. И последнее: Disconnect-VBRServer в блоке finally — не украшение. Внутри одной сессии PowerShell можно быть подключённым только к одному серверу Veeam, и висящие сессии рано или поздно начнут мешать.

• в действии задачи — `pwsh.exe` (PowerShell 7), а не `powershell.exe`;
• `Get-Module -Name Veeam.Backup.PowerShell -ListAvailable` в pwsh возвращает модуль;
• в скриптах нет жёстко прописанного порта 9392, либо он осознанно заменён на 443;
• имя пользователя в формате DOMAIN\Username или UPN, учётка не SAML;
• файл с учётными данными создан из-под служебной учётки на том же сервере;
• `Disconnect-VBRServer` вызывается в `finally`, транскрипт пишется в лог с ротацией.

Чек-лист перед включением MFA: не только PowerShell

Сценарий «включили MFA — сломался ровно один скрипт» встречается редко. Обычно ломается несколько вещей сразу, просто замечают их в разное время: отчёт — на следующий день, мониторинг — через неделю, а восстановление конфигурационной базы — в самый неподходящий момент, когда сервер уже лежит. Поэтому у меня перед включением MFA есть короткий обход по хозяйству.

Порядок такой: сначала инвентаризация всего, что ходит на бэкап-сервер без человека, потом заведение служебных учёток с отметкой service account под каждый пункт, и только потом — сама галка MFA. Именно в этом порядке, а не наоборот. Мой список обхода приведён ниже; в небольшой компании вроде типографии на два десятка мест он обычно укладывается в полчаса.

Практический совет по самому включению. Не делайте это в пятницу вечером и не делайте разом на всех серверах, если у вас их несколько. Возьмите один бэкап-сервер, включите MFA на нём, дождитесь полного суточного цикла — ночные задания, утренний отчёт, дневные проверки мониторинга — и только потом повторяйте на остальных. Сутки задержки ничего не стоят, а вот одновременно ослепшая обвязка на трёх площадках — это уже неприятный разговор с руководством.

Есть и приятные мелочи, о которых стоит знать заранее. MFA в Veeam совместима с любыми мобильными аутентификаторами, поддерживающими RFC 4226 и RFC 6238, то есть подойдёт что угодно из привычного. Push-уведомлений нет — код только руками из приложения. После более чем пяти неудачных попыток нужно заново открыть консоль и подождать не меньше минуты; если администратор потерял телефон, второй администратор с ролью Backup Administrator сбрасывает ему MFA кнопкой Reset MFA в том же разделе Security. Если же проблемы с MFA у всех администраторов разом, по документации остаётся только обращение в поддержку Veeam — поэтому администраторов с MFA должно быть минимум двое. И критично важное: коды завязаны на время — если часы бэкап-сервера разъедутся с UTC, аутентификация начнёт валиться у всех сразу, поэтому синхронизация времени на сервере из желательной превращается в обязательную.

Что изменилось в 13-й версии применительно к MFA, если судить по руководству пользователя. Второй фактор теперь спрашивается при входе и в удалённую консоль, и в web UI. Для Linux-based бэкап-сервера (Veeam Software Appliance) учётки, у которых есть доступ и к консоли Veeam Host Management, и к консоли/web UI, не требуют отдельных записей в аутентификаторе. Модуль PowerShell на Linux ставится отдельным пакетом, но ограничение по MFA для PowerShell действует и там. А на самом апплаенсе модули Veeam PowerShell недоступны для pre-job и post-job скриптов — если планировали переносить такие скрипты с Windows-сервера, закладывайте переделку.

• скрипты в планировщике на самом бэкап-сервере и на соседних серверах — почтовые отчёты, выгрузки в Zabbix, самописные проверки точек восстановления;
• всё, что дёргает REST API Veeam Backup & Replication — сборщики метрик, дашборды, интеграции с helpdesk;
• Veeam Backup Enterprise Manager, если он развёрнут: нативно MFA для EM не поддерживается, а его связь с backup-сервером идёт под конкретной учёткой — её надо пометить как служебную; сам вход в EM при желании закрывается сторонним IdP через SAML;
• агент Veeam ONE — та же история со связью с backup-сервером;
• Veeam Backup Validator, если вы им проверяете целостность копий по расписанию;
• учётная запись, под которой вы будете восстанавливать конфигурационную базу VBR — про неё забывают чаще всего, а вспоминают в аварии;
• Veeam Service Provider Console — если вы сервис-провайдер или вас подключил провайдер.

Главный вывод: молчание — не признак здоровья

История «Цветного тиража» в технической части тривиальна: галка не там, четыре минуты на исправление. Дорого в ней другое — то, что девять дней отсутствия отчёта прошли незамеченными. Схема мониторинга, в которой признаком проблемы является приход письма, ломается в момент, когда ломается сама доставка письма. И ломается тихо.

Лечится это одной идеей: отслеживать надо не появление плохой новости, а исчезновение хорошей. В простом виде — heartbeat: скрипт после успешной отправки отчёта дёргает URL или пишет метрику, а на стороне мониторинга стоит триггер «не было сигнала больше 26 часов». В Zabbix это элемент с nodata, в healthchecks-подобных сервисах — готовая функция «dead man's switch». Реализация любая, важен принцип: тишина обязана превращаться в алерт.

Второе, что я обязательно делаю после таких инцидентов, — прописываю в отчёт явные цифры. Не «ошибок нет», а «проверено 9 заданий, последняя успешная точка по каждому — не старше 26 часов, суммарный объём за сутки 186 ГБ». Отчёт, в котором есть числа, читают. Отчёт с зелёной надписью «OK» перестают открывать на второй неделе, и он превращается в шум, который не спасает даже когда доходит.

И третье, уже про сам Veeam: после любого изменения в аутентификации — включили MFA, поменяли роль, обновили билд — прогоните боевые скрипты руками в тот же день. Не «оно же работало вчера», а буквально запустите задачу из планировщика кнопкой Run и посмотрите на код возврата. Это две минуты. Мой опыт говорит, что именно эти две минуты отделяют «поправили за четыре минуты» от «шесть суток без свежей копии базы 1С».

• heartbeat после успешной отправки отчёта и триггер на отсутствие сигнала дольше 26 часов;
• в отчёте — число проверенных заданий и возраст последней успешной точки по каждому;
• транскрипт скрипта в файл с ротацией, чтобы причину сбоя было видно без повторного запуска;
• после любого изменения аутентификации или обновления билда — ручной запуск задачи и проверка кода возврата;
• раз в месяц — пробное восстановление одной ВМ или базы, а не только чтение отчёта.

Частые вопросы