The most important principle of protecting anything, and servers in particular, is to have a healthy disrespect for the rules. You will constantly run into statements like "that is not supported" and "we have never tested that." Those statements are very important, but they do not mean you cannot do something. They just mean you may be on your own doing it.
Certain things are known to be really bad for your careersuch as wholesale replacement of Everyone access control lists (ACLs) with Authenticated Usersbut there are a lot of others that simply have not been thoroughly tested but may be valuable nevertheless. You should feel free to experiment here. The fact remains that what is tested are things that will work in every, or almost every, environment. Your environment is unique and only you know how unique. If you want an optimally protected system for your environment, you need to analyze your environment, apply steps that are appropriate to mitigate the risks you find are important, and be willing to test some new things and break some rules in the process. This is not magic, just tedious . Nevertheless, some things simply do not make sense, such as the aforementioned replacement of Everyone with Authenticated Users. Since the two groups are functionally identical since Windows XP, the risk associated with doing so is considerably higher than the non-existent benefit. Also keep in mind one fundamental rule: Do NOT test "hardening" steps on production systems, unless you feel your career has progressed as far as you are interested in going already.
Turning on untested hardening tweaks on production systems is known as a CLMa career-limiting move. We do not like those. Feel free to break things; experimentation is important. Just make sure you do it on test systems, such as virtual machines or lab machines.
A note on hardening versus supportability is worthwhile here. As mentioned earlier, vendors often claim that some setting, tweak, or configuration is "unsupported." In some cases, as in the aforementioned ACL case, there is really good reason for this. Some tweaks simply put the system into an unstable or unreliable state. In other cases, the reason for a setting being unsupported is more likely that it has not been adequately tested. Supportability means that the vendor understands the configuration, can replicate it, and has tested it with a reasonable number of other applications and systems. Just because something is "unsupported" does not necessarily mean it will not work. What it does mean is that it may have intersting and exciting side-effects that you may not get vendor help in resolving, or that what you get is "best efforts" support, which might be limited to undoing your configuration. For this reason, it is critical that you maintain adequate documentation on what you did, understand the impact of the changes you are making on the functionality of the system, and understand how to undo the changes you make. ACL changes, for instance, cannot be undone in some casessuch as wholesale ACL changes on the root of the boot partitionwhereas Registry changes are trivial to undo, as long as the system still boots. You also need to understand how to test things because the vendor has not always done it.
OK, enough warnings, on to some of the basics of hardening services and server apps.