Microsoft Azure Add-on for Splunk, AAD users input

[cornemrc]

Hello,

we try to ingest the sourcetype azure:aad:user (AAD users input) and face an issue with timestamping.

Other inputs are working fine, for example groups or sign-ins.

• Around 33k of our 105k users are indexed with the latest timestamp of the last input interval (86400 seconds, once a day),
• but 22k users are indexed with the fixed timestamp 11/28/17 9:06:37.900 AM (CET)
• 50k users are indexed with the fixed timestamp 3/9/18 8:01:24.400 PM (CET)

We do not see any reference to these two timestamps within the Azure Active Directory, therefore we think it is a Splunk related issue. We use Splunk 8.1.6 and the Microsoft Azure Add-on 3.2.0

Do you have any idea to explain or change this behaviour?

[deckemha · Accepted solution]

Hello,

we were able to solved it by adding this to the local/props.conf on the heavy Forwarder where the azure app is running.

[azure:aad:user]
DATETIME_CONFIG = CURRENT

The issue was not 100% narrowed down, but we could see some errors in the log channel "DataParserVerbose" with this SPL

index=_internal host=<Hostname of the Heavy Forwarder> component=DateParserVerbose azure:aad:user

 e.g. messages about failed timpstamp extraction

01-19-2022 11:54:40.885 +0100 WARN  DateParserVerbose - Failed to parse timestamp in first MAX_TIMESTAMP_LOOKAHEAD (128) characters of event. Defaulting to timestamp of previous event (Fri Mar  9 20:01:24 2018). Context: source=tenant_id:xxxxxxxxxxxxx|host=xxxxxxxxxxxxx|azure:aad:user|\r\n

01-19-2022 11:51:58.536 +0100 WARN  DateParserVerbose - A possible timestamp match (Tue Jan 29 11:07:03 2002) is outside of the acceptable time window. If this timestamp is correct, consider adjusting MAX_DAYS_AGO and MAX_DAYS_HENCE. Context: source=tenant_id:xxxxxxxxxxxxx|host=xxxxxxxxxxxxx.schaeffler.com|azure:aad:user|\r\n				1 similar messages suppressed.  First occurred at: Wed Jan 19 11:46:56 2022

We think Splunk did try to parse the timestamp somewhere out of the data, but there was actually not real timestamp in the data.

So with the above mentioned solution, we force Splunk to use the actual timestamp all the time. This is what we want.

Many Regards

Michael