Druhé směrování při vzdálené komunikaci PowerShellu

Problém druhého segmentu směrování odkazuje na situaci, jako je následující:

  1. Jste přihlášeni k ServeruA.
  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 ServeruC 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 ServeruB do ServeruC.

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

Konfigurace Poznámka
CredSSP Vyvážení snadného používání a zabezpečení
Omezené delegování Kerberos založené na prostředcích Vyšší zabezpečení s jednodušší konfigurací
Omezené delegování Protokolu Kerberos Vysoké zabezpečení, ale vyžaduje správce domény.
Delegování Kerberos (bez trénování) Nedoporučuje se
Funkce 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ů
Předání přihlašovacích údajů uvnitř Invoke-Command bloku skriptu Nejjednodušší použití, 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 jeho použití vám otevře útoky na krádež 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í na klientských i serverových počítačích zakázaná. CredSSP byste měli povolit jenom v nejdůvěryhodně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 naleznete v tématu Náhodné sabotování: Pozor na CredSSP.

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

Příklad povolení a použití CredSSP pro vzdálené komunikace PowerShellu najdete v tématu Povolení funkce Druhého směrování PowerShellu s CredSSP.

Výhody

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

Nevýhody

Omezené delegování Protokolu Kerberos

K vytvoření druhého segmentu směrování můžete použít starší omezené delegování (nikoli na základě prostředků). Nakonfigurujte omezené delegování protokolu Kerberos s možností Použít libovolný ověřovací protokol, který umožňuje přechod protokolu.

Výhody

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

Nevýhody

  • Nepodporuje druhý segment směrování pro WinRM.
  • Vyžaduje přístup správce domény ke konfiguraci.
  • Musí být nakonfigurovaný na objektu služby Active Directory vzdáleného serveru (ServerB).
  • Omezeno na jednu doménu. Nelze překračovat domény nebo doménové struktury.
  • Vyžaduje práva k aktualizaci objektů a hlavních názvů služby (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 delegovat sadu vlastností. Další informace naleznete v tématu Zaměření na zabezpečení: Analýza účtu je citlivá a nelze ji delegovat pro privilegované účty a ověřovací nástroje protokolu Kerberos a nastavení.

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

Pomocí omezeného delegování Kerberos založeného na prostředcích (zavedených v Windows Server 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 segmentu směrování 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 ke konfiguraci přístup správce domény.
  • Funguje napříč doménami a doménovými strukturami.

Nevýhody

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

Poznámka

Účty služby Active Directory, které mají účet, jsou citlivé a nelze delegovat sadu vlastností. Další informace naleznete v tématu Zaměření na zabezpečení: Analýza účtu je citlivá a nelze ji delegovat pro privilegované účty a ověřovací nástroje protokolu Kerberos a nastavení.

Příklad

Podívejme se na příklad PowerShellu, který konfiguruje omezené delegování založené na prostředcích na ServeruC tak, aby umožňovalo delegované přihlašovací údaje ze serveruB. V tomto příkladu se předpokládá, že všechny servery běží Windows Server 2012 nebo novějším a že existuje alespoň jeden Windows Server 2012 řadič domény, do kterého patří některá z těchto serverů.

Než budete moct nakonfigurovat omezené delegování, musíte tuto funkci přidat RSAT-AD-PowerShell , abyste nainstalovali modul Active Directory PowerShellu, a pak tento modul naimportovali do relace:

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

Několik dostupných rutin teď 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 služby 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 proto vzdálené komunikace PowerShellu) běží jako účet počítače ve výchozím nastavení. Můžete to zobrazit tak, že se podíváte na vlastnost winrmStartName služby:

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

Aby serverC povolil delegování z relace vzdálené komunikace PowerShellu na ServeruB, musíme nastavit parametr PrincipalsAllowedToDelegateToAccount na ServerC na objekt počítače ServeruB:

# 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

Úložiště KDC (Key Distribution Center) protokolu Kerberos ukládá do mezipaměti pokusy o odepření přístupu (záporná mezipaměť) po dobu 15 minut. Pokud se ServerB dříve pokusil o přístup k ServeruC, budete muset vymazat mezipaměť na ServeruB 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 ze ServeruA přes ServerB na 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)
}

V tomto příkladu se $using proměnná používá k tomu, aby $ServerC byla proměnná viditelná pro ServerB. Další informace o $using proměnné najdete v tématu about_Remote_Variables.

Pokud chcete více serverů povolit delegování přihlašovacích údajů 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ý segment směrování napříč doménami, pomocí parametru Server zadejte plně kvalifikovaný název domény (FQDN) řadiče domény domény, do které 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 ServeruC na $null:

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

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

Delegování protokolu Kerberos (bez trénování)

K vytvoření druhého segmentu směrování můžete použít také nekontrénované delegování protokolu Kerberos. Stejně jako všechny scénáře Kerberos se přihlašovací údaje neukládají. Tato metoda nepodporuje druhý segment směrování pro WinRM.

Upozorně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.

Funkce Just Enough Administration (JEA)

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

Informace o funkci JEA najdete v tématu Just Enough Administration.

Výhody

  • Při používání virtuálního účtu není žádná údržba hesel.

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 ServeruB a nastavit jeho parametr RunAsCredential .

Informace o použití psSessionConfiguration a RunA k řešení problému s druhým segmentem směrování najdete v tématu Další řešení vzdálené komunikace PowerShellu s více segmenty směrování.

Výhody

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

Nevýhody

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

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

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

Výhody

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

Nevýhody

  • Vyžaduje nepříjemnou techniku kódu.
  • 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