Realizar el segundo salto en la comunicación remota de PowerShellMaking the second hop in PowerShell Remoting

El "problema del segundo salto" se refiere a una situación similar a la siguiente:The "second hop problem" refers to a situation like the following:

  1. Ha iniciado sesión en ServidorA .You are logged in to ServerA .
  2. En ServidorA , inicia una sesión remota de PowerShell para conectarse a ServidorB .From ServerA , you start a remote PowerShell session to connect to ServerB .
  3. Un comando que ejecuta en ServidorB a través de la sesión de comunicación remota de PowerShell intenta obtener acceso a un recurso en ServidorC .A command you run on ServerB via your PowerShell Remoting session attempts to access a resource on ServerC .
  4. Se le deniega el acceso al recurso en ServidorC , porque no se pasan las credenciales que ha usado para crear la sesión de comunicación remota de PowerShell de ServidorB a ServidorC .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 .

Hay varias formas de abordar este problema.There are several ways to address this problem. En la tabla siguiente se enumeran los métodos por orden de preferencia.The following table lists the methods in order of preference.

ConfiguraciónConfiguration Nota:Note
CredSSPCredSSP Ofrece un equilibrio entre la facilidad de uso y la seguridad.Balances ease of use and security
Delegación limitada de Kerberos basada en recursosResource-based Kerberos constrained delegation Ofrece mayor seguridad con una configuración más sencilla.Higher security with simpler configuration
Delegación limitada de KerberosKerberos constrained delegation Ofrece una seguridad elevada, pero requiere un administrador de dominio.High security but requires Domain Administrator
Delegación Kerberos (sin restricciones)Kerberos delegation (unconstrained) No recomendadoNot recommended
Just Enough Administration (JEA)Just Enough Administration (JEA) Puede proporcionar la mejor seguridad, pero requiere una configuración más detallada.Can provide the best security but requires more detailed configuration
PSSessionConfiguration con RunAsPSSessionConfiguration using RunAs Es una opción más sencilla de configurar, pero requiere la administración de credenciales.Simpler to configure but requires credential management
Pase de credenciales dentro de un bloque de script de Invoke-CommandPass credentials inside an Invoke-Command script block Es la opción más sencilla de usar, pero se deben proporcionar credenciales.Simplest to use but you must provide credentials

CredSSPCredSSP

Puede usar el proveedor de compatibilidad para seguridad de credenciales (CredSSP) para la autenticación.You can use the Credential Security Support Provider (CredSSP) for authentication. CredSSP copia en caché las credenciales en el servidor remoto ( ServidorB ), por lo que, al usarlo, le hace vulnerable a los ataques de robos de credenciales.CredSSP caches credentials on the remote server ( ServerB ), so using it opens you up to credential theft attacks. Si el equipo remoto se ve comprometido, el atacante tiene acceso a las credenciales del usuario.If the remote computer is compromised, the attacker has access to the user's credentials. CredSSP está deshabilitado de forma predeterminada tanto en el equipo del cliente como del servidor.CredSSP is disabled by default on both client and server computers. Debe habilitar CredSSP solo en los entornos de mayor confianza.You should enable CredSSP only in the most trusted environments. Por ejemplo, un administrador de dominio que se conecta a un controlador de dominio porque el controlador de dominio es de plena confianza.For example, a domain administrator connecting to a domain controller because the domain controller is highly trusted.

Para obtener más información sobre problemas de seguridad cuando se usa CredSSP para la comunicación remota de PowerShell, vea Accidental Sabotage: Beware of CredSSP (Sabotaje accidental: tenga cuidado con CredSSP).For more information about security concerns when using CredSSP for PowerShell Remoting, see Accidental Sabotage: Beware of CredSSP.

Para obtener más información acerca de los ataques de robo de credenciales, consulte Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft (Mitigación de ataques Pass-the-Hash (PtH) y otros robos de credenciales).For more information about credential theft attacks, see Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft.

