Maken van de tweede hop in PowerShell voor externe toegangMaking the second hop in PowerShell Remoting

De 'tweede hop '-probleem verwijst naar een situatie als volgt:The "second hop problem" refers to a situation like the following:

  1. U bent aangemeld bij ServerA.You are logged in to ServerA.
  2. Van ServerA, u verbinding maken met een externe PowerShell-sessie starten ServerB.From ServerA, you start a remote PowerShell session to connect to ServerB.
  3. Een opdracht die u uitvoert op ServerB via uw externe communicatie van PowerShell sessie probeert te krijgen tot een bron op ServerC.A command you run on ServerB via your PowerShell Remoting session attempts to access a resource on ServerC.
  4. Toegang tot de resource op ServerC is geweigerd omdat de referenties die u gebruikt voor het maken van de externe communicatie van PowerShell-sessie niet worden doorgegeven van ServerB naar ServerC.Access to the resource on ServerC is denied, because the credentials you used to create the PowerShell Remoting session are not passed from ServerB to ServerC.

Er zijn verschillende manieren om dit probleem te verhelpen.There are several ways to address this problem. In dit onderwerp, zullen we verschillende van de meest populaire oplossingen voor het tweede hop probleem.In this topic, we'll look at several of the most popular solutions to the second hop problem.

CredSSPCredSSP

U kunt de Credential Security Support Provider (CredSSP) voor verificatie.You can use the Credential Security Support Provider (CredSSP) for authentication. CredSSP in de cache opgeslagen referenties op de externe server (ServerB), zodat deze wordt geopend u maximaal credential theft aanvallen.CredSSP caches credentials on the remote server (ServerB), so using it opens you up to credential theft attacks. Als de externe computer is geknoeid, heeft de aanvaller toegang tot de referenties van de gebruiker.If the remote computer is compromised, the attacker has access to the user's credentials. CredSSP is standaard uitgeschakeld in zowel client- en servercomputers.CredSSP is disabled by default on both client and server computers. Alleen in de meest vertrouwde omgevingen, moet u CredSSP inschakelen.You should enable CredSSP only in the most trusted environments. Bijvoorbeeld, een domeinbeheerder verbinding te maken met een domeincontroller, omdat de domeincontroller uiterst vertrouwde is.For example, a domain administrator connecting to a domain controller because the domain controller is highly trusted.

Zie voor meer informatie over de beveiligingsoverwegingen wanneer u CredSSP voor externe communicatie van PowerShell onbedoeld Sabotage: Houd er rekening mee van CredSSP.For more information about security concerns when using CredSSP for PowerShell Remoting, see Accidental Sabotage: Beware of CredSSP.

Zie voor meer informatie over credential theft aanvallen Mitigating Pass-the-Hash (PtH) aanvallen en andere Referentiediefstal.For more information about credential theft attacks, see Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft.

Zie voor een voorbeeld van hoe u inschakelen en gebruiken van CredSSP voor externe communicatie van PowerShell CredSSP met behulp van de tweede hop probleem op te lossen.For an example of how to enable and use CredSSP for PowerShell remoting, see Using CredSSP to solve the second-hop problem.

VoordelenPros

  • De Tool werkt voor alle servers met Windows Server 2008 of hoger.It works for all servers with Windows Server 2008 or later.

NadelenCons

  • Beveiligingsproblemen heeft.Has security vulnerabilities.
  • Configuratie van functies voor zowel client als server vereist.Requires configuration of both client and server roles.

Kerberos-overdracht (een)Kerberos delegation (unconstrained)

U kunt ook een Kerberos-overdracht gebruikt voor het maken van de tweede hop.You can also used Kerberos unconstrained delegation to make the second hop. Deze methode biedt echter geen controle van waar de gedelegeerde referenties worden gebruikt.However, this method provides no control of where delegated credentials are used.

Opmerking: Active Directory-accounts waarvoor de Account is vertrouwelijk en kan niet worden overgedragen eigenschap is ingesteld, kan niet worden overgedragen.Note: Active Directory accounts that have the Account is sensitive and cannot be delegated property set cannot be delegated. Zie voor meer informatie beveiliging Focus: 'Account is vertrouwelijk en kan niet worden overgedragen' analyseren voor bevoegde Accounts en Kerberos-verificatie-hulpprogramma's en instellingenFor more information, see Security Focus: Analysing 'Account is sensitive and cannot be delegated' for Privileged Accounts and Kerberos Authentication Tools and Settings

