Wykonywanie drugiego przeskoku w komunikacji zdalnej programu PowerShell

"Problem z drugim przeskokiem" odnosi się do sytuacji podobnej do następującej:

  1. Zalogowano się do serweraA.
  2. Z serweraA uruchom zdalną sesję programu PowerShell, aby nawiązać połączenie z serweremB.
  3. Polecenie uruchamiane w usłudze ServerB za pośrednictwem sesji komunikacji zdalnej programu PowerShell próbuje uzyskać dostęp do zasobu na serwerze ServerC.
  4. Odmowa dostępu do zasobu w usłudze ServerC , ponieważ poświadczenia użyte do utworzenia sesji komunikacji zdalnej programu PowerShell nie są przekazywane z serweraB do serwera ServerC.

Istnieje kilka sposobów rozwiązania tego problemu. W poniższej tabeli wymieniono metody w kolejności preferencji.

Konfigurowanie Uwaga
Protokół CredSSP Równoważenie łatwości użycia i zabezpieczeń
Ograniczone delegowanie kerberos oparte na zasobach Wyższe zabezpieczenia z prostszą konfiguracją
Ograniczone delegowanie protokołu Kerberos Wysoki poziom zabezpieczeń, ale wymaga administratora domeny
Delegowanie protokołu Kerberos (nieobsługiwane) Niezalecane
Just Enough Administration (JEA) Może zapewnić najlepsze zabezpieczenia, ale wymaga bardziej szczegółowej konfiguracji
PsSessionConfiguration przy użyciu uruchomień Prostsze do skonfigurowania, ale wymaga zarządzania poświadczeniami
Przekazywanie poświadczeń wewnątrz bloku skryptu Invoke-Command Najprostsze do użycia, ale musisz podać poświadczenia

Protokół CredSSP

Do uwierzytelniania można użyć dostawcy obsługi zabezpieczeń poświadczeń (CredSSP ). Dostawca CredSSP buforuje poświadczenia na serwerze zdalnym (ServerB), więc użycie go otwiera do ataków kradzieży poświadczeń. W przypadku naruszenia zabezpieczeń komputera zdalnego osoba atakująca ma dostęp do poświadczeń użytkownika. Dostawca CredSSP jest domyślnie wyłączony na komputerach klienckich i serwerach. Należy włączyć program CredSSP tylko w najbardziej zaufanych środowiskach. Na przykład administrator domeny łączący się z kontrolerem domeny, ponieważ kontroler domeny jest wysoce zaufany.

Aby uzyskać więcej informacji na temat problemów z zabezpieczeniami w przypadku korzystania z protokołu CredSSP na potrzeby komunikacji zdalnej programu PowerShell, zobacz Przypadkowy sabotaż: uważaj na credSSP.

Aby uzyskać więcej informacji na temat ataków kradzieży poświadczeń, zobacz Łagodzenie ataków typu Pass-the-Hash (PtH) i innych kradzieży poświadczeń.

Aby zapoznać się z przykładem włączania i używania protokołu CredSSP na potrzeby komunikacji zdalnej programu PowerShell, zobacz Włączanie funkcji "Second-Hop" programu PowerShell z protokołem CredSSP.

Zalety

  • Działa ona dla wszystkich serwerów z systemem Windows Server 2008 lub nowszym.

Wady

Ograniczone delegowanie protokołu Kerberos

Możesz użyć starszego ograniczonego delegowania (nie opartego na zasobach), aby przeskoczyć drugi przeskok. Skonfiguruj ograniczone delegowanie protokołu Kerberos z opcją "Użyj dowolnego protokołu uwierzytelniania", aby zezwolić na przenoszenie protokołu.

Zalety

  • Nie wymaga specjalnego kodowania
  • Poświadczenia nie są przechowywane.

Wady

  • Nie obsługuje drugiego przeskoku dla usługi WinRM.
  • Wymaga dostępu administratora domeny do skonfigurowania.
  • Należy skonfigurować w obiekcie usługi Active Directory serwera zdalnego (ServerB).
  • Ograniczona do jednej domeny. Nie można przekraczać domen ani lasów.
  • Wymaga uprawnień do aktualizowania obiektów i głównych nazw usługi (SPN).
  • SerwerB może uzyskać bilet Protokołu Kerberos do serwera W imieniu użytkownika bez interwencji użytkownika.

