Mapping LDAP Roles

Search Guard
1

In an earlier question (Issues Configuring LDAP Authentication), I was unable to successfully authenticate to LDAP. I was able to resolve that issue, but now I’m having issues mapping AD groups to backend-role equivalents.

I.e., I’ve created the following roles in Search Guard by duplicating built-in roles from within the GUI and mapping them to the following backend roles (AD groups):

Role Duplicates Backend Role (AD Group)
APP-ELK-Admin SGS_ALL_ACCESS APP-ELK-Admin
APP-ELK-User SGS_KIBANA_USER APP-ELK-User

As you can see, I named the roles and mappings identically to the AD groups, for simplicity.

When users attempt to login, they get the following:

  • APP-ELK-Admin: Users in this group are able to login, but do not appear to have admin privileges (i.e., they are unable to see the Search Guard plugin in the left-hand toolbar and cannot update role configurations).
  • APP-ELK-User: Users in this group are unable to login, they get a 403/Forbidden.

I’ve included the definitions from the two files below:

sg_roles.yml

# Direct copy of SGS_ALL_ACCESS
APP-ELK-Admin:
  reserved: false
  hidden: false
  description: "Allow full access to all indices and all cluster APIs"
  cluster_permissions:
  - "*"
  index_permissions:
  - index_patterns:
    - "*"
    fls: []
    masked_fields: []
    allowed_actions:
    - "*"
  tenant_permissions:
  - tenant_patterns:
    - "*"
    allowed_actions:
    - "*"
  static: false

# Direct copy of SGS_KIBANA_USER
APP-ELK-User:
  reserved: false
  hidden: false
  description: "Provide the minimum permissions for a kibana user"
  cluster_permissions:
  - "SGS_CLUSTER_COMPOSITE_OPS"
  index_permissions:
  - index_patterns:
    - ".kibana"
    - ".kibana-6"
    - ".kibana_*"
    fls: []
    masked_fields: []
    allowed_actions:
    - "SGS_DELETE"
    - "SGS_INDEX"
    - "SGS_MANAGE"
    - "SGS_READ"
  - index_patterns:
    - "*:.management-beats"
    - "*:.tasks"
    - ".management-beats"
    - ".tasks"
    fls: []
    masked_fields: []
    allowed_actions:
    - "SGS_INDICES_ALL"
  tenant_permissions: []
  static: false

sg_roles_mapping.yml

APP-ELK-Admin:
  reserved: false
  hidden: false
  backend_roles:
  - "APP-ELK-Admin"
  hosts: []
  users: []
  and_backend_roles: []
  description: ""

APP-ELK-User:
  reserved: false
  hidden: false
  backend_roles:
  - "APP-ELK-User"
  hosts: []
  users: []
  and_backend_roles: []
  description: ""
2

Can you send all Elasticsearch and Kibana log? Restart and record all log. Also, I need elasticsearcgh.yml, sg_config.yml, and kibana.yml.

3

I’ll PM everything to you.

4

Sergeii -

I set both Kibana and Search Guard to debug and captured logs. I PM’d the files to you.

In those files, I did the following tests:

  • Attempted login with user assigned to admin AD group: User was able to login, but did not appear to have any admin permissions.
  • Attempted login with local user assigned to same role as admin AD group: Same results as AD admin user attempting login.
  • Attempted login with user assigned to user AD group: User was unable to login.
  • Attempted login with local user assigned to same role as user AD group: Same results as AD user attempting login.

As far as I can tell, the issue appears to be with the roles.

When I review the logs, I find the following entry for the non-admin AD user in elk-es-coord-1.log (line 6810):

{"type": "server", "timestamp": "2020-05-07T17:21:15,202Z", "level": "WARN", "component": "c.f.s.c.PrivilegesInterceptorImpl", "cluster.name": "elk-es", "node.name": "elk-es-coord-1", "message": "Tenant SGS_GLOBAL_TENANT is not allowed for user jsmith", "cluster.uuid": "s2SUJJW_TJS7977zJJGpmQ", "node.id": "d74bPNTVS-2Kc6cm22455w"  }

I haven’t tested an updated role yet, but when I created this role, I just copied SGS_KIBANA_USER role which doesn’t have any specific tenant permissions. Any idea why one works, but not the other?

I’m not able to see anything corresponding to this for my admin users.

