Have you ever tried accessing a remote resource within a PowerShell Remoting session only to hit a frustrating access denied roadblock? This common issue, known as the “double-hop” problem, prevents you from accessing a second remote machine from your current session.
The good news? There are ways to solve the double-hop problem without overly complex configurations. In this tutorial, you’ll build a customized session that seamlessly handles authentication, saving you time and effort while maintaining security.
Overcome double-hops with session configurations and streamline your workflow!
Running PowerShell as a Different User
If you’re working with scripts that connect to remote resources, you might encounter the double-hop problem. This issue occurs when your credentials fail to authenticate beyond the first hop in a remote connection.
For example, consider a script that counts sub-directories on a remote computer using a UNC path:
(Get-ChildItem -Path \\SRV2\c$ -Directory).Count
If you’re logged in to a user that lacks permission to access a resource, you can run PowerShell under a different user account:
- Search for PowerShell in the Start menu.
- Right click the PowerShell shortcut and select Open file location.
- In File Explorer, hold Shift, right-click the shortcut, and select Run as different user.
- Enter the credentials of a user with the necessary permissions.
After starting PowerShell as a different user, the command should now succeed:
(Get-ChildItem -Path \\SRV2\c$ -Directory).Count
Tip: If you frequently run commands with different credentials, consider using the Start-Process cmdlet with the -Credential parameter. This approach allows you to open new PowerShell sessions directly from the console with alternate credentials.
Testing Remote Connections
You might successfully access a remote resource locally, like a shared folder, when working with multiple remote systems. But you then discovered that the same command produces an “access denied” error when executed (from a second remote computer).
This inconsistency can be confusing, especially when you’re confident that your credentials have sufficient permissions.
To test your remote connections, establish a session with another computer:
Enter-PSSession -ComputerName SRV3
Once connected, try running the same command on the second machine:
(Get-ChildItem -Path \\SRV2\c$ -Directory).Count
This test often results in an “access denied” error, even if you use an account with permissions.
Confirm your current user with the following:
whoami
This behavior (double-hop) happens because PowerShell doesn’t pass your credentials to the next hop. This mechanism is a security feature built into Kerberos authentication, but it can be a major headache when managing multiple systems.
Solving the Double-Hop Problem with Session Configurations
One solution to the double-hop problem is to create a session configuration on the intermediate machine.
Start by registering a session configuration on the computer you’re connecting to, in this case, SRV3.
The following command:
- Assigns a
Nameto the session configuration (e.g.,Admin). - Specifies the account (
RunAsCredential) sessions will run under. - Ensures (
Force) the configuration is applied and restarts the WinRM service.
Invoke-Command -ComputerName SRV3 -ScriptBlock {
Register-PSSessionConfiguration -Name Admin -RunAsCredential 'psforsysadmins.local\adam' -Force
}
PowerShell prompts you for the password for the RunAsCredential account, which is stored securely on the remote machine. Once the configuration is registered, the WinRM service restarts and the session is closed.
With the configuration in place, you can now connect using the ConfigurationName parameter:
Invoke-Command -ComputerName SRV3 -ScriptBlock {
(Get-ChildItem -Path \\SRV2\c$ -Directory).Count
} -ConfigurationName Admin
This command performs the same operation as before. However, it specifies the Admin session configuration, which runs under the specified admin account.
Tip: Limit access to the session configuration by defining user or group-specific access permissions using the Set-PSSessionConfiguration cmdlet. Doing so ensures that only authorized users can leverage the configuration.
Conclusion
In this guide, you’ve seen and resolved the double-hop problem in PowerShell Remoting. Setting up a session configuration can resolve the double-hop problem and ensure that credentials are passed securely.
This solution is persistent, so you can reuse the configuration even after reboots, making it a robust approach to managing remote PowerShell sessions. Now, you can manage multi-hop remote operations confidently and streamline workflows without compromising security.
From here, consider exploring advanced security options, such as restricting session access or implementing certificate-based authentication. These enhancements can further strengthen your remoting setup while managing complex environments flexibly.