VoordelenPros

  • Vereist geen speciale coderen.Requires no special coding.

NadelenCons

  • Biedt de tweede hop geen ondersteuning voor WinRM.Does not support the second hop for WinRM.
  • Biedt geen controle over waar de referenties worden gebruikt, het maken van een beveiligingsprobleem.Provides no control over where credentials are used, creating a security vulnerability.

Kerberos-beperkte overdrachtKerberos constrained delegation

Verouderde beperkte delegering (geen resource gebaseerde) kunt u de tweede hop maken.You can use legacy constrained delegation (not resource-based) to make the second hop.

Opmerking: Active Directory-accounts waarvoor de Account is vertrouwelijk en kan niet worden overgedragen eigenschap is ingesteld, kan niet worden overgedragen.Note: Active Directory accounts that have the Account is sensitive and cannot be delegated property set cannot be delegated. Zie voor meer informatie beveiliging Focus: 'Account is vertrouwelijk en kan niet worden overgedragen' analyseren voor bevoegde Accounts en Kerberos-verificatie-hulpprogramma's en instellingenFor more information, see Security Focus: Analysing 'Account is sensitive and cannot be delegated' for Privileged Accounts and Kerberos Authentication Tools and Settings

VoordelenPros

  • Vereist geen speciale coderenRequires no special coding

