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
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?
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),
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
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
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
- 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.
|File and Print Incremental.inf
|Print servers, file servers
|DHCP servers, WINS servers
|Yet to be created SQL Incremental.inf
|Microsoft SQL database servers
|Yet to be created Exchange Incremental.inf
|Microsoft Exchange servers
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:
- Right-click on the Servers OU in Active Directory Users and Computers
and select Properties.
- On the properties page, select the Group Policy Tab.
- 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
- Back on the Group Policy page of the OU Properties, click the Edit
button to display the default GPO.
- 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.
- In the Import Policy From window, select the baseline.inf policy
and click Open.
- Close the window to close the policy.
- Click the Close button to close the OU property pages.
- Repeat the process for the FilenPrint OU, adding the File and Print