Use PowerShell to Pass Credentials to Legacy Systems

Use PowerShell to Pass Credentials to Legacy Systems

  • Comments 5
  • Likes

Summary: Microsoft Windows PowerShell MVP, Sean Kearney, teaches how to use passwords in a script and talk to legacy systems.

Microsoft Scripting Guy, Ed Wilson, here. This week we will have one guest blogger for the entire week. Sean Kearney has written a series of blog posts about Windows PowerShell and the Legacy. I am not going to be redundant by reposting his biography each and every day.

Take it away, Sean.

First off—this is NOT a good idea…

Leaving clear passwords in a script of any kind is about as bad as an idea can be. Except for maybe writing your PIN number on your bank machine card, or writing your network password on a piece of paper and taping it to your monitor…you get the idea.

This having been said, there are situations where it happens, especially when you need to manage legacy setups. In fact, this is a very common question that I receive when I talk to users.

Many old VBScript scripts and console application .bat files or CDMs will already be doing this. You may have to pass these to a Windows PowerShell script—or the other way around—you may be running a Windows PowerShell script and need to pass the credentials down to the legacy application.

Here’s example one. You’ve got a Windows PowerShell script that gets credentials as per normal:

$MyCredentials=GET-CREDENTIAL –credential CONTOSO\UberSecretUserName

And of course, as normal, you will see Windows PowerShell pop up the old familiar box shown here.

Image of credential request

You would key in the password as normal, which gives you a nice variable to pass into various cmdlets that require secure credentials.

Now here is a thought…

Let’s pretend that you need to pass those same credentials to a legacy VBScript script or CDM (or something else from the console world). Can you get the password out of this? Normally, you would type the variable on the screen and get output similar to the following.

PS C:\> $MyCredentials | format-list


UserName : CONTOSO\UberSecretUserName
Password : System.Security.SecureString

But the System.Security.SecureString is absolutely useless as a password to a legacy system.

I was playing about, and I ran Get-Member on the value and found that there is a method available called GetNetworkCredential. Running this method against $MyCredentials will reveal the Username, Password, and Domain as three separate, clear text values:

Username

: UberSecretUserName

Password

: MySecretPasswordYouShouldNotSee

SecurePassword

: System.Security.SecureString

Domain

: CONTOSO

With this method, I can pull out the username and password like so:

$MyCredentials.GetNetworkCredential().Username
$MyCredentials.GetNetworkCredential().Password
$MyCredentials.GetNetworkCredential().DOMAIN

With this in clear text, we could pass it directly back to a legacy application.

But now the flipside. Let’s pretend we have a legacy application that is already passing user IDs and passwords. You need to call a cmdlet in Windows PowerShell from a legacy setup. But it requires the output of Get-Credential. What to do?

This is not an issue. If you ran Get-Member against the $MyCredentials variable, you would see the class that it’s associated with in .NET as shown in the following image.

Image of command output

If you go to msdn.microsoft.com, you’ll see that to make this, you have to re-create the object by specifying the class and the values it needs.

$MyDomain=’CONTOSO’
$MyClearTextUsername=’SecretAgentMan’
$MyClearTextPassword=’OhNoTheWholeWorldCanSeeMyPassword’

$MyUsernameDomain=$MyDomain+’\’+$MyClearTextUsername

$SecurePassword=Converto-SecureString –String $MyClearTextPassword –AsPlainText –force

$CredentialsMadeFromClearText=New-object System.Management.Automation $MyUsernameDomain $SecurePassword

Now you can build that needed secure credential in Windows PowerShell from the legacy environment.  

There are far more secure ways to get this done. But the important point is knowing how to get the two worlds to happily coexist.

The Power of Shell is in you.

Guest blogger week will continue tomorrow when Sean will continue to talk about Windows PowerShell and the Legacy. A special thank you to Sean for writing this week’s blog posts. Hope you enjoy them.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • What do you expect this line to do?

    $CredentialsMadeFromClearText=New-object <b>System.Management.Automation</b> $MyUsernameDomain

  • I think this is what was intended:

    $CredentialsMadeFromClearText=New-object System.Management.Automation.PsCredential( $MyUsernameDomain, $SecurePassword)

    $CredentialsMadeFromClearText|fl

  • JV

    You are absolutely correct.  Thanks for catching that.  I goofed about when I was playing with this and for some reason that line got copied from my Console instead of the correct one.   Nice job on catching it.

    I sense the Power of Shell is STRONG in this one!

  • Sean - good demo.

    I munge things up all of the time if I don't take time to test, test, test.

    It might be worth noting that these secure strings are only valid for the current user account and cannot be transferred. Also anyone with access to the users account can decrypt the string back to plain text at any time so be careful.

  • JV

    The encrypted data is not transferrable between sessions but yes, as you could tell a clear text password would be readable.  However in many legacy environments that are passing credentials it's going to be clear text.   But of course those accounts and those scripts should also be kept on restricted locations, the accounts should have restricted rights including which systems they can access.

    As I said, Clear text, bad idea.  *BAD* idea but if you're working with an older system that is already doing this, it's good to know you don't have to tear apart what you have in the short term.

    Keep watching the rest of this week for more Legacy and Powershell goodness :)

    Cheers!

    Sean

    "The Energized Tech"

    @energizedtech