# Using Active Directory for authentication and Native Realm for role mapping

**URL:** <https://discuss.elastic.co/t/using-active-directory-for-authentication-and-native-realm-for-role-mapping/68197>\
**Category:** Elasticsearch\
**Created:** [December 6, 2016, 4:36pm UTC](https://discuss.elastic.co/t/using-active-directory-for-authentication-and-native-realm-for-role-mapping/68197 "2016-12-06T16:36:08Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![ksoucy](https://avatars.discourse-cdn.com/v4/letter/k/dc4da7/32.png) [@ksoucy](https://discuss.elastic.co/u/ksoucy)\
**Post date:** [December 6, 2016, 4:36pm UTC](https://discuss.elastic.co/t/using-active-directory-for-authentication-and-native-realm-for-role-mapping/68197/1 "2016-12-06T16:36:09Z")

</div>

Is it possible to use an Active Directory realm for user authentication, and let the Native Realm do the user-to-role mapping in x-pack (5.0)?  
Elastic created this nice Kibana interface for adding users and roles and mapping user to roles, however when we configured AD for authentication (which authenticates properly) it appears the role mapping we had previously done in the Native Realm (via the Kibana interface) is ignored and users have essentially no permissions.  
We do not want to do any mapping of AD groups/domains/ou's to roles (via the role\_mapping.yml file) as our corporate AD mapping is nowhere near as granular as we need to be at the Elastic level and we dont control our Corp. AD.  
Not sure if we're missing something but it seems odd that Elastic developed the capability to manage users/roles via Kibana (basically making the Native Realm the "king") only to have it rendered moot if you decide on a different mechanism for the authentication of users. Also - our user ids for AD are the exact same as what we had built into Elasticsearch Native realm to begin with - so not sure why they aren't "matched".

Our Active Directory config is thus, with real domain and url detail xxx'd out:

xpack.security.authc.realms:  
active\_directory:  
type: active\_directory  
order: 0  
domain\_name: [xxxxx.ad.xxxxxxx.com](http://xxxxx.ad.xxxxxxx.com)  
url: ldap://xxxx.xxxxxx.com:389  
unmapped\_groups\_as\_roles: false

This config works in that it allows us to authenticate and brings us to the default Kibana screen. From there we just get nothing when moving to other tabs or permission denied - even for a user that is in the "superuser" group in elasticsearch native realm.

---

<div class="post-metadata">

**Author:** ![skearns](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/skearns/32/125945_2.png) [@skearns](https://discuss.elastic.co/u/skearns)\
**Post date:** [December 6, 2016, 9:06pm UTC](https://discuss.elastic.co/t/using-active-directory-for-authentication-and-native-realm-for-role-mapping/68197/2 "2016-12-06T21:06:06Z")

</div>

Hi Kevin,

This is a good question - and I'm afraid that the answer at the moment is no. We do have plans to add a user-role mapping API, which would do exactly what you're after, though we're still in the planning stages of this and don't have a target release or date to share just yet.

To give you just a bit of context as to why it doesn't "just work" - each realm handles authentication and also handles mapping users to roles. Separately, we have role stores that the various realms can use in when doing their role mapping. Today, AD and LDAP only support mapping users to groups via the security config files, and this is what we're planning to extend with an API.

I realize that this doesn't help you today, but hopefully it gives you an understanding of how we're thinking about the problem.

Thanks,  
Steve

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [January 3, 2017, 9:06pm UTC](https://discuss.elastic.co/t/using-active-directory-for-authentication-and-native-realm-for-role-mapping/68197/3 "2017-01-03T21:06:05Z")

</div>

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