Good day. We are a RoR PRO subscriber, and I have been a bit lazy in keeping our production cluster upgraded, so we’ve been “coasting” on ES/Kibana 6.7 with RoR 1.18 for a while, and I am just now upgrading a test / clone cluster to 7.14 with RoR 1.33. Everything is mostly working, but it seems something we used to do in our RoR settings is not being recognized, or there’s a bug with the AD Group Membership coming from our LDAP queries, so I need some help.
Note that I am an experienced network and infrastructure engineer and so I generally know how to write permission ACLs, including “permit/deny all of these cases except a few of those unusual exceptions”, but of course every ACL-matching engine’s logic is different, so I am willing to reorganize our ACL config to accomplish the same goal, if need be. I don’t think our use case is very complicated, and I am happy to copy/paste our config or logs with appropriate bits redacted. If it’s easier for you to just provide a framework template of “typically this is how that would be done”, and leave it to me to adapt to my specific group names and such, that’s fine, too.
All my end users are authenticated and authorized through Microsoft AD LDAP. Obviously we’d prefer not to write any rules directly inside RoR that reference specific human usernames; we’d prefer to make all changes by simply moving users in and out of AD groups, and this had traditionally worked great for years. Our LDAP query is constrained to an OU that contains only the few group names under it, to keep the LDAP replies from including a pile of superfluous group names.
We are already using the special, rather old, Microsoft-proprietary LDAP_MATCHING_RULE_IN_CHAIN recursive membership filter field (unique_member_attribute: “member:1.2.840.113522.214.171.1241:”), to be sure to cover cases where user A is a member of group X, and then group X is a member (nested in AD) of group Y, and group Y is the one in the RoR config. I believe this is still working perfectly well right now, because I swapped it out for plain non-chaining “member” and the symptom persisted.
Generally we have 3 groups of users, of which a user would be expected to be a member of only one: Super Users, ReadAllIndices Users, and DashboardOnly Users. The first group should be able to do anything in ES, including writing data into indices (best practice, I’ve excluded editing the RoR settings, reserving that for the special Kibana admin superuser). The second should basically be able to query any data out of any-named indices and set up some quick visualizations, but not write to any indices (and not write back to Kibana, so they can’t mess up existing charts and dashboards). The third should only be able to view dashboards created by others, so the other application icons are suppressed; they probably do technically have read permissions on the underlying indices, but if they are unaware of that and don’t use manual “curl” commands, and they stay safely within the cocooned Kibana environment, then they remain pretty constrained.
However, there is a set of more-sensitive traffic logs in one (wildcarded set) of indices, so we want to keep even the “super users” from seeing them. So I made one additional AD group, and I added two rules ahead of the others, a Permit and a Deny, specifically matching on indices = “confidentiallogs-*” and groups = this 4th AD group name. So if the query is for one of these sensitive logs, then the user has to be in the 4th group; e.g. if they’re only a member of Super Users but not of Sensitive Logs Users, then they hit the Deny. Up until 6.7 w/1.18, this all worked terrific!
So judging from the behavior and error messages in the ES logs, this setup has stopped working upon upgrading RoR to the latest.
If a user is a member of multiple AD groups, it seems to recognize only one of them. In particular, I am a member of both the Super Users and Sensitive Logs groups, but when I first tried to sign into Kibana after the upgrade, it accepted my username & password (so, was confirming my credentials via LDAP), but then it wouldn’t even paint the main Kibana screen at all. It seemed to think I was in Sensitive Logs but not in Super Users (and also not ReadAllIndices or Dashboard Users), so it didn’t have enough ES permissions to show even the welcome screen.
So I set aside the Sensitive Users access for a moment and just took myself out of that AD group, leaving me only in Super Users. Then I was fully able to log in and start looking around the new Kibana 7 to see which dashboards might need some modifications. Not being in Sensitive Users means that I am (correctly) forbidden from seeing the indices with the sensitive data, which is great. So the use case for most of our users (if you are not in Sensitive Users, you can do other things but can never see those logs) is working. But the use case for our sensitive-log users, those who are members of two AD groups, which is working today in our un-upgraded cluster, stopped working. It feels like a bug to me.
I will try to gather some more information and do some experiments (like, see if the alphabetical sort ordering of these two group names is affecting which one it thinks I’m in…???). But I wanted to see if you were already aware of a bug like this or if it’s a new thing I need to deal with after having not watched the releases of RoR for a while. Thanks in advance!
– Jeff Saxe