Compartir a través de

Realizar el segundo salto en la comunicación remota de PowerShell

El "problema del segundo salto" hace referencia a una situación similar a la siguiente:

  1. Ha iniciado sesión en ServerA.
  2. En ServidorA, inicia una sesión remota de PowerShell para conectarse a ServidorB.
  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.
  4. Se deniega el acceso al recurso en ServerC , ya que las credenciales que usó para crear la sesión de comunicación remota de PowerShell no se pasan de ServerB a ServerC.

Hay varias maneras de solucionar este problema. En la tabla siguiente se enumeran los métodos en orden de preferencia.

Configuración Nota:
CredSSP Equilibra la facilidad de uso y la seguridad
Delegación restringida de Kerberos basada en recursos Mayor seguridad con una configuración más sencilla
Delegación limitada de Kerberos Alta seguridad, pero requiere administrador de dominio
Delegación kerberos (sin restricciones) No recomendado
Just Enough Administration (JEA) Puede proporcionar la mejor seguridad, pero requiere una configuración más detallada.
PSSessionConfiguration mediante RunAs Más sencillo de configurar, pero requiere la administración de credenciales
Pasar credenciales dentro de un Invoke-Command bloque de script Más sencillo de usar, pero debe proporcionar credenciales

CredSSP

Puede usar el proveedor de soporte técnico de seguridad de credenciales (CredSSP) para la autenticación. CredSSP almacena en caché las credenciales en el servidor remoto (ServerB), por lo que su uso le abre los ataques de robo de credenciales. Si el equipo remoto se ve comprometido, el atacante tiene acceso a las credenciales del usuario. CredSSP está deshabilitado de forma predeterminada tanto en el equipo del cliente como del servidor. Debe habilitar CredSSP solo en los entornos de mayor confianza. Por ejemplo, un administrador de dominio que se conecta a un controlador de dominio porque el controlador de dominio es de alta confianza.

Para obtener más información sobre los problemas de seguridad al usar CredSSP para la comunicación remota de PowerShell, consulte Sabotaje accidental: Cuidado con CredSSP.

Para obtener más información sobre los ataques de robo de credenciales, vea Mitigación de ataques pass-the-hash (PtH) y otro robo de credenciales.

Para obtener un ejemplo de cómo habilitar y usar CredSSP para la comunicación remota de PowerShell, consulte Habilitación de la funcionalidad de "segundo salto" de PowerShell con CredSSP.

Ventajas

  • Funciona para todos los servidores con Windows Server 2008 o posterior.

Desventajas

  • Tiene vulnerabilidades de seguridad.
  • Requiere la configuración de roles de cliente y servidor.
  • no funciona con el grupo Usuarios protegidos. Para obtener más información, consulte Grupo de seguridad usuarios protegidos.

Delegación limitada de Kerberos

Puede usar la delegación restringida heredada (no basada en recursos) para realizar el segundo salto. Configure la delegación restringida de Kerberos con la opción "Usar cualquier protocolo de autenticación" para permitir la transición del protocolo.

Ventajas

  • No requiere ninguna codificación especial
  • Las credenciales no se almacenan.

Desventajas

  • No admite el segundo salto para WinRM.
  • Requiere acceso de administrador de dominio para configurar.
  • Debe configurarse en el objeto Active Directory del servidor remoto (ServerB).
  • Limitado a un dominio. No se pueden cruzar dominios ni bosques.
  • Requiere derechos para actualizar objetos y nombres de entidad de seguridad de servicio (SPN).
  • ServerB puede adquirir un vale kerberos en ServerC en nombre del usuario sin intervención del usuario.

Nota:

Las cuentas de Active Directory que tienen la cuenta distinguen y no se pueden delegar las propiedades establecidas. Para obtener más información, vea Security Focus: Análisis de "Account is sensitive and can't be delegated" for Privileged Accounts and Kerberos Authentication Tools and Settings.

Delegación restringida de Kerberos basada en recursos

Con la delegación restringida de Kerberos basada en recursos (introducida en Windows Server 2012), se configura la delegación de credenciales en el objeto de servidor donde residen los recursos. En el segundo escenario de salto descrito anteriormente, configurará ServerC para especificar desde dónde acepta credenciales delegadas.

Ventajas

  • Las credenciales no se almacenan.
  • Configurado mediante cmdlets de PowerShell. No se requiere codificación especial.
  • No requiere acceso de administrador de dominio para configurar.
  • Funciona entre dominios y bosques.

Desventajas

  • Requiere Windows Server 2012 o posterior.
  • No admite el segundo salto para WinRM.
  • Requiere derechos para actualizar objetos y nombres de entidad de seguridad de servicio (SPN).

