Поделиться через

Выполнение второго прыжка при удаленном взаимодействии PowerShell

  • Статья

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

  1. Вы вошли в систему ServerA.
  2. С сервера ServerA вы запускаете удаленный сеанс PowerShell для подключения к серверу ServerB.
  3. Команда, запущенная вами на сервере ServerB через сеанс удаленного взаимодействия PowerShell, пытается получить доступ к ресурсу на сервере ServerC.
  4. Доступ к ресурсу ServerC запрещен, так как учетные данные, используемые для создания сеанса удаленного взаимодействия PowerShell, не передаются из ServerB в ServerC.

Существует несколько способов решения этой проблемы. В следующей таблице перечислены методы в порядке предпочтения.

Конфигурация Примечание.
CredSSP Балансирует удобство использования и безопасность
Делегирование полномочий Kerberos с ограничениями по ресурсам Более высокая безопасность с более простой конфигурацией
Ограниченное делегирование в Kerberos Высокий уровень безопасности, но требуется администратор домена
Делегирование Kerberos (без ограничений) Не рекомендуется
Just Enough Administration (JEA) Может обеспечить лучшую безопасность, но требует более подробной настройки
PSSessionConfiguration с помощью RunAs Проще настроить, но требуется управление учетными данными
Передача учетных данных внутри блока скриптов Invoke-Command Самый простой способ использования, но необходимо указать учетные данные

CredSSP

Для аутентификации можно использовать поставщик поддержки безопасности учетных данных (CredSSP) . CredSSP кэширует учетные данные на удаленном сервере (ServerB), поэтому при использовании он открывает атаки кражи учетных данных. Если безопасность удаленного компьютера нарушена, злоумышленник получает доступ к учетным данным пользователя. Протокол CredSSP по умолчанию отключен на компьютерах клиента и сервера. Включать протокол CredSSP следует только в самых надежных средах. Например, администратор домена, подключающийся к контроллеру домена, так как контроллер домена является высоконадежным.

Дополнительные сведения о проблемах безопасности при использовании CredSSP для удаленного взаимодействия PowerShell см. в разделе Случайное саботажирование: остерегайтесь credSSP.

Дополнительные сведения об атаках кражи учетных данных см. в разделе Устранение атак Pass-the-Hash (PtH) и других атак кражи учетных данных.

Пример того, как включить и использовать CredSSP для удаленного взаимодействия PowerShell, см. раздел Включение функций PowerShell "Second-Hop" с помощью CredSSP.

Плюсы

  • Он работает для всех серверов с Windows Server 2008 или более поздней версии.

Минусы

Ограниченное делегирование в Kerberos

Для выполнения второго этапа можно использовать устаревшее ограниченное делегирование (не на основе ресурсов). Настройте ограниченное делегирование Kerberos с параметром "Использовать любой протокол проверки подлинности", чтобы разрешить переход протокола.

Плюсы

  • Не требуется специального кода
  • Учетные данные не хранятся.

Минусы

  • Не поддерживает второй прыжок для WinRM.
  • Требуется доступ администратора домена для настройки.
  • Необходимо настроить на объекте Active Directory удаленного сервера (ServerB).
  • Ограничено одним доменом. Невозможно пересекать домены или леса.
  • Требуются права на обновление объектов и имен субъектов-служб (SPN).
  • ServerB может получить билет Kerberos на ServerC от имени пользователя без вмешательства пользователя.

Примечание.

Учетные записи Active Directory, имеющие учетную запись , конфиденциальны и не могут быть делегированы набор свойств нельзя делегировать. Дополнительные сведения см. в Фокус на безопасности: анализ 'Учетная запись является чувствительной и не может быть делегирована' для привилегированных учетных записей и Инструменты и настройки проверки подлинности Kerberos.

Ограниченное делегирование Kerberos на основе ресурсов

Используя ограниченное делегирование Kerberos на основе ресурсов (введенное в Windows Server 2012), вы настраиваете делегирование учетных данных на серверном объекте, где находятся ресурсы. Во втором сценарии прыжка, описанном выше, вы настраиваете ServerC, чтобы указать, откуда он принимает делегированные учетные данные.

