Why This Chapter Matters

---

Without a strategy for configuring and maintaining security settings on all computers on your network, the security of the systems will degrade over time. Even if you are willing to manually configure the security of every system, you could not count on that security staying the same. Administrators and users troubleshooting problems, installing new applications, or applying updates might inadvertently leave important configuration settings in a different, and possibly less secure, state.

Administrators use security templates to configure security settings on computers running Microsoft Windows. By itself, a security template is a convenient way to configure the security of a single system. When combined with Group Policy or scripting, security templates make it possible to maintain the security of networks with hundreds or thousands of computers running Windows.

Before You Begin

This chapter presents the skills and concepts that are required to configure security templates, deploy them across your network, and troubleshoot problems related to Group Policy. If you fulfilled the requirements for previous chapters, then you already have the necessary hardware and software configured. You can use the computers in the state they were in after completing the previous chapter, or you can install the software from scratch. To complete the practices, examples, and lab exercises in this chapter, you must have:

• A private, non-routed network.

• One computer. On this computer, perform a Microsoft Windows Server 2003 installation with default settings, and assign the computer name Computer1.

• Add the Domain Controller role to Computer1 using the default settings, and assigned the domain name cohowinery.com. The computer should be configured to use itself as its own primary Domain Name System (DNS) server.

Real World

I used to work at a hosting provider that managed hundreds of computers running Microsoft Windows NT Server 4.0 for external customers. We took security very seriously and put a great deal of energy into hardening those servers. Unfortunately, configuring a server securely is much easier than maintaining that security-a lesson I unfortunately had to learn the hard way.

When you harden the security of a system, you're bound to break some applications that were designed to work on a system with a standard security configuration. This isn't unusual; it just means that an administrator needs to identify the security settings required by the application and set them in a manner that allows the application to function without compromising the security of the system. At one point, a customer complained that an application wouldn't work, and one of the administrators on duty began troubleshooting the problem. The administrator did manage to solve the problem-unfortunately, the administrator did so by granting Everyone Full Control permissions over a directory that was accessible from the public Internet. The customer was happy with the solution…until a month later when an attacker used those weakened permissions to take control of the system.

This scenario could more easily be avoided today, thanks to the improvements offered by Windows Server 2003. With security templates and Group Policy properly configured, the administrator on duty would have been able to identify the cause of the problem and temporarily change the permissions. However, the administrator would need to request permission from a Domain Admin to change the centralized Group Policy to allow the new permissions, which would have given the Domain Admin the opportunity to suggest something more secure that would not have presented such a significant security vulnerability.

---