Удаленное управление Windows

В отличие от хостов Linux/Unix, которые по умолчанию используют SSH, хосты Windows настраиваются с помощью WinRM. Эта тема описывает, как настроить и использовать WinRM с Ansible.

• Что такое WinRM?
• Параметры аутентификации
  • Базовая
  • Сертификат
    • Генерация сертификата
    • Импорт сертификата в хранилище сертификатов
    • Сопоставление сертификата с учетной записью
  • NTLM
  • Kerberos
    • Установка библиотеки Kerberos
    • Настройка Kerberos для хоста
    • Автоматическое управление билетами Kerberos
    • Ручное управление билетами Kerberos
    • Устранение неполадок с Kerberos
  • CredSSP
    • Установка библиотеки CredSSP
    • CredSSP и TLS 1.2
    • Установить сертификат CredSSP
• Учетные записи без прав администратора
• Шифрование WinRM
• Параметры инвентаризации
• IPv6-адреса
• Валидация сертификатов HTTPS
• Ограничения

Что такое WinRM?

WinRM — это протокол управления, используемый Windows для удаленного взаимодействия с другим сервером. Это протокол на основе SOAP, который работает по HTTP/HTTPS и входит во все современные версии операционных систем Windows. Начиная с Windows Server 2012, WinRM включен по умолчанию, но в большинстве случаев для использования WinRM с Ansible требуется дополнительная настройка.

Ansible использует пакет pywinrm для взаимодействия с серверами Windows через WinRM. Он не устанавливается по умолчанию с пакетом Ansible, но может быть установлен, выполнив следующее:

pip install "pywinrm>=0.3.0"

Параметры аутентификации

При подключении к хосту Windows можно использовать несколько различных параметров при аутентификации с учетной записью. Тип аутентификации можно задать для хостов или групп инвентаризации с помощью переменной ansible_winrm_transport.

В следующей матрице представлен обзор параметров:

Базовая

Базовая аутентификация — один из самых простых способов аутентификации, но также и самый небезопасный. Это связано с тем, что имя пользователя и пароль просто кодируются в base64, а если безопасный канал не используется (например, HTTPS), то их может расшифровать любой. Базовая аутентификация может быть использована только для локальных учетных записей (не для учетных записей домена).

Следующий пример демонстрирует настройка переменных хоста для базовой аутентификации:

ansible_user: LocalUsername
ansible_password: Password
ansible_connection: winrm
ansible_winrm_transport: basic

Базовая аутентификация по умолчанию на хосте Windows не включена, но может быть включена, выполнив следующую команду в PowerShell:

Set-Item -Path WSMan:\localhost\Service\Auth\Basic -Value $true

Сертификат

Аутентификация по сертификату использует сертификаты как ключи, аналогично парам ключей SSH, но формат файла и процесс генерации ключей отличается.

Следующий пример демонстрирует настройка переменных хоста для аутентификации по сертификату:

ansible_connection: winrm
ansible_winrm_cert_pem: /path/to/certificate/public/key.pem
ansible_winrm_cert_key_pem: /path/to/certificate/private/key.pem
ansible_winrm_transport: certificate

Аутентификация по сертификату по умолчанию на хосте Windows не включена, но может быть включена, выполнив следующую команду в PowerShell:

Set-Item -Path WSMan:\localhost\Service\Auth\Certificate -Value $true

Генерация сертификата

Сертификат необходимо сгенерировать перед его сопоставлением с локальным пользователем. Это можно сделать одним из следующих способов:

• OpenSSL
• PowerShell, используя командлет New-SelfSignedCertificate
• Услуги сертификации Active Directory

Услуги сертификации Active Directory выходят за рамки данной документации, но могут быть лучшим вариантом при работе в среде домена. Более подробную информацию можно найти в документации по Услугам сертификации Active Directory.

Для генерации сертификата с помощью OpenSSL:

# set the name of the local user that will have the key mapped to
USERNAME="username"

cat > openssl.conf << EOL
distinguished_name = req_distinguished_name
[req_distinguished_name]
[v3_req_client]
extendedKeyUsage = clientAuth
subjectAltName = otherName:1.3.6.1.4.1.311.20.2.3;UTF8:$USERNAME@localhost
EOL

export OPENSSL_CONF=openssl.conf
openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -out cert.pem -outform PEM -keyout cert_key.pem -subj "/CN=$USERNAME" -extensions v3_req_client
rm openssl.conf

Для генерации сертификата с помощью New-SelfSignedCertificate:

