GPO GUID Resolve

[faiq1999]

Hi everyone.

Is there any way to resolve GPO GUID or SID within Windows Security Logs? For instance, when we change any GPO in the domain it is logged under EventCode 5136. There is a CN name inside the log that can be used for getting the Display name of GPO. 

Thanks 

[tscroggins]

Hi @faiq1999,

The ObjectDN data element should contain the distinguished name of the object. If that's not present in your data, can you provide a deidentified example of the event?

[faiq1999]

Here is. If I use the CN name value with Powershell's Get-GPO cmdlet then it returns me the Display Name of the GPO but I want to get it from Splunk results.

02/10/2024 11:30:27 AM
LogName=Security
EventCode=5136
EventType=0
ComputerName=DC-01.EXAMPLEDOMAIN.local
SourceName=Microsoft Windows security auditing.
Type=Information
RecordNumber=26135
Keywords=Audit Success
TaskCategory=Directory Service Changes
OpCode=Info
Message=A directory service object was modified.

Subject:
Security ID: EXAMPLEDOMAIN\administrator
Account Name: Administrator
Account Domain: EXAMPLEDOMAIN
Logon ID: 0x92B8F

Directory Service:
Name: exampledomain.local
Type: Active Directory Domain Services

Object:
DN: CN={CFD494B1-9D7F-448B-AF8F-3B7B3ABF1AA8}CN=POLICIES,CN=SYSTEM,DC=EXAMPLEDOMAIN,DC=LOCAL
GUID: CN={CFD494B1-9D7F-448B-AF8F-3B7B3ABF1AA8}CN=Policies,CN=System,DC=exampledomain,DC=local
Class: groupPolicyContainer

Attribute:
LDAP Display Name: versionNumber
Syntax (OID): 2.5.5.9
Value: 196611

Operation:
Type: Value Added
Correlation ID: {8eaedf1e-827a-4ee8-8118-2b8e0ddb1133}
Application Correlation ID: -

[tscroggins · Accepted solution]

First, install and configure Splunk Supporting Add-on for Active Directory on your search head or search head cluster. If you're using Splunk Cloud, you'll need connectivity to a directory replica, i.e. a domain controller, through a cloud-to-cloud private link or some other connection.

Note that Splunk does not index the Object DN field value correctly when renderXml = false (sourcetype=WinEventLog). There is a missing comma between the first and second RDNs.

This:

	DN:	CN={CFD494B1-9D7F-448B-AF8F-3B7B3ABF1AA8}CN=POLICIES,CN=SYSTEM,DC=EXAMPLEDOMAIN,DC=LOCAL

should be this:

	DN:	CN={CFD494B1-9D7F-448B-AF8F-3B7B3ABF1AA8},CN=POLICIES,CN=SYSTEM,DC=EXAMPLEDOMAIN,DC=LOCAL

with a comma between CN={CFD494B1-9D7F-448B-AF8F-3B7B3ABF1AA8} and CN=POLICIES.

We can fix the extracted DN field in our search:

| eval DN=replace(DN, "(?i)\\}CN=", "},CN=")

Assuming Splunk Supporting Add-on for Active Directory is configured and working, we can add the ldapfetch command to our search to fetch additional LDAP attributes using the DN field value:

| ldapfetch dn=DN attrs="displayName"

If a group policy object is deleted, it will no longer be in the directory, and ldapfetch will not return a displayName.

To allow for those cases, you can schedule a search to periodically fetch group policy objects and store attributes in a lookup file:

| ldapsearch search="(objectClass=groupPolicyContainer)" attrs="whenChanged,distinguishedName,displayName" basedn="CN=Policies,CN=System,DC=EXAMPLEDOMAIN,DC=LOCAL"
| eval _time=strptime(whenChanged, "%Y-%m-%d %H:%M:%S%z")
| table _time distinguishedName displayName
| sort 0 - _time
| inputlookup append=true group_policy_object_lookup
| dedup distinguishedName
| outputlookup group_policy_object_lookup

Note that whenChanged is not a replicated attribute, and its value won't be precise. Its use here allows to store the most recent displayName value available from the directory server in our lookup. The lookup should be defined with case-sensitivity disabled (case_sensitive_match = false).

With a lookup cache available, we can use the lookup command in place of ldapfetch:

| lookup group_policy_object_lookup distinguishedName as DN output displayName

While it's not relevant to Splunk, I like to note when I see it used that the .local TLD is reserved for use by multicast DNS. I normally use example.com for general purpose documentation, contoso.com for Microsoft documentation, and occasionally buttercupgames.com for Splunk documentation. ICANN recently proposed defining a private-use TLD, although not specifically .internal as many have reported. (I can only assume the reporters didn't actually read the proposal.) I hope the proposal is adopted!

[faiq1999]

Thank you for your answer.