Para obtener un ejemplo sobre cómo habilitar y usar CredSSP para la comunicación remota de PowerShell, vea Habilitar la funcionalidad "segundo salto" de PowerShell con CredSSP.For an example of how to enable and use CredSSP for PowerShell remoting, see Enable PowerShell "Second-Hop" Functionality with CredSSP.

VentajasPros

  • Funciona en todos los servidores con Windows Server 2008 o versiones posteriores.It works for all servers with Windows Server 2008 or later.

DesventajasCons

  • Tiene vulnerabilidades de seguridad.Has security vulnerabilities.
  • Requiere la configuración de roles de cliente y servidor.Requires configuration of both client and server roles.
  • No funciona con el grupo de usuarios protegidos.Does not work with the Protected Users group. Para obtener más información, vea Grupo de seguridad de usuarios protegidos.For more information, see Protected Users Security Group.

Delegación limitada de KerberosKerberos constrained delegation

Puede usar la delegación limitada heredada (no basada en recursos) para realizar el segundo salto.You can use legacy constrained delegation (not resource-based) to make the second hop. Configure la delegación restringida de Kerberos con la opción "Usar cualquier protocolo de autenticación" para permitir la transición del protocolo.Configure Kerberos constrained delegation with the option "Use any authentication protocol" to allow protocol transition.

VentajasPros

  • No requiere código especialRequires no special coding
  • Las credenciales no se almacenan.Credentials are not stored.

DesventajasCons

  • No se admite el segundo salto para WinRM.Does not support the second hop for WinRM.
  • Requiere el acceso de administrador de dominio para la configuración.Requires Domain Administrator access to configure.
  • Se debe configurar en el objeto de Active Directory del servidor remoto ( ServidorB ).Must be configured on the Active Directory object of the remote server ( ServerB ).
  • Limitado a un dominio.Limited to one domain. No puede cruzar dominios ni bosques.Cannot cross domains or forests.
  • Requiere derechos para actualizar objetos y nombres de entidad de seguridad de servicio (SPN).Requires rights to update objects and Service Principal Names (SPNs).
  • El ServidorB puede adquirir un vale de Kerberos para el ServidorC en nombre del usuario sin la intervención de este.ServerB can acquire a Kerberos ticket to ServerC on behalf of the user without user intervention.

Nota

No se pueden delegar las cuentas de Active Directory que tengan la propiedad La cuenta es importante y no se puede delegar establecida.Active Directory accounts that have the Account is sensitive and cannot be delegated property set cannot be delegated. Para obtener más información, consulte Security Focus: analizar "La cuenta es importante y no se puede delegar" para cuentas con privilegios y Configuración y herramientas de la autenticación Kerberos.For more information, see Security Focus: Analysing 'Account is sensitive and cannot be delegated' for Privileged Accounts and Kerberos Authentication Tools and Settings.

Delegación limitada de Kerberos basada en recursosResource-based Kerberos constrained delegation

Con la delegación limitada de Kerberos basada en recursos (introducida en Windows Server 2012), configura la delegación de credenciales en el objeto de servidor en que residen los recursos.Using resource-based Kerberos constrained delegation (introduced in Windows Server 2012), you configure credential delegation on the server object where resources reside. En el escenario del segundo salto descrito anteriormente, puede configurar el ServidorC para especificar desde dónde aceptar las credenciales delegadas.In the second hop scenario described above, you configure ServerC to specify from where it accepts delegated credentials.

VentajasPros

  • Las credenciales no se almacenan.Credentials are not stored.
  • Se configura con los cmdlets de PowerShell.Configured using PowerShell cmdlets. No requiere código especial.No special coding required.
  • No requiere el acceso de administrador de dominio para la configuración.Does not require Domain Administrator access to configure.
  • Funciona en dominios y bosques.Works across domains and forests.

DesventajasCons

  • Necesita Windows Server 2012 o versiones posteriores.Requires Windows Server 2012 or later.
  • No se admite el segundo salto para WinRM.Does not support the second hop for WinRM.
  • Requiere derechos para actualizar objetos y nombres de entidad de seguridad de servicio (SPN).Requires rights to update objects and Service Principal Names (SPNs).

