Compartir a través de

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

  • Artículo

El "problema del segundo salto" se refiere a una situación similar a la siguiente:

  1. Ha iniciado sesión en ServidorA.
  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 ha usado para crear la sesión de comunicación remota de PowerShell no se pasan de ServerB a ServerC.

Hay varias formas de abordar este problema. En la tabla siguiente se enumeran los métodos por orden de preferencia.

Configuración Nota:
CredSSP Ofrece un equilibrio entre la facilidad de uso y la seguridad.
Delegación limitada de Kerberos basada en recursos Ofrece mayor seguridad con una configuración más sencilla.
Delegación limitada de Kerberos Ofrece una seguridad elevada, pero requiere un administrador de dominio.
Delegación Kerberos (sin restricciones) No se recomienda
Just Enough Administration (JEA) Puede proporcionar la mejor seguridad, pero requiere una configuración más detallada.
PSSessionConfiguration con RunAs Es una opción más sencilla de configurar, pero requiere la administración de credenciales.
Pase de credenciales dentro de un bloque de script de Invoke-Command Es la opción más sencilla de usar, pero se deben proporcionar credenciales.

CredSSP

Puede usar el proveedor de compatibilidad para seguridad de credenciales (CredSSP) para la autenticación. 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. 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 plena confianza.

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

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

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.

Ventajas

  • Funciona en todos los servidores con Windows Server 2008 o versiones posteriores.

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, vea Grupo de seguridad de usuarios protegidos.

Delegación limitada de Kerberos

Puede usar la delegación limitada 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 código especial
  • Las credenciales no se almacenan.

Desventajas

  • No admite el segundo salto para WinRM.
  • Requiere el acceso de administrador de dominio para la configuración.
  • Se debe configurar en el objeto de Active Directory del servidor remoto (ServidorB).
  • 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).
  • El ServidorB puede adquirir un vale de Kerberos para el ServidorC en nombre del usuario sin la intervención de este.

Nota:

Las cuentas de Active Directory que tienen la propiedad Cuenta es confidencial y no se puede delegar no se pueden delegar. Para más información, consulte Enfoque de seguridad: análisis de "La cuenta es confidencial y no se puede delegar" para Cuentas con privilegios y Herramientas y configuración de autenticación Kerberos.

Delegación limitada de Kerberos basada en recursos

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. En el escenario del segundo salto descrito anteriormente, puede configurar el ServidorC para especificar desde dónde aceptar las credenciales delegadas.

Ventajas

  • Las credenciales no se almacenan.
  • Se configura con los cmdlets de PowerShell. No requiere código especial.
  • No requiere acceso de administrador de dominio para configurar.
  • Funciona en dominios y bosques.

Desventajas

  • Necesita Windows Server 2012 o versiones posteriores.
  • 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 propiedad Cuenta es confidencial y no se puede delegar no se pueden delegar. Para más información, consulte Enfoque de seguridad: análisis de "La cuenta es confidencial y no se puede delegar" para Cuentas con privilegios y Herramientas y configuración de autenticación Kerberos.

Ejemplo

Veamos un ejemplo de PowerShell que configura la delegación restringida basada en recursos en el ServidorC para admitir credenciales delegadas de un ServidorB. 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.

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:

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

Varios cmdlets disponibles tienen ahora 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 del equipo de ServidorA).

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. Puede ver esto si atiende a la propiedad StartName del servicio winrm:

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:

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

Después de borrar la caché, puede ejecutar correctamente código desde el ServidorA a través del ServidorB hasta el ServidorC:

# 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. Para obtener más información sobre la variable $using, consulte 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:

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

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

Información sobre la delegación limitada 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

No proporciona control sobre dónde se usan las credenciales delegadas. Es menos seguro que CredSSP. Solo se debe usar para escenarios de prueba.

Just Enough Administration (JEA)

JEA le 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ña al usar una cuenta virtual.

Desventajas

  • Requiere WMF 5.0 o versiones posteriores.
  • Es necesario configurar cada servidor intermedio (ServidorB).

PSSessionConfiguration con RunAs

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

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.

Ventajas

  • Funciona con cualquier servidor con WMF 3.0 o versiones posteriores.

Desventajas

  • Requiere la configuración de PSSessionConfiguration y RunAs en cada servidor intermedio (ServidorB).
  • Requiere el mantenimiento de la contraseña cuando se usa una cuenta de ejecución de dominio

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

Se pueden 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 versiones posteriores.

Desventajas

  • Se 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