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

Что такое WinRM?

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

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

Если вы выбрали pipx инструкции по установке, вы можете установить его, выполнив следующее:

pipx inject ansible pywinrm  # if you installed ansible with pipx
pipx inject ansible-core pywinrm  # if you installed ansible-core with pipx

Или, если вы выбрали pip инструкции по установке:

pip install "pywinrm>=0.3.0"

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

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

Следующая матрица — это общее представление о доступных параметрах:

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

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

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

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

# 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

# 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"))

$cert = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Certificate2 "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.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

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

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

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

winrm configSDDL default

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

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

Шифрование WinRM

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

Если вы работаете в доменной среде, 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 through --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, могут быть предоставлены вместо *

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

IP-адреса IPv6

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

При определении хоста с использованием IP-адреса IPv6 просто добавьте IP-адрес IPv6 так же, как и IP-адрес 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). Если прослушиватель WinRM HTTPS использует сертификат, подписанный другим центром сертификации, например AD CS, Ansible может быть настроен на доверие к этому издателю в рамках рукопожатия TLS.

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

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

Поддержка TLS 1.2

Так как WinRM работает через протокол HTTP, использование HTTPS означает, что протокол TLS используется для шифрования сообщений WinRM. 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 существует несколько ограничений при использовании 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, но позволяет выполнить только команду, а не модули.