LDAP - AD User Config vs AD Group Config - Issue

Users Feedback
1

Hi All,

When we configure RoR to connect to the AD and define ldap users against local groups, example:

- name: admins
  indices: [".kibana", ".kibana_*", "ls-*"]
  kibana_access: admin
  kibana_index: ".kibana"
  groups: ["admins"]

- username: test
  groups: ["admins", "dev"]
  ldap_authentication:
    name: ldap1

Everything is consistent, the drop down works flawlessly, no complains.

But when we want to define ldap groups instead (so no users in the config, directly fetch the users from the AD groups), example:

- name: admins perms
  ldap_auth:
    name: "ldap1"
    groups: ["admins"]
  indices: [".kibana", ".kibana_*", "ls-*"]
  kibana_access: admin
  kibana_index: ".kibana"

- name: dev
  ldap_auth:
    name: "ldap1"
    groups: ["dev"]
  indices: [".kibana_dev", "ls-x-*", "ls-g-*"]
  kibana_access: rw
  kibana_hide_apps: ["readonlyrest_kbn", "timelion", "monitoring"]
  kibana_index: ".kibana_dev"

That’s where our problems start, my user belong to both groups, we can login but sometimes the drop menu (admins / dev) appears sometimes it doesn’t… when it appears and I land on admins and choose dev, it goes to it but the drop menu instead of persisting disappear…

In conclusion if I rely on the AD only for user auth, everything is consistent, drop menu works flawlessly, if I rely on AD groups for everything it’s an inconsistent experience.

Any experience or opinion you can share.

Thanks

2

Thank you @insight for the report.

@support_team this needs investigation

3

UPDATE: I think I have a lead on how to solve this. Will prepare a test and see.

4

Hi Simone,

Thanks for your efforts.

I believe (assumption) this is related to how the authentication is done, in user mode the config search on the user ldap and execute the same auth against all the local groups defined within the same bracket while in group mode is completely different since it forces RoR to search the user within the group and execute the auth afterwards and that’s why some times the drop down menu dont appear, other times appear but dont have all the groups that the user belongs to etc…

Thanks
Tiago

5

Hey Tiago, I believe I fixed this by implementing a look-ahead in the whole ACL when computing the available groups (which populate the dropdown menu).

I’m producing a pre build for you, kindly what ES version are you using?

EDIT: here are some builds for common ES versions.

readonlyrest-1.16.29-pre2_es6.4.3.zip

readonlyrest-1.16.29-pre2_es6.4.2.zip

readonlyrest-1.16.29-pre2_es6.4.1.zip

6

Hi Simone,

Thanks for the quick turnaround.

We are using 6.4.2, I will test your new build and comeback to you with feedback.

Thanks
Tiago

1 Like
7

Hi Simone,

Unfortunately the issue persist, to give you additional information (without disclosure our internals), my user belongs to 6 groups, when I login I can only see 2 groups (admin and dev) from the drop down menu, this is my login trace against my default admin group:

