Administración remota de Windows sobre dominios no confiables


12

Actualmente estoy tratando de habilitar la administración remota de Windows (específicamente, Powershell Remoting) entre 2 dominios no confiables, y no tengo suerte.

Una breve descripción de mi configuración:

  • dominio1: mi estación de trabajo está en este dominio
  • dominio2: el servidor al que deseo conectarme está en este dominio

No hay confianza entre estos dominios.

Estoy intentando crear la conexión remota de Powershell usando los siguientes comandos desde mi estación de trabajo (unida al dominio1):

param (
    [Parámetro (obligatorio = $ verdadero)]
    $ servidor
)

$ username = "dominio \ usuario"
$ contraseña = read-host "Ingrese la contraseña para $ username" -AsSecureString

$ credential = New-Object System.Management.Automation.PSCredential ($ nombre de usuario, $ contraseña)

$ session = New-PSSession "$ server" -CredSSP de autenticación -Credential $ credential -UseSSL -SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck)
Enter-PSSession $ session

Lo que da como resultado el siguiente mensaje de error:

New-PSSession: [computername.domain2.com] La conexión al servidor remoto computername.domain2.com falló con el siguiente mensaje de error: El cliente WinRM
No se puede procesar la solicitud. Una política informática no permite la delegación de credenciales de usuario en la computadora de destino porque la computadora no es confiable. La identidad del objetivo.
la computadora se puede verificar si configura el servicio WSMAN para usar un certificado válido con el siguiente comando: winrm set winrm / config / service '@ {CertificateThumbprint = ""}' O
puede verificar el Visor de eventos para un evento que especifique que no se pudo crear el siguiente SPN: WSMAN /. Si encuentra este evento, puede crear manualmente el SPN usando
setspn.exe. Si existe el SPN, pero CredSSP no puede usar Kerberos para validar la identidad de la computadora de destino y aún desea permitir la delegación de las credenciales de usuario en el destino
computadora, use gpedit.msc y observe la siguiente política: Configuración de la computadora -> Plantillas administrativas -> Sistema -> Delegación de credenciales -> Permitir credenciales nuevas solo con NTLM
Autenticación del servidor. Verifique que esté habilitado y configurado con un SPN apropiado para la computadora de destino. Por ejemplo, para un nombre de computadora de destino "myserver.domain.com", el SPN puede ser
uno de los siguientes: WSMAN / myserver.domain.com o WSMAN / *. domain.com. Intente la solicitud nuevamente después de estos cambios. Para obtener más información, consulte el tema de Ayuda about_Remote_Troubleshooting.

He intentado / verificado las siguientes cosas:

  1. Verifiqué que existe un SPN para WSMAN \ computername y WSMAN \ computername.domain2.com en domain2.
  2. Verificó que la Configuración del equipo -> Plantillas administrativas -> Sistema -> Delegación de credenciales -> Permitir credenciales nuevas con autenticación de servidor solo NTLM se haya configurado correctamente.
  3. Winrm configurado en la computadora de destino para usar SSL.
  4. Configurado CredSSP en la computadora de destino y mi estación de trabajo local usando los siguientes comandos:
Enable-WSManCredSSP -Role Server #en la computadora de destino
Enable-WSManCredSSP -Role Client -DelegateComputer * -Force
  1. Verifiqué que ninguna regla de FW, ya sea local para las computadoras o la red está bloqueando mi acceso.

Ninguno de los cuales me ha permitido conectarme con éxito a la computadora de destino en el dominio2 desde mi estación de trabajo en el dominio1. Puedo conectarme con éxito a otros servidores que están unidos al dominio1, pero no a los servidores del dominio2. ¿Hay algo más que debería estar buscando y / o tratar de hacer que esto funcione?

ACTUALIZACIÓN 06/08/2015 De hecho, he podido verificar que me puedo conectar al servidor desde mi estación de trabajo sin usar CredSSP, lo cual estaría bien; sin embargo, necesito poder ejecutar scripts en SharePoint, y hacerlo sin CredSSP falla con un error de permisos.


¿Has intentado ser más específico sobre a qué delegas tus credenciales? Por ejemplo Enable-WSManCredSSP -Role Client -DelegateComputer WSMAN/computername.domain2.com( msdn.microsoft.com/en-us/library/ee309365(v=vs.85).aspx , punto 3.)
juan


Desafortunadamente, ninguna de esas sugerencias ha funcionado.
Nick DeMayo


1
Oooo! Encontré la respuesta en el artículo que vinculaste también. Intenté en el pasado configurar "AllowFreshCredentialsDomain" para tener un SPN, pero eso no funcionó. Resulta que podría establecer "AllowFreshCredentialsWhenNTLMOnly" y "AllowFreshCredentialsWhenNTLMOnlyDomain" y ¡funciona! usuario2320464, si pudiera publicar su comentario como respuesta, lo aceptaré y obtendrá la recompensa.
Nick DeMayo

Respuestas:


2

Este artículo de MSDN muestra cómo configurar WinRM para la compatibilidad con múltiples saltos, que también aborda hacer conexiones cuando Kerberos no es una opción. Breve resumen a continuación.

La Administración remota de Windows (WinRM) admite la delegación de credenciales de usuario en varias computadoras remotas. La funcionalidad de soporte de múltiples saltos ahora puede usar el Credential Security Service Provider (CredSSP) para la autenticación. CredSSP permite que una aplicación delegue las credenciales del usuario del equipo cliente al servidor de destino.

La autenticación CredSSP está destinada a entornos donde no se puede utilizar la delegación Kerberos. Se agregó soporte para CredSSP para permitir que un usuario se conecte a un servidor remoto y tenga la capacidad de acceder a una máquina de segundo salto, como un recurso compartido de archivos.

Específicamente, la sección del artículo perteneciente a la Entrada del Registro / Configuración de la política de grupo AllowFreshCredentialsWhenNTLMOnly resolvió el problema que estaba teniendo. Del artículo:

Si ni la autenticación Kerberos ni las huellas digitales del certificado están disponibles, el usuario puede habilitar la autenticación NTLM. Si se utiliza la autenticación NTLM, la política Permitir credenciales nuevas con autenticación de servidor solo NTLM (AllowFreshCredentialsWhenNTLMOnly) debe estar habilitada, y se debe agregar un SPN con el prefijo WSMAN a la política. Esta configuración es menos segura que la autenticación Kerberos y las huellas digitales de los certificados, ya que las credenciales se envían a un servidor no autenticado.

Para obtener más información acerca de la política AllowFreshCredentialsWhenNTLMOnly, consulte la descripción de la política proporcionada por el editor de la Política de grupo y KB 951608. La política AllowFreshCredentialsWhenNTLMOnly se encuentra en la siguiente ruta: Configuración del equipo \ Plantillas administrativas \ Sistema \ Delegación de credenciales.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.