header
header Register : : Login header
header
divider
menuleft
menuright
submenu
left
Oct 19

Written by: Joe Brinkman
Friday, October 19, 2007 9:12 AM

As part of getting ready for my PowerShell session at OpenForce '07, I am creating a set of helper functions for working with SMO to manipulate and query the database server.  A common need when working with the database is to pass the username and password to various SMO methods.  When I first started coding my examples, I just passed a username and password as parameters into my functions.  This works, but does not exactly look professional when you are sitting in a presentation and typing out passwords in plaintext.

I decided that it would be better to use Get-Credential in this case since it would provide a professional dialog and keep the password hidden throughout the process.  Since I wanted to support both scenarios, I came up with the below function. 

function global:get-sqluser($username="", $password="") {
# We are creating an object to which we'll add custom properties
$user = New-Object Management.Automation.PSObject
 
if ($username -eq "") {
# No username was specified, so we should use Get-Credential to prompt for a user
# We also define a default username in order to suppress console output
# The results are added as synthetic properties to the PSObject we created above
$cred = Get-Credential "SqlUser"
$user.psobject.members.add( 
(New-Object System.Management.Automation.PsNoteProperty UserName, $cred.username.split("\")[1]) )
$user.psobject.members.add( 
(New-Object System.Management.Automation.PsNoteProperty Password, $Cred.Password) )
} Else {
# In this case we can just create synthetic properties using the values passed to the function
$user.psobject.members.add( 
(New-Object System.Management.Automation.PsNoteProperty UserName, $username) )
$user.psobject.members.add( 
(New-Object System.Management.Automation.PsNoteProperty Password, $password) )
}
 
# Return our synthetic object
$user
}

It is not perfect as the two cases return the password as either a cleartext string or a securestring.   Also, I don't like the hack with the Get-Credential since I don't really need a domain qualified name (notice the ugly split("\")[1] that is needed to get just the username without a domain qualifier).  My next version will resolve both of these issues, but for now this will have to suffice.

Tags:

Re: Getting a Username/Password in PowerShell

We can add member to object using the built-in add-member cmdlet:

$user | add-member -name UserName -value $cred.username.split("\")[1] -membertype NoteProperty
$user | add-member -name Password -value $cred.password -membertype NoteProperty

By aleksandar on   Tuesday, October 16, 2007 6:25 PM

Re: Getting a Username/Password in PowerShell

See my next blog entry for the reason why I don't use add-member in this case.

By jbrinkman on   Wednesday, October 17, 2007 7:47 AM

Re: Getting a Username/Password in PowerShell

Yeah, I was going to comment on the code formatting, but it seems you noticed and fixed it.

By marco.shaw on   Thursday, October 18, 2007 5:59 PM

Re: Getting a Username/Password in PowerShell

$cred.GetNetworkCredential().username will give you just the username without a domain qualifier.

By aleksandar on   Monday, November 05, 2007 11:48 AM

Re: Getting a Username/Password in PowerShell

@Alesandar - Thanks for the info. This really highlights the need for maintaining consistency across APIs. I am used to web APIs in .Net which decompose objects properties on the top level object without requiring further method calls. You live and you learn I guess.

By jbrinkman on   Monday, November 05, 2007 11:51 AM
 

[August 25th, 2008] Check the home page regarding PowerShell related news from a brand new sponsor: Idera

Blogs
  
Search Blogs
  
Archives
  
right
   
footer Sponsored by Quest Software • SAPIEN Technologies • ShellTools, LLC • Microsoft Windows Server 2008 footer
footer