Help with Search != litsearch --- In 'litsearch' there are extra unwanted key=value statements

[dural_yyz]

We are spending a tremendous amount of time tuning our search structures lately. One thing we have run across in our Enterprise Security environment is an unwanted key=value in litsearch when reviewing the job board.

SPL

index=any-index-value sourcetype=any-sourcetype-value

litsearch

(index=any-index-value (sourcetype=any-sourcetype-value OR sourcetype=never-mentioned-value))

This 'never-mentioned-value' is always the same regardless of index or sourcetype we place in the SPL.  Things I have checked for:

- props-lookups: No 'sourcetype as x' on input side OR 'x as sourcetype' on output side

- props-EVAL-sourcetype = case(x,never-mentioned-value), this exists in our prod but same config in lower environment did not trigger the same action (will be removing this shortly after next push cause I just don't like it)

- TRANSFORMS - can not find any items of interest here

I have tried the following alternative searches

index=any-index-value

OR

index=any-index-value sourcetype::any-sourcetype-value

In both of the above SPL the 'extra' sourcetype key=value does not appear in the litsearch.  I do understand the differences in indexed fields and how the searches above are not triggering the addition key=value.

What I need help/direction/input is how do I track down the errant conf edit that is resulting in additional litsearch values when the SPL contains 'sourcetype='.

[mschaaf]

This could be due to your account having one or more roles that is assigned a srchFilter or imported_srchFilter.  This rest query will list any assigned to your role(s):

| rest splunk_server::local /services/authorization/roles/ 
| stats values(*srchFilter*) AS *srchFilter* by title 
| rename title AS role 
| append 
    [ rest splunk_server::local /services/authentication/current-context 
    | stats values(roles) AS role by username 
    | mvexpand role ] 
| stats values(*srchFilter*) AS *srchFilter* 
    values(username) as username
    by role 
| search username=* (srchFilter!="" OR imported_srchFilter!="")

[dural_yyz · Accepted solution]

Thank you for bumping this up again as I had forgotten about it.

Your suggestion was a good idea for me to check but search filters are not something we have implemented in our environment so the values are blank or wildcard.

Turns out I was able to solve this by finding the errant sourcetype props.  Under that was the following code.

[existing:sourcetype]
....
EVAL-sourcetype = case(value_doesnt_occur,"existing:sourcetype")

I commented out this EVAL.  Since it was only defined under the final value it would never actually execute.  However since part of the environment felt that sourcetype was an extracted value and not an indexed field this must be what was causing the litsearch to mysteriously add the content into the search string.

The app came built by the vendor and not splunk and since the key = value does not violate any patterns I assumed the app would pass validation checks.  I think this comes down to down mix extracted fields with indexed fields for best practice.

FYI - we have also carried this forward and re-written many of our eventtype tags so that the raw search does not contain any extracted field references which are also data model destination field names.( ie Eventtypes raw search does not contain action=x or user=y statements).  I would only do this in very large environments with processing or search tuning requirements - don't fix if it aint broke!