У меня странная проблема, связанная с основными запланированными задачами Windows, которая сбивает меня с толку уже несколько недель. Эти задания не могут выполняться на некоторых серверах, но работают на других, работающих на другом оборудовании / платформах виртуальных машин. Первоначально это была проблема, которую мы заметили в одной из наших производственных систем, но мне удалось упростить ее, чтобы она работала с минимальными изменениями по сравнению с конфигурацией «из коробки». На самом деле я создал пакетный файл из 5 строк, чтобы внести минимальные изменения в чистую установку, чтобы настроить ее, чтобы убедиться, что все тестовые машины идентичны.
Конфигурация
Оборудование, которое работает
Мы создали виртуальные машины на базе VMware, XenServer, физических серверов HP и других моделей серверов Dell (Poweredge R730, R720, R430). Большинство из них используют вращающиеся диски SAS 10k / 15k, хотя один из серверов HP, которые я построил, использовал твердотельные накопители SATA в RAID 10 в качестве теста.
Оборудование, которое не работает
Однако у наших новых серверов есть проблемы. Это новые Dell Poweredge R540. У них есть встроенные контроллеры BOSS RAID 1 (в основном твердотельные накопители M.2 RAID 1) с твердотельными накопителями SAS в качестве дополнительного быстрого хранилища через контроллер PERC.
Эта проблема
На более старом оборудовании вы можете увидеть выполнение запланированной задачи, если вы запустите ее вручную, хотя, очевидно, вы не видите, что блокнот действительно открывается, если он работает от имени другого пользователя.
Однако на Poweredge R540 задача не запускается с кодом ошибки 2147943726 (0x8007052e). Я считаю, что это ошибка «неизвестное имя пользователя или неверный пароль», несмотря на то, что учетные данные верны и учетная запись пользователя была недавно создана.
Здесь вы можете увидеть историю задачи, показывающую сбой задачи
Задача не может быть запущена вручную, и в журнале событий безопасности регистрируется следующее событие безопасности:
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 12/10/2018 17:30:00
Event ID: 4625
Task Category: Logon
Level: Information
Keywords: Audit Failure
User: N/A
Computer: <computername>
Description:
An account failed to log on.
Subject:
Security ID: SYSTEM
Account Name: <computername>$
Account Domain: <domainname>
Logon ID: 0x3E7
Logon Type: 4
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: @@CyBAAA.....<this is a long Base 62 ID, so I've removed it in case it contains sensitive information>
Account Domain:
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xC000006D
Sub Status: 0xC0000064
Process Information:
Caller Process ID: 0x590
Caller Process Name: C:\Windows\System32\svchost.exe
Network Information:
Workstation Name: <computername>
Source Network Address: -
Source Port: -
Detailed Authentication Information:
Logon Process: Advapi
Authentication Package: Negotiate
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
Вчера я восстановил 2x R540, 2x виртуальных машины и 1x сервер HP, и только R540s имел эту ошибку. Это предсказуемо - мы пытались повторно визуализировать все наши тестовые машины, и каждый раз результат был одинаковым.
Другие соответствующие выводы
Я могу заставить R540 работать правильно, если они встроены непосредственно в подразделение «компьютеры» в AD, что означает, что они не получают нашу базовую политику безопасности. Задачи устанавливаются и работают отлично. Если я затем перенесу компьютерный объект в то же подразделение, что и все остальные машины, с которыми мы тестируем, задачи перестанут работать. Перемещение объекта обратно из OU в OU компьютеров не заставляет задачи снова работать. Ясно, что что-то меняется, но я не вижу, что, и не знаю, почему это повлияет только на R540 таким образом, а не на виртуальные машины или другие модели оборудования.
Мы экспортировали и сравнили локальную политику безопасности на рабочих и неработающих машинах, чтобы проверить различия. Те, которые существуют, являются второстепенными, и когда рабочий набор политик импортируется на сломанный компьютер, он остается сломанным. Точно так же импорт набора политик с неисправной машины на рабочую не нарушает работу рабочей машины.
Если я изменю запланированную задачу так, чтобы она была отмечена галочкой «Не сохранять пароль», задача все же будет запущена, но это не сработает для нас в производственной среде, поскольку задаче требуется доступ к нелокальным ресурсам.
Если я изменяю запланированную задачу для запуска в контексте учетной записи администратора моего домена (давая себе права «вход в систему как пакетный» и «вход в систему в качестве службы»), она будет работать даже при снятом флажке «Не хранить пароль». Так что все, что ломается, похоже, связано только с локальными учетными записями пользователей.
Другие вещи, которые я пробовал, но без разницы:
Вывод
думаю что-то должны быть изменены нашей групповой политикой, которая мешает этому работать - возможно, каким-то образом базовый уровень безопасности. Однако я не могу объяснить, почему это только, кажется, нарушает работу запланированных задач на определенной модели оборудования, которая должна иметь идентичные конфигурации с рабочими машинами, созданными в то же время, таким же образом. Я не понимаю, чем это могло быть вызвано.
Кто-нибудь знает, использует ли как-либо аппаратные функции запланированные задачи или базовая аутентификация безопасности? Имеет ли TPM какое-то отношение к этому? Могу ли я еще что-нибудь сделать, чтобы отследить какие вызывает сбой учетной записи пользователя в момент запуска задачи? У меня закончились идеи.
Кроме того, если кто-то спросит, я попытался выполнить «runas» из командной строки, чтобы доказать, что созданная мной локальная учетная запись пользователя работает и что пароль, который я использовал, правильный.
Спасибо!
Проблема, по всей видимости, была вызвана включением Device Guard / Credential Guard с помощью нашей базовой политики безопасности. Device Guard запускается только в том случае, если в BIOS включена безопасная загрузка, то есть мы не видели ее на виртуальных машинах или старых серверах, которые изначально не поддерживали безопасную загрузку.
Вот статья, показывающая ту же проблему:
https://support.quest.com/kb/226489/scheduled-backups-are-not-running-on-windows-server-2016
Как упоминалось в статье выше, решение состоит в том, чтобы запустить задачу от имени пользователя системы, если этого достаточно, или отключить Device Guard, если это невозможно.
Мы тестировали с отключенным Device Guard, и как только мы воссоздали нашу запланированную задачу, она успешно работала с включенной безопасной загрузкой в BIOS.
Теперь мы знаем Зачем он не работал, теперь мы можем попробовать прочитать информацию о Device Guard / Credential Guard, чтобы узнать, как это должен работать с ними, и какие лучшие практики будут продвигаться вперед.
Спасибо Грегу Аскью за его вклад, который в конечном итоге привел к этому открытию!