PowerShell Problem Solver: Creating Permanent Credentials
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.
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.
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.
Now I don’t have to think about adding the –Credential parameter; PowerShell does it for me automatically.
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.
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.
This works because the credential is stored in the PSDefaultParameterValues.
I can override the value by specifying a different one.
For the local WMI issue, I can try using a null value and press cancel when prompted.
That’s a bit clunky. You might find it easier to temporarily disable default values.
$PSDefaultParameterValues.disabled = $True
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.
In this profile, I’ll add this command:
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.
No passwords are ever written to disk. But now I have an automatic credential. If the PowerShell command can use it, it will.
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.