Nota

No se pueden delegar las cuentas de Active Directory que tengan la propiedad La cuenta es importante y no se puede delegar establecida.Active Directory accounts that have the Account is sensitive and cannot be delegated property set cannot be delegated. Para obtener más información, consulte Security Focus: analizar "La cuenta es importante y no se puede delegar" para cuentas con privilegios y Configuración y herramientas de la autenticación Kerberos.For more information, see Security Focus: Analysing 'Account is sensitive and cannot be delegated' for Privileged Accounts and Kerberos Authentication Tools and Settings.

EjemploExample

Veamos un ejemplo de PowerShell que configura la delegación restringida basada en recursos en el ServidorC para admitir credenciales delegadas de un ServidorB .Let's look at a PowerShell example that configures resource-based constrained delegation on ServerC to allow delegated credentials from a ServerB . En este ejemplo, se supone que todos los servidores ejecutan Windows Server 2012 o una versión posterior y que hay al menos un controlador de dominio de Windows Server 2012 en cada dominio a los que pertenecen los servidores.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.

Antes de que pueda configurar la delegación restringida, debe agregar la característica RSAT-AD-PowerShell para instalar el módulo de PowerShell de Active Directory y después importar ese módulo en la sesión: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:

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

Varios cmdlets disponibles tienen ahora un parámetro PrincipalsAllowedToDelegateToAccount :Several available cmdlets now have a 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

El parámetro PrincipalsAllowedToDelegateToAccount establece el atributo de objeto de Active Directory msDS-AllowedToActOnBehalfOfOtherIdentity , que contiene una lista de control de acceso (ACL) que especifica qué cuentas tienen permiso para delegar credenciales a la cuenta asociada (en nuestro ejemplo, será la cuenta del equipo de ServidorA ).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 ServerA ).

Ahora vamos a configurar las variables que usaremos para representar los servidores: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 (y, por tanto, la comunicación remota de PowerShell) se ejecuta como la cuenta de equipo de forma predeterminada.WinRM (and therefore PowerShell remoting) runs as the computer account by default. Puede ver esto si atiende a la propiedad StartName del servicio winrm:You can see this by looking at the StartName property of the winrm service:

Get-CimInstance Win32_Service -Filter 'Name="winrm"' | Select-Object StartName
StartName
---------
NT AUTHORITY\NetworkService

Para que ServidorC permita la delegación desde una sesión de comunicación remota de PowerShell en ServidorB , debemos establecer el parámetro PrincipalsAllowedToDelegateToAccount en ServidorC al objeto de equipo de ServidorB :For ServerC to allow delegation from a PowerShell remoting session on ServerB , we must set 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

El Centro de distribución de claves (KDC) de Kerberos copia en caché los intentos de acceso denegados (caché negativa) durante 15 minutos.The Kerberos Key Distribution Center (KDC) caches denied-access attempts (negative cache) for 15 minutes. Si ServidorB ha intentado previamente obtener acceso a ServidorC , deberá borrar la caché de ServidorB al invocar el comando siguiente: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
}

También puede reiniciar el equipo o esperar al menos 15 minutos para borrar la caché.You could also restart the computer, or wait at least 15 minutes to clear the cache.

Después de borrar la caché, puede ejecutar correctamente código desde el ServidorA a través del ServidorB hasta el ServidorC :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)
}

En este ejemplo, la variable $using se usa para hacer visible la variable $ServerC en el ServidorB .In this example, the $using variable is used to make the $ServerC variable visible to ServerB . Para obtener más información sobre la variable $using, consulte about_Remote_Variables.For more information about the $using variable, see about_Remote_Variables.

Para permitir que varios servidores deleguen credenciales en el ServidorC , establezca el valor del parámetro PrincipalsAllowedToDelegateToAccount en el ServidorC a una matriz: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)

