# Query logs-\* with rights only on logs-user1-\* ?

**URL:** <https://forum.search-guard.com/t/query-logs-with-rights-only-on-logs-user1/1007>\
**Category:** Search Guard\
**Created:** [July 11, 2018, 8:20am UTC](https://forum.search-guard.com/t/query-logs-with-rights-only-on-logs-user1/1007 "2018-07-11T08:20:07Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![Aurelien\_GUILLAUME](https://avatars.discourse-cdn.com/v4/letter/a/dbc845/32.png) [@Aurelien\_GUILLAUME](https://forum.search-guard.com/u/Aurelien_GUILLAUME)\
**Post date:** [July 11, 2018, 8:20am UTC](https://forum.search-guard.com/t/query-logs-with-rights-only-on-logs-user1/1007/1 "2018-07-11T08:20:07Z")

</div>

Hello,

This is more of a theoretical question, because i couldn’t find a definitive answer in the docs (ES6.3.1 / SG 6.3.1-22.3)

I’m looking to provide a common read-only shared Kibana dashboard to several separate users who cannot see each others’ data.

I split the user’s data into several indexes:

- logs-user1-YYYY.MM.DD (1 by day)

- logs-user2-YYYY.MM.DD (1 by day)

…

- logs-userN-YYYY.MM.DD (1 by day)

But I run into at least one major issue, and i don’t know if this is by design or it’s something I don’t do correctly.

I added privileges to user1 onto logs-user1-\* (INDICES\_ALL), and I’m able to query the state of these indexes by querying /logs-user1-_; but if I run a query on /logs-_ with the same user, the permission is denied.

Is this behavior expected because Search Guard denies or allows based on the content, but is not able to filter the results themselves ?

Thanks,

Best regards,

Aurélien

---

<div class="post-metadata">

**Author:** ![jkressin](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/jkressin/32/9_2.png) [@jkressin](https://forum.search-guard.com/u/jkressin)\
**Post date:** [July 11, 2018, 1:49pm UTC](https://forum.search-guard.com/t/query-logs-with-rights-only-on-logs-user1/1007/2 "2018-07-11T13:49:27Z")

</div>

Search Guard has two ways of dealing with insufficient privileges when querying multiple indices (like in your case all the logs-\*) indices.

1. Deny the request completely

2. Only return data from allowed indices

The default is 1), because filtering out results (silently) may lead to strange results, especially when using aggregations. But it depends on the use case which option is “better”.

So to activate 2), add this to your sg\_config.yaml:

searchguard:

dynamic:

kibana:

do\_not\_fail\_on\_forbidden: true

``

Setting do\_not\_fail\_on\_forbidden to false will give you behavior 1), setting it to true will give you behavior 2).

> **···**
>
> On Wednesday, July 11, 2018 at 10:20:07 AM UTC+2, [footplus@gmail.com](mailto:footplus@gmail.com) wrote:
> 
> > Hello,
> 
> > 
> 
> > This is more of a theoretical question, because i couldn’t find a definitive answer in the docs (ES6.3.1 / SG 6.3.1-22.3)
> 
> > 
> 
> > I’m looking to provide a common read-only shared Kibana dashboard to several separate users who cannot see each others’ data.
> 
> > 
> 
> > I split the user’s data into several indexes:
> 
> > - logs-user1-YYYY.MM.DD (1 by day)
> 
> > - logs-user2-YYYY.MM.DD (1 by day)
> 
> > …
> 
> > - logs-userN-YYYY.MM.DD (1 by day)
> 
> > 
> 
> > But I run into at least one major issue, and i don’t know if this is by design or it’s something I don’t do correctly.
> 
> > 
> 
> > I added privileges to user1 onto logs-user1-\* (INDICES\_ALL), and I’m able to query the state of these indexes by querying /logs-user1-_; but if I run a query on /logs-_ with the same user, the permission is denied.
> 
> > 
> 
> > Is this behavior expected because Search Guard denies or allows based on the content, but is not able to filter the results themselves ?
> 
> > 
> 
> > Thanks,
> 
> > Best regards,
> 
> > Aurélien
> 
> > 
> 
> >

---

<div class="post-metadata">

**Author:** ![Aurelien\_GUILLAUME](https://avatars.discourse-cdn.com/v4/letter/a/dbc845/32.png) [@Aurelien\_GUILLAUME](https://forum.search-guard.com/u/Aurelien_GUILLAUME)\
**Post date:** [July 11, 2018, 3:40pm UTC](https://forum.search-guard.com/t/query-logs-with-rights-only-on-logs-user1/1007/3 "2018-07-11T15:40:07Z")

</div>

Hello,

Thanks for your quick response.

> Setting do\_not\_fail\_on\_forbidden to false will give you behavior 1), setting it to true will give you behavior 2).

> 

I had already tried this one, but it doesn’t seem to be effective ?

curl -u user1:pass ‘es:9200/\_cat/indices?index=access\_log-\*’ → permission denied  
{“error”:{“root\_cause”:[{“type”:“security\_exception”,“reason”:“no permissions for [indices:monitor/stats] and User [name=user1, roles=[customer], requestedTenant=null]”}],“type”:“security\_exception”,“reason”:“no permissions for [indices:monitor/stats] and User [name=user1, roles=[customer], requestedTenant=null]”},“status”:403}

``

curl -u user1:pass ‘es:9200/\_cat/indices?index=access\_log-user1-\*’ → 200 with index statuses  
green open access\_log-user1-2018.07.03 yDSuaz92S9iTM0izkV7Wfg 5 1 1104624 0 1.1gb 564.7mb  
green open access\_log-user1-2018.07.08 g8j24cSYS9qkiHJHWv6y7g 5 1 1862963 0 1.8gb 952.6mb  
green open access\_log-user1-2018.07.10 bNuWnlbURXyK3Xc0R6VYCQ 5 1 2030975 0 2gb 1gb  
green open access\_log-user1-2018.07.11 m1pXTJuWTrGIfR51ZpOl8Q 5 1 1331561 0 1.2gb 659.8mb  
green open access\_log-user1-2018.07.06 iYFrm3tkSNCcVvun-4KQBQ 5 1 2316625 0 2.2gb 1.1gb  
green open access\_log-user1-2018.07.02 yf-Q1-RjQdeLdBrwfzQ8Sg 5 1 1567440 0 1.4gb 761.9mb  
green open access\_log-user1-2018.07.07 M1rtzMTgSaqs\_WohIhzvjg 5 1 1822786 0 1.8gb 938.9mb  
green open access\_log-user1-2018.07.09 M8PjznBdSyGTWCnhR2JqXA 5 1 2137226 0 2.1gb 1gb  
green open access\_log-user1-2018.07.05 zIlMiTKGQLCzbhRIpINyQg 5 1 1517486 0 1.5gb 776.5mb

``

sg\_config.yml:

searchguard:  
dynamic:  
kibana:  
do\_not\_fail\_on\_forbidden: true  
http:  
anonymous\_auth\_enabled: false  
xff:  
enabled: false  
internalProxies: ‘192.168.0.10|192.168.0.11’ # regex pattern  
#internalProxies: ‘.\*’ # trust all internal proxies, regex pattern  
remoteIpHeader: ‘x-forwarded-for’  
proxiesHeader: ‘x-forwarded-by’  
authc:  
basic\_internal\_auth\_domain:  
http\_enabled: true  
transport\_enabled: true  
order: 4  
http\_authenticator:  
type: basic  
challenge: true  
authentication\_backend:  
type: intern

``

> **···**
>
> Le mercredi 11 juillet 2018 15:49:27 UTC+2, Jochen Kressin a écrit :

---

<div class="post-metadata">

**Author:** ![Aurelien\_GUILLAUME](https://avatars.discourse-cdn.com/v4/letter/a/dbc845/32.png) [@Aurelien\_GUILLAUME](https://forum.search-guard.com/u/Aurelien_GUILLAUME)\
**Post date:** [July 13, 2018, 2:20pm UTC](https://forum.search-guard.com/t/query-logs-with-rights-only-on-logs-user1/1007/4 "2018-07-13T14:20:17Z")

</div>

Hello,

> Hello,

> 

> Thanks for your quick response.

> 

> > Setting do\_not\_fail\_on\_forbidden to false will give you behavior 1), setting it to true will give you behavior 2).

> >

> 

> I had already tried this one, but it doesn’t seem to be effective ?

> 

Searching further in the code : is this setting even used for something other than the \_searchguard/kibana info page ?

BCS-NBK-AGU [footy] ~/Projects/search-guard % grep -r forbidden .

./sgconfig/sg\_config.yml: #do\_not\_fail\_on\_forbidden: false

./src/main/java/com/floragunn/searchguard/configuration/PrivilegesEvaluator.java: && getConfigSettings().getAsBoolean(“searchguard.dynamic.kibana.do\_not\_fail\_on\_forbidden”, false);

./src/main/java/com/floragunn/searchguard/tools/SearchGuardAdmin.java: System.out.println(" a configuration error and is therefore forbidden now.");

./src/main/java/com/floragunn/searchguard/rest/KibanaInfoAction.java: builder.field(“not\_fail\_on\_forbidden\_enabled”, evaluator.notFailOnForbiddenEnabled());

!130! BCS-NBK-AGU [footy] ~/Projects/search-guard % grep -r notFailOnForbidden .

