about_Remote_Requirements
Descripción breve
Describe los requisitos del sistema y los requisitos de configuración para ejecutar comandos remotos en PowerShell.
Descripción larga
En este tema se describen los requisitos del sistema, los requisitos de usuario y los requisitos de recursos para establecer conexiones remotas y ejecutar comandos remotos en PowerShell. También proporciona instrucciones para configurar operaciones remotas.
Nota
Muchos cmdlets (incluidos los Get-Servicecmdlets , Get-Process, Get-WMIObjectGet-EventLog, y Get-WinEvent ) obtienen objetos de equipos remotos mediante métodos de Microsoft .NET Framework para recuperar los objetos. No usan la infraestructura de comunicación remota de PowerShell. Los requisitos de este documento no se aplican a estos cmdlets.
Para buscar los cmdlets que tienen un parámetro ComputerName pero no usan la comunicación remota de PowerShell, lea la descripción del parámetro ComputerName de los cmdlets.
Requisitos del sistema
Para ejecutar sesiones remotas en Windows PowerShell 3.0, los equipos locales y remotos deben tener lo siguiente:
- Windows PowerShell 3.0 o posterior
- Microsoft .NET Framework 4 o posterior
- Administración remota de Windows 3.0
Para ejecutar sesiones remotas en Windows PowerShell 2.0, los equipos locales y remotos deben tener lo siguiente:
- Windows PowerShell 2.0 o posterior
- Microsoft .NET Framework 2.0 o posterior
- Administración remota de Windows 2.0
Puede crear sesiones remotas entre equipos que ejecutan Windows PowerShell 2.0 y Windows PowerShell 3.0. Sin embargo, las características que solo se ejecutan en Windows PowerShell 3.0, como la capacidad de desconectar y volver a conectarse a sesiones, solo están disponibles cuando ambos equipos ejecutan Windows PowerShell 3.0.
Para buscar el número de versión de una versión instalada de PowerShell, use la $PSVersionTable variable automática.
Windows Remote Management (WinRM) 3.0 y Microsoft .NET Framework 4 se incluyen en Windows 8, Windows Server 2012 y versiones más recientes del sistema operativo Windows. WinRM 3.0 se incluye en Windows Management Framework 3.0 para sistemas operativos anteriores. Si el equipo no tiene la versión necesaria de WinRM o Microsoft .NET Framework, se produce un error en la instalación.
Permisos de usuario
Para crear sesiones remotas y ejecutar comandos remotos, de forma predeterminada, el usuario actual debe ser miembro del grupo Administradores en el equipo remoto o proporcionar las credenciales de un administrador. De lo contrario, se produce un error en el comando.
Los permisos necesarios para crear sesiones y ejecutar comandos en un equipo remoto (o en una sesión remota en el equipo local) se establecen mediante la configuración de sesión (también conocida como punto de conexión) en el equipo remoto al que se conecta la sesión. En concreto, el descriptor de seguridad de la configuración de sesión determina quién tiene acceso a la configuración de sesión y quién puede usarlo para conectarse.
Los descriptores de seguridad de las configuraciones de sesión predeterminadas, Microsoft.PowerShell, Microsoft.PowerShell32 y Microsoft.PowerShell.Workflow, solo permiten el acceso a los miembros del grupo Administradores .
Si el usuario actual no tiene permiso para usar la configuración de sesión, se produce un error en el comando para ejecutar un comando (que usa una sesión temporal) o crear una sesión persistente en el equipo remoto. El usuario puede usar el parámetro ConfigurationName de cmdlets que crean sesiones para seleccionar una configuración de sesión diferente, si hay alguna disponible.
Los miembros del grupo Administradores de un equipo pueden determinar quién tiene permiso para conectarse al equipo de forma remota cambiando los descriptores de seguridad en las configuraciones de sesión predeterminadas y creando nuevas configuraciones de sesión con distintos descriptores de seguridad.
Para obtener más información sobre las configuraciones de sesión, consulte about_Session_Configurations.
Ubicaciones de red de Windows
A partir de Windows PowerShell 3.0, el cmdlet puede habilitar la Enable-PSRemoting comunicación remota en versiones de cliente y servidor de Windows en redes privadas, de dominio y públicas.
En las versiones de servidor de Windows con redes privadas y de dominio, el Enable-PSRemoting cmdlet crea reglas de firewall que permiten el acceso remoto sin restricciones. También crea una regla de firewall para redes públicas que permite el acceso remoto solo desde equipos de la misma subred local. Esta regla de firewall de subred local está habilitada de forma predeterminada en las versiones de servidor de Windows en redes públicas, pero Enable-PSRemoting vuelve a aplicar la regla en caso de que se haya cambiado o eliminado.
En las versiones de cliente de Windows con redes privadas y de dominio, de forma predeterminada, el Enable-PSRemoting cmdlet crea reglas de firewall que permiten el acceso remoto sin restricciones.
Para habilitar la comunicación remota en versiones de cliente de Windows con redes públicas, use el parámetro SkipNetworkProfileCheck del Enable-PSRemoting cmdlet . Crea una regla de firewall que solo permite el acceso remoto desde equipos de la misma subred local.
Para quitar la restricción de subred local en redes públicas y permitir el acceso remoto desde todas las ubicaciones de las versiones de cliente y servidor de Windows, use el Set-NetFirewallRule cmdlet en el módulo NetSecurity . Ejecute el siguiente comando:
Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any
Nota
El nombre de la regla de firewall puede ser diferente para diferentes versiones de Windows. Use Get-NetFirewallRule para ver una lista de reglas. Antes de habilitar la regla de firewall, vea la configuración de seguridad de la regla para comprobar que la configuración es adecuada para su entorno.
En Windows PowerShell 2.0, en versiones de servidor de Windows, Enable-PSRemoting crea reglas de firewall que permiten el acceso remoto en todas las redes.
En Windows PowerShell 2.0, en versiones de cliente de Windows, Enable-PSRemoting crea reglas de firewall solo en redes privadas y de dominio. Si la ubicación de red es pública, Enable-PSRemoting se produce un error.
Ejecutar como administrador
Los privilegios de administrador son necesarios para las siguientes operaciones de comunicación remota:
Establecer una conexión remota al equipo local. Esto se conoce normalmente como un escenario de "bucle invertido".
Administración de configuraciones de sesión en el equipo local.
Ver y cambiar la configuración de WS-Management en el equipo local. Estos son los valores del nodo LocalHost de la unidad WSMAN: .
Para realizar estas tareas, debe iniciar PowerShell con la opción "Ejecutar como administrador", incluso si es miembro del grupo Administradores en el equipo local.
En Windows 7 y en Windows Server 2008 R2, para iniciar PowerShell con la opción Ejecutar como administrador :
- Haga clic en Inicio, Todos los programas, Accesorios y, a continuación, en la carpeta De PowerShell.
- Haga clic con el botón derecho en PowerShell y, a continuación, haga clic en Ejecutar como administrador.
Para iniciar Windows PowerShell con la opción Ejecutar como administrador:
- Haga clic en Inicio, todos los programas y, a continuación, haga clic en la carpeta De PowerShell.
- Haga clic con el botón derecho en PowerShell y, a continuación, haga clic en Ejecutar como administrador.
La opción Ejecutar como administrador también está disponible en otras entradas del Explorador de Windows para PowerShell, incluidos los accesos directos. Solo tiene que hacer clic con el botón derecho en el elemento y, a continuación, hacer clic en Ejecutar como administrador.
Al iniciar PowerShell desde otro programa, como Cmd.exe, use la opción Ejecutar como administrador para iniciar el programa.
Cómo configurar el equipo para la comunicación remota
Los equipos que ejecutan todas las versiones compatibles de Windows pueden establecer conexiones remotas y ejecutar comandos remotos en PowerShell sin ninguna configuración. Sin embargo, para recibir conexiones y permitir a los usuarios crear sesiones de PowerShell locales y remotas administradas por el usuario ("PSSessions") y ejecutar comandos en el equipo local, debe habilitar la comunicación remota de PowerShell en el equipo.
Windows Server 2012 y versiones más recientes de Windows Server están habilitadas para la comunicación remota de PowerShell de forma predeterminada. Si se cambia la configuración, puede restaurar la configuración predeterminada mediante la ejecución del Enable-PSRemoting cmdlet .
En todas las demás versiones compatibles de Windows, debe ejecutar el cmdlet para habilitar la Enable-PSRemoting comunicación remota de PowerShell.
Las características de comunicación remota de PowerShell son compatibles con el servicio WinRM, que es la implementación de Microsoft del protocolo Servicios web para administración (WS-Management). Al habilitar la comunicación remota de PowerShell, se cambia la configuración predeterminada de WS-Management y se agrega la configuración del sistema que permite a los usuarios conectarse a WS-Management.
Para configurar PowerShell para recibir comandos remotos:
- Inicie PowerShell con la opción Ejecutar como administrador .
- En el símbolo del sistema, escriba:
Enable-PSRemoting
Para comprobar que la comunicación remota está configurada correctamente, ejecute un comando de prueba, como el siguiente, que crea una sesión remota en el equipo local.
New-PSSession
Si la comunicación remota está configurada correctamente, el comando creará una sesión en el equipo local y devolverá un objeto que representa la sesión. La salida debe ser similar a la siguiente salida de ejemplo:
Id Name ComputerName State ConfigurationName
-- ---- ------------ ----- -----
1 Session1 localhost Opened Microsoft.PowerShell
Si se produce un error en el comando, consulte about_Remote_Troubleshooting.
Información sobre las directivas
Al trabajar de forma remota, se usan dos instancias de PowerShell, una en el equipo local y otra en el equipo remoto. Como resultado, el trabajo se ve afectado por las directivas de Windows y las directivas de PowerShell en los equipos locales y remotos.
En general, antes de conectarse y al establecer la conexión, las directivas del equipo local están en vigor. Cuando se usa la conexión, las directivas del equipo remoto están en vigor.
Limitaciones de autenticación básicas en Linux y macOS
Al conectarse desde un sistema Linux o macOS a Windows, no se admite la autenticación básica a través de HTTP. La autenticación básica se puede usar a través de HTTPS mediante la instalación de un certificado en el servidor de destino. El certificado debe tener un nombre CN que coincida con el nombre de host, no ha expirado ni revocado. Se puede usar un certificado autofirmado con fines de prueba.
Consulte How To: Configure WINRM for HTTPS (Cómo: Configurar WINRM para HTTPS ) para obtener más detalles.
El comando siguiente, que se ejecuta desde un símbolo del sistema con privilegios elevados, configurará el agente de escucha HTTPS en Windows con el certificado instalado.
$hostinfo = '@{Hostname="<DNS_NAME>"; CertificateThumbprint="<THUMBPRINT>"}'
winrm create winrm/config/Listener?Address=*+Transport=HTTPS $hostinfo
En el lado Linux o macOS, seleccione Básico para la autenticación y -UseSSl.
Nota
No se puede usar la autenticación básica con cuentas de dominio; se requiere una cuenta local y la cuenta debe estar en el grupo Administradores .
# The specified local user must have administrator rights on the target machine.
# Specify the unqualified username.
$cred = Get-Credential username
$session = New-PSSession -Computer <hostname> -Credential $cred `
-Authentication Basic -UseSSL
Una alternativa a la autenticación básica a través de HTTPS es Negotiate. Esto da como resultado la autenticación NTLM entre el cliente y el servidor y la carga se cifra a través de HTTP.
A continuación se muestra el uso de Negotiate con New-PSSession:
# The specified user must have administrator rights on the target machine.
$cred = Get-Credential username@hostname
$session = New-PSSession -Computer <hostname> -Credential $cred `
-Authentication Negotiate
Nota
Windows Server requiere una configuración adicional del Registro para permitir que los administradores, que no sean el administrador integrado, se conecten mediante NTLM. Consulte la configuración del Registro LocalAccountTokenFilterPolicy en Negotiate Authentication in Authentication for Remote Connections