When you peruse the Microsoft Windows 2000 Server Resource Kit, you'll find the usual wealth of additional documentation and utilities that constitute a Microsoft resource kit. However, this resource kit is especially valuable to administrators who put a premium on security. In this article, I highlight just 10 of the many security-related reasons the resource kit is well worth its $300 price tag. Along the way, I point out several gotchas and drawbacks that you need to be aware of. (Be careful not to confuse the Win2K Server resource kit with the Microsoft Windows 2000 Professional Resource Kit, which is only a subset of the former.)
10. Analyze Security Logs with CLA
When I discovered that the valuable CyberSafe Log Analyst (CLA) is included in the Win2K Server resource kit, I did a double-take. CLA is a Microsoft Management Console (MMC) snap-in that lets you analyze the scattered Security logs of the systems in your domain as a whole. CLA has 11 prebuilt reports that provide useful views of your systems' security activity, but you can also design custom reports. To use CLA, you must first run setup.exe from the resource kit CD-ROM's \apps\loganalyst directory. Then, you can use the new shortcut in Administrative Tools to open CLA.
Using CLA is a three-step process. First, you need to tell CLA which event logs to analyze. To test CLA, you can copy the local system's current event log by right-clicking Logs to be Analyzed and selecting Cut Live Local Event Log. If you want to run reports on the merged activity of multiple systems, you'll first need to use Event Viewer to save each system's event log to an .evt file. (You can also use an event-log-dumping utility. For information about such utilities, see "Archiving and Analyzing the NT Security Log," August 2000.) After saving your logs, add them to CLA by selecting Add Event Log File from the Logs to be Analyzed context menu. Second, to tell CLA to analyze selected logs, select Analyze from the Logs to be Analyzed context menu. This action imports all the selected logs into CLA's native format, from which CLA can then run reports. Third, select and generate the desired report from the Report Templates folder. Figure 1 shows the prebuilt reports you can choose from.
CLA fills an important gap in Win2K's security-monitoring capabilities. Not only does CLA generate sophisticated reports (e.g., failed logon activity) but it gives you an enterprise view of your entire network's combined activity—not just one system at a time.
9. Control PKI with DSStore
Directory Services Store (DS-Store) is a general-purpose command-line utility that helps you diagnose and maintain a Win2K public key infrastructure (PKI) integrated with Active Directory (AD). If you aren't using enterprise root Certificate Authorities (CAs) to run a PKI in Win2K, you won't need this tool. But if you are, this tool is a godsend. DSStore is part of the resource kit's Security Tools component.
Although you can handle most PKI tasks from within the MMC Active Directory Users and Computers snap-in and the MMC Certificate Services snap-in, some operations aren't available from these MMC locations. DSStore lets you list, add, and delete Enterprise Root CAs and maintain certificate revocation lists (CRLs) in AD. DSStore also lets you add Win2K CAs or offline CAs to your enterprise PKI published in AD.
Win2K automatically enrolls users and computers with certificates the first time they perform an operation that requires a certificate. However, you've probably discovered that this process can be time-consuming in large networks. To speed up the process, DSStore lets you pulse auto-enrollment events, which proactively enroll users with appropriate certificates. You can also check the status of domain controller (DC) certificates and verify the validity of smart cards. Look in the resource kit's Tools Help document for more information about DSStore.
8. Manage EFS with EFSinfo
Encrypting File System (EFS) is a new and valuable Win2K feature that lets you protect confidential files—even from intruders who gain physical access to the disk while remaining transparent to the user. (For more information about EFS, see Mark Russinovich, NT Internals, "Inside Encrypting File System, Part 1," June 1999, and "Inside Encrypting File System, Part 2," July 1999.)
EFS currently lets one user per file designate a file or entire directory as encrypted. To encrypt a directory, you simply open the directory's Properties menu, click Advanced, then select the Encrypt contents to secure data check box, as Figure 2 shows. After you encrypt the directory, you can use the files as you usually do, without thinking about encryption. Win2K automatically encrypts and decrypts file data in memory as applications write to and read the file.
Win2K also supports data-recovery agents so that you can recover data that a user encrypted. You can use Group Policy to assign data-recovery agents to computers. If a user uses EFS to encrypt a file, only the data-recovery agents specified in Group Policy can access that file. Therefore, server administrators might feasibly encounter files they can't read on their own servers.
What if a server administrator needs to recover data but can't determine who originally encrypted it? EFSinfo, a command-line utility that installs with the resource kit's Security Tools component, solves this problem. EFSinfo displays encryption information for a specified directory or file. If you don't specify a pathname, EFSinfo displays encryption information for each file in the current directory.
If you type
you learn whether the file is encrypted and who can decrypt it (i.e., who originally encrypted the file). To display a file's authorized data-recovery agents, use the /r switch. In the following example, secret formula.txt was encrypted by Administrator, who is also the data-recovery agent for this system.
7. Manage Group Policy with GPresult
Win2K's Group Policy feature lets you manage system and user-profile configuration from a central point. But diagnosing exactly how Win2K is applying Group Policy to a given system or user can be tricky. Your system's configuration might be the result of many Group Policy Objects (GPOs) defined at the local system, site, domain, and organizational unit (OU) level. (For more information about Group Policy, see "Controlling Group Policy, Part 1," November 2000, and "Controlling Group Policy, Part 2," Winter 2000.)
GPresult, a command-line utility that installs as part of the resource kit's Network Management Tools component, helps you solve this diagnosis problem. GPresult's reports are too long to include here, but the tool provides a wealth of diagnostic information about how Win2K has applied Group Policy to the current computer or user. GPresult reports the Win2K version you're running (e.g., Win2K Professional, Win2K Server), group membership, privileges, date and time of the most recent application of Group Policy, which DC provided the GPOs, and most important, which GPOs Win2K applied from AD.
6. Scan for Vulnerabilities with System Scanner
I was excited about the resource kit's inclusion of CLA, but I was amazed to find that Internet Security Systems' (ISS's) System Scanner 1.1 was also included. ISS is one of the leading producers of security scanners, and System Scanner is a host-based vulnerability tool, as well as a policy-based assessment tool. Version 1.1 is admittedly several steps back from the current version 4.0, but it still excels at tackling the known vulnerabilities of workstations and servers exposed to the Internet. More important, System Scanner offers several policy and baseline checks that ISS originally designed for Windows NT but that apply equally well to Win2K.
To protect workstations, System Scanner checks for Internet browser vulnerabilities, ensures the correct configuration of virus protection, and watches for dangerous Microsoft Office settings. For Web servers, System Scanner checks for known Microsoft IIS-related exploits such as 8.3 filenames, server-side includes, and indexed ASP pages. System Scanner also checks for subtle risks. For example, when I ran the tool on a lab system, it warned, "Microsoft Office is installed on Web server." The message explained further, "A dedicated production web server should not have Office installed. Office exposes a large number of DCOM objects which can be used with scripting languages and may enable an attacker to subvert the web server." System Scanner checks for arcane NT vulnerabilities such as weak permissions on the registry's Winlogon and Run keys. You can also assess policy settings such as password, account lockout, and auditing.
My favorite System Scanner feature is its baseline capability, which lets you catch system modifications. System Scanner takes a snapshot, or baseline, of your system configuration. Upon subsequent scans, the tool compares the current system configuration with the snapshot and reports any changes. You can reset the baselines at any time, so you can take legitimate changes into account.
To track registry-value data, registry-key audit settings, ownership, and permissions, you can create registry baselines. To track changes to file content, and to audit settings, attributes, ownership, and permissions, you can create file-system baselines. (Figure 3 shows a custom scan policy for catching changes to content and permissions.) To identify new, unauthorized services and suspicious processes, you can create service and process baselines. Process baselines also let you track which programs and commands run at system startup and logon. You can create user baselines to monitor group membership, user-logon settings, RAS user settings, and rights assignments. You can even create share baselines to catch new shared directories or changes to share permissions.
To use System Scanner, run setup.exe from the resource kit CD-ROM's \appssystemscanner directory. Next, open System Scanner, and select File, Scan Now. Select an appropriate policy, and click OK. (Policies define which of the aforementioned checks you want to perform according to the type of system you're scanning.) System Scanner lists the vulnerabilities that it finds, as Figure 4 shows. When the scan has completed, the tool saves all findings to a scan history database, from which you can run reports that analyze scan results over time. You can run a simple Vulnerabilities Report that lists each vulnerability that System Scanner finds during one scan. Each Vulnerability Report includes an explanation of risk and instructions for fixing the problem. You can also run a Services Report, which identifies well-known Internet services that were open on your system during a scan. To quantify your progress in securing a system, you can run a Trends Report, which lets you compare the vulnerabilities that System Scanner finds in two or more selected scans. With the Differential Report, you can compare two scans and view vulnerabilities in the first scan, in the second scan, or common to both scans.
System Scanner is an impressive tool for scanning Win2K and NT systems. However, ISS clearly didn't write version 1.1 specifically for Win2K, and a few minor problems result. System Scanner doesn't check for all the open TCP/IP ports common to a Win2K DC, such as Common Internet File System (CIFS). However, you can use a custom policy to define additional ports to scan. System Scanner 1.1 also doesn't recognize all the base installation services (e.g., Kerberos, DFS) common to Win2K systems, and Microsoft has renamed some services between NT and Win2K. Therefore, the resource kit's version of System Scanner generates more "unknown service" vulnerabilities than it should. If you can't afford System Scanner 4.0, the resource kit's version will nevertheless prove very useful—and it won't cost you a dime.
5. Secure IIS Web Servers with Security Templates
The resource kit offers two new security templates for securing intranet and Internet Web servers when you use the Security Configuration and Analysis Tool. The Security Configuration and Analysis Tool is an exciting tool that lets you define nearly every aspect of a Win2K system's security configuration in an .inf template file. Using the MMC Security Templates snap-in, you can create different templates for each type of system, from workstations to servers. You can then apply a template to a system and secure it in one step. (This capability also helps to ensure standardization among multiple Web servers' security implementations.) For more information about the Security Configuration and Analysis Tool, see Mark Joseph Edwards, "Service Pack 4's New Security Configuration Editor," October 1998.
Win2K comes with predefined templates for different types of workstations, member servers, and DCs—and variants of each—for different levels of security. However, Microsoft hasn't tailored any templates to Web servers.
The resource kit introduces secure-intranetwebserver.inf and secureinternet-webserver.inf for both types of Web servers. Although I was initially excited to discover these templates, that enthusiasm was somewhat diminished when I investigated exactly which policies each template specifies. Unfortunately, the templates do little more than set arbitrary password and audit policies, secure some files under system32, and change a few rights assignments. These templates perform little if any hardening, or locking down, specific to Web servers (e.g., disabling services, restricting browsing users from accessing the Server service). According to the documentation, Microsoft has provided these templates as a useful starting point, which you must use your own knowledge of securing IIS to build on.
4. Audit IIS Web Servers with MetaEdit
When you need to audit an IIS Web server and ensure that authentication and access-control options are correctly configured throughout the Web site, you're in for a daunting task. In IIS, you can use Internet Service Manager (ISM) to configure security settings for each directory and file on your Web server. Security settings in IIS automatically flow down from parent directories to child files and directories, so you'll naturally start to check settings at the top. However, short of opening each object's Properties window, how can you determine whether you've accidentally weakened settings on files and directories below?
IIS configuration information resides in a database called the metabase. IIS arranges the metabase into keys and values. Each directory in your Web site has a corresponding key in the metabase. Each IIS property for that directory, including authentication and access control, has a corresponding value in that key. The metabase is similar to the registry but has one important difference: If you define a value in the metabase, that value automatically flows down to child folders—which is why IIS works the way it does.
Metabase Editor (MetaEdit), which comes with the resource kit's Internet Information Server Tools component, can help you speed up security checks on your IIS server. MetaEdit lets you quickly browse your Web site's configuration by navigating from one directory to another. After you learn the corresponding metabase value names of settings in ISM's Properties window, you can use MetaEdit to quickly traverse a branch of the directory tree and ensure that security is configured consistently throughout.
To test MetaEdit, first install the utility by running setup.exe from the resource kit CD-ROM's \apps\metaedit directory. Next, open MetaEdit. Web sites reside in the IIS metabase under \LM\W3SVC. Each Web site is contained in a subkey and identified by a number. For example, the settings for Default Web Site reside under \LM\W3SVC\1. To identify a Web site, look at the ServerComment value. Figure 5 shows that value for Default Web Site.
An important security setting for each Web directory is AccessFlags. This DWORD value represents preferences determined by check boxes on the Virtual Directory tab of a Web directory's Properties window, which Figure 6 shows. Access flags determine how browsers access the Web directory.
Another important value is AuthFlags, which corresponds to authentication methods for a Web directory. AuthFlags isn't a magic wand for auditing your IIS server, but if you learn your values and value names, you can check Web directory properties much faster than you can in ISM.
3. Restrict Concurrent Logons with Cconnect
Novell NetWare administrators often complain that neither Win2K nor NT has a concurrent logon restriction to prevent a user from logging on to more than one workstation simultaneously. In NT, you can limit a user to a specific workstation by defining a workstation restriction on the user account's properties in User Manager for Domains, but this workaround needlessly limits the user to a specific workstation instead of limiting the number of concurrent logons.
The resource kit's Concurrent Connection Limiter (Cconnect) utility lets you limit concurrent logons in Win2K and NT networks. Cconnect contains two components: Cconnect Administrator lets you view current logons across your entire domain and forcibly log off users when necessary, and Cconnect Client runs on each workstation and enforces the concurrent logon restriction. You must install Cconnect Client on each workstation. When a user logs on to a workstation, Cconnect Client counts the number of currently active logons for that user in a Microsoft SQL Server database, then compares that number to the maximum number you've allowed for that user. If the user has exceeded the limit, Cconnect immediately logs the user off.
To use Cconnect, you first set up a new database and user account on an SQL Server machine. Then, to centrally manage all the instances of Cconnect Client, you need to import some new Win2K Group Policies or NT system policies. The policies, which reside in the cconnect.adm file, define registry values under the HKEY_CURRENT_ USER\Software\Microsoft\Cconnect subkey. These registry values point Cconnect Client to the correct SQL Server database and define the user's concurrent logon limit. (Figure 7 shows these policies imported into System Policy Editor—SPE.) After you import the cconnect.adm file, you can configure Cconnect's policy and SQL Server connection data. Next, to install Cconnect Client on each workstation, run setup.exe from the \apps \cconnect\client directory. To install Cconnect Administrator, run setup.exe from the \apps\cconnect\administrator directory. The first time Cconnect Client or Cconnect Administrator runs within your network, it builds the necessary tables in the SQL Server database you created.
If the only Cconnect function you require is concurrent logon restrictions and you're running Win2K on the desktop as well as on the DC, you don't need to install Cconnect Client. Instead, you can modify your user's logon and logoff scripts to call cconnect.vbs and cclogoff.vbs, respectively. If you define your logon scripts in Group Policy under User Configuration, Windows Settings, Scripts, you can deploy Cconnect throughout your domain without ever touching a workstation.
You need to be aware of a few caveats regarding Cconnect. Because the SQL Server database deletes active logon records only when a user logs off in a usual manner, Cconnect might improperly deny logon. For example, the database doesn't delete the logon record during a power failure. If a user is limited to one concurrent logon and uses the same workstation for his or her next logon, the database deletes the orphaned logon record, and the problem disappears. However, if the user tries to log on to a different workstation, Cconnect assumes the user is exceeding the logon limit. To fix the problem, you must use Cconnect Administrator to manually delete the old logon record.
Another problem is that savvy users can defeat Cconnect. Cconnect uses SQL Server only to store current logon data. For other configuration and policy settings, the utility uses the HKEY_CURRENT_USER\Software\Microsoft\Cconnect registry subkey. Therefore, users who understand the registry can disable Cconnect simply by pointing the tool to a bogus SQL Server machine or by increasing their concurrent logon limit. To mitigate this risk, you can use Group Policy in Win2K or SPE in NT to disable registry editors. But users who know how to use scripts to access the registry can circumvent that restriction. To limit users to Read access to the Cconnect registry key, you might try implementing a script that is executed at logon.
Also, Cconnect Client stores SQL Server user and password data in clear text in the registry. If you follow the instructions for setting up the SQL Server user account for Cconnect, the account will have SQL Server authority similar to SQL Server's built-in administrator account (i.e., sa). The account's username and password are therefore sitting dangerously in clear text on every workstation registry. To reduce the risk of malicious users using this account to attack other databases on the same SQL Server machine, first create the Cconnect database and user account on the SQL Server machine, as cconnect .doc describes. Then, run Cconnect Client for the first time to populate the SQL Server database you just created. Now, modify the authority of the Cconnect user account to restrict it to just the Cconnect database.
Finally, you need to be aware of special requirements when you use Cconnect in a network of NT workstations. Each workstation needs Service Pack 4 (SP4) or later with Windows Script Host (WSH), Web-Based Enterprise Management (WBEM), and Microsoft Data Access Components (MDAC) 2.0 or later. All these components are available for download at http://www.microsoft.com/ ntserver/all/downloads.asp. Unfortunately, you can't use Cconnect for users with Windows 9x systems.
2. Centrally Control IE with IEAK
The resource kit includes the Microsoft Internet Explorer (IE) 5.0 Administration Kit (IEAK). The IEAK lets you customize IE before you deploy it to your workstations. You can specify IE's initial security options (e.g., restrict ActiveX and Java components), then control which settings your users can change. This capability lets you ensure that IE's browser settings adhere to corporate standards.
To install the IEAK, run ieak5.exe from the resource kit CD-ROM's \apps\ieak directory. To learn more about the IEAK, go to the new Microsoft IEAK folder in your Start menu and select IEAK Help.
1. Scrutinize the Documentation
A final important security tool in the resource kit is the wealth of documentation you'll find in the resource kit's Documentation folder in your Start menu. One of the most valuable documents is Error and Event Messages. According to Microsoft, this document "contains most of the error and event messages generated by Windows 2000. With each message comes a detailed explanation and a suggested user action." The document lives up to that promise.
You'll find the Event Log section especially useful for understanding all the events in the Security log. The Group Policy document is an enlightening reference, offering detailed information about the hundreds of settings that Group Policy contains. You'll be pleased to find an updated reference to the Win2K registry, as well as seven more references and guides under Online Books. I long ago read the brief documentation in Win2K's online Help, so now I take all my questions to the resource kit's Online Books.
Essential Tools
The Win2K Server resource kit lives up to the series' reputation for delivering useful tools and desperately needed documentation. Arguably, Microsoft should include all this information with the original product, but I suppose the opportunity to charge more for additional documentation and unsupported utilities is too valuable for Microsoft to pass up.
Regardless, the resource kit is essential to systems administrators concerned about security. Don't try administering Win2K without it.
