De tweede hop maken voor externe communicatie met PowerShell

  • Artikel

Het 'tweede hopprobleem' verwijst naar een situatie zoals hieronder:

  1. U bent aangemeld bij ServerA.
  2. Vanuit ServerA start u een externe PowerShell-sessie om verbinding te maken met ServerB.
  3. Een opdracht die u uitvoert op ServerB via uw externe PowerShell-sessie probeert toegang te krijgen tot een resource op ServerC.
  4. De toegang tot de resource op ServerC wordt geweigerd, omdat de referenties die u hebt gebruikt voor het maken van de externe PowerShell-sessie niet worden doorgegeven van ServerB naar ServerC.

Er zijn verschillende manieren om dit probleem op te lossen. De volgende tabel bevat de methoden in volgorde van voorkeur.

Configuratie Notitie
CredSSP Zorgt voor gebruiksgemak en beveiliging
Beperkte Kerberos-delegering op basis van resources Hogere beveiliging met eenvoudigere configuratie
Beperkte Kerberos-delegering Hoge beveiliging, maar vereist domein Beheer istrator
Kerberos-delegatie (niet-getraind) Niet aanbevolen
Just Enough Administration (JEA) Kan de beste beveiliging bieden, maar vereist meer gedetailleerde configuratie
PSSessionConfiguration met RunAs Eenvoudiger te configureren, maar vereist referentiebeheer
Referenties doorgeven in een Invoke-Command scriptblok Eenvoudigst te gebruiken, maar u moet referenties opgeven

CredSSP

U kunt de Referentiebeveiligingsondersteuningsprovider (CredSSP) gebruiken voor verificatie. CredSSP slaat referenties op de externe server (ServerB) in de cache op, dus als u deze gebruikt, wordt u geopend voor aanvallen met diefstal van referenties. Als de externe computer is aangetast, heeft de aanvaller toegang tot de referenties van de gebruiker. CredSSP is standaard uitgeschakeld op zowel client- als servercomputers. Schakel CredSSP alleen in de meest vertrouwde omgevingen in. Een domeinbeheerder die verbinding maakt met een domeincontroller, bijvoorbeeld omdat de domeincontroller zeer vertrouwd is.

Voor meer informatie over beveiligingsproblemen bij het gebruik van CredSSP voor externe communicatie met PowerShell raadpleegt u Onbedoelde sabotage: pas op voor CredSSP.

Zie Pass-the-Hash-aanvallen (PtH) beperken en Andere referentiediefstal voor meer informatie over aanvallen met referentiediefstal.

Voor een voorbeeld van het inschakelen en gebruiken van CredSSP voor externe communicatie met PowerShell raadpleegt u PowerShell 'Second-Hop' Functionality inschakelen met CredSSP.

Voordelen

  • Het werkt voor alle servers met Windows Server 2008 of hoger.

Nadelen

  • Heeft beveiligingsproblemen.
  • Vereist configuratie van zowel client- als serverfuncties.
  • werkt niet met de groep Beveiligde gebruikers. Zie Beveiligde gebruikersbeveiligingsgroep voor meer informatie.

Beperkte Kerberos-delegering

U kunt verouderde beperkte delegering (niet op basis van resources) gebruiken om de tweede hop te maken. Configureer beperkte Kerberos-delegering met de optie 'Elk verificatieprotocol gebruiken' om protocolovergang toe te staan.

Voordelen

  • Vereist geen speciale codering
  • Referenties worden niet opgeslagen.

Nadelen

  • Biedt geen ondersteuning voor de tweede hop voor WinRM.
  • Vereist domein Beheer istrator-toegang om te configureren.
  • Moet worden geconfigureerd op het Active Directory-object van de externe server (ServerB).
  • Beperkt tot één domein. Kan geen domeinen of forests kruisen.
  • Hiervoor zijn rechten vereist voor het bijwerken van objecten en SPN's (Service Principal Names).
  • ServerB kan een Kerberos-ticket verkrijgen voor ServerC namens de gebruiker zonder tussenkomst van de gebruiker.

Notitie

Active Directory-accounts met het account zijn gevoelig en kunnen niet worden gedelegeerd en kunnen niet worden gedelegeerd. Zie Beveiligingsfocus voor meer informatie: Analyseren van 'Account is gevoelig en kan niet worden gedelegeerd' voor Bevoegde accounts en Kerberos Authentication Tools en Instellingen.

Beperkte Kerberos-delegering op basis van resources

Met beperkte Kerberos-delegering op basis van resources (geïntroduceerd in Windows Server 2012) configureert u referentiedelegering op het serverobject waarin resources zich bevinden. In het hierboven beschreven tweede hopscenario configureert u ServerC om op te geven waar gedelegeerde referenties worden geaccepteerd.

Voordelen

  • Referenties worden niet opgeslagen.
  • Geconfigureerd met Behulp van PowerShell-cmdlets. Er is geen speciale codering vereist.
  • Hiervoor is geen domein-Beheer istrator-toegang vereist om te configureren.
  • Werkt tussen domeinen en forests.

Nadelen

  • Vereist Windows Server 2012 of hoger.
  • Biedt geen ondersteuning voor de tweede hop voor WinRM.
  • Hiervoor zijn rechten vereist voor het bijwerken van objecten en SPN's (Service Principal Names).

Notitie

Active Directory-accounts met het account zijn gevoelig en kunnen niet worden gedelegeerd en kunnen niet worden gedelegeerd. Zie Beveiligingsfocus voor meer informatie: Analyseren van 'Account is gevoelig en kan niet worden gedelegeerd' voor Bevoegde accounts en Kerberos Authentication Tools en Instellingen.

