LDAP - AD User Config vs AD Group Config - Issue


#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


(Simone Scarduzio) #2

Thank you @insight for the report.

@support_team this needs investigation


(Simone Scarduzio) #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


(Simone Scarduzio) #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


#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


(Simone Scarduzio) #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'