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

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

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

Что такое WinRM?

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

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

pip install "pywinrm>=0.3.0"

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

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

Следующая таблица — это общий обзор параметров:

Базовая

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

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

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

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

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

Сертификат

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

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

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

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

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

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

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

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

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

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

Это можно сделать с помощью следующей команды 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

После установки зависимостей wrapper 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 hostvar на полное квалифицированное имя пути к бинарному файлу 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 и известна своей совместимостью с библиотеками Kerberos MIT и Heimdal. Для решения проблем с установкой pykerberos, убедитесь, что системные зависимости для Kerberos удовлетворены (см.: Установка библиотеки Kerberos), удалите все пользовательские пути инструментов Kerberos из переменной среды PATH и повторите попытку установки пакета библиотеки Python Kerberos.

CredSSP

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

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

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

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

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

Есть несколько дополнительных переменных host vars, которые можно задать, как показано ниже:

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

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

Enable-WSManCredSSP -Role Server -Force

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

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

pip install pywinrm[credssp]

CredSSP и TLS 1.2

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

Есть два способа использования более старых хостов с CredSSP:

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

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

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

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

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

Установить сертификат CredSSP

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

Чтобы явно установить сертификат для использования с CredSSP:

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

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

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

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

winrm configSDDL default

Это откроет редактор 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 в переменных host vars.

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

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

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

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

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

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

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

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

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

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

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

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

IPv6-адреса

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.

Ограничения

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