Can MSBuild deploy using integrated authentication or only basic?

Question

I'm deploying a web app package from the MSBuild command line to MSDepSvc on IIS6 which is working fine with the following command using basic authentication:

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=***

However, what I'd really like to do is drop the username and password parameters and fall back to integrated auth under the identity of the current user. This command is going into a build server and I'd prefer not to have the plain text credentials of an account with admin rights on the target environment (required for MsDepSvc) visible. I can't locate any documentation on how to do this and dropping off the credentials returns 401 unauthorised when I attempt to publish.

What makes it particularly frustrating is that I can happily run the deploy command in the package with integrated auth (just don't include credentials), I just can't seem to run it from the MSBuild command line. I'm trying to encapsulate the package and deploy processes into a single command without editing build files and this is the only thing in the way at present.

Any ideas out there?

Edit After some discussions with Sayed and looking a bit deeper into the command line output, after executing the MSBuild command above (without username and password parameters), the following MSDeploy command is being invoked:

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

You can see the UserName attribute is being set and the value is the username of the current logged on user. If I take this out and run the above command directly, the deployment goes through just fine.

So on that basis, why is the original MSBuild command inserting a UserName attribute when it calls MSDeploy? This appears to be the only barrier now.

England

If you set UseMSDeployExe to true does the command not include AuthType=NTLM??? – Girvin

Actually, I get challenged when publishing from Visual Studio to another machine on the same domain. After entering the credentials I'm already logged on with, the publish goes through fine and the underlying MSBuild command DOES show AuthType='NTLM', but also includes my credentials. So I'm kind of back at the original command! – England

For Visual Studio 2012, you need to omit the /P:UserName property entirely. – Ced

Answer 1

And the answer is...

Following my edit above about the current identity's username persisting to the MSDeploy command even when not passed in the original MSBuild call, I tried reconstructing the parameters to pass an empty username as follows:

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=

Which then generates the following MSDeploy command:

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

This call no longer includes the UserName attribute. So in short, if you do not add a username parameter to the MSBuild call it will insert the current identity anyway and defer to basic auth which will fail because there's no password. If you include the username parameter but don't give it a value, it doesn't include it at all in the MSDeploy command.

England

Is there any way to get the Publish Web GUI dialog to do this? It seems adamant on prompting for credentials before even generating the msdeploy.exe command so it always sets AuthType to Basic. – Scruggs

There's a very easy way to solve that Yadyn - just hit "Enter" without typing any credentials when you get challenged. Easy :) – England

Hm, tried that, and when using UseMsDeployExe=true I can see that it is definitely leaving off the username/password parameters (finally!) but it's still setting AuthType to Basic. This is when using a WMSvc address (MsDeploy.axd)... Also, I gotta say clicking OK without entering anything is not intuitive at all. – Scruggs

This was part of the solution for us (on TFS2013,) we also had to modify the registry as described here – Hunkers

Answer 2

I looked in the Microsoft.Web.Publishing.targets and saw this:

<PropertyGroup>
  <NormalizePublishSettings ...>
  <AuthType Condition="'$(AuthType)'==''" >Basic</AuthType>
  <!--Supported value for $(MSDeployPublishMethod): WMSVC, RemoteAgent, InProc-->
  <MSDeployPublishMethod ... >WMSVC</MSDeployPublishMethod>
  ...
</PropertyGroup>

So, it looks like the default is Basic authentication when running from MSBuild. Then I found this http://technet.microsoft.com/de-de/library/dd569001(WS.10).aspx

authenticationType specifies the type of authentication to be used. The possible values are NTLM and Basic. If the wmsvc provider setting is specified, the default authentication type is Basic; otherwise, the default authentication type is NTLM.

I haven't tried it yet, but maybe it's something like /p:AuthType=NTLM

Autarch

Good find, but what it explains is not consistent with what I'm observing. The way I read that statement is that deploying against MsDepSvc (i.e. not WMSvc), NTLM should occur by default. I've tried the AuthType switch with NTLM just to be sure, but no luck. – England

I was thinking the build target was overriding the default behavior of MSDeploy by specifying it's own default for AuthType. It was just a guess. – Autarch

Answer 3

I was able to get NTLM working as follows where the service is running under an account with admin privs on [server name].

"C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe" app\Test.Web\Test.Web.csproj /T:Clean /T:Package /P:Configuration=Release

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

which generates:

"C:\Program Files\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://[server name]/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

Reluctant

Answer 4

This worked, I initially was distracted by the targets file but realised my error was in the connection string, i.e. was trying to use https instead of http.

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

Tip

Answer 5

Breaking the process into 2 steps worked for me -

1. Build & Package

   msbuild.exe /p:DeployOnBuild=True /p:WebPublishMethod=Package /p:PackageAsASingleFile=true /p:AllowUntrustedCertificate=True /p:CreatePackageOnPublish=True /p:SkipExtraFilesOnServer=True /p:PublishProfile=DevProfile /p:Configuration=dev

2. Deploy

   msdeploy.exe -source:package='C:\packagelocation\dev.zip' -dest:auto,ComputerName='http://destinationserver/MsDeployAgentService',IncludeAcls='False',AuthType='NTLM' -verb:sync -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -retryAttempts=2

Supplant

Do you know why DeployOnBuild must be True in Step#1 if we are deploying in Step#2? – Gillum