Permissions required to manipulate Windows Services remotely on another Workgroup-linked computer

Question

I know there are a lot of questions similar to this, but all of them use the following syntax to connect:

runas /netonly /user:[Domain]\[Account on Domain with Administrator access] 
[Program]

I need to start/stop services remotely from another Workgroup-linked computer. My problem is my computer is not linked via a domain structure which the syntax seems to imply. Using this opens the program (say cmd), but performing sc \\[Domain\Machine] query on the opened instance of cmd.exe does not work giving the Access Denied error.

Another alternative I've found elsewhere in StackOverflow is

net use \\[Machine IP/Host name]\IPC$ user:[Account on Machine with 
Administrator Access] [Password]
sc \\[Machine] [Command]

In the second case, the first line works if I input the account credentials properly provided the same account isn't used by anyone else in the remote machine...

But the second line fails giving the same access denied error as earlier. I am at my wit's end to solve this problem.

Funnily, the exact situation doesn't seem to be addressed at all elsewhere in the internet, and nobody's complained of requirement of credentials stopping them from using sc or net start e.g., remotely. Almost all questions on SO relate to the exact syntax.

The only problem I can identify is if my computer is connected in a Workgroup structure as opposed to the Domain. What is the real issue?

EDIT : An important point to note is that when I say sc \[Machine] start [Service] and I give the name of a non-existent service in the syntax, the error message is something like service does not exist as installed service, but if I enter the name of a valid service, the error is Access Denied..

EDIT 2 : It worked after completely disabling user access control. I assume that isn't the safest way to do it. Are there any alternatives with UAC enabled?

EDIT 3 : I figure it is to do with getting adminstrative priveliges on the remote machine using cmd. How can I achieve that within command line?

Solution

OK, I found the issue.. Apparently, at least in Windows 8, 8.1 and Windows Server 2008, UAC restricts administrative-privileges requiring changes to local admins by default.

The only reason I can imagine for this is that if a Workgroup connected remote machine's logged in user has identical credentials (ID and password) as that of the home computer, the remote user would be qualified to make changes on command line with administrative privileges despite it probably not being the intention of the guy controlling the home computer.

So this probably means, for security reasons, an additional filter has been introduced to restrict such activities to only the local admin.

It's given over here... https://serverfault.com/questions/111007/having-trouble-using-psservice-and-sc-exe-between-windows-server-2008-machines

i.e. setting

[HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\
LocalAccountTokenFilterPolicy] = 1

in the registry is likely to solve the issue after rebooting the computer. Seeing as this is such a common issue, at least amongst workgroup-linked computers, I've no clue why this solution isn't more easily reachable on the net.

Comments

[hrishi1990]

The problem is it just doesn't seem to connect... when doing sc query, the response is Access is Denied.... there's something fundamentally wrong in my procedure, it works lovely after disabling UAC, but without, it just doesn't.

[Glen]

So you should be accessing your the remote pc with an account that is an administrator. The administrator account should have lower UAC than a user/poweruser account. You only use this account when doing admin tasks.

[hrishi1990]

I've tried it all.... I've found the issue, it's something related to UAC for administrative access across the network. It seems, at least in Windows 8, 8.1, it restricts access to local administrator accounts by default. Even if the network has an administrator, he is denied access. How to get across it is mentioned here serverfault.com/questions/111007/…

[admax]

For Windows Server the fix works without restarting