Göra det andra hoppet i PowerShell-fjärrkommunikation

  • Artikel

"Second Hop-problemet" refererar till en situation som liknar följande:

  1. Du är inloggad på ServerA.
  2. Från ServerA startar du en powershell-fjärrsession för att ansluta till ServerB.
  3. Ett kommando som du kör på ServerB via powershell-fjärrkommunikationssessionen försöker komma åt en resurs på ServerC.
  4. Åtkomst till resursen på ServerC nekas eftersom de autentiseringsuppgifter som du använde för att skapa PowerShell-fjärrkommunikationssessionen inte skickas från ServerB till ServerC.

Det finns flera sätt att lösa det här problemet. I följande tabell visas metoderna i prioritetsordning.

Konfiguration Kommentar
CredSSP Balanserar användarvänlighet och säkerhet
Resursbaserad Kerberos-begränsad delegering Högre säkerhet med enklare konfiguration
Kerberos-begränsad delegering Hög säkerhet men kräver domänadministratör
Kerberos-delegering (obegränsad) Rekommenderas inte
JEA (Just Enough Administration) Kan ge den bästa säkerheten men kräver mer detaljerad konfiguration
PSSessionConfiguration med hjälp av RunAs Enklare att konfigurera men kräver hantering av autentiseringsuppgifter
Skicka autentiseringsuppgifter i ett Invoke-Command skriptblock Enklast att använda men du måste ange autentiseringsuppgifter

CredSSP

Du kan använda CredSSP (CredSSP) för autentisering. CredSSP cachelagrar autentiseringsuppgifter på fjärrservern (ServerB), så om du använder den öppnas attacker för stöld av autentiseringsuppgifter. Om fjärrdatorn komprometteras har angriparen åtkomst till användarens autentiseringsuppgifter. CredSSP är inaktiverat som standard på både klient- och serverdatorer. Du bör endast aktivera CredSSP i de mest betrodda miljöerna. Till exempel en domänadministratör som ansluter till en domänkontrollant eftersom domänkontrollanten är mycket betrodd.

Mer information om säkerhetsproblem när du använder CredSSP för PowerShell-fjärrkommunikation finns i Oavsiktligt sabotage: Akta dig för CredSSP.

Mer information om stöldattacker för autentiseringsuppgifter finns i Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft (Mildra Pass-the-Hash-attacker) och Annan stöld av autentiseringsuppgifter.

Ett exempel på hur du aktiverar och använder CredSSP för PowerShell-fjärrkommunikation finns i Aktivera PowerShell"Second-Hop"-funktioner med CredSSP.

Fördelar

  • Det fungerar för alla servrar med Windows Server 2008 eller senare.

Nackdelar

  • Har säkerhetsrisker.
  • Kräver konfiguration av både klient- och serverroller.
  • fungerar inte med gruppen Skyddade användare. Mer information finns i Säkerhetsgrupp för skyddade användare.

Kerberos-begränsad delegering

Du kan använda äldre begränsad delegering (inte resursbaserad) för att göra det andra hoppet. Konfigurera Kerberos-begränsad delegering med alternativet "Använd valfritt autentiseringsprotokoll" för att tillåta protokollövergång.

Fördelar

  • Kräver ingen särskild kodning
  • Autentiseringsuppgifter lagras inte.

Nackdelar

  • Stöder inte det andra hoppet för WinRM.
  • Kräver domänadministratörsåtkomst för att konfigurera.
  • Måste konfigureras på Active Directory-objektet för fjärrservern (ServerB).
  • Begränsad till en domän. Det går inte att korsa domäner eller skogar.
  • Kräver behörighet att uppdatera objekt och tjänsthuvudnamn (SPN).
  • ServerB kan hämta en Kerberos-biljett till ServerC för användarens räkning utan att användaren behöver göra något.

Kommentar

Active Directory-konton som har kontot är känsliga och kan inte delegeras egenskapsuppsättning kan inte delegeras. Mer information finns i Säkerhetsfokus: Analysera "Kontot är känsligt och kan inte delegeras" för privilegierade konton och Kerberos-autentiseringsverktyg och Inställningar.

Resursbaserad Kerberos-begränsad delegering

Med resursbaserad Kerberos-begränsad delegering (introducerades i Windows Server 2012) konfigurerar du delegering av autentiseringsuppgifter på serverobjektet där resurserna finns. I det andra hoppscenariot som beskrivs ovan konfigurerar du ServerC för att ange varifrån den accepterar delegerade autentiseringsuppgifter.

Fördelar

  • Autentiseringsuppgifter lagras inte.
  • Konfigurerad med PowerShell-cmdletar. Ingen särskild kodning krävs.
  • Kräver inte domänadministratörsåtkomst för att konfigurera.
  • Fungerar mellan domäner och skogar.

Nackdelar

  • Kräver Windows Server 2012 eller senare.
  • Stöder inte det andra hoppet för WinRM.
  • Kräver behörighet att uppdatera objekt och tjänsthuvudnamn (SPN).

Kommentar

