We have Access controls on in our Dev environment that allow users to create Dashboard based on data, searches, etc.
When a user creates a Dashboard it is defaulting the permissions to private so no other users or able to login and see the newly created dashboard. When I log on using my Admin or Root account and go do dashboards I'm still unable to see the dashboard.
I'm then stuck going to Settings -> User Interface -> Views and manually changing the permissions.
I believe this has something to do with what capabilities the User role has but I'm not sure which to assign based on what's contained within the authorize.conf or through http://docs.splunk.com/Documentation/Splunk/6.0.1/Security/Rolesandcapabilities
Any advice is appreciated. Currently the user role has these capabilities:
change_own_password
get_metadata
get_typeahead
input_file
list_inputs
output_file
request_remote_tok
rest_apps_view
rest_properties_get
rest_properties_set
rtsearch
schedule_rtsearch
schedule_search
search
Thank you!
After some more investigation this would be a much better solution:
http://docs.splunk.com/Documentation/Splunk/6.0.1/AdvancedDev/SetPermissions
Every user has their own user directory, so if they create a saved search, for example, it lives in their user directory. Users can promote objects from their users level to the app level -- but only if they have write permissions on the app. When a user shares an object by promoting it, Splunk actually moves the object on the filesystem from the user directory to the app directory. For example, if a member of the Ops team creates a saved search, it lives in their user directory unless they specifically share it with a given app. Then, it is available to all users who have read access within that app.
So to summarize....
Giving users write permissions to the Search App (or any Roles that you are inheriting "user" level permissions from) should alleviate having to give admin_all_objects to a user level role which could help getting the "I accidentally deleted a production dashboard" call.
After some more investigation this would be a much better solution:
http://docs.splunk.com/Documentation/Splunk/6.0.1/AdvancedDev/SetPermissions
Every user has their own user directory, so if they create a saved search, for example, it lives in their user directory. Users can promote objects from their users level to the app level -- but only if they have write permissions on the app. When a user shares an object by promoting it, Splunk actually moves the object on the filesystem from the user directory to the app directory. For example, if a member of the Ops team creates a saved search, it lives in their user directory unless they specifically share it with a given app. Then, it is available to all users who have read access within that app.
So to summarize....
Giving users write permissions to the Search App (or any Roles that you are inheriting "user" level permissions from) should alleviate having to give admin_all_objects to a user level role which could help getting the "I accidentally deleted a production dashboard" call.
I've looked into this before, and the it seems you need to give the users the Admin_All_Objects role. I know it sounds excessive, but that's the only thing that seems to work.
admin_all_objects Access and modify any object in the system (user objects, search jobs, etc.). (Overrides any limits set in the objects.)
I was afraid that might be the case as that could be a bit too much control to give a typical user once this goes over into our production environment. I'll keep digging around.
Any additional help from the community is appreciated!