Remoting double hop within an endpoint

by oogabooga at 2012-10-18 09:13:42

If you want to remote into a server and then remote into yet another server with different credentials, this works fine, even within a configured endpoint.

The problem I have is that if I give someone access to an endpoint that isn’t an administrator on the machine, they can’t then remote into another server with the same alternate credentials to server 2.

To be clear…the only difference between these accounts, is that one is an admin on the endpoint server, and the other person isn’t.

etsn www03 -Credential $cdctest -ConfigurationName HelpDesk -Authentication credssp

[www03]: PS C:\Users\cdctest\Documents> invoke-command www01 { ls c:\ } -credential $cred
Invoke-Command : An internal error occurred.
At line:1 char:15
+ invoke-command <<<< www01 { ls c:\ } -credential $cred
+ CategoryInfo : InvalidOperation: (:slight_smile: [Invoke-Command], PSInvalidOperationException
+ FullyQualifiedErrorId : InvalidOperation,Microsoft.PowerShell.Commands.InvokeCommandCommand

Does anybody know what permissions I need to give the group / user that I configure in the endpoint in order to do remoting on another server? I want to use minimum permissions…if I give them admin on the endpoint server, that kind of defeats the purpose.

You can easily duplicate this by following these steps:

Server 1 - Configure endpoint and give permissions to testuser (don’t make him and admin on the server)
Register-PSSessionConfiguration -Name HelpDesk -StartupScript C:\scripts\HelpDesk.ps1 -Force
Set-PSSessionConfiguration -Name HelpDesk -ShowSecurityDescriptorUI -Force

Server 2 - Create a user named ‘testuser2’ in the domain and give him admin to this server

etsn server1 -cred $testuser -auth credssp -configurationname helpdesk
$password = "2012" | ConvertTo-SecureString -AsPlainText -Force
$User = "DOMAIN\testuser2"
$cred = New-Object system.Management.Automation.PSCredential($User,$password)
icm server2 -cred $cred { ls c:\ }

That will fail. Now give testuser admin on server1 and try again and it will pass. I want it to pass without giving admin.

Thanks in advance guys.
by DonJ at 2012-10-19 09:54:16
I’m gonna try and test this when I’m back home next week… get back to ya ASAP.

In the interim, could you spell this out with just a bit more detail? Specifically, come up with machine names (TestUser2 is starting on CLIENT1, remoting to SERVER1, and failing to remote to SERVER2) just so I know I’m testing the same thing you’re trying?
by oogabooga at 2012-10-19 10:40:37
Sure, no problem Don. Love your new book btw. Working my way through the toolmaking MEAP.

HELPDESKDUDE is starting on CLIENT1. His goal is to run a script on PROBLEMSERVER. (The script requires administrative privileges, so I want to leverage an endpoint to proxy him through using alternate credentials.)

Some awesome admin guy (that’s me) decided to leverage endpoints, and sets one up on server ENDPOINT1. A service account named SVCADMIN is setup and given admin privileges to PROBLEMSERVER The script isn’t important…just set the endpoint script to do this:
Invoke-Command -Computername PROBLEMSERVER -Cred $svcadmin { ls c:\ }

The script that I give HELPDESKDUDE to run is named Fix-ProblemServer.ps1 and the contents look like this:
Invoke-Command -Computername ENDPOINT1 -Cred $helpdeskdudecred -auth credssp

When he runs this script he gets the error above. If I give him admin on ENDPOINT1, it works like a charm. I don’t want to give him admin on ENDPOINT1 though, because I want to hide my code which includes the password for SVCADMIN along with all the other endpoints I plan to setup for delegation.

I’m going to try answering some questions that might be rolling around in your head.

Why not just set the endpoint up on PROBLEMSERVER?
A couple of reasons. First, it’s a filthy 2003 server and I avoid adding any configuration to these whenever possible. Also, I’d like to keep all of my endpoints centralized as this solution grows.

Why not just use WMI?
I could actually accomplish this specific goal using WMI for the endpoint script, and I’ve tested it and it works great. What about other problems that require remoting though? What if I wanted to give someone access to restart an app pool? Ok, bad example because that can be done via WMI also. What about registering a DLL or running a Sharepoint commandlet, or anything else. You’d know better than me, but sometimes you just want to delegate functions that require administrative permissions on a server and Remoting would be a great vehicle. The person that you want to delegate to shouldn’t need to be an expert either. I just want to give them a script or create a GUI for them or whatever that calls functions on an endpoint, that may or may not need to remote into another computer.

Isn’t this dangerous from a security perspective?
As long as you do it right, I don’t think it is. It’s really not that much different than sudo and jailing for Linux. I’m logging everything to a Splunk server, so we know who’s running what functions, and if it improves problem response time and customer satisfaction then the trade-off should be worth it.

Have you tried using Server 2012 because the endpoint solution has changed?
I haven’t tried it yet because the company I’m at hasn’t approved 2012 to go into production. I plan on playing with it to see if it works, and will definitely move that direction as soon as it gets approved.

Thanks again for your help. Let me know if you have any questions.
by Aleksandar at 2012-10-19 18:34:53
You can’t use Server 2012, but can you install PowerShell 3.0 on ENDPOINT1 server?
by oogabooga at 2012-10-20 07:36:46
That’s a great idea Aleksandar.

Just tested and it works great. gpduck is sitting next to me trying to figure out why v2 doesn’t work, but I don’t really care. :stuck_out_tongue:

I’ll install WMF 3.0 first thing Monday morning.

Thank you very much!!