PowerShell Remoting через WinRM: настройка HTTPS-листенера, Kerberos и JEA в корпоративной сети

Я Семёнов Евгений Сергеевич, директор АйТи Фреш. За 15+ лет обслуживания Windows-инфраструктур развернул WinRM на сотнях серверов — от простого «Enable-PSRemoting» на десятке машин до сложных схем с JEA, HTTPS, Kerberos Constrained Delegation и ограниченными наборами cmdlet для helpdesk. И каждый раз сталкиваюсь с одним и тем же: админы включают WinRM, но не настраивают безопасность, или настраивают с ошибками, которые всплывают в самый неподходящий момент. В этой статье — как я сам развожу WinRM на продакшене, с акцентом на HTTPS, сертификаты, корректную delegation и траблшутинг.

Что такое WinRM и PowerShell Remoting

WinRM — реализация протокола WS-Management от Microsoft. По HTTP/HTTPS передаёт XML-сообщения, поверх которых работают разные приложения: PowerShell Remoting, Ansible winrm connection, PSExec через WinRM, SCVMM. PowerShell Remoting — набор командлетов (Invoke-Command, Enter-PSSession, New-PSSession), которые используют WinRM для выполнения скриптов на удалённом хосте.

Порты по умолчанию:

• 5985 — HTTP (шифрование через Kerberos или NTLM SSP).
• 5986 — HTTPS (TLS-шифрование с сертификатом).

Быстрое включение — только для начала

# На целевой машине (PowerShell от администратора)
Enable-PSRemoting -Force

# С клиента
Test-WSMan -ComputerName srv-app01
Invoke-Command -ComputerName srv-app01 -ScriptBlock { hostname }

Enable-PSRemoting делает за вас: запускает службу WinRM, создаёт HTTP-листенер на 5985, добавляет правила firewall. Для лабы и первого знакомства — хватит. Для продакшена — нет, потому что открытый HTTP-листенер на публичных интерфейсах и отсутствие HTTPS — это плохая практика.

Правильный HTTPS-листенер

Стандартная корпоративная схема — HTTPS с сертификатом из собственного AD CS. Шаблон «Web Server» нужно включить на Issuing CA, затем на каждом сервере запросить сертификат:

# Автоэнроллмент через GPO выдаст сертификат на Computer
# Либо вручную:
$req = [ordered]@{
    Subject = "CN=$env:COMPUTERNAME.corp.itfresh.local"
    DnsName = @("$env:COMPUTERNAME", "$env:COMPUTERNAME.corp.itfresh.local")
    KeyAlgorithm = 'RSA'
    KeyLength = 2048
    CertStoreLocation = 'Cert:\LocalMachine\My'
    Template = 'WebServer'
}
Get-Certificate @req -Url ldap:

# Создание HTTPS-листенера
$cert = Get-ChildItem Cert:\LocalMachine\My |
    Where-Object { $_.Subject -like "*$env:COMPUTERNAME*" } |
    Select-Object -First 1

New-Item -Path WSMan:\localhost\Listener -Transport HTTPS `
    -Address * -CertificateThumbPrint $cert.Thumbprint -Force

# Правило firewall
New-NetFirewallRule -Name 'WinRM-HTTPS-In' -DisplayName 'WinRM HTTPS Inbound' `
    -Protocol TCP -LocalPort 5986 -Direction Inbound -Action Allow

# Удалить HTTP-листенер (по желанию)
Get-ChildItem WSMan:\localhost\Listener | Where-Object Keys -like '*HTTP*' |
    Where-Object Keys -notlike '*HTTPS*' | Remove-Item -Recurse

Проверка с клиента: Test-WSMan -ComputerName srv-app01 -UseSSL. Ответ должен прийти в формате XML с версией WS-Management.

Kerberos против NTLM в WinRM

Я у себя всегда стараюсь использовать Kerberos. Это значит: подключаться только по FQDN (не по IP), целевой хост в AD-домене, клиент либо в том же, либо в доверенном домене. Когда подключаюсь к машинам в рабочей группе или по IP — прописываю TrustedHosts на клиенте:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value 'srv-dmz01,192.168.100.*' -Force
Get-Item WSMan:\localhost\Client\TrustedHosts

Проблема double hop и решения

Типичный сценарий: подключились к серверу A через Invoke-Command, оттуда хотите достучаться до серверного share B. С Kerberos по умолчанию это не работает — учётка остаётся на сервере A. Варианты:

• Kerberos Constrained Delegation (Resource-Based, RBKCD) — правильное решение. Настраивается в AD: компьютер B разрешает компьютеру A делегировать учётки.
• CredSSP — ленивое и небезопасное решение. Пароль реально передаётся на сервер A. Используйте только в изолированных тестовых средах.
• PSSessionConfiguration с RunAsCredential — задаём учётку под которой выполнять на A без передачи клиентских.
• Just Enough Administration — всё то же самое, плюс ограничение cmdlet.

