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

Security
1

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?

2

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:

roles: engineering

and the LDAP authorization configuration could include:

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?

3

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?

4

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?

5

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.

6

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.ymlby narrowing the userbase and, if needed, the usersearch filter.
Relevant config.yml fields:

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:

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:

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.