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

  • Cikk

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

  1. A rendszer bejelentkezett 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 futtatott parancs a PowerShell-remoting munkameneten keresztül próbál hozzáférni egy erőforráshoz a ServerC-en.
  4. Az erőforráshoz való hozzáférés a ServerC-en megtagadva, mert a PowerShell-újraküldési munkamenet létrehozásához használt hitelesítő adatok nem lesznek átadva a ServerB-bőla ServerC-be.

A probléma többféleképpen is kezelhető. Az alábbi táblázat a kívánt sorrendben sorolja fel a metódusokat.

Konfiguráció Feljegyzés
CredSSP Egyensúlyba teszi a könnyű használatot és a biztonságot
Erőforrás-alapú Kerberos korlátozott delegálás Nagyobb biztonság egyszerűbb konfigurációval
Kerberos korlátozott delegálás Magas biztonság, de tartományi Rendszergazda istratort igényel
Kerberos-delegálás (nincs korlátozva) Nem ajánlott
Just Enough Administration (JEA) A legjobb biztonságot nyújthatja, de részletesebb konfigurációt igényel
PSSessionConfiguration futtatókörnyezetek használatával 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 hitelesítőadat-biztonsági támogatási szolgáltatót (CredSSP). A CredSSP gyorsítótárazza a hitelesítő adatokat a távoli kiszolgálón (ServerB), így használatával hitelesítő adatokkal kapcsolatos lopási támadásokat indíthat el. 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 is. Csak a legmegbízhatóbb környezetekben engedélyezze a CredSSP-t. Például egy tartományvezérlőhöz csatlakozó tartományi rendszergazda, mert a tartományvezérlő megbízható.

A CredSSP PowerShell-remotinghoz való használatakor felmerülő biztonsági problémákról további információt a Véletlen szabotázs: Óvakodj a CredSSP-ről című témakörben talál.

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-remotinghoz 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

  • A Windows Server 2008 vagy újabb rendszerű kiszolgálókon működik.

Hátrányok

  • Biztonsági résekkel rendelkezik.
  • Az ügyfél- és kiszolgálói szerepkörök konfigurálásához is szükség van.
  • nem működik a Védett felhasználók csoporttal. További információ: Védett felhasználók biztonsági csoport.

Kerberos korlátozott delegálás

A második ugráshoz használhat régi korlátozott delegálást (nem erőforrás-alapú). 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

  • Nincs szükség speciális kódolásra
  • 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 Rendszergazda istrator-hozzáférés szükséges.
  • A távoli kiszolgáló (ServerB) Active Directory-objektumán kell konfigurálni.
  • Egy tartományra korlátozva. Nem lehet tartományokat vagy erdőket keresztezni.
  • Az objektumok és a szolgáltatásnévnevek (SPN-ek) frissítésére vonatkozó jogosultságokat igényel.
  • A ServerB felhasználói beavatkozás nélkül beszerezhet egy Kerberos-jegyet a ServerC-be a felhasználó nevében.

Feljegyzés

A fiókkal rendelkező Active Directory-fiókok bizalmasak, és nem delegálhatók delegálható tulajdonságkészletek. További információkért lásd: "A fiók bizalmas és nem delegálható" elemelemzés a kiemelt fiókokhoz, a Kerberos-hitelesítési eszközökhöz és a Gépház.

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

Az erőforrás-alapú Kerberos korlátozott delegálás (a Windows Server 2012-ben bevezetett) használatával konfigurálja 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 megadja, 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 Rendszergazda istrator-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.
  • Az objektumok és a szolgáltatásnévnevek (SPN-ek) frissítésére vonatkozó jogosultságokat igényel.

Feljegyzés

A fiókkal rendelkező Active Directory-fiókok bizalmasak, és nem delegálhatók delegálható tulajdonságkészletek. További információkért lásd: "A fiók bizalmas és nem delegálható" elemelemzés a kiemelt fiókokhoz, a Kerberos-hitelesítési eszközökhöz és a Gépház.

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-en, hogy engedélyezze a delegált hitelesítő adatokat egy ServerB-ből. Ez a példa feltételezi, hogy minden kiszolgáló a Windows Server támogatott verzióit futtatja, és hogy minden megbízható tartományhoz legalább egy Windows tartományvezérlő tartozik.

A korlátozott delegálás konfigurálása előtt hozzá kell adnia a funkciót 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 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 hitelesítő adatok delegálásához a társított fiókhoz (a példában ez lesz a KiszolgálóA gépfiókja).

Most állítsuk be a kiszolgálókat ábrázoló változókat:

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

A WinRM (és így a PowerShell-újramoting) 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-újrametszési munkamenetből a ServerB-en, a ServerC PrincipalsAllowedToDelegateToAccount paraméterét a ServerB számítógépobjektumá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 Key Distribution Center (KDC) 15 percig gyorsítótárazza a megtagadott hozzáférésű 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 legalább 15 percet várhat a gyorsítótár törléséhez.

A gyorsítótár törlése után sikeresen futtathat kódot a ServerA-ból a ServerB-bő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 változót $using arra használjuk, hogy láthatóvá tegye a változót a $ServerC ServerB számára. A változóval kapcsolatos további információkért lásd: $using about_Remote_Variables.

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

# 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 tartományvezérlőjének 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

A hitelesítő adatok ServerC-hez való delegálásának eltávolításához állítsa a ServerC PrincipalsAllowedToDelegateToAccount paraméterének értékét a következő értékre$null:

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

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

Kerberos-delegálás (nincs korlátozva)

A Kerberos korlátozás nélküli delegálásával is elvégezheti a második ugrást. Mint minden Kerberos-forgatókönyvben, 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 hol használják 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 lehetővé teszi, hogy korlátozza a rendszergazda által futtatható parancsokat a PowerShell-munkamenetek során. A második ugrási probléma megoldására használható.

További információ a JEA-ról: Just Enough Rendszergazda istration.

Előnyök

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

Hátrányok

  • A WMF 5.0-s vagy újabb verziójára van szükség.
  • Konfigurálást igényel minden köztes kiszolgálón (ServerB).

PSSessionConfiguration futtatókörnyezetek használatával

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

A PSSessionConfiguration és a futtatókörnyezetek második ugrással kapcsolatos problémájának megoldásáról további információt a PowerShell több ugrásos újratelepítésének másik megoldása című témakörben talál.

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 a RunA konfigurálásáhozminden köztes kiszolgálón (ServerB) szükség van.
  • Jelszókarbantartást igényel tartományi futtató fiók használata esetén

Hitelesítő adatok átadása egy meghívási parancs szkriptblokkon belül

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

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ása esetén 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 adhat át 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