Security Advisor

Securing Windows 2003 the First Time

There are special considerations when bringing up the first domain controller in the first domain of your new Windows 2003 forest.

• By Roberta Bragg
• 05/01/2003

Many of you are approaching a new first for your network family—the introduction of Windows Server 2003. Why not give this special event the attention it deserves? Do the research. Bring up the server in a safe and secure environment for testing. Bring it up secure and use it to develop a new security paradigm for your network. Because many of you will also be making this new server the first domain controller (DC) in the first domain in a Windows 2003 forest, some special planning and implementation needs to be done. Like your kindly grandmother or, rather, like your interfering mother-in-law, I’ve developed some helpful rules.

The thing to remember when approaching this task is that your work has two purposes. First, you’re modeling the security for all DCs in your organization. Second, you’re beginning the process of modeling the security for all computers within your organization.

These facts should give you pause. The dual nature of your assignment should loom large as you plan and implement the first DC in the first forest in your test network. This section will help you with the primary goal.

Pre-Installation Preparation
1. Secure hardware. Is the location of the test network sufficiently physically secure so that additional security isn’t necessary? Consider adding physical locks and/or establishing smart card or biometric authentication once the system is installed.

2. Configure hardware and BIOS. Remove the floppy drive. (After installation, consider removing the CD ROM.) Reducing the attack surface of systems is always a sound principle. Remove unnecessary physical ports, if possible, or disable them in the BIOS. Ensure that the system isn’t accessible by other machines on the test network unless an installation server is in use. Disconnect the test network from the Internet and add sufficient internal drives so that appropriate installation of components to separate drives is possible. Consider a BIOS password for this computer.

Installation
This list isn’t a step-by-step how-to for installing Windows Server 2003. Rather, it’s a list of points during installation when you must make security choices.

1. Note the license agreement. Significant changes include statements on digital rights management technology (MS DRM) for securing digital content. They imply Microsoft’s right to access this system to update the technology. Any access to the DC from outside your organization should be, at a minimum, scrutinized. Forward the license agreement to your legal team.

2. Rename the system folder. Default names for system folders are known by attackers. While it’s easy to discover which folder is the system folder, many attack scripts are simplistic and hard-code the name of the “Windows” folder. Renaming the folder foils those scripts.

3. Don’t check the box that includes support for East Asian language (unless, of course, you need this in your environment) on this server. I know of no vulnerabilities that this might introduce, but the less code running on the system, the fewer the opportunities for later exploitation.

4. Uncheck “Yes, download updated setup files.” Instead, check “No, skip this step and continue installation.” If you don’t, your system will attempt to access Microsoft across the Internet to locate updated files. What is Microsoft thinking? Any system is vulnerable during installation and shouldn’t be exposed to the Internet.

5. Partition drives and format with NTFS. Period. There’s no reason to use anything else. You can’t secure FAT drives or promote this system to a DC without an NTFS partition.

6. Select a computer name that doesn’t reveal the computer role of this system. Do not, for example, name it “DC1.”

7. Enter a strong password for the Administrator account and write it down. While it’s true that you should memorize passwords and not write them where others may find them, it’s equally true that, during an installation, it’s easy to forget that password. Write it down and keep it safe until you’ve memorized it, changed it, or replaced it with other technology. Note that Windows 2003 tries to help you here, supplying a warning if you attempt to use blank passwords, common words or passwords that don’t meet complexity requirements.

8. Configure custom network settings. All DCs should have static addresses; set them now. Also, set gateway and DNS server addresses. If the first DC will also be a DNS server, point the server to itself. You’ll find error messages in the log until you add the DNS service, but you won’t forget this basic step when you promote the server to a DC. Disable NetBIOS over TCP/IP if no pre-Windows 2000 computer needs to communicate with this server.

9. Install the server in a workgroup and rename the workgroup. You’re just adding a little obscurity.

Server-to-DC Promotion
1. Use some time to examine the environment between installation and the selection of the DC role. There are several steps you can take to lock down the system. While you may want to do these after DC promotion, spend time examining them now, with this first system. Promoting a server to a DC changes some settings and you’ll want to know both the default server and basic DC environments.

2. Note which services are disabled by default and which aren’t. Can you disable additional services without preventing promotion? Which are they? Windows 2003 is an interim OS. While it doesn’t completely fulfill the Trustworthy Computing mandate, it’s a step along the way. One security feature is that many services are disabled by default or, like IIS, not installed at all. A future column will detail what services are used for and what happens when they’re disabled, as well as offer advice on when to disable them.

3. Open the System applet in Control Panel and, on the Update tab, uncheck “Keep my computer up to date” (Figure 1). You should be managing system updates on DCs, if not all systems, in some other manner. You don’t want to risk instability or compromise because you’re unaware of code changes on key systems. Updates need to be tested and don’t need to be downloaded individually to each machine. To do so is an incredible waste of resources and a potential source of instability.

Figure 1. Keep this box unchecked until establishing an update policy. (Click image to view larger version.)

4. Also in the system applet, but on the Remote Access tab, make sure the Remote Assistance and Remote Access check boxes are blank. After setup is complete, configure and secure remote access for administration and use Group Policy to establish a remote access/assistance policy for the domain. For now, you want to ensure that no extraneous access to the system is possible.