Uwaga

Nie można delegować kont usługi Active Directory z uwzględnieniem konta i nie można delegować zestawu właściwości. Aby uzyskać więcej informacji, zobacz Security Focus: Analizowanie "Konto jest poufne i nie można go delegować" dla uprzywilejowanych kont i narzędzi uwierzytelniania Kerberos i ustawień.

Ograniczone delegowanie kerberos oparte na zasobach

Za pomocą ograniczonego delegowania kerberos opartego na zasobach (wprowadzonego w Windows Server 2012) należy skonfigurować delegowanie poświadczeń na obiekcie serwera, w którym znajdują się zasoby. W scenariuszu drugiego przeskoku opisanym powyżej skonfigurujesz serwer ServerC , aby określić miejsce, w którym akceptuje delegowane poświadczenia.

Zalety

  • Poświadczenia nie są przechowywane.
  • Skonfigurowano przy użyciu poleceń cmdlet programu PowerShell. Nie jest wymagane żadne specjalne kodowanie.
  • Nie wymaga dostępu administratora domeny do skonfigurowania.
  • Działa w różnych domenach i lasach.

Wady

  • Wymaga Windows Server 2012 lub nowszej.
  • Nie obsługuje drugiego przeskoku dla usługi WinRM.
  • Wymaga uprawnień do aktualizowania obiektów i głównych nazw usługi (SPN).

Uwaga

Nie można delegować kont usługi Active Directory z uwzględnieniem konta i nie można delegować zestawu właściwości. Aby uzyskać więcej informacji, zobacz Security Focus: Analizowanie "Konto jest poufne i nie można go delegować" dla uprzywilejowanych kont i narzędzi uwierzytelniania Kerberos i ustawień.

Przykład

Przyjrzyjmy się przykładowi programu PowerShell, który konfiguruje ograniczone delegowanie oparte na zasobach na serwerze ServerC w celu zezwolenia na delegowane poświadczenia z serweraB. W tym przykładzie przyjęto założenie, że wszystkie serwery działają Windows Server 2012 lub nowszym, a co najmniej jedna Windows Server 2012 kontroler domeny, do której należy dowolny z serwerów.

Przed skonfigurowaniem ograniczonego delegowania należy dodać RSAT-AD-PowerShell funkcję, aby zainstalować moduł programu PowerShell usługi Active Directory, a następnie zaimportować ten moduł do sesji:

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

Kilka dostępnych poleceń cmdlet ma teraz parametr 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

Parametr PrincipalsAllowedToDelegateToAccount ustawia atrybut obiektu usługi Active Directory msDS-AllowedToActOnBehalfOfOtherIdentity, który zawiera listę kontroli dostępu (ACL), która określa, które konta mają uprawnienia do delegowania poświadczeń do skojarzonego konta (w naszym przykładzie będzie to konto komputera dla serweraA).

Teraz skonfigurujemy zmienne, których będziemy używać do reprezentowania serwerów:

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

Usługa WinRM (i dlatego komunikacja zdalna programu PowerShell) jest domyślnie uruchamiana jako konto komputera. Możesz to zobaczyć, przeglądając właściwość winrmStartName usługi:

Get-CimInstance Win32_Service -Filter 'Name="winrm"' | Select-Object StartName
StartName
---------
NT AUTHORITY\NetworkService

Aby serwerC zezwalał na delegowanie z sesji komunikacji zdalnej programu PowerShell na serwerzeB, musimy ustawić parametr PrincipalsAllowedToDelegateToAccount na serverC na obiekt komputera SerweraB:

# 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

Centrum dystrybucji kluczy Kerberos (KDC) buforuje próby odmowy dostępu (ujemna pamięć podręczna) przez 15 minut. Jeśli wcześniej podjęto próbę uzyskania dostępu do serwera ServerC, należy wyczyścić pamięć podręczną w usłudze ServerB, wywołując następujące polecenie:

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

