Управление узлами Windows с помощью Ansible

PSRP и WinRM

Исторически Ansible использовал Windows Remote Management (WinRM) в качестве протокола подключения для управления узлами Windows. Плагины подключения psrp и winrm работают через WinRM, и их можно использовать для подключения к узлам Windows. Плагин подключения psrp новее и обладает рядом преимуществ по сравнению с плагином подключения winrm, например:

• Может работать немного быстрее
• Меньше подвержен проблемам с тайм-аутами при высокой нагрузке на узел Windows
• Лучше поддерживает прокси-серверы

Подробнее о настройке WinRM и использовании плагинов подключения psrp и winrm в Ansible см. в разделе Удалённое управление Windows.

SSH

SSH — это традиционный плагин подключения для узлов POSIX, однако его также можно использовать для управления узлами Windows вместо традиционных плагинов подключения psrp или winrm.

Некоторые преимущества SSH по сравнению с транспортами на основе WinRM:

• SSH проще настроить в средах без домена
• SSH поддерживает аутентификацию на основе ключей, которой проще управлять, чем сертификатами
• Передача файлов по SSH быстрее, чем по WinRM

Подробнее о настройке SSH для узлов Windows см. в разделе SSH в Windows.

Команда работает локально, но не в Ansible

Ansible выполняет команды через сетевой вход в систему, который может изменить способ авторизации действий в Windows. Из-за этого команды, работающие локально, могут завершаться ошибкой при выполнении через Ansible. Вот несколько примеров таких ошибок:

• процесс не может передать учётные данные пользователя сетевому ресурсу, что приводит к ошибкам Access is  Denied или Resource Unavailable
• приложениям, которым требуется интерактивный сеанс, не удастся работать
• доступ к некоторым API Windows ограничен при выполнении команд через сетевой вход в систему
• для некоторых задач требуется доступ к хранилищу секретов DPAPI, которое обычно недоступно при сетевом входе в систему

Обычно для выполнения команды с явными учётными данными используют Повышение привилегий: become. Использование become в Windows переключает сетевой вход в систему на интерактивный. Если для идентификатора become указаны явные учётные данные, команда сможет обращаться к сетевым ресурсам и разблокировать хранилище DPAPI.

Другой вариант — использовать параметр аутентификации в плагине подключения, который позволяет делегировать учётные данные. Для SSH это можно сделать с помощью явного указания имени пользователя и пароля либо с помощью входа Kerberos/GSSAPI с включённым делегированием. Для подключений на основе WinRM можно использовать CredSSP или Kerberos с делегированием. Дополнительные сведения см. в документации к соответствующему плагину подключения.

Учётные данные отклоняются

Есть несколько причин, по которым учётные данные могут быть отклонены при подключении к узлу Windows. Вот некоторые из них:

• неверное имя пользователя или пароль
• учётная запись пользователя заблокирована, отключена или ей запрещён вход на этот сервер
• учётной записи пользователя запрещён вход через сеть
• учётная запись пользователя не входит в локальную группу «Администраторы»
• учётная запись пользователя является локальной, а параметр LocalAccountTokenFilterPolicy не задан

Чтобы проверить правильность учётных данных или наличие у пользователя разрешения на вход на узел, выполните на узле Windows приведённую ниже команду PowerShell, чтобы просмотреть последнюю неудачную попытку входа. Будут выведены сведения о событии, включая код ошибки Status и Sub Status, указывающий причину сбоя входа.

Get-WinEvent -FilterHashtable @{LogName = 'Security'; Id = 4625} |
    Select-Object -First 1 -ExpandProperty Message

Не все плагины подключения требуют, чтобы пользователь, от имени которого выполняется подключение, входил в локальную группу «Администраторы», однако обычно это настройка по умолчанию. Если пользователь не входит в локальную группу «Администраторы» или является локальным пользователем, для которого не задан параметр LocalAccountTokenFilterPolicy, аутентификация завершится ошибкой.