Getting Data In

SA-ldapsearch TA timestamp issue

tech_g706
Path Finder

Hi,

I am experiencing issue with  SA-ldapsearch TA. 
 I am using this search to validate the timestamp

index = <index name>
| eval bucket=_bkt
| eval diff = _indextime - _time
| eval indextime=strftime(_indextime,"%Y-%m-%d %H:%M:%S")
| eval capturetime=strftime(_time,"%Y-%m-%d %H:%M:%S")
| table indextime capturetime diff _raw

I can see that, the indextime  = 2025-06-08 05:00:20 but capturetime = 2020-01-13 10:00:01

Splunk is ingesting the latest ldap events but _time field is having timestamps of 2020. 

In the raw event, there are multiple timestamps available:

"whenCreated":"2018-06-05 10:43:19+00:00
"whenChanged":"2024-02-11 13:52:37+00:00
"pwdLastSet":"2019-07-24T06:41:44.698530Z
"lastLogonTimestamp":"2019-07-24T06:41:44.282975Z


but I am not able to understand how the TA is extracting the 2020 timestamp from the raw as there is no such timestamp in the raw event.

Labels (2)
0 Karma
1 Solution

livehybrid
Super Champion

Not quite, _indextime will always the time its indexed, however _time is usually derived/determined from the data. For some reason Splunk is detecting the incorrect time.

Try updating your props like this:

[source::.../var/log/splunk/SA-ldapsearch.log]
sourcetype = SA-ldapsearch
DATETIME_CONFIG = CURRENT

🌟 Did this answer help you? If so, please consider:

  • Adding karma to show it was useful
  • Marking it as the solution if it resolved your issue
  • Commenting if you need any clarification

Your feedback encourages the volunteers in this community to continue contributing

View solution in original post

tech_g706
Path Finder

@richgalloway 

My understanding is that, if indextime is today so _time should have been the same since there is no delay during ingestion.


Here is the default props.conf that comes with the SA-ldapsearch TA: (there is no transform.conf)

[source::.../var/log/splunk/SA-ldapsearch.log]
sourcetype = SA-ldapsearch


[SA-ldapsearch]
EXTRACT-vars = Level=.+, (?<log_source>Pid=.+, File=.+, Line=.+), (?<message>.*)

0 Karma

livehybrid
Super Champion

Not quite, _indextime will always the time its indexed, however _time is usually derived/determined from the data. For some reason Splunk is detecting the incorrect time.

Try updating your props like this:

[source::.../var/log/splunk/SA-ldapsearch.log]
sourcetype = SA-ldapsearch
DATETIME_CONFIG = CURRENT

🌟 Did this answer help you? If so, please consider:

  • Adding karma to show it was useful
  • Marking it as the solution if it resolved your issue
  • Commenting if you need any clarification

Your feedback encourages the volunteers in this community to continue contributing

livehybrid
Super Champion

Hi @tech_g706 

If there are no fields in the event that you want to use as the _time field when it is ingested then I would recommend forcing the _time to be the ingestion time using the following props.conf update:

[yourSourcetype]
# Your other props here
# Set _time to current time
DATETIME_CONFIG = CURRENT

If you want one of the fields in the event to be _time then please share the full raw event and details of the field which should be _time.

🌟 Did this answer help you? If so, please consider:

  • Adding karma to show it was useful
  • Marking it as the solution if it resolved your issue
  • Commenting if you need any clarification

Your feedback encourages the volunteers in this community to continue contributing

richgalloway
SplunkTrust
SplunkTrust

What do you expect/want to see for capturetime?  None of the timestamps in the event seem appropriate and all of them will either throw a warning or cause a quarantine bucket to be created.

Please share the props.conf settings for that sourcetype.

---
If this reply helps you, Karma would be appreciated.
Get Updates on the Splunk Community!

Dashboards: Hiding charts while search is being executed and other uses for tokens

There are a couple of features of SimpleXML / Classic dashboards that can be used to enhance the user ...

Splunk Observability Cloud's AI Assistant in Action Series: Explaining Metrics and ...

This is the fourth post in the Splunk Observability Cloud’s AI Assistant in Action series that digs into how ...

Brains, Bytes, and Boston: Learn from the Best at .conf25

When you think of Boston, you might picture colonial charm, world-class universities, or even the crack of a ...