ReadonlyREST with LDAP

Users Feedback
1

Hi,
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:

readonlyrest:
    enable: true
    response_if_req_forbidden: Forbidden by ReadonlyREST ES plugin

    access_control_rules:

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


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

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

    ldaps:

      - name: ldap
        host: "xxxx.xxxxxxx.com"
        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, OA:xxx.xx.xxx.xx, 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”

P.S
Our LDAP is microsoft active directory 2008R2

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.

3

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

4

Hi,

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, OA:172.22.xxx.xx, 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
https://github.com/sscarduzio/elasticsearch-readonlyrest-plugin/blob/master/src/test/resources/test_elasticsearch.yml

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

Questions:

  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

Regards

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.
6

Hi,

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:127.0.0.1, 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?
Thanks,

7

Update:
Is there any different configuration for Windows Active Directory?

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.

9

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

10

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

11

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

12

The link:

https://github.com/sscarduzio/elasticsearch-readonlyrest-plugin/blob/master/src/test/resources/test_example.ldif

13

Hi,
what could be the alternative values for:
unique_member_attribute
&
user_id_attribute

by:

" 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)"

Thanks,
Maor

14

Hi,
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 : testuser5@XXXXXX.XX.XX

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: 172.22.224.54, Dst: 172.16.20.162
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)
searchRequest
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)
equalityMatch
attributeDesc: uid
assertionValue: testuser5
attributes: 0 items
[Response In: 8]

Regards,
Maor

15

Hi,
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: elasticsearch-readonlyrest-plugin/test_elasticsearch.yml at 689bf0733f25d89fae0001868cbdfbcd4a71cda7 · sscarduzio/elasticsearch-readonlyrest-plugin · GitHub

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_dn:******
bind_password: ********
ssl_enabled: false
ssl_trust_all_certs: false
user_id_attribute: "sAMAccountName"
search_user_base_DN: *******
search_groups_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
ldap_auth:
- name: “ldap” # ldap name from ‘ldaps’ section
groups: [“Users”] # group within 'ou=Groups,dc=example,dc=com’
indices: [“index1”]

17

Are there more options in ldap_auth?

18

could you paste a log from ROR, please?

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:127.0.0.1, 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]] }

20

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