Możesz również ponownie uruchomić komputer lub poczekać co najmniej 15 minut, aby wyczyścić pamięć podręczną.

Po wyczyszczeniu pamięci podręcznej można pomyślnie uruchomić kod z serweraA za pośrednictwem serweraB do serwera 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)
}

W tym przykładzie zmienna $using jest używana do tworzenia zmiennej widocznej $ServerC dla serweraB. Aby uzyskać więcej informacji na temat zmiennej $using , zobacz about_Remote_Variables.

Aby umożliwić wielu serwerom delegowanie poświadczeń do serwera ServerC, ustaw wartość parametru PrincipalsAllowedToDelegateToAccount na serwerze ServerC na tablicę:

# 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

Jeśli chcesz ustawić drugi przeskok między domenami, użyj parametru Serwera , aby określić w pełni kwalifikowaną nazwę domeny (FQDN) kontrolera domeny domeny, do której należy SerwerB :

# 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

Aby usunąć możliwość delegowania poświadczeń do serweraC, ustaw wartość parametru PrincipalsAllowedToDelegateToAccount na serverC na $nullwartość :

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

Informacje na temat ograniczonego delegowania protokołu Kerberos opartego na zasobach

Delegowanie protokołu Kerberos (bez ograniczeń)

Możesz również użyć ograniczonego delegowania protokołu Kerberos, aby wykonać drugi przeskok. Podobnie jak w przypadku wszystkich scenariuszy protokołu Kerberos poświadczenia nie są przechowywane. Ta metoda nie obsługuje drugiego przeskoku dla usługi WinRM.

Ostrzeżenie

Ta metoda nie zapewnia kontroli nad tym, gdzie są używane delegowane poświadczenia. Jest on mniej bezpieczny niż CredSSP. Ta metoda powinna być używana tylko w przypadku scenariuszy testowania.

Just Enough Administration (JEA)

Narzędzie JEA umożliwia ograniczenie poleceń, które administrator może uruchamiać podczas sesji programu PowerShell. Może służyć do rozwiązywania problemu z drugim przeskoku.

Aby uzyskać informacje o narzędziu JEA, zobacz Just Enough Administration (Just Enough Administration).

Zalety

  • Brak konserwacji haseł podczas korzystania z konta wirtualnego.

Wady

  • Wymaga programu WMF 5.0 lub nowszego.
  • Wymaga konfiguracji na każdym serwerze pośrednim (ServerB).

PsSessionConfiguration przy użyciu uruchom jako

Konfigurację sesji można utworzyć na serwerzeB i ustawić jego parametr RunAsCredential .

Aby uzyskać informacje o korzystaniu z poleceń PSSessionConfiguration i RunAs w celu rozwiązania problemu z drugim przeskoku, zobacz Inne rozwiązanie komunikacji zdalnej programu PowerShell z wieloma przeskokami.

Zalety

  • Działa z dowolnym serwerem z programem WMF 3.0 lub nowszym.

Wady

  • Wymaga konfiguracji psSessionConfiguration i Uruchom jako na każdym serwerze pośrednim (ServerB).
  • Wymaga konserwacji haseł podczas korzystania z konta Uruchom jako domeny

Przekazywanie poświadczeń wewnątrz bloku skryptu Invoke-Command

Poświadczenia można przekazać wewnątrz parametru ScriptBlock wywołania do polecenia cmdlet Invoke-Command .

Zalety

  • Nie wymaga specjalnej konfiguracji serwera.
  • Działa na dowolnym serwerze z systemem WMF 2.0 lub nowszym.

Wady

  • Wymaga niezręcznej techniki kodu.
  • W przypadku uruchamiania programu WMF 2.0 wymagana jest inna składnia przekazywania argumentów do sesji zdalnej.

Przykład

W poniższym przykładzie pokazano, jak przekazać poświadczenia w bloku skryptu:

# 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}
}

Zobacz też

Zagadnienia dotyczące zabezpieczeń komunikacji zdalnej programu PowerShell