Is that a Server? Or: Why you can't use domain service accounts on workstations!

What's a server? A server is a computer that you keep in the machine room. Why is that?

• Well of course there can be a host of operational reasons. If you want to keep it running all the time, better install your box where the cleaner won't unplug it
• And there are the security reasons. What are they? From the security PoV, what's a server?

The point really is that access to the physical console of a PC carries a risk that we accept in the case of workstations, but don't accept for other machines. The risk is controlled by controlling access and that's why we have cards, combinations, access logs etc on machine rooms.

I think it's interesting to take the components that traditionally make up that risk and look at the consequences for the machines we DON'T put in the machine room:

1. The contents of the hard disk are confidential or valuable. Apart from the normal confidentiality of a fileserver or application server perhaps the build or install is hard to replicate. So we keep the box in a safe place. Implications for workstations kept in their dangerous places are:
   • Filing on the workstation C: is never right. Users should not be able to write to WS local drives, OR (the laptop solution) local drives should be encrypted with explicit backup responsibility transferred to the user.
   • You should be able to replicate any WS build, or you are hostage to any user who declines to give up their PC
2. Local admin is available to anyone prepared to do a reboot. (You do so know how!) You definitely don't want attackers making themselves admins on your servers, so you lock them away. Workstations can't be locked away, and so their administrator accounts must each have a different, unpredictable password. Then, if I crack my own WS, I'm still not admin on any other, remote, WS. The same goes for any other local account -- so on workstations you probably shouldn't have any.
3. The local admin can run as any domain account used for a service account or task scheduler processing. So our attacker now has access to some domain accounts. (You know how to do that too, without cracking the SC database password list). For workstations, where you know it's possible that an attacker may make themseleves admin, this means that you can't use any system that uses a domain account to run agent services. That was a surprise to me, but it's inescapable.
4. Some applications require a console session to work to be permanently open. It is our solemn duty to mock the designers of these nightmares, but we have to accomodate them, and the right place is in the machine room. For workstations, the implication is that we can only allow processing that can be shut down.

Those last points makes the simplest definition of a server. It's a server if it does unattended processing a) under a domain service account or b) on the console.

The biggest surprise for me was the service account problem. It knocks out some agent-based management tools. Instead, we get to choose the trade-off:

• Agentless tools pass (the same) admin credentials across the network for each machine it manages -- a terrible choice for network security
• Agent-based has to use its own secure channel to report results --duplicating effort and potentially introducing obscure insecurity.