Marble Drop

Securing your servers by using templates isn't child's play. In her second installment on this topic, Roberta finds a parallel to a game.

• By Roberta Bragg
• October 01, 2002

I used to play Marble Drop a lot. In this game, the object is to figure out how to get several colored marbles into the right holes through a series of slides, flippers, loop-de-loops and other Rube Goldberg-esque contraptions. Like these contraptions, Marble Drop isn’t a Pinball-type game. Once you release or “drop” the marble, it’s on its own. You simply watch as it makes its way through the course. The only way to win the game is to try to figure out, according to the diagram presented, what might happen if you started the marble at one of several entry points. Then, each time you drop a marble, you watch where it goes to see if you’re right and correct your plan for the next time. Did I mention that each time a marble goes down a path, the path changes?

Start Simple
Designing security policies is like figuring out the Marble Drop game, except instead of marbles in the right hole, you want the right configuration applied to a specific computer or user. To do so in the most efficient manner, you may end up creating many levels of policies. Because each policy can have hundreds of configurations and several levels may affect any one machine, the possibilities for conflicts and not getting what you expect are endless. The right way to approach it is similar for success in Marble Drop: Start with a simple structure and work on one policy. When you’ve reached success with that, go on to the next one, and so on.

This is how we’ll approach the implementation of security policies in our network. For those of you who missed the introduction last month, we’re implementing the Microsoft Security Operations Guide (SOG),
http:// microsoft.com/technet/treeview/default.asp?url=/technet/security/ prodtech/windows/windows2000/staysecure/, on a test network in preparation for rolling it out in a production one. If you want, I’d love for you to join me in this little experiment. Just go online, get last month’s column at http://mcpmag.com/security/, get started on your test network, then follow along here.

The SOG provides a comprehensive list of steps to securing your network, along with some customized templates and strategies. Last month I described in detail the philosophy of the guide and implemented the baseline policy on a single Windows 2000 server. The next step is to figure out how to make Win2K automate the process. Even in a small network, it’s incredibly tedious to implement a policy on many machines one at a time. If we’re going to develop incremental templates for different computer roles, we’d better find a different technique. Many of you know where I’m going here: Group policy is the way to automate the application of security policy. We can create the separate templates for computer roles as described by the SOG, import them into policies at a central location and distribute them across our network—without ever visiting another machine.

The Domino Effect
Sometimes I could kick myself for making the stupid mistakes that I do. Then I realize that without stupid mistakes, much learning is lost. Take the next step in my network makeover project. The obvious thing to do is to bring up the domain controller and implement an Organizational Unit (OU) and group policy infrastructure. As I complete the configuration for each new computer role, I can snap it into place and be ready to stamp every similar computer with these ultimate hardening rules.

Here’s where I goofed. In my mind I knew that the provided domain controller template is a separate but equal template. That is, the BaselineDC.inf template is meant for domain controllers, and the baseline.inf template is the baseline for all other servers. Also in my mind, I had thoughts of changing the setup files so that all Win2K servers came up hardened with the baseline template. It’s not a bad idea. The problem is that, in my exuberance, I then took a baseline template-hardened file server and promoted it to a domain controller. That means using Dcpromo.

If you’ve familiarized yourself with the severe restrictions of the baseline template and understand what Dcpromo does, you’ll understand the errors I managed to generate.

The first error was a warning that Dcpromo couldn’t proceed because the File Replication Service couldn’t be started. Naturally, this service is disabled by the baseline template. Changing the service from disabled to Manual solves that problem, allowing Dcpromo to proceed and install Active Directory, secure system files and so on. However, another problem occurred. In the baseline template, the DNS service is disabled, as is a service upon which DNS is dependent. If Dcpromo attempts to add the service on the local computer, DNS can’t start. (In my simple network, I elected to run DNS on the domain controller). Fortunately, because this error doesn’t prevent Dcpromo from continuing, the DNS service can be installed afterward.

After Dcpromo finished its work, a quick check of the error messages showed that the problem service was the NTLM Security Support Provider service. Changing its configuration to Manual in the services applet prepared the system for DNS. At this point, a manual start of the DNS service was necessary. Next, because DNS failed to start, Dcpromo couldn’t create this new domain’s zone or enter the appropriate records. To fix this, I manually created the zone, then used the command Ipconfig/registerdns to generate the correct DNS records for an AD domain.

Checking the event log again revealed DCOM errors related to the Windows Management Instrumentation service. Starting this service stops the errors. More on this in the discussion to come on the baseline DC template.

At this point it was tempting to continue troubleshooting and use this domain controller in the network. Though that might have been instructive, I elected not to. Don’t repeat my error; the baseline template isn’t for domain controllers.

Configuration Changes for File and Print Servers Our baseline template locks down the server. Incremental templates serve two roles. First, they may relax security so an application can run. Second, the application may add new security challenges that a template could participate in managing. For file and print servers, our template merely relaxes security. Additional security for the file and/or print server can be added by using NTFS DACLs to secure the files. Because each file server is normally unique, the proper place for the new DACLs is in the file system, not the template. The File and Print Incremental.inf template makes the following changes: Sets Print Spooler service to automatic. This service is necessary if this server will be a print server. Sets Server Service to automatic. The server service is necessary to share folders Changes the Registry Key HKLM\CurrentControlSet\LanManWorkstation\Require SecuritySignature to 0. This removes the requirement created by the baseline template for SMB signing, thus improving performance and allowing communication with systems not configured for SMB signing.

Preparing the OU Structure
OK, so in my case I started over. Not wanting a “tainted” machine for a domain controller, I wiped the box and reinstalled Win2K. You might have opted to leave well enough alone; after all, I did get the domain controller running and everything seemed fine. However, I didn’t want some future problem to crop up or some security flaw or benefit to be the result of my misadventure. I’d never know for sure if what I’d done had caused the system to act or react the way it did. At any rate, that’s the benefit of doing things on a test network first. You can start over; you don’t have to live with your mistakes or take the network down to recover from them.

I’m going to skip, for now, a discussion of what the baselineDC.inf template does and where to put account policies. Instead, I want to configure and test my OUs and GPOs. Remember that our current implementation is the application of security for servers; strategies for workstations and users will be considered at a future time. While your design may differ, here’s one that fits the strategy proposed in the SOG.

Your first consideration should be the ultimate result that will be applied to the computer(s). In my case, it’s been established that I will have file and print servers, Exchange, SQL and an IIS intranet server. I have a baseline template for all servers, except domain controllers, and accept the basic principle of using incremental templates for other servers. This means I want the baseline policy applied first, then the incremental. To do this I create a Servers OU and multiple child OUs underneath it. Each server can then be placed in the appropriate OU.

Table 1 pairs the templates with the OUs and proper servers. At this point, all user accounts are created in the Users container until a formal hardening strategy for user accounts is developed. Also absent is an OU to handle workstations. Our simple server strategy, like initial attempts at Marble Drop, allows us to keep a lid on the complexity and be successful right out of the chute. Instead of developing a complex OU design that may be difficult to troubleshoot, I’ve opted for the step-by-step approach. Going forward we can build on this knowledge.

Table 1. Server Organizational Units and their associated templates.

OU Template Servers Servers Baseline.inf None FilenPrint File and Print Incremental.inf Print servers, file servers Web IIS Incremental.inf IIS server Infrastruct Infrastructure Incremental.inf DHCP servers, WINS servers SQL Yet to be created SQL Incremental.inf Microsoft SQL database servers Mail Yet to be created Exchange Incremental.inf Microsoft Exchange servers

Incremental Success
After the OUs have been created, it’s time to test the design. First I’ve got to add a server domain and place its computer account in the FilenPrint OU and import my security templates into a group policy for each OU. I’ll add templates to the other OUs at a later date. To examine the incremental template for file and print servers see, “Changing Configuration for File and Print.” After adding the computer account, I copy my templates to the WINNT\Security\templates folder on the domain controller. This makes them available for use in my group policy configuration. The process:

1. Right-click on the Servers OU in Active Directory Users and Computers and select Properties.
2. On the properties page, select the Group Policy Tab.
3. Because no default polices are created for OUs, the first step is to create one. Click the New button, enter a name for the policy and click OK.
4. Back on the Group Policy page of the OU Properties, click the Edit button to display the default GPO.
5. To import the baseline.inf, click on the plus sign next to Windows Settings, then on the one next to Security Settings. Right-click Security Settings and select Import Policy.
6. In the Import Policy From window, select the baseline.inf policy and click Open.
7. Close the window to close the policy.
8. Click the Close button to close the OU property pages.
9. Repeat the process for the FilenPrint OU, adding the File and Print Incremental.inf template.