# Настройка RBKCD (правильный способ)
Set-ADComputer -Identity 'srv-fileB' `
    -PrincipalsAllowedToDelegateToAccount (Get-ADComputer 'srv-adminA')
# После этого с A можно без проблем открывать \\srv-fileB\share

Just Enough Administration (JEA)

JEA — механизм, при котором админы и операторы подключаются по WinRM, но получают урезанную оболочку с конкретным набором разрешённых команд. Отлично для helpdesk: сотрудник может разблокировать учётку и перезапустить службу, но не может создать пользователя или удалить файл.

# Role capability file (разрешённые команды)
New-PSRoleCapabilityFile -Path .\HelpdeskOperator.psrc `
    -VisibleCmdlets 'Unlock-ADAccount','Enable-ADAccount',
                    @{Name='Set-ADAccountPassword'; Parameters=@(
                        @{Name='Identity'},@{Name='Reset'},@{Name='NewPassword'})},
                    'Restart-Service' `
    -ModulesToImport ActiveDirectory

# Session configuration
New-PSSessionConfigurationFile -Path .\Helpdesk.pssc `
    -SessionType RestrictedRemoteServer `
    -RoleDefinitions @{ 'CORP\Helpdesk' = @{ RoleCapabilities = 'HelpdeskOperator' } } `
    -RunAsVirtualAccount

Register-PSSessionConfiguration -Name Helpdesk -Path .\Helpdesk.pssc -Force

# Использование
Enter-PSSession -ComputerName srv-dc01 -ConfigurationName Helpdesk -UseSSL

Мини-кейс: централизованное управление 120 серверами

В августе 2025 клиент (логистика, 3 дата-центра, 120 Windows-серверов) пришёл с запросом: сделать так, чтобы у каждого из 8 админов был ограниченный доступ, все действия логировались, и подключаться можно было только с выделенных jump-hosts. До этого у них все админы имели Domain Admin и лезли напрямую через RDP.

Что мы сделали за две недели:

• Подняли два jump-host на Dell с Xeon Platinum 8280, 64 ГБ RAM, 40G Mellanox до центрального файлового хранилища в дата-центре МТС.
• На всех 120 серверах включили HTTPS-листенер WinRM с автоэнроллментом сертификата.
• Отключили HTTP-листенер через GPO.
• Разработали 4 JEA-роли: Helpdesk, FileAdmin, AppAdmin, DbAdmin.
• Настроили OverTheWire логирование всех PSSession в централизованный Event Log на SIEM.
• Domain Admin оставили только у двух инженеров для аварийных ситуаций.

Результат: поверхность атаки снизилась, каждое админ-действие теперь задокументировано с timestamp и user ID, помощник администратора спокойно разблокирует учётку без риска что-то сломать. Стоимость работ 130 тыс. руб.

Траблшутинг WinRM

Частые проблемы и как их чинить:

# Полный сброс конфигурации WinRM (осторожно)
winrm invoke restore winrm/config
Enable-PSRemoting -Force

# Посмотреть все листенеры
winrm e winrm/config/listener
Get-ChildItem WSMan:\localhost\Listener

Безопасность и чек-лист

• HTTPS-листенер на 5986 с сертификатом из AD CS.
• HTTP-листенер на 5985 отключён на серверах с выходом в интернет.
• TrustedHosts на клиентах — только необходимый минимум, не '*'.
• Группа Remote Management Users — только те, кому нужно.
• JEA для операторов и helpdesk.
• Логирование PSSession включено, пересылается в SIEM.
• CredSSP отключён или используется только с KCD.
• Регулярная ротация сертификатов (автоэнроллмент).

FAQ — частые вопросы по WinRM

HTTP или HTTPS для WinRM?

Внутри AD-домена HTTP тоже шифрует трафик через Kerberos, поэтому формально безопасно. Но для машин вне домена, non-domain клиентов, машин за маршрутизаторами — только HTTPS с сертификатом из AD CS или публичного CA.

Что такое TrustedHosts?

Список имён/IP, которым клиент доверяет при NTLM-аутентификации (без Kerberos). Нужен, когда подключаетесь по IP или к машинам за пределами домена. Минимизируйте список, не ставьте '*'.

Зачем CredSSP?

CredSSP делегирует учётные данные на удалённый хост, чтобы оттуда можно было пройти на следующий (double hop). Небезопасно — отключённый сервер увидит ваш пароль. Используйте только в тестовых средах или для Kerberos Constrained Delegation.

Что такое JEA?

Just Enough Administration — механизм, когда администратор подключается через WinRM, но видит только ограниченный набор команд под сервисной учёткой. Снижает поверхность атаки, идеален для операторов helpdesk.

Как дебажить WinRM?

Test-WSMan -ComputerName srv — базовый пинг. winrm e winrm/config/listener — состояние листенеров. Логи: event viewer → Microsoft-Windows-WinRM/Operational. Для сетевой диагностики — Test-NetConnection -Port 5985/5986.