Integrating OpenSearch with LDAP

[mkrnbk23]

I've been trying to integrate OpenSearch with our LDAP-catalog, in order to not have the whole team logging in as "admin", but I can't quite make it work.

I tried changing the settings in viya4-monitoring-kubernetes/logging/opensearch/securityconfig/config.yaml based on the documentation from OpenSearch which is linked to in the security settings menu in the default SAS OpenSearch installation, i.e. this https://opensearch.org/docs/latest/security/authentication-backends/ldap/

But when I re-apply my installation after updating and adding all required values OpenSearch does not change, and if I go back and login again with my local account and go to securit> settings > the LDAP expression is still the local one
{
"enable_ssl": false,
"enable_start_tls": false,
"enable_ssl_client_auth": false,
"verify_hostnames": true,
"hosts": [
"localhost:8389"
],
"userbase": "ou=people,dc=example,dc=com",
"usersearch": "(sAMAccountName={0})"
}

Is this because I cannot modify the settings after first installation, will it help if I do a complete uninstall and then reinstall ?

Is there a way to do this with settings in the viya4-monitoring-userdir config files instead ?

[gsmith-sas]

@mkrnbk23 Integrating with a site's LDAP is something we have on our radar but, unfortunately, we haven't had a chance to focus on it yet. I think you are probably correct: you will need to make your changes prior to the initial deployment. Looking over the OpenSearch documentation, I see references to two different files: config/opensearch-security/config.yml and config.yaml. Although those names are very similar, I believe they are in fact two different files. And, as I recall, we have run into cases where the same changes need to be made in both files.

Rather than making changes directly to the files in your copy of our project repo, I suggest you follow our preferred customization process which makes use of a USER_DIR directory. This is a directory located outside of the project repo with a specific set of sub-directories and files with specific names. You point to this directory by setting the environment variable USER_DIR prior to running our scripts. This will ensure you can update your copy of our project repo in the future without wiping out any changes you have made. Please refer to the Customization Process section of our documentation for full details.

In this case, your USER_DIR might be structured like this:
~/myviya4monitoring
~/myviya4monitoring/logging
~/myviya4monitoring/logging/user-values-opensearch.yaml
~/myviya4monitoring/logging/securityconfig/config.yaml

Any customizations you need to make to the OpenSearch config.yaml file would go in the appropriate section within the myviya4monitoring/logging/user-values-opensearch.yaml file. And, any customizations you need to make to the config/opensearch-security/config.yml file would go in the appropriate section of the myviya4monitoring/logging/securityconfig/config.yaml file. Before calling the logging/bin/deploy_logging.sh script, you would set the USER_DIR environment variable to "~/myviyamonitoring".

Please let us know how it goes. As I said, this is something we would like to document but haven't been able to look into due to other priorities. If you are successful, your fellow users could benefit from you experience.

[gsmith-sas]

@mkrnbk23 We're you ever able to successfully integrate OpenSearch with LDAP? If so, please provide details so other users can see how you did it. As I mentioned last year, this is something we would like to document but haven't been able to look into due to other priorities.

[mauriziopinzi]

Hello,
are there any news on this enhancement? I did a test putting the config file from viya4-monitoring-kubernetes/logging/opensearch/securityconfig/config.yml to $USER_DIR/monitoring/securityconfig/ and changing the values but it looks like is not taken into account, I did a fresh installation, this is my file, checking inside OSD I don't see any change in the security section

