Issues with LDAP autherization on Opensearch 2.8

On behalf of a user of Slack

" Hi,
I am facing issue with LDAP autherization in Opensearch 2.8. i have configured all the required fields in config.yaml and user able to login but the role is not assigned to ldap group.

No index-level perm match for User [name=saurabhkumar, backend_roles=[shi-admin, gitlab-group], requestedTenant=
_user_] Resolved [aliases=[*], allIndices=[*], types=[*], originalRequested=[*], remoteIndices=[ ]] [Action [indices:admin/resolve/index]] [RolesChecked [own_index]]"

Hi Saurabh,

Could you please provide me with the content of your roles_mapping.yml file?

Thanks,
Mantas

Hi,

Please find the roles.yaml and roles_mapping.yml

roles.yaml: i have created the sreadmin role so i have pasted the some last lines.

Allows users to use all security analytics functionality

security_analytics_full_access:
reserved: true
cluster_permissions:
- ‘cluster:admin/opensearch/securityanalytics/alerts/
- 'cluster:admin/opensearch/securityanalytics/correlations/

- ‘cluster:admin/opensearch/securityanalytics/detector/
- 'cluster:admin/opensearch/securityanalytics/findings/

- ‘cluster:admin/opensearch/securityanalytics/mapping/
- 'cluster:admin/opensearch/securityanalytics/rule/

index_permissions:
- index_patterns:
- ‘*’
allowed_actions:
- ‘indices:admin/mapping/put’
- ‘indices:admin/mappings/get’

Allows users to view and acknowledge alerts

