Windows Server 2003 has a large number of relatively minor, but very important, changes in the management category. We consider many of these changes to be minor only because they build on previous functionality or implement functionality first available in Windows XP; the impact of these changes on your environment can by anything but minor.
Security templates were introduced in Windows 2000 and provide a means of consistently applying security settings across all the computers in your organization. Security templates can be deployed via group policy, enabling you to configure account policies, local security policies, event log settings, system services settings, Registry entries, file system permissions, and the membership of restricted groups. In fact, about the only things you can't configure in a security template are IPSec and public key policies.
Windows Server 2003 introduces some new predefined security templates, so you can deploy specific security scenarios without having to custom-build your own security templates. Windows Server 2003 installs these templates to your system root folder (\Windows by default), under the Security\Templates subfolder. Some of the predefined templates are included with Windows 2000 Server, as well; for completeness, we'll list them all and their effects on Windows Server 2003:
Setup security.inf? This template is applied by Windows Server 2003 Setup and creates the initial security settings for a new installation of the operating system. The template's exact effects differ between an upgrade from a prior version and a clean install, and you can reapply the template, preferably by using the Secedit tool, to restore the default settings.
Setup security.inf is huge because it contains all the security settings needed on a new installation of Windows Server 2003. "Huge" in this case means that you should under no circumstances apply this template through group policy. If you do, you'll see some seriously slow performance and group policy struggles to deal with such a massive group of settings.
DC security.inf? This template is applied when a server is promoted to a domain controller. This template includes several file permission settings, so reapply it with caution because it can overwrite custom security settings you've applied to your server.
Compatws.inf? This template lowers system security somewhat in favor of compatibility with older applications. Older applications, for example, can require the built-in Users group to have write permissions to areas of the Registry. Under older versions of Windows, the Users group had those permissions; under the more-secure Windows Server 2003, it doesn't. This template restores older-version security to enable older applications to run without modification. You should use this template only if absolutely necessary because it does, after all, lower system security. Never apply this template to a domain controller because it will negatively affect domain controller security and operations.
Secure*.inf? This is actually two templates: Securews.inf is intended for client computers and member servers, and Securedc.inf is intended for domain controllers. These templates raise system security from the default as much as possible while maintaining a high level of application compatibility. These templates configure clients to use only NTLMv2 authentication and configure servers to refuse older LAN Manager authentication. From an authentication standpoint, these templates can be safely used in any environment running Windows NT Server 4.0, Service Pack 4, or higher. Note that Windows 9x computers can use NTLMv2 authentication only if they have Microsoft's Directory Services Client Pack installed; without it, they will be unable to authenticate in an environment using Securedc.inf.
Hisec*.inf? These templates impose stronger security than the Secure*.inf templates. Hisecdc.inf configures domain controllers to refuse all LAN Manager and NTLM authentication, and Hisecws.inf forces clients to use only NTLMv2. The Hisec*.inf templates also require data encryption between clients and file servers and stronger encryption between domain controllers and domain members. These templates are safe only in environments that are running Windows 2000 or higher operating systems or Windows 9x clients with the Directory Services Client Pack installed. The Hisec*.inf templates also remove all members from clients' Power Users group and ensure that only the Domain Admins group and the local Administrator account are members of computers' local Administrators group. This behavior can create problems with older applications expecting users to have additional security privileges.
Rootsec.inf? This template defines the root permissions for Windows Server 2003, which are the permissions on the root of the system drive (usually C:\). You can use this template to reapply the default root permissions, if necessary, or you can modify the template to apply the same root permissions to other volumes. The template does not overwrite explicit permissions on child folders; it simply changes the root permissions and enables them to propagate to child folders that inherit permissions.
Notssid.inf? The default file and Registry permissions on Windows Server 2003 grant permissions to the special Terminal Server Security Identifier (SID), which is used when Terminal Services is running in application compatibility mode. If you're not using Terminal Services, however, you can apply Notssid.inf to remove the Terminal Server SID from all files and Registry entries. Alternatively, you can run Terminal Services in Full Security mode, which does not utilize the special Terminal Server SID.
Some of these template names might look familiar because many of them are included in Windows 2000. However, the templates included with Windows Server 2003 configure a different range of settings, and in many cases configure different settings, so you'll need to analyze them all over again before you start using them.
So, how can you apply these templates? Just as in Windows 2000, you can use the Security Configuration and Analysis snap-in to the Microsoft Management Console (MMC), or you can use the command-line tool Secedit.exe.
If you're not familiar with the MMC and would like a quick tutorial, log on to www.samspublishing.com and enter this book's ISBN number (no hyphens or parentheses) in the Search field; then click the book's cover image to access the book details page. Click the Web Resources link in the More Information section, and locate article ID# A011301. If you'd like a quick tutorial on Secedit.exe, enter ID# A011302.
Windows Server 2003 includes a full set of software restriction policies, which enable you to control the software that runs on your servers. You can configure these policies within a server's local security policy, or you can use group policy to deploy a consistent software restriction policy set to all your servers and client computers. Software restriction policies consists of some basic components:
One or more security levels? By default, two levels are included: Disallowed and Unrestricted. You can set one of these to be the default (Unrestricted starts out as the default), and it will be applied to all software that doesn't have a specific policy defined.
A basic enforcement policy? By default, it allows all software except DLL files and other libraries to execute for all users.
A designated file types policy? Defines specific file types that are considered to be executable code, such as EXE, COM, BAT, VBS, and so forth. The default list is quite comprehensive, including just about every bit of executable code Microsoft could think of.
A trusted publishers list? Defines who can select software publishers to trust. By default, end users are given this capability. Software restrictions will allow software from a trusted publisher to run, provided the software is digitally signed with the publisher's certificate.
Additional rules? This is where you can define your own specific software restrictions. Windows Server 2003 supports four types of rules:
Certificate rules? Enable you to identify software by a digital certificate used to sign the software and decide which security level will be applied to the software.
Hash rules? Enable you to identify software through a checksum method. You need to identify a specific file, and then Windows will perform a mathematical operation on the file to generate a hash, or checksum. You then decide which security level will apply to software that meets the hash. The purpose of the hash is to uniquely identify software regardless of its name. For example, if you want to ensure that Notepad.exe will execute, no matter what filename it actually uses, you would create a hash rule. Hash rules are most often used to stop software from being run because the hash detects the software even if a user attempts to rename it.
Internet zone rules? Enable you to define a security level for specific Internet zones.
Path rules? Enable you to define a security level for a specific file according to its exact path. Note that a user can almost always move the file to a different location, rendering the path rule inoperative.
Figure 13.1 shows a new hash rule that assigns the Unrestricted security level to all files matching the hash for Notepad.exe. If you defined the Disallowed security level as your default, you would need to define a rule such as this one for all the software you want your users to be able to run.
Keep in mind that, because software restriction policies can be deployed through group policy, you can define multiple, different sets of restrictions. For example, one set might apply to domain controllers only and include severe restrictions on the software that can run, helping to prevent viruses and other unauthorized software. Users' computers might have a less restrictive set of policies applied, which might prevent only specific unauthorized software, such as Napster-style applications, from running. Software restrictions can also be configured in either or both of the Computer or User Configuration sections of a group policy object (GPO), enabling you to get very specific and even assign restrictions to particular users? provided those users are organized into organizational units (OUs) within Active Directory.
Microsoft's IntelliMirror technologies are alive and well in Windows Server 2003, with only minor changes to support new Windows Server 2003 and Windows XP deployment options. One important new change is in the software deployment user interface. This interface now includes an option to allow 32-bit packages to be deployed to 64-bit computers. Because both Windows XP and Windows Server 2003 are available in 64-bit editions, this option enables you to deploy 32-bit applications (which will run in 32-bit compatibility mode) or prevent 32-bit applications from being published or assigned to 64-bit clients.
Microsoft's white papers on IntelliMirror stress its suitability for "simple" software deployments and take care to point out the availability of Microsoft Systems Management Server (SMS) for more complex deployment needs. If you're evaluating SMS for use in your environment, do so with great care: SMS is a complex product with important planning requirements. You also might want to look into the next version of SMS, which will integrate more fully with Active Directory and other Windows Server 2003 technologies.
Some of the most useful changes to IntelliMirror are actually changes to group policy, such as the new Resultant Set of Policies display, the new Group Policy Management Console, and so forth. These changes all contribute to IntelliMirror management and troubleshooting, as well as general group policy administration.
If you'd like to know more about changes to group policy in Windows Server 2003, see Chapter 6, "Group Policy Changes," p. 81.