# Document level Security **URL:** \ **Category:** Elasticsearch\ **Created:** [March 24, 2017, 11:00am UTC](https://discuss.elastic.co/t/document-level-security/79876 "2017-03-24T11:00:01Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![tausif786](https://avatars.discourse-cdn.com/v4/letter/t/bb73d2/32.png) [@tausif786](https://discuss.elastic.co/u/tausif786)\ **Post date:** [March 24, 2017, 11:00am UTC](https://discuss.elastic.co/t/document-level-security/79876/1 "2017-03-24T11:00:01Z")
Hi Everyone, Active Directory Authentication is enabled in my ELK stack. Now i want a AD user for eg user= 'John' to see only data for country='US' how can i achieve that please help. Regards, Tausif Khan. ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [March 24, 2017, 11:18am UTC](https://discuss.elastic.co/t/document-level-security/79876/2 "2017-03-24T11:18:52Z")
You want to read: [https://www.elastic.co/guide/en/x-pack/current/field-and-document-access-control.html](https://www.elastic.co/guide/en/x-pack/current/field-and-document-access-control.html) ---
**Author:** ![tausif786](https://avatars.discourse-cdn.com/v4/letter/t/bb73d2/32.png) [@tausif786](https://discuss.elastic.co/u/tausif786)\ **Post date:** [March 24, 2017, 11:46am UTC](https://discuss.elastic.co/t/document-level-security/79876/3 "2017-03-24T11:46:36Z")
I read it but couldn't understand much can i do the same in kibana GUI, under management section ? ---
**Author:** ![tausif786](https://avatars.discourse-cdn.com/v4/letter/t/bb73d2/32.png) [@tausif786](https://discuss.elastic.co/u/tausif786)\ **Post date:** [March 24, 2017, 11:53am UTC](https://discuss.elastic.co/t/document-level-security/79876/4 "2017-03-24T11:53:41Z")
I couldn't find in that document related to the query which i asked , could you please help with the query rather then the link. ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [March 24, 2017, 4:01pm UTC](https://discuss.elastic.co/t/document-level-security/79876/5 "2017-03-24T16:01:37Z")
I don't have a laptop nearby but IIRC the Kibana interface there is this option in user management UI. May be someone else can give more details ---
**Author:** ![jetnet](https://avatars.discourse-cdn.com/v4/letter/j/a87d85/32.png) [@jetnet](https://discuss.elastic.co/u/jetnet)\ **Post date:** [March 25, 2017, 10:51am UTC](https://discuss.elastic.co/t/document-level-security/79876/6 "2017-03-25T10:51:01Z")
the role query should be very simple: ``` {"term" : { "country" : "US" }} ``` And we have two options here: - you have the correct role mapping in the AD realm section: role\_mapping.yml: ``` role_name: - "CN=johns_group,dc=corp,dc=org" ``` OR - put this parameter `unmapped_groups_as_roles: true` to your AD config section and make sure the role name is one of the group the user "John" belongs to ---
**Author:** ![TimV](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timv/32/13162_2.png) [@TimV](https://discuss.elastic.co/u/TimV)\ **Post date:** [March 27, 2017, 12:29am UTC](https://discuss.elastic.co/t/document-level-security/79876/7 "2017-03-27T00:29:12Z")
> [@jetnet](#): > > role\_mapping.yml: [...] > OR > [...] unmapped\_groups\_as\_roles: true While `unmapped_groups_as_roles` can be useful in a small number of cases, it really should be avoided unless you absolutely need to use it. The `role_mapping.yml` approach is the preferred solution in this case. ---
**Author:** ![jetnet](https://avatars.discourse-cdn.com/v4/letter/j/a87d85/32.png) [@jetnet](https://discuss.elastic.co/u/jetnet)\ **Post date:** [March 27, 2017, 6:38am UTC](https://discuss.elastic.co/t/document-level-security/79876/8 "2017-03-27T06:38:35Z")
Any particular reason, why it should be avoided? From my point of view, it's a very cool feature - all groups can be managed in AD directly, and you don't need to manage one additional mapping file (role\_mapping.yml). And nested groups are supported! The only concern I could imaging - a security issue: if you create the "superuser" group and include your user into it, you'll get full access to the cluster. Any other pitfalls?.. ---
**Author:** ![tausif786](https://avatars.discourse-cdn.com/v4/letter/t/bb73d2/32.png) [@tausif786](https://discuss.elastic.co/u/tausif786)\ **Post date:** [March 27, 2017, 6:40am UTC](https://discuss.elastic.co/t/document-level-security/79876/9 "2017-03-27T06:40:30Z")
Could you please assist on your way of approach. ---
**Author:** ![TimV](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timv/32/13162_2.png) [@TimV](https://discuss.elastic.co/u/TimV)\ **Post date:** [March 27, 2017, 11:38pm UTC](https://discuss.elastic.co/t/document-level-security/79876/10 "2017-03-27T23:38:08Z")
> [@jetnet](#): > > Any particular reason, why it should be avoided? There are security, performance and maintainability impacts that are sometimes a necessary price to pay, but we find that a lot of people turn on `unmapped_groups_as_roles` as a trivial convenience - a way to avoid editing a file once or twice - and don't appreciate or consider the impacts on their cluster. Some of the consequences to consider when using `unmapped_groups_as_roles`: - Your are delegating full security access to your cluster to the administrators of the directory. If an AD admin adds a user to a `superuser` group in AD, then they get the `superuser` role in Elasticsearch, and you can't prevent it. - You have to plan you group/role naming well, or you will run into unintended overlaps or misaligned roles. Generally speaking, an AD admin will assume that creating a brand new group in the directory and assigning it to a user is a totally safe operation, and will not affect dependent applications. But if `unmapped_groups_as_roles` is enabled, then any new group that matches with an Elasticsearch role will unintentionally change the user's Elasticsearch permissions. - If a user has a large number of AD groups then Elasticsearch needs to try and load a role for each one of them, even though that role probably doesn't exist. This overhead is larger than you might expect it to be. `unmapped_groups_as_roles` has uses, but it's not completely safe in all cases, so if you're just using it to avoid editing `role_mapping.yml` then that's often the wrong trade-off. ---
**Author:** ![jetnet](https://avatars.discourse-cdn.com/v4/letter/j/a87d85/32.png) [@jetnet](https://discuss.elastic.co/u/jetnet)\ **Post date:** [March 28, 2017, 7:34am UTC](https://discuss.elastic.co/t/document-level-security/79876/11 "2017-03-28T07:34:39Z")
Thank you very much for the comprehensive reply, I really appreciate that. 1. yes, the security issue is a very important one, I asked already here, on some other topic, that would be great, if you could extend the AD configuration by adding a black (or white-) -list feature, so, only the AD groups, let's say, containing _ELK_ would be mapped. 2. the group naming should not be an issue, as, from my experience, all modern organizations use naming standards on their infrastructure already. 3. large number of AD groups - yes, that's true, an account has a lot of AD groups usually. But I thought, since the groups get cached, it shouldn't impact on performance much. Ok, we'll check the time spent on mapping from the `authc` trace-logs. Thanks a lot! ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [April 25, 2017, 7:35am UTC](https://discuss.elastic.co/t/document-level-security/79876/12 "2017-04-25T07:35:04Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.