Sdílet prostřednictvím

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

  • Článek

Problém druhého segmentu směrování se týká situace, jako je následující:

  1. Jste přihlášeni k serveru A.
  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 priority.

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í kerberos Vysoké zabezpečení, ale vyžaduje Správa istrator domény.
Delegování protokolu 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ží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 použití se 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í 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áž: Pozor na CredSSP.

Další informace o útocích krádeže přihlašovacích údajů najdete v tématu Zmírnění útoků typu 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 "Second-Hop" PowerShellu s CredSSP.

Výhody

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

Nevýhody

  • Obsahuje ohrožení zabezpečení.
  • Vyžaduje konfiguraci rolí klienta i serveru.
  • nefunguje se skupinou Chránění uživatelé. Další informace naleznete v tématu Skupina zabezpečení Chránění uživatelé.

Omezené delegování kerberos

K vytvoření druhého segmentu směrování můžete použít starší omezené delegování (nikoli založené na prostředcích). Nakonfigurujte omezené delegování protokolu Kerberos s možností 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ý segment směrování pro WinRM.
  • Ke konfiguraci vyžaduje přístup k doméně Správa istrator.
  • Musí být nakonfigurovaný na objektu služby Active Directory vzdáleného serveru (ServerB).
  • Omezeno na jednu doménu. Nejde přechádět mezi doménami ani doménovými strukturami.
  • 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 nejde delegovat sadu vlastností. Další informace najdete v tématu Zaměření na zabezpečení: Analýza účtu je citlivá a nedá se delegovat pro privilegované účty a ověřovací nástroje 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 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 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 k doméně Správa istrator.
  • 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žeb (SPN).

Poznámka:

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

Příklad

Podívejme se na příklad PowerShellu, který konfiguruje omezené delegování na serveru ServerC na základě prostředků tak, aby umožňovalo delegované přihlašovací údaje ze serveruB. 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 RSAT-AD-PowerShell funkci pro instalaci modulu Active Directory PowerShellu a pak tento modul importovat 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 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 se jedná o úč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) 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 winrm StartName 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

Služba Kerberos Key Distribution Center (KDC) do mezipaměti odepře pokusy o přístup (záporná mezipaměť) po dobu 15 minut. Pokud se ServerB dříve pokusil o přístup k ServeruC, musíte 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 $using se 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 povolit delegování přihlašovacích údajů na ServerC více serverů, nastavte hodnotu parametru PrincipalsAllowedToDelegateToAccount na ServeruC 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, 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í)

Druhý segment směrování můžete také provést pomocí nekontrénovaného delegování 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.

Upozorňující

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, které příkazy může správce spustit během relace PowerShellu. Dá se použít k vyřešení problému druhého segmentu směrování.

Informace o FUNKCI JEA naleznete v tématu Just Enough Správa istration.

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

Informace o použití PSSessionConfiguration a RunAs 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 libovolným 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 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 v parametru ScriptBlock volání rutiny 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 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