Post cover image

August 23, 2026

Building a SOC Lab from Scratch: Part 5: Connecting Active Directory to Splunk and Collecting…

In the first four parts, the lab slowly moved from a single Splunk server into a small Windows domain. Part 1 built the Splunk foundation…

By Anouar RIYANE

5 min read

In the first four parts, the lab slowly moved from a single Splunk server into a small Windows domain. Part 1 built the Splunk foundation and centralized Windows logs. Part 2 added Sysmon and PowerShell logging. Part 3 introduced Active Directory and DNS on DC01, and Part 4 added CLIENT01 and joined it to the soclab.local domain. At this point the machines could talk to each other, users could authenticate through the domain, and the next question was the one a SOC analyst actually cares about: can we see what the domain is doing?

That is the goal of Part 5. I installed a Splunk Universal Forwarder on the Domain Controller, selected the Windows event channels I wanted to collect, and sent those events to SPLUNK01. Then I generated normal and failed domain-authentication activity from CLIENT01 and confirmed that Kerberos and credential-validation events were arriving in Splunk.

Lab state before starting:_ SPLUNK01 is the Ubuntu Splunk Enterprise server at 192.168.196.10, DC01 is the Windows Server 2022 Domain Controller and DNS server at 192.168.196.20, and CLIENT01 is the Windows 11 domain workstation at 192.168.196.30. The domain is soclab.local._

  1. Installing the Universal Forwarder on DC01

I started on DC01. The Domain Controller is one of the most valuable log sources in this lab because it handles domain authentication, Kerberos tickets, account activity, and many other events that are useful during an investigation. Instead of installing another full Splunk instance, I used the lightweight Universal Forwarder and pointed it at the Splunk server we already built in Part 1.

During the installer, I left the deployment-server field empty because this lab is still small and I am configuring the forwarder directly. For the receiving indexer I used:

  • Host / IP: 192.168.196.10
  • Port: 9997

Port 9997 was already configured on SPLUNK01 earlier in the series, so DC01 only needed to know where to send its data.

None

2. Verifying the Forwarder Service

After installation, I checked that the Windows service was actually running. This sounds basic, but it is the fastest way to separate an installation problem from a forwarding or input problem.

Get-Service SplunkForwarder

The service returned as Running, which told me the Universal Forwarder had started correctly on DC01.

None

3. Telling the Forwarder Which Windows Logs to Collect

Installing the forwarder is only half of the job. I still needed to tell it which event channels I wanted. For this stage I kept the configuration simple and focused on the main Windows logs plus the PowerShell Operational channel.

I created the file below on DC01:

C:\Program Files\SplunkUniversalForwarder\etc\system\local\inputs.conf
[WinEventLog://Application]
disabled = 0
index = windows
renderXml = true

[WinEventLog://Security]
disabled = 0
index = windows
renderXml = true

[WinEventLog://System]
disabled = 0
index = windows
renderXml = true

[WinEventLog://Microsoft-Windows-PowerShell/Operational]
disabled = 0
index = windows
renderXml = true

All four inputs send to the existing windows index. I also kept renderXml enabled so the events arrive in XML format, which makes the underlying Windows fields visible while I am still learning how each event is structured.

None

A small troubleshooting lesson:_ My first version was accidentally saved by Notepad as inputs.conf.txt. Splunk did not load it, so no Windows events appeared even though the forwarder service was running and port 9997 was reachable. Renaming the file to exactly inputs.conf fixed the issue. This was a good reminder to check file extensions before changing anything more complicated._

4. Restarting the Forwarder After the Configuration Change

After correcting the filename and saving the configuration, I restarted the Universal Forwarder so it would reload the new inputs.

Restart-Service SplunkForwarder
Get-Service SplunkForwarder

The service came back as Running. From this point, DC01 had both an output destination and a set of event channels to monitor.

None

5. Confirming That DC01 Logs Reach Splunk

I moved back to Splunk Web and started with the broadest possible search for the Domain Controller:

index=windows host=DC01

This time the result was immediate: hundreds of events from DC01 were visible. That was the point where the pipeline was proven end to end Windows Event Log → Universal Forwarder → TCP 9997 → SPLUNK01 → windows index.

None

I then grouped the results by source and sourcetype to check that every channel from inputs.conf was present:

index=windows host=DC01
| stats count by source, sourcetype
| sort - count

The result showed Security, System, Application, and Microsoft-Windows-PowerShell/Operational data. Security was the busiest source, which is exactly where most of the Active Directory authentication events I wanted to study would appear.

None

6. Watching Real Domain Authentication in Splunk

The next step was more interesting than simply counting logs. CLIENT01 was already joined to soclab.local from Part 4, so normal domain activity was generating Kerberos events on DC01. I searched the Security log for a small set of authentication-related Event IDs:

index=windows host=DC01 source="WinEventLog:Security"
| rex field=_raw "<EventID[^>]*>(?<EventCode>\d+)</EventID>"
| search EventCode IN (4768,4769,4771,4776)
| table _time EventCode _raw
| sort - _time

Two of the events that immediately appeared were 4768 and 4769. In simple terms, these show Kerberos ticket activity. In the raw event I could see socuser, the SOCLAB.LOCAL domain, CLIENT01, and the workstation IP address 192.168.196.30. This is where the lab started to feel less like "collecting Windows logs" and more like watching an actual domain operate.

  • 4768 — a Kerberos authentication ticket (TGT) was requested.
  • 4769 — a Kerberos service ticket was requested.
None

7. Generating a Failed Domain Authentication

I also wanted to prove that failed authentication could be observed. On CLIENT01, I used runas with the domain account and intentionally entered an incorrect password:

runas /user:SOCLAB\socuser cmd.exe

Windows rejected the attempt with error 1326, confirming that the username/password combination was invalid. The important part was not the error itself it was whether the Domain Controller would record the failure and whether Splunk would receive it.

None

At first the failed events were not visible. I checked the auditing configuration on DC01 and made sure failure auditing was enabled for the Kerberos Authentication Service and Credential Validation categories:

index=windows host=DC01 source="WinEventLog:Security"
| rex field=_raw "<EventID[^>]*>(?<EventCode>\d+)</EventID>"
| search EventCode IN (4771,4776)
| table _time EventCode _raw
| sort - _time

8. What Part 5 Added to the Lab

By the end of this part, the Domain Controller was no longer a blind spot. DC01 was continuously forwarding its Windows event logs to SPLUNK01, and I could see both normal Kerberos authentication and failed credential activity from CLIENT01.

The most important result is the data path we now have:CLIENT01 → DC01 / Active Directory → Windows Security Events → Universal Forwarder → SPLUNK01

I also learned two practical troubleshooting lessons that are easy to miss in a clean tutorial: a forwarder can be running while its input configuration is being ignored, and Windows will only generate some security events when the corresponding audit policy is enabled. Checking each layer separately made the problem much easier to solve.

Next: Part 6: Monitoring Active Directory Security Events

Part 5 was about getting the Domain Controller data into Splunk. In Part 6, the focus will move from collection to monitoring. I will generate Active Directory changes such as account creation, account deletion, group membership changes, and account lockouts, then search and investigate those events in Splunk. That is where the lab starts moving from infrastructure into actual SOC detection work.