Sdílet prostřednictvím

Druhý skok při vzdálené správě PowerShellu

Problém druhého skoku se týká situace, jako je následující:

  1. Jste přihlášeni na ServerA.
  2. Ze serveru A spustíte vzdálenou relaci PowerShellu pro připojení k ServeruB.
  3. Příkaz, který spustíte na ServeruB prostřednictvím relace vzdálené komunikace PowerShellu, se pokusí o přístup k prostředku na ServeruC.
  4. Přístup k prostředku na ServerC je odepřen, protože přihlašovací údaje, které jste použili k vytvoření relace vzdálené komunikace PowerShellu, se nepředá z ServerB do ServerC.

Existuje několik způsobů, jak tento problém vyřešit. Následující tabulka uvádí metody v pořadí podle priority.

Konfigurace Poznámka:
CredSSP Vyvážení snadného používání a zabezpečení
Kerberos omezené delegování založené na prostředcích Vyšší zabezpečení s jednodušší konfigurací
Omezené delegování Kerberos Vysoké zabezpečení, ale vyžaduje správce domény
Delegování protokolu Kerberos (neomezené) Nedoporučuje se
Just Enough Administration (JEA) Může poskytovat nejlepší zabezpečení, ale vyžaduje podrobnější konfiguraci.
PSSessionConfiguration s využitím RunAs Jednodušší konfigurace, ale vyžaduje správu přihlašovacích údajů
Zadejte přihlašovací údaje do bloku skriptu Invoke-Command. Nejjednodušší použít, ale musíte zadat přihlašovací údaje.

CredSSP

K ověřování můžete použít zprostředkovatele podpory zabezpečení přihlašovacích údajů (CredSSP). CredSSP ukládá přihlašovací údaje do mezipaměti na vzdáleném serveru (ServerB), takže při jeho použití se vystavujete riziku krádeže přihlašovacích údajů. Pokud dojde k ohrožení zabezpečení vzdáleného počítače, má útočník přístup k přihlašovacím údajům uživatele. CredSSP je ve výchozím nastavení zakázán na klientských i serverových počítačích. CredSSP byste měli povolit jenom v nejvěřenějších prostředích. Správce domény se například připojuje k řadiči domény, protože řadič domény je vysoce důvěryhodný.

Další informace o obavách zabezpečení při použití CredSSP pro vzdálené komunikace PowerShellu najdete v tématu Náhodné sabotáže: Pozor na credSSP.

Další informace o krádeži přihlašovacích údajů najdete v tématu zmírnění útoků pass-the-hash (PtH) a jiných krádeží přihlašovacích údajů.

Příklad, jak povolit a používat CredSSP pro vzdálenou správu PowerShellu, najdete v tématu Povolení funkce "Second-Hop" v CredSSP.

Výhody

  • Funguje pro všechny servery se systémem Windows Server 2008 nebo novějším.

Nevýhody

Omezené delegování Kerberos

K provedení druhého kroku můžete použít starší omezené delegování (nikoli založené na prostředcích). Nakonfigurujte omezené delegování protokolu Kerberos s volbou "Použít libovolný ověřovací protokol" pro povolení přechodu protokolu.

Výhody

  • Nevyžaduje žádné speciální kódování.
  • Přihlašovací údaje se neukládají.

Nevýhody

  • Nepodporuje druhý přeskok pro WinRM.
  • Vyžaduje přístup správce domény ke konfiguraci.
  • Musí být nakonfigurován na objekt služby Active Directory vzdáleného serveru (ServerB).
  • Omezeno na jednu doménu. Nelze překročit mezi doménami ani lesy.
  • Vyžaduje práva k aktualizaci objektů a hlavních názvů služeb (SPN).
  • ServerB může získat lístek Kerberos pro ServerC jménem uživatele bez zásahu uživatele.

Poznámka:

Účty služby Active Directory, které mají Účet, jsou citlivé a nelze je delegovat, sadu vlastností nelze delegovat. Další informace najdete v tématu Zaměření na zabezpečení: Analyzovat 'Účet je citlivý a nelze ho delegovat' u privilegovaných účtů a nástroje a nastavení ověřování Kerberos.

Kerberos omezené delegování založené na prostředcích

Pomocí omezeného delegování Kerberos založeného na prostředcích (zavedených ve Windows Serveru 2012) nakonfigurujete delegování přihlašovacích údajů na objektu serveru, ve kterém se nacházejí prostředky. Ve scénáři druhého hopu popsaném výše nakonfigurujete ServerC tak, aby určil, odkud přijímá delegované přihlašovací údaje.

Výhody

  • Přihlašovací údaje se neukládají.
  • Nakonfigurováno pomocí rutin PowerShellu. Nevyžaduje se žádné speciální kódování.
  • Nevyžaduje přístup správce domény ke konfiguraci.
  • Funguje napříč doménami a lesy.

Nevýhody

  • Vyžaduje Windows Server 2012 nebo novější.
  • Nepodporuje druhý přeskok pro WinRM.
  • Vyžaduje práva k aktualizaci objektů a hlavních názvů služeb (SPN).

Poznámka:

Účty služby Active Directory, které mají Účet, jsou citlivé a nelze je delegovat, sadu vlastností nelze delegovat. Další informace najdete v tématu Zaměření na zabezpečení: Analyzovat 'Účet je citlivý a nelze ho delegovat' u privilegovaných účtů a nástroje a nastavení ověřování Kerberos.

