Before SQL Server, IIS, or clustering can exist, identity needs to exist. This is where Active Directory Domain Services (AD DS) comes into play.
Now that the boundary of my simulated enterprise datacenter (SED) is protected with PF01, my pfSense firewall, it’s time to implement the backbone by standing up VMs dedicated to ADDS and File Services. Also important, I will implement a file share witness that will be the quorum vote once my SQL cluster is up and operational. This phase focuses on three major parts: (1) deploying DC01, (2) implementing ADDS, and (3) preparing the SED for future clustering.
Why Sequence Matters
Planning the sequence of what services are stood up is just as important as the architecture. ADDS centralizes authorization, authentication, and access policies, allowing the security configuration and access policies to be easily propagated throughout a network. File services operate similarly, offering a centralized location for data stores.
Given this, it makes sense to think of these two services as the foundation of my simulated enterprise datacenter; the other services that will be added later, including SQL Server and IIS, will rely directly on this core backbone for identity and access management. Without this backbone, the entire system is compromised.
Domain Controller Sizing
Sizing the domain controller is another consideration. The contrast between a large and small organization’s computing requirements is significant, and definitions can vary. While a large enterprise with 50K users would likely need to size their domain controller with 8–16 vCPUs, 32–64 GB RAM, and 500 GB–1 TB of SSD storage on a disk array, the needs for a small organization with 5K or fewer users are, in comparison, quite modest (i.e., 2–4 vCPUs, 8–16 GB RAM, and 120–250 GB SSD storage). Of course, a mid-sized organization would lie somewhere in the middle between the extremes.
The resources I dedicated to the domain controller, DC01, in my SED (2 vCPUs, 4 GB RAM, and 60 GB of SSD storage) may seem undersized, but when you consider the use case (i.e., simulation and functionality testing), it is sized appropriately. This is a key lesson in FinOps: only allocate the capacity required for the actual load, even in production environments. Over-provisioning is wasteful, but under-provisioning can lead to system inconsistency or failure.
The ADDS Structure
With DC01 up and operational, the next step was installing ADDS. For repeatability and maintainability, I try to avoid using the GUI to perform operations that can be easily accomplished by PowerShell. With that in mind, I created a PowerShell script to install and configure ADDS (GitHub repo here). This also aligns with the infrastructure-as-code approach that I’m following.
At one point, I found the difference between ADDS structures (i.e., forests, domains, and organizational units) quite confusing until I began thinking about it in the following manner:
- You can think of an AD forest, in my SED’s case SED.local, like an apartment complex. Each apartment complex has its own address, management company, and maintenance team. All of the apartments within the complex follow the same building code. Like the apartment complex, a forest is its own self-contained structure.
- Within the forest, our domains are like apartments in the complex. Each domain has its own locks, residents, and household rules (i.e., security, users, and policy).
- Organizational units (OUs) within the domain are similar to individual rooms. OUs help us organize space. In an enterprise, we can designate OUs according to department (e.g., HR, IT, Procurement), with each OU containing its own set of policies.
- Group Policy Objects (GPOs) are essentially the “house rules.” We can have rules that apply to the entire domain or to individual OUs. For example, there may be a global policy that sets password complexity across the entire domain and another rule that establishes elevated permissions for users who belong to the IT OU.
Years ago, when I encountered ADDS, it was this analogy that anchored the principles for me. It may do the same for you.
Of course, after standing up ADDS, the next step was establishing file services and the file share witness. I won’t go into detail about its configuration in this post, but you can access my GitHub (updates coming soon), which contains well-commented PowerShell scripts so you can follow along with the process.
Now that the SED backbone (ADDS and file services) is operational, the next step is provisioning SQL Server and establishing the SQL Server cluster. As mentioned, the cluster relies heavily on these foundational services, reinforcing why the sequencing of services is so important. In my next post, we’ll explore my SQL Server cluster in detail.