Filter/Decision block from within an Input playbook

[JackTheRipper]

Hey, consider a scenario where you want to create a reusable input playbook that takes advantage 

of the condition blocks such as Filter&Decision. 

For example, an input playbook that receives an ip_hostname, then queries AD over LDAP to check whether the ip_hostname is in a specific OU. that would be easily achievable using Filter/Decision normally, but since its in an input playbook, I haven't seen any output parameters that u can then use as in a main playbook to find out whether the condition was true or false. 

Thanks in advance

[phanTom]

Again, there are many ways to do things in SOAR and we're just trying to give you ideas. 

Sometimes the work needed to build re-usable playbooks, if it's just 1 action and 1 filter/decision, isn't worth not adding it into the main playbook each time as it takes just as much time to input the inputs to the action/decision than an input playbook. 

It depends really on what you are wanting to do with the True/False items?

If true ones are sent to another action then yes, just use the input playbook to work out True and then output a list of them for use later. If you want to get more complicated you can as playbooks allow that. 

[JackTheRipper]

the filter/decision blocks doesnt have an output variable that tells you which route it took natively that you can use as a result... 

[SOARt_of_Lost]

I understand now. If the only thing you need to do is evaluate whether the user exists or not, and there are no actions you need to take down either branch, I'd say a simple custom code block is the way to go. Filter and decision blocks are more useful for deciding a path for the playbook to continue down.

Something along the lines of

if user exists:
    output_variable = True
else:
    output_variable = False

[JackTheRipper]

custom code block? we are talking about an app action it may vary and a custom code block is not suitable here without further interactions -_- also what if there are 10 different paths, filter/decision simply should result in what path was derived from the condition... just like in ansible

[phanTom]

Why not have the input playbook act as a filter and anything that matches your requirement come as an one output and if you want, the others under another output? Then you can work out which was True and which was False?

OR tag/update the artifact that contains the value with something to indicate the result of the check?

There are many ways to do things in SOAR just depends how janky you want to get!

[JackTheRipper]

I didnt quite understand what you mean, you are saying for example the input will return the OU of the domain computer and then in automation playbooks I filter it based on the value? if yes, that kinda defeats the purpose of input playbooks?

[jenniandthebets]

I think what you may be looking for is something like the following:

1. Action block that queries AD for the OU the object is in. 
   1. The object (ip_hostname in your example) is configured as the input at the start of the playbook
2. Decision Block checking if the OU matches your condition
   • My org had some trouble with these initially, you should configure these like below (rather than the opposite direction,  which is what we were trying initially)

if <artifact_datapath> == <the OU you're trying to match>​

3. Each path on your decision block then has a custom code block. You'll need to configure an output variable for the custom block themselves and set it to either True/False 

4. The output of your entire playbook will be set to the variable you configured in step 3.

[JackTheRipper]

what you said doesnt make sense, in the end I can only choose one variable to return so all of the custom blocks must share the same variable, change it on -the-fly depends on the passed result. sure you can use a custom function e.g passthrough for that but that seems so unnecessary for such a simple task,  thanks anyways I understand the only solutions arent quite built-in 

[SOARt_of_Lost]

I'm not entirely clear what the problem is here since you decide what the outputs are when building an input playbook. Working off your example, I would say it's better to have the input playbook determine whether the user exists, output that result, then make any decisions in the parent playbook.