# set the name of the local user that will have the key mapped
$username = "username"
$output_path = "C:\temp"

# instead of generating a file, the cert will be added to the personal
# LocalComputer folder in the certificate store
$cert = New-SelfSignedCertificate -Type Custom `
    -Subject "CN=$username" `
    -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2","2.5.29.17={text}upn=$username@localhost") `
    -KeyUsage DigitalSignature,KeyEncipherment `
    -KeyAlgorithm RSA `
    -KeyLength 2048

# export the public key
$pem_output = @()
$pem_output += "-----BEGIN CERTIFICATE-----"
$pem_output += [System.Convert]::ToBase64String($cert.RawData) -replace ".{64}", "$&`n"
$pem_output += "-----END CERTIFICATE-----"
[System.IO.File]::WriteAllLines("$output_path\cert.pem", $pem_output)

# export the private key in a PFX file
[System.IO.File]::WriteAllBytes("$output_path\cert.pfx", $cert.Export("Pfx"))

Импорт сертификата в хранилище сертификатов

После генерации сертификата необходимо импортировать сертификат в Trusted Root Certificate Authorities хранилища LocalMachine, а общедоступный ключ клиентского сертификата должен быть в папке Trusted People хранилища LocalMachine. В этом примере и сертификат, и открытый ключ — одинаковые.

Следующий пример показывает, как импортировать сертификат:

$cert = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Certificate2
$cert.Import("cert.pem")

$store_name = [System.Security.Cryptography.X509Certificates.StoreName]::Root
$store_location = [System.Security.Cryptography.X509Certificates.StoreLocation]::LocalMachine
$store = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Store -ArgumentList $store_name, $store_location
$store.Open("MaxAllowed")
$store.Add($cert)
$store.Close()

Код для импорта открытого ключа клиентского сертификата:

$cert = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Certificate2
$cert.Import("cert.pem")

$store_name = [System.Security.Cryptography.X509Certificates.StoreName]::TrustedPeople
$store_location = [System.Security.Cryptography.X509Certificates.StoreLocation]::LocalMachine
$store = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Store -ArgumentList $store_name, $store_location
$store.Open("MaxAllowed")
$store.Add($cert)
$store.Close()

Сопоставление сертификата с учетной записью

После импорта сертификата его необходимо сопоставить с локальной учетной записью.

Это можно сделать с помощью следующей команды PowerShell:

$username = "username"
$password = ConvertTo-SecureString -String "password" -AsPlainText -Force
$credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $username, $password

# this is the issuer thumbprint which in the case of a self generated cert
# is the public key thumbprint, additional logic may be required for other
# scenarios
$thumbprint = (Get-ChildItem -Path cert:\LocalMachine\root | Where-Object { $_.Subject -eq "CN=$username" }).Thumbprint

