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

"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.

CredSSP (på engelska)

Du kan använda credential Security Support Provider (CredSSP) för autentisering. CredSSP lagrar autentiseringsuppgifter på fjärrservern (ServerB), vilket gör att du riskerar att utsättas för stöldattacker av autentiseringsuppgifter om du använder den. 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 att minimera Pass-the-Hash-attacker (PtH) och andra stölder av autentiseringsuppgifter.

Ett exempel på hur du aktiverar och använder CredSSP för PowerShell-fjärrstyrning finns i Aktivera PowerShell "Second-Hop"-funktionalitet 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.

Begränsad Kerberos-delegering

Du kan använda äldre form av begränsad delegering (inte resursbaserad) för att möjliggö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.

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- 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).

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 funktionen RSAT-AD-PowerShell 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 en PrincipalsAllowedToDelegateToAccount parameter:

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 är 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 ServerC att tillåta delegering från en PowerShell-fjärrkommunikationssession på ServerB, måste vi ställa in 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 cachen 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 Using:-omfångsmodifieraren för att göra $ServerC variabeln synlig för ServerB-. Mer information om omfångsmodifieraren Using: finns i about_Remote_Variables.

Om du vill tillåta att flera servrar delegerar autentiseringsuppgifter till ServerCanger 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 parametern Server för att ange fullständigt kvalificerat domännamn (FQDN) för domänkontrollanten 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

• Nyheter i Kerberos-autentisering
• Hur Windows Server 2012 lindrar smärtan för Kerberos-begränsad delegering, del 1
• Hur Windows Server 2012 underlättar smärtan för Kerberos-begränsad delegering, del 2
• Förstå Kerberos-begränsad delegering för Microsoft Entra-programproxydistributioner med integrerad Windows-autentisering
• [MS-ADA2 Attribut i Active Directory-schema M2.210 Attribut msDS-AllowedToActOnBehalfOfOtherIdentity]MS-ADA2
• [MS-SFU Kerberosprotokollextensioner: Tjänst för användare och begränsad delegeringsprotokoll 1.3.2 S4U2proxy]MS-SFU
• Fjärradministration utan begränsad delegering med hjälp av "principalsAllowedToDelegateToAccount"

Kerberos-delegering (obegränsad)

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

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 problemet med det andra hoppet 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 en domän RunAs-konto

Skicka autentiseringsuppgifter i ett Invoke-Command skriptblock

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