CAMILLE STENNIS

What I broke

I worked four failures as tickets. With wrong DNS on the workstation, domain login failed while the domain controller still answered pings. When I stopped the DHCP service, the workstation gave itself a 169.254 address. With the domain controller offline, users who had signed in before got in with cached credentials, but new users couldn’t. “No internet” was really no DNS. For an account lockout, I verified identity, then unlocked the account.

What surprised me

My first DNS break didn’t show up at all. Cached lookups kept working until a reboot. That’s exactly how “it worked yesterday” tickets happen.

What’s next

A second domain controller would remove the single point of failure. BitLocker encryption and a full Windows reinstall are next in the lab.

What I did

I built a Windows Server 2025 domain controller with a static IP and promoted it to a new Active Directory forest. I set DNS forwarding to the firewall and added a reverse lookup zone. I migrated DHCP from the firewall to the domain controller in a planned order, avoiding two DHCP servers on one network. I built a Windows 11 workstation, joined it to the domain, and created a user who must change their password at first login. I confirmed the login went through the domain controller.

What broke

Neither Windows installer could see the disk or network until I loaded VirtIO drivers. A health check, dcdiag, flagged two failures. Their timestamps matched the first reboot after promotion. I confirmed the services were working before calling them startup noise.

What I learned

Active Directory lives and dies by DNS. That’s why the domain controller hands out its own address as the DNS server.

What I did

I created an isolated lab network bridge in Proxmox and installed OPNsense as the gateway between my home network and the lab. I set up NAT, DHCP, and DNS.

What broke

The first install failed with disk read errors because the installer image was truncated during upload. I downloaded it directly to the server and verified it with a SHA-256 checksum. The default config briefly put the firewall’s LAN side on my home network, using my home router’s address range. That created a rogue DHCP risk, so I disconnected it until I reassigned the interfaces. After the setup wizard, I was locked out of the firewall’s web interface. The browser said “timed out,” not “refused,” which told me packets were being silently dropped. I wrote a narrow rule allowing HTTPS only from my home network.

What I learned

I verify images before installing. “Timed out” versus “refused” helps me tell a firewall problem from a dead service. I also traced a packet hop by hop through two layers of NAT.

What I decided

• Retired my plan to build a SOC simulation (Active Directory, Sysmon, Wazuh, attack simulation).
• Refocused the homelab into a network lab, aimed at the CCNA.
• Updated my certification path: AWS Cloud Practitioner, then CompTIA Security+, then CCNA, then AWS Solutions Architect Associate.

Why

While mapping out the SOC build, I noticed where my attention actually went. Every time I got into the network layer (IP addressing, how traffic moves between machines, VLANs) I wanted to keep going. When the work moved up to the applications and alerts sitting on top of the system, my interest faded. I like the bones of a system. Networking is the part that hooks me, so that’s where I’m building.

This isn’t a restart. Everything from Entries 01 and 02 still counts: Proxmox, static IPs, SSH, and Docker all live on the network. My Terraform project was VPC work, which is networking in the cloud.

What’s next

• Build my first topologies in Cisco Packet Tracer: switches, routers, VLANs, and subnetting.
• Buy a managed switch (still on the list from Entry 01) and segment my home network.
• Later: run GNS3 or EVE-NG on the Proxmox box for more realistic labs. 16GB of RAM may get tight, so I’m watching that.

Studying for the CCNA too? I’d love to compare notes.

Update, Oct 2026: I brought Windows and Active Directory back as an IT support lab to match the help desk and field tech roles I’m interviewing for.

What I did

• Installed Docker on my Ubuntu VM (the virtual computer I built last time).
• Set up Portainer, a dashboard that lets me see and manage everything Docker is running, without typing commands for every little thing.
• Deployed my first container: a small web server running a test page.

The plain-English version

Think of my physical computer as an apartment building. Proxmox (the software I installed directly on the hardware) is what let me carve that building into separate apartments, each one a fully independent “unit” with its own walls, its own everything. My Ubuntu VM is one of those apartments.

Docker works differently, and inside that one apartment. Instead of building more walls, Docker is more like buying a bunch of matching, ready-to-go furniture sets, each one a “container”, and dropping them into different rooms of the same apartment. Each one is self-contained and comes with everything it needs already assembled, but they're all still sharing the same electricity and plumbing (the apartment's operating system) underneath. That's the real difference between a VM and a container: a VM is its own separate apartment, a container is a self-sufficient room inside one.

Portainer, then, is just the building manager's clipboard, a single dashboard where I can see every “furniture set” I've dropped in, check if it's working, and add or remove them, instead of manually checking each room myself.

For today's test, the “furniture set” I dropped in was a basic webpage. Not exciting on its own, but it proved the whole chain works: hardware, to virtual apartment, to container, to something visibly running that I could pull up in a browser.

What broke / what I learned

• Portainer's first-time setup has a short security timer. If you don't finish creating your admin account fast enough, it locks you out and you have to restart it and grab a fresh access code. Mildly chaotic, but a good reminder that even setup screens are built with security-first thinking.
• Small syntax trip-up: typing $actualname instead of $USER in a command. In this world, a $ in front of something means “look up this stored value,” not “insert this literal word.” One character, big difference in outcome, exactly the kind of precision this field rewards.

What's next

• Get more comfortable deploying containers through Portainer's interface.
• Start building toward the bigger picture: a mock “company” (a fake office network) inside my homelab, complete with its own user accounts and machines, so I can practice real security monitoring on something realistic instead of just an empty VM.

What I did

• Sourced and assembled a full homelab rig from scratch: a $188 refurbished Dell OptiPlex 3060 SFF, a monitor, keyboard/mouse, and a dual-connector USB drive, all bought used or on a budget.
• Wired the machine into my home network, confirmed the NIC and static IP entirely from the command line before ever touching a browser.
• Installed Proxmox VE (a bare-metal hypervisor) directly onto the hardware, configured with a static IPv4 address instead of the default IPv6.
• Created and installed my first virtual machine (Ubuntu Server 24.04), fully isolated from the host.
• Set up SSH so I can manage that VM entirely from my laptop, no monitor or keyboard required going forward.

What broke / what I learned

• My HDMI cable didn't fit the OptiPlex's port. Turned out the “HDMI” label on the refurb listing was wrong: it was actually DisplayPort. Fell back to VGA for the one-time setup screen instead of buying the wrong adapter twice.
• balenaEtcher (the tool I planned to use to flash my installer USB) threw a bug on both local file and URL flashing. Skipped it entirely and used dd via Terminal instead, which is honestly the more “real” way people do this anyway.
• Learned the hard way that Proxmox's default free-tier repo setup throws update errors until you manually disable the enterprise repos, an easy one-line fix once I knew to look for it, but not obvious from the UI alone.
• Biggest lesson: almost nothing about this was plug-and-play. Every step had a small decision to make or a small thing to debug, which is exactly the muscle I'm trying to build for SOC work.

What's next

• Install Docker on the Ubuntu VM and get my first containerized service running.
• Buy a managed switch and start segmenting my network into VLANs.
• Eventually: build out log aggregation so I can practice actually monitoring what I've built, not just running it.

Following along or building your own? I'd love to hear what you're working on.