./src/main/java/com/floragunn/searchguard/configuration/PrivilegesEvaluator.java: public boolean notFailOnForbiddenEnabled() {

./src/main/java/com/floragunn/searchguard/rest/KibanaInfoAction.java: builder.field(“not\_fail\_on\_forbidden\_enabled”, evaluator.notFailOnForbiddenEnabled());

Thanks,

Best regards,

Aurélien

> **···**
>
> > On 11 Jul 2018, at 17:40, [footplus@gmail.com](mailto:footplus@gmail.com) wrote:  
> > Le mercredi 11 juillet 2018 15:49:27 UTC+2, Jochen Kressin a écrit :

---

<div class="post-metadata">

**Author:** ![jkressin](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/jkressin/32/9_2.png) [@jkressin](https://forum.search-guard.com/u/jkressin)\
**Post date:** [July 18, 2018, 5:03pm UTC](https://forum.search-guard.com/t/query-logs-with-rights-only-on-logs-user1/1007/5 "2018-07-18T17:03:58Z")

</div>

I think we now have a guess regarding this issue: Am I right in the assumption that you are using the Community Edition? If this is the case, please try the 6.3.1-compliance-2 SG plugin.

Background: The feature I mentioned was once an Enterprise feature, but we made it a Community feature. This has been implemented in the SG Compliance codebase. We are in the process of merging the codebases, but for now it is only available in the compliance builds.

You can use these builds and disable all enterprise features as you probably did with the 22.3 version.

> **···**
>
> On Friday, July 13, 2018 at 4:20:20 PM UTC+2, Aurélien GUILLAUME wrote:
> 
> > Hello,
> 
> > > On 11 Jul 2018, at 17:40, [footplus@gmail.com](mailto:footplus@gmail.com) wrote:
> 
> > > Hello,
> 
> > >
> 
> > > Thanks for your quick response.
> 
> > >
> 
> > > Le mercredi 11 juillet 2018 15:49:27 UTC+2, Jochen Kressin a écrit :
> 
> > > > Setting do\_not\_fail\_on\_forbidden to false will give you behavior 1), setting it to true will give you behavior 2).
> 
> > > >
> 
> > >
> 
> > > I had already tried this one, but it doesn’t seem to be effective ?
> 
> > >
> 
> > 
> 
> > Searching further in the code : is this setting even used for something other than the \_searchguard/kibana info page ?
> 
> > 
> 
> > BCS-NBK-AGU [footy] ~/Projects/search-guard % grep -r forbidden .
> 
> > ./sgconfig/sg\_config.yml: #do\_not\_fail\_on\_forbidden: false
> 
> > ./src/main/java/com/floragunn/searchguard/configuration/PrivilegesEvaluator.java: && getConfigSettings().getAsBoolean(“searchguard.dynamic.kibana.do\_not\_fail\_on\_forbidden”, false);
> 
> > ./src/main/java/com/floragunn/searchguard/tools/SearchGuardAdmin.java: System.out.println(" a configuration error and is therefore forbidden now.");
> 
> > ./src/main/java/com/floragunn/searchguard/rest/KibanaInfoAction.java: builder.field(“not\_fail\_on\_forbidden\_enabled”, evaluator.notFailOnForbiddenEnabled());
> 
> > 
> 
> > !130! BCS-NBK-AGU [footy] ~/Projects/search-guard % grep -r notFailOnForbidden .
> 
> > ./src/main/java/com/floragunn/searchguard/configuration/PrivilegesEvaluator.java: public boolean notFailOnForbiddenEnabled() {
> 
> > ./src/main/java/com/floragunn/searchguard/rest/KibanaInfoAction.java: builder.field(“not\_fail\_on\_forbidden\_enabled”, evaluator.notFailOnForbiddenEnabled());
> 
> > 
> 
> > Thanks,
> 
> > 
> 
> > Best regards,
> 
> > Aurélien

---

<div class="post-metadata">

**Author:** ![Aurelien\_GUILLAUME](https://avatars.discourse-cdn.com/v4/letter/a/dbc845/32.png) [@Aurelien\_GUILLAUME](https://forum.search-guard.com/u/Aurelien_GUILLAUME)\
**Post date:** [July 20, 2018, 1:46pm UTC](https://forum.search-guard.com/t/query-logs-with-rights-only-on-logs-user1/1007/6 "2018-07-20T13:46:20Z")

</div>

Hello,

In fact I thought this was an enterprise feature, and I enabled the Trial licence to check that. I also did try the compliance edition:

[2018-07-20T15:36:44,978][INFO][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Info: SearchGuardLicense [uid=00000000-0000-0000-0000-000000000000, type=TRIAL, features=[COMPLIANCE], issueDate=2018-07-03, expiryDate=2018-09-02, issuedTo=The world, issuer=floragunn GmbH, startDate=2018-07-03, majorVersion=6, clusterName=\*, allowedNodeCount=2147483647, msgs=, expiresInDays=43, isExpired=false, valid=true, action=, prodUsage=Yes, one cluster with all commercial features and unlimited nodes per cluster., clusterService=org.elasticsearch.cluster.service.ClusterService@176bcbb5, getMsgs()=, getExpiresInDays()=43, isExpired()=false, isValid()=true, getAction()=, getProdUsage()=Yes, one cluster with all commercial features and unlimited nodes per cluster.]

But there is no change in the outputs.

Using com.floragunn:search-guard-6:6.3.1-compliance-2 right now; with the same errors.

Privilege lookup log is the following:

[2018-07-20T15:42:12,298][INFO][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=user1, roles=[customer], requestedTenant=null] Resolved [aliases=, indices=[access\_log-2018.06.18, access\_log-2018.06.19, access\_log-global-2018.07.19, access\_log-user2-2018.07.20, access\_log-global-2018.07.17, access\_log-global-2018.07.18, access\_log-global-2018.07.15, access\_log-global-2018.07.16, access\_log-global-2018.07.13, access\_log-global-2018.07.14, access\_log-global-2018.07.11, access\_log-global-2018.07.12, access\_log-global-2018.07.10, access\_log-user1-2018.07.15, access\_log-user1-2018.07.16, access\_log-user1-2018.07.17, access\_log-user1-2018.07.18, access\_log-user1-2018.07.11, access\_log-user1-2018.07.12, access\_log-user1-2018.07.13, access\_log-user1-2018.07.14, access\_log-user1-2018.07.19, access\_log-global-2018.07.08, access\_log-global-2018.07.09, access\_log-global-2018.07.06, access\_log-test-2018.07.02, access\_log-user2-2018.07.10, access\_log-global-2018.07.07, access\_log-user2-2018.07.11, access\_log-global-2018.07.05, access\_log-user2-2018.07.12, access\_log-user2-2018.07.13, access\_log-global-2018.07.02, access\_log-test-2018.07.06, access\_log-user2-2018.07.14, access\_log-global-2018.07.03, access\_log-test-2018.07.05, access\_log-user1-2018.07.20, access\_log-user2-2018.07.15, access\_log-user2-2018.07.16, access\_log-test-2018.07.03, access\_log-user2-2018.07.17, access\_log-user2-2018.07.18, access\_log-test-2018.07.09, access\_log-user2-2018.07.19, access\_log-test-2018.07.08, access\_log-test-2018.07.07, access\_log-user1-2018.07.05, access\_log-user1-2018.07.06, access\_log-user1-2018.07.07, access\_log-user1-2018.07.02, access\_log-user1-2018.07.03, access\_log-2018.07.02, access\_log-user1-2018.07.08, access\_log-2018.06.30, access\_log-user1-2018.07.09, access\_log-2018.07.01, access\_log-test-2018.07.13, access\_log-test-2018.07.12, access\_log-test-2018.07.11, access\_log-test-2018.07.10, access\_log-test-2018.07.17, access\_log-user2-2018.07.02, access\_log-test-2018.07.16, access\_log-user2-2018.07.03, access\_log-test-2018.07.15, access\_log-user2-2018.07.05, access\_log-test-2018.07.14, access\_log-user1-2018.07.10, access\_log-user2-2018.07.06, access\_log-user2-2018.07.07, access\_log-test-2018.07.19, access\_log-user2-2018.07.08, access\_log-test-2018.07.18, access\_log-user2-2018.07.09, access\_log-2018.06.27, access\_log-2018.06.28, access\_log-2018.06.29, access\_log-2018.06.23, access\_log-2018.06.24, access\_log-2018.06.25, access\_log-2018.06.26, access\_log-2018.06.20, access\_log-2018.06.21, access\_log-2018.06.22, access\_log-test-2018.07.20, access\_log-global-2018.07.20], allIndices=[access\_log-2018.06.18, access\_log-2018.06.19, access\_log-global-2018.07.19, access\_log-user2-2018.07.20, access\_log-global-2018.07.17, access\_log-global-2018.07.18, access\_log-global-2018.07.15, access\_log-global-2018.07.16, access\_log-global-2018.07.13, access\_log-global-2018.07.14, access\_log-global-2018.07.11, access\_log-global-2018.07.12, access\_log-global-2018.07.10, access\_log-user1-2018.07.15, access\_log-user1-2018.07.16, access\_log-user1-2018.07.17, access\_log-user1-2018.07.18, access\_log-user1-2018.07.11, access\_log-user1-2018.07.12, access\_log-user1-2018.07.13, access\_log-user1-2018.07.14, access\_log-user1-2018.07.19, access\_log-global-2018.07.08, access\_log-global-2018.07.09, access\_log-global-2018.07.06, access\_log-test-2018.07.02, access\_log-user2-2018.07.10, access\_log-global-2018.07.07, access\_log-user2-2018.07.11, access\_log-global-2018.07.05, access\_log-user2-2018.07.12, access\_log-user2-2018.07.13, access\_log-global-2018.07.02, access\_log-test-2018.07.06, access\_log-user2-2018.07.14, access\_log-global-2018.07.03, access\_log-test-2018.07.05, access\_log-user1-2018.07.20, access\_log-user2-2018.07.15, access\_log-user2-2018.07.16, access\_log-test-2018.07.03, access\_log-user2-2018.07.17, access\_log-user2-2018.07.18, access\_log-test-2018.07.09, access\_log-user2-2018.07.19, access\_log-test-2018.07.08, access\_log-test-2018.07.07, access\_log-user1-2018.07.05, access\_log-user1-2018.07.06, access\_log-user1-2018.07.07, access\_log-user1-2018.07.02, access\_log-user1-2018.07.03, access\_log-2018.07.02, access\_log-user1-2018.07.08, access\_log-2018.06.30, access\_log-user1-2018.07.09, access\_log-2018.07.01, access\_log-test-2018.07.13, access\_log-test-2018.07.12, access\_log-test-2018.07.11, access\_log-test-2018.07.10, access\_log-test-2018.07.17, access\_log-user2-2018.07.02, access\_log-test-2018.07.16, access\_log-user2-2018.07.03, access\_log-test-2018.07.15, access\_log-user2-2018.07.05, access\_log-test-2018.07.14, access\_log-user1-2018.07.10, access\_log-user2-2018.07.06, access\_log-user2-2018.07.07, access\_log-test-2018.07.19, access\_log-user2-2018.07.08, access\_log-test-2018.07.18, access\_log-user2-2018.07.09, access\_log-2018.06.27, access\_log-2018.06.28, access\_log-2018.06.29, access\_log-2018.06.23, access\_log-2018.06.24, access\_log-2018.06.25, access\_log-2018.06.26, access\_log-2018.06.20, access\_log-2018.06.21, access\_log-2018.06.22, access\_log-test-2018.07.20, access\_log-global-2018.07.20], types=[\*], isAll()=false, isEmpty()=false] [Action [indices:monitor/stats]] [RolesChecked [sg\_own\_index, sg\_customer]]

[2018-07-20T15:42:12,300][INFO][c.f.s.c.PrivilegesEvaluator] No permissions for [indices:monitor/stats]

> **···**
>
> > On 18 Jul 2018, at 19:03, Jochen Kressin [jkressin@floragunn.com](mailto:jkressin@floragunn.com) wrote:
> 
> > I think we now have a guess regarding this issue: Am I right in the assumption that you are using the Community Edition? If this is the case, please try the 6.3.1-compliance-2 SG plugin.
> 
> > Background: The feature I mentioned was once an Enterprise feature, but we made it a Community feature. This has been implemented in the SG Compliance codebase. We are in the process of merging the codebases, but for now it is only available in the compliance builds.
> 
> > 
> 
> > You can use these builds and disable all enterprise features as you probably did with the 22.3 version.
> > 
> > On Friday, July 13, 2018 at 4:20:20 PM UTC+2, Aurélien GUILLAUME wrote:
> > 
> > > Hello,
> 
> > > > On 11 Jul 2018, at 17:40, [footplus@gmail.com](mailto:footplus@gmail.com) wrote:
> 
> > > > Hello,
> 
> > > >
> 
> > > > Thanks for your quick response.
> 
> > > >
> 
> > > > Le mercredi 11 juillet 2018 15:49:27 UTC+2, Jochen Kressin a écrit :
> 
> > > > > Setting do\_not\_fail\_on\_forbidden to false will give you behavior 1), setting it to true will give you behavior 2).
> 
> > > > >
> 
> > > >
> 
> > > > I had already tried this one, but it doesn’t seem to be effective ?
> 
> > > >
> 
> > >
> 
> > > Searching further in the code : is this setting even used for something other than the \_searchguard/kibana info page ?
> 
> > >
> 
> > > BCS-NBK-AGU [footy] ~/Projects/search-guard % grep -r forbidden .
> 
> > > ./sgconfig/sg\_config.yml: #do\_not\_fail\_on\_forbidden: false
> 
> > > ./src/main/java/com/floragunn/searchguard/configuration/PrivilegesEvaluator.java: && getConfigSettings().getAsBoolean(“searchguard.dynamic.kibana.do\_not\_fail\_on\_forbidden”, false);
> 
> > > ./src/main/java/com/floragunn/searchguard/tools/SearchGuardAdmin.java: System.out.println(" a configuration error and is therefore forbidden now.");
> 
> > > ./src/main/java/com/floragunn/searchguard/rest/KibanaInfoAction.java: builder.field(“not\_fail\_on\_forbidden\_enabled”, evaluator.notFailOnForbiddenEnabled());
> 
> > >
> 
> > > !130! BCS-NBK-AGU [footy] ~/Projects/search-guard % grep -r notFailOnForbidden .
> 
> > > ./src/main/java/com/floragunn/searchguard/configuration/PrivilegesEvaluator.java: public boolean notFailOnForbiddenEnabled() {
> 
> > > ./src/main/java/com/floragunn/searchguard/rest/KibanaInfoAction.java: builder.field(“not\_fail\_on\_forbidden\_enabled”, evaluator.notFailOnForbiddenEnabled());
> 
> > >
> 
> > > Thanks,
> 
> > >
> 
> > > Best regards,
> 
> > > Aurélien
> 
> > 
> 
> > –
> > 
> > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.
> > 
> > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard+unsubscribe@googlegroups.com](mailto:search-guard+unsubscribe@googlegroups.com).
> > 
> > To post to this group, send email to [search-guard@googlegroups.com](mailto:search-guard@googlegroups.com).
> > 
> > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/8c6f70fe-15a8-4f2f-b4c3-8ba39fe20fcb%40googlegroups.com](https://groups.google.com/d/msgid/search-guard/8c6f70fe-15a8-4f2f-b4c3-8ba39fe20fcb%40googlegroups.com?utm_medium=email&utm_source=footer).
> > 
> > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![Aurelien\_GUILLAUME](https://avatars.discourse-cdn.com/v4/letter/a/dbc845/32.png) [@Aurelien\_GUILLAUME](https://forum.search-guard.com/u/Aurelien_GUILLAUME)\
**Post date:** [July 31, 2018, 9:17am UTC](https://forum.search-guard.com/t/query-logs-with-rights-only-on-logs-user1/1007/7 "2018-07-31T09:17:52Z")

</div>

Hello,

So, is it a bug or did I misunderstood the feature ?

Thanks,

Best regards,

> **···**
>
> –
> 
> Aurélien GUILLAUME
> 
> [footplus@gmail.com](mailto:footplus@gmail.com)
> 
> > On 20 Jul 2018, at 15:46, Aurélien GUILLAUME [footplus@gmail.com](mailto:footplus@gmail.com) wrote:
> 
> > Hello,
> 
> > In fact I thought this was an enterprise feature, and I enabled the Trial licence to check that. I also did try the compliance edition:
> 
> > 
> 
> > [2018-07-20T15:36:44,978][INFO][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Info: SearchGuardLicense [uid=00000000-0000-0000-0000-000000000000, type=TRIAL, features=[COMPLIANCE], issueDate=2018-07-03, expiryDate=2018-09-02, issuedTo=The world, issuer=floragunn GmbH, startDate=2018-07-03, majorVersion=6, clusterName=\*, allowedNodeCount=2147483647, msgs=, expiresInDays=43, isExpired=false, valid=true, action=, prodUsage=Yes, one cluster with all commercial features and unlimited nodes per cluster., clusterService=org.elasticsearch.cluster.service.ClusterService@176bcbb5, getMsgs()=, getExpiresInDays()=43, isExpired()=false, isValid()=true, getAction()=, getProdUsage()=Yes, one cluster with all commercial features and unlimited nodes per cluster.]
> 
> > 
> 
> > But there is no change in the outputs.
> 
> > 
> 
> > Using com.floragunn:search-guard-6:6.3.1-compliance-2 right now; with the same errors.
> 
> > 
> 
> > Privilege lookup log is the following:
> 
> > 
> 
> > [2018-07-20T15:42:12,298][INFO][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=user1, roles=[customer], requestedTenant=null] Resolved [aliases=, indices=[access\_log-2018.06.18, access\_log-2018.06.19, access\_log-global-2018.07.19, access\_log-user2-2018.07.20, access\_log-global-2018.07.17, access\_log-global-2018.07.18, access\_log-global-2018.07.15, access\_log-global-2018.07.16, access\_log-global-2018.07.13, access\_log-global-2018.07.14, access\_log-global-2018.07.11, access\_log-global-2018.07.12, access\_log-global-2018.07.10, access\_log-user1-2018.07.15, access\_log-user1-2018.07.16, access\_log-user1-2018.07.17, access\_log-user1-2018.07.18, access\_log-user1-2018.07.11, access\_log-user1-2018.07.12, access\_log-user1-2018.07.13, access\_log-user1-2018.07.14, access\_log-user1-2018.07.19, access\_log-global-2018.07.08, access\_log-global-2018.07.09, access\_log-global-2018.07.06, access\_log-test-2018.07.02, access\_log-user2-2018.07.10, access\_log-global-2018.07.07, access\_log-user2-2018.07.11, access\_log-global-2018.07.05, access\_log-user2-2018.07.12, access\_log-user2-2018.07.13, access\_log-global-2018.07.02, access\_log-test-2018.07.06, access\_log-user2-2018.07.14, access\_log-global-2018.07.03, access\_log-test-2018.07.05, access\_log-user1-2018.07.20, access\_log-user2-2018.07.15, access\_log-user2-2018.07.16, access\_log-test-2018.07.03, access\_log-user2-2018.07.17, access\_log-user2-2018.07.18, access\_log-test-2018.07.09, access\_log-user2-2018.07.19, access\_log-test-2018.07.08, access\_log-test-2018.07.07, access\_log-user1-2018.07.05, access\_log-user1-2018.07.06, access\_log-user1-2018.07.07, access\_log-user1-2018.07.02, access\_log-user1-2018.07.03, access\_log-2018.07.02, access\_log-user1-2018.07.08, access\_log-2018.06.30, access\_log-user1-2018.07.09, access\_log-2018.07.01, access\_log-test-2018.07.13, access\_log-test-2018.07.12, access\_log-test-2018.07.11, access\_log-test-2018.07.10, access\_log-test-2018.07.17, access\_log-user2-2018.07.02, access\_log-test-2018.07.16, access\_log-user2-2018.07.03, access\_log-test-2018.07.15, access\_log-user2-2018.07.05, access\_log-test-2018.07.14, access\_log-user1-2018.07.10, access\_log-user2-2018.07.06, access\_log-user2-2018.07.07, access\_log-test-2018.07.19, access\_log-user2-2018.07.08, access\_log-test-2018.07.18, access\_log-user2-2018.07.09, access\_log-2018.06.27, access\_log-2018.06.28, access\_log-2018.06.29, access\_log-2018.06.23, access\_log-2018.06.24, access\_log-2018.06.25, access\_log-2018.06.26, access\_log-2018.06.20, access\_log-2018.06.21, access\_log-2018.06.22, access\_log-test-2018.07.20, access\_log-global-2018.07.20], allIndices=[access\_log-2018.06.18, access\_log-2018.06.19, access\_log-global-2018.07.19, access\_log-user2-2018.07.20, access\_log-global-2018.07.17, access\_log-global-2018.07.18, access\_log-global-2018.07.15, access\_log-global-2018.07.16, access\_log-global-2018.07.13, access\_log-global-2018.07.14, access\_log-global-2018.07.11, access\_log-global-2018.07.12, access\_log-global-2018.07.10, access\_log-user1-2018.07.15, access\_log-user1-2018.07.16, access\_log-user1-2018.07.17, access\_log-user1-2018.07.18, access\_log-user1-2018.07.11, access\_log-user1-2018.07.12, access\_log-user1-2018.07.13, access\_log-user1-2018.07.14, access\_log-user1-2018.07.19, access\_log-global-2018.07.08, access\_log-global-2018.07.09, access\_log-global-2018.07.06, access\_log-test-2018.07.02, access\_log-user2-2018.07.10, access\_log-global-2018.07.07, access\_log-user2-2018.07.11, access\_log-global-2018.07.05, access\_log-user2-2018.07.12, access\_log-user2-2018.07.13, access\_log-global-2018.07.02, access\_log-test-2018.07.06, access\_log-user2-2018.07.14, access\_log-global-2018.07.03, access\_log-test-2018.07.05, access\_log-user1-2018.07.20, access\_log-user2-2018.07.15, access\_log-user2-2018.07.16, access\_log-test-2018.07.03, access\_log-user2-2018.07.17, access\_log-user2-2018.07.18, access\_log-test-2018.07.09, access\_log-user2-2018.07.19, access\_log-test-2018.07.08, access\_log-test-2018.07.07, access\_log-user1-2018.07.05, access\_log-user1-2018.07.06, access\_log-user1-2018.07.07, access\_log-user1-2018.07.02, access\_log-user1-2018.07.03, access\_log-2018.07.02, access\_log-user1-2018.07.08, access\_log-2018.06.30, access\_log-user1-2018.07.09, access\_log-2018.07.01, access\_log-test-2018.07.13, access\_log-test-2018.07.12, access\_log-test-2018.07.11, access\_log-test-2018.07.10, access\_log-test-2018.07.17, access\_log-user2-2018.07.02, access\_log-test-2018.07.16, access\_log-user2-2018.07.03, access\_log-test-2018.07.15, access\_log-user2-2018.07.05, access\_log-test-2018.07.14, access\_log-user1-2018.07.10, access\_log-user2-2018.07.06, access\_log-user2-2018.07.07, access\_log-test-2018.07.19, access\_log-user2-2018.07.08, access\_log-test-2018.07.18, access\_log-user2-2018.07.09, access\_log-2018.06.27, access\_log-2018.06.28, access\_log-2018.06.29, access\_log-2018.06.23, access\_log-2018.06.24, access\_log-2018.06.25, access\_log-2018.06.26, access\_log-2018.06.20, access\_log-2018.06.21, access\_log-2018.06.22, access\_log-test-2018.07.20, access\_log-global-2018.07.20], types=[\*], isAll()=false, isEmpty()=false] [Action [indices:monitor/stats]] [RolesChecked [sg\_own\_index, sg\_customer]]
> 
> > [2018-07-20T15:42:12,300][INFO][c.f.s.c.PrivilegesEvaluator] No permissions for [indices:monitor/stats]
> 
> > > On 18 Jul 2018, at 19:03, Jochen Kressin [jkressin@floragunn.com](mailto:jkressin@floragunn.com) wrote:
> 
> > > I think we now have a guess regarding this issue: Am I right in the assumption that you are using the Community Edition? If this is the case, please try the 6.3.1-compliance-2 SG plugin.
> 
> > > Background: The feature I mentioned was once an Enterprise feature, but we made it a Community feature. This has been implemented in the SG Compliance codebase. We are in the process of merging the codebases, but for now it is only available in the compliance builds.
> 
> > >
> 
> > > You can use these builds and disable all enterprise features as you probably did with the 22.3 version.
> > > 
> > > On Friday, July 13, 2018 at 4:20:20 PM UTC+2, Aurélien GUILLAUME wrote:
> > > 
> > > > Hello,
> 
> > > > > On 11 Jul 2018, at 17:40, [footplus@gmail.com](mailto:footplus@gmail.com) wrote:
> 
> > > > > Hello,
> 
> > > > >
> 
> > > > > Thanks for your quick response.
> 
> > > > >
> 
> > > > > Le mercredi 11 juillet 2018 15:49:27 UTC+2, Jochen Kressin a écrit :
> 
> > > > > > Setting do\_not\_fail\_on\_forbidden to false will give you behavior 1), setting it to true will give you behavior 2).
> 
> > > > > >
> 
> > > > >
> 
> > > > > I had already tried this one, but it doesn’t seem to be effective ?
> 
> > > > >
> 
> > > >
> 
> > > > Searching further in the code : is this setting even used for something other than the \_searchguard/kibana info page ?
> 
> > > >
> 
> > > > BCS-NBK-AGU [footy] ~/Projects/search-guard % grep -r forbidden .
> 
> > > > ./sgconfig/sg\_config.yml: #do\_not\_fail\_on\_forbidden: false
> 
> > > > ./src/main/java/com/floragunn/searchguard/configuration/PrivilegesEvaluator.java: && getConfigSettings().getAsBoolean(“searchguard.dynamic.kibana.do\_not\_fail\_on\_forbidden”, false);
> 
> > > > ./src/main/java/com/floragunn/searchguard/tools/SearchGuardAdmin.java: System.out.println(" a configuration error and is therefore forbidden now.");
> 
> > > > ./src/main/java/com/floragunn/searchguard/rest/KibanaInfoAction.java: builder.field(“not\_fail\_on\_forbidden\_enabled”, evaluator.notFailOnForbiddenEnabled());
> 
> > > >
> 
> > > > !130! BCS-NBK-AGU [footy] ~/Projects/search-guard % grep -r notFailOnForbidden .
> 
> > > > ./src/main/java/com/floragunn/searchguard/configuration/PrivilegesEvaluator.java: public boolean notFailOnForbiddenEnabled() {
> 
> > > > ./src/main/java/com/floragunn/searchguard/rest/KibanaInfoAction.java: builder.field(“not\_fail\_on\_forbidden\_enabled”, evaluator.notFailOnForbiddenEnabled());
> 
> > > >
> 
> > > > Thanks,
> 
> > > >
> 
> > > > Best regards,
> 
> > > > Aurélien
> 
> > >
> 
> > > –
> > > 
> > > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.
> > > 
> > > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard+unsubscribe@googlegroups.com](mailto:search-guard+unsubscribe@googlegroups.com).
> > > 
> > > To post to this group, send email to [search-guard@googlegroups.com](mailto:search-guard@googlegroups.com).
> > > 
> > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/8c6f70fe-15a8-4f2f-b4c3-8ba39fe20fcb%40googlegroups.com](https://groups.google.com/d/msgid/search-guard/8c6f70fe-15a8-4f2f-b4c3-8ba39fe20fcb%40googlegroups.com?utm_medium=email&utm_source=footer).
> > > 
> > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> 
> >

---

<div class="post-metadata">

**Author:** ![jkressin](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/jkressin/32/9_2.png) [@jkressin](https://forum.search-guard.com/u/jkressin)\
**Post date:** [July 31, 2018, 5:35pm UTC](https://forum.search-guard.com/t/query-logs-with-rights-only-on-logs-user1/1007/8 "2018-07-31T17:35:20Z")

</div>

I don’t think it is a bug. I have now tried to replicate the problem and I think somehow the “do not fail on forbidden” feature is not active. Here’s what I did:

I set up three sample indices with one document each:

```auto
yellow open logs-user3-2018.1 QwzklrtbTUGrA5QLtS-fIw 5 1 1 0 4.5kb 4.5kb
yellow open logs-user2-2018.1 4qx9VaNgSyaXr76PKSA5DA 5 1 1 0 4.5kb 4.5kb
yellow open logs-user1-2018.1 -Vj1d4cMRzyU-KhJEcuFTw 5 1 1 0 4.5kb 4.5kb

```

``

I created a user “user1” with the following role:

sg\_user1:

cluster:

- UNLIMITED

indices:

‘logs-user1-\*’:

‘\*’:

- INDICES\_ALL

``

And enable dnfof with:

searchguard:

dynamic:

```
kibana:

  do_not_fail_on_forbidden: true

```

``

When I query

https://:9200/logs-\*/\_search

``

I get data from the index:

```auto
logs-user1-2018.1

```

``

without an error. Tested with the compliance edition.

Can you check whether the dnfof feature is really active by pulling your current configuration from the cluster and posting the sg\_config.yml here? You can use sgadmin and the -r/–retrieve switch which will pull the active configuration from the cluster and place them in the current directory.

> **···**
>
> On Tuesday, July 31, 2018 at 11:17:56 AM UTC+2, Aurélien GUILLAUME wrote:
> 
> > Hello,
> 
> > So, is it a bug or did I misunderstood the feature ?
> 
> > 
> 
> > Thanks,
> 
> > ## Best regards,
> 
> > Aurélien GUILLAUME
> 
> > [footplus@gmail.com](mailto:footplus@gmail.com)
> 
> > 
> 
> > 
> 
> > > On 20 Jul 2018, at 15:46, Aurélien GUILLAUME [footplus@gmail.com](mailto:footplus@gmail.com) wrote:
> 
> > > Hello,
> 
> > > In fact I thought this was an enterprise feature, and I enabled the Trial licence to check that. I also did try the compliance edition:
> 
> > >
> 
> > > [2018-07-20T15:36:44,978][INFO][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Info: SearchGuardLicense [uid=00000000-0000-0000-0000-000000000000, type=TRIAL, features=[COMPLIANCE], issueDate=2018-07-03, expiryDate=2018-09-02, issuedTo=The world, issuer=floragunn GmbH, startDate=2018-07-03, majorVersion=6, clusterName=\*, allowedNodeCount=2147483647, msgs=, expiresInDays=43, isExpired=false, valid=true, action=, prodUsage=Yes, one cluster with all commercial features and unlimited nodes per cluster., clusterService=org.elasticsearch.cluster.service.ClusterService@176bcbb5, getMsgs()=, getExpiresInDays()=43, isExpired()=false, isValid()=true, getAction()=, getProdUsage()=Yes, one cluster with all commercial features and unlimited nodes per cluster.]
> 
> > >
> 
> > > But there is no change in the outputs.
> 
> > >
> 
> > > Using com.floragunn:search-guard-6:6.3.1-compliance-2 right now; with the same errors.
> 
> > >
> 
> > > Privilege lookup log is the following:
> 
> > >
> 
> > > [2018-07-20T15:42:12,298][INFO][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=user1, roles=[customer], requestedTenant=null] Resolved [aliases=, indices=[access\_log-2018.06.18, access\_log-2018.06.19, access\_log-global-2018.07.19, access\_log-user2-2018.07.20, access\_log-global-2018.07.17, access\_log-global-2018.07.18, access\_log-global-2018.07.15, access\_log-global-2018.07.16, access\_log-global-2018.07.13, access\_log-global-2018.07.14, access\_log-global-2018.07.11, access\_log-global-2018.07.12, access\_log-global-2018.07.10, access\_log-user1-2018.07.15, access\_log-user1-2018.07.16, access\_log-user1-2018.07.17, access\_log-user1-2018.07.18, access\_log-user1-2018.07.11, access\_log-user1-2018.07.12, access\_log-user1-2018.07.13, access\_log-user1-2018.07.14, access\_log-user1-2018.07.19, access\_log-global-2018.07.08, access\_log-global-2018.07.09, access\_log-global-2018.07.06, access\_log-test-2018.07.02, access\_log-user2-2018.07.10, access\_log-global-2018.07.07, access\_log-user2-2018.07.11, access\_log-global-2018.07.05, access\_log-user2-2018.07.12, access\_log-user2-2018.07.13, access\_log-global-2018.07.02, access\_log-test-2018.07.06, access\_log-user2-2018.07.14, access\_log-global-2018.07.03, access\_log-test-2018.07.05, access\_log-user1-2018.07.20, access\_log-user2-2018.07.15, access\_log-user2-2018.07.16, access\_log-test-2018.07.03, access\_log-user2-2018.07.17, access\_log-user2-2018.07.18, access\_log-test-2018.07.09, access\_log-user2-2018.07.19, access\_log-test-2018.07.08, access\_log-test-2018.07.07, access\_log-user1-2018.07.05, access\_log-user1-2018.07.06, access\_log-user1-2018.07.07, access\_log-user1-2018.07.02, access\_log-user1-2018.07.03, access\_log-2018.07.02, access\_log-user1-2018.07.08, access\_log-2018.06.30, access\_log-user1-2018.07.09, access\_log-2018.07.01, access\_log-test-2018.07.13, access\_log-test-2018.07.12, access\_log-test-2018.07.11, access\_log-test-2018.07.10, access\_log-test-2018.07.17, access\_log-user2-2018.07.02, access\_log-test-2018.07.16, access\_log-user2-2018.07.03, access\_log-test-2018.07.15, access\_log-user2-2018.07.05, access\_log-test-2018.07.14, access\_log-user1-2018.07.10, access\_log-user2-2018.07.06, access\_log-user2-2018.07.07, access\_log-test-2018.07.19, access\_log-user2-2018.07.08, access\_log-test-2018.07.18, access\_log-user2-2018.07.09, access\_log-2018.06.27, access\_log-2018.06.28, access\_log-2018.06.29, access\_log-2018.06.23, access\_log-2018.06.24, access\_log-2018.06.25, access\_log-2018.06.26, access\_log-2018.06.20, access\_log-2018.06.21, access\_log-2018.06.22, access\_log-test-2018.07.20, access\_log-global-2018.07.20], allIndices=[access\_log-2018.06.18, access\_log-2018.06.19, access\_log-global-2018.07.19, access\_log-user2-2018.07.20, access\_log-global-2018.07.17, access\_log-global-2018.07.18, access\_log-global-2018.07.15, access\_log-global-2018.07.16, access\_log-global-2018.07.13, access\_log-global-2018.07.14, access\_log-global-2018.07.11, access\_log-global-2018.07.12, access\_log-global-2018.07.10, access\_log-user1-2018.07.15, access\_log-user1-2018.07.16, access\_log-user1-2018.07.17, access\_log-user1-2018.07.18, access\_log-user1-2018.07.11, access\_log-user1-2018.07.12, access\_log-user1-2018.07.13, access\_log-user1-2018.07.14, access\_log-user1-2018.07.19, access\_log-global-2018.07.08, access\_log-global-2018.07.09, access\_log-global-2018.07.06, access\_log-test-2018.07.02, access\_log-user2-2018.07.10, access\_log-global-2018.07.07, access\_log-user2-2018.07.11, access\_log-global-2018.07.05, access\_log-user2-2018.07.12, access\_log-user2-2018.07.13, access\_log-global-2018.07.02, access\_log-test-2018.07.06, access\_log-user2-2018.07.14, access\_log-global-2018.07.03, access\_log-test-2018.07.05, access\_log-user1-2018.07.20, access\_log-user2-2018.07.15, access\_log-user2-2018.07.16, access\_log-test-2018.07.03, access\_log-user2-2018.07.17, access\_log-user2-2018.07.18, access\_log-test-2018.07.09, access\_log-user2-2018.07.19, access\_log-test-2018.07.08, access\_log-test-2018.07.07, access\_log-user1-2018.07.05, access\_log-user1-2018.07.06, access\_log-user1-2018.07.07, access\_log-user1-2018.07.02, access\_log-user1-2018.07.03, access\_log-2018.07.02, access\_log-user1-2018.07.08, access\_log-2018.06.30, access\_log-user1-2018.07.09, access\_log-2018.07.01, access\_log-test-2018.07.13, access\_log-test-2018.07.12, access\_log-test-2018.07.11, access\_log-test-2018.07.10, access\_log-test-2018.07.17, access\_log-user2-2018.07.02, access\_log-test-2018.07.16, access\_log-user2-2018.07.03, access\_log-test-2018.07.15, access\_log-user2-2018.07.05, access\_log-test-2018.07.14, access\_log-user1-2018.07.10, access\_log-user2-2018.07.06, access\_log-user2-2018.07.07, access\_log-test-2018.07.19, access\_log-user2-2018.07.08, access\_log-test-2018.07.18, access\_log-user2-2018.07.09, access\_log-2018.06.27, access\_log-2018.06.28, access\_log-2018.06.29, access\_log-2018.06.23, access\_log-2018.06.24, access\_log-2018.06.25, access\_log-2018.06.26, access\_log-2018.06.20, access\_log-2018.06.21, access\_log-2018.06.22, access\_log-test-2018.07.20, access\_log-global-2018.07.20], types=[\*], isAll()=false, isEmpty()=false] [Action [indices:monitor/stats]] [RolesChecked [sg\_own\_index, sg\_customer]]
> 
> > > [2018-07-20T15:42:12,300][INFO][c.f.s.c.PrivilegesEvaluator] No permissions for [indices:monitor/stats]
> 
> > > > On 18 Jul 2018, at 19:03, Jochen Kressin [jkressin@floragunn.com](mailto:jkressin@floragunn.com) wrote:
> 
> > > > I think we now have a guess regarding this issue: Am I right in the assumption that you are using the Community Edition? If this is the case, please try the 6.3.1-compliance-2 SG plugin.
> 
> > > > Background: The feature I mentioned was once an Enterprise feature, but we made it a Community feature. This has been implemented in the SG Compliance codebase. We are in the process of merging the codebases, but for now it is only available in the compliance builds.
> 
> > > >
> 
> > > > You can use these builds and disable all enterprise features as you probably did with the 22.3 version.
> > > > 
> > > > On Friday, July 13, 2018 at 4:20:20 PM UTC+2, Aurélien GUILLAUME wrote:
> > > > 
> > > > > Hello,
> 
> > > > > > On 11 Jul 2018, at 17:40, [footplus@gmail.com](mailto:footplus@gmail.com) wrote:
> 
> > > > > > Hello,
> 
> > > > > >
> 
> > > > > > Thanks for your quick response.
> 
> > > > > >
> 
> > > > > > Le mercredi 11 juillet 2018 15:49:27 UTC+2, Jochen Kressin a écrit :
> 
> > > > > > > Setting do\_not\_fail\_on\_forbidden to false will give you behavior 1), setting it to true will give you behavior 2).
> 
> > > > > > >
> 
> > > > > >
> 
> > > > > > I had already tried this one, but it doesn’t seem to be effective ?
> 
> > > > > >
> 
> > > > >
> 
> > > > > Searching further in the code : is this setting even used for something other than the \_searchguard/kibana info page ?
> 
> > > > >
> 
> > > > > BCS-NBK-AGU [footy] ~/Projects/search-guard % grep -r forbidden .
> 
> > > > > ./sgconfig/sg\_config.yml: #do\_not\_fail\_on\_forbidden: false
> 
> > > > > ./src/main/java/com/floragunn/searchguard/configuration/PrivilegesEvaluator.java: && getConfigSettings().getAsBoolean(“searchguard.dynamic.kibana.do\_not\_fail\_on\_forbidden”, false);
> 
> > > > > ./src/main/java/com/floragunn/searchguard/tools/SearchGuardAdmin.java: System.out.println(" a configuration error and is therefore forbidden now.");
> 
> > > > > ./src/main/java/com/floragunn/searchguard/rest/KibanaInfoAction.java: builder.field(“not\_fail\_on\_forbidden\_enabled”, evaluator.notFailOnForbiddenEnabled());
> 
> > > > >
> 
> > > > > !130! BCS-NBK-AGU [footy] ~/Projects/search-guard % grep -r notFailOnForbidden .
> 
> > > > > ./src/main/java/com/floragunn/searchguard/configuration/PrivilegesEvaluator.java: public boolean notFailOnForbiddenEnabled() {
> 
> > > > > ./src/main/java/com/floragunn/searchguard/rest/KibanaInfoAction.java: builder.field(“not\_fail\_on\_forbidden\_enabled”, evaluator.notFailOnForbiddenEnabled());
> 
> > > > >
> 
> > > > > Thanks,
> 
> > > > >
> 
> > > > > Best regards,
> 
> > > > > Aurélien
> 
> > > >
> 
> > > > –
> > > > 
> > > > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.
> > > > 
> > > > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard+unsubscribe@googlegroups.com](mailto:search-guard+unsubscribe@googlegroups.com).
> > > > 
> > > > To post to this group, send email to [search-guard@googlegroups.com](mailto:search-guard@googlegroups.com).
> > > > 
> > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/8c6f70fe-15a8-4f2f-b4c3-8ba39fe20fcb%40googlegroups.com](https://groups.google.com/d/msgid/search-guard/8c6f70fe-15a8-4f2f-b4c3-8ba39fe20fcb%40googlegroups.com?utm_medium=email&utm_source=footer).
> > > > 
> > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> 
> > >
> 
> >

---

<div class="post-metadata">

**Author:** ![Aurelien\_GUILLAUME](https://avatars.discourse-cdn.com/v4/letter/a/dbc845/32.png) [@Aurelien\_GUILLAUME](https://forum.search-guard.com/u/Aurelien_GUILLAUME)\
**Post date:** [August 1, 2018, 12:17pm UTC](https://forum.search-guard.com/t/query-logs-with-rights-only-on-logs-user1/1007/9 "2018-08-01T12:17:04Z")

</div>

Hello,

I’m able to replicate this.

But now, when you make a generic dashboard in Kibana for your customers (e.g. a public generic read-only .kibana for your customer - in my case I use ), you need to add logs-\* as a log pattern.

And the inventory of the indexes then fails: please try with the user: /\_cat/indices?v&index=logs-\* (vs /\_cat/indices?v&index=logs-user1-\* which works).

But perhaps this is a known behavior.

Thanks,

Best regards,

> **···**
>
> –
> 
> Aurélien GUILLAUME
> 
> [footplus@gmail.com](mailto:footplus@gmail.com)
> 
> > On 31 Jul 2018, at 19:35, Jochen Kressin [jkressin@floragunn.com](mailto:jkressin@floragunn.com) wrote:
> 
> > I don’t think it is a bug. I have now tried to replicate the problem and I think somehow the “do not fail on forbidden” feature is not active. Here’s what I did:
> 
> > I set up three sample indices with one document each:
> 
> > 
> 
> > ```auto
> > yellow open logs-user3-2018.1 QwzklrtbTUGrA5QLtS-fIw 5 1 1 0 4.5kb 4.5kb
> > yellow open logs-user2-2018.1 4qx9VaNgSyaXr76PKSA5DA 5 1 1 0 4.5kb 4.5kb
> > yellow open logs-user1-2018.1 -Vj1d4cMRzyU-KhJEcuFTw 5 1 1 0 4.5kb 4.5kb
> > 
> > ```
> 
> > ``
> 
> > I created a user “user1” with the following role:
> 
> > 
> 
> > sg\_user1:
> 
> > cluster:
> 
> > - UNLIMITED
> 
> > indices:
> 
> > ‘logs-user1-\*’:
> 
> > ‘\*’:
> 
> > - INDICES\_ALL
> 
> > 
> 
> > ``
> 
> > And enable dnfof with:
> 
> > 
> 
> > searchguard:
> 
> > dynamic:
> 
> > ```
> > kibana:
> > 
> > ```
> 
> > ```
> > do_not_fail_on_forbidden: true
> > 
> > ```
> 
> > ``
> 
> > 
> 
> > When I query
> 
> > https://:9200/logs-\*/\_search
> 
> > ``
> 
> > 
> 
> > I get data from the index:
> 
> > 
> 
> > ```auto
> > logs-user1-2018.1
> > 
> > ```
> 
> > ``
> 
> > without an error. Tested with the compliance edition.
> 
> > 
> 
> > Can you check whether the dnfof feature is really active by pulling your current configuration from the cluster and posting the sg\_config.yml here? You can use sgadmin and the -r/–retrieve switch which will pull the active configuration from the cluster and place them in the current directory.
> 
> > On Tuesday, July 31, 2018 at 11:17:56 AM UTC+2, Aurélien GUILLAUME wrote:
> > 
> > > Hello,
> 
> > > So, is it a bug or did I misunderstood the feature ?
> 
> > >
> 
> > > Thanks,
> 
> > > ## Best regards,
> 
> > > Aurélien GUILLAUME
> 
> > > [footplus@gmail.com](mailto:footplus@gmail.com)
> 
> > >
> 
> > >
> 
> > > > On 20 Jul 2018, at 15:46, Aurélien GUILLAUME [footplus@gmail.com](mailto:footplus@gmail.com) wrote:
> 
> > > > Hello,
> 
> > > > In fact I thought this was an enterprise feature, and I enabled the Trial licence to check that. I also did try the compliance edition:
> 
> > > >
> 
> > > > [2018-07-20T15:36:44,978][INFO][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Info: SearchGuardLicense [uid=00000000-0000-0000-0000-000000000000, type=TRIAL, features=[COMPLIANCE], issueDate=2018-07-03, expiryDate=2018-09-02, issuedTo=The world, issuer=floragunn GmbH, startDate=2018-07-03, majorVersion=6, clusterName=\*, allowedNodeCount=2147483647, msgs=, expiresInDays=43, isExpired=false, valid=true, action=, prodUsage=Yes, one cluster with all commercial features and unlimited nodes per cluster., clusterService=org.elasticsearch.cluster.service.ClusterService@176bcbb5, getMsgs()=, getExpiresInDays()=43, isExpired()=false, isValid()=true, getAction()=, getProdUsage()=Yes, one cluster with all commercial features and unlimited nodes per cluster.]
> 
> > > >
> 
> > > > But there is no change in the outputs.
> 
> > > >
> 
> > > > Using com.floragunn:search-guard-6:6.3.1-compliance-2 right now; with the same errors.
> 
> > > >
> 
> > > > Privilege lookup log is the following:
> 
> > > >
> 
> > > > [2018-07-20T15:42:12,298][INFO][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=user1, roles=[customer], requestedTenant=null] Resolved [aliases=, indices=[access\_log-2018.06.18, access\_log-2018.06.19, access\_log-global-2018.07.19, access\_log-user2-2018.07.20, access\_log-global-2018.07.17, access\_log-global-2018.07.18, access\_log-global-2018.07.15, access\_log-global-2018.07.16, access\_log-global-2018.07.13, access\_log-global-2018.07.14, access\_log-global-2018.07.11, access\_log-global-2018.07.12, access\_log-global-2018.07.10, access\_log-user1-2018.07.15, access\_log-user1-2018.07.16, access\_log-user1-2018.07.17, access\_log-user1-2018.07.18, access\_log-user1-2018.07.11, access\_log-user1-2018.07.12, access\_log-user1-2018.07.13, access\_log-user1-2018.07.14, access\_log-user1-2018.07.19, access\_log-global-2018.07.08, access\_log-global-2018.07.09, access\_log-global-2018.07.06, access\_log-test-2018.07.02, access\_log-user2-2018.07.10, access\_log-global-2018.07.07, access\_log-user2-2018.07.11, access\_log-global-2018.07.05, access\_log-user2-2018.07.12, access\_log-user2-2018.07.13, access\_log-global-2018.07.02, access\_log-test-2018.07.06, access\_log-user2-2018.07.14, access\_log-global-2018.07.03, access\_log-test-2018.07.05, access\_log-user1-2018.07.20, access\_log-user2-2018.07.15, access\_log-user2-2018.07.16, access\_log-test-2018.07.03, access\_log-user2-2018.07.17, access\_log-user2-2018.07.18, access\_log-test-2018.07.09, access\_log-user2-2018.07.19, access\_log-test-2018.07.08, access\_log-test-2018.07.07, access\_log-user1-2018.07.05, access\_log-user1-2018.07.06, access\_log-user1-2018.07.07, access\_log-user1-2018.07.02, access\_log-user1-2018.07.03, access\_log-2018.07.02, access\_log-user1-2018.07.08, access\_log-2018.06.30, access\_log-user1-2018.07.09, access\_log-2018.07.01, access\_log-test-2018.07.13, access\_log-test-2018.07.12, access\_log-test-2018.07.11, access\_log-test-2018.07.10, access\_log-test-2018.07.17, access\_log-user2-2018.07.02, access\_log-test-2018.07.16, access\_log-user2-2018.07.03, access\_log-test-2018.07.15, access\_log-user2-2018.07.05, access\_log-test-2018.07.14, access\_log-user1-2018.07.10, access\_log-user2-2018.07.06, access\_log-user2-2018.07.07, access\_log-test-2018.07.19, access\_log-user2-2018.07.08, access\_log-test-2018.07.18, access\_log-user2-2018.07.09, access\_log-2018.06.27, access\_log-2018.06.28, access\_log-2018.06.29, access\_log-2018.06.23, access\_log-2018.06.24, access\_log-2018.06.25, access\_log-2018.06.26, access\_log-2018.06.20, access\_log-2018.06.21, access\_log-2018.06.22, access\_log-test-2018.07.20, access\_log-global-2018.07.20], allIndices=[access\_log-2018.06.18, access\_log-2018.06.19, access\_log-global-2018.07.19, access\_log-user2-2018.07.20, access\_log-global-2018.07.17, access\_log-global-2018.07.18, access\_log-global-2018.07.15, access\_log-global-2018.07.16, access\_log-global-2018.07.13, access\_log-global-2018.07.14, access\_log-global-2018.07.11, access\_log-global-2018.07.12, access\_log-global-2018.07.10, access\_log-user1-2018.07.15, access\_log-user1-2018.07.16, access\_log-user1-2018.07.17, access\_log-user1-2018.07.18, access\_log-user1-2018.07.11, access\_log-user1-2018.07.12, access\_log-user1-2018.07.13, access\_log-user1-2018.07.14, access\_log-user1-2018.07.19, access\_log-global-2018.07.08, access\_log-global-2018.07.09, access\_log-global-2018.07.06, access\_log-test-2018.07.02, access\_log-user2-2018.07.10, access\_log-global-2018.07.07, access\_log-user2-2018.07.11, access\_log-global-2018.07.05, access\_log-user2-2018.07.12, access\_log-user2-2018.07.13, access\_log-global-2018.07.02, access\_log-test-2018.07.06, access\_log-user2-2018.07.14, access\_log-global-2018.07.03, access\_log-test-2018.07.05, access\_log-user1-2018.07.20, access\_log-user2-2018.07.15, access\_log-user2-2018.07.16, access\_log-test-2018.07.03, access\_log-user2-2018.07.17, access\_log-user2-2018.07.18, access\_log-test-2018.07.09, access\_log-user2-2018.07.19, access\_log-test-2018.07.08, access\_log-test-2018.07.07, access\_log-user1-2018.07.05, access\_log-user1-2018.07.06, access\_log-user1-2018.07.07, access\_log-user1-2018.07.02, access\_log-user1-2018.07.03, access\_log-2018.07.02, access\_log-user1-2018.07.08, access\_log-2018.06.30, access\_log-user1-2018.07.09, access\_log-2018.07.01, access\_log-test-2018.07.13, access\_log-test-2018.07.12, access\_log-test-2018.07.11, access\_log-test-2018.07.10, access\_log-test-2018.07.17, access\_log-user2-2018.07.02, access\_log-test-2018.07.16, access\_log-user2-2018.07.03, access\_log-test-2018.07.15, access\_log-user2-2018.07.05, access\_log-test-2018.07.14, access\_log-user1-2018.07.10, access\_log-user2-2018.07.06, access\_log-user2-2018.07.07, access\_log-test-2018.07.19, access\_log-user2-2018.07.08, access\_log-test-2018.07.18, access\_log-user2-2018.07.09, access\_log-2018.06.27, access\_log-2018.06.28, access\_log-2018.06.29, access\_log-2018.06.23, access\_log-2018.06.24, access\_log-2018.06.25, access\_log-2018.06.26, access\_log-2018.06.20, access\_log-2018.06.21, access\_log-2018.06.22, access\_log-test-2018.07.20, access\_log-global-2018.07.20], types=[\*], isAll()=false, isEmpty()=false] [Action [indices:monitor/stats]] [RolesChecked [sg\_own\_index, sg\_customer]]
> 
> > > > [2018-07-20T15:42:12,300][INFO][c.f.s.c.PrivilegesEvaluator] No permissions for [indices:monitor/stats]
> 
> > > > > On 18 Jul 2018, at 19:03, Jochen Kressin [jkressin@floragunn.com](mailto:jkressin@floragunn.com) wrote:
> 
> > > > > I think we now have a guess regarding this issue: Am I right in the assumption that you are using the Community Edition? If this is the case, please try the 6.3.1-compliance-2 SG plugin.
> 
> > > > > Background: The feature I mentioned was once an Enterprise feature, but we made it a Community feature. This has been implemented in the SG Compliance codebase. We are in the process of merging the codebases, but for now it is only available in the compliance builds.
> 
> > > > >
> 
> > > > > You can use these builds and disable all enterprise features as you probably did with the 22.3 version.
> > > > > 
> > > > > On Friday, July 13, 2018 at 4:20:20 PM UTC+2, Aurélien GUILLAUME wrote:
> > > > > 
> > > > > > Hello,
> 
> > > > > > > On 11 Jul 2018, at 17:40, [footplus@gmail.com](mailto:footplus@gmail.com) wrote:
> 
> > > > > > > Hello,
> 
> > > > > > >
> 
> > > > > > > Thanks for your quick response.
> 
> > > > > > >
> 
> > > > > > > Le mercredi 11 juillet 2018 15:49:27 UTC+2, Jochen Kressin a écrit :
> 
> > > > > > > > Setting do\_not\_fail\_on\_forbidden to false will give you behavior 1), setting it to true will give you behavior 2).
> 
> > > > > > > >
> 
> > > > > > >
> 
> > > > > > > I had already tried this one, but it doesn’t seem to be effective ?
> 
> > > > > > >
> 
> > > > > >
> 
> > > > > > Searching further in the code : is this setting even used for something other than the \_searchguard/kibana info page ?
> 
> > > > > >
> 
> > > > > > BCS-NBK-AGU [footy] ~/Projects/search-guard % grep -r forbidden .
> 
> > > > > > ./sgconfig/sg\_config.yml: #do\_not\_fail\_on\_forbidden: false
> 
> > > > > > ./src/main/java/com/floragunn/searchguard/configuration/PrivilegesEvaluator.java: && getConfigSettings().getAsBoolean(“searchguard.dynamic.kibana.do\_not\_fail\_on\_forbidden”, false);
> 
> > > > > > ./src/main/java/com/floragunn/searchguard/tools/SearchGuardAdmin.java: System.out.println(" a configuration error and is therefore forbidden now.");
> 
> > > > > > ./src/main/java/com/floragunn/searchguard/rest/KibanaInfoAction.java: builder.field(“not\_fail\_on\_forbidden\_enabled”, evaluator.notFailOnForbiddenEnabled());
> 
> > > > > >
> 
> > > > > > !130! BCS-NBK-AGU [footy] ~/Projects/search-guard % grep -r notFailOnForbidden .
> 
> > > > > > ./src/main/java/com/floragunn/searchguard/configuration/PrivilegesEvaluator.java: public boolean notFailOnForbiddenEnabled() {
> 
> > > > > > ./src/main/java/com/floragunn/searchguard/rest/KibanaInfoAction.java: builder.field(“not\_fail\_on\_forbidden\_enabled”, evaluator.notFailOnForbiddenEnabled());
> 
> > > > > >
> 
> > > > > > Thanks,
> 
> > > > > >
> 
> > > > > > Best regards,
> 
> > > > > > Aurélien
> 
> > > > >
> 
> > > > > –
> > > > > 
> > > > > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.
> > > > > 
> > > > > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard+unsubscribe@googlegroups.com](mailto:search-guard+unsubscribe@googlegroups.com).
> > > > > 
> > > > > To post to this group, send email to [search-guard@googlegroups.com](mailto:search-guard@googlegroups.com).
> > > > > 
> > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/8c6f70fe-15a8-4f2f-b4c3-8ba39fe20fcb%40googlegroups.com](https://groups.google.com/d/msgid/search-guard/8c6f70fe-15a8-4f2f-b4c3-8ba39fe20fcb%40googlegroups.com?utm_medium=email&utm_source=footer).
> > > > > 
> > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> 
> > > >
> 
> > >
> 
> > 
> 
> > –
> > 
> > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.
> > 
> > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard+unsubscribe@googlegroups.com](mailto:search-guard+unsubscribe@googlegroups.com).
> > 
> > To post to this group, send email to [search-guard@googlegroups.com](mailto:search-guard@googlegroups.com).
> > 
> > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/1434cc0c-2709-4ba4-9f14-a670a9ccd6c0%40googlegroups.com](https://groups.google.com/d/msgid/search-guard/1434cc0c-2709-4ba4-9f14-a670a9ccd6c0%40googlegroups.com?utm_medium=email&utm_source=footer).
> > 
> > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![jkressin](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/jkressin/32/9_2.png) [@jkressin](https://forum.search-guard.com/u/jkressin)\
**Post date:** [August 1, 2018, 12:49pm UTC](https://forum.search-guard.com/t/query-logs-with-rights-only-on-logs-user1/1007/10 "2018-08-01T12:49:08Z")

</div>

Ok, thanks for the info, that gives the error a better frame. I will try to replicate it with Kibana as well.

> **···**
>
> On Wednesday, August 1, 2018 at 2:17:08 PM UTC+2, Aurélien GUILLAUME wrote:
> 
> > Hello,
> 
> > I’m able to replicate this.
> 
> > 
> 
> > But now, when you make a generic dashboard in Kibana for your customers (e.g. a public generic read-only .kibana for your customer - in my case I use ), you need to add logs-\* as a log pattern.
> 
> > 
> 
> > And the inventory of the indexes then fails: please try with the user: /\_cat/indices?v&index=logs-\* (vs /\_cat/indices?v&index=logs-user1-\* which works).
> 
> > 
> 
> > But perhaps this is a known behavior.
> 
> > 
> 
> > Thanks,
> 
> > Best regards,
> 
> > –
> 
> > Aurélien GUILLAUME
> 
> > [footplus@gmail.com](mailto:footplus@gmail.com)
> 
> > 
> 
> > 
> 
> > > On 31 Jul 2018, at 19:35, Jochen Kressin [jkressin@floragunn.com](mailto:jkressin@floragunn.com) wrote:
> 
> > > I don’t think it is a bug. I have now tried to replicate the problem and I think somehow the “do not fail on forbidden” feature is not active. Here’s what I did:
> 
> > > I set up three sample indices with one document each:
> 
> > >
> 
> > > ```auto
> > > yellow open logs-user3-2018.1 QwzklrtbTUGrA5QLtS-fIw 5 1 1 0 4.5kb 4.5kb
> > > yellow open logs-user2-2018.1 4qx9VaNgSyaXr76PKSA5DA 5 1 1 0 4.5kb 4.5kb
> > > yellow open logs-user1-2018.1 -Vj1d4cMRzyU-KhJEcuFTw 5 1 1 0 4.5kb 4.5kb
> > > 
> > > ```
> 
> > > ``
> 
> > > I created a user “user1” with the following role:
> 
> > >
> 
> > > sg\_user1:
> 
> > > cluster:
> 
> > > - UNLIMITED
> 
> > > indices:
> 
> > > ‘logs-user1-\*’:
> 
> > > ‘\*’:
> 
> > > - INDICES\_ALL
> 
> > >
> 
> > > ``
> 
> > > And enable dnfof with:
> 
> > >
> 
> > > searchguard:
> 
> > > dynamic:
> 
> > > ```
> > > kibana:
> > > 
> > > ```
> 
> > > ```
> > > do_not_fail_on_forbidden: true
> > > 
> > > ```
> 
> > > ``
> 
> > >
> 
> > > When I query
> 
> > > https://:9200/logs-\*/\_search
> 
> > > ``
> 
> > >
> 
> > > I get data from the index:
> 
> > >
> 
> > > ```auto
> > > logs-user1-2018.1
> > > 
> > > ```
> 
> > > ``
> 
> > > without an error. Tested with the compliance edition.
> 
> > >
> 
> > > Can you check whether the dnfof feature is really active by pulling your current configuration from the cluster and posting the sg\_config.yml here? You can use sgadmin and the -r/–retrieve switch which will pull the active configuration from the cluster and place them in the current directory.
> 
> > > On Tuesday, July 31, 2018 at 11:17:56 AM UTC+2, Aurélien GUILLAUME wrote:
> > > 
> > > > Hello,
> 
> > > > So, is it a bug or did I misunderstood the feature ?
> 
> > > >
> 
> > > > Thanks,
> 
> > > > ## Best regards,
> 
> > > > Aurélien GUILLAUME
> 
> > > > [footplus@gmail.com](mailto:footplus@gmail.com)
> 
> > > >
> 
> > > >
> 
> > > > > On 20 Jul 2018, at 15:46, Aurélien GUILLAUME [footplus@gmail.com](mailto:footplus@gmail.com) wrote:
> 
> > > > > Hello,
> 
> > > > > In fact I thought this was an enterprise feature, and I enabled the Trial licence to check that. I also did try the compliance edition:
> 
> > > > >
> 
> > > > > [2018-07-20T15:36:44,978][INFO][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Info: SearchGuardLicense [uid=00000000-0000-0000-0000-000000000000, type=TRIAL, features=[COMPLIANCE], issueDate=2018-07-03, expiryDate=2018-09-02, issuedTo=The world, issuer=floragunn GmbH, startDate=2018-07-03, majorVersion=6, clusterName=\*, allowedNodeCount=2147483647, msgs=, expiresInDays=43, isExpired=false, valid=true, action=, prodUsage=Yes, one cluster with all commercial features and unlimited nodes per cluster., clusterService=org.elasticsearch.cluster.service.ClusterService@176bcbb5, getMsgs()=, getExpiresInDays()=43, isExpired()=false, isValid()=true, getAction()=, getProdUsage()=Yes, one cluster with all commercial features and unlimited nodes per cluster.]
> 
> > > > >
> 
> > > > > But there is no change in the outputs.
> 
> > > > >
> 
> > > > > Using com.floragunn:search-guard-6:6.3.1-compliance-2 right now; with the same errors.
> 
> > > > >
> 
> > > > > Privilege lookup log is the following:
> 
> > > > >
> 
> > > > > [2018-07-20T15:42:12,298][INFO][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=user1, roles=[customer], requestedTenant=null] Resolved [aliases=, indices=[access\_log-2018.06.18, access\_log-2018.06.19, access\_log-global-2018.07.19, access\_log-user2-2018.07.20, access\_log-global-2018.07.17, access\_log-global-2018.07.18, access\_log-global-2018.07.15, access\_log-global-2018.07.16, access\_log-global-2018.07.13, access\_log-global-2018.07.14, access\_log-global-2018.07.11, access\_log-global-2018.07.12, access\_log-global-2018.07.10, access\_log-user1-2018.07.15, access\_log-user1-2018.07.16, access\_log-user1-2018.07.17, access\_log-user1-2018.07.18, access\_log-user1-2018.07.11, access\_log-user1-2018.07.12, access\_log-user1-2018.07.13, access\_log-user1-2018.07.14, access\_log-user1-2018.07.19, access\_log-global-2018.07.08, access\_log-global-2018.07.09, access\_log-global-2018.07.06, access\_log-test-2018.07.02, access\_log-user2-2018.07.10, access\_log-global-2018.07.07, access\_log-user2-2018.07.11, access\_log-global-2018.07.05, access\_log-user2-2018.07.12, access\_log-user2-2018.07.13, access\_log-global-2018.07.02, access\_log-test-2018.07.06, access\_log-user2-2018.07.14, access\_log-global-2018.07.03, access\_log-test-2018.07.05, access\_log-user1-2018.07.20, access\_log-user2-2018.07.15, access\_log-user2-2018.07.16, access\_log-test-2018.07.03, access\_log-user2-2018.07.17, access\_log-user2-2018.07.18, access\_log-test-2018.07.09, access\_log-user2-2018.07.19, access\_log-test-2018.07.08, access\_log-test-2018.07.07, access\_log-user1-2018.07.05, access\_log-user1-2018.07.06, access\_log-user1-2018.07.07, access\_log-user1-2018.07.02, access\_log-user1-2018.07.03, access\_log-2018.07.02, access\_log-user1-2018.07.08, access\_log-2018.06.30, access\_log-user1-2018.07.09, access\_log-2018.07.01, access\_log-test-2018.07.13, access\_log-test-2018.07.12, access\_log-test-2018.07.11, access\_log-test-2018.07.10, access\_log-test-2018.07.17, access\_log-user2-2018.07.02, access\_log-test-2018.07.16, access\_log-user2-2018.07.03, access\_log-test-2018.07.15, access\_log-user2-2018.07.05, access\_log-test-2018.07.14, access\_log-user1-2018.07.10, access\_log-user2-2018.07.06, access\_log-user2-2018.07.07, access\_log-test-2018.07.19, access\_log-user2-2018.07.08, access\_log-test-2018.07.18, access\_log-user2-2018.07.09, access\_log-2018.06.27, access\_log-2018.06.28, access\_log-2018.06.29, access\_log-2018.06.23, access\_log-2018.06.24, access\_log-2018.06.25, access\_log-2018.06.26, access\_log-2018.06.20, access\_log-2018.06.21, access\_log-2018.06.22, access\_log-test-2018.07.20, access\_log-global-2018.07.20], allIndices=[access\_log-2018.06.18, access\_log-2018.06.19, access\_log-global-2018.07.19, access\_log-user2-2018.07.20, access\_log-global-2018.07.17, access\_log-global-2018.07.18, access\_log-global-2018.07.15, access\_log-global-2018.07.16, access\_log-global-2018.07.13, access\_log-global-2018.07.14, access\_log-global-2018.07.11, access\_log-global-2018.07.12, access\_log-global-2018.07.10, access\_log-user1-2018.07.15, access\_log-user1-2018.07.16, access\_log-user1-2018.07.17, access\_log-user1-2018.07.18, access\_log-user1-2018.07.11, access\_log-user1-2018.07.12, access\_log-user1-2018.07.13, access\_log-user1-2018.07.14, access\_log-user1-2018.07.19, access\_log-global-2018.07.08, access\_log-global-2018.07.09, access\_log-global-2018.07.06, access\_log-test-2018.07.02, access\_log-user2-2018.07.10, access\_log-global-2018.07.07, access\_log-user2-2018.07.11, access\_log-global-2018.07.05, access\_log-user2-2018.07.12, access\_log-user2-2018.07.13, access\_log-global-2018.07.02, access\_log-test-2018.07.06, access\_log-user2-2018.07.14, access\_log-global-2018.07.03, access\_log-test-2018.07.05, access\_log-user1-2018.07.20, access\_log-user2-2018.07.15, access\_log-user2-2018.07.16, access\_log-test-2018.07.03, access\_log-user2-2018.07.17, access\_log-user2-2018.07.18, access\_log-test-2018.07.09, access\_log-user2-2018.07.19, access\_log-test-2018.07.08, access\_log-test-2018.07.07, access\_log-user1-2018.07.05, access\_log-user1-2018.07.06, access\_log-user1-2018.07.07, access\_log-user1-2018.07.02, access\_log-user1-2018.07.03, access\_log-2018.07.02, access\_log-user1-2018.07.08, access\_log-2018.06.30, access\_log-user1-2018.07.09, access\_log-2018.07.01, access\_log-test-2018.07.13, access\_log-test-2018.07.12, access\_log-test-2018.07.11, access\_log-test-2018.07.10, access\_log-test-2018.07.17, access\_log-user2-2018.07.02, access\_log-test-2018.07.16, access\_log-user2-2018.07.03, access\_log-test-2018.07.15, access\_log-user2-2018.07.05, access\_log-test-2018.07.14, access\_log-user1-2018.07.10, access\_log-user2-2018.07.06, access\_log-user2-2018.07.07, access\_log-test-2018.07.19, access\_log-user2-2018.07.08, access\_log-test-2018.07.18, access\_log-user2-2018.07.09, access\_log-2018.06.27, access\_log-2018.06.28, access\_log-2018.06.29, access\_log-2018.06.23, access\_log-2018.06.24, access\_log-2018.06.25, access\_log-2018.06.26, access\_log-2018.06.20, access\_log-2018.06.21, access\_log-2018.06.22, access\_log-test-2018.07.20, access\_log-global-2018.07.20], types=[\*], isAll()=false, isEmpty()=false] [Action [indices:monitor/stats]] [RolesChecked [sg\_own\_index, sg\_customer]]
> 
> > > > > [2018-07-20T15:42:12,300][INFO][c.f.s.c.PrivilegesEvaluator] No permissions for [indices:monitor/stats]
> 
> > > > > > On 18 Jul 2018, at 19:03, Jochen Kressin [jkressin@floragunn.com](mailto:jkressin@floragunn.com) wrote:
> 
> > > > > > I think we now have a guess regarding this issue: Am I right in the assumption that you are using the Community Edition? If this is the case, please try the 6.3.1-compliance-2 SG plugin.
> 
> > > > > > Background: The feature I mentioned was once an Enterprise feature, but we made it a Community feature. This has been implemented in the SG Compliance codebase. We are in the process of merging the codebases, but for now it is only available in the compliance builds.
> 
> > > > > >
> 
> > > > > > You can use these builds and disable all enterprise features as you probably did with the 22.3 version.
> > > > > > 
> > > > > > On Friday, July 13, 2018 at 4:20:20 PM UTC+2, Aurélien GUILLAUME wrote:
> > > > > > 
> > > > > > > Hello,
> 
> > > > > > > > On 11 Jul 2018, at 17:40, [footplus@gmail.com](mailto:footplus@gmail.com) wrote:
> 
> > > > > > > > Hello,
> 
> > > > > > > >
> 
> > > > > > > > Thanks for your quick response.
> 
> > > > > > > >
> 
> > > > > > > > Le mercredi 11 juillet 2018 15:49:27 UTC+2, Jochen Kressin a écrit :
> 
> > > > > > > > > Setting do\_not\_fail\_on\_forbidden to false will give you behavior 1), setting it to true will give you behavior 2).
> 
> > > > > > > > >
> 
> > > > > > > >
> 
> > > > > > > > I had already tried this one, but it doesn’t seem to be effective ?
> 
> > > > > > > >
> 
> > > > > > >
> 
> > > > > > > Searching further in the code : is this setting even used for something other than the \_searchguard/kibana info page ?
> 
> > > > > > >
> 
> > > > > > > BCS-NBK-AGU [footy] ~/Projects/search-guard % grep -r forbidden .
> 
> > > > > > > ./sgconfig/sg\_config.yml: #do\_not\_fail\_on\_forbidden: false
> 
> > > > > > > ./src/main/java/com/floragunn/searchguard/configuration/PrivilegesEvaluator.java: && getConfigSettings().getAsBoolean(“searchguard.dynamic.kibana.do\_not\_fail\_on\_forbidden”, false);
> 
> > > > > > > ./src/main/java/com/floragunn/searchguard/tools/SearchGuardAdmin.java: System.out.println(" a configuration error and is therefore forbidden now.");
> 
> > > > > > > ./src/main/java/com/floragunn/searchguard/rest/KibanaInfoAction.java: builder.field(“not\_fail\_on\_forbidden\_enabled”, evaluator.notFailOnForbiddenEnabled());
> 
> > > > > > >
> 
> > > > > > > !130! BCS-NBK-AGU [footy] ~/Projects/search-guard % grep -r notFailOnForbidden .
> 
> > > > > > > ./src/main/java/com/floragunn/searchguard/configuration/PrivilegesEvaluator.java: public boolean notFailOnForbiddenEnabled() {
> 
> > > > > > > ./src/main/java/com/floragunn/searchguard/rest/KibanaInfoAction.java: builder.field(“not\_fail\_on\_forbidden\_enabled”, evaluator.notFailOnForbiddenEnabled());
> 
> > > > > > >
> 
> > > > > > > Thanks,
> 
> > > > > > >
> 
> > > > > > > Best regards,
> 
> > > > > > > Aurélien
> 
> > > > > >
> 
> > > > > > –
> > > > > > 
> > > > > > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.
> > > > > > 
> > > > > > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard+unsubscribe@googlegroups.com](mailto:search-guard+unsubscribe@googlegroups.com).
> > > > > > 
> > > > > > To post to this group, send email to [search-guard@googlegroups.com](mailto:search-guard@googlegroups.com).
> > > > > > 
> > > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/8c6f70fe-15a8-4f2f-b4c3-8ba39fe20fcb%40googlegroups.com](https://groups.google.com/d/msgid/search-guard/8c6f70fe-15a8-4f2f-b4c3-8ba39fe20fcb%40googlegroups.com?utm_medium=email&utm_source=footer).
> > > > > > 
> > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> 
> > > > >
> 
> > > >
> 
> > >
> 
> > > –
> > > 
> > > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.
> > > 
> > > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard+unsubscribe@googlegroups.com](mailto:search-guard+unsubscribe@googlegroups.com).
> > > 
> > > To post to this group, send email to [search-guard@googlegroups.com](mailto:search-guard@googlegroups.com).
> > > 
> > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/1434cc0c-2709-4ba4-9f14-a670a9ccd6c0%40googlegroups.com](https://groups.google.com/d/msgid/search-guard/1434cc0c-2709-4ba4-9f14-a670a9ccd6c0%40googlegroups.com?utm_medium=email&utm_source=footer).
> > > 
> > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> 
> >

---

<div class="post-metadata">

**Author:** ![jkressin](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/jkressin/32/9_2.png) [@jkressin](https://forum.search-guard.com/u/jkressin)\
**Post date:** [August 2, 2018, 1:17pm UTC](https://forum.search-guard.com/t/query-logs-with-rights-only-on-logs-user1/1007/11 "2018-08-02T13:17:13Z")

</div>

However, I could not reproduce this behavior in Kibana. I logged in with user1, created an index pattern “logs-\*” and a visualization and a dashboard. Everything worked fine here. Could you please describe how to reproduce this exactly in Kibana?

> **···**
>
> On Wednesday, August 1, 2018 at 2:49:08 PM UTC+2, Jochen Kressin wrote:
> 
> > Ok, thanks for the info, that gives the error a better frame. I will try to replicate it with Kibana as well.
> > 
> > On Wednesday, August 1, 2018 at 2:17:08 PM UTC+2, Aurélien GUILLAUME wrote:
> > 
> > > Hello,
> 
> > > I’m able to replicate this.
> 
> > >
> 
> > > But now, when you make a generic dashboard in Kibana for your customers (e.g. a public generic read-only .kibana for your customer - in my case I use ), you need to add logs-\* as a log pattern.
> 
> > >
> 
> > > And the inventory of the indexes then fails: please try with the user: /\_cat/indices?v&index=logs-\* (vs /\_cat/indices?v&index=logs-user1-\* which works).
> 
> > >
> 
> > > But perhaps this is a known behavior.
> 
> > >
> 
> > > Thanks,
> 
> > > Best regards,
> 
> > > –
> 
> > > Aurélien GUILLAUME
> 
> > > [footplus@gmail.com](mailto:footplus@gmail.com)
> 
> > >
> 
> > >
> 
> > > > On 31 Jul 2018, at 19:35, Jochen Kressin [jkressin@floragunn.com](mailto:jkressin@floragunn.com) wrote:
> 
> > > > I don’t think it is a bug. I have now tried to replicate the problem and I think somehow the “do not fail on forbidden” feature is not active. Here’s what I did:
> 
> > > > I set up three sample indices with one document each:
> 
> > > >
> 
> > > > ```auto
> > > > yellow open logs-user3-2018.1 QwzklrtbTUGrA5QLtS-fIw 5 1 1 0 4.5kb 4.5kb
> > > > yellow open logs-user2-2018.1 4qx9VaNgSyaXr76PKSA5DA 5 1 1 0 4.5kb 4.5kb
> > > > yellow open logs-user1-2018.1 -Vj1d4cMRzyU-KhJEcuFTw 5 1 1 0 4.5kb 4.5kb
> > > > 
> > > > ```
> 
> > > > ``
> 
> > > > I created a user “user1” with the following role:
> 
> > > >
> 
> > > > sg\_user1:
> 
> > > > cluster:
> 
> > > > - UNLIMITED
> 
> > > > indices:
> 
> > > > ‘logs-user1-\*’:
> 
> > > > ‘\*’:
> 
> > > > - INDICES\_ALL
> 
> > > >
> 
> > > > ``
> 
> > > > And enable dnfof with:
> 
> > > >
> 
> > > > searchguard:
> 
> > > > dynamic:
> 
> > > > ```
> > > > kibana:
> > > > 
> > > > ```
> 
> > > > ```
> > > > do_not_fail_on_forbidden: true
> > > > 
> > > > ```
> 
> > > > ``
> 
> > > >
> 
> > > > When I query
> 
> > > > https://:9200/logs-\*/\_search
> 
> > > > ``
> 
> > > >
> 
> > > > I get data from the index:
> 
> > > >
> 
> > > > ```auto
> > > > logs-user1-2018.1
> > > > 
> > > > ```
> 
> > > > ``
> 
> > > > without an error. Tested with the compliance edition.
> 
> > > >
> 
> > > > Can you check whether the dnfof feature is really active by pulling your current configuration from the cluster and posting the sg\_config.yml here? You can use sgadmin and the -r/–retrieve switch which will pull the active configuration from the cluster and place them in the current directory.
> 
> > > > On Tuesday, July 31, 2018 at 11:17:56 AM UTC+2, Aurélien GUILLAUME wrote:
> > > > 
> > > > > Hello,
> 
> > > > > So, is it a bug or did I misunderstood the feature ?
> 
> > > > >
> 
> > > > > Thanks,
> 
> > > > > ## Best regards,
> 
> > > > > Aurélien GUILLAUME
> 
> > > > > [footplus@gmail.com](mailto:footplus@gmail.com)
> 
> > > > >
> 
> > > > >
> 
> > > > > > On 20 Jul 2018, at 15:46, Aurélien GUILLAUME [footplus@gmail.com](mailto:footplus@gmail.com) wrote:
> 
> > > > > > Hello,
> 
> > > > > > In fact I thought this was an enterprise feature, and I enabled the Trial licence to check that. I also did try the compliance edition:
> 
> > > > > >
> 
> > > > > > [2018-07-20T15:36:44,978][INFO][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Info: SearchGuardLicense [uid=00000000-0000-0000-0000-000000000000, type=TRIAL, features=[COMPLIANCE], issueDate=2018-07-03, expiryDate=2018-09-02, issuedTo=The world, issuer=floragunn GmbH, startDate=2018-07-03, majorVersion=6, clusterName=\*, allowedNodeCount=2147483647, msgs=, expiresInDays=43, isExpired=false, valid=true, action=, prodUsage=Yes, one cluster with all commercial features and unlimited nodes per cluster., clusterService=org.elasticsearch.cluster.service.ClusterService@176bcbb5, getMsgs()=, getExpiresInDays()=43, isExpired()=false, isValid()=true, getAction()=, getProdUsage()=Yes, one cluster with all commercial features and unlimited nodes per cluster.]
> 
> > > > > >
> 
> > > > > > But there is no change in the outputs.
> 
> > > > > >
> 
> > > > > > Using com.floragunn:search-guard-6:6.3.1-compliance-2 right now; with the same errors.
> 
> > > > > >
> 
> > > > > > Privilege lookup log is the following:
> 
> > > > > >
> 
> > > > > > [2018-07-20T15:42:12,298][INFO][c.f.s.c.PrivilegesEvaluator] No index-level perm match for User [name=user1, roles=[customer], requestedTenant=null] Resolved [aliases=, indices=[access\_log-2018.06.18, access\_log-2018.06.19, access\_log-global-2018.07.19, access\_log-user2-2018.07.20, access\_log-global-2018.07.17, access\_log-global-2018.07.18, access\_log-global-2018.07.15, access\_log-global-2018.07.16, access\_log-global-2018.07.13, access\_log-global-2018.07.14, access\_log-global-2018.07.11, access\_log-global-2018.07.12, access\_log-global-2018.07.10, access\_log-user1-2018.07.15, access\_log-user1-2018.07.16, access\_log-user1-2018.07.17, access\_log-user1-2018.07.18, access\_log-user1-2018.07.11, access\_log-user1-2018.07.12, access\_log-user1-2018.07.13, access\_log-user1-2018.07.14, access\_log-user1-2018.07.19, access\_log-global-2018.07.08, access\_log-global-2018.07.09, access\_log-global-2018.07.06, access\_log-test-2018.07.02, access\_log-user2-2018.07.10, access\_log-global-2018.07.07, access\_log-user2-2018.07.11, access\_log-global-2018.07.05, access\_log-user2-2018.07.12, access\_log-user2-2018.07.13, access\_log-global-2018.07.02, access\_log-test-2018.07.06, access\_log-user2-2018.07.14, access\_log-global-2018.07.03, access\_log-test-2018.07.05, access\_log-user1-2018.07.20, access\_log-user2-2018.07.15, access\_log-user2-2018.07.16, access\_log-test-2018.07.03, access\_log-user2-2018.07.17, access\_log-user2-2018.07.18, access\_log-test-2018.07.09, access\_log-user2-2018.07.19, access\_log-test-2018.07.08, access\_log-test-2018.07.07, access\_log-user1-2018.07.05, access\_log-user1-2018.07.06, access\_log-user1-2018.07.07, access\_log-user1-2018.07.02, access\_log-user1-2018.07.03, access\_log-2018.07.02, access\_log-user1-2018.07.08, access\_log-2018.06.30, access\_log-user1-2018.07.09, access\_log-2018.07.01, access\_log-test-2018.07.13, access\_log-test-2018.07.12, access\_log-test-2018.07.11, access\_log-test-2018.07.10, access\_log-test-2018.07.17, access\_log-user2-2018.07.02, access\_log-test-2018.07.16, access\_log-user2-2018.07.03, access\_log-test-2018.07.15, access\_log-user2-2018.07.05, access\_log-test-2018.07.14, access\_log-user1-2018.07.10, access\_log-user2-2018.07.06, access\_log-user2-2018.07.07, access\_log-test-2018.07.19, access\_log-user2-2018.07.08, access\_log-test-2018.07.18, access\_log-user2-2018.07.09, access\_log-2018.06.27, access\_log-2018.06.28, access\_log-2018.06.29, access\_log-2018.06.23, access\_log-2018.06.24, access\_log-2018.06.25, access\_log-2018.06.26, access\_log-2018.06.20, access\_log-2018.06.21, access\_log-2018.06.22, access\_log-test-2018.07.20, access\_log-global-2018.07.20], allIndices=[access\_log-2018.06.18, access\_log-2018.06.19, access\_log-global-2018.07.19, access\_log-user2-2018.07.20, access\_log-global-2018.07.17, access\_log-global-2018.07.18, access\_log-global-2018.07.15, access\_log-global-2018.07.16, access\_log-global-2018.07.13, access\_log-global-2018.07.14, access\_log-global-2018.07.11, access\_log-global-2018.07.12, access\_log-global-2018.07.10, access\_log-user1-2018.07.15, access\_log-user1-2018.07.16, access\_log-user1-2018.07.17, access\_log-user1-2018.07.18, access\_log-user1-2018.07.11, access\_log-user1-2018.07.12, access\_log-user1-2018.07.13, access\_log-user1-2018.07.14, access\_log-user1-2018.07.19, access\_log-global-2018.07.08, access\_log-global-2018.07.09, access\_log-global-2018.07.06, access\_log-test-2018.07.02, access\_log-user2-2018.07.10, access\_log-global-2018.07.07, access\_log-user2-2018.07.11, access\_log-global-2018.07.05, access\_log-user2-2018.07.12, access\_log-user2-2018.07.13, access\_log-global-2018.07.02, access\_log-test-2018.07.06, access\_log-user2-2018.07.14, access\_log-global-2018.07.03, access\_log-test-2018.07.05, access\_log-user1-2018.07.20, access\_log-user2-2018.07.15, access\_log-user2-2018.07.16, access\_log-test-2018.07.03, access\_log-user2-2018.07.17, access\_log-user2-2018.07.18, access\_log-test-2018.07.09, access\_log-user2-2018.07.19, access\_log-test-2018.07.08, access\_log-test-2018.07.07, access\_log-user1-2018.07.05, access\_log-user1-2018.07.06, access\_log-user1-2018.07.07, access\_log-user1-2018.07.02, access\_log-user1-2018.07.03, access\_log-2018.07.02, access\_log-user1-2018.07.08, access\_log-2018.06.30, access\_log-user1-2018.07.09, access\_log-2018.07.01, access\_log-test-2018.07.13, access\_log-test-2018.07.12, access\_log-test-2018.07.11, access\_log-test-2018.07.10, access\_log-test-2018.07.17, access\_log-user2-2018.07.02, access\_log-test-2018.07.16, access\_log-user2-2018.07.03, access\_log-test-2018.07.15, access\_log-user2-2018.07.05, access\_log-test-2018.07.14, access\_log-user1-2018.07.10, access\_log-user2-2018.07.06, access\_log-user2-2018.07.07, access\_log-test-2018.07.19, access\_log-user2-2018.07.08, access\_log-test-2018.07.18, access\_log-user2-2018.07.09, access\_log-2018.06.27, access\_log-2018.06.28, access\_log-2018.06.29, access\_log-2018.06.23, access\_log-2018.06.24, access\_log-2018.06.25, access\_log-2018.06.26, access\_log-2018.06.20, access\_log-2018.06.21, access\_log-2018.06.22, access\_log-test-2018.07.20, access\_log-global-2018.07.20], types=[\*], isAll()=false, isEmpty()=false] [Action [indices:monitor/stats]] [RolesChecked [sg\_own\_index, sg\_customer]]
> 
> > > > > > [2018-07-20T15:42:12,300][INFO][c.f.s.c.PrivilegesEvaluator] No permissions for [indices:monitor/stats]
> 
> > > > > > > On 18 Jul 2018, at 19:03, Jochen Kressin [jkressin@floragunn.com](mailto:jkressin@floragunn.com) wrote:
> 
> > > > > > > I think we now have a guess regarding this issue: Am I right in the assumption that you are using the Community Edition? If this is the case, please try the 6.3.1-compliance-2 SG plugin.
> 
> > > > > > > Background: The feature I mentioned was once an Enterprise feature, but we made it a Community feature. This has been implemented in the SG Compliance codebase. We are in the process of merging the codebases, but for now it is only available in the compliance builds.
> 
> > > > > > >
> 
> > > > > > > You can use these builds and disable all enterprise features as you probably did with the 22.3 version.
> > > > > > > 
> > > > > > > On Friday, July 13, 2018 at 4:20:20 PM UTC+2, Aurélien GUILLAUME wrote:
> > > > > > > 
> > > > > > > > Hello,
> 
> > > > > > > > > On 11 Jul 2018, at 17:40, [footplus@gmail.com](mailto:footplus@gmail.com) wrote:
> 
> > > > > > > > > Hello,
> 
> > > > > > > > >
> 
> > > > > > > > > Thanks for your quick response.
> 
> > > > > > > > >
> 
> > > > > > > > > Le mercredi 11 juillet 2018 15:49:27 UTC+2, Jochen Kressin a écrit :
> 
> > > > > > > > > > Setting do\_not\_fail\_on\_forbidden to false will give you behavior 1), setting it to true will give you behavior 2).
> 
> > > > > > > > > >
> 
> > > > > > > > >
> 
> > > > > > > > > I had already tried this one, but it doesn’t seem to be effective ?
> 
> > > > > > > > >
> 
> > > > > > > >
> 
> > > > > > > > Searching further in the code : is this setting even used for something other than the \_searchguard/kibana info page ?
> 
> > > > > > > >
> 
> > > > > > > > BCS-NBK-AGU [footy] ~/Projects/search-guard % grep -r forbidden .
> 
> > > > > > > > ./sgconfig/sg\_config.yml: #do\_not\_fail\_on\_forbidden: false
> 
> > > > > > > > ./src/main/java/com/floragunn/searchguard/configuration/PrivilegesEvaluator.java: && getConfigSettings().getAsBoolean(“searchguard.dynamic.kibana.do\_not\_fail\_on\_forbidden”, false);
> 
> > > > > > > > ./src/main/java/com/floragunn/searchguard/tools/SearchGuardAdmin.java: System.out.println(" a configuration error and is therefore forbidden now.");
> 
> > > > > > > > ./src/main/java/com/floragunn/searchguard/rest/KibanaInfoAction.java: builder.field(“not\_fail\_on\_forbidden\_enabled”, evaluator.notFailOnForbiddenEnabled());
> 
> > > > > > > >
> 
> > > > > > > > !130! BCS-NBK-AGU [footy] ~/Projects/search-guard % grep -r notFailOnForbidden .
> 
> > > > > > > > ./src/main/java/com/floragunn/searchguard/configuration/PrivilegesEvaluator.java: public boolean notFailOnForbiddenEnabled() {
> 
> > > > > > > > ./src/main/java/com/floragunn/searchguard/rest/KibanaInfoAction.java: builder.field(“not\_fail\_on\_forbidden\_enabled”, evaluator.notFailOnForbiddenEnabled());
> 
> > > > > > > >
> 
> > > > > > > > Thanks,
> 
> > > > > > > >
> 
> > > > > > > > Best regards,
> 
> > > > > > > > Aurélien
> 
> > > > > > >
> 
> > > > > > > –
> > > > > > > 
> > > > > > > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.
> > > > > > > 
> > > > > > > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard+unsubscribe@googlegroups.com](mailto:search-guard+unsubscribe@googlegroups.com).
> > > > > > > 
> > > > > > > To post to this group, send email to [search-guard@googlegroups.com](mailto:search-guard@googlegroups.com).
> > > > > > > 
> > > > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/8c6f70fe-15a8-4f2f-b4c3-8ba39fe20fcb%40googlegroups.com](https://groups.google.com/d/msgid/search-guard/8c6f70fe-15a8-4f2f-b4c3-8ba39fe20fcb%40googlegroups.com?utm_medium=email&utm_source=footer).
> > > > > > > 
> > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> 
> > > > > >
> 
> > > > >
> 
> > > >
> 
> > > > –
> > > > 
> > > > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.
> > > > 
> > > > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard+unsubscribe@googlegroups.com](mailto:search-guard+unsubscribe@googlegroups.com).
> > > > 
> > > > To post to this group, send email to [search-guard@googlegroups.com](mailto:search-guard@googlegroups.com).
> > > > 
> > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/1434cc0c-2709-4ba4-9f14-a670a9ccd6c0%40googlegroups.com](https://groups.google.com/d/msgid/search-guard/1434cc0c-2709-4ba4-9f14-a670a9ccd6c0%40googlegroups.com?utm_medium=email&utm_source=footer).
> > > > 
> > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> 
> > >
> 
> Ok, I see what you mean with /\_cat/indices?v&index=logs-\* vs /\_cat/indices?v&index=logs-user1-\*. We need to dig a bit deeper into this.