IT administrators have been working with and around Active Directory since the introduction of the technology in Windows 2000 Server. Windows 2000 Server was released on February 17, 2000 but many administrators began working with Active Directory in late 1999 when it was released to manufacturing (RTM) on December 15, 1999.
There are some good practices to adhere to when deploying DCs. Many of these practices are documented. But not many organizations are implementing these practices.
How to deploy and setup Domain Controller
We will skip over the well-known good practices such as maintaining the Active Directory database on one set of disk spindles, the log files on separate disk spindles, and the operating system on its own set of disk spindles.
Some of the lesser implemented good practices for domain controllers are:
-
Run the Server Core installation of the operating system.
Many administrators avoid change, especially for systems such as AD DS that are incredibly stable. So when a new administrator proposes switching over to the Server Core installation, he is often met with icy stares. But the reality is that most administrators administrate AD DS remotely by launching ADUC or PowerShell on their client or administrative computer. All of the core management tools including the Active Directory Administrative Center (ADAC) and Windows PowerShell work almost identically when used locally on a DC or remotely from a client computer or an administrative computer. Thus, by moving to the Server Core installation, the administrative experience isn’t degraded. And, you gain security enhancements and some small performance enhancements.
-
Do not run other software or services on a DC.
Back in the old days, like 10 years ago, most organizations used physical servers because virtualization was in its infancy. So, when it was time to provision a new file server, DHCP server, or print server, administrators often just tapped an existing server. A DC was often used too. Fast forward to 2015 when virtualization is the de facto standard and automated provisioning helps deliver a new VM in minutes and the old way of doing things isn’t nearly as compelling. Now, when you need a place for a file server, DHCP server, print server, or some other application server, you can provision a new VM. Or, better yet, you can provision a new VM as a utility server. A utility server is a server that hosts all of the applications and services that are too small to warrant a dedicated server. This allows your DCs to stick with a dedicated service which brings more stability.
-
Adjust the startup order and set a BIOS password.
While all of your read-write DCs should be in a secure data center, there are plenty of IT and non-IT people that have access to the data center. For example, the contracted electricians that works on the cooling system have data center access. In addition, there are likely network guys, cabling guys, and IT management with data center access. Anybody that has physical access to a DC can gain access to a physical DC in only a couple of minutes at a console in the data center. There are specialized freeware boot images available that you can use to boot into and reset passwords, install malware, or gain access to the disk data, assuming that the disk isn’t encrypted. To avoid this, perform the following configurations:
- Ensure that all removable media is not part of the BIOS boot order. Instead, only the hard disk where the operating system installed should be part of the boot order. This is true for your virtualization host servers too, if you have virtual DCs.
- Set a strong BIOS password. If you don’t set a BIOS password, somebody can update the boot order, boot to the Windows Server installation media or many freeware toolkits, perform a repair to get to a command prompt. Once at the command prompt, they can wreak some havoc and quickly reset passwords for domain accounts.
- Keep the DCs in a locked cabinet. While a BIOS password is one layer of security, if the attacker is semi-capable, he or she will likely know how to reset the BIOS so that the configuration resets and password is removed. Often, this requires gaining access to the motherboard. You can reduce the risk of such an attack by keeping DCs in a locked cabinet. Some servers also allow for chassis locks. In high security environments, you should opt for both.
-
Standardize the configuration of all domain controllers.
You should try to match the configuration settings for each DC. You can accomplish some of this by using build automation through deployment tools such as System Center Configuration Manager. Items of interest for DCs are the event log size settings to ensure that you have large sizes to capture auditing and security related information, boot settings such as the timeout waiting for OS selection on physical servers, firmware and BIOS versions and settings, and hardware configuration. Of course, there are many other configuration items to standardize by using Group Policy. The primary goal is to configure the DCs identically.
More information about Active Directory basisc you will find in our AD tutorial for begginners.
