%3F.png)
Siempre he accedido a máquinas remotas con cosas como archivos compartidos (\\serverName\share) y usando comandos de Powershell que usan un parámetro -ComputerName. Si hago esto para una máquina en un dominio remoto, debo proporcionar el argumento -Credential. Y todo eso funciona bien. Creo que eso se llama DCOM. También puedo acceder a WMI así. Sin embargo, cuando intento usar enter-pssession en la máquina remota, no funciona debido a algún problema de Kerberos. Supuestamente, la diferencia es que Kerberos proporciona autenticación mutua de las máquinas. Pero, si accedo a una máquina en un dominio remoto, de todos modos no estoy usando Kerberos para las transacciones de estilo DCOM. Entonces, si hago que la sesión funcione colocando la máquina remota en mis Winrm TrustedHosts (y nombrándola con la dirección IP) en lugar de configurar una infraestructura de certificados (y por lo tanto no tener ninguna autenticación de máquina), eso es realmente peor que el DCOM. ¿Comandos que he estado ejecutando desde siempre? --He visto a personas escribir cosas como "use esto solo en máquinas de prueba, no en un entorno de producción" porque la conexión no está cifrada. Pero, supuestamente, la transacción de credenciales todavía está cifrada. Si está bien usar -ComputerName y -Credential con otros comandos, ¿cuál es la diferencia?
Respuesta1
Sí, es menos seguro.
NTLM (que es el protocolo de autenticación utilizado) es técnicamente menos seguro. Estás presentando tus credenciales a un anfitrión. Y NTLM no ofrece autenticación del host al cliente. Es sencillo para un atacante hacerse pasar por ese host en esa dirección IP.
En un entorno Kerberos, no presenta sus credenciales al host, las presenta a un servidor de autenticación independiente, este proporciona un token y ese token luego se presenta para la autenticación. Las credenciales se presentan en menos hosts que son más seguros que un servidor típico.
Si la autenticación básica está habilitada y utilizada en lugar de Negociar/NTLM, esas credenciales se envían por cable sin cifrar, lo que obviamente es malo. Sin embargo, después de la autenticación, la sesión se cifra a nivel de mensaje independientemente del esquema de transporte HTTP/HTTPS. Los métodos de autenticación Basic+HTTP y Digest nunca deben habilitarse/utilizarse.
La mayoría de las organizaciones no hacen esto porque no pasaría una auditoría. En escenarios de grupos de trabajo, casi siempre se utilizan certificados.
https://devblogs.microsoft.com/powershell/compromising-yourself-with-winrms-allowunencrypted-true/