Wykonywanie drugiego przeskoku w komunikacji zdalnej programu PowerShell

  • Artykuł

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

  1. Zalogowano się do serweraA.
  2. Z poziomu serweraA uruchom zdalną sesję programu PowerShell w celu nawiązania połączenia 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 na serwerze ServerC , ponieważ poświadczenia użyte do utworzenia sesji komunikacji zdalnej programu PowerShell nie są przekazywane z serweraB do serweraC.

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

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

Protokół CredSSP

Do uwierzytelniania można użyć dostawcy obsługi zabezpieczeń poświadczeń (CredSSP ). 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. Protokół CredSSP jest domyślnie wyłączony na komputerach klienckich i serwerowych. Należy włączyć protokół CredSSP tylko w najbardziej zaufanych środowiskach. Na przykład administrator domeny nawiązujący połączenie z kontrolerem domeny, ponieważ kontroler domeny jest wysoce zaufany.

Aby uzyskać więcej informacji na temat problemów z zabezpieczeniami podczas 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 polegających na kradzieży poświadczeń, zobacz Ograniczanie 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 programu PowerShell "Drugi przeskok" przy użyciu protokołu CredSSP.

Plusy

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

Minusy

  • Ma luki w zabezpieczeniach.
  • Wymaga konfiguracji zarówno ról klienta, jak i serwera.
  • nie działa z grupą Chronieni użytkownicy. Aby uzyskać więcej informacji, zobacz Grupa zabezpieczeń Chronieni użytkownicy.

Ograniczone delegowanie protokołu Kerberos

Możesz użyć starszego ograniczonego delegowania (nie opartego na zasobach), aby wykonać drugi przeskok. Skonfiguruj ograniczone delegowanie protokołu Kerberos przy użyciu opcji "Użyj dowolnego protokołu uwierzytelniania", aby zezwolić na przejście protokołu.

Plusy

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

Minusy

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

Uwaga

Konta usługi Active Directory, które mają konto , są poufne i nie można delegować zestawu właściwości. Aby uzyskać więcej informacji, zobacz Security Focus: Analizowanie konta jest wrażliwe i nie można go delegować dla uprzywilejowanych kont i narzędzi uwierzytelniania Kerberos oraz Ustawienia.

Ograniczone delegowanie kerberos oparte na zasobach

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

Plusy

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

Minusy

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

Uwaga

Konta usługi Active Directory, które mają konto , są poufne i nie można delegować zestawu właściwości. Aby uzyskać więcej informacji, zobacz Security Focus: Analizowanie konta jest wrażliwe i nie można go delegować dla uprzywilejowanych kont i narzędzi uwierzytelniania Kerberos oraz Ustawienia.

Przykład

Przyjrzyjmy się przykładowi programu PowerShell, który konfiguruje ograniczone delegowanie oparte na zasobach na serwerze ServerC, aby zezwolić na delegowane poświadczenia z serweraB. W tym przykładzie przyjęto założenie, że wszystkie serwery mają obsługiwane wersje systemu Windows Server i że istnieje co najmniej jeden kontroler domeny systemu Windows dla każdej zaufanej domeny.

Przed skonfigurowaniem ograniczonego delegowania należy dodać RSAT-AD-PowerShell funkcję w celu zainstalowania modułu 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 użyjemy 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ć, patrząc na właściwość winrm StartName usługi:

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

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

Aby serwerC zezwolił na delegowanie z sesji komunikacji zdalnej programu PowerShell na serwerzeB, należy ustawić parametr PrincipalsAllowedToDelegateToAccount na ServerC na obiekt komputera 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

Centrum dystrybucji kluczy protokołu 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 SerweraC:

# 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 klasy ServerC, ustaw wartość parametru PrincipalsAllowedToDelegateToAccount na 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 utworzyć 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 ServerC, ustaw wartość parametru PrincipalsAllowedToDelegateToAccount na ServerC na wartość $null:

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ć delegowania bez ograniczeń 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 kontroluje miejsca użycia poświadczeń delegowanych. Jest mniej bezpieczny niż CredSSP. Ta metoda powinna być używana tylko w scenariuszach testowania.

Just Enough Administration (JEA)

Usługa JEA umożliwia ograniczenie poleceń, które administrator może uruchomić podczas sesji programu PowerShell. Można go użyć do rozwiązania problemu drugiego przeskoku.

Aby uzyskać informacje na temat serwera JEA, zobacz Just Enough Administracja istration.

Plusy

  • Brak konserwacji haseł podczas korzystania z konta wirtualnego.

Minusy

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

PsSessionConfiguration przy użyciu uruchomień

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 do komunikacji zdalnej programu PowerShell z wieloma przeskokami.

Plusy

  • Współpracuje z dowolnym serwerem z programem WMF 3.0 lub nowszym.

Minusy

  • 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 .

Plusy

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

Minusy

  • 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