Megosztás a következőn keresztül:

A második ugrás végrehajtása a PowerShell távvezérlés során

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

  1. Ön be van jelentkezve a ServerAszerverre.
  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. Hozzáférés megtagadva az erőforráshoz a(z) ServerC-en, mert a PowerShell-távoli elérés munkamenet létrehozásához használt hitelesítő adatok nem kerülnek átadásra a(z) ServerB-ról a(z) ServerC-re.

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ó Megjegyzé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 szükséges
Kerberos-delegálás (korlátozás nélkül) Nem ajánlott
Éppen elegendő adminisztráció (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 Invoke-Command szkriptblokkon 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 a használata kitesz a hitelesítő adatokkal kapcsolatos lopási támadások kockázatának. 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álata során felmerülő biztonsági problémákról további információt a Véletlen szabotázs: Óvakodj a CredSSP-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éről és használatáról a PowerShell "Second-Hop" funkciójának engedélyezése a CredSSPcímű témakörben olvashat.

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 rendszergazdai hozzáférés szükséges.
  • A távoli kiszolgáló Active Directory-objektumán (ServerB) 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.
  • ServerB felhasználói beavatkozás nélkül szerezhet be Kerberos-jegyet ServerC számára.

Megjegyzés

Az fiókkal rendelkező Active Directory-fiókok bizalmasak, és nem delegálhatók tulajdonságkészlet nem delegálható. További információért lásd: Biztonsági fókusz: "A fiók bizalmas, és nem delegálható" elemzése a kiemelt jogosultságú fiókokkal kapcsolatosan, valamint a Kerberos-hitelesítési eszközök és beállítások.

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 ServerC konfigurálásával adja meg, hogy 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.
  • Az objektumok és a szolgáltatásnévnevek (SPN-ek) frissítésére vonatkozó jogosultságokat igényel.

Megjegyzés

Az fiókkal rendelkező Active Directory-fiókok bizalmasak, és nem delegálhatók tulajdonságkészlet nem delegálható. További információért lásd: Biztonsági fókusz: "A fiók bizalmas, és nem delegálható" elemzése a kiemelt jogosultságú fiókokkal kapcsolatosan, valamint a Kerberos-hitelesítési eszközök és beállítások.

Példa

Tekintsünk meg egy PowerShell-példát, amely erőforrás-alapú korlátozott delegálást konfigurál ServerC-on, hogy lehetővé tegye a hitelesítő adatok delegálását ServerB-ró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 RSAT-AD-PowerShell funkciót az 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ő parancsmaghoz most már tartozik egy PrincipalsAllowedToDelegateToAccount paraméter.

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 Active Directory objektumattribútumot msDS-AllowedToActOnBehalfOfOtherIdentity, 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 ServerAgé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 távelérés) alapértelmezés szerint a számítógép fiókként fut. Ezt a szolgáltatás winrm tulajdonságában tekintheti meg:

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

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

Ahhoz, hogy a ServerC lehetővé tegye a jogosultságátvitel egy PowerShell távvezérlői munkamenetből a ServerBszerverre, be kell állítanunk a PrincipalsAllowedToDelegateToAccount paramétert a ServerC szerveren a ServerBszámítógép objektumára.

# 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 ServerB korábban megkísérelte elérni ServerC, a következő parancs meghívásával törölnie kell a gyorsítótárat ServerB:

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 ServerAServerB keresztül 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)
}

Ebben a példában a Using: hatókör-módosítót használják arra, hogy a $ServerC változó láthatóvá váljon a ServerBszámára. A hatókör-módosítóról további információt a Using:about_Remote_Variables talál.

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

# 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 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 delegálásának lehetőségét a ServerC felé, állítsa a PrincipalsAllowedToDelegateToAccount paraméter értékét a ServerC kiszolgálón $null-ra.

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 (korlátozás nélkül)

A Kerberos korlátlan delegálását is használhatja a második lépés végrehajtásához. 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ó.

Éppen elegendő adminisztráció (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 megoldható ezzel.

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

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 ServerB, és beállíthatja annak RunAsCredential paraméterét.

A második ugrási probléma megoldásához a PSSessionConfiguration és a RunAs használatával kapcsolatos információkért lásd a Több ugrásos PowerShell-remoting másik megoldása.

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

  • PSSessionConfiguration és RunAs beállítására van szükség minden köztes kiszolgálón (ServerB).
  • Jelszókarbantartást igényel a tartománynál használt RunAs-fiók esetén.

Hitelesítő adatok átadása Invoke-Command szkriptblokkon belül

A hitelesítő adatokat a ScriptBlock paraméteren belül adhatja át a 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 biztonsági megfontolások

  • Last updated on