Get-Credential cmdlet to prompt for a username and password, and passing that secure string object directly to the -Credential parameter of Start-Process. This approach ensures your script does not hardcode sensitive information while allowing you to execute applications under a specific identity.
The Get-Credential Cmdlet
The foundation of handling credentials in PowerShell is the Get-Credential cmdlet. When executed, it opens a standard Windows dialog box requesting a username and password. The username is optional; if left blank, it defaults to the current user context or allows you to specify a domain account. Crucially, this cmdlet returns a PSCredential object, which stores the password as a SecureString. This encryption at rest prevents the plaintext password from appearing in memory dumps or process lists.
To assign the result to a variable for later use, simply store the output:
$cred = Get-CredentialUpon running this line, the console pauses and displays the credential prompt. Once the user enters their details and clicks OK, the variable $cred holds the authenticated identity. You can verify the type of object returned by piping it to Get-Member, confirming it is indeed a PSCredential instance ready for authentication tasks.
Using Start-Process with Credentials
Once you have a valid PSCredential object, you can leverage it within the Start-Process cmdlet. This is particularly useful when you need to launch an application that requires higher privileges than the currently logged-in user possesses, or when connecting to remote resources using specific network credentials.
The syntax involves adding the -Credential parameter followed by your variable:
Start-Process -FilePath "notepad.exe" -Credential $credThis command attempts to launch Notepad using the identity provided in $cred. If successful, the application runs under that user context. It is important to note that not all processes support elevation via this method depending on the operating system version and security policies. For example, some system-level services may require interactive desktop access that is restricted in non-interactive sessions.
Troubleshooting Missing Pop-ups
A common issue arises when scripts run in automated environments, such as Task Scheduler or background jobs, where the graphical user interface (GUI) is not accessible. In these scenarios, the standard credential pop-up may fail to appear, causing the script to hang indefinitely or throw an error because it cannot interact with the desktop session.
If you are running your script via Task Scheduler, ensure that the task is configured to run whether the user is logged on or not, but be aware that UI prompts are generally suppressed in this mode. To resolve this, you might need to pre-seed the credentials or use alternative authentication methods that do not rely on GUI interaction. For more details on scheduling scripts effectively, see our guide on Powershell Script Not Running in Task Scheduler: A Troubleshooting Guide.
In interactive sessions, if the pop-up does not appear, check if another window is stealing focus or if the host environment restricts modal dialogs. Sometimes, running PowerShell in a separate console window rather than an integrated terminal within an IDE can help restore the expected behavior.
Security Best Practices
While Get-Credential is convenient, hardcoding credentials in scripts is a severe security risk. Always use dynamic retrieval methods. Additionally, consider the scope of the SecureString. By default, it is encrypted using the current user's DPAPI keys, meaning only that specific user on that specific machine can decrypt it. This adds a layer of protection against unauthorized access if the script file is stolen.
For advanced scenarios involving multiple machines or cross-user decryption, you may need to export and import the secure string with a key, though this introduces complexity. Always validate that the target process accepts the provided credentials. Some legacy applications may not handle modern authentication protocols correctly, leading to silent failures.
Alternative Authentication Methods
If GUI-based prompting is not feasible due to automation constraints, consider using stored credentials or certificate-based authentication. Tools like Windows Credential Manager can store passwords securely, allowing scripts to retrieve them without user interaction. Alternatively, for service-to-service communication, managed identities or certificates offer robust alternatives that bypass password management entirely.
Another option is to use the New-Object System.Management.Automation.PSCredential constructor if you already have the secure string in memory, though this still requires obtaining the secure string through a safe initial input mechanism. Never pass plaintext passwords to constructors.
Frequently Asked Questions
Can I use Get-Credential in a scheduled task?
No, standard GUI pop-ups do not appear in non-interactive scheduled tasks. You must pre-configure the credentials or use a method that does not require user input, such as reading from a protected file or using Kerberos delegation.
What happens if I enter the wrong password?
The Start-Process command will fail, typically returning an error indicating access was denied. The process will not start, and no exception is thrown unless you wrap the call in a try-catch block to handle the failure gracefully.
Is SecureString really secure?
It protects against casual viewing in memory or logs, but it is tied to the user account and machine. Any user with admin rights on that machine can potentially decrypt it. It is not suitable for protecting data across different systems without additional key management.
How do I clear the credential variable after use?
You should explicitly remove the variable using Remove-Variable cred or set it to $null. While PowerShell eventually garbage collects it, explicit removal reduces the time the secure string remains in memory, minimizing exposure risks.
Can I pass credentials to Invoke-WebRequest?
Yes, many cmdlets accept a -Credential parameter. However, Invoke-WebRequest often requires basic authentication setup or NTLM/Kerberos headers. Ensure the target server supports the authentication scheme you are attempting to use with the provided credentials.