Domain Controller Lockdown

Implement Group Policy to automate the process of locking down domain controllers.

• By Roberta Bragg
• November 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:

1. 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).
2. Select the Default DC’s Policy and click the Edit button.
3. Navigate to Computer Configuration | Windows Settings | Security Settings.
4. Right-click on Security Settings and select Import Policy.
5. Browse to the location of the BaselineDC.inf template and select it.
6. 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:

1. Open Active Directory Sites and Services.
2. Expand Sites, then the site name, then servers.
3. Expand each server.
4. Right-click on its NTDS settings.
5. Choose replicate now.
6. 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