LDAPSearch lastLogon doesn't return value

[Newb_KB]

I recently migrated from v8 to v9 for Splunk and I am having issues with ldapsearch not returning data that it had previously returned. I am trying to pull lastLogon for accurate tracking but this attribute will not return anything. lastLogontimestamp works but is too far out of sync for my requirements on reporting. I have LDAP configuration in the Active Directory add-on set to 3269 and everything else works fine except this one attribute. I setup delegation to read lastLogonTimestamp and then everything so its not a permissions issue from what I can see. Any help would be appreciated. 

[Newb_KB]

| ldapsearch domain=mine search="objectClass=user)"
| where isnull(isCriticalSystemObject)
| eval Enabled=if(match(userAccountControl,".*ACCOUNTDISABLE.*"),"False","True")
| eval expires=if(userAccountControl="DONT_EXPIRE_PASSWD","True","False")
| eval "Last Logon"=strftime(strptime(LastLogon, "%Y-%m-%dT%H:%M:%S.%QZ"),"%Y%m%d %H:%M:%S")
| eval lastLogon=strptime(LastLogon, "%Y-%m-%dT%H:%M:%S.%QZ")
| eval daysSincelogon=round((now()-lastlogon)/86400, 0)
| table sAMAccountName,Enabled,daysSinceLogon,"Last Logon",expires

When I upgraded to version 9 I had pulled all the latest add-ons from Splunk directly. The new instance was stood up and then add-ons were installed, I pulled over lookups, etc. after the fact. I inherited this system and very green to Splunk (1 month of experience).

[dural_yyz]

Splunk fields are case sensitive but given the opportunity for confusion it's typically not best practice to overlap spellings.  Unless the app specifically overlaps fields with case issues then I would avoid that.

However, it appears the SPL is all based from a field specifically referenced as "LastLogon".  I would look to see if that field still exists after the updated application.  It's possible the information still exists but is not being extracted into the previous field name which the SPL is relying on.

If so then you have the option to update the field extraction to that field name or update your SPL to reference any new fields that contain the information you require.

[Newb_KB]

I checked the Field Extraction section and did NOT find any reference to "Last Logon". Being new to Splunk this is where I am unsure where fields come from and how they work which is fine for now, something for me to research. 

I switched the SPL to the following and it still doesn't return the 'lastLogon' attribute from AD, would this be expected or should it in fact return the 'lastLogon' attribute? 

| ldapsearch domain=mine search="(objectClass=user)" attrs=sAMAccountName,lastLogon | table sAMAccountName,lastLogon

[dural_yyz]

| eval "Last Logon"=strftime(strptime(LastLogon, "%Y-%m-%dT%H:%M:%S.%QZ"),"%Y%m%d %H:%M:%S")
| eval lastLogon=strptime(LastLogon, "%Y-%m-%dT%H:%M:%S.%QZ")

Sorry about not having a better explanation.  "Last Logon" and "lastLogon" are being generated from a field "LastLogon" which I hope or assume is in the original data set.

"Last Logon" is a nested strptime inside a strftime.  The strptime takes and human readable format and converts to epoch, while the strftime will take epoch and convert to human readable.  The nested function here essentially converts the format from one human readable to another human readable.  There are easier methods but if it was working maybe don't change it until your skill level jumps.

"lastLogon" just takes the human readable format and converts to epoch(Unix) time - which makes duration calculations much easier.

Check that "LastLogon" field is still there and that the format still matches the "xxxx-xx-xxTxx:xx:xx.xxxZ" that the strptime command is configured to expect.  Also check to see if the time shift you are experience can be explain by the delta in your local time zone (either personal setting, or that of the Search Head).  It expects the raw data from the field to be in Zulu time.

[dural_yyz]

1) Can you share the exact SPL search

2) Did you upgrade/refresh the Add On when you upgrade from v8 to v9