Выполнение второго прыжка при удаленном взаимодействии 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 см. в статье Accidental Sabotage: Beware of CredSSP (Непреднамеренный саботаж: берегитесь CredSSP).

Дополнительные сведения об атаках, направленных на хищение учетных данных, см. в техническом документе Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft.

См. пример того, как включить и использовать CredSSP для удаленного взаимодействия PowerShell.

Плюсы

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

Минусы

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

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

Плюсы

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

Минусы

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

Примечание.

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

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

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

Плюсы

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

Минусы

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

Примечание.

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

Пример

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

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

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, мы должны задать в качестве значения параметра PrincipalsAllowedToDelegateToAccount на ServerC объект компьютера 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

Центр распространения ключей 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 см. в разделе Just Enough Administration.

Плюсы

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

Минусы

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

PSSessionConfiguration с использованием RunAs

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

Сведения об использовании PSSessionConfiguration и RunAs для решения проблемы второго прыжка см. в статье Another solution to multi-hop PowerShell remoting (Другое решение для удаленного взаимодействия PowerShell с несколькими прыжками).

Плюсы

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

Минусы

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

Передача учетных данных внутри блока сценария 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