Setting up a Centralized Active Directory Environment for a Homelab
Article Goal
When walking into the large brick office as an information systems security intern on my first day, I was quite nervous. I had tried my hardest to review as many topics related to cybersecurity as I could with the weeks leading up into my first day, but I knew there much more information than the capacity of my brain. As I was walking around of office for the initial tour of the building with other young interns, I saw an individual who was kneeling next to a set of computers, plugging in wires to one of the machines – it appeared he was setting up some new computer workstations. I briefly glanced at one of the computer screens and to my surprise my name was on the Windows login screen. I wondered how this individual had already set up my account as I walked into the next corridor and little did I know at the time, Active Directory was working behind the scenes.
If you have ever had the chance to look inside a corporate business network, you will almost always see Active Directory being used to provision and manage all workstations under the network. Active Directory is what makes Windows Servers so critical to a large-scale business network. With its seamlessly easy-to-use management console and Single Sign On (SSO) functionalities, Active Directory is a critical service utilized by most large-scale business networks.
In this article, we will be addressing what Active Directory is, how it’s used, why it relates to cybersecurity, and how to setup the initial configurations inside Active Directory for your homelab.
Quick note: The steps and points below have been summarized to keep this part short. All resources and guides followed throughout this course will be linked when necessary. At the end of this article is a Article Links and Resources I Used, which lists all articles referenced throughout this post. You can simply follow each of these resources in sequential order and achieve the same result.
For this part of the homelab, I will be working inside the main PC to setup and configure Active Directory.
What is Active Directory?
Active Directory is server service used to set security controls and permissions in a Windows environment. Due to the large magnitude of computer workstations, services, and devices used on a corporate network, there needs to be a way or process of centrally managing all of these devices, while having the ability to set specific permissions on each device. Active Directory is the service used to accomplish this task.
Active Directory, often abbreviated to AD, is known as the “pinnacle of Single Sign On (SSO)” – meaning once you sign into one device, you get access to everything allowed for the specific account. You can lock down security policies on individual windows workstations or using what is known as Group Policy Objects (GPO) you can set permissions for groups of workstations.
You may be wondering why use an AD environment for a homelab setup… If you work in I.T., you will encounter AD at one point. Understanding the fundamentals of how to use AD will help you quickly configure and troubleshoot potential problems. In addition, you will learn how to centrally manage and set permissions on the various services you will be setting up on your homelab network so you have more control.
A Basic Overview of How Active Directory Works
AD can get complicated very quickly, depending on the scale and size of your network. For the purpose of this article and the homelab project, I will be briefly going over how AD works… Remember all resources I used are linked below.
Servers controlling AD services are called Domain Controllers (DC)s. A DC is often configured in a Windows Server environment. Domain Controllers are in charge of setting up and managing AD’s core capabilities and features.
Under a DC, you can add user and computer accounts. User and computer accounts are based on the user, perhaps an employee, or a computer, such as a specific location. User and computer accounts are based off of the “schema” which is the types of data stored into the DC. Examples of possible fields within the schema include usernames, passwords, email, office number, etc. And this schema is “extendable” meaning data fields can be added to it in the future.
So now we have a Domain Controller (DC) which is in charge of setting up and managing AD itself and under this DC we can add user and computer accounts with details added to what is called a “schema.”
To optimize the overall organization of user and computer accounts, we can add a set of accounts into Groups. Instead of having to configure each individual permission for every single user account, we can add the account to a Group. And the account under this Group “inherits” the permissions set in the Group. Groups are used for security purposes.
Finally, we have Organization Units (OU)s which are used for administrative purposes. You can organize groups into Organization Units to make groups easier to manage.
Let’s say you are the only network administrator for an organization that has five hundred employees located in ten different locations around the world. Each of these locations has a group titled “DebooCompany-Location” and within these groups are sub-groups consisting of the department. If you had to setup, manage, and maintain each these groups, you would quickly be overwhelmed by the administration overhead of each group and location. Organization Units make this process much easier. Under each OU, you can set up a local administrator account, so the local administrator has direct control for their specific group. Now you do not have to worry about each location and its group because each OU now has a local administrator who control their specific permissions for the user and computer accounts which reside under them.
Each Domain Controller which consists of user and computer accounts is known as an entire domain.
AD can get much more complicated than this, but we will stop here because this is all we need to know for the sake of a homelab.
If you want to learn more about AD, watch this overview video of Active Directory by Eli the Computer Guy.
How does Active Directory Relate to Cybersecurity?
AD is the lifeblood for a corporation’s apps, files, and users. Without AD, permissions cannot be set on workstations and services, meaning employees could gain access to devices they don’t need to have access to and customize their individual workstations allowing to open up potential areas for attack.
AD allows for Single Sign On (SSO) capabilities which reduces administration overhead and implements a separation of privileges among the entire network, meaning each user and computer account is limited on what they can do.
Install and Setup Active Directory
Now we know what AD is, how it works (in the most basic terms), and why it related to cybersecurity. It’s time to setup and configure AD for our homelab.
As a quick reminder, this article is not a step-by-step technical walkthrough of setting up AD. This is a high-level overview with the included resources you need to setup AD for you homelab.
To install, setup, and work with AD, we will need a Windows Server environment. Since we are using VMs in our homelab, you can download a ISO image for Windows Server 2016 or 2019 here.
If you need help setting up the Windows Server VM, have a look at this quick YouTube tutorial by Heath Adams (The Cyber Mentor).
After downloading and setting the initial configurations for the Windows Server VM, we will need to install AD onto our Windows Server. In addition to downloading AD, we will also need to install DNS and DHCP functionalities to create our very own Domain Controller. And once this is finished, we will need to set a static IP address for the DC. To do all of this, I used a 20 minute Windows Server 2016 tutorial on YouTube by MSFT WebCast here.
The entire setup process and configurations for the baseline AD can be followed in the MSFT Webcast YouTube tutorial.
When I was walking through the YouTube tutorial, I was curious on why we needed to setup DNS and DHCP on Active Directory. After conducting some quick Google searches, I found out the reasons.
DNS in Active Directory
Domain Name Services (DNS) resolution services make it possible for clients to locate Domain Controllers and for the Domain Controllers hosting directory services to communicate with each other. AD relies on DNS to locate objects within AD.
When configuring DNS in AD, you will need to configure a reverse lookup zone. A reverse lookup zone is an authoritative DNS zone that is primarily used to resolve IP address to network resource names. Without configuring a reverse lookup zone, you cannot map IP addresses in the zone to the hostname. A forward lookup zone is used to resolve hostnames (ex cybercademy.org) to IP addresses.
DHCP in Active Directory
Dynamic Host Configuration Protocol (DHCP) allows the Domain Controller to send out IP addressing information so that clients can communicate with other machines and services, while still being under direct control from the Domain Controller with AD installed.
This is why you will need to install and configure DNS and DHCP in AD to make the entire process work cohesively.
Test Active Directory Setup and Services
After successfully following and finishing the initial configurations and setup for AD on the Windows Server 2016 VM, I wanted to see if everything worked. To do this, I went ahead and downloaded a Windows 10 Enterprise addition VM from here.
Following the last five minutes of the MSFT Webcast tutorial, you will learn how to connect the Windows 10 workstation to AD with proper IP addressing.
Summary
In this part of the Cybercademy Cybersecurity Homelab project, we have successfully learned what Active Directory is, why we use it, how it relates to cybersecurity, how to setup AD for a homelab environment with DNS and DHCP installed, while successfully testing and connecting a Windows 10 Enterprise Edition to the network.
In this next part of this project, I will be setting up and connecting Linux and Windows 10 workstations while also performing baseline configurations to a Remote Desktop Protocol (RDP) Server.