Security

How do I restrict which apps are visible to a specific AD group?

Engager

Hi

I have set up an app that is only accessible to a certain AD group. There are a lot of apps on my Splunk instance which are not necessary for this user group. I don't want that group to be able to see the other apps on my Splunk instance. How do I restrict which apps are visible to certain AD groups?

0 Karma
1 Solution

Path Finder

In authorize.conf (or through UI) create a new role for your AD group to map to. In authentication.conf (or through UI) map that other AD group to that role that will be used to restrict access. This role will be different from YOUR role, which will not be restricted (I will assume the ADMIN role here) but you'll need to know your role as well.
authorize.conf

[role_admin]
#other configs that are relevant to your environment

[role_restricted_access_role_name]
importRoles = appropriate_roles_for_your_environment
#other configs that are relevant to your environment

authentication.conf

[roleMap_AD_Strategy_Name]
admin = YOUR_AD_GROUP_NAME
restricted_access_role_name = RESTRICTED_AD_GROUP_NAME

Then you'll need to set up metadata configs that will allow you to limit who can have read access in each of those apps. Inside of the app that you don't want to have this restricted group view, make a metadata folder, and then add a default.meta file.

$SPLUNK_HOME/etc/apps/RestrictedSearchHeadAppName/metadata/default.meta

 []
 access = read : [ admin, other_allowed_roles ], write : [ admin, other_allowed_roles ]

With the above configs, anyone in the admin and otherallowedroles roles and associated AD groups would have both read and write access to the RestrictedSearchHeadAppName app, but anyone that is in the restrictedaccessrole_name role would not be able to access or even see that search head app.

View solution in original post

Engager

Thank you all for answering my question. I see the answer was basically to just remove read access for my role to other access. Which I suppose makes a lot of sense. I accepted thsplunkmonkey's answer as it was the most detailed.

0 Karma

Path Finder

In authorize.conf (or through UI) create a new role for your AD group to map to. In authentication.conf (or through UI) map that other AD group to that role that will be used to restrict access. This role will be different from YOUR role, which will not be restricted (I will assume the ADMIN role here) but you'll need to know your role as well.
authorize.conf

[role_admin]
#other configs that are relevant to your environment

[role_restricted_access_role_name]
importRoles = appropriate_roles_for_your_environment
#other configs that are relevant to your environment

authentication.conf

[roleMap_AD_Strategy_Name]
admin = YOUR_AD_GROUP_NAME
restricted_access_role_name = RESTRICTED_AD_GROUP_NAME

Then you'll need to set up metadata configs that will allow you to limit who can have read access in each of those apps. Inside of the app that you don't want to have this restricted group view, make a metadata folder, and then add a default.meta file.

$SPLUNK_HOME/etc/apps/RestrictedSearchHeadAppName/metadata/default.meta

 []
 access = read : [ admin, other_allowed_roles ], write : [ admin, other_allowed_roles ]

With the above configs, anyone in the admin and otherallowedroles roles and associated AD groups would have both read and write access to the RestrictedSearchHeadAppName app, but anyone that is in the restrictedaccessrole_name role would not be able to access or even see that search head app.

View solution in original post

Path Finder

You would edit your metadata on that app to read for the specific group as opposed to everyone. The assumption that the AD group is mapped to a specific role.

Builder

You would map your AD groups to user roles (role=AD groups) .

Then in the App permissions, you would remove read access from "everyone" and assign it to only those roles (roles=AD groups) you want to have access to those app.

When you configure the role, you can set the default app for those users, indexes they can search, and capabilities.

https://docs.splunk.com/Documentation/Splunk/7.3.1/Admin/Aboutusersandroles