Security Advisor
Domain Controller Lockdown
Implement Group Policy to automate the process of locking down domain controllers.
- By Roberta Bragg
- 11/01/2002
Yesterday I watched as a man struggled up a ladder with one end of a
400-pound steel beam balanced on his shoulder. At first he steadied it
with cloth-gloved hands. A cigarette hung out one side of his mouth. A
buddy held the other end on scaffolding 12 feet up. Another gave virtual
assistance from the foot of the ladder. It wasn’t a cakewalk. One step,
pause, make slight adjustments. Then start another step. Stop. Remove
the gloves. (How he did this without dropping the beam or crushing something
vital in his body, I don’t know.) He gathered himself like a lion getting
ready to attack. Then he stopped, removed the butt from his mouth, gathered
himself again and proceeded step by step up the ladder. When he jiggled
the beam into a waiting holder at the top, the ladder, now unburdened,
literally grew a couple of inches taller. The man—I’ll call him Joe—then
casually backed down the ladder and lit up another smoke.
Me, I turned off the cell phone. I’d been standing there with 9-1-1 keyed
in just in case, and I didn’t take my eyes off him. I felt as if I’d just
witnessed someone lifting a load for which ordinary human bodies weren’t
built. To Joe, as I found out when I chatted with him later, it was just
one more beam out of more yet to do today, perhaps more for tomorrow.
Doing the Heavy Lifting
Sounds like the job you do keeping your networks running and secure.
Sometimes it takes all your energy, wit and understanding. Make no mistake:
You’re performing feats for which no human was built, but to you it’s
all in a day’s work. Then again, like Joe, you could choose to use powerful
tools to assist you with the manual labor. Here’s where Group Policy,
planning and security templates come in.
Over the last two months, I’ve reviewed baseline server security and
incremental server security as outlined in Microsoft’s Security Operations
Guide. Now it’s time to put it all together by examining domain controller
baseline security and implementing Group Policy to automate the lockdown
process.
Security
Templates |
A full list of enabled and disabled services
for the baseline.inf template can be found online, in
the September 2002 “Security
Advisor” column. |
|
|
Keeping my promise to you, I’ve implemented these practices on my company
network. For my domain controller security upgrade, I decided that only
a new DC would do. I took down the second DC in my current domain, scrubbed
the hard drive and loaded Windows 2000 Server anew. I did this with the
box connected to a test network, one in which the machine exists by itself.
Meanwhile, the other DC—the forest root—is chugging along and servicing
my current crew.
The new DC will become the new forest root. Once it’s up and running,
I’ll move user accounts and have all other servers and workstations removed
from the old domain and rejoin the new one. Then the old root can be scrubbed
and rebuilt as the second DC in my small domain. This method of abandoning
the old and putting in the new was an easier choice for me, but it may
not be possible for you. If not, you can still use the template I’m implementing
and vastly improve your system’s security and ease management chores related
to it. As always, you’ll need to test this prescription to make sure there
are no conflicts with the applications and users you may have on your
network.
Security Cookie Cutter: the BaseLineDC Template
The BaselineDC.inf template applies a higher level of security
to Win2K DCs. To implement it, use Group Policy:
- Open the Group Policy Object (GPO) for DCs (right-click on the DC
OU in Active Directory Users and Computers and chose Properties, then
Group Policy).
- Select the Default DC’s Policy and click the Edit button.
- Navigate to Computer Configuration | Windows Settings | Security
Settings.
- Right-click on Security Settings and select Import Policy.
- Browse to the location of the BaselineDC.inf template and select
it.
- Click OK to close.
Before you use it, however, examine it closely. It’s possible that settings
in this template will damage your DC’s functionality. On the other hand,
modifying the template may allow you to achieve the proper balance of
security and functionality for your DC.
It’s worth reviewing the first article in this series, which appeared
in September, for general settings for audit policy, security options
and restricted groups. There are no changes between the settings for the
baseline.inf template, meant for Win2K servers, and those meant for Win2K
DCs. Registry ACLs are likewise not changed in the template. File ACLs
are set, but are less substantive than in the baseline template. These
changes modify permissions on key commands restricting their access to
the Administrators group. You should note, though, that both Registry
and File Access control permissions are set during Dcpromo. The permission
settings on files, folders and registry keys are different for DCs than
servers, but there’s no need to detail them in the template, as they’re
already set.
As in the baseline.inf template, most services are disabled, making the
enabled picture far different than a standard implementation. A few additional
services are necessary for a DC, so those are added to the enabled list.
Table 1 lists the enabled services in the BaselineDC.inf template. An
asterisk (*) denotes services enabled in the template for DCs, but not
servers.
Table 1. Enabled
Services for DCs Manual Auto |
COM_ Event System |
X |
|
DFS* |
|
X |
DHCP Client |
|
X |
Distributed Link Tracking Client |
|
X |
DNS Server* |
|
X |
DNS Client |
|
X |
Event Log |
|
X |
Kerberos Distribution Center* |
|
X |
Logical Disk Manager |
X |
|
Logical Disk Manager Administrator |
|
X |
Net Logon |
|
X |
*NTLM Security Support Provider |
|
X |
*NTFRS (file replication service) |
|
X |
Network Connections |
X |
|
Performance Logs and Alerts |
X |
|
Plug and Play |
|
X |
Protected Storage |
|
X |
Remote Procedure Call (RPC) |
|
X |
*Remote Procedure Call (RPC)
locator |
|
X |
Remote Registry Service |
|
X |
Security Accounts Manager |
|
X |
Server |
|
X |
System Event Notification |
|
X |
TCP/IP Net BIOS Helper Service |
|
X |
Windows Management Instrumentation Driver Extensions
|
X |
|
Windows Time |
|
X |
Workstation
|
|
X |
*=Services enabled in the template for DCs and disabled
for the server template.
|
|
|
Templates Aren’t a Cure-All
Using security templates and Group Policy can take you a long way
toward achieving the goals for a secure Win2K network. However, they can’t
do everything for you. The Security Operations Guide realizes this and
makes suggestions for other security tasks. There are two areas of focus.
First are the numerous nontechnical policy issues (risk analysis, intrusion
detection, patching policy and so on) to deal with. Their scope is wide
and broad, and I couldn’t do them justice even if I had this entire magazine
to myself. Second are chores related to preparing your network for template
application, which I will tackle. Be warned, though: If you don’t deal
with the non-technical issues first, your security policy and practices
will be weak and could negate any template usage benefits.
1. Pre-check that Domain Services are in Working Order
Group Policy is dependent on proper replication, time synch and
DNS. Before setting up Group Policy, do yourself a favor and determine
that these systems are working. The tools indicated below can be found
in the Support Tools directory of the Win2K Server installation CD-ROM:
- Verify DNS—Use dcdiag /v and netdiag /v on DCs and netdiag
/v and nslookup on servers to determine proper DNS function.
- Verify replication—Use repladmin to force replication and
provide a status report on its success.
- Verify time synch—Compare times at servers and DCs. Look for
W32 time errors and Kerberos errors in the event log. Remember: The
PDC emulator in the forest root domain is the only Win2K Server in the
domain that needs synchronization with an outside source.
2. Set Domain Password Policy and Account Policy
The template doesn’t set Password and Account Policy, similar to
the baseline server template. Maybe Microsoft envisioned you recklessly
instituting the baseline without a review and, suddenly, thousands of
your users would be faced with locked-out accounts and requests to modify
their 10-year-old password.
The SOG does, however, make recommendations on how the Password and Account
Lockout and Kerberos Policy should be set. Those settings were discussed
in October’s article. These settings, or those preferred for your organization,
shouldn’t be set in the BaselineDC.inf template. Instead, they should
be set in the default domain policy or placed in a new GPO and linked
to the domain. I know it’s confusing, but that’s the way Group Policy
works for these components. A DC is set to read the password policy and
account policy for domain accounts from the GPO linked to the domain,
not the GPO linked to the DC OU. Microsoft says this is because a DC could
(could, not should, mind you) be moved from the DC OU; therefore, these
components must be set in a GPO set at the domain level. Knowledge Base
article Q259576, “Group Policy Application Rules for DCs,” delineates
this rule and also indicates that three security options are also read
by DCs from the domain level GPO:
- Automatically log off users when logon time expires.
- Rename administrator account.
- Rename guest account.
3. Prepare to Use Templates
- Security templates aren’t replicated! Centrally locate them to avoid
version-control problems. I also suggest you keep an original copy of
your templates in a safe place. You can then audit the templates online,
against this original copy.
- Don’t forget to determine the appropriate templates for other systems
and apply these templates to the GPO linked at the appropriate OU.
- Set permissions to prevent modification of GPOs and their links.
Make a limited number of administrators capable of managing and modifying
GPOs. Create special groups that give power, for instance, to some admins
to modify GPOs for IIS servers and give power to another group for DC
GPO management. This way, should an attacker get access to one group,
he or she doesn’t automatically get to manage others.
- Don’t allow anyone other than domain-level administrators to remove
or add objects to an OU. If a user can remove a server from an OU, he
can modify the security settings on the server.
- Use the No Override option sparingly, but use it if you must for
critical policies. The No Override option prevents policies applied
later in the process from overriding settings in the higher-level policy.
A
Domain Controller Gotcha |
Sometimes it would be nice to have a magic button on
my desktop—one that would shoot me in the foot occasionally
when I make configuration mistakes on my computer systems.
Applying the principles and procedures outlined in the
guide has gone smoothly, but recently I really messed
up.
Because I’d decided on a complete redo of my DCs, I’d
set aside time to rebuild them. There’s lot of things
that can be done while waiting for the various file
copies and reboots, and this day’s work was no different.
I was a little frustrated that the Compaq setup disk
and Win2K installation process didn’t allow me to strip
some of the installation options. It even installed
IIS and SNMP by default (drat those Compaq management
tools—forgot about them). It did allow me to customize
TCP/IP, though, and removing the excess baggage after
installation wasn’t a problem; just more work. Next
time I’ll be more careful. I know better than to trust
these third-party installation “helpers”—they’re fine
if you want the tools, but there are costs involved.
Somehow, I just can’t imagine running IIS on my DC just
so I can use a third-party tool. Thanks, but no thanks.
Complaints aside, I had her stripped back down to normal
in less time than a reinstall. Dcpromo went smoothly.
Before applying the template though, I checked DNS.
Everything seemed OK. Opening up Group Policy, however,
was a bust. Win2K politely informed me that I didn’t
have permission! In the systems event log I found the
following errors:
- Event ID 1000 and 10001 (about every five minutes).
- “Group Policy client-side extension security has
passed flags (17) and returned an error status code
of (3).”
- “Security Policy cannot be propagated.”
A quick search of TechNet (Q271213)
supplied me with some believable reasons. Either replication
wasn’t occurring for some reason, DNS wasn’t working
or the GPO was corrupt. Instructions for correcting
these issues seemed a little extreme. It also seemed
a little harsh that a brand-new install, single DC,
single domain in the forest would be popping errors
of this nature.
Then it hit me: File and Print Services. I have a little
pattern I follow on new Server and Professional installs.
I don’t install or remove extraneous things. I disable
File and Printer Sharing for Microsoft Networks and
disable NetBIOS over TCP/IP. NetBIOS over TCP/IP isn’t
necessary in my network, and few servers are used for
file and print. But (I can see some of you grinning)
DCs must have File and Printer Sharing enabled. The
SYSVOL share must be present and accessible (even a
single DC accesses its own SYSVOL share to read its
Group Policies).
So, deeply chagrined, I turned File and Printer Sharing
on. Hurrah! Group Policy could now be set. Later, I
also found Q258296,
which explicitly identifies the File and Printer Sharing
issue and how it can even affect multi-homed machines
on which only one NIC has File and Printer Sharing disabled.
Sigh.
—Roberta Bragg
|
|
|
4. Apply Group Policy
Changing baseline settings and copying the template to a DC have
no effect. You must apply the baseline using secedit or security configuration
and analysis or use Group Policy. Since you want to apply the settings
to all DCs, use Group Policy. (Don’t forget to use Group Policy to apply
the other templates you’ve examined, specifically tested and modified
for other servers in your domains.) To use Group Policy, you must import
the template into the security settings portion of the appropriate GPO.
While you need do nothing more, if you want to speed up its application,
you’ll need to force replication and policy refresh. To force replication:
- Open Active Directory Sites and Services.
- Expand Sites, then the site name, then servers.
- Expand each server.
- Right-click on its NTDS settings.
- Choose replicate now.
- Repeat for each server.
To force policy refresh, use the secedit command on each server.
5. Verify Settings Are Being Applied
Two options are possible. First, use the secedit analyze (secedit
/analyze /db secedit.sdb /cfg ) command or security configuration
and analysis to compare the current policy settings on the computer to
the policy settings in the template. Second, open the Local Security Policy
console on the computer and compare the effective settings column to that
in the template.
You should also review Event Log messages. When the policy is applied,
message 1704, with a sourceID of SceCli and a message, “Security policy
in the Group Policy objects are applied successfully,” will be written.
Alternatively, if Group Policy can’t be applied, you may find other events
generated.
6. Keep Up with Changes
No matter what, there will be changes. In order to make them smoothly,
make them to the original templates, test them, and then re-import the
templates into the GPO. There’s no automatic way to do this. Just remember:
If you make changes to security settings directly in the GPO, they take
effect without testing. You also lose your ability to verify them using
secedit and have no template to use in other domains.
Help with the Heavy Lifting
Like Joe, you’ve got a tremendous load to lift. It does take a lot of
oomph sometimes to put security practice into place; just when you get
it jiggled together, you realize there’s another beam waiting to be hauled
up the ladder. Me? I’m that virtual assistant on the ground. Ready with
a little steadying and approval as you start, there to pick up your butts
and take care of your gloves as you ascend, and all smiles and kudos when
you’ve got the job done.