Coming Soon: GET:IT Endpoint Management 1-Day Conference on September 28th at 9:30 AM ET Coming Soon: GET:IT Endpoint Management 1-Day Conference on September 28th at 9:30 AM ET
PowerShell

PowerShell Problem Solver: Creating Permanent Credentials

password-hero-img-aspect

If you run your IT operations the smart and safe way, you use a normal user credential for most of the day. When you need to do something in PowerShell that requires administrator credentials, then you can often specify an alternate credential.

get-wmiobject win32_service -filter "name = 'dns'" -computer chi-dc04 -Credential globomantics\administrator

I’m prompted for a password, and PowerShell uses the credential to connect, and I get a result. This gets tedious if I have to do that every time I want to use an alternate credential. One solution is to save the credential to a variable with Get-Credential.

$da = Get-Credential globomantics\administrator

Now I can use that instead.
get-wmiobject win32_service -filter "name = 'dns'" -computer chi-dc04 –Credential $da

I can use this variable with any command that can use a PSCredential.

Testing an alternate credential (Image Credit: Jeff Hicks)
Testing an alternate credential (Image Credit: Jeff Hicks)

Although I’m logged on as Jeff when I connect to CHI-FP02, I’m using the alternate credential. The only situation I can think of where this won’t work is when using Get-WMIObject and connecting to the localhost. WMI doesn’t support alternate credentials for local queries.

Sponsored Content

Say Goodbye to Traditional PC Lifecycle Management

Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.

That’s nice and all, but I still have to remember to use the credential. There’s a better way.

PowerShell 3.0 introduced PSDefaultParameterValues. There’s a help topic (about_Parameters_Default_Values) that you can take a look at for more details. But for now, I can tell PowerShell to use my credential variable forany cmdlet that has a credential parameter.

$PSDefaultParameterValues.Add("*:Credential",$da)

Now I don’t have to think about adding the –Credential parameter; PowerShell does it for me automatically.

Testing the PSDefault credential (Image Credit: Jeff Hicks)
Testing the PSDefault credential (Image Credit: Jeff Hicks)

Notice that I didn’t have to specify the alternate credential, but PowerShell used it anyway. Sometimes you can’t tell it is being used, but I can tell that it is because I get a WMI error.

WMI error using a credential locally (Image Credit: Jeff Hicks)
WMI error using a credential locally (Image Credit: Jeff Hicks)

Although I didn’t type it, PowerShell used –Credential. This behavior will last for as long as my PowerShell session is running even if I delete the credential variable.

Testing variable removal (Image Credit: Jeff Hicks)
Testing variable removal (Image Credit: Jeff Hicks)

This works because the credential is stored in the PSDefaultParameterValues.

The PSDefaultParameterValue setting (Image Credit: Jeff Hicks)
The PSDefaultParameterValue setting (Image Credit: Jeff Hicks)

I can override the value by specifying a different one.

Overriding the parameter default value (Image Credit: Jeff Hicks)
Overriding the parameter default value (Image Credit: Jeff Hicks)

For the local WMI issue, I can try using a null value and press cancel when prompted.

Using a null credential (Image Credit: Jeff Hicks)
Using a null credential (Image Credit: Jeff Hicks)

That’s a bit clunky. You might find it easier to temporarily disable default values.

$PSDefaultParameterValues.disabled = $True

Testing without the parameter default (Image Credit: Jeff Hicks)
Testing without the parameter default (Image Credit: Jeff Hicks)

When you are ready, you can re-enable it by setting Disabled to $False.

To make this truly permanent, you can add these steps to your PowerShell profile. You might even want to put it in your profile script that covers both the PowerShell console and the PowerShell ISE.

Profile for current user all hosts (Image Credit: Jeff Hicks)
Profile for current user all hosts (Image Credit: Jeff Hicks)

In this profile, I’ll add this command:

$PSDefaultParameterValues.Add("*:Credential",(Get-Credential globomantics\administrator))

I’m not even going to save the credential to a variable first. When I start a new PowerShell session, I’m prompted for the password.

Testing the profile (Image Credit: Jeff Hicks)
Testing the profile (Image Credit: Jeff Hicks)

No passwords are ever written to disk. But now I have an automatic credential. If the PowerShell command can use it, it will.

Testing the new default parameter credential (Image Credit: Jeff Hicks)
Testing the new default parameter credential (Image Credit: Jeff Hicks)

Now I can run all the PowerShell commands I need with the correct credential, and I don’t have to think about it. If you try this out, please share your experience in the article comments below.

Related Topics:

BECOME A PETRI MEMBER:

Don't have a login but want to join the conversation? Sign up for a Petri Account

Register
Comments (0)

Leave a Reply

Live Webinar: Active Directory Security: What Needs Immediate Priority!Live on Tuesday, October 12th at 1 PM ET

Attacks on Active Directory are at an all-time high. Companies that are not taking heed are being punished, both monetarily and with loss of production.

In this webinar, you will learn:

  • How to prioritize vulnerability management
  • What attackers are leveraging to breach organizations
  • Where Active Directory security needs immediate attention
  • Overall strategy to secure your environment and keep it secured

Sponsored by: