A második ugrás végrehajtása a PowerShell távoli eljáráshívásai során

A "második ugrási probléma" az alábbihoz hasonló helyzetre utal:

  1. Be van jelentkezve a ServerA-ba.
  2. A ServerA-ból elindít egy távoli PowerShell-munkamenetet a ServerB-hez való csatlakozáshoz.
  3. A ServerB-en a PowerShell-távelérési munkameneten keresztül futtatott parancs megpróbál hozzáférni egy erőforráshoz a ServerC-en.
  4. A Rendszer megtagadja az erőforráshoz való hozzáférést a ServerC-en , mert a PowerShell-távelérési munkamenet létrehozásához használt hitelesítő adatok nem lesznek átadva a ServerB-ből a ServerC-nek.

Ezt a problémát többféleképpen is megoldhatja. Az alábbi táblázat a metódusokat sorolja fel előnyben részesített sorrendben.

Konfiguráció Megjegyzés
CredSSP Kiegyensúlyozza a könnyű használatot és a biztonságot
Erőforrás-alapú korlátozott Kerberos-delegálás Nagyobb biztonság egyszerűbb konfigurációval
Kerberos által korlátozott delegálás Magas szintű biztonság, de tartományi rendszergazdát igényel
Kerberos-delegálás (nem korlátozott) Nem ajánlott
Just Enough Administration (JEA) A legjobb biztonságot nyújtja, de részletesebb konfigurálást igényel
PSSessionConfiguration futtató fiókokkal Egyszerűbben konfigurálható, de hitelesítő adatok kezelését igényli
Hitelesítő adatok átadása szkriptblokkon Invoke-Command belül A legegyszerűbben használható, de meg kell adnia a hitelesítő adatokat

CredSSP

A hitelesítéshez használhatja a Credential Security Support Providert (CredSSP ). A CredSSP gyorsítótárazza a hitelesítő adatokat a távoli kiszolgálón (ServerB), így a használatával a hitelesítő adatok ellopására irányuló támadásokat indíthat. Ha a távoli számítógép biztonsága sérül, a támadó hozzáfér a felhasználó hitelesítő adataihoz. A CredSSP alapértelmezés szerint le van tiltva az ügyfél- és kiszolgálószámítógépeken. A CredSSP-t csak a legmegbízhatóbb környezetekben engedélyezze. Például egy tartományi rendszergazda azért csatlakozik egy tartományvezérlőhöz, mert a tartományvezérlő megbízható.

További információ a CredSSP PowerShell-táveléréshez való használata során felmerülő biztonsági problémákról : Véletlen szabotázs: Vigyázz a CredSSP-re.

További információ a hitelesítő adatok ellopásával kapcsolatos támadásokról: Pass-the-Hash (PtH) támadások és egyéb hitelesítő adatok ellopása.

A CredSSP PowerShell-táveléréshez való engedélyezésére és használatára vonatkozó példa: A PowerShell "Second-Hop" funkciójának engedélyezése a CredSSP-vel.

Előnyök

  • Minden Windows Server 2008 vagy újabb rendszerű kiszolgáló esetében működik.

Hátrányok

  • Biztonsági résekkel rendelkezik.
  • Ügyfél- és kiszolgálói szerepkörök konfigurálását igényli.
  • Nem működik a Védett felhasználók csoporttal. További információ: Védett felhasználók biztonsági csoport.

Kerberos által korlátozott delegálás

A második ugráshoz használhat örökölt korlátozott delegálást (nem erőforrás-alapút). Konfigurálja a Kerberos által korlátozott delegálást a "Bármely hitelesítési protokoll használata" beállítással a protokollváltás engedélyezéséhez.

Előnyök

  • Nem igényel speciális kódolást
  • A hitelesítő adatok nincsenek tárolva.

Hátrányok

  • Nem támogatja a WinRM második ugrását.
  • A konfiguráláshoz tartományi rendszergazdai hozzáférés szükséges.
  • Konfigurálni kell a távoli kiszolgáló (ServerB) Active Directory-objektumán.
  • Egy tartományra korlátozva. Nem lehet tartományokat vagy erdőket keresztezni.
  • Jogosultságot igényel az objektumok és egyszerű szolgáltatásnevek (SPN-ek) frissítéséhez.
  • A ServerB felhasználói beavatkozás nélkül tud Kerberos-jegyet beszerezni a ServerC-hez a felhasználó nevében.

