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!