# This is the main Open Distro Security configuration file where authentication
# and authorization is defined.
#
# You need to configure at least one authentication domain in the authc of this file.
# An authentication domain is responsible for extracting the user credentials from
# the request and for validating them against an authentication backend like Active Directory for example.
#
# If more than one authentication domain is configured the first one which succeeds wins.
# If all authentication domains fail then the request is unauthenticated.
# In this case an exception is thrown and/or the HTTP status is set to 401.
#
# After authentication authorization (authz) will be applied. There can be zero or more authorizers which collect
# the roles from a given backend for the authenticated user.
#
# Both, authc and auth can be enabled/disabled separately for REST and TRANSPORT layer. Default is true for both.
#        http_enabled: true
#        transport_enabled: true
#
# For HTTP it is possible to allow anonymous authentication. If that is the case then the HTTP authenticators try to
# find user credentials in the HTTP request. If credentials are found then the user gets regularly authenticated.
# If none can be found the user will be authenticated as an "anonymous" user. This user has always the username "anonymous"
# and one role named "anonymous_backendrole".
# If you enable anonymous authentication all HTTP authenticators will not challenge.
#
#
# Note: If you define more than one HTTP authenticators make sure to put non-challenging authenticators like "proxy" or "clientcert"
# first and the challenging one last.
# Because it's not possible to challenge a client with two different authentication methods (for example
# Kerberos and Basic) only one can have the challenge flag set to true. You can cope with this situation
# by using pre-authentication, e.g. sending a HTTP Basic authentication header in the request.
#
# Default value of the challenge flag is true.
#
#
# HTTP
#   basic (challenging)
#   proxy (not challenging, needs xff)
#   kerberos (challenging)
#   clientcert (not challenging, needs https)
#   jwt (not challenging)
#   host (not challenging) #DEPRECATED, will be removed in a future version.
#                          host based authentication is configurable in roles_mapping

# Authc
#   internal
#   noop
#   ldap

# Authz
#   ldap
#   noop



_meta:
  type: "config"
  config_version: 2

