Hi @sscarduzio,
Suppose I have
bind_dn: "CN=c-ajitb,OU=Development,OU=abc – Corporate functions,OU=abc,OU=Mumbai Airoli abc,DC=ad,DC=example,DC=com"
search_user_base_DN: "dc=ad,dc=example,dc=com"
search_groups_base_DN: "dc=ad,dc=example,dc=com"
This is my configuration for LDAP. I want to give access to only those users who has OU=Development
Please provide configuration. As discussed with you on call we need sub group access only.Hi @sscarduzio,
Please guide us on authorisation,
I have implement below configuration.
# GROUPS (g1) ##############
- name: "Group 1"
kibana_access: admin
groups: ["g1"]
indices: [".kibana","logstash-*","index1"]
# GROUPS (g2) ##############
- name: "Group 2"
kibana_access: admin
groups: ["g2"]
indices: [".kibana","logstash-*","index2"]
# USERS TO GROUPS (LDAP) ########
users:
- username: c-ajitb
groups: ["g1"]
ldap_authentication:
name: ldap1
- username: amitkum
groups: ["g2"]
ldap_authentication:
name: ldap1
I have g1 and g2 group g1 has index1 access and g2 has index2 access, I am assigning g1 to c-ajitb and g2 to amitkum user.
But c-ajitb is able to access index2. He should not be accessible to index2.
waiting for your reply @sscarduzio`
I am using only one LDAP.
You have to provide the ES logs that show the ACL history, also you should learn how to read it, so you can understand better what is going on at all times. I will show you when you provide it.
Hi @sscarduzio,
We have these two users,
1. CN=RonakB,OU=Wallets Research,OU=abc – Client Analytics,OU=abc,OU=Mumbai Airoli abc,DC=ad,DC=example,DC=com
2. CN=c-shubhamg,OU=Technology,OU=Corporate Technology,OU=Corporate Group,OU=Mumbai example House,DC=ad,DC=example,DC=com
These two users are from different groups. They should be access different indexes specified.
and in search dn
search_user_base_DN: "dc=ad,dc=example,dc=com"
search_groups_base_DN: "dc=ad,dc=example,dc=com"
This is my LDAP information. Anyways I will provide you logs of ES. In above query it should work means two different groups with different index and two different users and single LDAP this should work.
Hi @sscarduzio,
- name: "Group 1"
kibana_access: admin
groups: ["g1"]
indices: [".kibana","logstash-*","index1"]
# GROUPS (g2) ##############
- name: "Group 2"
kibana_access: admin
groups: ["g2"]
indices: [".kibana","logstash-*","index2"]
# USERS TO GROUPS (LDAP) ########
users:
- username: c-ajitb
groups: ["g1"]
ldap_authentication:
name: ldap1
- username: amitkum
groups: ["g2"]
ldap_authentication:
name: ldap1
Hi @sscarduzio I dont want to use multiple LDAPs . Just do this work for us. Multiple groups and multiple usersHi @sscarduzio,
After saving settings I have below logs. I have two groups with index1 and index2 and two users c-ajitb and amitkum. and only one LDAP configuration. Here I am using LDAP for authentication. But my group wise authentication is not working . c-ajitb can use "GET index2/type2/2" but he has only access to "GET index1/type1/1" . Please give suggestion on this.
[2018-06-20T18:16:05,583][INFO ][t.b.r.e.IndexLevelActionFilter] [node-1] Settings observer refreshing...
[2018-06-20T18:16:05,585][INFO ][t.b.r.r.SerializationTool] no custom audit log serialisers found, proceeding with default.
[2018-06-20T18:16:05,597][INFO ][t.b.r.a.ACL ] ADDING BLOCK: { name: '::admin::', policy: ALLOW}
[2018-06-20T18:16:05,597][INFO ][t.b.r.a.ACL ] ADDING BLOCK: { name: '::LOGSTASH::', policy: ALLOW}
[2018-06-20T18:16:05,597][INFO ][t.b.r.a.ACL ] ADDING BLOCK: { name: '::KIBANA-SRV::', policy: ALLOW}
[2018-06-20T18:16:05,609][INFO ][t.b.r.a.ACL ] ADDING BLOCK: { name: 'g1', policy: ALLOW}
[2018-06-20T18:16:05,609][INFO ][t.b.r.a.ACL ] ADDING BLOCK: { name: 'g2', policy: ALLOW}
[2018-06-20T18:16:05,609][INFO ][t.b.r.e.IndexLevelActionFilter] [node-1] Configuration reloaded - ReadonlyREST enabled
[2018-06-20T18:16:05,609][INFO ][t.b.r.a.ACL ] [36mALLOWED by { name: '::admin::', policy: ALLOW} req={ ID:163145727-1711392549#37557, TYP:RRAdminRequest, CGR:N/A, USR:admin, BRS:false, KDX:null, ACT:cluster:admin/rradmin/refreshsettings, OA:172.21.153.176, DA:172.21.153.176, IDX:<N/A>, MET:POST, PTH:/_readonlyrest/admin/config, CNT:<OMITTED, LENGTH=2641>, HDR:{authorization=Basic YWRtaW46YWRtaW4=, Connection=close, Authorization=<OMITTED>, content-length=2641, content-type=application/json, Host=mumchelk01:9200}, HIS:[::admin::->[auth_key->true]] } [0m
[2018-06-20T18:16:05,624][INFO ][t.b.r.e.SettingsObservableImpl] all ok, written settingsreadonlyrest.yml
# GROUPS (LDAP) ##############
- name: "g1"
kibana_access: admin
groups: ["g1"]
indices: [".kibana","logstash-*","index1"]
# GROUPS (LDAP) ##############
- name: "g2"
kibana_access: admin
groups: ["g2"]
indices: [".kibana","logstash-*","index2"]
# USERS TO GROUPS (LDAP) ########
users:
- username: c-shubhamg
groups: ["g1"]
ldap_authentication:
name: ldap1
- username: c-ajitb
groups: ["g1"]
ldap_authentication:
name: ldap1
- username: amitkum
groups: ["g2"]
ldap_authentication:
name: ldap1
ldaps:
- name: ldap1
host: "ad.example.com"
port: 389 # default 389
ssl_enabled: false # default true
ssl_trust_all_certs: false # default false
bind_dn: "CN=c-shubhamg,OU=Technology,OU=Corporate Technology,OU=Corporate Group,OU=Mumbai example House,DC=ad,DC=crisil,DC=com" # skip for anonymous bind
bind_password: "pass@1234" # skip for anonymous bind
search_user_base_DN: "dc=ad,dc=example,dc=com"
search_groups_base_DN: "dc=ad,dc=example,dc=com"
user_id_attribute: "sAMAccountName" # default "uid"
unique_member_attribute: "member" # default "uniqueMember"
connection_pool_size: 10 # default 30
connection_timeout_in_sec: 10 # default 1
request_timeout_in_sec: 10 # default 1
cache_ttl_in_sec: 60
Hi @sscarduzio,
1. I want to close all things today so please reply as soon as possible. In above scenario I have created g1 and g2 and I have given access index1 to g1 and index2 to g2.
2. After that I have created two users c-ajitb and amitkum with g1 and g2.
3. Now, To test scenarios I login to c-ajitb and go to dev tool, and use GET index1/type1/1 this is fine because I have given g1 to c-ajitb and g1 has access of index1. But c-ajitb has no access of g2 and index2. But after fetching GET index2/type2/2 it is also working fine. It should give forbidden error this time because c-ajitb has no access of g2 and index2.
If you want any other info from me let me know as soon as possible.Hi @sscarduzio,
if you want more logs(after login),then we'll provide you but please try to give us an exact solution.
we are almost near to finish this process.Hi @sscarduzio,
Please reply as soon as possible. We are waiting for your reply. Below configuration should be run properly.
With only one LDAP for authentication. Then our all requirements will be fulfilled.
# GROUPS (LDAP) ##############
- name: "g1"
kibana_access: admin
groups: ["g1"]
indices: [".kibana","logstash-*","index1"]
# GROUPS (LDAP) ##############
- name: "g2"
kibana_access: admin
groups: ["g2"]
indices: [".kibana","logstash-*","index2"]
# USERS TO GROUPS (LDAP) ########
users:
- username: c-shubhamg
groups: ["g1"]
ldap_authentication:
name: ldap1
- username: c-ajitb
groups: ["g1"]
ldap_authentication:
name: ldap1
- username: amitkum
groups: ["g2"]
ldap_authentication:
name: ldap1Hi, your configuration file is incomplete, it’s a fragment. Come on man, don’t let’s do things in a hurry, let’s do things well and with calm, otherwise we spend 10x the time on this.
Also, as you can see, if you read the single log line you sent me, this is not a request to index2:
[2018-06-20T18:16:05,609][INFO ][t.b.r.a.ACL ] [36mALLOWED by { name: '::admin::', policy: ALLOW} req={ ID:163145727-1711392549#37557, TYP:RRAdminRequest, CGR:N/A, USR:admin, BRS:false, KDX:null, ACT:cluster:admin/rradmin/refreshsettings, OA:172.21.153.176, DA:172.21.153.176, IDX:<N/A>, MET:POST, PTH:/_readonlyrest/admin/config, CNT:<OMITTED, LENGTH=2641>, HDR:{authorization=Basic YWRtaW46YWRtaW4=, Connection=close, Authorization=<OMITTED>, content-length=2641, content-type=application/json, Host=mumchelk01:9200}, HIS:[::admin::->[auth_key->true]] } [0m
Look, it’s just a settings refresh. How can you state your user can see the index2? You did not send me the right logs.
SUGGESTION
Don’t use Kibana to test what index a user can see. Switch off Kibana and use cURL towards Elasticsearch.
For example:
curl -vvv -H 'Content-Type: application/json' -u c-shubhamg:XXXXXXX -k "http://localhost:9200/index2/_search"
Where XXXXXX is the LDAP password of that user.
The expected result is a 401/403 error, permission denied. If this is not the case, please go to elasticsearch.log and copy the single log line generated
Hi Simone,
i tried, "https://localhost:9200/index2/_search and https://localhost:9200/index1/_search" both are returning
the value of index which is wrong.
In my cofiguration file i have 2 groups(Corporate and Technology).
In the Corporate Group users i am giving access of index1 and In the Technology users i am giving access
of index2.
our requirement is,Corporate Group users should not have access the index2 and Technology users should
not have access the index1.(it must be give forbidden OR 401/403)
ReadOnlyRest Configuration File is:
readonlyrest:
ssl:
enable: true
keystore_file: "/opt/READONLYREST/elasticsearch-6.3.0/config/keystore.jks"
keystore_pass: readonlyrest
key_pass: readonlyrest
key_alias: elk01 #This is needed only when the keystore has multiple entries
audit_collector: true
access_control_rules:
- name: "::admin::"
auth_key: admin:admin
# MACHINES ##################
- name: "::LOGSTASH::"
auth_key: logstash:logstash
actions: ["indices:data/read/*","indices:data/write/*","indices:admin/template/*","indices:admin/create"]
indices: ["logstash-*"]
- name: "::KIBANA-SRV::"
auth_key: kibana:kibana
verbosity: error
# GROUPS (LDAP) ##############
- name: "Corporate Group"
kibana_access: admin
groups: ["Corporate Group"]
indices: [".kibana","logstash-*","index1"]
- name: "Technlogy"
kibana_access: admin
groups: ["Technology"]
indices: [".kibana","logstash-*","index2"]
# USERS TO GROUPS (LDAP) ########
users:
- username: c-shubhamg
groups: ["Corporate Group"]
ldap_authentication:
name: ldap1
- username: amitkum
groups: ["Corporate Group"]
ldap_authentication:
name: ldap1
- username: c-ajitb
groups: ["Technology"]
ldap_authentication:
name: ldap1
- username: c-akhilesht
groups: ["Technology"]
ldap_authentication:
name: ldap1
ldaps:
- name: ldap1
host: "ad.example.com"
port: 389 # default 389
ssl_enabled: false # default true
ssl_trust_all_certs: false # default false
bind_dn: "CN=c-shubhamg,OU=Technology,OU=Corporate Technology,OU=Corporate
Group,OU=Mumbai AbcHouse,DC=ad,DC=Abc,DC=com"
bind_password: "Abc@2011" # skip for anonymous bind
search_user_base_DN: "dc=ad,dc=example,dc=com"
search_groups_base_DN: "dc=ad,dc=example,dc=com"
user_id_attribute: "sAMAccountName" # default "uid"
unique_member_attribute: "member" # default "uniqueMember"
connection_pool_size: 10 # default 30
connection_timeout_in_sec: 10 # default 1
request_timeout_in_sec: 10 # default 1
cache_ttl_in_sec: 60
please let me know where i am wrong in this configuration.
@Akhilesh you need to paste the logs that correspond to those curl command! That was the whole point, mate. I don’t have your system at disposition for test this autonomously.
Hi Simone,
Now we are able to login with different LDAP Groups,but index wise authorization is still pending.
readonlyrest.yml
readonlyrest:
ssl:
enable: true
keystore_file: "/opt/READONLYREST/elasticsearch-6.3.0/config/keystore.jks"
keystore_pass: readonlyrest
key_pass: readonlyrest
key_alias: elk01 #This is needed only when the keystore has multiple entries
audit_collector: true
access_control_rules:
- name: "::admin::"
auth_key: admin:admin
- name: "::LOGSTASH::"
auth_key: logstash:logstash
actions: ["indices:data/read/*","indices:data/write/*","indices:admin/template/*","indices:admin/create"]
indices: ["logstash-*"]
- name: "::KIBANA-SRV::"
auth_key: kibana:kibana
verbosity: error
- name: "ABC GROUP BUISSNESS"
ldap_authentication:
name: "ldap1"
cache_ttl_in_sec: 60
#ldap_authorization:
# name: "ldap1"
#groups: ["Technology"]
#cache_ttl_in_sec: 60
#indices: [".kibana","index1","logstash-*"]
- name: "ABC GROUP DEVELOPMENT"
ldap_authentication:
name: "ldap2"
cache_ttl_in_sec: 60
#ldap_authorization:
# name: "ldap2"
#groups: ["Development"]
#cache_ttl_in_sec: 60
#indices: [".kibana","index2","logstash-*"]
ldaps:
- name: ldap1
host: "ad.abc.com"
port: 389
ssl_enabled: false
ssl_trust_all_certs: true
bind_dn: "CN=c-abcd,OU=Technology,OU=Corporate Technology,OU=Corporate Group,OU=Mumbai abc House,DC=ad,DC=abc,DC=com"
bind_password: "abc@2018"
search_user_base_DN: "OU=Technology,OU=Corporate Technology,OU=Corporate Group,OU=Mumbai abc House,DC=ad,DC=abc,DC=com"
search_groups_base_DN: "OU=Technology,OU=Corporate Technology,OU=Corporate Group,OU=Mumbai abc House,DC=ad,DC=abc,DC=com"
user_id_attribute: "sAMAccountName"
unique_member_attribute: "uniqueMember"
connection_pool_size: 10
connection_timeout_in_sec: 10
request_timeout_in_sec: 10
cache_ttl_in_sec: 60
- name: ldap2
host: "ad.abc.com"
port: 389
ssl_enabled: false
ssl_trust_all_certs: true
bind_dn: "CN=c-ajitb,OU=Development,OU=abc – Corporate functions,OU=Mercator,OU=Mumbai Airoli abc,DC=ad,DC=abc,DC=com"
bind_password: "pass#1234"
search_user_base_DN: "OU=Development,OU=abc – Corporate functions,OU=abc,OU=Mumbai Airoli abc,DC=ad,DC=abc,DC=com"
search_groups_base_DN: "OU=Development,OU=abc – Corporate functions,OU=abc,OU=Mumbai Airoli abc,DC=ad,DC=abc,DC=com"
user_id_attribute: "sAMAccountName"
unique_member_attribute: "uniqueMember"
connection_pool_size: 10
connection_timeout_in_sec: 10
request_timeout_in_sec: 10
cache_ttl_in_sec: 60
This configuration is working fine for Authentication with different ldap groups but if we uncomment these lines from our configuration file-
#ldap_authorization:
# name: "ldap1"
#groups: ["Technology"]
#cache_ttl_in_sec: 60
#indices: [".kibana","index1","logstash-*"]
#ldap_authorization:
# name: "ldap2"
#groups: ["Development"]
#cache_ttl_in_sec: 60
#indices: [".kibana","index2","logstash-*"]
Then we are getting unauthorized exception on login screen. We are now able to work with LDAP. Only last thing is pending i.e. LDAP authorization. Commented code should work with rest of the configuration, Means two LDAPs and with different index access.
Please suggest us ASAP.
Hi,
Could you post some logs ? Without logs, it is impossible to help you.
Logs from elasticsearch, or from dedicated logs where are RoR logs in debug mode.
Also maybe kibana logs ?
Also remove cache_ttl_in_sec from rule block
Sure we will give you logs, But I have stated simply
#ldap_authorization:
# name: “ldap1”
#groups: [“Technology”]
#cache_ttl_in_sec: 60
#indices: [".kibana",“index1”,“logstash-*”]
#ldap_authorization:
# name: "ldap2"
#groups: ["Development"]
#cache_ttl_in_sec: 60
#indices: [".kibana","index2","logstash-*"]
Is this configuration correct or not after uncomment? If its wrong then provide us proper configuration for multiple LDAPs and Multiple groups with different index each.
@sscarduzio / @ld57 Can please reply on this. We are waiting for your reply.
Hi @ld57 ,
here is the kibana logs,
{"type":"response","@timestamp":"2018-06-25T09:56:34Z","tags":[],"pid":1409,"method":"post","statusCode":200,"req":{"url":"/login","method":"post","headers":{"host":"mumchelk01:5601","connection":"keep-alive","content-length":"37","origin":"http://mumchelk01:5601","kbn-xsrf":"6.3.0","kbn-version":"6.3.0","user-agent":"Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36","content-type":"application/x-www-form-urlencoded; charset=UTF-8","accept":"application/json, text/javascript, */*; q=0.01","x-requested-with":"XMLHttpRequest","referer":"http://mumchelk01:5601/login","accept-encoding":"gzip, deflate","accept-language":"en-GB,en;q=0.9,en-US;q=0.8,fr;q=0.7"},"remoteAddress":"172.21.215.204","userAgent":"172.21.215.204","referer":"http://mumchelk01:5601/login"},"res":{"statusCode":200,"responseTime":118,"contentLength":9},"message":"POST /login 200 118ms - 9.0B"}
{"type":"response","@timestamp":"2018-06-25T09:56:34Z","tags":[],"pid":1409,"method":"get","statusCode":304,"req":{"url":"/plugins/readonlyrest_kbn/css/normalize.min.css","method":"get","headers":{"host":"mumchelk01:5601","connection":"keep-alive","if-none-match":"\"19eb672b6fc36e089f0fd5390857b11ef04ca1de-gzip\"","if-modified-since":"Tue, 19 Jun 2018 09:54:54 GMT","user-agent":"Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36","accept":"text/css,*/*;q=0.1","referer":"http://mumchelk01:5601/login","accept-encoding":"gzip, deflate","accept-language":"en-GB,en;q=0.9,en-US;q=0.8,fr;q=0.7"},"remoteAddress":"172.21.215.204","userAgent":"172.21.215.204","referer":"http://mumchelk01:5601/login"},"res":{"statusCode":304,"responseTime":2,"contentLength":9},"message":"GET /plugins/readonlyrest_kbn/css/normalize.min.css 304 2ms - 9.0B"}
{"type":"response","@timestamp":"2018-06-25T09:56:34Z","tags":[],"pid":1409,"method":"get","statusCode":304,"req":{"url":"/plugins/readonlyrest_kbn/js/jquery-3.2.1.min.js","method":"get","headers":{"host":"mumchelk01:5601","connection":"keep-alive","accept":"text/javascript, application/javascript, application/ecmascript, application/x-ecmascript, */*; q=0.01","x-requested-with":"XMLHttpRequest","user-agent":"Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36","referer":"http://mumchelk01:5601/login","accept-encoding":"gzip, deflate","accept-language":"en-GB,en;q=0.9,en-US;q=0.8,fr;q=0.7","if-none-match":"\"be73a6288956ace701a7c5900c4f5185b3fe29e0-gzip\"","if-modified-since":"Tue, 19 Jun 2018 09:54:54 GMT"},"remoteAddress":"172.21.215.204","userAgent":"172.21.215.204","referer":"http://mumchelk01:5601/login"},"res":{"statusCode":304,"responseTime":1,"contentLength":9},"message":"GET /plugins/readonlyrest_kbn/js/jquery-3.2.1.min.js 304 1ms - 9.0B"}
{"type":"response","@timestamp":"2018-06-25T09:56:35Z","tags":[],"pid":1409,"method":"get","statusCode":304,"req":{"url":"/plugins/readonlyrest_kbn/js/jquery.shake.js","method":"get","headers":{"host":"mumchelk01:5601","connection":"keep-alive","accept":"text/javascript, application/javascript, application/ecmascript, application/x-ecmascript, */*; q=0.01","x-requested-with":"XMLHttpRequest","user-agent":"Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36","referer":"http://mumchelk01:5601/login","accept-encoding":"gzip, deflate","accept-language":"en-GB,en;q=0.9,en-US;q=0.8,fr;q=0.7","if-none-match":"\"4a23464a70922f8529fa8749c9c94af9be5efeef-gzip\"","if-modified-since":"Tue, 19 Jun 2018 09:54:54 GMT"},"remoteAddress":"172.21.215.204","userAgent":"172.21.215.204","referer":"http://mumchelk01:5601/login"},"res":{"statusCode":304,"responseTime":1,"contentLength":9},"message":"GET /plugins/readonlyrest_kbn/js/jquery.shake.js 304 1ms - 9.0B"}@Akhilesh the most important logs are the ES ones for the case at hand.
- Use curl as I explained you to simulate a certain user trying to access a certain index.
- Then give us the debug logs ES has generated in response to the above curl request
HI Simone Scarduzio,
here is the Es logs.
`[2018-06-25T15:44:37,401][INFO ][t.b.r.a.ACL ] e[35mFORBIDDEN by default req={ ID:1493330477-197998816#374, TYP:NodesInfoRequest, CGR:N/A, USR:c-ajitb, BRS:false, KDX:null, ACT:cluster:monitor/nodes/info, OA:localhost, DA:0.0.0.0, IDX:<N/A>, MET:GET, PTH:/_nodes/_local, CNT:<N/A>, HDR:{authorization=Basic Yy1haml0YjpwYXNzIzEyMzQ=, Connection=close, Authorization=<OMITTED>, content-length=0, Host=Abchelk01:9200}, HIS:[::admin::->[auth_key->false]], [::LOGSTASH::->[auth_key->false]], [::KIBANA-SRV::->[auth_key->false]], [BUISSNESS GROUP.->[ldap_authentication->false]], [DEVELOPMENT GROUP.->[ldap_authorization->false, ldap_authentication->true, indices->true]] } e[0m` HI Simone Scarduzio,
here is the some more Es logs.
[2018-06-25T15:47:31,913][DEBUG][t.b.r.a.d.l.l.AuthenticationLdapClientLoggingDecorator] Trying to authenticate user [c-ajitb] with LDAP [ldap2]
[2018-06-25T15:47:31,935][DEBUG][t.b.r.a.d.l.l.AuthenticationLdapClientLoggingDecorator] User [c-ajitb] authenticated by LDAP [ldap2]
[2018-06-25T15:47:31,935][DEBUG][t.b.r.a.b.r.i.IndicesSyncRule] Stage -1
[2018-06-25T15:47:31,935][DEBUG][t.b.r.a.d.l.l.AuthenticationLdapClientLoggingDecorator] Trying to fetch user with identifier [c-ajitb] from LDAP [ldap2]
[2018-06-25T15:47:31,941][DEBUG][t.b.r.a.d.l.l.AuthenticationLdapClientLoggingDecorator] User with identifier [c-ajitb] found [dn = CN=c-AjitB,OU=Development,OU=Abc – Corporate functions,OU=Abc,OU=Mumbai Airoli Abc,DC=ad,DC=Abc,DC=com]
[2018-06-25T15:47:31,941][DEBUG][t.b.r.a.d.l.l.GroupsProviderLdapClientLoggingDecorator] Trying to fetch user [id=c-ajitb, dnCN=c-AjitB,OU=Development,OU=Abc – Corporate functions,OU=Abc,OU=Mumbai Airoli Abc,DC=ad,DC=Abc,DC=com] groups from LDAP [ldap2]
[2018-06-25T15:47:31,941][DEBUG][t.b.r.a.d.l.u.UnboundidGroupsProviderLdapClient] LDAP search string: (&(cn=*)(uniqueMember=CN=c-AjitB,OU=Development,OU=Abc \e2\80\93 Corporate functions,OU=Abc,OU=Mumbai Airoli Abc,DC=ad,DC=Abc,DC=com)) | groupNameAttr: cn
[2018-06-25T15:47:31,948][DEBUG][t.b.r.a.d.l.l.GroupsProviderLdapClientLoggingDecorator] LDAP [ldap2] returned for user [c-ajitb] following groups: []
[2018-06-25T15:47:31,949][DEBUG][t.b.r.a.b.Block ] e[33m[DEVELOPMENT GROUP.] the request matches no rules in this block: { ID:648372969-867378791#235, TYP:NodesInfoRequest, CGR:N/A, USR:c-ajitb, BRS:false, KDX:null, ACT:cluster:monitor/nodes/info, OA:172.21.153.176, DA:172.21.153.176, IDX:<N/A>, MET:GET, PTH:/_nodes/_local, CNT:<N/A>, HDR:{authorization=Basic Yy1haml0YjpwYXNzIzEyMzQ=, Connection=close, content-length=0, Host=mumchelk01:9200}, HIS:[::admin::->[auth_key->false]], [::LOGSTASH::->[auth_key->false]], [::KIBANA-SRV::->[auth_key->false]], [BUISSNESS GROUP.->[ldap_authentication->false]], [DEVELOPMENT GROUP.->[ldap_authentication->true, ldap_authorization->false, indices->true]] }e[0m
[2018-06-25T15:47:31,952][DEBUG][r.suppressed ] path: /_nodes/_local, params: {settings_filter=transport.profiles.*.xpack.security.ssl.trust_restrictions,xpack.notification.email.account.*.smtp.password,xpack.notification.jira.account.*.secure_user,xpack.security.transport.ssl.key,xpack.ssl.trust_restrictions.path,xpack.ssl.keystore.password,xpack.security.transport.ssl.truststore.algorithm,xpack.security.http.ssl.truststore.password,xpack.security.http.ssl.keystore.password,xpack.http.ssl.certificate,xpack.security.transport.ssl.truststore.password,xpack.security.authc.realms.*.certificate_authorities,xpack.http.ssl.truststore.algorithm,transport.profiles.*.xpack.security.ssl.certificate_authorities,xpack.security.http.ssl.supported_protocols,xpack.security.authc.realms.*.ssl.key_passphrase,xpack.ssl.keystore.path,xpack.security.transport.ssl.supported_protocols,xpack.notification.jira.account.*.user,xpack.security.http.ssl.truststore.algorithm,xpack.notification.jira.account.*.secure_password,xpack.ssl.certificate_authorities,transport.profiles.*.xpack.security.ssl.keystore.password,xpack.ssl.truststore.path,xpack.security.transport.ssl.keystore.key_password,xpack.notification.jira.account.*.url,xpack.security.http.ssl.key,xpack.security.http.ssl.keystore.type,xpack.security.http.ssl.verification_mode,xpack.security.authc.realms.*.ssl.trust_restrictions.path,xpack.ssl.certificate,xpack.security.authc.realms.*.ssl.keystore.type,transport.profiles.*.xpack.security.ssl.supported_protocols,xpack.security.authc.realms.*.ssl.keystore.path,xpack.ssl.verification_mode,xpack.security.authc.realms.*.ssl.certificate,xpack.security.transport.ssl.cipher_suites,transport.profiles.*.xpack.security.ssl.truststore.path,xpack.security.http.ssl.certificate,xpack.ssl.truststore.type,xpack.security.authc.realms.*.ssl.keystore.algorithm,xpack.ssl.cipher_suites,xpack.http.ssl.keystore.type,xpack.security.http.ssl.certificate_authorities,xpack.http.ssl.keystore.algorithm,transport.profiles.*.xpack.security.ssl.truststore.type,xpack.ssl.truststore.algorithm,transport.profiles.*.xpack.security.ssl.cipher_suites,xpack.http.ssl.supported_protocols,xpack.http.ssl.keystore.path,xpack.security.authc.realms.*.encryption.keystore.algorithm,xpack.security.authc.realms.*.ssl.keystore.key_password,xpack.notification.hipchat.account.*.secure_auth_token,xpack.security.http.ssl.truststore.path,xpack.security.authc.realms.*.encryption.keystore.path,xpack.http.ssl.truststore.password,xpack.security.authc.realms.*.ssl.truststore.algorithm,xpack.security.authc.realms.*.ssl.truststore.type,xpack.security.transport.ssl.verification_mode,xpack.security.authc.realms.*.signing.keystore.type,xpack.notification.pagerduty.account.*.secure_service_api_key,xpack.security.transport.ssl.certificate,xpack.security.authc.realms.*.encryption.keystore.type,xpack.monitoring.exporters.*.auth.*,xpack.ssl.keystore.type,xpack.http.ssl.key,xpack.security.authc.realms.*.bind_dn,xpack.security.authc.realms.*.ssl.truststore.password,xpack.http.ssl.keystore.key_password,xpack.security.authc.realms.*.signing.key,xpack.ssl.keystore.key_password,transport.profiles.*.xpack.security.ssl.truststore.password,xpack.http.ssl.verification_mode,transport.profiles.*.xpack.security.ssl.certificate,transport.profiles.*.xpack.security.ssl.verification_mode,xpack.security.http.ssl.keystore.key_password,transport.profiles.*.xpack.security.*,xpack.security.authc.realms.*.ssl.keystore.password,xpack.security.authc.realms.*.ssl.cipher_suites,transport.profiles.*.xpack.security.ssl.keystore.key_password,xpack.monitoring.exporters.*.ssl,xpack.http.ssl.truststore.path,xpack.http.ssl.key_passphrase,xpack.security.http.ssl.cipher_suites,xpack.notification.pagerduty.account.*.service_api_key,xpack.security.authc.realms.*.hostname_verification,transport.profiles.*.xpack.security.ssl.truststore.algorithm,xpack.security.transport.ssl.truststore.type,xpack.security.authc.realms.*.truststore.algorithm,xpack.security.transport.ssl.certificate_authorities,xpack.http.ssl.keystore.password,xpack.security.transport.ssl.keystore.path,xpack.security.authc.realms.*.encryption.key,xpack.http.ssl.trust_restrictions.path,xpack.security.authc.realms.*.bind_password,xpack.security.authc.realms.*.ssl.supported_protocols,xpack.security.transport.ssl.truststore.path,xpack.security.transport.ssl.trust_restrictions.path,xpack.security.http.ssl.truststore.type,xpack.security.http.ssl.key_passphrase,xpack.ssl.truststore.password,xpack.http.ssl.certificate_authorities,xpack.security.http.ssl.trust_restrictions.path,xpack.security.authc.realms.*.ssl.key,xpack.security.authc.realms.*.ssl.verification_mode,xpack.http.ssl.truststore.type,xpack.security.transport.ssl.keystore.type,transport.profiles.*.xpack.security.ssl.keystore.algorithm,xpack.security.http.ssl.keystore.algorithm,xpack.notification.slack.account.*.url,xpack.notification.jira.account.*.secure_url,xpack.security.authc.realms.*.ssl.truststore.path,xpack.ssl.key_passphrase,xpack.security.authc.realms.*.signing.keystore.path,xpack.security.transport.ssl.client_authentication,xpack.notification.hipchat.account.*.auth_token,xpack.notification.jira.account.*.password,transport.profiles.*.xpack.security.ssl.key,xpack.security.transport.ssl.keystore.password,xpack.http.ssl.client_authentication,xpack.security.transport.ssl.key_passphrase,xpack.monitoring.exporters.*.auth.password,xpack.security.transport.ssl.keystore.algorithm,transport.profiles.*.xpack.security.ssl.keystore.type,xpack.monitoring.exporters.*.ssl.*,xpack.security.hide_settings,xpack.ssl.key,xpack.security.authc.realms.*.ssl.certificate_authorities,xpack.notification.slack.account.*.secure_url,transport.profiles.*.xpack.security.ssl.client_authentication,xpack.security.authc.realms.*.truststore.password,transport.profiles.*.xpack.security.ssl.keystore.path,xpack.security.http.ssl.keystore.path,xpack.ssl.supported_protocols,xpack.http.ssl.cipher_suites,xpack.security.authc.realms.*.ssl.client_authentication,xpack.security.authc.realms.*.signing.certificate,xpack.security.authc.realms.*.encryption.certificate,xpack.monitoring.exporters.*.auth.username,xpack.security.authc.realms.*.truststore.path,xpack.security.http.ssl.client_authentication,xpack.security.authc.accept_default_password,xpack.security.authc.realms.*.signing.keystore.algorithm,xpack.ssl.client_authentication,xpack.ssl.keystore.algorithm,transport.profiles.*.xpack.security.ssl.key_passphrase, nodeId=_local}
tech.beshu.ror.es.IndexLevelActionFilter$1$1: forbidden
at tech.beshu.ror.es.IndexLevelActionFilter$1.onForbidden(IndexLevelActionFilter.java:162) ~[?:?]