Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Allow LDAP groups to impersonate users #3762

Open
spapadop opened this issue Nov 22, 2023 · 1 comment
Open

[FEATURE] Allow LDAP groups to impersonate users #3762

spapadop opened this issue Nov 22, 2023 · 1 comment
Labels
enhancement New feature or request help wanted Community contributions are especially encouraged for these issues. triaged Issues labeled as 'Triaged' have been reviewed and are deemed actionable.

Comments

@spapadop
Copy link

Is your feature request related to a problem?

I have integrated LDAP for authentication and authorisation in my OpenSearch clusters.
Each cluster is "managed" by a different LDAP group, that are acting as superadmins (i.e. essentially they are mapped to the "all_access" role, through backend_role).

Now, reading the official doc I thought of giving an LDAP group the possibility to impersonate users in my cluster.

So, I add this on my opensearch.yml config, hoping that besides user "joe", all people in "it-opensearch-administrators" LDAP group will be able to impersonate every user in the cluster.

plugins.security.authcz.rest_impersonation_user.admin:
- "*"
plugins.security.authcz.impersonation_dn:
  "CN=it-opensearch-administrators,OU=e-groups,OU=Workgroups,DC=mydomain,DC=com":
  - "*"

authenticating (using basic auth) and impersonating any user with user "admin" works as expected.

and then I try this (authenticating through kerberos) with a user "joe" who is member of "it-opensearch-administrators" LDAP group:

curl --negotiate -u : -k -H "opendistro_security_impersonate_as: paok" https://mycluster.mydomain.com/_cluster/health?pretty

I get this:

{
  "error" : {
    "root_cause" : [
      {
        "type" : "security_exception",
        "reason" : "'joe' is not allowed to impersonate as 'paok'"
      }
    ],
    "type" : "security_exception",
    "reason" : "'joe' is not allowed to impersonate as 'paok'"
  },
  "status" : 403
}

What solution would you like?
I would like to be able to give impersonation rights to an LDAP group dynamically, so that any user of the organisation that is member of that group (which changes over time), automatically gets impersonation rights over other users.

What alternatives have you considered?
Setting up an internal_user for each cluster and let them use that for impersonation. But that's a work-around more than a solution to the problem.

Do you have any additional context?
Here's my entire config.yml, in case it helps.

_meta:
  type: "config"
  config_version: 2

config:
  dynamic:
    http:
      anonymous_auth_enabled: false
      xff:
	enabled: false
        internalProxies: '192\.168\.0\.10|192\.168\.0\.11' # regex pattern

    kibana:
      multitenancy_enabled: true
      server_username: iteskibanauser
      index: '.kibana'
    do_not_fail_on_forbidden: true

    authc:
      basic_internal_auth_domain:
        description: "Authenticate via HTTP Basic against internal users database"
        http_enabled: true
        transport_enabled: true
        order: 1
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          type: intern
      openid_auth_domain:
        description: "Authenticate via OpenID Connect"
        http_enabled: true
        transport_enabled: true
        order: 0
        http_authenticator:
          type: openid
          challenge: false
          config:
            subject_key: preferred_username
            openid_connect_url: 'https://keycloak.mydomain.com/auth/realms/mydomain/.well-known/openid-configuration'
            skip_users:
            - iteskibanauser
        authentication_backend:
          type: noop
      ldap_auth_domain:
        description: "Authenticate via LDAP or Active Directory"
        http_enabled: true
        transport_enabled: true
        order: 2
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          type: ldap
          config:
            enable_ssl: false
            enable_start_tls: false
            enable_ssl_client_auth: false
            verify_hostnames: true
            hosts:
            - xldap.mydomain.com:389
            bind_dn: null
            password: null
            userbase: 'OU=Users,OU=Organic Units,DC=mydomain,DC=com'
            usersearch: '(sAMAccountName={0})'
            username_attribute: 'cn'
      kerberos_auth_domain:
        description: "Authenticate via Kerberos"
        http_enabled: true
        transport_enabled: true
        order: 3
        http_authenticator:
          type: kerberos
          challenge: true
          config:
            krb_debug: false
            strip_realm_from_principal: true
        authentication_backend:
          type: noop

    authz:
      roles_from_myldap:
        description: "Authorize via LDAP or Active Directory"
        http_enabled: true
        transport_enabled: false
        authorization_backend:
          type: ldap
          config:
            enable_ssl: false
            enable_start_tls: false
            enable_ssl_client_auth: false
            verify_hostnames: true
            hosts:
            - xldap.mydomain.com:389
            bind_dn: null
            password: null
            userbase: 'OU=Users,OU=Organic Units,DC=mydomain,DC=com'
            usersearch: '(sAMAccountName={0})'
            username_attribute: 'cn'
            rolebase: 'OU=Unix,OU=Workgroups,DC=mydomain,DC=com'
            rolesearch: '(member={0})'
            userroleattribute: null
            userrolename: 'memberOf'
            rolename: 'cn'
            resolve_nested_roles: true
            skip_users:
            - iteskibanauser
@spapadop spapadop added enhancement New feature or request untriaged Require the attention of the repository maintainers and may need to be prioritized labels Nov 22, 2023
@cwperks cwperks added triaged Issues labeled as 'Triaged' have been reviewed and are deemed actionable. help wanted Community contributions are especially encouraged for these issues. and removed untriaged Require the attention of the repository maintainers and may need to be prioritized labels Dec 4, 2023
@cwperks
Copy link
Member

cwperks commented Dec 4, 2023

[Triage] Thank you for filing this issue and providing details @spapadop.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Community contributions are especially encouraged for these issues. triaged Issues labeled as 'Triaged' have been reviewed and are deemed actionable.
Projects
None yet
Development

No branches or pull requests

2 participants