Queremos utilizar la administración de versiones de TFS para nuestras implementaciones. Disponemos de varios entornos (dev, qa, staging, prod). Cada uno de ellos en un bosque AD separado. La máquina de construcción también reside en un bosque separado. No hay confianza entre ellos.

Configuré las máquinas de destino para que acepten autenticaciones CredSSP para la comunicación remota de PS. Pude ingresar a la sesión de PS en la máquina de destino desde la máquina de compilación. Pero no hubo suerte con la tarea de TFS 'Powershell en Target Machines'.

Aquí cómo se ven mis tareas en TFS: tarea TFS PS en máquinas de destino

En los registros: 2016-12-30T15: 04: 11.0279893Z System.Management.Automation.Remoting.PSRemotingTransportException: La conexión con el servidor remoto app.dev.local falló con el siguiente mensaje de error: WinRM no puede procesar la solicitud. Se produjo el siguiente error con el código de error 0x80090322 al utilizar la autenticación de negociación: Se produjo un error de seguridad desconocido.

¿Hay alguna forma de hacer que TFS ejecute PS en las máquinas de destino que residen fuera del dominio de AD de la máquina de compilación?

La confianza en AD no parece una opción. Y sin el control remoto adecuado de PS, no parece que la gestión de versiones pueda proporcionarnos mucho valor.

0
Sergey Tunnik 3 ene. 2017 a las 13:13

1 respuesta

La mejor respuesta

TL; DR;

No, tienes dos opciones.

  1. Configure una confianza unidireccional entre su dominio principal y todos sus subdominios para que sus credenciales de dominio de producción se puedan usar en todos sus subdominios.
  2. use cuentas ocultas para permitir la autenticación entre dominios. Estas son cuentas locales con el mismo nombre de usuario y contraseña en todas las máquinas que permiten la autenticación. Esta es la solución oficial de MSFT para la autenticación de dominios que no son de confianza.

La respuesta larga

Aparte de eso, dado que se encuentra fuera del camino feliz admitido, deberá implementar sus propias tareas personalizadas que faciliten la autenticación de dominio cruzado que desea. Implementar sus propias tareas en PowerShell debería ser una tarea bastante simple.

https://www.visualstudio.com/en-us/docs/integrate/extensions/develop/add-build-task

La realidad es que solo hay unos pocos escenarios limitados en los que necesita un entorno de "prueba de AD" y nunca es correcto tener dominios para Dev, QA o Staging. AD no está diseñado de esa manera y nunca lo he visto funcionar en beneficio de la organización o los esfuerzos de desarrollo. Es un producto de administradores de sistemas paranoicos y es una causa perdida.

La única razón para tener un dominio adicional permanente es que sus administradores de sistemas prueben sus cambios y configuraciones de dominio.

Para proyectos de desarrollo de software que cambian activamente AD, o requieren configuraciones específicas para las pruebas, crearía dinámicamente su dominio de prueba junto con las máquinas de prueba requeridas. Así es como crea pruebas válidas y repetibles contra un dominio.

2
Community 20 jun. 2020 a las 12:12
Gracias por explicar la respuesta. Pero incluso si solo tenemos un AD para dev \ qa \ staging, todavía tendremos diferentes AD aislados para prod y dev.
 – 
Sergey Tunnik
3 ene. 2017 a las 15:35
1
Me confundes. Debe tener un dominio de producción que contenga todos sus entornos y servidores.
 – 
MrHinsh - Martin Hinshelwood
3 ene. 2017 a las 15:38