LDAP Integration fails when i'm adding Password into the OpenSearch keystore

Hi Team,

I have been trying to add the LDAP passwords to Opensearch-keystore as a property to secure the password but it’s throwing the error during the service startup.
Installed Version - opensearch-1.1.0-linux-x64.tar.gz

Please help to resolve this issue.

Error log:
… 6 more

uncaught exception in thread [main]
java.lang.IllegalArgumentException: unknown secure setting [authc.ldap.password] please check that any required plugins are installed, or check the breaking changes documentation for removed settings
at org.opensearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:557)
at org.opensearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:502)

Hi @Naga10. Could you share your config.yml file?

1 Like

—# This is the main OpenSearch 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: 2config:
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: false
#kibana:

Kibana multitenancy

#multitenancy_enabled: true
#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’

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: internal
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: dn #optional, if omitted DN becomes username
challenge: false
authentication_backend:
type: noop
ldap:
description: “Authenticate via LDAP or Active Directory”
http_enabled: true
transport_enabled: true
order: 1
http_authenticator:
type: basic
challenge: true
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:

  • localhost:389
    bind_dn: xxxxxxxxxxxxxxx
    password: xxxxxxxxxxxxxxxxx
    userbase: ‘dc=mycompany,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: cn
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:

  • localhsot:389
    bind_dn: xxxxxxxxxxxxxxx
    password: xxxxxxxxxxxxxxxxx
    rolebase: ‘DC=mycompany,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={memberDN})’

Specify the name of the attribute which value should be substituted with {2} above

userroleattribute: name

Roles as an attribute of the user entry

userrolename: name
#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=mycompany,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: 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

max_tracked_clients: 100000

Pattern (Java Platform SE 7 )

HI , Any update on the above config file ?

@pablo Any update on my below config ?

Could you send your config as preformatted text?

Accroding to your error authc.ldap.password is unknown, which is true. Please check the below example. Be sure that all indents in your config are correct.

      ldap:
        description: "Authenticate via LDAP or Active Directory"
        http_enabled: true
        transport_enabled: true
        order: 5
        http_authenticator:
          type: "basic"
          challenge: true
        authentication_backend:
          type: "ldap"
          config:
            enable_ssl: true
            pemtrustedcas_filepath: "cert.crt"
            enable_start_tls: false
            enable_ssl_client_auth: false
            verify_hostnames: true
            hosts:
            - "host.example.com:636"
            bind_dn: "cn=administrator,cn=users,dc=example,dc=com"
            password: "password"
            userbase: "cn=users,dc=exmaple,dc=com"
            usersearch: "(sAMAccountName={0})"
            username_attribute: "cn"

Hi Pablo,

we want to know whether OpenSearch provides an option to securely use the password. Because we are able to setup LDAP with clear text password…
Wan to understand, OpenSearch provide an option to hash or encrypt the password or store the password securely. Please advice.

@pablo Do you have any update on my above request?