Příklad

Podívejme se na příklad PowerShellu, který konfiguruje delegování s omezením na základě prostředků na ServerC umožňující delegované přihlašovací údaje ze ServerB. Tento příklad předpokládá, že všechny servery používají podporované verze Windows Serveru a že pro každou důvěryhodnou doménu existuje aspoň jeden řadič domény Windows.

Než budete moct nakonfigurovat omezené delegování, musíte přidat funkci RSAT-AD-PowerShell, aby se nainstaloval modul PowerShellu služby Active Directory, a pak tento modul naimportovat do relace:

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

Několik dostupných cmdletů nyní má 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 nastaví atribut objektu Active Directory msDS-AllowedToActOnBehalfOfOtherIdentity, který obsahuje seznam řízení přístupu (ACL), který určuje, které účty mají oprávnění delegovat přihlašovací údaje k přidruženému účtu (v našem příkladu to bude účet počítače pro ServerA).

Teď nastavíme proměnné, které použijeme k reprezentaci serverů:

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

WinRM (a tím i vzdálené spuštění přes PowerShell) se ve výchozím nastavení spouští jako účet počítače. Můžete to zobrazit tak, že se podíváte na vlastnost StartName služby winrm:

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

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

Pro povolení delegování z relace PowerShellu na vzdáleném ServerC na ServerBje potřeba nastavit parametr PrincipalsAllowedToDelegateToAccount na ServerC na objekt počítače 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

Služba Kerberos Key Distribution Center (KDC) ukládá do mezipaměti pokusy o odepření přístupu (záporná mezipaměť) po dobu 15 minut. Pokud se ServerB dříve pokusili o přístup k ServerC, musíte vymazat mezipaměť na ServerB vyvoláním následujícího příkazu:

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

Můžete také restartovat počítač nebo počkat alespoň 15 minut, než vymažete mezipaměť.

Po vymazání mezipaměti můžete úspěšně spustit kód z ServerA prostřednictvím ServerBServerC:

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

V tomto příkladu se modifikátor oboru Using: používá k tomu, aby byla proměnná $ServerC viditelná pro ServerB. Další informace o oborovém modifikátoru Using: najdete v tématu about_Remote_Variables.

Aby bylo možné umožnit více serverům delegovat přihlašovací údaje na ServerC, nastavte hodnotu parametru PrincipalsAllowedToDelegateToAccount na ServerC na pole:

# 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

Pokud chcete provést druhý přeskok napříč doménami, pomocí parametru Server zadejte plně kvalifikovaný název domény (FQDN) řadiče domény, ke kterému ServerB patří:

# 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

Pokud chcete odebrat možnost delegovat přihlašovací údaje na ServerC, nastavte hodnotu parametru PrincipalsAllowedToDelegateToAccount na ServerC na $null:

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

Informace o omezeném delegování pomocí Kerbera s využitím zdrojů

Delegování protokolu Kerberos (neomezené)

Druhý skok můžete také provést pomocí neomezeného delegování Kerberos. Stejně jako všechny scénáře Kerberos se přihlašovací údaje neukládají. Tato metoda nepodporuje druhý krok pro WinRM.

Varování

Tato metoda neposkytuje žádnou kontrolu nad tím, kde se používají delegovaná pověření. Je méně zabezpečený než CredSSP. Tato metoda by se měla používat pouze pro testovací scénáře.

Just Enough Administration (JEA)

FUNKCE JEA umožňuje omezit, které příkazy může správce spustit během relace PowerShellu. Dá se použít k vyřešení problému druhého hopu.

Informace o JEA viz Just Enough Administration.

Výhody

  • Při použití virtuálního účtu není údržba hesla.

Nevýhody

  • Vyžaduje WMF 5.0 nebo novější.
  • Vyžaduje konfiguraci na každém zprostředkujícím serveru (ServerB).

PSSessionConfiguration s využitím RunAs

Konfiguraci relace můžete vytvořit na ServerB a nastavit její Parametr RunAsCredential.

Informace o použití PSSessionConfiguration a RunAs k řešení problému druhého skoku najdete v tématu Jiné řešení vícenásobného přeskoku v PowerShell remotingu.

Výhody

  • Funguje s libovolným serverem s WMF 3.0 nebo novějším.

Nevýhody

  • Vyžaduje konfiguraci PSSessionConfiguration a Spustit jako na každém zprostředkujícím serveru (ServerB).
  • Vyžaduje údržbu hesla při použití účtu Spustit jako domény.

Předání přihlašovacích údajů uvnitř bloku skriptu Invoke-Command

Přihlašovací údaje můžete předat uvnitř parametru ScriptBlock při volání cmdletu Invoke-Command.

Výhody

  • Nevyžaduje speciální konfiguraci serveru.
  • Funguje na jakémkoli serveru se systémem WMF 2.0 nebo novějším.

Nevýhody

  • Vyžaduje neohrabanou programovací techniku.
  • Pokud používáte WMF 2.0, vyžaduje pro předávání argumentů vzdálené relaci jinou syntaxi.

Příklad

Následující příklad ukazuje, jak předat přihlašovací údaje v bloku skriptu:

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

Viz také

aspekty zabezpečení vzdálené komunikace PowerShellu

  • Last updated on