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:
Thanks!
Chris Bowles
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 :
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.
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.
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 :
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.
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.