Вопрос или проблема
У меня странная проблема, и я надеюсь, что кто-нибудь сможет мне помочь.
Что я делаю:
Я создаю запланированную задачу через GPO, которая запускает скрипт Powershell, расположенный на сетевом ресурсе. Скрипт должен выполняться под учетной записью “System”. Создание проходит успешно.
Но когда я запускаю задачу, она сразу же завершает работу с кодом выхода 0x1.
Действие выглядит следующим образом:
Программа для запуска: powershell.exe
Параметр: -command “& ‘\\%ServerFQDN\Path\Scriptname.ps1.ps1’ -executionpolicy bypass”
Когда я меняю FQDN сервера на только имя сервера, без части домена, это работает. Или, когда я меняю пользователя на мою админскую учетную запись, это также работает. (С FQDN и только с именем сервера)
Итак, мое первое предположение было: это должно быть связано с Kerberos. Имя сервера возвращается к NTLM, и локальная системная учетная запись имеет некоторые проблемы с Kerberos.
Поэтому я хотел углубиться и получить подробную ошибку. Итак, я создал локальный обертка-скрипт, который вызывает подскрипт на сети с FQDN в пути.
И что я могу сказать: это сработало…
Краткий итог:
FQDN / Системная Учетная Запись –> Не работает
Имя сервера / Системная Учетная Запись –> Работает
Файл на локальной файловой системе / Системная Учетная Запись –> Работает
FQDN / Доменная Учетная Запись –> Работает
Имя сервера / Доменная Учетная Запись –> Работает
FQDN / Системная Учетная Запись / Запуск через обертка-скрипт –> Работает
Возможные решения:
Использование только имени сервера –> Не возможно, потому что мы хотим избавиться от NTLM, и я хочу, чтобы это работало в других доменах.
Использование доменной учетной записи –> Я не хочу, чтобы учетные данные кэшировались на сервере.
Использование локального скрипта обертки –> это не задумка хранения скрипта на сетевом устройстве.
Может кто-нибудь объяснить мне, почему это происходит?
################################## 10.03.25 22:45 Обновление:
В журнале Windows Powershell я нашел запись, что он не выполняет скрипт из-за политики дистанционного выполнения. Похоже, он игнорирует мой параметр ExecutionPolicy Bypass.
Я подписал скрипт и доверил сертификат, и это сработало.
Я все еще не могу объяснить, почему это работает с именем хоста вместо FQDN. Потому что одно только имя хоста не должно быть доверенным местом. Сам сервер не находится в списке доверенных зон. Но домен (включая подстановочный знак) находится.
Ответ или решение
Понимание проблемы, связанной с запуском сетевого скрипта через планировщик заданий с использованием FQDN (Fully Qualified Domain Name) от имени системного аккаунта, требует глубокого анализа. Рассмотрим вашу ситуацию, в которой скрипт, расположенный на сетевом ресурсе, запускается через планировщик заданий с использованием GPO (групповой политики). Вы сталкиваетесь с успешным выполнением при обращении по имени сервера, но сбоем при использовании FQDN. Это указывает на потенциальную проблему с аутентификацией и политикой безопасности.
Теоретическая часть
1. Аутентификация и политика безопасности:
При использовании системного аккаунта, работающего в локальной системе, доступ к сетевым ресурсам требует проверки с помощью учетных данных, которые обычно осуществляются через механизм Kerberos. Когда вы используете только имя сервера, система может использовать NTLM (хоть и устаревший механизм авторизации, но он может работать без дополнительных настроек для локальных сервисов). FQDN же требует более строгой проверки доверия, где предполагается использование Kerberos.
2. Execution Policy в PowerShell:
Execution Policy в PowerShell по умолчанию ограничивает выполнение скриптов с сетевых ресурсов из соображений безопасности. Параметр -ExecutionPolicy Bypass используется для обхода этих ограничений, но иногда политика групп или системная конфигурация может игнорировать такую инструкцию, требуя подписи скриптов как дополнительной меры безопасности.
Применение на практике
Пример:
- Системный и доменный аккаунты: Вы упомянули, что выполнение от имени доменного аккаунта работает нормально независимо от использования FQDN или имени сервера. Это указывает на то, что доменные учетные записи проходят аутентификацию по Kerberos, и они могут обойти ограничения Execution Policy, если доменная политика это позволяет.
- Локальные Wrapper скрипты: Поскольку выполнение завернутого скрипта с FQDN от имени системного аккаунта работает, это указывает на то, что проблема может быть связана либо с первоначальной проверкой прав доступа, либо с первоначальной интерпретацией параметров командной строки.
Рекомендации для разрешения проблемы:
-
Проверка конфигурации Kerberos:
- Убедитесь, что все параметры SPN (Service Principal Names) правильно настроены для сервисов, задействованных в аутентификации.
- Проверьте журналы событий и аутентификации Kerberos, чтобы выявить возможные ошибки.
-
Изменение Execution Policy:
- Если возможно, временно измените политику исполнения для вашей системы, чтобы проверить, изменится ли поведение. Используйте
Set-ExecutionPolicy RemoteSignedи убедитесь, что скрипт подписан доверенным сертификатом.
- Если возможно, временно измените политику исполнения для вашей системы, чтобы проверить, изменится ли поведение. Используйте
-
Источники доверия:
- Пересмотрите настройки Trusted Zones: хотя домен может быть добавлен в список доверенных, возможно, что системный аккаунт каким-то образом трактует доверие иначе. Проверьте и явно добавьте сетевой ресурс в список доверенных.
-
Использование альтернативных подтвержденных методов:
- Если вышеуказанные методы не дают положительного результата, рассмотрите возможность использования другого механизма для делегирования учетных данных, such as Managed Service Accounts или Group Managed Service Accounts, которые могут предоставить необходимые разрешения системному аккаунту.
Заключение
Эта проблема, связанная с исполнением скриптов по сети, подчеркивает важность понимания взаимосвязей между аутентификацией, политиками безопасности и управлением учетными данными в системах Windows. Несмотря на сложность темы, последовательный метод исследования и тестирования помогает устранить неочевидные проблемы, возникающие при управлении средой на корпоративном уровне. В конечном итоге, основное внимание должно быть уделено правильной конфигурации безопасного доступа и доверия для системных учетных записей при работе с сетевыми ресурсами.