ReadonlyREST with LDAP

(Talia) #1

we have a 5 node elasticsearch cluster running 5.2.0,
2 of the nodes are configured as client nodes (data=false, master=false),
we configured the two client nodes to work with the ReadOnlyRest plugin and enabled the ldap authentication

for some reason we cannot authenticate with ldap.

this is our elasticsearch.yml:

    enable: true
    response_if_req_forbidden: Forbidden by ReadonlyREST ES plugin


      - name: kibana
        type: allow
        auth_key: kibana:kibanapass
        indices: [".kibana"]

      - name: b1
        type: allow
           - name: "ldap"                                       
             groups: ["group1"]
        indices: ["*"]

      - name: b2
        type: allow
           - name: "ldap"
             groups: ["group2"]
        indices: ["*"]


      - name: ldap
        host: ""
        port: 389
        ssl_enabled: false
        ssl_trust_all_certs: false
        bind_dn: "cn=appUser,ou=someOU,dc=dcName,dc=com"
        bind_password: "xxxxx"
        search_user_base_DN: "dc=dcName,dc=com"
        search_groups_base_DN: "dc=dcName,dc=com"
        connection_pool_size: 10
        connection_timeout_in_sec: 10
        request_timeout_in_sec: 10
        cache_ttl_in_sec: 60

