¿MSBuild puede implementarse utilizando autenticación integrada o solo básica?

msdeploy (4)

Estoy implementando un paquete de aplicación web desde la línea de comandos de MSBuild a MSDepSvc en IIS6, que funciona bien con el siguiente comando usando autenticación básica:

MSBuild.exe Web.csproj /p:Configuration=Debug /p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:MsDeployServiceUrl=http://[server name]/MsDeployAgentService /p:DeployIisAppPath=DeploymentTestProject /p:MSDeployPublishMethod=RemoteAgent /p:CreatePackageOnPublish=True /p:username=*** /p:password=***

Sin embargo, lo que realmente me gustaría hacer es soltar los parámetros de nombre de usuario y contraseña y volver a la autenticación integrada bajo la identidad del usuario actual. Este comando va a un servidor de compilación y prefiero no ver las credenciales de texto sin formato de una cuenta con derechos de administrador en el entorno de destino (requerido para MsDepSvc). No puedo encontrar ninguna documentación sobre cómo hacer esto y dejar las credenciales devuelve 401 no autorizado cuando intento publicar.

Lo que lo hace particularmente frustrante es que puedo ejecutar felizmente el comando deploy en el paquete con autenticación integrada (simplemente no incluyo las credenciales), parece que no puedo ejecutarlo desde la línea de comandos de MSBuild. Estoy tratando de encapsular el paquete e implementar procesos en un solo comando sin editar archivos de compilación, y esto es lo único que queda por el momento.

¿Alguna idea por ahí?

Editar Después de algunas conversaciones con Sayed y profundizar un poco más en la salida de la línea de comandos, después de ejecutar el comando MSBuild anterior (sin los parámetros de nombre de usuario y contraseña), se invoca el siguiente comando de MSDeploy:

msdeploy.exe -source:package=''[project path]/Web/obj/Debug/Package/Web.zip'' -dest:auto,ComputerName=''http://[server]/MsDeployAgentService'',UserName=''***'',IncludeAcls=''False'',AuthType=''NTLM'' -verb:sync -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -retryAttempts=2

Puede ver que el atributo UserName se está configurando y el valor es el nombre de usuario del usuario que inició sesión actualmente. Si tomo esto y ejecuto el comando de arriba directamente, la implementación pasa muy bien.

Entonces, sobre esa base, ¿por qué el comando MSBuild original inserta un atributo UserName cuando llama a MSDeploy? Esta parece ser la única barrera ahora.

Busqué en Microsoft.Web.Publishing.targets y vi esto:

<PropertyGroup> <NormalizePublishSettings ...> <AuthType Condition="''$(AuthType)''==''''" >Basic</AuthType>  <MSDeployPublishMethod ... >WMSVC</MSDeployPublishMethod> ... </PropertyGroup>

Por lo tanto, parece que el valor predeterminado es la autenticación Basic cuando se ejecuta desde MSBuild. Luego encontré esto http://technet.microsoft.com/de-de/library/dd569001(WS.10).aspx

authenticationType especifica el tipo de autenticación que se utilizará. Los valores posibles son NTLM y Básico. Si se especifica la configuración del proveedor wmsvc, el tipo de autenticación predeterminado es Básico; de lo contrario, el tipo de autenticación predeterminado es NTLM.

Todavía no lo he probado, pero tal vez sea algo como /p:AuthType=NTLM

Esto funcionó, inicialmente me distrajo el archivo de objetivos pero me di cuenta de que mi error estaba en la cadena de conexión, es decir, estaba tratando de usar https en lugar de http.

MSBuild.exe Web.csproj / p: Configuración = Depurar / p: DeployOnBuild = True / p: DeployTarget = MSDeployPublish / p: MsDeployServiceUrl = http: // [serverName] / MsDeployAgentService / p: DeployIisAppPath = DeploymentTestProject / p: MSDeployPublishMethod = RemoteAgent / p: CreatePackageOnPublish = True / p: username =

Logré que NTLM funcionara de la siguiente manera donde el servicio se ejecuta bajo una cuenta con privilegios de administrador en [nombre del servidor].

Aplicación "C: / Windows / Microsoft.NET / Framework / v4.0.30319 / msbuild.exe" / Test.Web / Test.Web.csproj / T: Limpiar / T: Paquete / P: Configuración = Versión

C: / hudson / jobs / Test / workspace / app / Test.Web / obj / Release / Package / Test.Web.deploy.cmd / Y "/ M: http: // [nombre del servidor] / MSDEPLOYAGENTSERVICE" / A: ntlm -allowUntrusted

que genera:

"C: / Archivos de programa / IIS / Microsoft Web Deploy / msdeploy.exe" -source: package = ''C: / hudson / jobs / Test / workspace / app / Test.Web / obj / Release / Package / Test.Web. zip ''-dest: auto, computerName ='' http: // [nombre del servidor] / MSDEPLOYAGENTSERVICE '', authtype ='' ntlm '', includeAcls ='' False ''-verb: sync -disableLink: AppPoolExtension -disableLink: ContentExtension -disableLink: CertificateExtension - setParamFile: "C: / hudson / jobs / Test / workspace / app / Test.Web / obj / Release / Package / RapidPrototypeRequestSystem.Web.SetParameters.xml" -allowUntrusted

Y la respuesta es...

Después de mi edición anterior sobre el nombre de usuario de la identidad actual que persiste en el comando MSDeploy incluso cuando no se aprobó en la llamada MSBuild original, traté de reconstruir los parámetros para pasar un nombre de usuario vacío de la siguiente manera:

Que luego genera el siguiente comando MSDeploy:

msdeploy.exe -source:package=''[project path]/obj/Debug/Package/Web.zip'' -dest:auto,ComputerName=''http://[server name]/MsDeployAgentService'',IncludeAcls=''False'',AuthType=''NTLM'' -verb:sync -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -retryAttempts=2

Esta llamada ya no incluye el atributo UserName. En resumen, si no agrega un parámetro de nombre de usuario a la llamada MSBuild, insertará la identidad actual de todos modos y diferirá a la autenticación básica, que fallará porque no hay contraseña. Si incluye el parámetro de nombre de usuario pero no le da un valor, no lo incluye en absoluto en el comando MSDeploy.