We recently covered what can happen if your user roles are configured in a way which allows standard users to have too much control of the network. While that article made it clear that having unnecessary domain admin access can be bad, there were still a few points it did not cover. One such point is what can happen when your users have excess privileges on a remote (or local) server – unexpected server shut down.
What is the problem?
Consider the following. In many workplaces, users are told that at the end of the day they should shut down their computers. Whether they actually do it is another story. A lot of businesses are also making the jump to cloud computing with co-location and terminal servers to make their work more efficient. The problem arises when the server – or users – are configured poorly.
When a user goes to shut down their computer at the end of the day but they are actually remotely logged in to a terminal server, if they have the appropriate permissions, the server will shut down. If it is remote, turning it back on might be a bit trickier than just pressing a button like you would if it was on-site. If it is a true cloud service such as an Amazon EC2 instance, you can just restart it online, but if it is a physical machine in a data centre, you might be out of luck.
What is the solution?
The most common solution to this problem is to implement a group policy to remove the option to shut down or restart from certain users. Expanding on our last article, the best way to do this is to allow only administrators the ability to cause a server shut down, and to assign this role sparingly. Most users should not fall into this role as it gives them additional rights and expands the potential attack surface of your network. The same principles should be applied to all servers and mission critical systems on the network. Standard users should not have the permissions or the physical access required to shut down or restart a server. This privilege should be reserved for the system administrator.