config:
  dynamic:
    # Set filtered_alias_mode to 'disallow' to forbid more than 2 filtered aliases per index
    # Set filtered_alias_mode to 'warn' to allow more than 2 filtered aliases per index but warns about it (default)
    # Set filtered_alias_mode to 'nowarn' to allow more than 2 filtered aliases per index silently
    #filtered_alias_mode: warn
    do_not_fail_on_forbidden: true
    kibana:
    # Kibana multitenancy
      multitenancy_enabled: true
      # disable private tenant
      private_tenant_enabled: false
    #server_username: kibanaserver
    #index: '.kibana'
    http:
      anonymous_auth_enabled: false
      xff:
        enabled: false
        internalProxies: '192\.168\.0\.10|192\.168\.0\.11' # regex pattern
        #internalProxies: '.*' # trust all internal proxies, regex pattern
        #remoteIpHeader:  'x-forwarded-for'
        ###### see https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html for regex help
        ###### more information about XFF https://en.wikipedia.org/wiki/X-Forwarded-For
        ###### and here https://tools.ietf.org/html/rfc7239
        ###### and https://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Remote_IP_Valve
    authc:
      kerberos_auth_domain:
        http_enabled: false
        transport_enabled: false
        order: 6
        http_authenticator:
          type: kerberos
          challenge: true
          config:
            # If true a lot of kerberos/security related debugging output will be logged to standard out
            krb_debug: false
            # If true then the realm will be stripped from the user name
            strip_realm_from_principal: true
        authentication_backend:
          type: noop
      basic_internal_auth_domain:
        description: "Authenticate via HTTP Basic against internal users database"
        http_enabled: true
        transport_enabled: true
        order: 4
        http_authenticator:
          type: basic
          challenge: true
        authentication_backend:
          type: intern
      proxy_auth_domain:
        description: "Authenticate via proxy"
        http_enabled: false
        transport_enabled: false
        order: 3
        http_authenticator:
          type: proxy
          challenge: false
          config:
            user_header: "x-proxy-user"
            roles_header: "x-proxy-roles"
        authentication_backend:
          type: noop
      jwt_auth_domain:
        description: "Authenticate via Json Web Token"
        http_enabled: false
        transport_enabled: false
        order: 0
        http_authenticator:
          type: jwt
          challenge: false
          config:
            signing_key: "base64 encoded HMAC key or public RSA/ECDSA pem key"
            jwt_header: "Authorization"
            jwt_url_parameter: null
            roles_key: null
            subject_key: null
        authentication_backend:
          type: noop
      clientcert_auth_domain:
        description: "Authenticate via SSL client certificates"
        http_enabled: false
        transport_enabled: false
        order: 2
        http_authenticator:
          type: clientcert
          config:
            username_attribute: cn #optional, if omitted DN becomes username
          challenge: false
        authentication_backend:
          type: noop
      ldap:
        description: "Authenticate via LDAP or Active Directory"
        http_enabled: false
        transport_enabled: false
        order: 5
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          # LDAP authentication backend (authenticate users against a LDAP or Active Directory)
          type: ldap
          config:
            # enable ldaps
            enable_ssl: false
            # enable start tls, enable_ssl should be false
            enable_start_tls: false
            # send client certificate
            enable_ssl_client_auth: false
            # verify ldap hostname
            verify_hostnames: true
            hosts:
            - gelldap-service.gelldap:389
            bind_dn: "cn=admin,dc=gelldap,dc=com"
            password: ""
            userbase: "dc=gelldap,dc=com"
            # Filter to search for users (currently in the whole subtree beneath userbase)
            # {0} is substituted with the username
            usersearch: '(sAMAccountName={0})'
            # Use this attribute from the user as username (if not set then DN is used)
            username_attribute: null
    authz:
      roles_from_myldap:
        description: "Authorize via LDAP or Active Directory"
        http_enabled: false
        transport_enabled: false
        authorization_backend:
          # LDAP authorization backend (gather roles from a LDAP or Active Directory, you have to configure the above LDAP authentication backend settings too)
          type: ldap
          config:
            # enable ldaps
            enable_ssl: false
            # enable start tls, enable_ssl should be false
            enable_start_tls: false
            # send client certificate
            enable_ssl_client_auth: false
            # verify ldap hostname
            verify_hostnames: true
            hosts:
            - gelldap-service.gelldap:389
            bind_dn: "cn=admin,dc=gelldap,dc=com"
            password: ""
            rolebase: 'ou=groups,dc=example,dc=com'
            # Filter to search for roles (currently in the whole subtree beneath rolebase)
            # {0} is substituted with the DN of the user
            # {1} is substituted with the username
            # {2} is substituted with an attribute value from user's directory entry, of the authenticated user. Use userroleattribute to specify the name of the attribute
            rolesearch: '(member={0})'
            # Specify the name of the attribute which value should be substituted with {2} above
            userroleattribute: null
            # Roles as an attribute of the user entry
            userrolename: disabled
            #userrolename: memberOf
            # The attribute in a role entry containing the name of that role, Default is "name".
            # Can also be "dn" to use the full DN as rolename.
            rolename: cn
            # Resolve nested roles transitive (roles which are members of other roles and so on ...)
            resolve_nested_roles: true
            userbase: "dc=gelldap,dc=com"
            # Filter to search for users (currently in the whole subtree beneath userbase)
            # {0} is substituted with the username
            usersearch: '(uid={0})'
            # Skip users matching a user name, a wildcard or a regex pattern
            #skip_users:
            #  - 'cn=Michael Jackson,ou*people,o=TEST'
            #  - '/\S*/'
      roles_from_another_ldap:
        description: "Authorize via another Active Directory"
        http_enabled: false
        transport_enabled: false
        authorization_backend:
          type: ldap
          #config goes here ...
  #    auth_failure_listeners:
  #      ip_rate_limiting:
  #        type: ip
  #        allowed_tries: 10
  #        time_window_seconds: 3600
  #        block_expiry_seconds: 600
  #        max_blocked_clients: 100000
  #        max_tracked_clients: 100000
  #      internal_authentication_backend_limiting:
  #        type: username
  #        authentication_backend: intern
  #        allowed_tries: 10
  #        time_window_seconds: 3600
  #        block_expiry_seconds: 600
  #        max_blocked_clients: 100000

[gsmith-sas]

@mauriziopinzi No, unfortunately, we have not had a chance to work on this particular enhancement. You will need to refer to the OpenSearch documentation, especially the Configuring the Security backend, Configuring Dashboards sign-in for multiple authentication options and Active Directory and LDAP section within the Security in OpenSearch topic of the OpenSearch documentation for more information. It is important to look at the OpenSearch 2.19 documentation since we have not moved to OpenSearch 3.x yet. I would also encourage you to very carefully compare the contents of viya4-monitoring-kubernetes/logging/opensearch/securityconfig/config.yml with what is shown in the documentation. That file has been part of our repo for a long time and may not exactly match newer versions. Please consider sharing your results if you are successful.