security_analytics_ack_alerts:
reserved: true
cluster_permissions:
- ‘cluster:admin/opensearch/securityanalytics/alerts/*’

SRE admin roles

sreadmin:
cluster_permissions:
- ‘
index_permissions:
- index_patterns:
- '

allowed_actions:
- ‘*’

Role mapping : I have created the sreadmin rolemapping with ldap backend role. pasting some last lines.
kibana_server:
reserved: true
users:

  • “kibanaserver”

sreadmin:
backend_roles:
- “cn=shi-admin,ou=GITLAB,dc=example,dc=IN”
sh-readonly:
backend_roles:
- “cn=shi-readonly,ou=GITLAB,dc=example,dc=IN”

But every time i login with my ldap user which is part of shi-admin group is only access own_index privileges not admin.

If you need more details let me know. As this is urgent for me to configure the logging solution with ldap.

Hi @saurabhtmba2005,

Could you please run the below and share the results and please share your config.yml with me?

curl --insecure -u <LDAP_user> -XGET https://<OpenSearch_FQDN_or_IP>:9200/_plugins/_security/authinfo?pretty

Best,
Mantas

Hi, Please find the curl result.

curl --insecure -u saurabhkumar -XGET https://10.32.5.24:9200/_plugins/_security/authinfo?pretty
Enter host password for user ‘saurabhkumar’:
{
“user” : “User [name=saurabhkumar, backend_roles=[shi-admin, gitlab-group], requestedTenant=null]”,
“user_name” : “saurabhkumar”,
“user_requested_tenant” : null,
“remote_address” : “10.32.5.24:36580”,
“backend_roles” : [
“shi-admin”,
“gitlab-group”
],
“custom_attribute_names” : [
“attr.ldap.badPwdCount”,
“attr.ldap.userAccountControl”,
“attr.ldap.mS-DS-ConsistencyGuid”,
“attr.ldap.whenCreated”,
“attr.ldap.msExchAddressBookFlags”,
“ldap.original.username”,
“attr.ldap.physicalDeliveryOfficeName”,
“attr.ldap.sAMAccountName”,
“attr.ldap.msExchTextMessagingState”,
“attr.ldap.userPrincipalName”,
“attr.ldap.msExchMailboxAuditLogAgeLimit”,
“attr.ldap.whenChanged”,
“attr.ldap.msExchMailboxAuditEnable”,
“attr.ldap.description”,
“attr.ldap.objectSid”,
“attr.ldap.codePage”,
“attr.ldap.msExchShadowDisplayName”,
“attr.ldap.garbageCollPeriod”,
“attr.ldap.mail”,
“attr.ldap.msExchUMDtmfMap”,
“attr.ldap.msExchTransportRecipientSettingsFlags”,
“attr.ldap.msExchPoliciesIncluded”,
“attr.ldap.lastLogonTimestamp”,
“attr.ldap.primaryGroupID”,
“attr.ldap.msExchArchiveQuota”,
“attr.ldap.msExchMailboxGuid”,
“attr.ldap.msExchShadowCountryCode”,
“attr.ldap.msExchShadowMailNickname”,
“attr.ldap.objectGUID”,
“attr.ldap.msExchMDBRulesQuota”,
“attr.ldap.msExchProvisioningFlags”,
“attr.ldap.countryCode”,
“attr.ldap.department”,
“attr.ldap.msExchRemoteRecipientType”,
“attr.ldap.instanceType”,
“attr.ldap.protocolSettings”,
“attr.ldap.msExchModerationFlags”,
“attr.ldap.telephoneNumber”,
“attr.ldap.msExchShadowGivenName”,
“attr.ldap.objectClass”,
“attr.ldap.msExchVersion”,
“attr.ldap.msExchUMEnabledFlags2”,
“attr.ldap.givenName”,
“ldap.dn”,
“attr.ldap.sAMAccountType”,
attr.ldap.cn”,
“attr.ldap.accountExpires”,
“attr.ldap.dSCorePropagationData”,
“attr.ldap.name”,
“attr.ldap.internetEncoding”,
“attr.ldap.uSNCreated”,
“attr.ldap.uSNChanged”,
“attr.ldap.msExchRecipientTypeDetails”,
“attr.ldap.pwdLastSet”,
“attr.ldap.msExchUserAccountControl”,
“attr.ldap.msExchRecipientDisplayType”,
“attr.ldap.msExchWhenMailboxCreated”,
“attr.ldap.msExchArchiveWarnQuota”,
“attr.ldap.mailNickname”,
“attr.ldap.msExchBypassAudit”,
“attr.ldap.mobile”
],
“roles” : [
“own_index”
],
“tenants” : {
“saurabhkumar” : true
},
“principal” : null,
“peer_certificates” : “0”,
“sso_logout_url” : null
}

Config.yaml


_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: false
#kibana:
# Kibana multitenancy
#multitenancy_enabled: true
#private_tenant_enabled: true
#default_tenant: “”
#server_username: kibanaserver
#index: ‘.kibana’
http:
anonymous_auth_enabled: false
xff:
enabled: false
internalProxies: ‘192.168.0.10|192.168.0.11’ # regex pattern
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
jwt_clock_skew_tolerance_seconds: 30
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: true
transport_enabled: true
order: 5
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:
- 192.168.207.5:389
bind_dn: cn=sre admin,ou=Common,ou=example,dc=example,dc=IN
password: D3^0p@$taR
userbase: ‘ou=example,dc=example,dc=IN’
# 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: sAMAccountName
authz:
roles_from_myldap:
description: “Authorize via LDAP or Active Directory”
http_enabled: true
transport_enabled: true
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:
- 192.168.207.5:389
bind_dn: cn=sre admin,ou=Common,ou=example,dc=example,dc=IN
password: D3^0p@$taR
rolebase: ‘ou=GITLAB,ou=example,dc=example,dc=IN’
# 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: ‘ou=example,dc=example,dc=IN’
# Filter to search for users (currently in the whole subtree beneath userbase)
# {0} is substituted with the username
#usersearch: ‘(uid={0})’
usersearch: ‘(sAMAccountName={0})’
# Skip users matching a user name, a wildcard or a regex pattern
#skip_users:
# - ‘cn=Michael Jackson,oupeople,o=TEST’
# - '/\S
/’
roles_from_another_ldap:
description: “Authorize via another Active Directory”
http_enabled: false
transport_enabled: false
authorization_backend:
type: ldap

Hi,

Please help here.

Hi @saurabhtmba2005,

It looks like the “backend roles” do not match the roles expected by Opensearch at the moment. To match the “backend_roles” you will have to update the rolename to use “dn” instead of “cn” (ldap.authz.config.rolename) in the Config.yaml.

Alternatively, you can keep on using the cn value with rolename option and map the LDAP group name as backend_role in the roles_mapping.yml, for example:

roles_mapping.yml
...
sreadmin:
  backend_roles:
   - “shi-admin”
…

Please try the suggestions above and let me know if you have further questions.

Best,
Mantas

Hi Mantas,

Thanks for the clarification on this. Now working fine.