5

The question is about the shutdown command with /m \\MACHINE switch, which can be used to shut down (reboot, sleep etc.) a Windows machine remotely. In my case I'm dealing with a local home network between Windows 7 and Windows 8 machines. Homegroup is disabled on all machines and networking is managed the "traditional" way by creating user accounts with passwords on all machines.

I read somewhere that in order to execute that command remotely the issuing account should also be registered on the remote recipient machine as a member of Administrators group. To test this behavior of shutdown command I set up two user accounts named Test and Mike on the local (issuing) Windows 7 Pro machine. Both accounts belonged to regular Users group.

I also went to the remote (recipient) Windows 8 Pro machine called FILES and created just one account there named Mike as a member of Users group.

Now, I logged in as Test into my local machine and issued a

shutdown /m \\FILES /r /f /t 0

command from the command prompt. I immediately received an "Access denied" response. This was expected behavior. So far so good.

Then I logged in as Mike into my local machine and issued the same command. To my surprise, the remote machine immediately went into reboot. What gives?

I went to the remote machine and opened its Local Security Policy settings. In its User Policies group I found such policies as

Force shutdown from a remote system = Administrators
Shut down the system = Administrators, Users 

I removed Users from the latter policy, leaving only Administrators there.

I rebooted the remote machine, again logged in as Mike into my local machine and issued the same command. The remote machine again compliantly went into reboot.

The amusing detail here is that when Mike is logged into FILES machine locally, he cannot reboot it, since Shut down the system policy is set to Administrators, while Mike is a mere User. But the same Mike can successfully reboot FILES remotely.

So, what's going on here? How come I am able to reboot the remote machine using a User level account? Moreover, the aptly named policy Force shutdown from a remote system set to Administrators seems to suggest that regular User accounts should not be able to do it. Yet it reboots.

What am I missing here? What lets that remote reboot command slip through? What should I block and where to prevent Mike from being able to reboot FILES machine remotely?


A further investigation shows the following entries in the Event Log of FILES

The process wininit.exe (192.168.1.2) has initiated the restart of computer FILES 
on behalf of user FILES\Administrator for the following reason: No title for this 
reason could be found
 Reason Code: 0x800000ff
 Shutdown Type: restart
 Comment: 

Such entries correspond to each remote reboot command received by FILES. 192.168.1.2 in this case is the IP address of the machine that issued the shutdown command. So, as @misha256 correctly suggested, the command is actually executed on the remote machine as if it was issued by Administrator. This is why the current policies don't block it.

Now the question is where it managed to elevate from Mike to Administrator: on the local machine or on the remote machine? And, of course, how and why it happened...

  • try the command gpudate /force – Richie Frame Feb 27 '15 at 6:01
  • @Richie Frame: Just tried it. Doesn't change anything. Rebooting the remote machine should have updated the policy anyway... – AnT Feb 27 '15 at 6:18
5

I found the culprit.

A long while ago user Mike (which has been around for a while) wanted to connect to one of the administrative shares on the remote FILES machine, say, \\FILES\C$. In order to achieve that user Mike connected to FILES as an Administrator, entering remote Administrator password and asking Windows to save his credentials. The credentials got saved. All the time they were visible in Control Panel's Credential Manager applet under Windows Credentials.

Apparently, shutdown command takes advantage of these stored credentials when it receives an "Access denied" response from the remote machine (or, maybe, it takes advantage of these stored credentials right away, unconditionally). This is how Mike was able to elevate himself to FILES\Administrator level and successfully reboot the remote machine.

Once I removed the stored credential from Credential Manager, Mike immediately started to receive the expected "Access denied" response from shutdown.

| improve this answer | |
  • I wouldn't have thought of that! This is good to know. Thanks for posting your answer for the benefit of others too :-) – misha256 Feb 27 '15 at 19:56
0

If the login on target machine is valid, it should work no matter if the account type is administrator or user, since standard users do have the right to shutdown or reboot the station. Exception for this is only if the rights have been revoked via security policy.

| improve this answer | |
  • Well, firstly, in my case the shutdown rights have been revoked via security policy. When logged in locally as Mike into the FILES machine I cannot shut it down locally, since Shut down the system policy is set to Administrators. Yet, somehow the same Mike can shut it down remotely. This makes no sense at all. – AnT Feb 27 '15 at 6:33
  • Secondly, local operations and remote operations are typically controlled by Windows security policies separately. So, I expect this policy to also be controllable separately. And the Force shutdown from a remote system policy seems to be designed for that purpose specifically, as the name suggests. However, it doesn't seem to work. – AnT Feb 27 '15 at 6:34
  • The policies are interlinked and also have some dependencies. This will certainly require further testing. Since this case is interesting, i will try to emulate your situation in virtual environment since I do have the two operating systems already installed. – Overmind Feb 27 '15 at 6:41
  • @AndreyT This is not a policy issue. Somehow Shutdown is executing as Administrator on the remote machine. Now we need to figure out how that is the case. Hmmm... – misha256 Feb 27 '15 at 6:46
  • @misha256: Could be. But how? – AnT Feb 27 '15 at 6:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.