Удаленное управление 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
• Поддержка TLS 1.2
• Ограничения

Что такое 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), то их может декодировать любой. Базовая аутентификация может использоваться только для локальных учетных записей (не учетных записей домена).

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

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, но формат файла и процесс генерации ключа отличаются.

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

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, используя cmdlet 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()

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

После импорта сертификата, сопоставьте его с локальной учетной записью пользователя:

$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

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

NTLM

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

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

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

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

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

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

Kerberos

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

Kerberos требует дополнительных настроек на хосте Ansible перед его правильным использованием.

Следующий пример показывает настройки host vars для аутентификации 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 должен быть получен заранее. Подробнее см. ниже.

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

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-поиски работают правильно в домене. Для проверки этого, выполните пинг хоста Windows по имени, а затем используйте полученный IP-адрес с nslookup. То же имя должно быть возвращено при использовании nslookup для IP-адреса.
• Часы хоста Ansible синхронизированы с контроллером домена. Kerberos чувствителен к времени, и даже небольшое смещение часов может привести к сбоям в процессе генерации билетов.

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

  kinit -C username@MY.DOMAIN.COM
  klist
  

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

• Если утилиты Kerberos по умолчанию были заменены или изменены (некоторые решения IdM могут это сделать), это может вызвать проблемы при установке или обновлении библиотеки Python Kerberos. По состоянию на момент написания этой документации, эта библиотека называется pykerberos и известна своей работой как с библиотеками MIT, так и Heimdal Kerberos. Для решения проблем с установкой pykerberos, убедитесь, что системные зависимости Kerberos удовлетворены (см.: Установку библиотеки Kerberos), удалите все пользовательские пути к инструментам Kerberos из переменной окружения PATH и повторите попытку установки пакета Python Kerberos library.

CredSSP

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

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

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

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

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

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

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 для получения дополнительной информации о том, как включить TLS 1.2 на хосте Windows.

Установить сертификат 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 в переменных хоста.

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

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 библиотека аутентификации будет пытаться отправить токены привязки канала, чтобы снизить риск атак «человек посередине». Этот флаг управляет отправкой этих привязок (по умолчанию: yes).
• 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 доверял центру сертификации (ЦС) вроде AD CS, можно экспортировать сертификат-выдающий орган ЦС в формате PEM. Затем этот сертификат можно скопировать на контроллер Ansible и использовать в качестве источника проверки сертификатов, также известного как цепочка ЦС.

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

Поддержка TLS 1.2

Поскольку WinRM работает поверх протокола HTTP, использование HTTPS означает, что для шифрования сообщений WinRM используется протокол TLS. TLS автоматически попытается договориться о наилучшем протоколе и наборе шифров, доступных как клиенту, так и серверу. Если совпадение невозможно, Ansible выдаст ошибку, похожую на:

HTTPSConnectionPool(host='server', port=5986): Max retries exceeded with url: /wsman (Caused by SSLError(SSLError(1, '[SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:1056)')))

Обычно это происходит, когда хост Windows не настроен на поддержку TLS v1.2, но также может означать, что на контроллере Ansible установлена более старая версия OpenSSL.

Windows 8 и Windows Server 2012 по умолчанию имеют установленный и включённый TLS v1.2, но на более старых хостах, таких как Server 2008 R2 и Windows 7, его необходимо включить вручную.

Чтобы проверить, какие протоколы поддерживает хост Windows, можно выполнить следующую команду на контроллере Ansible:

openssl s_client -connect <hostname>:5986

Вывод будет содержать информацию о сессии TLS, а строка Protocol покажет согласованную версию:

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: 962A00001C95D2A601BE1CCFA7831B85A7EEE897AECDBF3D9ECD4A3BE4F6AC9B
    Session-ID-ctx:
    Master-Key: ....
    Start Time: 1552976474
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: AE16000050DA9FD44D03BB8839B64449805D9E43DBD670346D3D9E05D1AEEA84
    Session-ID-ctx:
    Master-Key: ....
    Start Time: 1552976538
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)

Если хост возвращает TLSv1, его следует настроить так, чтобы TLS v1.2 был включен. Для этого можно запустить следующий PowerShell-скрипт:

Function Enable-TLS12 {
    param(
        [ValidateSet("Server", "Client")]
        [String]$Component = "Server"
    )

    $protocols_path = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'
    New-Item -Path "$protocols_path\TLS 1.2\$Component" -Force
    New-ItemProperty -Path "$protocols_path\TLS 1.2\$Component" -Name Enabled -Value 1 -Type DWORD -Force
    New-ItemProperty -Path "$protocols_path\TLS 1.2\$Component" -Name DisabledByDefault -Value 0 -Type DWORD -Force
}

Enable-TLS12 -Component Server

# Not required but highly recommended to enable the Client side TLS 1.2 components
Enable-TLS12 -Component Client

Restart-Computer

Ниже приведены Ansible-задачи, которые также можно использовать для включения TLS v1.2:

- name: enable TLSv1.2 support
  win_regedit:
    path: HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\{{ item.type }}
    name: '{{ item.property }}'
    data: '{{ item.value }}'
    type: dword
    state: present
  register: enable_tls12
  loop:
  - type: Server
    property: Enabled
    value: 1
  - type: Server
    property: DisabledByDefault
    value: 0
  - type: Client
    property: Enabled
    value: 1
  - type: Client
    property: DisabledByDefault
    value: 0

- name: reboot if TLS config was applied
  win_reboot:
  when: enable_tls12 is changed

Существуют и другие способы настройки протоколов TLS и наборов шифров, предлагаемых хостом Windows. Один из инструментов, который предоставляет графический интерфейс для управления этими настройками, — IIS Crypto от Nartac Software.

Ограничения

Из-за особенностей протокола 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, но может запускать только команду, а не модули.