If your job includes security, the Security Configuration Editor in SP4 can truly make things much easier. In this new column, an NT security expert tells what the new release can do for you.

Inside Service Pack 4

If your job includes security, the Security Configuration Editor in SP4 can truly make things much easier. In this new column, an NT security expert tells what the new release can do for you.

• By Roberta Bragg
• 01/01/1999

What’s the best server? Right—the one that’s up 24 x 7 x 365. Attention to security is one way to keep it there. As administrators, managers, integrators, developers, and trainers we’re responsible for making others aware of security issues. We don’t want to be among the 75 percent of companies that a 1997 Computer Security Institute study lists as having lost money to computer crimes. We don’t want our computer systems to be harmed by attacks this year.

That’s why MCP Magazine and I would like to welcome you to “Security Advisor,” a monthly column that explores security as it applies to your enterprise. You probably already lock your doors at night; we’ll show you how to lock your network. In coming months, we plan to look at many different aspects of security, from conducting a security audit to the special concerns and techniques of ensuring security on BackOffice products. This month, we’ll examine the increased security offered by Service Pack 4 for Windows NT 4.0.

An Awareness of Security

A lot has changed since Service Pack 3 for Windows NT 4.0 was introduced in May 1997. At that time, there were fewer NT boxes in large organizations, and fewer of us were focused on security issues. The network philosophy seemed to be, “If it ain’t broke, don’t fix it.”

With earlier releases of NT, Microsoft often appeared to be on the defensive, denying security issues while preparing fixes for only the most notable ones. With the growing acceptance of NT, that’s changed. Today, Microsoft has a Web site—www.microsoft.com/security—dedicated to security issues. When a new NT problem is reported, the company appears to move into action, rapidly verifying or reassuring, explaining, offering a hot fix, and making recommendations. You can even sign up for Microsoft security bulletins, delivered by e-mail.

While only a few of the 300 bug fixes in SP4 actually address security issues, what you will find in it is the Security Configuration Editor (SCE). Designed to be a part of NT 5.0, the SCE integrates security implementation and analysis on NT, thereby addressing a fundamental weakness of the OS. [This article is based on a beta version of SP 4.—Ed.]

Snap-in Security

I used to wonder why my students complained about the lack of NT security. They’d pose a problem and I’d answer with instructions on how to use NTFS, how to set up rights and permissions, and how to turn on auditing. Simple, from a classroom stance—and if you’re in a small domain. But more and more of my students were coming from companies implementing huge enterprises with dozens of NT servers and hundreds of NT workstations. They didn’t want to hear, “First enable file and object auditing in User Manager for Domains, then visit folders and files in Windows Explorer to turn on auditing for files and folder, then use Printers to turn on auditing for printers, then edit the NT Registry, then...” They wanted—demanded, even—something more central and less time-consuming and confusing. Some bought third-party solutions. Others just didn’t implement any security beyond logon.

The Security Configuration Editor is a Microsoft Management Console snap-in utility that lets you centrally administer security features across a Windows NT domain. It doesn’t replace the current set of utilities for adding users, establishing object permissions, and auditing; although you can do all of these tasks in the new editor, you can still use other utilities as well. SCE simplifies the implementation of security features and provides an analysis component that detects variations from the policy set. Security configuration is made in the large and implemented in the background. Analysis provides information about the compliance to policy.

Installing SCE

Installation of SCE is straightforward. After installing Service Pack 4, follow these steps.

1. Run the Microsoft Management Console. (Click Start | Run and type “mmc”, then press Enter.)
2. From the Console menu, click Add/Remove Snap-Ins.
3. Click Add.
4. Select Security Configuration Editor.
5. Click OK.

Security Configuration Areas are subdivisions of system-wide security configurations. Table 1 shows the currently defined areas.