Nota:

Las cuentas de Active Directory que tienen la cuenta distinguen y no se pueden delegar las propiedades establecidas. Para obtener más información, vea Security Focus: Análisis de "Account is sensitive and can't be delegated" for Privileged Accounts and Kerberos Authentication Tools and Settings.

Ejemplo

Echemos un vistazo a un ejemplo de PowerShell que configura la delegación restringida basada en recursos en ServerC para permitir credenciales delegadas de un ServerB. En este ejemplo se supone que todos los servidores ejecutan versiones compatibles de Windows Server y que hay al menos un controlador de dominio de Windows para cada dominio de confianza.

Para poder configurar la delegación restringida, debe agregar la RSAT-AD-PowerShell característica para instalar el módulo de PowerShell de Active Directory y, a continuación, importar ese módulo en la sesión:

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

Ahora hay varios cmdlets disponibles que tienen un parámetro 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

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 de equipo para ServerA).

Ahora vamos a configurar las variables que usaremos para representar los servidores:

# 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. Para ver esto, examine la propiedad StartName del winrm servicio:

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

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

Para que ServerC permita la delegación desde una sesión de comunicación remota de PowerShell en ServerB, debemos establecer el parámetro PrincipalsAllowedToDelegateToAccount en ServerC en el objeto de equipo de 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 almacena en caché los intentos de acceso denegado (caché negativa) durante 15 minutos. Si ServerB ha intentado acceder previamente a ServerC, debe borrar la memoria caché en ServerB invocando el siguiente comando:

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 memoria caché.

Después de borrar la memoria caché, puede ejecutar correctamente el código de ServerA a través de ServerB a 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, el Using: modificador de ámbito se usa para hacer que la $ServerC variable sea visible para ServerB. Para obtener más información sobre el modificador de Using: ámbito, consulte about_Remote_Variables.

Para permitir que varios servidores deleguen credenciales a ServerC, establezca el valor del parámetro PrincipalsAllowedToDelegateToAccount en ServerC en una matriz:

# 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

Si desea realizar el segundo salto entre dominios, use el parámetro Server para especificar el nombre de dominio completo (FQDN) del controlador de dominio del dominio al que pertenece ServerB :

# 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 ServerC, establezca el valor del parámetro PrincipalsAllowedToDelegateToAccount en ServerC$nullen :

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

Información sobre la delegación restringida de Kerberos basada en recursos

Delegación kerberos (sin restricciones)

También puede usar la delegación sin restricciones de Kerberos para realizar el segundo salto. Al igual que todos los escenarios de Kerberos, las credenciales no se almacenan. Este método no admite el segundo salto para WinRM.

Advertencia

Este método no proporciona ningún control de dónde se usan las credenciales delegadas. Es menos seguro que CredSSP. Este método solo se debe usar para escenarios de prueba.

Just Enough Administration (JEA)

JEA permite restringir qué comandos puede ejecutar un administrador durante una sesión de PowerShell. Se puede usar para resolver el problema del segundo salto.

Para obtener información sobre JEA, consulte Just Enough Administration.

Ventajas

  • No hay mantenimiento de contraseñas cuando se usa una cuenta virtual.

Desventajas

  • Requiere WMF 5.0 o posterior.
  • Requiere configuración en cada servidor intermedio (ServerB).

PSSessionConfiguration mediante RunAs

Puede crear una configuración de sesión en ServerB y establecer su parámetro RunAsCredential .

Para obtener información sobre el uso de PSSessionConfiguration y RunAs para resolver el problema del segundo salto, consulte Otra solución para la comunicación remota de PowerShell con varios saltos.

Ventajas

  • Funciona con cualquier servidor con WMF 3.0 o posterior.

Desventajas

  • Requiere la configuración de PSSessionConfiguration y RunAs en todos los servidores intermedios (ServerB).
  • Requiere el mantenimiento de contraseñas cuando se usa una cuenta de ejecución de dominio

Pasar credenciales dentro de un bloque de script de Invoke-Command

Puede pasar credenciales dentro del parámetro ScriptBlock de una llamada al cmdlet Invoke-Command .

Ventajas

  • No requiere una configuración especial del servidor.
  • Funciona en cualquier servidor que ejecute WMF 2.0 o posterior.

Desventajas

  • Requiere una técnica de código complicada.
  • Si ejecuta WMF 2.0, requiere una sintaxis diferente para pasar argumentos a una sesión remota.

Ejemplo

En el ejemplo siguiente se muestra cómo pasar credenciales en un bloque de script:

# 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én

Consideraciones de seguridad de comunicación remota de PowerShell