Note: You may recall that the ability for an ordinary user to provide remote assistance was first provided in Windows XP. All a user has to do is send out an invitation via e-mail or instant messenger, and another user can remotely connect. With the original user’s permission, this person can make changes to the user’s machine. The issue, of course, is that you want to manage any access to systems. The innocent request for help using remote assistance can open any computer on your network to penetration from less-than-friendly sources. It’s got no place on your first DC of the forest.

5. There’s an improved interface to the Managing Your Server applet (Figure 2). The concept of assigning roles to computers and securing them with attention to their roles isn’t new. What is new are the extensive documentation, step-by-step details and security references available through this interface. In these days of reduced training and travel budgets, you’ve got a whole course of securing your Windows 2003 network right on the desktop. Take advantage of it. Just think of it: If every one of you reads and takes this information to heart, your network will be safer—and so will the entire Internet.

Figure 2. The Manage Your Server GUI contains a host of great security information—use it! (Click image to view larger version.)

6. Start your studies by examining the DC role. Don’t forget to review the “Next Steps” (things you do after you bring up the DC), which outlines many helpful security plans and tasks. Use the “Manage Your Server” applet to apply the server role to the DC. When you select “Domain Controller” as this computer’s role, promotion will include an option to select a DNS server on your network or to install the service on this DC. I recommend the latter option, as you can then secure DNS information as part of your DC strategy.

7. Select an appropriate DNS name for the domain. If policy doesn’t dictate and you’re selecting a domain name that won’t be registered on the Internet, be sure to use the correct format. Don’t use a name that lacks a period, as additional configuration is necessary. You may not only find that this is difficult, but it’ll hamper your attempts to apply domain-wide security. If computers can’t locate and connect to DCs, Group Policy can’t be replicated and security settings won’t be applied.

8. Store the Active Directory database (%system folder%\NTDS) on a different drive than the logs (log\NDS). This will improve performance and make recovery easier.

9. Select compatibility mode as Win2K and higher. If the compatibility with legacy systems mode is selected, security is relaxed on the system; this includes anonymous access to shares.

10. Set a strong Directory Services Restore Mode Administrator password and make it different from the Domain Administrator password. These accounts are different. Only the Directory Services Restore Mode account can be used to restore a System State backup. By giving these accounts different passwords, you can separate duties—always a good security idea. Be sure to write down and store the password in a secure place. The need for it may be long after the person who installs this server has left the company.

Post-Installation
1. Ensure access to a timeserver. By default, the system is pointed to time.windows.com; but after you promote this machine to be the first DC in the root domain, it becomes the time source for all computers in the forest. You should set it to synchronize with a reliable time source.

2. Check DNS. Specifically, look for error messages that registration didn’t occur and check the DNS server for evidence of the proper addition of all entries for this DC. Remember, problems with DNS can mean that carefully constructed security settings are never applied.

3. Review default security settings. For example, note that an Audit policy is set. This is excellent. Figure 3 displays the default settings. Note, however, that items are turned on for success only. You may want to revise these policies to record failure events, too. The default settings are a welcome change!

Figure 3. The default audit settings are a welcome change from those in Windows 2000. (Click image to view larger version.)

4. Disable EFS. By now, you should be aware of the need to educate all users before EFS usage is allowed, as well as establish recovery methods. Window 2003 offers key recovery in addition to file recovery, but both these solutions must be thoroughly understood and require configuration and training. Disable EFS until your policy and solution are in place by unchecking the “Allow Users to Encrypt Files using the Encrypting File System” check box on the Property page of the Public Key Policy in the Security settings of the Default Domain Security Policy.

This is different than the procedure followed for Win2K. Figure 4 shows this dialog box. In the background, you can see the recovery certificate for the domain. There’s no need to remove this certificate to disable EFS. Windows 2003 doesn’t need to have a Recovery Agent certificate to use EFS but one is provided by default, and files encrypted on computers in the domain use this certificate.

Figure 4. Disable EFS until you can develop a strategy and policy that will prevent data loss. (Click image to view larger version.)

5. Examine use of the Everyone group in User Rights. While Windows 2003 doesn’t include the anonymous SID in the Everyone group, you should still refrain from using this group where possible. Be careful! Removing this group without understanding that groups need to be added to provide appropriate access can be disastrous. Consider that Everyone includes the operating system. You don’t want to remove permissions for the operating system.

6. Note the default application of communications security in Security Options. SMB message signing and banning the use of LAN Manager does much to secure network communications between Windows computers but also prevents some legacy systems from communicating at all. Others need configuration to do so.

7. Secure Remote Desktop for Administrators by using Group Policy.

8. Remove the Administrator account from membership in Schema Admins. If modification of the Schema is necessary, it can be added back in. By removing the account now, you make the review of these types of modifications more likely, because no one can simply install an application that will modify the schema by accident.

9. Develop and implement a comprehensive baseline security for DCs.

Afterglow
Congratulations—you did it. You did it right. That’s good. Now do it again—and do it better. Take what you’ve learned and create security baselines for all servers and workstations and for all the roles they’ll play in your network. Then implement and test them. The knowledge gained from your test network can be used as you bring up new production systems, migrate services to them and upgrade old ones.