SCE was developed to support additional elements. Because configuration information is stored in a standard .INF file format, it can easily be modified by those who understand this format. For instance, software vendors who write services can extend the “system services” component to include their own. Security can thus be configured on an ISV’s service, and the ISV can be sure that any analysis performed will included its own service.

A Simple Interface

The SCE’s Explorer-like user interface is simple to navigate (see Figure 1).

Figure 1. The Security Configuration Editor. The left pane holds configuration and inspection folders; the right pane shows objects to be kept secure or actual attributes of an object’s security configuration.

The left pane includes top-level folders for Configuration/Inspection Templates and Last Configuration/Inspection.

You can expand these folders to show greater detail on each template and security area. The right pane exposes the objects , and when you view an analysis, it also exposes departures from the security policy.

Context menus are available to perform configuration assignment; security analysis; and for identification of and making changes to objects, rights, privileges, and services.

The SCE includes sample templates for defining your security policy. You can modify the existing templates or, as I’ve mentioned, define your own (through the .INF files). You can make Security Configuration Area settings on your domain by selecting a template in the tree view under “Configuration /Inspection Templates” and then right-clicking on the template and selecting “Assign Configuration” from the context menu.

When you’ve selected and assigned a template, its security configuration becomes the security configuration for the local machines as well as for some parts of the domain (system services and restricted groups). For example, members of the Administrators group who aren’t identified in the policy are removed from the Administrators group and logged to the configuration log.

Changing template configurations to get the policy that is right for you is as simple as pointing and clicking. Double-clicking on an object exposes dialog boxes that allow you to view and edit the current configuration. Most boxes appear to be exact replicas of the more familiar tools such as “Add Users and Groups” or easily discernable variations like “Maximum Password Age.” If you’re already familiar with current configuration tools, you’ll have no trouble with SCE’s interface.

Security Analysis

To analyze security, right-click on the Last Configuration/ Inspection and Click Perform Analysis. A pop-up window tracks your progress. When the analysis is complete, you can view the results in both a log (see Figure 2) and by traversing the “Last Configuration/Analysis” branch.

Figure 2. A fragment of the text log for an analysis of user rights.

Another nice feature that SCE provides is an Analysis Viewer that shows each template recommendation next to current settings. It also highlights problem areas with different fonts and colors. You can correct problems in the view by changing the recommended settings. If you do correct problems in this way and then select the “reconfiguration” option, the correction will be made to the object. The Analysis Viewer is more than a way to “view” problems. Problems can be fixed without leaving the viewer.

Not All Is Perfect…

Hold on, though. SCE isn’t necessarily the final solution. Imagine this scenario. Administrator A gets tired of repeated demands from User1 for more permission on the system, so she makes User1 a member of the Administrators group. Administrator B, who is the Auditor, runs a security analysis and discovers that this unknown Administrator, User1, exists. Administrator B removes this administrator from the Administrators group and makes a note to chastise Administrator A. Meanwhile User1 can’t install the latest whiz-bang utility and hollers at Administrator A, who puts him back in the Administrators group. You can only imagine the NT Administrator privilege war that would develop as each Administrator tries to gain control. The bottom line: If authority is distributed, maybe you shouldn’t install SCE.

Along with ease of implementation and administration in NT, there’s definitely a need for policy control and maintenance. In environments where authority is distributed, SCE shouldn’t be installed—or contentious issues should be excluded from analysis (unless you’ve already resolved them).

The Master at Managing Security

Is Service Pack 4 really a Security Pack 4? In some ways, yes. It has many elements that you can use to improve Windows NT 4.0 security. Can is the key word here. Bug fixes, security editors, and analyzers won’t work if you don’t know how to use them. Will Service Pack 4 solve all your problems? Nope. Will it create some new ones? No doubt. Do I recommend installing it? You bet! It takes the pain out of downloading, understanding, and applying numerous hot fixes, and it has created an answer to one of my most compelling annoyances: managing security in NT. SCE centralizes many of the more meddlesome aspects of security maintenance and shows promise of more to come.