Using a single variable as a value to multiple fields in SPL

[NatSec]

I have a working dashboard where a token is used as a variable. But now I am trying to use the same concept when making a direct search within "Search & Reporting app".  I have Windows events that have multiple fields that produce a common value. In this example, the following search will give me usernames.

...base search (member_dn=* OR member_id=* OR Member_Security_ID=* OR member_user_name=*)

I would like to declare a variable that I can use as a value to search all four aforementioned fields.

I tried the following with no luck:

index=windows_logs | eval userid=johnsmith | where $userid$ IN (member_dn, member_id, Member_Security_ID, member_user_name)

[PickleRick]

You're thinking about this too much as a "programming" exercise.

SPL works differently. A bit like a bash one-liner (I suppose the pipe chars in the SPL syntax weren't chosen randomly ;-))

So please be a bit more descriptive about what you want to do with those four fields returned from the ldapsearch.

[yuanliu]

Pro tip: "no luck" and "doesn't work" are bad words in a discussion forum as they convey little information in best case scenario.  If I have to read your mind, the second search returns no result.  Is this correct?

Before diagnosing the second search, I want to delve into the first one first.  What's wrong with simply plugging your token in that one?

...base search (member_dn=$userid$ OR member_id=$userid$ OR Member_Security_ID=$userid$ OR member_user_name=$userid$)

Not only is this the simplest way you can express your condition, but it is also more efficient.

As to your second one, it does not express what you think it "should" do.  When the compiler sees a token in a search, it simply substitute it with the current value in that token space.  Suppose your user sets $userid$ to joeshmoe.  After compilation, the SPL engine sees this expression:

index=windows_logs
| where joeshmoe IN (member_dn, member_id, Member_Security_ID, member_user_name)

It is highly unlikely for your data set to have a field named joeshmoe AND this field has some values that equal to one of those four fields.  It is much more likely that member_dn, member_id, Member_Security_ID, or member_user_name in your dataset has a literal value of "joeshmoe".

In SPL, all eval expressions treat bare words as either a function name or a field name, not string literal. (As such, the second phrase in that second search, | eval userid=johnsmith, assigns a null value to userid.)   So, if you want to use the where command instead of plugging the token into index search, quote the token properly:

index=windows_logs
| where "$userid$" IN (member_dn, member_id, Member_Security_ID, member_user_name)

I still recommend the first one, however. (Note: search (implied in the first line) is one of few SPL commands that interprets bare words as literals unless they explicitly appear in the left-hand side of a search operator such as = and IN.

Hope this helps.

[richgalloway]

Tokens ($something$) cannot be used in SPL except in the map command.  They're not necessary, however.  Just use a field.

index=windows_logs 
| eval userid=johnsmith 
| where in(userid,member_dn, member_id, Member_Security_ID, member_user_name)

 Notice I changed the where command since it does not support the IN operator.

[NatSec]

Let me add more context. In this example, "userid" is not a field but a variable that I intend to use as a search value from the four fields.  The four fields are:

member_dn, member_id, Member_Security_ID, member_user_name

[richgalloway]

In SPL, there's no such thing as a "variable".  We call them "fields".