LDAP X-pack error Config: Error 403 Forbidden

Serg · October 27, 2017, 2:39pm

I installed x-pack and edited config elasticsearch.yml

xpack:
security:
authc:
realms:
ldap1:
type: ldap
order: 0
url: "ldap://ldap"
bind_dn: "cn=admin,dc=my"
bind_password: pass
user_search:
base_dn: "dc=my"
attribute: cn
group_search:
base_dn: "dc=my"
files:
role_mapping: "CONFIG_DIR/x-pack/role_mapping.yml"
unmapped_groups_as_roles: false

After I edited role_mapping.yml

superuser:

"cn=jon snow,ou=users,dc=my"

I could log in to kibana but I got error

Config: Error 403 Forbidden: [security_exception] action [indices:data/write/update] is unauthorized for user [jon snow]

{
"username" : "jon snow",
"roles" : ,
"full_name" : null,
"email" : null,
"metadata" : {
"ldap_dn" : "cn=jon snow,ou=users,dc=my",
"ldap_groups" :
},
"enabled" : true
}

TimV · October 28, 2017, 1:11am

Firstly, please paste the contents of configuration files as code blocks - formatting matters, and we can't tell whether your file is formatted correctly unless you display it as a code block.

Secondly, when things don't work, always check the logs, and include any relevant messages in your post. There is a lot of useful information there, and it shouldn't be ignored.

Your issue is this

files:
  role_mapping: "CONFIG_DIR/x-pack/role_mapping.yml"

CONFIG_DIR doesn't mean anything special here, so it's looking for a file in a directory that almost certainly doesn't exist.

Serg · October 30, 2017, 9:51am

Thanks!

1 more question I added to role mapping config:
If I am adding some user everything works properly.
ex.

kibana_view:
  - "cn=test test,ou=users,dc=my"

But if I use some group like

kibana_view:
  - "cn=kibana,ou=groups,dc=my"

I have the same error with permission, this DN by 100% exists in LDAP (cn=kibana,ou=groups,dc=my)

TimV · October 30, 2017, 10:12am

It appears that you haven't configuredgroup_search correctly.
If the ldap_groups array is empty in the_authenticate response, then you need to look at your configuration.

Serg · October 30, 2017, 10:42am

I am using this

          group_search:
            base_dn: "dc=my"

And this is correct base DN in my ldap.

Should i use some other syntax ?

Serg · October 30, 2017, 10:45am

This all xpack config

xpack:
 security:
    authc:
      realms:
        ldap1:
          type: ldap
          order: 0
          url: "ldap://ldap.my"
          bind_dn: "cn=admin,dc=my"
          bind_password: pass
          user_search:
            base_dn: "dc=my"
            attribute: cn
          group_search:
            base_dn: "dc=my"
          files:
            role_mapping: "/etc/elasticsearch/x-pack/role_mapping.yml"
          unmapped_groups_as_roles: false

TimV · October 30, 2017, 11:11am

Since your ldap_groups is coming out empty, that configuration must not be the right fit for your directory.

You're going to need to read the documentation on the configuration options and try a few different options, because it's impossible for me to to know what the problem is without access to your directory schema.

https://www.elastic.co/guide/en/x-pack/5.6/ldap-realm.html#ldap-settings

You might consider turning on TRACE logging that will capture the LDAP searches that x-pack is running against your directory.

Edit the log4j2.properties file in your config directory, and add:

logger.ldap.name = org.elasticsearch.xpack.security.authc.ldap
logger.ldap.level = TRACE

The elasticsearch logs should provide more details about what's taking place under the covers.

Serg · October 30, 2017, 3:58pm

Manual search: in elastic:

curl -XGET 'elastic:pass@localhost:9200/_xpack/security/_authenticate?pretty' -u test\ test
Enter host password for user 'test test':
{
  "username" : "test test",
  "roles" : [
    "kibana_view"
  ],
  "full_name" : null,
  "email" : null,
  "metadata" : {
    "ldap_dn" : "cn=test test,ou=users,dc=my",
    "ldap_groups" : [ ]
  },
  "enabled" : true
}

