Udostępnij za pomocą

Wykonywanie drugiego przeskoku w komunikacji zdalnej programu PowerShell

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

  1. Jesteś zalogowany na ServerA.
  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.

Konfiguracja Uwaga
Certyfikat CredSSP Równoważy łatwość użycia i bezpieczeństwo
Oparte na zasobach ograniczone delegowanie Kerberos Wyższe zabezpieczenia z prostszą konfiguracją
Delegowanie ograniczone Kerberos Wysoki poziom zabezpieczeń, ale wymaga administratora domeny
Delegowanie protokołu Kerberos (bez ograniczeń) Niezalecane
Just Enough Administration (JEA) Może zapewnić najlepsze zabezpieczenia, ale wymaga bardziej szczegółowej konfiguracji
PSSessionConfiguration z użyciem RunAs Prostsze konfigurowanie, ale wymaga zarządzania poświadczeniami
Przekaż poświadczenia w Invoke-Command bloku skryptu Najprostsze do użycia, ale należy podać poświadczenia

Certyfikat 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 na to, jak włączyć i używać protokołu CredSSP w przypadku komunikacji zdalnej przy użyciu PowerShell, zobacz Włączanie funkcji "Drugi przeskok" przy użyciu protokołu CredSSP w PowerShell.

Zalety

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

Delegowanie ograniczone Kerberos

Możesz użyć dziedziczonego ograniczonego delegowania (nieopartego 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.

Zalety

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

Minusy

  • Nie obsługuje drugiego etapu połączenia 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 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ą ustawioną właściwość Konto jest poufne i nie można delegować, nie mogą być delegowane. Aby uzyskać więcej informacji, zobacz Security Focus: Analizowanie 'konto jest wrażliwe i nie można go delegować' w kontekście kont uprzywilejowanych i Narzędzia i ustawienia uwierzytelniania Kerberos.

Oparte na zasobach ograniczone delegowanie Kerberos

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.

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.

Minusy

  • Wymaga systemu Windows Server 2012 lub nowszego.
  • Nie obsługuje drugiego etapu połączenia 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ą ustawioną właściwość Konto jest poufne i nie można delegować, nie mogą być delegowane. Aby uzyskać więcej informacji, zobacz Security Focus: Analizowanie 'konto jest wrażliwe i nie można go delegować' w kontekście kont uprzywilejowanych i Narzędzia i ustawienia uwierzytelniania Kerberos.

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 Active Directory msDS-AllowedToActOnBehalfOfOtherIdentity, który zawiera listę kontroli dostępu (ACL), określającą, które konta mają uprawnienia do delegowania poświadczeń do skojarzonego konta (w naszym przykładzie będzie to konto komputera dla ServerA).

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 zdalny dostęp PowerShell) jest domyślnie uruchamiana jako konto komputera. Możesz to zobaczyć, patrząc na właściwość winrm usługi:

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

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

Aby ServerC zezwolił na delegowanie z sesji zdalnej PowerShell na ServerB, 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 dostępu, które zostały odmówione (negatywna 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 Using: modyfikator zakresu jest używany do tworzenia zmiennej $ServerC widocznej dla ServerB. Aby uzyskać więcej informacji na temat Using: modyfikatora zakresu, zobacz about_Remote_Variables.

Aby umożliwić wielu serwerom delegowanie poświadczeń do 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ć protokołu Kerberos do delegowania bez ograniczeń, aby wykonać drugi przeskok. Podobnie jak w przypadku wszystkich scenariuszy Kerberos, poświadczenia nie są przechowywane. Ta metoda nie obsługuje drugiego etapu 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 o jea, zobacz Just Enough Administration (Just Enough Administration).

Zalety

  • 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 z użyciem RunAs

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

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

Zalety

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

Minusy

  • Wymaga konfiguracji PSSessionConfiguration i RunAs na każdym serwerze pośrednim (ServerB).
  • Wymaga zarządzania hasłami przy użyciu konta domeny RunAs

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

Poświadczenia można przekazać jako parametr ScriptBlock polecenia cmdlet Invoke-Command.

Zalety

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

# 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

  • Last updated on