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

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

• Что такое WinRM?

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

  • Базовая

  • Сертификат

    • Генерация сертификата
    • Импорт сертификата в хранилище сертификатов
    • Сопоставление сертификата с учетной записью
  • NTLM

  • Kerberos

    • Установка библиотеки Kerberos
    • Настройка Kerberos для хоста
    • Автоматическое управление билетами Kerberos
    • Ручное управление билетами Kerberos
    • Устранение неполадок с Kerberos

  • CredSSP

    • Установка библиотеки CredSSP
    • CredSSP и TLS 1.2
    • Установка сертификата CredSSP
• Учетные записи без прав администратора
• Шифрование WinRM
• Параметры инвентаризации
• IP-адреса 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 Certificate Services.

Для генерации сертификата с 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_port: 5985
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 gcc 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 чувствителен к времени, и небольшое отклонение во времени может привести к сбою процесса генерации билетов.

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

  kinit -C username@MY.DOMAIN.COM
  klist
  

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

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

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

Это отобразит редактор ACL, где можно добавить новых пользователей или группы. Для выполнения команд через 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-адреса

Можно использовать IPv6-адреса вместо IPv4-адресов или имен хостов. Этот параметр обычно задается в инвентаре. 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 Certificate Services (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, но позволит только выполнить команду, а не модули.