NadelenCons

  • Biedt de tweede hop geen ondersteuning voor WinRM.Does not support the second hop for WinRM.
  • Moet worden geconfigureerd op de Active Directory-object van de externe server (ServerB).Must be configured on the Active Directory object of the remote server (ServerB).
  • Beperkt tot één domein.Limited to one domain. Kan niet meerdere domeinen of forests.Cannot cross domains or forests.
  • Rechten voor het bijwerken van objecten en Service Principal Names (SPN's) vereist.Requires rights to update objects and Service Principal Names (SPNs).

Bronnen gebaseerde beperkte Kerberos-overdrachtResource-based Kerberos constrained delegation

Met behulp van Kerberos bronnen gebaseerde beperkte delegering (geïntroduceerd in Windows Server 2012), configureert u de overdracht van referenties op het object van de server waar de bronnen zich bevinden.Using resource-based Kerberos constrained delegation (introduced in Windows Server 2012), you configure credential delegation on the server object where resources reside. In het tweede hop-scenario die hierboven worden beschreven, configureert u ServerC om op te geven van waar worden geaccepteerd overgedragen referenties.In the second hop scenario described above, you configure ServerC to specify from where it will accept delegated credentials.

Opmerking: Active Directory-accounts waarvoor de Account is vertrouwelijk en kan niet worden overgedragen eigenschap is ingesteld, kan niet worden overgedragen.Note: Active Directory accounts that have the Account is sensitive and cannot be delegated property set cannot be delegated. Zie voor meer informatie beveiliging Focus: 'Account is vertrouwelijk en kan niet worden overgedragen' analyseren voor bevoegde Accounts en Kerberos-verificatie-hulpprogramma's en instellingenFor more information, see Security Focus: Analysing 'Account is sensitive and cannot be delegated' for Privileged Accounts and Kerberos Authentication Tools and Settings

VoordelenPros

  • Referenties worden niet opgeslagen.Credentials are not stored.
  • Betrekkelijk eenvoudig te configureren met behulp van PowerShell-cmdlets--er is geen speciale codering vereist.Relatively easy to configure by using PowerShell cmdlets--no special coding required.
  • Er is geen speciale domeintoegang is vereist.No special domain access is required.
  • Deze optie werkt in domeinen en forests.Works across domains and forests.
  • PowerShell-code.PowerShell code.

NadelenCons

  • WindowsServer 2012 of later vereist.Requires Windows Server 2012 or later.
  • Biedt de tweede hop geen ondersteuning voor WinRM.Does not support the second hop for WinRM.
  • Rechten voor het bijwerken van objecten en Service Principal Names (SPN's) vereist.Requires rights to update objects and Service Principal Names (SPNs).

VoorbeeldExample

Bekijk een voorbeeld van de resource configureert u beperkte delegering op basis van PowerShell ServerC waarmee gedelegeerde referenties van een ServerB.Let's look at a PowerShell example that configures resource based constrained delegation on ServerC to allow delegated credentials from a ServerB. In dit voorbeeld wordt ervan uitgegaan dat alle servers worden uitgevoerd met WindowsServer 2012 of later, en of er ten minste één Windows Server 2012-domeincontroller waarop elke van de servers elk domein behoren.This example assumes that all servers are running Windows Server 2012 or later, and that there is at least one Windows Server 2012 domain controller each domain to which any of the servers belong.

Voordat u beperkte delegering configureren kunt, moet u toevoegen de RSAT-AD-PowerShell om te installeren van de Active Directory PowerShell-module en vervolgens importeren die module in uw sessie:Before you can configure constrained delegation, you must add the RSAT-AD-PowerShell feature to install the Active Directory PowerShell module, and then import that module into your session:

PS C:\> Add-WindowsFeature RSAT-AD-PowerShell

PS C:\> Import-Module ActiveDirectory

Verschillende beschikbare cmdlets hebt nu een PrincipalsAllowedToDelegateToAccount parameter:Several available cmdlets now have a PrincipalsAllowedToDelegateToAccount parameter:

PS C:\> Get-Command -ParameterName 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 PrincipalsAllowedToDelegateToAccount parameter stelt het Active Directory-objectkenmerk msDS-AllowedToActOnBehalfOfOtherIdentity, die een toegangsbeheerlijst (ACL) bevat die Hiermee geeft u op welke accounts gemachtigd voor het overdragen van referenties voor de gekoppelde account (in ons voorbeeld dient de computeraccount voor Server).The PrincipalsAllowedToDelegateToAccount parameter sets the Active Directory object attribute msDS-AllowedToActOnBehalfOfOtherIdentity, which contains an access control list (ACL) that specifies which accounts have permission to delegate credentials to the associated account (in our example, it will be the machine account for Server).

Nu gaan we instellen van de variabelen die we gebruiken om weer te geven van de servers:Now let's set up the variables we'll use to represent the servers:

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

WinRM (en dus PowerShell voor externe toegang) wordt uitgevoerd als het computeraccount standaard.WinRM (and therefore PowerShell remoting) runs as the computer account by default. U kunt dit zien door te kijken naar de StartName eigenschap van de winrm service:You can see this by looking at the StartName property of the winrm service:

PS C:\> Get-WmiObject win32_service -filter 'name="winrm"' | Format-List StartName

StartName : NT AUTHORITY\NetworkService

Voor ServerC waarmee de overdracht van een PowerShell-sessie voor externe toegang op ServerB, zullen we toegang verlenen door in te stellen de PrincipalsAllowedToDelegateToAccount parameter op ServerC voor het computerobject van ServerB:For ServerC to allow delegation from a PowerShell remoting session on ServerB, we will grant access by setting the PrincipalsAllowedToDelegateToAccount parameter on ServerC to the computer object of 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

Het Kerberos Key Distribution Center (KDC) caches geweigerd toegangspogingen (negatieve cache) gedurende 15 minuten.The Kerberos Key Distribution Center (KDC) caches denied access attempts (negative cache) for 15 minutes. Als ServerB eerder heeft geprobeerd toegang te ServerC, moet u de cache wissen op ServerB door het aanroepen van de volgende opdracht:If ServerB has previously attempted to access ServerC, you will need to clear the cache on ServerB by invoking the following command:

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

U kunt ook de computer opnieuw opstarten of wacht ten minste 15 minuten om de cache te wissen.You could also restart the computer, or wait at least 15 minutes to clear the cache.

Na het uitschakelen van de cache kunt u de code van uitgevoerd ServerA via ServerB naar ServerC:After clearing the cache, you can successfully run code from ServerA through ServerB to 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)
}

In dit voorbeeld wordt de $using variabele wordt gebruikt om de $ServerC variabele zichtbaar is voor ServerB.In this example, the $using variable is used to make the $ServerC variable visible to ServerB. Voor meer informatie over de $using variabele, Zie about_Remote_Variables.For more information about the $using variable, see about_Remote_Variables.

