Users with multiple Splunk Roles

[cbowles]

I've got a Splunk Installation with multiple independent Splunk Roles that grant access to individual indexes and also list that index as the default search index. My assumption was that the SrchIndexesDefault field would be OR'd between the various group memberships, similar to how the srchFilter works, so that the final default search indexes would be the combination of all of the individual groups.

However, I have found that instead it is the final Splunk group that provides the SrchIndexesDefault value.

I.e. if the user was a member of foo and goo , it would be the SrchIndexesDefault from goo that would apply to the user.

Two questions:

1. Am I missing something here, or is this implementation of SrchIndexesDefault working as designed?
   
2. What is the recommended manner for granting access to multiple independent indexes? I am considering creating higher-level groups that inherit the values of the lower level groups, but I would prefer to preserve my building block approach if possible.

Thanks!

Chris Bowles

[cbowles]

Followup - Problem Resolved

At it turns out, Splunk was working as advertised. The problem observed was the result of two different configurations interacting in an unexpected way.

The user in question had been granted access to the index in question via a Splunk Group that had only granted access (but not set the index as a "default search") The group that was supposed to grant access and set the index as default was not being used since its corresponding Active Directory group was empty.

Under the assumption that the specific group was working correctly, the only explanation was that there was a Splunk bug with how the SrchIndexesDefault variable was being combined for the user.

Once I discovered that the user was being given access to the index through a group that did not set the SrchIndexesDefault variable, the pieces fell into place.

I rectified the config and test, and Splunk worked correctly.

[yannK · Accepted solution]

Please differentiate srchIndexesAllowed and SrchIndexesDefault, the first one contains the real permissions, the second one can be easily bypassed at search time with by index=*.

According to the docs : "Members of multiple roles inherit properties from the role with the broadest permissions."

So if user has the foo and goo :

• foo SrchIndexesDefault=A
• goo SrchIndexesDefault=B

at the end the user should be able to search on both A and B by default.

If this is not the case, please fill a support case.

[cbowles]

YannK,

I have verified that srchIndexesAllowed values are correctly being inherited, i.e. members of the foo and goo groups get the combination of the two:

foo -->srchIndexesAllowed=foo

goo --> srchIndexesAllowed=goo

ending with the user getting --> srchIndexesAllowed=foo,goo

However, the SrchIndexesDefault fields are not working in the same way. To use the example from above:

foo -->srchIndexesAllowed=foo

goo --> srchIndexesAllowed=goo

ending with the user getting --> srchIndexesAllowed=goo

Will file a support ticket.