Again - this is all with Elasticsearch/Kibana 7.6.2, and I’ve updated SG to 41.0.0.

Thanks.

Edit 1

I gave my standard user role rights on SGS_GLOBAL_TENANT and users in that role now appear to have kibanaserver-equivalent rights. Not certain why I had to add the extra permissions, but it worked.

Edit 2

Gave my standard user role SGS_READ rights on * (similar to the SGS_READALL role), and now they can view indices, but can’t save visualizations, dashboards, or queries (which is what I would expect, since I’m duplicating a RO role). Any idea what rights I need to grant on which indices in order to do that?

5

Hi,

there are a couple of issues and questions, let me try go through them one by one:

“APP-ELK-Admin : Users in this group are able to login, but do not appear to have admin privileges (i.e., they are unable to see the Search Guard plugin in the left-hand toolbar and cannot update role configurations).”

The REST API can be used to change security-related settings, thus you need to configure explicitly which roles should have access to what endpoints. You can grant access on a global level (e.g. give a role full access to all API endpoints), or you can do that on a finer-grained level. For example, define that a role should only have read access, but should not be able to change anything.

In your case you would need to grant access to the APP-ELK-Admin Search Guard role. In ellasticsearch.yml, add:

searchguard.restapi.roles_enabled: ["APP-ELK-Admin"]

More details on API access control can be found here: Access Control | Security for Elasticsearch | Search Guard

" I gave my standard user role rights on SGS_GLOBAL_TENANT and users in that role now appear to have kibanaserver-equivalent rights. Not certain why I had to add the extra permissions, but it worked."

Usually we advise users to map all Kibana users to the SGS_KIBANA_USER role. This is mainly due to how tenants and multi tenancy is implemented. If you use that role, permissions are handled automatically by Search Guard. If you define your own role, you need to add the tenants (in this case the global tenant) manually. May I ask why you want to re-define the SGS_KIBANA_USER role and replace it with your own? What would be the use case for it?

“Gave my standard user role SGS_READ rights on * (similar to the SGS_READALL role), and now they can view indices, but can’t save visualizations, dashboards, or queries (which is what I would expect, since I’m duplicating a RO role). Any idea what rights I need to grant on which indices in order to do that?”

I don’t know if I understand this question correctly, but: In Kibana, dashboards, visualizations and queries are so-called “saved objects”. They are stored in the .kibana index, or, in case Kibana already ran index migrations, in an index .kibana_1, .kibana_2 etc. This is why the standard SGS_KIBANA_USER role handles access to saved objects via the tenant settings.

To make a long story short, I would advise you:

  • to map your AD Kibana users to the SGS_KIBANA_USER role (for handling access to Kibana related objects)
  • in addition to that, map the users to your self-defined roles which only need to define access permissions to data indices, but do not need to define anything special regarding Kibana

Let me know if this helps or if I probably misunderstood your questions or your use case! Thx!

1 Like
6

I will update this in elasticsearch.yml and let you know.

The reason for defining a new role is that (as far as I can tell) there is no way to map an AD user to the SGS_KIBANA_USER role, while granting access based on AD group membership, which is the biggest reason I’m using LDAP - our company’s security team are experts in managing users, I am not. :grinning:

Please correct me if I’m wrong on this, which I hope I am, as being able to assign AD groups to the built-in roles will make my life sooooo much easier.

However, the way I understand it, LDAP authentication treats AD group membership as a backend role, which SGS_KIBANA_USER and the built-in admin role also are. There does not appear to be any way that I can map an AD group to built-in roles without either setting it to reserved: False or adding the AD group to it in the sg_roles_mapping.yaml.

I prefer not to do the first, because I don’t want another admin to come along and accidentally delete that role, and I prefer not to do the latter, because then it’s not obvious from within the UI where the roles are being mapped.

You absolutely understood my use cases, but I don’t think I adequately explained why I’m doing things the way I’m doing them. Hopefully this gives you enough of that information that you can correct any false assumptions I may be operating under.

One thing that I will note that is a little frustrating, however, is that duplicating a built-in role exactly (i.e., cloning it) and mapping a group to it should exactly duplicate the functionality of that role.

Thanks!

7

I updated the mappings in sg_roles_mapping.yml, then loaded it, and everything is now functioning as expected.

Thanks for the assist.

8

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.