New-Item -Path WSMan:\localhost\ClientCertificate `
    -Subject "$username@localhost" `
    -URI * `
    -Issuer $thumbprint `
    -Credential $credential `
    -Force

После этого переменная хоста ansible_winrm_cert_pem должна быть установлена в путь к открытому ключу, а переменная ansible_winrm_cert_key_pem — в путь к закрытому ключу.

NTLM

NTLM — это более старый механизм аутентификации, используемый Microsoft, который может поддерживать как локальные, так и доменные учетные записи. NTLM включен по умолчанию в службе WinRM, поэтому дополнительная настройка не требуется перед его использованием.

NTLM — самый простой в использовании протокол аутентификации и более безопасный, чем аутентификация Basic. Если вы работаете в среде домена, следует использовать Kerberos, а не NTLM.

Kerberos имеет несколько преимуществ перед использованием NTLM:

• NTLM — это старый протокол и не поддерживает более новые протоколы шифрования.
• NTLM медленнее в аутентификации, так как требует большего числа циклов обмена с хостом на этапе аутентификации.
• В отличие от Kerberos, NTLM не позволяет делегировать учетные данные.

В этом примере показаны переменные хоста, настроенные для использования аутентификации NTLM:

ansible_user: LocalUsername
ansible_password: Password
ansible_connection: winrm
ansible_winrm_transport: ntlm

Kerberos

Kerberos — рекомендуемый параметр аутентификации для работы в среде домена. Kerberos поддерживает такие функции, как делегирование учетных данных и шифрование сообщений по HTTP, и является одним из более безопасных вариантов через WinRM.

Для использования Kerberos требуется дополнительная настройка хоста Ansible.

В следующем примере показаны переменные хоста, настроенные для аутентификации Kerberos:

ansible_user: username@MY.DOMAIN.COM
ansible_password: Password
ansible_connection: winrm
ansible_winrm_transport: kerberos

Начиная с версии Ansible 2.3, билет Kerberos создается на основе ansible_user и ansible_password. Если используется более старая версия Ansible или когда ansible_winrm_kinit_mode имеет значение manual, билет Kerberos необходимо получить заранее. Подробнее об этом ниже.

Можно установить дополнительные переменные хоста:

ansible_winrm_kinit_mode: managed/manual (manual means Ansible will not obtain a ticket)
ansible_winrm_kinit_cmd: the kinit binary to use to obtain a Kerberos ticket (default to kinit)
ansible_winrm_service: overrides the SPN prefix that is used, the default is ``HTTP`` and should rarely ever need changing
ansible_winrm_kerberos_delegation: allows the credentials to traverse multiple hops
ansible_winrm_kerberos_hostname_override: the hostname to be used for the kerberos exchange

Установка библиотеки Kerberos

Перед использованием Kerberos необходимо установить некоторые системные зависимости. Скрипт ниже указывает зависимости в зависимости от дистрибутива:

# Via Yum (RHEL/Centos/Fedora)
yum -y install python-devel krb5-devel krb5-libs krb5-workstation

# Via Apt (Ubuntu)
sudo apt-get install python-dev libkrb5-dev krb5-user

# Via Portage (Gentoo)
emerge -av app-crypt/mit-krb5
emerge -av dev-python/setuptools

# Via Pkg (FreeBSD)
sudo pkg install security/krb5

# Via OpenCSW (Solaris)
pkgadd -d http://get.opencsw.org/now
/opt/csw/bin/pkgutil -U
/opt/csw/bin/pkgutil -y -i libkrb5_3

# Via Pacman (Arch Linux)
pacman -S krb5

После установки зависимостей можно установить оболочку python-kerberos с помощью pip:

pip install pywinrm[kerberos]

Настройка Kerberos для хоста

После установки зависимостей Kerberos необходимо настроить для связи с доменом. Эта настройка выполняется через файл /etc/krb5.conf, который устанавливается вместе с пакетами в скрипте выше.

Для настройки Kerberos добавьте в раздел, начинающийся с:

[realms]

полное имя домена и полностью квалифицированные доменные имена первичных и вторичных контроллеров домена Active Directory. Должно выглядеть примерно так:

[realms]
    MY.DOMAIN.COM = {
        kdc = domain-controller1.my.domain.com
        kdc = domain-controller2.my.domain.com
    }

В разделе, начинающемся с:

[domain_realm]

добавить строку для каждого домена, к которому Ansible должен получить доступ:

[domain_realm]
    .my.domain.com = MY.DOMAIN.COM

Вы можете настроить другие параметры в этом файле, такие как домен по умолчанию. См. krb5.conf для получения более подробной информации.

Автоматическое управление билетами Kerberos

Версии Ansible 2.3 и более поздние по умолчанию автоматически управляют билетами Kerberos, когда для хоста заданы как ansible_user, так и ansible_password. В этом процессе для каждого хоста создается новый билет в временном кэше учетных данных. Это делается перед выполнением каждой задачи, чтобы свести к минимуму вероятность истечения срока действия билета. Временные кэши учетных данных удаляются после завершения каждой задачи и не будут мешать стандартному кэшу учетных данных.

Чтобы отключить автоматическое управление билетами, задайте ansible_winrm_kinit_mode=manual в инвентаре.

Автоматическое управление билетами требует стандартного исполняемого файла kinit в пути системы хоста управления. Чтобы указать другое расположение или имя исполняемого файла, задайте переменную ansible_winrm_kinit_cmd хост-переменной полному пути к бинарному файлу MIT krbv5 kinit-совместимой версии.

Ручное управление билетами Kerberos

Для ручного управления билетами Kerberos используется исполняемый файл kinit. Чтобы получить новый билет, используется следующая команда:

kinit username@MY.DOMAIN.COM

Чтобы увидеть полученные билеты (если таковые имеются), используйте следующую команду:

klist

Чтобы уничтожить все полученные билеты, используйте следующую команду:

kdestroy

Устранение неполадок Kerberos

Kerberos зависит от правильно настроенной среды для работы. Для устранения неполадок Kerberos убедитесь, что:

• Имя хоста, заданное для хоста Windows, является полным доменным именем (FQDN), а не IP-адресом.
• Прямые и обратные DNS-поиски работают правильно в домене. Чтобы проверить это, выполните ping для хоста Windows по имени, а затем используйте полученный IP-адрес с nslookup. То же имя должно возвращаться при использовании nslookup с IP-адресом.
• Часы хоста Ansible синхронизированы с контроллером домена. Kerberos чувствителен к времени, и небольшое смещение времени может привести к сбою процесса генерации билетов.

• Убедитесь, что полное доменное имя для домена настроено в файле krb5.conf. Для проверки этого выполните команду:

  kinit -C username@MY.DOMAIN.COM
  klist
  

  Если доменное имя, возвращенное klist, отличается от запрошенного, используется псевдоним. Файл krb5.conf необходимо обновить, чтобы использовать полное доменное имя, а не псевдоним.

CredSSP

CredSSP - более новый протокол аутентификации, который позволяет делегировать учетные данные. Это достигается путем шифрования имени пользователя и пароля после успешной аутентификации и отправки этого серверу с помощью протокола CredSSP.

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

CredSSP может использоваться для локальных и доменных учетных записей и также поддерживает шифрование сообщений по протоколу HTTP.

Для использования аутентификации CredSSP переменные host vars настраиваются следующим образом:

ansible_user: Username
ansible_password: Password
ansible_connection: winrm
ansible_winrm_transport: credssp

Существуют дополнительные переменные host vars, которые могут быть заданы, как показано ниже:

ansible_winrm_credssp_disable_tlsv1_2: when true, will not use TLS 1.2 in the CredSSP auth process

Аутентификация CredSSP по умолчанию не включена на хосте Windows, но ее можно включить, выполнив следующую команду в PowerShell:

Enable-WSManCredSSP -Role Server -Force

Установка библиотеки CredSSP

Обёртку requests-credssp можно установить с помощью pip:

pip install pywinrm[credssp]

CredSSP и TLS 1.2

По умолчанию библиотека requests-credssp настроена на аутентификацию по протоколу TLS 1.2. TLS 1.2 установлен и включен по умолчанию для Windows Server 2012 и Windows 8 и более поздних версий.

Существует два способа использования устаревших хостов с CredSSP:

• Установите и включите исправление, чтобы включить поддержку TLS 1.2 (рекомендуется для Server 2008 R2 и Windows 7).
• Задайте ansible_winrm_credssp_disable_tlsv1_2=True в инвентаре, чтобы работать по протоколу TLS 1.0. Это единственный вариант при подключении к Windows Server 2008, который не поддерживает TLS 1.2.

Для включения поддержки TLS 1.2 на Server 2008 R2 и Windows 7 необходимо установить необязательное обновление KRB3080079.

После применения обновления и перезагрузки хоста Windows выполните следующие команды PowerShell для включения TLS 1.2:

$reg_path = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProvider\SCHANNEL\Protocols\TLS 1.2"
New-Item -Path $reg_path
New-Item -Path "$reg_path\Server"
New-Item -Path "$reg_path\Client"

New-ItemProperty -Path "$reg_path\Server" -Name "Enabled" -Value 1 -PropertyType DWord
New-ItemProperty -Path "$reg_path\Server" -Name "DisabledByDefault" -Value 0 -PropertyType DWord
New-ItemProperty -Path "$reg_path\Client" -Name "Enabled" -Value 1 -PropertyType DWord
New-ItemProperty -Path "$reg_path\Client" -Name "DisabledByDefault" -Value 0 -PropertyType DWord

Настройка сертификата CredSSP

CredSSP работает путем шифрования учетных данных через протокол TLS и по умолчанию использует самозаверяющий сертификат. Параметр CertificateThumbprint в конфигурации службы WinRM можно использовать для указания отпечатка другого сертификата.

Для явного указания сертификата для CredSSP:

# note the value $certificate_thumbprint will be different in each
# situation, this needs to be set based on the cert that is used.
$certificate_thumbprint = "7C8DCBD5427AFEE6560F4AF524E325915F51172C"

# set the thumbprint value
Set-Item -Path WSMan:\localhost\Service\CertificateThumbprint -Value $certificate_thumbprint

Учетные записи без прав администратора

WinRM настроен по умолчанию для разрешения подключений только из учетных записей в локальной группе Administrators. Это можно изменить, выполнив команду:

winrm configSDDL default

Это отобразит редактор правил доступа, где можно добавить новых пользователей или группы. Для выполнения команд через WinRM пользователям и группам должны быть включены как минимум права Read и Execute.

Хотя учетные записи без прав администратора можно использовать с WinRM, для большинства типичных задач администрирования сервера требуется определенный уровень доступа администратора, поэтому этот инструмент обычно ограничен.

Шифрование WinRM

По умолчанию WinRM не будет работать при работе по незащищенному каналу. Протокол WinRM считает канал зашифрованным, если используется TLS поверх HTTP (HTTPS) или шифрование на уровне сообщений. Использование WinRM с TLS является рекомендуемым вариантом, так как оно работает со всеми вариантами аутентификации, но требует создания и использования сертификата на слушателе WinRM.

ConfigureRemotingForAnsible.ps1 создаёт самозаверяющий сертификат и создаёт слушателя с этим сертификатом. Если вы работаете в доменной среде, ADCS также может создать сертификат для хоста, выданный самим доменом.

Если использование HTTPS невозможно, можно использовать HTTP, когда параметр аутентификации NTLM, Kerberos или CredSSP . Эти протоколы будут шифровать содержимое WinRM с использованием собственного метода шифрования перед отправкой на сервер. Шифрование на уровне сообщений не используется при работе через HTTPS, так как шифрование использует более безопасный протокол TLS. Если требуется и транспортное, и шифрование сообщений, установите ansible_winrm_message_encryption=always в переменных host vars.

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

Set-Item -Path WSMan:\localhost\Service\AllowUnencrypted -Value $true

Параметры инвентаризации

Поддержка Windows в Ansible использует несколько стандартных переменных для указания имени пользователя, пароля и типа подключения удаленных хостов. Эти переменные наиболее удобно настраивать в инвентаре, но их можно настроить на уровне host_vars/ group_vars.

При настройке инвентаря требуются следующие переменные:

# it is suggested that these be encrypted with ansible-vault:
# ansible-vault edit group_vars/windows.yml
ansible_connection: winrm

# may also be passed on the command-line via --user
ansible_user: Administrator

# may also be supplied at runtime with --ask-pass
ansible_password: SecretPasswordGoesHere

Используя переменные выше, Ansible подключится к хосту Windows с использованием аутентификации Basic через HTTPS. Если у ansible_user есть значение UPN, например username@MY.DOMAIN.COM, то вариант аутентификации автоматически попытается использовать Kerberos, если ansible_winrm_transport не установлено на значение отличное от kerberos.

Также поддерживаются следующие пользовательские переменные инвентаря для дополнительной настройки подключений WinRM:

• ansible_port: Порт, на котором будет работать WinRM, HTTPS — 5986, по умолчанию, а HTTP — 5985
• ansible_winrm_scheme: Укажите схему подключения (http или https) для подключения WinRM. Ansible использует https по умолчанию, если ansible_port не 5985
• ansible_winrm_path: Укажите альтернативный путь к конечной точке WinRM. Ansible использует /wsman по умолчанию
• ansible_winrm_realm: Укажите домен для аутентификации Kerberos. Если ansible_user содержит @, Ansible по умолчанию будет использовать часть имени пользователя после @
• ansible_winrm_transport: Укажите один или несколько параметров транспорта аутентификации в виде списка, разделённого запятыми. По умолчанию Ansible использует kerberos, basic, если модуль kerberos установлен и определён домен, в противном случае — plaintext
• ansible_winrm_server_cert_validation: Укажите режим проверки подлинности серверного сертификата (ignore или validate). Ansible по умолчанию использует validate в Python 2.7.9 и выше, что может привести к ошибкам проверки сертификатов для самозаверяемых сертификатов Windows. Если не были сконфигурированы проверенные сертификаты на слушателях WinRM, это значение следует установить в ignore
• ansible_winrm_operation_timeout_sec: Увеличение значения таймаута по умолчанию для операций WinRM. Ansible использует значение 20 по умолчанию
• ansible_winrm_read_timeout_sec: Увеличение таймаута чтения WinRM. Ansible использует значение 30 по умолчанию. Полезно при периодических проблемах с сетью и повторных ошибках таймаута чтения
• ansible_winrm_message_encryption: Укажите операцию шифрования сообщений (auto, always, never) для использования. Ansible использует auto по умолчанию. auto означает, что шифрование сообщений используется только тогда, когда ansible_winrm_scheme равно http, и ansible_winrm_transport поддерживает шифрование сообщений. always означает, что шифрование сообщений всегда используется, а never означает, что шифрование сообщений никогда не используется
• ansible_winrm_ca_trust_path: Используется для указания контейнера cacert, отличного от используемого в модуле certifi. Подробнее см. раздел Проверка подлинности HTTPS-сертификатов.
• ansible_winrm_send_cbt: При использовании ntlm или kerberos по протоколу HTTPS библиотека аутентификации попытается отправить токены привязки канала для защиты от атак «человек посередине». Этот флаг управляет отправкой этих привязок (по умолчанию: True).
• ansible_winrm_*: Любые дополнительные ключевые аргументы, поддерживаемые winrm.Protocol, могут быть переданы вместо *

Кроме того, существуют также специфические переменные, которые необходимо установить для каждого варианта аутентификации. Подробнее см. выше раздел об аутентификации.

IPv6-адреса

Вместо IPv4-адресов или имён хостов могут использоваться IPv6-адреса. Этот параметр обычно устанавливается в инвентаризации. Ansible попытается разобрать адрес с помощью пакета ipaddress и передать его pywinrm корректно.

При определении хоста с использованием IPv6-адреса достаточно добавить IPv6-адрес так же, как вы добавляете IPv4-адрес или имя хоста:

[windows-server]
2001:db8::1

[windows-server:vars]
ansible_user=username
ansible_password=password
ansible_connection=winrm

Проверка подлинности HTTPS-сертификатов

В рамках протокола TLS выполняется проверка подлинности сертификата для обеспечения соответствия хоста предмету и доверия клиента к издателю серверного сертификата. При использовании самозаверяемого сертификата или установке ansible_winrm_server_cert_validation: ignore эти механизмы безопасности обходятся. Хотя самозаверяемые сертификаты всегда потребуют флага ignore, сертификаты, выпущенные центром сертификации, по-прежнему могут быть проверены.

Один из наиболее распространённых способов настройки HTTPS-слушателя в среде домена — использование службы сертификатов Active Directory (AD CS). AD CS используется для генерации подписанных сертификатов из запроса на подпись сертификата (CSR). Если HTTPS-слушатель WinRM использует сертификат, подписанный другим центром сертификации, например AD CS, Ansible можно настроить для доверия к этому издателю как части рукопожатия TLS.

Чтобы Ansible доверял центру сертификации (CA), такому как AD CS, можно экспортировать сертификат издателя CA в формате PEM. Затем этот сертификат можно скопировать на контроллер Ansible и использовать в качестве источника проверки сертификатов, также известного как цепочка сертификатов CA.

Цепочка сертификатов CA может содержать один или несколько сертификатов издателя, и каждая запись содержится в новой строке. Затем для использования настраиваемой цепочки сертификатов CA в процессе проверки установите ansible_winrm_ca_trust_path на путь к файлу. Если эта переменная не установлена, используется цепочка сертификатов CA по умолчанию, расположенная в пути установки пакета Python certifi.

Ограничения

Из-за особенностей протокола WinRM при использовании WinRM существует несколько ограничений, которые могут привести к проблемам при создании playbooks для Ansible. К ним относятся:

• Для большинства типов аутентификации делегирование учетных данных не выполняется, что приводит к ошибкам аутентификации при доступе к сетевым ресурсам или установке некоторых программ.
• Многие вызовы API Windows Update блокируются при работе через WinRM.
• Некоторые программы не устанавливаются через WinRM из-за отсутствия делегирования учетных данных или из-за доступа к запрещённым API Windows, например, WUA через WinRM.
• Команды в рамках WinRM выполняются в неинтерактивной сессии, что может препятствовать выполнению некоторых команд или исполняемых файлов.
• Нельзя запустить процесс, который взаимодействует с DPAPI, что используется некоторыми установщиками (например, Microsoft SQL Server).

Некоторые из этих ограничений можно обойти, выполнив одно из следующих действий:

• Установите ansible_winrm_transport в credssp или kerberos (с ansible_winrm_kerberos_delegation=true) для обхода проблемы двойного перехода и доступа к сетевым ресурсам
• Используйте become для обхода всех ограничений WinRM и выполнения команды так, как если бы она выполнялась локально. В отличие от использования транспортного средства аутентификации, такого как credssp, это также удалит ограничение неинтерактивности и ограничения на API, такие как WUA и DPAPI
• Используйте запланированную задачу для выполнения команды, которая может быть создана с помощью модуля win_scheduled_task. Подобно become, это обходит все ограничения WinRM, но может выполнять только команду, а не модули.