Плюсы

  • Учетные данные не хранятся.
  • Настроено с помощью командлетов PowerShell. Не требуется специальное кодирование.
  • Не требуется доступ администратора домена к настройке.
  • Работает между доменами и лесами.

Минусы

  • Требуется Windows Server 2012 или более поздней версии.
  • Не поддерживает второй прыжок для WinRM.
  • Требуются права на обновление объектов и имен субъектов-служб (SPN).

Примечание.

Учетные записи Active Directory, имеющие учетную запись , конфиденциальны и не могут быть делегированы набор свойств нельзя делегировать. Дополнительные сведения см. в разделе Фокус безопасности: анализ "Учетная запись является чувствительной и не может быть делегирована" для привилегированных учетных записей и средств проверки подлинности Kerberos и параметров.

Пример

Рассмотрим пример PowerShell, который настраивает ограниченное делегирование на основе ресурсов на ServerC, чтобы разрешить делегированные учетные данные из ServerB. В этом примере предполагается, что все серверы работают под управлением поддерживаемых версий Windows Server, и что для каждого доверенного домена существует по крайней мере один контроллер домена Windows.

Прежде чем настроить ограниченное делегирование, необходимо добавить функцию RSAT-AD-PowerShell для установки модуля PowerShell Active Directory, а затем импортировать этот модуль в сеанс:

Add-WindowsFeature RSAT-AD-PowerShell
Import-Module ActiveDirectory
Get-Command -ParameterName PrincipalsAllowedToDelegateToAccount

Теперь несколько доступных командлетов имеют параметр PrincipalsAllowedToDelegateToAccount:

CommandType Name                 ModuleName
----------- ----                 ----------
Cmdlet      New-ADComputer       ActiveDirectory
Cmdlet      New-ADServiceAccount ActiveDirectory
Cmdlet      New-ADUser           ActiveDirectory
Cmdlet      Set-ADComputer       ActiveDirectory
Cmdlet      Set-ADServiceAccount ActiveDirectory
Cmdlet      Set-ADUser           ActiveDirectory

Параметр PrincipalsAllowedToDelegateToAccount задает атрибут объекта Active Directory msDS-AllowedToActOnBehalfOfOtherIdentity, который содержит список управления доступом (ACL), указывающий, какие учетные записи имеют разрешение на делегирование учетных данных связанной учетной записи (в нашем примере это учетная запись компьютера для ServerA).

Теперь давайте настроим переменные, которые мы будем использовать для представления серверов:

# Set up variables for reuse
$ServerA = $Env:COMPUTERNAME
$ServerB = Get-ADComputer -Identity ServerB
$ServerC = Get-ADComputer -Identity ServerC

WinRM (и поэтому удаленное управление PowerShell) выполняется под учетной записью компьютера по умолчанию. Это можно увидеть, взглянув на свойство StartName службы winrm:

Get-CimInstance Win32_Service -Filter 'Name="winrm"' | Select-Object StartName

StartName
---------
NT AUTHORITY\NetworkService

Чтобы ServerC разрешить делегирование из сеанса удаленного взаимодействия PowerShell на ServerB, необходимо задать параметр PrincipalsAllowedToDelegateToAccountServerC на объект компьютера ServerB:

# Grant resource-based Kerberos constrained delegation
Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $ServerB

# Check the value of the attribute directly
$x = Get-ADComputer -Identity $ServerC -Properties msDS-AllowedToActOnBehalfOfOtherIdentity
$x.'msDS-AllowedToActOnBehalfOfOtherIdentity'.Access

# Check the value of the attribute indirectly
Get-ADComputer -Identity $ServerC -Properties PrincipalsAllowedToDelegateToAccount

Центр распространения ключей (KDC) Kerberos кэширует попытки отказа в доступе (отрицательный кэш) в течение 15 минут. Если ServerB ранее пытались получить доступ к ServerC, необходимо очистить кэш ServerB, вызвав следующую команду:

Invoke-Command -ComputerName $ServerB.Name -Credential $cred -ScriptBlock {
    klist purge -li 0x3e7
}

Вы также можете перезагрузить компьютер или подождать не менее 15 минут, чтобы очистить кэш.

После очистки кэша можно успешно запустить код из ServerA через ServerB до ServerC:

