| Windows Server 2003 comes with a full set of preconfigured security templates that you can use to customize the security settings of the server (or other computers in the domain) to your liking. These preconfigured templates can be thought of in one of two ways: either as a starting point from which to make your own customized security templates or as a solution in of themselves. These preconfigured templates have the extension .inf and are located in the %systemroot%\security\templates folder on a Windows Server 2003 computer. You can use the Security Configuration and Analysis snap-in, the secedit.exe tool, or the Local Security Policy console to apply these templates to a local computer. Table 11 details the preconfigured security templates that ship with Windows Server 2003. Table 11. The Preconfigured Security Templates in Windows Server 2003Template (Filename) | Description |
|---|
Default (Setup security.inf) | This template is created during the installation of Windows on the computer. This template varies from one computer to the next, depending on whether the installation was performed as a clean installation or as an upgrade. Setup security.inf represents the default security settings that a computer started out with and thus can be used to reset portions of security as required. This template can be applied to both workstations and member servers, but not to domain controllers (DCs), and it should never be applied via Group Policy due to the large amount of data it contains. Doing so can result in performance degradation. | Default DC (DC security.inf) | This template is automatically created when a member server is promoted to a DC. It represents the file, registry, and system service default security settings for that DC and can be used later to reset those areas to their default configurations. | Compatible (compatws.inf) | This template allows members of the Users group to run applications that do not conform to the Windows Logo Program for Windows 2000 and above. Applications that were written for Windows NT 4.0 do not use the same security model that applications written for Windows 2000 and above use. Applications that do conform to the Windows Logo Program can be, in the majority of cases, successfully run by members of the Users group without any further modifications required. For applications that do not conform, there are two basic choices: You can make the users members of the Power Users group or relax the default permissions of the Users group. The Compatible template solves this problem by changing the default file and registry permissions that are granted to the Users group to allow them to run most applications that are not part of the Windows Logo Program. As a side effect of applying this template, all users are removed from the Power Users group because the basic assumption is that the template is being applied in an effort to prevent the need for that group. This template should not be applied to DCs, so do not import it into the Default Domain Policy or the Default Domain Controller Policy. | Secure (securews.inf, securedc.inf) | The Secure templates are the first ones to actually begin the process of locking down the computer to which they are applied. There are two different Secure templates: securews.inf, which is for workstations and member servers, and securedc.inf, which is for DCs only. The Secure templates prevent the usage of the LAN Manager (LM) authentication protocol. Windows 9x clients need to have Active Directory Client Extensions installed to enable NT LAN Manager version 2 (NTLMv2) to allow them to communicate with Windows 2000 and above clients and servers using these templates. These templates also impose additional restrictions on anonymous users, such as preventing them from enumerating account and share information. The secure templates also enable Server Message Block (SMB) signing on the server side. By default, SMB signing is enabled on client computers. If you apply this template, SMB packet signing will always be negotiated between clients and servers. | Highly Secure (hisecws.inf, hisecdc.inf) | The Highly Secure templates impose further restrictions on computers to which they are applied. Whereas the Secure templates require at least NTLM authentication, the Highly Secure templates require NTLMv2 authentication. The Secure templates enable SMB packet signing, and the Highly Secure templates also require SMB packet signing. In addition to the various extra security restrictions that are imposed by the Highly Secure templates, these templates also make several changes to group membership and the login process. All members of the Power Users group are removed from this group. In addition, only members of the Domain Admins group and the local administrative account will be allowed to be members of the local Administrators group. When the Highly Secure templates are used, it is assumed that only Windows Logo Program-compliant applications are in use. Therefore, there is no provision in place for users to use noncompliant applications because the Compatible template is not needed and the Power Users group has no members. Members of the Users group are able to use applications that are Windows Logo Program compliant. In addition, members of the Administrators group can use any application they want. | System Root (rootsec.inf) | This template defines the root permissions for the root of the system volume. If these permissions are changed, they can be reapplied by using this template. In addition, you can modify this template to apply the same permissions to other volumes. Explicitly configured permissions are not overwritten on child objects when you use this template. | No Terminal Server Use SID (notssid.inf) | This template is used on servers that are not running Windows Terminal Services. It removes all unnecessary Terminal Services security identifiers (SIDs) from the file system and registry. This, however, does not increase the security of the server. |
The Security Configuration Manager is not one console or tool per se; it is actually a collection of tools and utilities that you can use to implement security solutions across a network. The following are the components of the Security Configuration Manager: The Security Configuration and Analysis snap-in The Security Templates snap-in Group Policy security extensions The secedit.exe command
The Security Configuration and Analysis snap-in is an important tool in an administrator's security template toolbox. By using the Security Configuration and Analysis snap-in, you can create, configure, test, and implement security template settings for a local computer. However, this reveals its one real weakness: It can be used to work only with the settings of a local computer. You can, however, find ways to get around this limitation by using the other tools that are at your disposal, including secedit.exe and the security extensions to Group Policy, both of which are discussed later in this chapter. The Security Configuration and Analysis snap-in can be used in two basic modes, as its name suggests: configuration and analysis. You can analyze and configure the following areas by using the Security Configuration and Analysis snap-in: Account Policies Local Policies Event Log Restricted Groups System Services Registry File System
You can use seceditto perform the same functions as the Security Configuration and Analysis snap-in. In addition, it has a couple additional functions not found in the snap-in. The secedit command has the following top-level options available for use: /analyze /configure /export /import /validate /GenerateRollback
To analyze the current security configuration of the local computer, you would issue the secedit.exe command with the following syntax: secedit /analyze /db FileName /cfg FileName /overwrite /log FileName /quiet
Windows Server 2003 provides the following areas in which you can enable auditing: The following are some of Microsoft's recommended practices for successfully implementing and maintaining a security auditing solution: Create an audit plan before you implement auditing. Collect and archive logs across the entire organization. Audit system events for success and failure events. Audit policy change events for success events. Audit account management events for success events. Audit account logon events for success events on DCs. Configure specific object access auditing.
The Security Configuration Wizard (SCW) is a new and more advanced security hardening tool for Windows Server 2003 SP1 and Windows Server 2003 R2. If you have servers running these latest versions of Windows Server 2003, the SCW is worth taking a look at. By default, the SCW is not installed on your Windows Server 2003 computer. Before you can work with it, you'll need to install it. Although Windows Server 2003 provides native support for the Windows Server Update Service (WSUS) and the older Server Update Service (SUS), it does not by default include WSUS. It's easy enough, however, to acquire the WSUS installation package and get to work configuring and implementing WSUS on a network. But what, really, is WSUS? WSUS is nothing more than a locally controlled and managed Windows Update server. Instead of allowing the Automatic Updates client on your client workstations and servers to download updates directly from the Microsoft Windows Update servers, you can install and configure one or more WSUS servers on your internal network and point your client workstations and servers toward those WSUS servers. As you might imagine, the ability to have your client workstations use an internal server for Windows Update can be a tremendous benefit to you because it means decreased bandwidth usage. As important as bandwidth savings might be, there is actually a larger benefit to be realized by implementing a WSUS solution on your internal network: the ability to approve specific updates that are to be installed on your clients. When you use Windows Update, your client computers install any available update that matches their needs, but with WSUS, you can specify which of the available updates are authorized to be pushed to the clients after you are satisfied that the update will pose no problems for the systems. This is a tremendous benefit that often goes unrealized. The requirements to install WSUS on a Windows Server 2003 computer are as follows: The system partition of the server must be formatted with the NTFS file system. The partition on which you install WSUS must be formatted with the NTFS file system. The system partition must have at least 1GB of free space available. The partition where you install WSUS must have a minimum of 6GB of free space available; however, for best results, it is recommended that the partition being used have at least 30GB of free space available. The partition where WSUS setup installs the Windows SQL Server 2000 Desktop Engine (WMSDE) must have at least 2GB of free space available. The server must have Internet Information Services (IIS) 6.0 installed. The server must have the Microsoft .NET Framework 1.1 SP1 for Windows Server 2003 software installed. The server must have the Background Intelligent Transfer Service (BITS) 2.0 update installed. The Windows SQL Server 2000 Desktop Engine (WMSDE), which will be installed by the WSUS setup.
Clients to be updated by WSUS must fall into one of the following groups: Microsoft Windows 2000 Professional with SP3 or SP4. Windows 2000 Server with SP3 or SP4 or Windows 2000 Advanced Server with SP3 or SP4. Microsoft Windows XP Professional, with or without SP1 or SP2. Microsoft Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; Windows Serve 2003, Datacenter Edition; or Windows Server 2003, Web Edition.
|
