Powershell: Start-BitsTransfer & User Authentication

I recently discussed an issue with ActualReverend (alright it was a month and a half ago and I'm just now blogging about it) concerning Powershell and using Start-BitsTransfer against a web server requiring user authentication. Additionally, this is my first time ever using Powershell for any task more than running 'ipconfig /all'. So I suppose we'll start with our problem statement:

"Using 'Start-BitsTransfer', download a file from a web server (an apache/svn service), which requires user authentication against an LDAP server, to a given location. Path is '/path/file.ps1' user credentials are 'username:password.' "

Should be a fairly simple script, he needed it for more but I am mostly interested with why it's not working as expected.

$creds = Get-Credential

Start-Bitstransfer -Source https://ourmixbreedserver.domain.com/path/file.ps1 -Destination C:\destination\ -Credential $creds -Authentication basic

Pretty straight forward script. It prompts the user for their credentials we enter "username" and "password" as that's our credentials. The authentication type is basic, and the server is properly configured to goto LDAP, so we're ready to Rock 'N Roll... But the results are of course not as expected, let's see the error.

Start-BitsTransfer : HTTP status 401: The requested resource requires user authentication.

Well, damn. We thought that providing the username and password pair would cover us but something went wrong and the error is not as forthcoming with the cause as we'd like. We provided credentials and the fact that we wanted the cmdlet to use authentication, so what the hell? Maybe our server logs will provide some insight.

[Thu Aug 19 13:30:50 2010] [error] [client 10.1.1.2] user \\username not found: /path/file.ps1 

 Ah ha, so our user isn't found. Thats weird though why is there a '\\' preceding our username, we didn't enter that! Lets inspect our object $creds and see if it supports this outrageous server log claim (hopefully identify the source of the hiccup).

PS C:\Users\username>$creds 

UserName              Password

--------              --------

\username             System.Security.SecureString

PS C:\Users\username>

Huh so, there is our issue. Our LDAP server certainly has no idea who '\username' is. So our Username property in our... wait what type of object is this? Running $creds.GetType() shows us its a 'PSCredential' type. The MSDN shows us this is in the 'System.Management.Automation' namespace. So in theory I can use the New-Object cmdlet to make a new object with the contents of the old object and clean it up, right? Right!

PS C:\Users\username> $creds = New-Object -TypeName 'System.Management.Automation.PSCredential' -ArgumentList $creds.Username.Remove(0,1),$creds.Password

Alright,  lets check out our object now...

PS C:\Users\username>$creds 

UserName              Password

--------              --------

username             System.Security.SecureString

PS C:\Users\username>

Very cool, so lets try it out (cross our fingers):

PS C:\Users\username> Start-BitsTransfer -Credential $creds -Source "https://ourmixbreedserver.domain.com/path/file.ps1" -Destination C:\destination\ -Authentication basic

PS C:\Users\username> 

Voilà, we're now providing our user credentials successfully and downloading the file we want without error! Powershell, you have just made my Windows using experience that much better.