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

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

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

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

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

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

• Если утилиты Kerberos по умолчанию были заменены или изменены (некоторые решения IdM могут это сделать), это может вызвать проблемы при установке или обновлении библиотеки Python Kerberos. На момент написания данной документации эта библиотека называется pykerberos и известна своей работой с библиотеками MIT и Heimdal Kerberos. Для решения проблем с установкой 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, может быть просмотрено, изменено, а также удалённая сессия может быть полностью взята под контроль любым пользователем в той же сети. Чтобы отключить требование шифрования, выполните следующую команду из 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 библиотека аутентификации будет пытаться отправлять токены привязки канала, чтобы уменьшить риски атак «человек посередине». Этот флаг управляет отправкой этих привязок (по умолчанию: 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 (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.

Поддержка 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, но может только выполнить команду, а не модули.