Log result:

[2017-10-30T15:41:32,635][DEBUG][o.e.x.s.a.l.LdapRealm    ] [m_yIIDS] user [test test] not found in cache for realm [ldap1], proceeding with normal authentication
[2017-10-30T15:41:32,636][TRACE][o.e.x.s.a.l.s.LdapUtils  ] LDAP Search SearchRequest(baseDN='dc=my', scope=SUB, deref=NEVER, sizeLimit=0, timeLimit=5, filter='(cn=test test)', attrs={1.1}) => SearchResult(resultCode=0 (success), messageID=70, entriesReturned=1, referencesReturned=0) ([SearchResultEntry(dn='cn=test test,ou=users,dc=my', messageID=70, attributes={}, controls={})])
[2017-10-30T15:41:37,640][DEBUG][o.e.x.s.a.l.LdapUserSearchSessionFactory] [m_yIIDS] Resolving LDAP groups + meta-data for user [cn=test test,ou=users,dc=my]
[2017-10-30T15:41:37,641][TRACE][o.e.x.s.a.l.s.LdapUtils  ] LDAP Search SearchRequest(baseDN='dc=my', scope=SUB, deref=NEVER, sizeLimit=0, timeLimit=5, filter='(&(|(objectclass=groupOfNames)(objectclass=groupOfUniqueNames)(objectclass=group)(objectclass=posixGroup))(|(uniqueMember=cn=test test,ou=users,dc=my)(member=cn=test test,ou=users,dc=my)(memberUid=cn=test test,ou=users,dc=my)))', attrs={1.1}) => SearchResult(resultCode=0 (success), messageID=4, entriesReturned=0, referencesReturned=0) ([])
[2017-10-30T15:41:37,642][DEBUG][o.e.x.s.a.l.LdapUserSearchSessionFactory] [m_yIIDS] Resolved 0 LDAP groups [[]] for user [cn=test test,ou=users,dc=my]
[2017-10-30T15:41:37,642][DEBUG][o.e.x.s.a.l.LdapUserSearchSessionFactory] [m_yIIDS] Resolved 0 meta-data fields [{}] for user [cn=test test,ou=users,dc=my]
[2017-10-30T15:41:37,644][DEBUG][o.e.x.s.a.l.LdapRealm    ] [m_yIIDS] realm [ldap1] authenticated user [test test], with roles [[kibana_view]]

Search in LDAP:

root@bastion:/home/users/# ldapsearch -x -b 'dc=my'  -s sub -h ldap.my -LLL | grep -A 10  kibana
dn: cn=kibana,ou=groups,dc=my
gidNumber: 509
cn: kibana
objectClass: posixGroup
objectClass: top
memberUid: ttest



root@bastion:/home/users/# ldapsearch -x -b 'dc=my' '(uid='ttest')' -s sub -h ldap.my -LLL
dn: cn=test test,ou=users,dc=my
cn: test test
givenName: test
gidNumber: 503
homeDirectory: /home/users/ttest
sn: test
loginShell: /bin/bash
uidNumber: 2001
uid: ttest
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top

As u see user exist and he is in the correct group.

Also i tried to change value in config to

          group_search:
            base_dn: "ou=groups,dc=my"

But got the same result
Any ideas?

ikakavas · October 30, 2017, 6:01pm

As you can see above in the log output you have provided:

[2017-10-30T15:41:37,641][TRACE][o.e.x.s.a.l.s.LdapUtils  ] LDAP Search SearchRequest(baseDN='dc=my', scope=SUB, deref=NEVER, sizeLimit=0, timeLimit=5, filter='(&(|(objectclass=groupOfNames)(objectclass=groupOfUniqueNames)(objectclass=group)(objectclass=posixGroup))(|(uniqueMember=cn=test test,ou=users,dc=my)(member=cn=test test,ou=users,dc=my)(memberUid=cn=test test,ou=users,dc=my)))', attrs={1.1}) => SearchResult(resultCode=0 (success), messageID=4, entriesReturned=0, referencesReturned=0) ([])