Active Directory-konton som har kontot är känsliga och kan inte delegeras egenskapsuppsättning kan inte delegeras. Mer information finns i Säkerhetsfokus: Analysera "Kontot är känsligt och kan inte delegeras" för privilegierade konton och Kerberos-autentiseringsverktyg och Inställningar.

Exempel

Nu ska vi titta på ett PowerShell-exempel som konfigurerar resursbaserad begränsad delegering på ServerC för att tillåta delegerade autentiseringsuppgifter från en ServerB. Det här exemplet förutsätter att alla servrar kör versioner av Windows Server som stöds och att det finns minst en Windows-domänkontrollant för varje betrodd domän.

Innan du kan konfigurera begränsad delegering måste du lägga till RSAT-AD-PowerShell funktionen för att installera Active Directory PowerShell-modulen och sedan importera modulen till sessionen:

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

Flera tillgängliga cmdletar har nu parametern 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

Parametern PrincipalsAllowedToDelegateToAccount anger Active Directory-objektattributet msDS-AllowedToActOnBehalfOfOtherIdentity, som innehåller en åtkomstkontrollista (ACL) som anger vilka konton som har behörighet att delegera autentiseringsuppgifter till det associerade kontot (i vårt exempel blir det datorkontot för ServerA).

Nu ska vi konfigurera de variabler som vi ska använda för att representera servrarna:

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

WinRM (och därmed PowerShell-fjärrkommunikation) körs som datorkonto som standard. Du kan se detta genom att titta på egenskapen StartName för winrm tjänsten:

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

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

För att ServerC ska tillåta delegering från en PowerShell-fjärrkommunikationssession på ServerB måste vi ange parametern PrincipalsAllowedToDelegateToAccount på ServerC till datorobjektet för ServerB:

# 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

Kerberos Key Distribution Center (KDC) cachelagrar försök till nekad åtkomst (negativ cache) i 15 minuter. Om ServerB tidigare har försökt komma åt ServerC måste du rensa cacheminnet på ServerB genom att anropa följande kommando:

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

Du kan också starta om datorn eller vänta minst 15 minuter för att rensa cacheminnet.

När du har rensat cacheminnet kan du köra kod från ServerA via ServerB till 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)
}

I det här exemplet används variabeln $using för att göra variabeln $ServerC synlig för ServerB. Mer information om variabeln finns i $using about_Remote_Variables.

Om du vill tillåta att flera servrar delegerar autentiseringsuppgifter till ServerC anger du värdet för parametern PrincipalsAllowedToDelegateToAccount på ServerC till en matris:

# 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

Om du vill göra det andra hoppet mellan domäner använder du serverparametern för att ange fullständigt kvalificerat domännamn (FQDN) för domänkontrollanten för domänen som ServerB tillhör:

# 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

Om du vill ta bort möjligheten att delegera autentiseringsuppgifter till ServerC anger du värdet för parametern PrincipalsAllowedToDelegateToAccount på ServerC till $null:

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

Information om resursbaserad Kerberos-begränsad delegering

Kerberos-delegering (obegränsad)

Du kan också använda Kerberos-obegränsad delegering för att göra det andra hoppet. Precis som alla Kerberos-scenarier lagras inte autentiseringsuppgifter. Den här metoden stöder inte det andra hoppet för WinRM.

Varning

Den här metoden ger ingen kontroll över var delegerade autentiseringsuppgifter används. Det är mindre säkert än CredSSP. Den här metoden bör endast användas för testscenarier.

JEA (Just Enough Administration)

MED JEA kan du begränsa vilka kommandon en administratör kan köra under en PowerShell-session. Den kan användas för att lösa det andra hoppproblemet.

Information om JEA finns i Just Enough Administration.

Fördelar

  • Inget lösenordsunderhåll när du använder ett virtuellt konto.

Nackdelar

  • Kräver WMF 5.0 eller senare.
  • Kräver konfiguration på varje mellanliggande server (ServerB).

PSSessionConfiguration med hjälp av RunAs

Du kan skapa en sessionskonfiguration på ServerB och ange parametern RunAsCredential .

Information om hur du använder PSSessionConfiguration och RunAs för att lösa det andra hoppproblemet finns i En annan lösning på powershell-fjärrkommunikation med flera hopp.

Fördelar

  • Fungerar med valfri server med WMF 3.0 eller senare.

Nackdelar

  • Kräver konfiguration av PSSessionConfiguration och RunAs på varje mellanliggande server (ServerB).
  • Kräver lösenordsunderhåll när du använder ett RunAs-domänkonto

Skicka autentiseringsuppgifter i skriptblocket Invoke-Command

Du kan skicka autentiseringsuppgifter i parametern ScriptBlock för ett anrop till cmdleten Invoke-Command .

Fördelar

  • Kräver inte särskild serverkonfiguration.
  • Fungerar på alla servrar som kör WMF 2.0 eller senare.

Nackdelar

  • Kräver en besvärlig kodteknik.
  • Om du kör WMF 2.0 krävs en annan syntax för att skicka argument till en fjärrsession.

Exempel

I följande exempel visas hur du skickar autentiseringsuppgifter i ett skriptblock:

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

Se även

Säkerhetsöverväganden för PowerShell-fjärrkommunikation