Summary of Exam Objectives

Configuring server security based on its role is a critical step in the security implementation process that you simply cannot overlook. For the longest time, it was simply considered good enough to configure all servers (and most workstations, for that matter) alike when it came to security. This no longer is true.

Fortunately, a number of sources of help are available to you—some from Microsoft, some from respected third parties such as the National Institute of Standards and Technology (NIST) and the National Security Agency (NSA). IIS servers, SQL servers, Exchange servers, IAS servers, file and print servers, and domain controllers all require their own different security configurations. Using specialized security templates (policies) along with hardening tools such as IIS Lockdown, URLScan, the MBSA, and HFNetChk can go a long way toward helping you secure your servers to allow them to perform their functions without leaving them excessively vulnerable to attacks and hostile code implementation.

Desktop workstations and portable client computers also require special security configuration, different from that applied to your servers. Desktop and portable computers should have their Data Recovery Agent certificate and keys removed and placed in a secure storage location, among other things. Implementing specialized (more secure) security templates on these computers is also an option that should be investigated. Of course, keeping all clients up to date with the latest service packs and hotfixes is a critical step in keeping them secure—one that cannot be underestimated. Procuring and deploying updates is discussed in more detail in Chapter 3.

When implementing security in your network, you are likely to run across some problems or issues. Upgraded computers and legacy clients can all lead to problems you were not prepared to deal with. Examining the Event Log and configuring Active Directory diagnostic event logging can help you track down issues with Group Policy applications—and, therefore, security implementation. You also have the gpresult.exe tool at your disposal, which provides a very powerful Group Policy information collection system that can be used from the command line to quickly determine the current state of Group Policy on a target computer.

Although legacy clients cannot receive Group Policy settings, they can still participate in Active Directory in a limited way by use of the Directory Services Client application. Since Group Policy objects are not applied to these clients, you might well want to examine the use of System Policies and the System Policy Editor to configure consistent security and cosmetic settings across these legacy computers.

Server Message Block (SMB) signing can be implemented to prevent the man-in-the-middle attack and message attacks by authenticating both sides of a communications session (server and client) and by also digitally signing the packets. In order for SMB signing to be effective, both the client and the server must be configured for at least the same minimum setting. Should a server require SMB signing and a client attempting to initiate a connection not at least be enabled for SMB signing, the connection attempt will fail.