Active Directory Lab

Active Directory or AD is Microsoft’s tool for managing domain networks. It allows an administrator to control and set permissions and privileges to resources like machines or users in a network. Knowledge of AD is essential for many system administrator positions, and I will familiarize myself with the tool in this lab.

The first thing I had to do was set up my lab environment. Normally, I would have liked to set up my virtual machines on my Proxmox server, but unfortunately, I am away from my apartment right now. So, I will be using VirtualBox on my laptop to virtualize my lab. The most important piece is the Windows Server 2022. This machine will be where I actually use Active Directory, while the other two machines in this lab are there to test and verify certain actions I take in AD. These other machines are going to be two instances of Windows 11 Enterprise. I debated doing this lab with Windows 10 Enterprise machines since many organizations are still using this version, but the reality is that for the purposes of this lab, the differences between managing these machines in AD are almost non-existent.

I created a group in VirtualBox to hold all of the machines for this lab together and named it “Active Directory”. When configuring the machines, it was important that I set all of their network adapters to “Internal Network” and created a LAN called “LAN 1”. Besides bumping the server’s memory up to 4 GB, I left all of the other settings as default.

Next, I worked on installing and configuring the operating systems. Starting with Windows Server 2022, I installed the Desktop Experience version so I would have access to a GUI. I configured the network settings, as shown in the image above. The DNS server must be set to the domain controller because a large part of how AD functions is through DNS. I also renamed the computer to “DC1” for simplicity.

Continuing the setup, I gave this server the roles of “Active Directory Domain Service” and “DNS Server”. I created a new forest called “ad.lab” which is the highest organizational level in AD. Inside a forest, there can be multiple unique domains that all share one namespace.

Since this Windows Server was also going to function as the DNS server for the workstations in the domain, I needed to configure a DNS forwarder. This way, when a workstation tries to query a domain name, the request can be passed to an external DNS server like 8.8.8.8 to complete the request. Otherwise, my Windows Server will not have the IP address to resolve that request, causing an error.

Next, I created my first user on the domain. Jim Admin will be the domain administrator in charge of managing the company through AD. I created this user account with the option to require a password change at the next logon. This allows Jim to easily set his own password rather than the default one I assigned when establishing the user. I went ahead and added Jim to the default Domain Admins group that comes on the Windows Server. This will give the account the necessary permissions to fulfill its role.

Now that the domain administrator was ready to go, I signed in through Jim’s account and got to work creating the other users in the domain. John and Jane were made similarly, although I did not yet assign them to any groups. Instead, I went to the two Windows 11 Enterprise machines I installed and added them to the domain. This is done in System Properties and requires that the machines can communicate with the Windows Server over the local network. To accomplish this, I used the network configuration as seen above. John’s machine was assigned 192.168.1.3, while Jane’s was 192.168.1.3. The important thing was setting the DNS server to the IP address of the Windows Server. This provided a direct line of communication between the workstations and the AD server.

In this image, I renamed the workstations to “BOX1” and “BOX2” respectively, while enrolling them in the domain. This makes it easier to identify them inside of AD. After clicking “OK”, I was prompted to input the desired user account from the ad.lab domain that I wanted on that given machine. Now, I had both virtualized workstations enrolled in the newly created domain with different users for each. Upon restarting, it was immediately apparent that the changes were successful since I was greeted with User Access Control and required an administrator account when I tried to modify some settings.

Back in the AD server, I created Organizational Units, or OUs, to organize the network's users and machines. These OUs are essentially just container objects that are used to logically combine and separate network resources. As you can see in the image, I created OUs for the hypothetical Sales, Marketing, and IT departments in addition to Management. I moved John into Management, Jane into Sales, and Jim into IT.

Here, you can see the renamed computers that are now in the domain. I created a new OU called “Workstations” and moved them into there. In a larger network, I would also have OUs for servers and domain controllers. Having multiple domain controllers is common for a few reasons. Redundancy is important because if one domain controller goes offline, the other can take over, allowing for high availability, which is one of the core concepts of cybersecurity. Another reason to have multiple is for load balancing. As domains grow and more machines call upon the controllers, there may be a need to have more computing power to handle the load.

OUs allow the domain administrator to delegate control over these units to different users or groups. This is a valuable feature because it creates an environment where the domain administrator isn’t needed for every minor IT issue. Now, a marketing team manager can help a user in their department reset their password if needed instead of going directly to the domain admin.

The next thing I wanted to look at was Group Policy. Group Policies are sets of rules that can be applied to users or OUs and dictate both computer and user policies. A Group Policy Object or GPO is the actual collection of settings that can be applied wherever needed. To experiment with this, the first thing I did was edit the Default Domain Policy. This is the GPO that is automatically applied to every new user that is added to the network. I changed some of the password policies so that passwords now had to be 12 characters instead of the default seven, and a new password had to be created every month. This change will now affect all of the users that are linked with this GPO.

The last thing I did was create an entirely new GPO. I named it “Remove Cleanup Wizard” since the goal of the GPO was to remove the Desktop Cleanup Wizard. I enabled the appropriate policy under User Configuration > Policies > Administrative Templates > Desktop. From here, all that is left to do is drag the GPO on the left column to any of the OUs I want it to apply to. I did this for both Sales and Marketing. Sure enough, upon logging into Jane’s workstation, she no longer had access to the tool.

This lab went through some of the basics of working in Active Directory. I gained hands-on experience in administrating a basic network and became familiar with the layout and options in the tool. I wanted to do this because AD is very commonly seen in roles involving any system administration. Additionally, Active Directory is a common target of attackers since it provides so much power over a network. Attackers can harvest user credentials, deploy malware, and get detailed reconnaissance from the tool. I will continue to mess around in this lab and get more comfortable with AD's capabilities. I will specifically harden AD in a future lab to protect against hackers.