If you do a quick search of the TechRepublic Web site or of the Web for that matter, you will find that there are countless articles regarding Active Directory security. Even so, I have noticed that there seems to be at least one aspect of Active Directory security that is consistently overlooked: domain controller deployment. I'll explain why it is important to deploy your domain controllers as securely as possible and give you some tips on how to secure your domain controller deployments.
Before I begin
Before I get started, I want to pause for a quick reality check. As you read some of my tips later in this article, you might question my mental health and assume that I am an extremely paranoid individual. I will be the first to admit that these techniques are not for everyone. I have worked in a broad enough variety of environments to know that different organizations have different security needs.
For example, at one point in my career, I was in charge of computer security for Fort Knox. Obviously, in that environment there is no such thing as too much security. At the same time though, I have also worked as a network administrator in a small office with about 20 employees. On my first day, the president of the company told me in no uncertain terms that he wanted to maintain a very insecure computing environment. In his way of thinking, high security was bad for employee morale and that if he could not trust his employees then they had no business working for him. He also explained that he wanted to make sure that other people were able to access the system should I get hit by a bus or something.
My point is that different organizations have different security needs. The techniques that I am about to show you will be ideally suited to some organizations, but will be overkill for others. It’s up to you to decide which if any of these techniques should be applied to your own organization.
Domain controller deployment
Okay, now that I’ve gotten my disclaimer out of the way, let’s talk about domain controller deployment. Assuming that your network has relatively good security in place, your network is seldom more vulnerable to attack than it is while you are in the process of deploying a new domain controller. There are quite a few different reasons for this. One of the primary reasons is simply because of how long it takes to install Windows.
Let’s face it, installing Windows takes forever to complete. If you’re like me, you probably don’t have time to sit around all afternoon staring at an installation screen. Most of the network administrators that I know usually try to work on something else while waiting for a Windows installation to complete. Often, this other task involves going to another part of the building. During this time, the new server is left unattended.
I can tell you that I myself have been guilty of leaving a new server unattended during installation, even if it’s only long enough for a quick trip to the Coke machine. My rationale was that there is nothing on the server, so it is not vulnerable to compromise.
I was wrong though. This is actually the point at which the server is the most vulnerable to attack. Even if the new server were not connected to the network, some unscrupulous person could have snuck into my office and loaded a malicious service, planted a Trojan, or cracked the administrative password.
Fortunately, I was never the victim of such an attack, but it would have been easy for someone to compromise the new installation. The reason is because a new installation, especially Windows Server 2003, is almost completely unprotected. There are no hot fixes or service packs, there is no antivirus protection, and unnecessary services may still be running on the server.
It might therefore seem as though lesson number one would be not to turn your back on a new server during the installation process. This would be ideal, but it isn’t realistic to assume that you will be able to babysit a new server all afternoon. There is almost always some kind of interruption. Interruptions come in the form of last minute staff meetings, fire drills, a quick trip to the restroom, or even going to get a CD out of the closet.
Since you can’t guarantee that you can watch over a server the entire time you are setting it up, there are a few other things that you can do to help improve security. I recommend starting out by automating the installation process. If you automate the installation process then you don’t have to worry about someone slipping into your office and tampering with it.
There are several good ways to automate installation. You could run Setup and use an answer file to automatically answer the Setup questions. Another technique is to use a remote installation server to build up the new server. Still another technique is to load Windows by copying a ghosted hard drive image. Any of these techniques are more secure than a manual installation, assuming that you can guarantee the integrity of the installation media.
Finding a secure location
Another thing that you can do is to use a secure location for setting up the new server. Ideally, it would be nice to have an office with a locking door to which no one else has the key. Server rooms or wiring closets are okay too, but typically other people from the IT or building maintenance staff also have keys to such rooms.
Finding a secure location usually isn’t that difficult if you are setting up the new server in the building that you normally work in. However, if you are setting up the new server at a satellite office, a secure location can be tough to come by. If you have to set up a domain controller for a satellite office, the best thing that you can do from a security standpoint is to perform the setup at your office and then ship the server to the satellite office fully configured.
Sometimes though, this isn’t an option. If you absolutely have to set up a new domain controller at a satellite office and don’t have a secure work area at your disposal, you will have to use a little imagination. In the past, I have resorted to asking the manager of a satellite office if I can use their office for a few hours. My experience has been that managers are usually accommodating if they understand the need for a secure work environment.
Preventing post-installation vulnerabilities
Finding a secure location in which to set up a new domain controller is important, but it is only half of the battle. You also have to worry about preventing post installation vulnerabilities. For example, imagine that you have some unethical individual in your company who would love nothing more than to hack a domain controller.
Now imagine that this person gets word of the fact that you are setting up a new domain controller today. You know nothing of this person’s intentions, but you have taken reasonable precautions to insure that the installation process is secure. You have automated the entire process and have the server sitting behind a locked door to which only you have a key.
Although you have certainly taken some good precautions, the server is far from being safe. The reason is because once the installation process completes, you will have a domain controller on your network that is almost completely unprotected. After all, you have not installed any service packs or hot fixes. The new server does not even have any antivirus software installed at this point.
In all fairness, the server isn’t 100 percent vulnerable. The server is a domain controller, and assuming that it is not the first domain controller in a brand new domain, the domain security policy will help to protect the new domain controller. Don’t get a false sense of security though, because even the best domain security policy will only protect a server if the operating system remains intact. If the operating system is compromised, then the domain security policy can often be circumvented.
My point is that you never want to put yourself in a situation in which a server with a default Windows installation is sitting on your network just waiting to be attacked. Even if you cared nothing about that server’s security, if the server were compromised, it could be used as a staging point from which to launch attacks against other servers on the network.
Fortunately, you don’t have to put yourself into such a vulnerable position. The installation process can be kept secure if you follow a few simple guidelines. The first guideline is that you shouldn’t connect the server to the network until you absolutely have to.
One of the nice things about Windows 2000 Server and Windows Server 2003 is that you are not locked into configuring the server as a domain controller or as a member server. You can change the server’s role at any time. Since the server is vulnerable to attack from the time that you finish installing Windows until the time that you complete the server’s security configuration, does it really make sense to initially configure the server to be a domain controller?
Even if only for a short period of time, it’s an extraordinarily bad idea to have an insecure server acting as a domain controller. Therefore, I recommend setting all new servers up as stand-alone servers, even if they will eventually serve as member servers or as domain controllers. Why stand-alone servers?
If you were to initially configure your new servers as member servers, the servers would have to join a domain. Even if the new server is not yet functioning as a domain controller, you still do not want an insecure server to be involved with an otherwise secure domain. If you set up a new server as a stand-alone server, you can get away with not even plugging the server into a network jack until you know that the server is secure.
So, the plan so far is to put the new server behind a locked door, automate setup to configure the new machine as a stand-alone server, and not to plug the machine into the network until it is secure enough to be promoted to domain controller status. That’s a good plan, but there are still other things that you can do to make the installation process even more secure.
Typically, after installing Windows one of the first things that you would do would be to install the latest service pack and hot fixes. If you know that this will need to be done, why not include it as a part of the installation process? There is a technique called slipstreaming that allows you to apply service packs and hot fixes during the initial Windows installation.
Slipstreaming a service pack is easy to do. Begin by copying the Windows installation files to a folder on your network (or on a local hard disk if you are worried about security). Next, create an empty folder on the hard disk and copy the service pack to that folder. Now, open a Command Prompt window, navigate to the service pack folder, and enter the service pack’s file name with the –X switch.
The service pack setup program will now ask you for the path to which you would like to extract the service pack files. Enter the name of the current directory and click OK to continue. When you do, the setup program will extract the files contained within the service pack. The final step is to enter the UPDATE command followed by the /S switch, a colon, and the path to the Windows installation files (UPDATE /S:C:\WIN2003CD). This will update the Windows installation files.
After you have slipstreamed the service pack onto the Windows installation files, there are a few different things that you can do. Usually, at this point, you would create a bootable Windows installation CD containing your slipstreamed files. If you want to even further automate and protect the installation process then you can go so far as to integrate any necessary driver files into your Windows installation files.
So far I have talked about why you should use an automated installation to configure your future domain controller as a stand alone-server. Assuming that you have slipstreamed the latest service packs and hot fixes into the installation files and that you have not connected your server to the network, the server should be safe until you return to finish the setup.
There are a few other things that you will want to do in the interest of setting up a secure domain controller though. Before connecting the server to the network, I recommend going ahead and installing virus and spyware protection. Theoretically, a domain controller should never be used to surf the Internet so there is little chance of the machine becoming infected with spyware, but you can’t be too careful.
After you have installed virus and spyware protection and verified that the latest hot fixes were actually installed, then it’s time to plug the server into the network. Being that the server was initially configured to act as a stand-alone server, you will probably want to join the domain that the server will initially be a domain controller for.
The last step in the procedure is to run DCPROMO to promote the machine to domain controller status. Again though, running DCPROMO can take some time to complete and there is a chance that you could be called away while DCPROMO is running. Although there isn’t a lot that someone could do to exploit a server while DCPROMO is running, I still recommend automating DCPROMO as a precaution. To do so, use the following command:
In the above command, the answerfile.txt file refers to a file that you must create to answer any prompts produced by DCPROMO. A couple of words of caution though: Remember that the answerfile.txt file is a plain text file, so you should not include the administrative password in it. It is safe to include all other answers, but you don’t want the administrator’s password to be plainly viewable to anyone who gains access to the answer file.
That leads me to my next point. As with any answer file, you will want to tightly control access to the disk containing your DCPROMO answer file. There’s nothing confidential on the disk, but you don’t want to give anyone the chance to tamper with the answer file.
Security needn't be difficult
As you can see, one of the keys to good Active Directory security is to insure that the domain controllers are not compromised during installation. By following the several different techniques discussed above, you can ensure the sanctity of new domain controllers.