Mapping LDAP Groups to Roles

Elastic Stack Elasticsearch
1

I have the below ldap config in elasticsearch.yml

xpack:
  security:
    authc:
      realms:
        ldap1:
          type: ldap
          url: "ldap://ldap:389"
          bind_dn: "cn=admin,dc=vqcomms"
          bind_password: "password"
          user_search:
            base_dn: "ou=50users,dc=vqcomms"
            attribute: uid
          unmapped_groups_as_roles: true

I can log into Kibana as a user defined in the 50users group but the user doesn't have any permissions to do anything. I've tried mapping groups to roles but it doesn't seem to work because logging out and back in again I still have no permissions. Below are the mappings I have which is a result of trying various mapping configurations.

{
  "admins": {
    "enabled": true,
    "roles": [
      "monitoring",
      "user",
      "kibana_user"
    ],
    "rules": {
      "field": {
        "groups": "ou=50users,dc=vqcomms"
      }
    },
    "metadata": {}
  },
  "50users": {
    "enabled": true,
    "roles": [
      "monitoring",
      "user",
      "kibana_user"
    ],
    "rules": {
      "field": {
        "groups": "ou=50users,dc=vqcomms"
      }
    },
    "metadata": {}
  },
  "ou=50users,dc=vqcomms": {
    "enabled": true,
    "roles": [
      "monitoring",
      "user",
      "kibana_user"
    ],
    "rules": {
      "field": {
        "groups": "ou=50users,dc=vqcomms"
      }
    },
    "metadata": {}
  }
}

ccing @forloop @ESamir

2

Hi,

My initial reaction is that this is because the role mapping API is whitespace and case sensitive. So if your LDAP server returns ou=50users, dc=vqcomms or OU=50users,DC=vqcomms for instance, the comparison will fail and the users will not get the role assignement.

You can enable

logger.authc.name = org.elasticsearch.xpack.security.authc
logger.authc.level = DEBUG

in log4j2.properties and log in again, the log output will allow us to verify that this is indeed what is happening and will give you the correct case and spacing for the Group DN to use in the role mapping API.

3

Thanks. Where is that file. I'm currently running under docker.

4

log4j2.properties is under $ES_HOME/config

You can also set it via the API :

PUT /_cluster/settings
{
  "transient": {
    "logger.org.elasticsearch.xpack.security.authc": "debug"
  }
}
5

You're trying to treat an ou as a group, but ...

you're also saying that ou is an ancestor (parent tree) for your users.

I think you're mixed up about LDAP trees vs groups.

A group is more likely to be something like cn=foo,ou=groups,dc=vqcomms

Your realm configuration doesn't include anything that describes how to lookup groups, which means it defaults to using the memberOf attribute. That will work on some LDAP directories, but not all. It's quite likely that you will need to configure the group_search settings in order to find groups within your directory. We can walk you through that process, but we'll need more information about your directory.

However, maybe you don't really care about groups. The example you used was just trying to assign a role based on the user's location in the directory tree. If that's all you want, then check the role mapping examples as there is an example there for checking a sub-tree.

6

Hi Thanks for the reply.

I got it working with your last suggestion:

PUT _xpack/security/role_mapping/test
{
  "roles": [
    "monitoring",
    "user",
    "kibana_user",
    "superuser"
  ],
  "rules": {
    "field": {
      "dn": "*,ou=50users,dc=vqcomms"
    }
  },
  "enabled": true
}

I know this is a different question but is there a way to store metadata for LDAP users in ES? I'm reading this (https://www.elastic.co/blog/attribute-based-access-control-with-xpack) and this shows storing security_attributes against users and this works fine for non ldap users. What would be the recommend approach for that, would it be storing metadata in the ldap server and then expose that via the realm configuration?

7

Nudge @TimV @ikakavas :slight_smile:

8

Yes, you can configure the LDAP realm to pull in any user property you need from the directory, and then add it to the ES user's metadata
See the metadata setting here.

9

Thanks @TimV

In your opinion would that be the only way to do the document level security. Only reason I ask is having to go to our customers saying we need you to store some metadata on your ldap server which we can then use in ES to do some security could be problematic for some enterprise customers.

10

It's not the only way, but the alternatives probably aren't going to suit you any better.

X-Pack doesn't store a shadow user for externally authenticated users, so there's no other place to store the metadata.

It's technically possible to do it through role mappings, but it may require a lot of roles and mappings.

11

@TimV thanks, you might prefer this as another question/thread. Can I set xpack up to point to my own API to do forms authentication and then set the current user and its metadata?

12

You can write your own custom authentication realm, but then you need to handle everything yourself. It's certainly possible, but you'd lose all the existing LDAP support.

It might make more sense to implement a custom roles provider.
Then you can just map every user to a role based on their userid, and dynamically build that role when they login.

13

@TimV We have a product with users in it. These users tend to come from LDAP so we import them into our product but we can authenticate users that way too. We now want to expose some users of our product to Kibana.

Our data is sensitive so certain people can only see certain documents. We got the demo working here https://www.elastic.co/blog/attribute-based-access-control-with-xpack and it fitted our scenario perfectly.

We then thought about using the ldap plugin for authentication but the downside to that is customers having to store our product's data in LDAP for future metadata use which I dont think they would do. We could mirror our users from LDAP into ES as normal users but obviously if they change their password on LDAP we can't mirror that to ES/Kibana and it falls down (You might be say it can be done).

We then thought about doing a custom authentication approach on the assumption that we could store the user and metadata in a cookie or something and ES/Kibana could be assigned the user and metadata that way.

I guess we're at a point where I'm not sure what the best approach is so with the above information any help would be appreciated

14

Nudge....help! :slight_smile:

15

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