# Capture a credential
$cred = Get-Credential Contoso\Alice

# Test kerberos double hop
Invoke-Command -ComputerName $ServerB.Name -Credential $cred -ScriptBlock {
    Test-Path \\$($Using:ServerC.Name)\C$
    Get-Process lsass -ComputerName $($Using:ServerC.Name)
    Get-EventLog -LogName System -Newest 3 -ComputerName $($Using:ServerC.Name)
}

В этом примере модификатор области Using: используется для отображения переменной $ServerC для ServerB. Дополнительные сведения о модификаторе Using: области см. в about_Remote_Variables.

Чтобы разрешить нескольким серверам делегировать учетные данные серверу ServerC, установите значение параметра PrincipalsAllowedToDelegateToAccount на сервере ServerC в массив.

# Set up variables for each server
$ServerB1 = Get-ADComputer -Identity ServerB1
$ServerB2 = Get-ADComputer -Identity ServerB2
$ServerB3 = Get-ADComputer -Identity ServerB3
$ServerC  = Get-ADComputer -Identity ServerC

$servers = @(
    $ServerB1,
    $ServerB2,
    $ServerB3
)

# Grant resource-based Kerberos constrained delegation
Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $servers

Если вы хотите сделать второй прыжк между доменами, используйте параметр сервера, чтобы указать полное доменное имя (FQDN) контроллера домена, которому принадлежит ServerB:

# For ServerC in Contoso domain and ServerB in other domain
$ServerB = Get-ADComputer -Identity ServerB -Server dc1.alpineskihouse.com
$ServerC = Get-ADComputer -Identity ServerC
Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $ServerB

Чтобы убрать возможность делегирования учетных данных на сервер ServerC, укажите значение параметра PrincipalsAllowedToDelegateToAccount на сервере ServerC в $null:.

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

Сведения об ограниченном делегировании Kerberos на основе ресурсов

Делегирование Kerberos (без ограничений)

Вы также можете использовать неограниченное делегирование Kerberos, чтобы выполнить второй переход. Как и во всех сценариях Kerberos, учетные данные не хранятся. Этот метод не поддерживает второй прыжк для WinRM.

Предупреждение

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

Just Enough Administration (JEA)

JEA позволяет ограничить команды, которые администратор может выполнять во время сеанса PowerShell. Его можно использовать для решения проблемы второго этапа.

Дополнительные сведения о JEA (Минимально достаточное администрирование) см. в .

Плюсы

  • При использовании виртуальной учетной записи не выполняется обслуживание паролей.

Минусы

  • Требуется WMF 5.0 или более поздней версии.
  • Требуется настройка на каждом промежуточном сервере (ServerB).

PSSessionConfiguration с помощью RunAs

На сервере ServerB можно создать конфигурацию сеанса и задать параметр RunAsCredential.

Сведения об использовании PSSessionConfiguration и RunAs для решения проблемы второго перехода см. статью Другое решение для удаленного взаимодействия PowerShell с несколькими переходами.

Плюсы

  • Работает с любым сервером с WMF 3.0 или более поздней версии.

Минусы

  • Требуется настройка PSSessionConfiguration и RunAs на каждом промежуточном сервере (ServerB).
  • Требуется обслуживание паролей при использовании учетной записи RunAs домена

Передача учетных данных внутри блока скриптов Invoke-Command

Учетные данные можно передать в параметр ScriptBlock, вызывая командлет Invoke-Command.

Плюсы

  • Не требуется специальная конфигурация сервера.
  • Работает на любом сервере под управлением WMF 2.0 или более поздней версии.

Минусы

  • Требует неудобной техники кода.
  • При запуске WMF 2.0 требуется другой синтаксис для передачи аргументов в удаленный сеанс.

Пример

В следующем примере показано, как передать учетные данные в блоке скрипта:

# This works without delegation, passing fresh creds
# Note $Using:Cred in nested request
$cred = Get-Credential Contoso\Administrator
Invoke-Command -ComputerName ServerB -Credential $cred -ScriptBlock {
    hostname
    Invoke-Command -ComputerName ServerC -Credential $Using:cred -ScriptBlock {hostname}
}

См. также

рекомендации по обеспечению безопасности удаленного взаимодействия PowerShell