[2018-11-09T19:50:06,080][INFO ][t.b.r.a.ACL              ] ALLOWED by { **name: 'shrprd-admins permissions',** policy: ALLOW, rules: [ldap_auth, actions, indices, kibana_access,
kibana_index]} req={ ID:1218281348--573860775#863, TYP:SearchRequest, **CGR:shrprd-admins**, USR:myuser, BRS:false, KDX:.kibana, ACT:indices:data/read/search, OA:xxx.xxx.xxx.xxx, DA:xxx.xxx.xxx.xxx, IDX:.kibana, MET:POST, PTH:/.kibana/_search?size=10000&from=0, CNT:<OMITTED, LENGTH=83>, HDR:{authorization=<OMITTED>, **x-ror-current-group=shrprd-admins**,

Then I go to the drop down menu and change to the dev group, immediately the drop down menu disappear and look to the trace:

[2018-11-09T19:51:32,494][INFO ][t.b.r.a.ACL              ] ALLOWED by { **name: 'shrprd-admins permissions'**, policy: ALLOW, rules: [ldap_auth, actions, indices, kibana_access,
kibana_index]} req={ ID:1859652729-1092121678#1320, TYP:RRAdminRequest, **CGR:shrprd-dev-rw,** USR:myuser, BRS:false, KDX:.kibana, ACT:cluster:admin/rradmin/refreshsettings, OA:xxx.xxx.xxx.xxx, DA:xxx.xxx.xxx.xxx, IDX:<N/A>, MET:GET, PTH:/_readonlyrest/metadata/current_user, CNT:<N/A>, HDR:{authorization=<OMITTED>, Connection=close, content-length=0, **x-ror-current-group=shrprd-dev-rw,**

So RoR change group but goes against the admin ACL, so instead of impersonating the Dev Group and consequently it’s perms (as it does with LDAP user + Local Groups) keep the admin perms while changing group and disappear with the drop down menu all together.

I believe this will take some time to fix so I’m going to suggest my team to change to the User LDAP + Local Groups, it serves our purposes the only drawback is we need to add user by user.

Thanks for all your help.
Tiago

8

Hi Tiago,

Excellent you have a workaround.

Does this mean you expected to see all six?

Some debugging to see if we are on the same page on the ES side of things

Can you try a curl in your problematic system?

# To see available groups passed to Kibana dropdown after login
curl -k -vvv -u myuser:passwd 'https://es-host:9200/_readonlyrest/metadata/current_user' 

# Simulate a change of current group (shrprd-admins)
curl -k -vvv -u myuser:passwd 'https://es-host:9200/_readonlyrest/metadata/current_user'  -H'x-ror-current-group:group=shrprd-admins'

# Simulate a change of current group (dev)
curl -k -vvv -u myuser:passwd 'https://es-host:9200/_readonlyrest/metadata/current_user'  -H'x-ror-current-group:group=shrprd-dev-rw'
9

Hi Simone,

Sorry for the delay in my reply but I was out of the office.

That said, yes I expect to see all the 6 groups since I belong to them and they are defined in the configuration, the exact same way that admin and dev appear.

1st query:

< HTTP/1.1 200 OK
< x-ror-kibana_access: admin
< x-ror-username: myuser
< x-ror-kibana_index: .kibana
< content-type: application/json; charset=UTF-8
< content-length: 175
<
* Connection #0 to host 10.245.3.167 left intact
{"x-ror-current-group":null,"x-ror-username":"myuser","x-ror-kibana-hidden-apps":[],"x-ror-kibana_access":"admin","x-ror-available-groups":[],"x-ror-kibana_index":".kibana"}

2nd query:

> Accept: */*
> x-ror-current-group:group=shrprd-admins
>
< HTTP/1.1 200 OK
< x-ror-current-group: group=shrprd-admins
< x-ror-username: myuser
< x-ror-kibana_access: admin
< x-ror-kibana_index: .kibana
< content-type: application/json; charset=UTF-8
< content-length: 192
<
* Connection #0 to host 10.245.3.167 left intact
{"x-ror-current-group":"group=shrprd-admins","x-ror-username":"myuser","x-ror-kibana-hidden-apps":[],"x-ror-kibana_access":"admin","x-ror-available-groups":[],"x-ror-kibana_index":".kibana"}

3rd query:

> Accept: */*
> x-ror-current-group:group=shrprd-dev-rw
>
< HTTP/1.1 200 OK
< x-ror-current-group: group=shrprd-dev-rw
< x-ror-username: myuser
< x-ror-kibana_access: admin
< x-ror-kibana_index: .kibana
< content-type: application/json; charset=UTF-8
< content-length: 200
<
* Connection #0 to host 10.245.3.167 left intact
{"x-ror-current-group":"group=shrprd-dev-rw","x-ror-username":"myuser","x-ror-kibana-hidden-apps":[],"x-ror-kibana_access":"admin","x-ror-available-groups":[],"x-ror-kibana_index":".kibana"}

As you can see on the 1st query the groups come up as Null more often than they appear, the experience as in the GUI is inconsistent and reflects the appear and dissapear of the drop down menu, the 2nd query is working as it should, right group, perms and index but the 3rd while it change to the desired group keep the exact same permissions / index of the admin group which is the first in line of our configuration.

As curiosity the first 2 groups (admin && dev) that appear allocated to my user are the 2 first in line in the configuration, the 3rd one I dont belong to it but I do on the 4th and that one is nowhere to be seen in terms of RoR fetching it, it seems that stop on the 2nd since I dont belong on the 3rd.

Meanwhile we changed our Prod config to user ldap + local groups and everything works as it should.

Thanks for all your help once again.
Tiago

10

All of the responses have an empty list of available groups, this is not normal, are you sure the request is matching the correct block? There might be some issue with blocks ordering.

11

Hi Simone,

The block order is the same as in the user ldap + local groups and by that I mean:

LDAP Groups:

readonlyrest:
    ssl:

access_control_rules:

LDAP Groups 

LDAP  Config

ldaps:

User LDAP + Local Groups:

readonlyrest:
    ssl:

access_control_rules:

Local Groups 

LDAP Users

LDAP  Config

ldaps:

Yet you are correct when you say that on the LDAP groups config the available groups appear as NULL where in the User LDAP + Local Groups appears as:

{"x-ror-current-group":"shrprd-admins","x-ror-username":"myuser","x-ror-kibana-hidden-apps":[],"x-ror-kibana_access":"admin","x-ror-available-groups":["usprd-all-dev","euprd-all-dev","usprd-res-dev","shrprd--dev-rw","euprd-res-dev","shrprd-admins"],"x-ror-kibana_index":".kibana"}

As you can see both configs are very similar in every regard yet one works perfectly (user ldap + local groups) where the other does not, when we rely on RoR to identify the ldap user and consequently the groups it belong to in the AD the experience is inconsistent / broken.

Thanks
Tiago

12

Hey @insight, I’m afraid the empty avail groups is due to the fact that I had a typo in the curls I gave you.

-H'x-ror-current-group:group=shrprd-admins'

This of course should be:

-H'x-ror-current-group:shrprd-admins'

So sorry, can you try again? And let’s also confirm the right block are matched when we do those curls.

13

Hi Simone,

You are right, the command was not accordingly on my first reply, that said:

{"x-ror-current-group":"shrprd-admins","x-ror-username":"myuser","x-ror-kibana-hidden-apps":[],"x-ror-kibana_access":"admin","x-ror-available-groups":["shrprd-dev-rw","shrprd-admins"],"x-ror-kibana_index":".kibana"}

and

< HTTP/1.1 200 OK
< x-ror-current-group: shrprd-dev-rw
< x-ror-username: myuser
< x-ror-kibana_access: admin
< x-ror-kibana_index: .kibana
< content-type: application/json; charset=UTF-8
< content-length: 194
<
* Connection #0 to host 10.245.3.167 left intact
{"x-ror-current-group":"shrprd-dev-rw","x-ror-username":"myuser","x-ror-kibana-hidden-apps":[],"x-ror-kibana_access":"admin","x-ror-available-groups":[],"x-ror-kibana_index":".kibana"}

So when you push shrprd-admins the 2 groups appear as available, when you push the dev one it comes as NULL. Nothing substantial changes, not all the groups appear and the NULL just reflect the drop down menu absence in a GUI perspective when you select from admin to dev.

Thanks
Tiago

14

…And the ACL block being matched by the above request in the ES logs are the ones you expected?

15

Hi Simone,

RoR when it needs to go through the ACL blocks only associate my user to 2 groups when I belong to 6 that are clearly defined on the configuration, joining to that when you login and select from the admin group to the dev group in the drop down menu you cannot comeback since the drop down menu dissapear which checks with the NULL of the available groups when it should at the very least keep the 2 identified ones:

{“x-ror-current-group”:“shrprd-dev-rw”,“x-ror-username”:“myuser”,“x-ror-kibana-hidden-apps”:[],“x-ror-kibana_access”:“admin”,“x-ror-available-groups”:[]

So even when RoR identifies my user belonging to this 2 groups the experience is broken.

PS: I even tried to add to the configuration just the 2 groups that are identified (nothing else) and the result is exactly the same.

Thanks
Tiago