Si quiere realizar el segundo salto entre dominios, agregue el nombre de dominio completo (FQDN) del controlador del dominio al que pertenece el ServidorB :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

Para quitar la capacidad de delegar credenciales en el ServidorC, establezca el valor del parámetro PrincipalsAllowedToDelegateToAccount en el ServidorC en $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

Información sobre la delegación limitada de Kerberos basada en recursosInformation on resource-based Kerberos constrained delegation

Delegación Kerberos (sin restricciones)Kerberos delegation (unconstrained)

También puede usar la delegación Kerberos sin restricciones para realizar el segundo salto.You can also used Kerberos unconstrained delegation to make the second hop. Al igual que todos los escenarios de Kerberos, las credenciales no se almacenan.Like all Kerberos scenarios, credentials are not stored. Este método no admite el segundo salto para WinRM.This method does not support the second hop for WinRM.

Advertencia

No proporciona control sobre dónde se usan las credenciales delegadas.This method provides no control of where delegated credentials are used. Es menos seguro que CredSSP.It is less secure than CredSSP. Solo se debe usar para escenarios de prueba.This method should only be used for testing scenarios.

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

JEA le permite restringir qué comandos puede ejecutar un administrador durante una sesión de PowerShell.JEA allows you to restrict what commands an administrator can run during a PowerShell session. Se puede usar para resolver el problema del segundo salto.It can be used to solve the second hop problem.

Para obtener información sobre JEA, consulte Just Enough Administration.For information about JEA, see Just Enough Administration.

VentajasPros

  • No hay mantenimiento de contraseña al usar una cuenta virtual.No password maintenance when using a virtual account.

DesventajasCons

  • Requiere WMF 5.0 o versiones posteriores.Requires WMF 5.0 or later.
  • Es necesario configurar cada servidor intermedio ( ServidorB ).Requires configuration on every intermediate server ( ServerB ).

PSSessionConfiguration con RunAsPSSessionConfiguration using RunAs

Puede crear una configuración de sesión en el ServidorB y establecer su parámetro RunAsCredential .You can create a session configuration on ServerB and set its RunAsCredential parameter.

Para obtener información sobre el uso de PSSessionConfiguration y RunAs para resolver el problema del segundo salto, vea Otra solución a la comunicación remota de PowerShell de varios saltos.For information about using PSSessionConfiguration and RunAs to solve the second hop problem, see Another solution to multi-hop PowerShell remoting.

VentajasPros

  • Funciona con cualquier servidor con WMF 3.0 o versiones posteriores.Works with any server with WMF 3.0 or later.

DesventajasCons

  • Requiere la configuración de PSSessionConfiguration y RunAs en cada servidor intermedio ( ServidorB ).Requires configuration of PSSessionConfiguration and RunAs on every intermediate server ( ServerB ).
  • Requiere el mantenimiento de la contraseña cuando se usa una cuenta de ejecución de dominioRequires password maintenance when using a domain RunAs account

Pasar credenciales dentro de un bloque de script de Invoke-CommandPass credentials inside an Invoke-Command script block

Se pueden pasar credenciales dentro del parámetro ScriptBlock de una llamada al cmdlet Invoke-Command.You can pass credentials inside the ScriptBlock parameter of a call to the Invoke-Command cmdlet.

VentajasPros

  • No requiere configuración especial del servidor.Does not require special server configuration.
  • Funciona en cualquier servidor que ejecute WMF 2.0 o versiones posteriores.Works on any server running WMF 2.0 or later.

DesventajasCons

  • Se requiere una técnica de código complicada.Requires an awkward code technique.
  • Si ejecuta WMF 2.0, requiere una sintaxis diferente para pasar argumentos a una sesión remota.If running WMF 2.0, requires different syntax for passing arguments to a remote session.

EjemploExample

En el ejemplo siguiente, se muestra cómo pasar las credenciales en un bloque de script Invoke-Command :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}
}

Consulte tambiénSee also

Consideraciones de seguridad de comunicación remota de PowerShellPowerShell Remoting Security Considerations