Op meerdere servers te delegeren referenties ServerC, stel de waarde van de PrincipalsAllowedToDelegateToAccount parameter op ServerC om in een matrix:To allow multiple servers to delegate credentials to ServerC, set the value of the PrincipalsAllowedToDelegateToAccount parameter on ServerC to an array:

# 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

# Grant resource-based Kerberos constrained delegation
Set-ADComputer -Identity $ServerC `
    -PrincipalsAllowedToDelegateToAccount @($ServerB1,$ServerB2,$ServerB3)

Als u maken van de tweede hop tussen domeinen wilt, volledig gekwalificeerde domeinnaam (FQDN) van de domeincontroller van het domein aan toevoegen die ServerB behoort:If you want to make the second hop across domains, add fully-qualified domain name (FQDN) of the domain controller of the domain to which ServerB belongs:

# 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 wilt verwijderen van de mogelijkheid overdragen van referenties voor ServerC, stel de waarde van de PrincipalsAllowedToDelegateToAccount parameter op ServerC naar $null:To remove the ability to delegate credentials to ServerC, set the value of the PrincipalsAllowedToDelegateToAccount parameter on ServerC to $null:

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

Informatie over bronnen gebaseerde beperkte Kerberos-overdrachtInformation on resource-based Kerberos constrained delegation

Met RunAs-PSSessionConfigurationPSSessionConfiguration using RunAs

U kunt een sessieconfiguratie maken op ServerB en stel de RunAsCredential parameter.You can create a session configuration on ServerB and set its RunAsCredential parameter.

Zie voor meer informatie over het gebruik van PSSessionConfiguration en RunAs voor het oplossen van de tweede hop probleem andere oplossing voor externe communicatie van PowerShell Multihop.For information about using PSSessionConfiguration and RunAs to solve the second hop problem, see Another solution to multi-hop PowerShell remoting.

VoordelenPros

  • Als u werkt met een server met WMF 3.0 of hoger.Works with any server with WMF 3.0 or later.

NadelenCons

  • Configuratie van vereist PSSessionConfiguration en RunAs op elke server tussenliggende (ServerB).Requires configuration of PSSessionConfiguration and RunAs on every intermediate server (ServerB).
  • Wachtwoord onderhoud is vereist bij het gebruik van een domein RunAs accountRequires password maintenance when using a domain RunAs account

Just Enough Administration (JEA)Just Enough Administration (JEA)

JEA kunt u beperken welke opdrachten die een beheerder kan worden uitgevoerd tijdens een PowerShell-sessie.JEA allows you to restrict what commands an administrator can run during a PowerShell session. Het kan worden gebruikt voor het oplossen van de tweede hop probleem.It can be used to solve the second hop problem.

Zie voor meer informatie over JEA net genoeg beheer.For information about JEA, see Just Enough Administration.

VoordelenPros

  • Er is geen wachtwoord onderhoud bij gebruik van een virtueel account.No password maintenance when using a virtual account.

NadelenCons

  • WMF 5.0 of hoger vereist.Requires WMF 5.0 or later.
  • Moet worden geconfigureerd op elke server tussenliggende (ServerB).Requires configuration on every intermediate server (ServerB).

Referenties in een scriptblok Invoke-Command doorgevenPass credentials inside an Invoke-Command script block

U kunt doorgeven referenties binnen de ScriptBlock parameter van een aanroep naar de Invoke-Command cmdlet.You can pass credentials inside the ScriptBlock parameter of a call to the Invoke-Command cmdlet.

VoordelenPros

  • Is geen speciale configuratie vereist.Does not require special server configuration.
  • Werkt op elke server waarop WMF 2.0 of hoger wordt uitgevoerd.Works on any server running WMF 2.0 or later.

NadelenCons

  • Vereist een techniek onhandige code.Requires an awkward code technique.
  • Als WMF 2.0 wordt uitgevoerd, moet andere syntaxis voor het doorgeven van de argumenten voor een externe sessie.If running WMF 2.0, requires different syntax for passing arguments to a remote session.

VoorbeeldExample

Het volgende voorbeeld ziet u hoe u kunt doorgeven van referenties in een Invoke-Command scriptblok:The following example shows how to pass credentials in an Invoke-Command script block:

# 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 ookSee also

Beveiligingsoverwegingen bij externe communicatie met PowerShellPowerShell Remoting Security Considerations