Windows – Who has the rights to shutdown a Windows machine remotely

remotesecurity-policyshutdownwindows 7windows 8

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…

Best Answer

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.

Related Question