the ldap filter for resolving the ldap groups contains the following clause

(memberUid=cn=test test,ou=users,dc=my)

which doesn't match anything since memberUid contains the uid and not the DN.

You can overcome this by setting group_search.user_attribute to uid (it defaults to DN hence the not matching filter clause above ) as described in https://www.elastic.co/guide/en/x-pack/5.6/ldap-realm.html#ldap-settings

Serg · October 30, 2017, 9:33pm

Magic! it's work, but I did not get why. Search log show that Elastic could get user with this DN

(uniqueMember=cn=test test,ou=users,dc=my)(member=cn=test test,ou=users,dc=my)(memberUid=cn=test test,ou=users,dc=my)))

and also is it bug or feature that i should use "long" CN , not "short" uid for log in ?

ikakavas · October 31, 2017, 10:10am

The log line you provided shouldn't be the one you get from the logs now, if you have set the

user_attribute: "uid"

You should see a line similar to the one below:

[o.e.x.s.a.l.s.LdapUtils  ] LDAP Search SearchRequest(baseDN='dc=my', scope=SUB, deref=NEVER, sizeLimit=0, timeLimit=5, filter='(&(|(objectclass=groupOfNames)(objectclass=groupOfUniqueNames)(objectclass=group)(objectclass=posixGroup))(|(uniqueMember=ttest)(member=ttest)(memberUid=ttest)))', attrs={1.1}) => SearchResult(resultCode=0 (success), messageID=4, entriesReturned=1, referencesReturned=0) ([])

and also is it bug or feature that i should use "long" CN , not "short" uid for log in ?

You should use the one that matches your directory structure and the Group types you are using. Most of the group objectclasses, such as groupOfNames , groupOfUniqueNames have a multivalued attribute ( member or uniqueMember respectively ) that holds the Distinguished Name of the users that are members of the groups. On the other hand, posixGroup objectclass has a multivalued attribute named memberUid that contain the uid of all the users that are members of the group.

The default value for group_search.user_attribute is Distinguished Name ( or the long form you mention above which looks like cn=test test,ou=users,dc=my ) and this would satisfy your use case if you were using groupOfNames or groupOfUniqueNames. Now that you are using posixGroup which has the memberUid attribute, you needed to change group_search.user_attribute to uid.

Hope this is clearer now.

Serg · October 31, 2017, 2:26pm

As i found any user could log in (if it exists in ldap ) without any permission
But could I for somehow to deny log in at all if user does not have some group (in my case it is "kibana" ldap group) ?

ikakavas · October 31, 2017, 3:57pm

Yes, definitely. Even if your existing ldap users can "log in" via Kibana for example, they would get an error

Config: Error 403 Forbidden: action [indices:data/write/update] is unauthorized for user [your_user]: [security_exception] action [indices:data/write/update] is unauthorized for user [your_user]

and won't be able to perform any action or read any data.

You should take a look at Configuring Role-based Access Control | X-Pack for the Elastic Stack [6.2] | Elastic . In short, Role Based Access Control (RBAC) is supported for authorization. Users with no explicit role assignment get a default role that enables them to access the authenticate endpoint, which is what you probably mention above as

any user could log in (if it exists in ldap ) without any permission

,change their own passwords, and get information about themselves.

Moving forward you can use the built-in roles, or define your own in order to fine grain the permissions and privileges that apply to them ( and they users who have them ). You can map the LDAP groups to roles using the role_mapping.yml file as you've already done.

TimV · October 31, 2017, 11:00pm

I'm afraid Kibana does not currently have a feature to prevent users logging in if they have no permissions. Every user that exists in your LDAP tree is allowed to login, but they see a blank page.

Serg · November 1, 2017, 9:44am

Very bad, maybe u want to add this feature to the next sprint?
Thanks a lot for help

system · November 29, 2017, 9:44am

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.