Opmerking

Laten we eens kijken naar een PowerShell-voorbeeld waarmee beperkte overdracht op basis van resources op ServerC wordt geconfigureerd om gedelegeerde referenties van een ServerB toe te staan. In dit voorbeeld wordt ervan uitgegaan dat alle servers ondersteunde versies van Windows Server uitvoeren en dat er ten minste één Windows-domeincontroller is voor elk vertrouwd domein.

Voordat u beperkte delegering kunt configureren, moet u de RSAT-AD-PowerShell functie toevoegen om de Active Directory PowerShell-module te installeren en die module vervolgens in uw sessie te importeren:

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

Verschillende beschikbare cmdlets hebben nu de parameter 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

De parameter PrincipalsAllowedToDelegateToAccount stelt het kenmerk Active Directory-object msDS-AllowedToActOnBehalfOfOtherIdentity in, dat een toegangsbeheerlijst (ACL) bevat die aangeeft welke accounts gemachtigd zijn om referenties te delegeren aan het gekoppelde account (in ons voorbeeld is dit het computeraccount voor ServerA).

Nu gaan we de variabelen instellen die we gaan gebruiken om de servers weer te geven:

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

WinRM (en daarom externe communicatie met PowerShell) wordt standaard uitgevoerd als het computeraccount. U kunt dit zien door naar de eigenschap StartName van de winrm service te kijken:

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

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

ServerC moet de parameter PrincipalsAllowedToDelegateToAccount op ServerC instellen op ServerC op het computerobject van ServerB om overdracht van een externe PowerShell-sessie op ServerB toe te staan:

# 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

De KDC-cache (Kerberos Key Distribution Center) heeft gedurende 15 minuten geweigerde toegangspogingen (negatieve cache). Als ServerB eerder heeft geprobeerd toegang te krijgen tot ServerC, moet u de cache op ServerB wissen door de volgende opdracht aan te roepen:

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

U kunt de computer ook opnieuw opstarten of ten minste 15 minuten wachten om de cache te wissen.

Nadat u de cache hebt gewist, kunt u code van ServerA via ServerB naar ServerC uitvoeren:

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

In dit voorbeeld wordt de $using variabele gebruikt om de $ServerC variabele zichtbaar te maken voor ServerB. Zie about_Remote_Variables voor meer informatie over de $using variabele.

Als u wilt toestaan dat meerdere servers referenties delegeren aan ServerC, stelt u de waarde van de parameter PrincipalsAllowedToDelegateToAccount op ServerC in op een matrix:

# 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

Als u de tweede hop tussen domeinen wilt maken, gebruikt u de serverparameter om FQDN (Fully Qualified Domain Name) van de domeincontroller van het domein waartoe ServerB behoort op te geven:

# 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

Als u de mogelijkheid wilt verwijderen om referenties te delegeren aan ServerC, stelt u de waarde van de parameter PrincipalsAllowedToDelegateToAccount op ServerC in op$null:

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

Informatie over beperkte Kerberos-delegering op basis van resources

Kerberos-delegatie (niet-getraind)

U kunt kerberos niet-getrainde delegatie ook gebruiken om de tweede hop te maken. Net als bij alle Kerberos-scenario's worden referenties niet opgeslagen. Deze methode biedt geen ondersteuning voor de tweede hop voor WinRM.

Waarschuwing

Deze methode biedt geen controle over waar gedelegeerde referenties worden gebruikt. Het is minder veilig dan CredSSP. Deze methode mag alleen worden gebruikt voor testscenario's.

Just Enough Administration (JEA)

Met JEA kunt u beperken welke opdrachten een beheerder kan uitvoeren tijdens een PowerShell-sessie. Het kan worden gebruikt om het tweede hopprobleem op te lossen.

Zie Just Enough Beheer istration voor informatie over JEA.

Voordelen

  • Geen wachtwoordonderhoud bij gebruik van een virtueel account.

Nadelen

  • Vereist WMF 5.0 of hoger.
  • Vereist configuratie op elke tussenliggende server (ServerB).

PSSessionConfiguration met RunAs

U kunt een sessieconfiguratie maken op ServerB en de bijbehorende RunAsCredential-parameter instellen.

Zie een andere oplossing voor externe communicatie met PowerShell voor meer informatie over het gebruik van PSSessionConfiguration en RunAs om het probleem met de tweede hop op te lossen.

Voordelen

  • Werkt met elke server met WMF 3.0 of hoger.

Nadelen

  • Vereist configuratie van PSSessionConfiguration en RunAs op elke tussenliggende server (ServerB).
  • Wachtwoordonderhoud vereist bij het gebruik van een RunAs-domeinaccount

Referenties doorgeven in een scriptblok invoke-command

U kunt referenties doorgeven in de ScriptBlock-parameter van een aanroep naar de cmdlet Invoke-Command .

Voordelen

  • Er is geen speciale serverconfiguratie vereist.
  • Werkt op elke server met WMF 2.0 of hoger.

Nadelen

  • Hiervoor is een onhandige codetechniek vereist.
  • Als U WMF 2.0 uitvoert, is een andere syntaxis vereist voor het doorgeven van argumenten aan een externe sessie.

Opmerking

In het volgende voorbeeld ziet u hoe u referenties doorgeeft in een scriptblok:

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

Zie ook

Beveiligingsoverwegingen bij externe communicatie met PowerShell