we enabled the access logs and failed entries look like:
[2017-04-04T14:28:06,439][INFO ][org.elasticsearch.plugin.readonlyrest.acl.ACL] ^[[31m no block has matched, forbidding by default: { ID:7c6850045f7bxxxxbdd110bxxxxf6f9b, TYP:SearchRequest, USR:dcName/someUserName, BRS:false, ACT:indices:data/read/search,, IDX:.kibana, MET:POST, PTH:/.kibana/index-pattern/_search, CNT:<OMITTED, LENGTH=39>, HDR:authorization,content-length,x-forwarded-proto,Connection,x-forwarded-port,content-type,Host,x-forwarded-for, EFF:0, HIS:[kibana->[indices->true, auth_key->false]], [b1->[ldap_auth->false]], [b2->[ldap_auth->false]], [b1->[indices->true]], [b2->[indices->true]] }^[[0m

the user “someUserName” is part of the group “group1”

Our LDAP is microsoft active directory 2008R2

(Simone Scarduzio) #2

Apparently, the LDAP connector manages to connect to the LDAP server (you should have had an exception otherwise), but it says the user credentials are not matching.

Maybe some username format issues? Different case? The server uses some kind of prefixes?

@coutoPL have you ever tested this with Windows by chance?

BTW, you can remove that indices: ["*"], it doesn’t add any meaning.

(Mateusz Kołodziejczyk) #3

Not tested with Windows LDAP.
Are you sure search_groups_base_DN is configured properly?



I am geeting the following error message:
[2017-04-05T14:27:59,327][INFO ][o.e.p.r.IndexLevelActionFilter] [ptkpl-kibana1] forbidden request: { ID:71ef4e85454a42a6b82cc2fac9697ee0, TYP:GetRequest, USR:yoavb, BRS:false, ACT:indices:data/read/get,, IDX:.kibana, MET:GET, PTH:/.kibana/config/5.2.2, CNT:<OMITTED, LENGTH=0>, HDR:authorization,Connection,Host,Content-Length, EFF:0, HIS:[b1 - Accept requests from users in group team1 on index1->[ldap_auth->false]], [kibana->[indices->true, auth_key->false]], [b1 - Accept requests from users in group team1 on index1->[indices->true, methods->true]] } Reason: null (null)

I have looked at

I also added: methods: GET to the elasticsearch.yml file but it didnt helped.


  1. Does: ldap_auth->false mean that it not quey the LDAP , or does it mean that the ldap didnt found the user ?
  2. I would like to know if there is another configuration file . I didnt understood the purpose of test_example.ldif file


(Simone Scarduzio) #5
  1. that means that the LDAP query didn’t find the user or the user was present, but didn’t have that password
  2. The other configuration file is for our OpenLDAP docker container we use in integration tests, also it’s a reference if someone needs to configure an OpenLDAP server to work with ReadonlyREST.

(Rodrigo Rodrigues Do Carmo) #6


I’m getting this error too:

[2017-04-05T10:45:04,375][INFO ][o.e.p.r.a.ACL ] no block has matched, forbidding by default: { ID:fd12cd80021c426dbc8466ec9aa6547d, TYP:MainRequest, USR:someUser (?), BRS:true, ACT:cluster:monitor/main, OA:, IDX:<N/A>, MET:GET, PTH:/, CNT:<OMITTED, LENGTH=0>, HDR:Accept,Accept-Encoding,Accept-Language,Authorization,Connection,content-length,Cookie,Host,Upgrade-Insecure-Requests,User-Agent, EFF:0, HIS:[Accept requests from users in group team1 on index1->[ldap_auth->false]], [Accept requests from users in group team1 on index1->[indices->true]], [kibana->[indices->true, auth_key->false]]

And my LDAP server is a Windows LDAP.
Is there a way to see which calls are being made to the server?

(Rodrigo Rodrigues Do Carmo) #7

Is there any different configuration for Windows Active Directory?

(Simone Scarduzio) #8

I would use wireshark to analyse the network traffic from the Elasticsearch node to the LDAP server. There should be a dissector for LDAP to show you exactly what’s going on in a graphical way.

The above log line adds nothing to the picture.

(Rodrigo Rodrigues Do Carmo) #9

Thank you @sscarduzio. I will check using Wireshark to see what is going on.

(Simone Scarduzio) #10

lovely, don’t forget to let us know :slight_smile:

(Rodrigo Rodrigues Do Carmo) #11

where can I find the test_example.ldif? In the elasticsearch directory there is no test/resources/test_example.ldif.


The link:

(Maor Shmueli) #13

what could be the alternative values for:


" LDAP configuration requirements:

user from search_user_base_DN should have uid attribute (can be overwritten using user_id_attribute)
groups from search_groups_base_DN should have uniqueMember attribute (can be overwritten using unique_member_attribute)"


(Maor Shmueli) #14

followed my previous update,
I ran Wireshark and catched a packet that holds the data sent to the ldap server.
You can see that the attributes have 0 items in it and the attributeDesc is uid.
In my company we are using Microsoft Active directory that by default don’t holds uid and uniqueMember attributes for users and groups, this is an example of the attributes Active Directory holds for user:

PS C:\Windows\system32> Get-ADUser testuser5

DistinguishedName : CN=testuser5,OU=Groups,DC=XXXXX,DC=XX,DC=XX
Enabled : True
GivenName : testuser5
Name : testuser5
ObjectClass : user
ObjectGUID : 9a064X5ae-feX25-448b-b864-ac5ed8fXd6637
SamAccountName : testuser5
SID : S-1-5-21-37826006-52974X2403-198261X2992-6X6516
Surname :
UserPrincipalName : [email protected]

This is the packet that I catched of a user trying to authenticate with that ldap server:

Frame 7: 145 bytes on wire (1160 bits), 145 bytes captured (1160 bits)
Linux cooked capture
Internet Protocol Version 4, Src:, Dst:
Transmission Control Protocol, Src Port: 35620, Dst Port: 389, Seq: 80, Ack: 23, Len: 77
Lightweight Directory Access Protocol
LDAPMessage searchRequest(2) “OU=Groups,DC=XXXXXX DC=XX,DC=XX” wholeSubtree
messageID: 2
protocolOp: searchRequest (3)
baseObject: OU=Groups,DC=XXXXXX,DC=XX,DC=XX
scope: wholeSubtree (2)
derefAliases: neverDerefAliases (0)
sizeLimit: 0
timeLimit: 0
typesOnly: False
Filter: (uid=testuser5)
filter: equalityMatch (3)
attributeDesc: uid
assertionValue: testuser5
attributes: 0 items
[Response In: 8]


(Mateusz Kołodziejczyk) #15

It seems that your LDAP user is not identified by uid attribute but by SamAccountName. You can override identifier name by ‘user_id_attribute’ key in ldap configuration. Example can be find in here:

(Rodrigo Rodrigues Do Carmo) #16

After analyzing Wireshark to see what was going on, I successfully managed to get a response from the AD server by using the follow configuration in elasticsearch.yml:

name: ldap
host: ******
port: 389
bind_password: ********
ssl_enabled: false
ssl_trust_all_certs: false
user_id_attribute: "sAMAccountName"
search_user_base_DN: *******

Now, the only problem is that I still cannot authenticate with ReadonlyRest, it is still saying that could not find the user even though if I use the ldapsearch command it finds successfully.
Is there something that I’m missing here:

- name: Accept requests from users in group team1 on index1
type: allow
- name: “ldap” # ldap name from ‘ldaps’ section
groups: [“Users”] # group within 'ou=Groups,dc=example,dc=com’
indices: [“index1”]

(Rodrigo Rodrigues Do Carmo) #17

Are there more options in ldap_auth?

(Mateusz Kołodziejczyk) #18

could you paste a log from ROR, please?

(Rodrigo Rodrigues Do Carmo) #19

Are you referring to this log?

[2017-04-06T14:28:20,356][INFO ][o.e.p.r.a.ACL ] no block has matched, forbidding by default: { ID:ac2f359110d6432888114f3b660b7503, TYP:GetIndexRequest, USR:someUser (?), BRS:true, ACT:indices:admin/get, OA:, IDX:sharepoint, MET:GET, PTH:/sharepoint, CNT:<OMITTED, LENGTH=0>, HDR:Accept,Accept-Encoding,Accept-Language,Authorization,Connection,content-length,Host,Upgrade-Insecure-Requests,User-Agent, EFF:0, HIS:[Accept requests from users in group team1 on index1->[ldap_auth->false]], [kibana->[indices->true, auth_key->false]], [Accept requests from users in group team1 on index1->[indices->true]] }

(Mateusz Kołodziejczyk) #20

are you sure that your LDAP group has “uniqueMember” attribute? and “uniqueMember” in ‘Users’ group contains ‘testuser5’?