Secure the WIN 2003 domain controller

A domain controller, like its name, has administrative permissions on the entire Windows domain and on all computers in the domain. So you have to spend more effort to secure the domain controller and keep it safe. This article will take you through some of the security measures that should be deployed on domain controllers.

Physical security of domain controllers

The first (and often overlooked) step is to protect the physical security of your domain controllers. In other words, you should put the server in a locked room, and strictly audit and record the visit of the room. Instead of having a "safe to hide" view, it is wrong to assume that such a critical server in a remote place without any protection can withstand the attacks of stubborn data spies and insurgents.

Because the police who specialize in crime prevention research tell us that we are not able to make our own homes, companies, cars and of course include our servers with absolute security. Security measures do not guarantee that your valuables will not be taken by the "bad guys", it will only increase their difficulty and difficulty in obtaining valuable items. If you can make their attack process last longer, they will give up the attack or stop trying, and even the possibility of catching them on the spot will be greatly increased.

After physical security, you should deploy a multi-tiered defense plan. A locked server is just the first tier. This can only be considered peripheral security, like a fence around your yard or a lock on your house door. In the event that perimeter security is breached, additional security measures should be put in place to protect them (at this point, DC). You may install a security alert system to notify you or the police when your fence or door lock is damaged. Similarly, you should consider deploying an alert system between servers that emits sound alerts when unauthorized users (who do not know the password to unlock the alert system) enter the server room. Also consider installing detectors on doors and infrared detectors to prevent illegal entry through doors, windows, and other holes (we strongly recommend reducing the number of doors, windows, and holes as much as possible).

When you deploy your multi-tier security plan from the inside out, you should ask yourself a question repeatedly, "What if this security measure fails?" What new hurdles can we deploy on the intruder's attack line? "Just as you put your money and jewellery in a fenced, locked, alarm-system-protected room, you should also consider the security of the server itself." Here are some guidelines:

Remove all Removable storage device drives, such as floppy drive, optical drive, external hard drive, Zip drive, flash drive, and so on. This will increase the difficulty for intruders to upload programs (such as viruses) to the server or download data. If you do not use these devices, you can also remove the ports that these external devices need to use (shutdown from the BIOS or physical removal). These ports include USB/IEEE 1394, serial port, and port, SCSI interface and so on.

Lock the chassis to prevent unauthorized users from stealing hard drives or damaging machine components.

The server is placed in a closed-lock server rack (to ensure good ventilation), and the power device is best set in the server rack. In order to avoid the intruder can easily cut off the power or ups to interfere with the system's power supply.

Preventing remote intrusion of domain controllers

If you think your physical security plan is perfect enough, you need to shift your focus to prevent hackers, hackers, and attackers from accessing your domain controllers over the network. Of course, the "best" approach is to disconnect the domain controller from the network, but the domain controller is useless. Therefore, you have to take steps to reinforce them to withstand the usual attack methods.

Secure the domain account

The simplest (for hackers), the most unexpected, and most commonly used method is through a legitimate account password, login system, to obtain network and domain controller access rights.

In a typical installation, hackers want to log on to the system, only need two things: a legitimate account, and its corresponding password. If you are still using the default Administrator account--administrator, this will make the hacker's intrusion much easier. All he had to do was collect some information. Unlike other accounts, this default administrator account will not be locked for multiple failed landings. This means that hackers just keep guessing the password (through the "brute force" method to crack the password) until he gets administrator privileges.

That's why the first thing you should do is rename the system's built-in account. Of course, it doesn't make sense to forget to change the default description ("Computer/Domain built-in Admin account") if you just renamed it. So you want to avoid intruders who quickly find an account with administrator privileges. Of course, keep in mind that all you do is slow down intruders. A firm, capable hacker can circumvent your security measures (for example, the SID of an administrator account cannot be changed, and it usually ends with a 500.) Some hackers can use the tool SID number to identify the administrator's account.

In Windows Server 2003, it is possible to completely disable the built-in Administrator account. Of course, if you want to do that, you must first create another account and give it administrator permissions. Otherwise, you will find yourself unable to perform certain privileged tasks yourself. Of course, the built-in Guest account should be banned (this is the default). If some users need permission from a guest, create a new account with a name that is less visible and restrict access to it.

All the accounts, especially the admin account, should have a strong password. A strong password should contain more than 8 characters, numbers, and symbols that should be mixed in size and should not be words in the dictionary. Users must be careful not to write down their passwords or to tell others (social engineering is also a common way to gain unauthorized access). You can also use Group Policy to enforce requirements for passwords to change on a certain basis.

REDIRECT Active Directory database

The database of the Active Directory contains a large amount of core information, which is the part that should be properly protected. One approach is to move these files from the default location known to the attacker (on the system volume) to another location. For more in-depth protection, consider moving the ad database file to a redundant or mirrored volume so that you can recover it if the disk fails.

The database files for the Active Directory include: Ntds.dit;edb.log;temp.edb

Note: Moving the database files of the Active Directory to a physical hard disk that is different from the system volume can also improve the system performance of DCs.

You can transfer the database and log files of the Active Directory by NTDSUTIL.EXE This tool by following these steps:

1. Restart the domain controller.

2. Press the F8 key at startup to access the Advanced Options menu.

3. Select Directory Service Recovery mode from the menu.

4. If you have more than one Windows Server 2003, select the correct one and press ENTER to continue.

5. At the login prompt, use the user password for the Active Directory recovery account specified when you upgraded the server.

6. Click Start | Run, enter CMD, and run the command prompt line.

7. In the command prompt line, enter NTDSUTIL.EXE and execute.

8. In the prompt line of Ntdsutil, enter files.

9. Select the database or log file that you want to move, and then enter the moved DB to or moves LOGS to.

10. Enter two times quit, exit Ntdsutil, return to the command prompt line, and close the command prompt line window.

11. Restart the domain controller again to enter Windows Server 2003 in normal mode.