Ticket to Ride

My Simulation Setup

I wired GLPI into infrastructure that was already live in my homelab, then worked it most nights across all four ITIL types: incident, service request, problem, and change. Real volume built up honestly instead of arriving all at once, the fundamentals sitting right next to the interesting finds: password resets and printer jams alongside a Kerberoasting attempt the SIEM never caught.

Wiring It to Something Real

I stood up GLPI on its own VM and pointed it at the Active Directory domain already running the rest of this lab, through a dedicated least-privilege LDAP service account instead of reusing the domain admin credentials. First sync back came in wrong: fifty-five objects imported, most of them AD's own built-in security groups, Domain Admins and Schema Admins sitting in the ticketing system's user list next to actual people. GLPI's LDAP directory had no filter scoping the search to real person accounts, so it pulled in everything under the base DN regardless of object type.

I caught it by actually reading the imported names instead of trusting the "55 imported" success count, fixed the filter to scope to real accounts only, and cleaned the directory down to the six that were ever real.

Digesting the Tickets

I came back to this most nights over about a week, never a marathon session, just whatever time I had. Forty-six tickets came out of it across all four ITIL types: incident, service request, problem, and change. Password resets and account unlocks. A new hire's laptop that wouldn't power on. A conference room's HDMI switcher stuck on the wrong input five minutes before a client call. A printer that kept losing its static IP after every firmware update, which happened often enough to stop treating it as a one-off and open a real Problem ticket instead, find the actual root cause, and fix it with a DHCP reservation instead of resetting the IP by hand every time.

Forty-three of those forty-six closed clean. One stayed open, a request to bring a set of training containers back online that I genuinely didn't have the access to finish that night, documented honestly as blocked instead of quietly marked solved.

The Sneak Attack

The most interesting result of the whole project wasn't a ticket I closed, it was one where the tooling failed. I ran a real Kerberoasting attempt against a domain service account, chaining off the same low-privilege LDAP account I'd wired in earlier, and got back a crackable ticket hash. Then I ran five real failed logon attempts against Administrator, checking for account lockout risk first so I wasn't about to lock myself out of my own domain controller.

I checked the SIEM. Nothing. The agent on the domain controller was active, reporting other Windows Security events in the exact same window, but neither the Kerberoasting request nor the failed logons produced a single alert.

I didn't just note it and move on. I wrote it up as a real Incident ticket documenting what actually happened at the protocol level, then opened a linked Problem ticket root-causing the gap itself: an audit policy likely missing the right subcategories, a ruleset with no coverage for RC4-encrypted ticket requests, no correlation rule for a burst of failed logons from one source. That Problem ticket is still open, because the honest answer right now is that I know what's broken and haven't fixed it yet. A clean detection would have been a less useful story than a real gap with a documented root cause.

A Change That Didn't Go Cleanly Either

I ran a Change ticket through its full lifecycle against a real infrastructure change, bumping a VM's memory allocation, and treated the self-approval step as an actual step instead of skipping it. The change itself didn't apply the way I expected. qm set --memory updated the config file but the running VM kept its old allocation, since nothing had hotplug configured. I caught it by checking free -h inside the guest instead of trusting the command's clean exit code, rebooted, and verified the new number for real before closing it out.

Small thing, but it's the same lesson as the LDAP sync: a command returning success and a change actually taking effect are two different claims, and only one of them is worth closing a ticket over.

What This Actually Proved

The tickets themselves aren't the point, the habit underneath them is. I check a sync, a config push, or a solved status twice before I trust it, since the failure mode in every one of these cases was quiet, not loud. There are sites built specifically for this kind of practice, but I built my own instead, right inside the same homelab I already use for everything else. It's not a simulator I logged into, it's infrastructure I stood up myself, which is the whole reason I run a homelab in the first place.

Related Notes

• Home Lab build series, the Active Directory domain and Wazuh SIEM this project runs on top of