# Is it possible to use AD Authc and Opensearch internal role mapping (no AD Authz)?

**URL:** <https://forum.opensearch.org/t/is-it-possible-to-use-ad-authc-and-opensearch-internal-role-mapping-no-ad-authz/28162>\
**Category:** Security\
**Created:** [June 25, 2026, 7:16pm UTC](https://forum.opensearch.org/t/is-it-possible-to-use-ad-authc-and-opensearch-internal-role-mapping-no-ad-authz/28162 "2026-06-25T19:16:39Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![subgenius](https://avatars.discourse-cdn.com/v4/letter/s/4bbf92/32.png) [@subgenius](https://forum.opensearch.org/u/subgenius)\
**Post date:** [June 25, 2026, 7:16pm UTC](https://forum.opensearch.org/t/is-it-possible-to-use-ad-authc-and-opensearch-internal-role-mapping-no-ad-authz/28162/1 "2026-06-25T19:16:39Z")

</div>

**I have successfully set up AD Authc on Opensearch. Now I am moving on to configure Authz.**

Is it feasible to configure Authz to be manually configured in Opensearch for AD authenticated clients?

In the Active Directory and LDAP page " **Approach 2: Use a user’s attribute as the role name"** I think it seems to be suggesting that I would manually create a user entry and assign a ‘backend\_role’. Is this correct?

---

<div class="post-metadata">

**Author:** ![Yanlin](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/yanlin/32/10286_2.png) [@Yanlin](https://forum.opensearch.org/u/Yanlin)\
**Post date:** [June 29, 2026, 12:56pm UTC](https://forum.opensearch.org/t/is-it-possible-to-use-ad-authc-and-opensearch-internal-role-mapping-no-ad-authz/28162/2 "2026-06-29T12:56:50Z")

</div>

Hi @Subgenius,

Yes, this is feasible. You can use AD/LDAP for authentication and still manage the OpenSearch roles, permissions, and role mappings on the OpenSearch side. **However** , to be technically precise regarding “manually configured in OpenSearch”: If you use Approach 2, it still relies on an attribute value associated with the user profile **on the AD side.**

Regarding **Approach 2** (“Use a user’s attribute as the role name”), You do not need to create a user in OpenSearch as this is only used for internal users to OpenSearch, In your case the users are managed via LDAP.

Instead, the role information is read from an attribute on the LDAP user entry. For example, the LDAP user entry could contain:

```bash
roles: engineering

```

and the LDAP authorization configuration could include:

```bash
userrolename: roles
rolesearch_enabled: false

```

In this example, the value `engineering` is read from the LDAP user entry and can be used as the backend role in OpenSearch role mappings. You could then map the backend role `engineering` to an OpenSearch role, for example `engineering_reader`.So the user still authenticates through AD/LDAP, while the OpenSearch side manages the role, permissions, and role mapping. It is not necessary to create a separate OpenSearch user entry for that AD/LDAP user for this approach.

Just to confirm the intended setup: are you trying to avoid using AD group membership for authorization, or mainly checking how Approach 2 should be interpreted?

---

<div class="post-metadata">

**Author:** ![subgenius](https://avatars.discourse-cdn.com/v4/letter/s/4bbf92/32.png) [@subgenius](https://forum.opensearch.org/u/subgenius)\
**Post date:** [June 29, 2026, 8:35pm UTC](https://forum.opensearch.org/t/is-it-possible-to-use-ad-authc-and-opensearch-internal-role-mapping-no-ad-authz/28162/3 "2026-06-29T20:35:40Z")

</div>

Thanks for the reply.

I was hoping to manually assign AD accounts roles in Opensearch the way I do in certain SAML or Oauth apps. In this type of scenario the application creates a profile for the account and the roles are mapped there after initial login.

Since this does not seem to be a thing, I can use AD groups, but it is not clear to me from the documentation of how this would work.

I would need around 14 user groups that I would grant permissions to certain tenants based on the group that they are a member of - at last that’s how I am thinking of it now.

What is the normal way to think about managing permissions in a large enterprise with multiple departments who each need to be restricted to view their own dashboards?

---

<div class="post-metadata">

**Author:** ![Yanlin](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/yanlin/32/10286_2.png) [@Yanlin](https://forum.opensearch.org/u/Yanlin)\
**Post date:** [June 30, 2026, 4:03pm UTC](https://forum.opensearch.org/t/is-it-possible-to-use-ad-authc-and-opensearch-internal-role-mapping-no-ad-authz/28162/4 "2026-06-30T16:03:42Z")

</div>

Hi @Subgenius,

Thanks for the additional details.

A common pattern is to organize users into groups in Active Directory and assign permissions based on the groups they are members of. OpenSearch Security can then use those groups as backend roles and map them to OpenSearch roles, where you configure the corresponding permissions and tenant access.

Could you please elaborate a bit more on the specific issue or limitation you are running into with that approach?

---

<div class="post-metadata">

**Author:** ![subgenius](https://avatars.discourse-cdn.com/v4/letter/s/4bbf92/32.png) [@subgenius](https://forum.opensearch.org/u/subgenius)\
**Post date:** [July 1, 2026, 3:30pm UTC](https://forum.opensearch.org/t/is-it-possible-to-use-ad-authc-and-opensearch-internal-role-mapping-no-ad-authz/28162/5 "2026-07-01T15:30:23Z")

</div>

Thanks again for your replies @Yanlin

Maybe it would help to describe my end goal in detail.

Lets say I create the AD groups:

opensearch\_users

Dept1\_os\_users

Dept2\_os\_users

…

Dept(x)\_os\_users

AD authentication is already working - however, the groups do not exist today. This implies that any valid AD account could successfully authenticate.

Step 1 User authenticates with valid AD account (functioning)

Question 1 Is it possible to restrict successful authentications to members of the ‘opensearch\_users’ AD group? If so, where and how would this be configured?

Step 2 The users group memberships are brought back by the config/query in the Authz section of config.yml (Not configured yet)?

Question 2 Is step 2 described correctly above?

Question 3 How do the groups returned get mapped to a role? Is the code just looking for an AD group name that matches a role name?

Step 3 The role assigned for Dept(x)\_os\_users only has access to the Dept(x) tenant.

Question 4 I haven’t gotten far enough to dig through this yet. Is there an example or documentation specific to this use case?

Thanks in advance.

---

<div class="post-metadata">

**Author:** ![Yanlin](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/yanlin/32/10286_2.png) [@Yanlin](https://forum.opensearch.org/u/Yanlin)\
**Post date:** [July 3, 2026, 8:27am UTC](https://forum.opensearch.org/t/is-it-possible-to-use-ad-authc-and-opensearch-internal-role-mapping-no-ad-authz/28162/6 "2026-07-03T08:27:40Z")

</div>

Hi @Subgenius,

Thanks for taking the time to describe your target setup.

For **Q1** , No, not directly. OpenSearch Security authenticates the user first and retrieves AD groups afterwards for authorization.If you want to restrict which users can authenticate, you should configure the LDAP authentication (`authc`) domain in `config/opensearch-security/config.yml`by narrowing the `userbase` and, if needed, the `usersearch` filter.  
Relevant `config.yml` fields:

```auto
usersearch: '(sAMAccountName={0})'
userbase: 'ou=people,dc=example,dc=com'

```

The relevant documentation is here:  
`https://docs.opensearch.org/latest/security/authentication-backends/ldap/#use-active-directory-and-ldap-for-authentication`

For **Q2** , yes, your understanding is generally correct. After authentication succeeds, the LDAP authorization (`authz`) configuration is used to resolve the authenticated user’s LDAP/AD group memberships. In OpenSearch Security, those groups can then be used as backend roles and mapped to OpenSearch roles through role mappings.

For **Q3** , regarding “Is the code just looking for an AD group name that matches a role name?” No, OpenSearch Security does not automatically grant permissions by looking for an OpenSearch role with the same name as the AD group.

The LDAP/AD groups returned during authorization are typically used as backend roles. Those backend roles are then mapped to OpenSearch roles through role mappings, for example using the `Security UI`, the `REST API`, or `roles_mapping.yml`. The mapping is configured explicitly rather than relying on an OpenSearch role with the same name as the AD group.

For example, if LDAP resolves the AD group `Dept1_os_users`, you could create a role mapping for the OpenSearch role `dept1_role` in `roles_mapping.yml`:

```auto
dept1_role:
  reserved: false
  backend_roles:
    - "Dept1_os_users"
  users: []
  hosts: []

```

The permissions are then configured on the OpenSearch role `dept1_role`, not directly on the AD group name.

For **Q4** , yes,the model you described is reasonable.The department group should not receive tenant access directly. Instead, the usual flow would be:

```auto
AD group: Dept1_os_users
backend role: Dept1_os_users
OpenSearch role: dept1_role
tenant permissions: Dept1 tenant

```

So `dept1_role` would contain the permissions for the `Dept1` tenant, and the AD group/backend role `Dept1_os_users` would be mapped to `dept1_role` through role mappings.

The relevant documentation is split across a few areas rather than one single end-to-end example:  
LDAP auth/authz: `https://docs.opensearch.org/latest/security/authentication-backends/ldap`  
Role mappings: `https://docs.opensearch.org/latest/security/access-control/users-roles`  
Multi-tenancy/tenant permissions: `https://docs.opensearch.org/latest/security/multi-tenancy/multi-tenancy-config`

If you run into any issues while setting this up, feel free to share the relevant OpenSearch Security configuration (with any sensitive information redacted), and I’d be happy to review it.