Megjegyzés

A fiókkal rendelkező, delegált tulajdonságkészlettel nem rendelkező Active Directory-fiókok nem delegálhatók. További információ : Biztonsági fókusz: "A fiók bizalmas, és nem delegálható" elemzendő a kiemelt jogosultságú fiókokhoz és a Kerberos-hitelesítési eszközökhöz és -beállításokhoz.

Erőforrás-alapú korlátozott Kerberos-delegálás

Az erőforrás-alapú korlátozott Kerberos-delegálással (amelyet a Windows Server 2012 vezetünk be) konfigurálhatja a hitelesítő adatok delegálását azon a kiszolgálóobjektumon, ahol az erőforrások találhatók. A fent ismertetett második ugrási forgatókönyvben úgy konfigurálja a ServerC-t , hogy meghatározza, honnan fogadja el a delegált hitelesítő adatokat.

Előnyök

  • A hitelesítő adatok nincsenek tárolva.
  • PowerShell-parancsmagokkal konfigurálva. Nincs szükség speciális kódolásra.
  • Nincs szükség tartományi rendszergazdai hozzáférésre a konfiguráláshoz.
  • Tartományok és erdők között működik.

Hátrányok

  • Windows Server 2012 vagy újabb verziót igényel.
  • Nem támogatja a WinRM második ugrását.
  • Jogosultságot igényel az objektumok és egyszerű szolgáltatásnevek (SPN-ek) frissítéséhez.

Megjegyzés

A fiókkal rendelkező, delegált tulajdonságkészlettel nem rendelkező Active Directory-fiókok nem delegálhatók. További információ : Biztonsági fókusz: "A fiók bizalmas, és nem delegálható" elemzendő a kiemelt jogosultságú fiókokhoz és a Kerberos-hitelesítési eszközökhöz és -beállításokhoz.

Példa

Tekintsünk meg egy PowerShell-példát, amely úgy konfigurálja az erőforrás-alapú korlátozott delegálást a ServerC-n , hogy engedélyezze a delegált hitelesítő adatokat a ServerB-ről. Ez a példa feltételezi, hogy az összes kiszolgáló Windows Server 2012 vagy újabb rendszert futtat, és legalább egy Windows Server 2012 tartományvezérlő van minden olyan tartományhoz, amelyhez a kiszolgálók tartoznak.

A korlátozott delegálás konfigurálása előtt hozzá kell adnia a szolgáltatást az RSAT-AD-PowerShell Active Directory PowerShell-modul telepítéséhez, majd importálnia kell a modult a munkamenetbe:

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

Több elérhető parancsmag most már rendelkezik PrincipalsAllowedToDelegateToAccount paraméterrel:

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

A PrincipalsAllowedToDelegateToAccount paraméter beállítja az msDS-AllowedToActOnBehalfOfOtherIdentity Active Directory-objektumattribútumot, amely egy hozzáférés-vezérlési listát (ACL) tartalmaz, amely meghatározza, hogy mely fiókok rendelkeznek engedéllyel a hitelesítő adatok a társított fiókhoz való delegálásához (a példánkban ez lesz a ServerA számítógépfiókja).

Most állítsuk be azokat a változókat, amelyek a kiszolgálókat jelölik:

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

A WinRM (és így a PowerShell-távelérés) alapértelmezés szerint számítógépfiókként fut. Ezt a szolgáltatás StartName tulajdonságának winrm megtekintésével tekintheti meg:

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

Ahhoz, hogy a ServerC engedélyezze a Delegálást egy PowerShell-távelérési munkamenetből a ServerB-n, a ServerC PrincipalsAllowedToDelegateToAccount paraméterét a ServerB számítógép-objektumára kell állítani:

# 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

