Setting LDAP group for impersonation feature

Security
1

Versions (relevant - OpenSearch/Dashboard/Server OS/Browser):
OpenSearch v2.10

Describe the issue:
I have integrated LDAP for authentication and authorisation in my OpenSearch cluster. Now, reading the official doc I thought of giving an LDAP group the possibility to impersonate users in my cluster. I am not convinced that this is something that it is indeed supposed to work. If not, please let me know so that I raise a feature request.

So, I add this on my opensearch.yml config:

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

authenticating (using basic auth) for user admin works as expected.

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

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

and 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
}

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
2

Hi @spapadop

Could you try to use the following configurations in the opensearch.yml?

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

Yeap this works, but it’s not what I wanted, as it is not dynamic. Essentially this part of the config is not doing anything:

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

Imagine that the LDAP egroup it-opensearch-experts have members:

  • joe
  • maria
  • bob

what you are suggesting is to hardcode this on the opensearch.yml

plugins.security.authcz.rest_impersonation_user.joe:
- "*"
plugins.security.authcz.rest_impersonation_user.maria:
- "*"
plugins.security.authcz.rest_impersonation_user.bob:
- "*"

That works but it treats Joe, Maria and Bob as internal_users. I am expecting that since these folks are part of the it-opensearch-experts egroup, adding this in the configuration should be sufficient to enable impersonation:

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

This way, any changes on the e-group (alice becoming member of it, or bob leaving) would be reflected dynamically. Unfortunately, the above seems to have no effect, which goes against the official doc.

I wonder what transport layer impersonation actually means in this case. How can I take advantage of the plugins.security.authcz.impersonation_dn setting? Should a new one plugins.security.authcz.rest_impersonation_dn be added for my use case to work?

4

I’ve opened [FEATURE] Allow LDAP groups to impersonate users · Issue #3762 · opensearch-project/security · GitHub so that this feature request is followed up with the community.