Two months ago, in “3 PowerShell Account Tweaks,” I mentioned the PowerShell get-credential command in passing, but I didn't really cover it. This month, I want to introduce it to you more fully, because I think you'll find it very useful, particularly if you administer more than one forest or if you often have to do a one-off admin job wherein you don't want to have to log off and back on to get that job done.
Sometimes you're logged on as a domain administrator—but not always. To address that, the Active Directory (AD) PowerShell cmdlets all support a -credential parameter. For example, if you're logged on as someone with no domain admin powers, and you run the command
that command would fail. Suppose, however, that you do have a domain user account named bigfirm\Kathleen, and you want PowerShell to use that account just for this command. You could then type
which would cause PowerShell to pop up a GUI logon dialog box with a username text field (pre-populated with bigfirm\Kathleen) and a password text field. Punch in the password, click OK, and the command would run without flaw. If you didn't want to specify the username in the command invocation, you could just type
In that case, the same dialog box would pop up—but with an empty username field. You might be wondering how you might put a username and password directly onto the command line, as in
Unfortunately, that's not possible. You can, however, save yourself some typing by getting that credential once, saving it, and re-using it. You can do that by running get-credential a bit differently.
First, run get-credential, but this time, capture its result in a PowerShell variable. Variables are spaces in memory that you can use to store data, and PowerShell identifies variables by their first letter: $ (the dollar sign). Variables can store just about any kind of data. For example, if you typed the lines
$myresult= $firstnum + $secondnum
into PowerShell and pressed Enter, you'd see a result of 13. Notice that you can give variables any name you want, as long as the first character in that name is $. The variables $firstnum, $secondnum, and $myresult didn’t exist before I typed them, and when I exit PowerShell, any variables I've worked with disappear. To save myself some typing, I could log on as bigfirm\mark and store that credential into a variable that I'll call $c with the command
I can then use the credential in a subsequent command, such as the set-aduser example, as in
Now, for the rest of the day, every time I need to run some AD command, I can just add -credential $c rather than punching in my password all the time. That's nice, but it gets better if your day requires you to run commands from different accounts, such as running some things under a local account and others under admin accounts from various domains. For example, suppose you need a credential for your local machine on an account named me on your computer, PC429; one from a domain account bigfirm\alex in one forest; and one from outsiders\wally in another forest. You could put these three commands in your PowerShell profile:
$c2 = get-credential bigfirm\alex
$c3 = get-credential outsiders\wally
Your system would prompt you for each of those passwords, and you could avoid typing passwords for the rest of the day.
Wondering what's in that credential? Essentially, it's just the name of the account that the credential is based on, as well as a pile of binary data of some type. Ask PowerShell to show you what's in $c by just typing
PowerShell will respond with the username and inform you that it includes a password, and that the password is a System.Security.SecureString, which sort of looks like a dead end. A little searching shows that PowerShell has a command called convertfrom-securestring. Typing
will dump a long string of hex, which clearly isn't your password—or is it? When you type
PowerShell will show you the password that you typed in.
In sum, then, you can use get-credential to create variables that will store your passwords and save you time when you’re running tasks that require different credentials. But be sure to lock your workstation when you walk away from it, or a bit of quick typing might just reveal your password!