A Kerberos kulcsterjesztési központ (KDC) 15 percig gyorsítótárazza a megtagadott hozzáférési kísérleteket (negatív gyorsítótár). Ha a ServerB korábban megkísérelte elérni a ServerC-t, a következő parancs meghívásával törölnie kell a gyorsítótárat a ServerB-en :

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

Újraindíthatja a számítógépet, vagy várhat legalább 15 percet a gyorsítótár kiürítéséhez.

A gyorsítótár kiürítése után sikeresen futtathat kódot a ServerA-bóla ServerB-n keresztül a ServerC-be:

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

Ebben a példában a $using változót arra használjuk, hogy láthatóvá tegye a változót a $ServerCServerB számára. A változóval kapcsolatos további információkért lásd a $usingabout_Remote_Variables.

Ha engedélyezni szeretné, hogy több kiszolgáló hitelesítő adatokat delegáljon a ServerC-nek, állítsa a PrincipalsAllowedToDelegateToAccount paraméter értékét egy tömbre a ServerC-n :

# 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

Ha a második ugrást a tartományok között szeretné elvégezni, a Kiszolgáló paraméterrel adja meg annak a tartománynak a teljes tartománynevét (FQDN), amelyhez a ServerB tartozik:

# 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

Ha el szeretné távolítani a hitelesítő adatok ServerC-be történő delegálásának lehetőségét, állítsa a PrincipalsAllowedToDelegateToAccount paraméter értékét a következőre$nulla ServerC-n:

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

Információ az erőforrás-alapú korlátozott Kerberos-delegálásról

Kerberos-delegálás (nem korlátozott)

A Kerberos nem korlátozott delegálásával is elvégezheti a második ugrást. Az összes Kerberos-forgatókönyvhez hasonlóan a hitelesítő adatok sem tárolódnak. Ez a metódus nem támogatja a WinRM második ugrását.

Figyelmeztetés

Ez a módszer nem szabályozza, hogy a rendszer hol használja a delegált hitelesítő adatokat. Kevésbé biztonságos, mint a CredSSP. Ez a módszer csak tesztelési forgatókönyvekhez használható.

Just Enough Administration (JEA)

A JEA segítségével korlátozhatja, hogy a rendszergazda milyen parancsokat futtathat egy PowerShell-munkamenet során. A második ugrási probléma megoldására használható.

A JEA-ról további információt a Just Enough Administration (Elegendő felügyelet) című témakörben talál.

Előnyök

  • Virtuális fiók használata esetén nincs jelszókarbantartás.

Hátrányok

  • WMF 5.0-s vagy újabb verziót igényel.
  • Konfigurálást igényel minden köztes kiszolgálón (ServerB).

PSSessionConfiguration futtató fiókokkal

Létrehozhat egy munkamenet-konfigurációt a ServerB-en , és beállíthatja annak RunAsCredential paraméterét.

További információ a PSSessionConfiguration és a futtató példányok használatáról a második ugrási probléma megoldásához: Egy másik megoldás a több ugrásos PowerShell-remotingra.

Előnyök

  • Bármely kiszolgálóval együttműködik a WMF 3.0-s vagy újabb verziójával.

Hátrányok

  • A PSSessionConfiguration és futtató kiszolgálók konfigurálását igényli minden köztes kiszolgálón (ServerB).
  • Jelszókarbantartást igényel tartományi futtató fiók használata esetén

Hitelesítő adatok átadása Invoke-Command szkriptblokkban

A hitelesítő adatokat az Invoke-Command parancsmag hívásának ScriptBlock paraméterén belül adhatja át.

Előnyök

  • Nincs szükség speciális kiszolgálókonfigurációra.
  • Bármely WMF 2.0-s vagy újabb rendszert futtató kiszolgálón működik.

Hátrányok

  • Kínos kódtechnikát igényel.
  • A WMF 2.0 futtatásakor az argumentumok távoli munkamenetbe való továbbításához eltérő szintaxis szükséges.

Példa

Az alábbi példa bemutatja, hogyan adhatja át a hitelesítő adatokat egy szkriptblokkban:

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

Lásd még

PowerShell távoli eljáráshívásainak biztonsági megfontolásai