how to create application specific user roles. I have multiple applications, need to keep an set of users to perform read and another set of users to write. but the same set of users may required edit permission on the other applications.
Example
user1 - app1_read, app2_power, app3_read
user2- app1_read, app2_read, app3_power
user3 - app1_power,app2_read, app3_read
app_read - can only access like basic user
app_power - can edit the knowledge objects and update the permission of other users like (admin).
thanks,
Typically this is how I do it.
I will create apps for each integration. Lets say we're pulling in windows event logs from a sharepoint team's farm...
myorg_sharpoint_inputs - contains inputs.conf settings (goes to forwarders only)
myorg_sharepoint_props - contains props.conf and transforms.conf (goes to forwarders and indexers)
myorg_sharepoint_search - contains authorization settings, dashboards, search time knowledge objects (props and transforms too), etc (goes to search heads only)
In myorg_sharepoint_search i will include the following files in /default (you may chose to use /local instead, depending on your needs):
authorize.conf
authentication.conf
authorize.conf will contain something like this:
[role_sharepoint_indexes]
srchIndexesAllowed = sharepoint_windows_eventlogs
srchIndexesDefault = sharepoint_windows_eventlogs
...
[role_sharepoint_app_read]
...
[role_sharepoint_app_write]
...
[role_sharepoint_user]
importRoles = role_sharepoint_app_read, role_sharepoint_indexes
...
[role_sharepoint_power]
importRoles = role_sharepoint_user, role_sharepoint_app_write, role_sharepoint_indexes
And authentication.conf will contain something similar to this:
[roleMap_LDAPsTRATEGYnAME]
role_sharepoint_user = sharepoint_user_group_name_in_ldap
role_sharepoint_power = sharepoint_power_group_name_in_ldap
And also i create a metadata folder with default.meta like this:
[]
access = read : [ role_sharepoint_app_read ], write : [ role_sharepoint_app_write, admin ]
export = none
I do this for every integration, and specify other stuff in power/user roles in relation to their other capabilities.. (like schedule_rtsearch = disabled, etc.)
I typically clone the out of the box power & user profiles and then reduce the capabilities according to what the requirements are. So you'll notice im not importing power or user roles
Sometimes I have a further need for something like role_sharepoint_groupA_filter in case I need to give different groups of users within the sharepoint team different search filters.
So in conclusion a good model for "personas" is to have a role for each of the following:
Index Access
Application Access
Splunk Capabilities
Search Filters
So that someone can be a member of multiple roles in case they manage more than one team, require access to more than just their team's data, and many other reasons.
@davesplunk01 - Did the answer provided by jkat54 help provide a working solution to your question? If yes, please don't forget to resolve this post by clicking "Accept". If no, please leave a comment with more feedback. Thanks!
Typically this is how I do it.
I will create apps for each integration. Lets say we're pulling in windows event logs from a sharepoint team's farm...
myorg_sharpoint_inputs - contains inputs.conf settings (goes to forwarders only)
myorg_sharepoint_props - contains props.conf and transforms.conf (goes to forwarders and indexers)
myorg_sharepoint_search - contains authorization settings, dashboards, search time knowledge objects (props and transforms too), etc (goes to search heads only)
In myorg_sharepoint_search i will include the following files in /default (you may chose to use /local instead, depending on your needs):
authorize.conf
authentication.conf
authorize.conf will contain something like this:
[role_sharepoint_indexes]
srchIndexesAllowed = sharepoint_windows_eventlogs
srchIndexesDefault = sharepoint_windows_eventlogs
...
[role_sharepoint_app_read]
...
[role_sharepoint_app_write]
...
[role_sharepoint_user]
importRoles = role_sharepoint_app_read, role_sharepoint_indexes
...
[role_sharepoint_power]
importRoles = role_sharepoint_user, role_sharepoint_app_write, role_sharepoint_indexes
And authentication.conf will contain something similar to this:
[roleMap_LDAPsTRATEGYnAME]
role_sharepoint_user = sharepoint_user_group_name_in_ldap
role_sharepoint_power = sharepoint_power_group_name_in_ldap
And also i create a metadata folder with default.meta like this:
[]
access = read : [ role_sharepoint_app_read ], write : [ role_sharepoint_app_write, admin ]
export = none
I do this for every integration, and specify other stuff in power/user roles in relation to their other capabilities.. (like schedule_rtsearch = disabled, etc.)
I typically clone the out of the box power & user profiles and then reduce the capabilities according to what the requirements are. So you'll notice im not importing power or user roles
Sometimes I have a further need for something like role_sharepoint_groupA_filter in case I need to give different groups of users within the sharepoint team different search filters.
So in conclusion a good model for "personas" is to have a role for each of the following:
Index Access
Application Access
Splunk Capabilities
Search Filters
So that someone can be a member of multiple roles in case they manage more than one team, require access to more than just their team's data, and many other reasons.