In ldap config allow array or wildcard for org_id

[calebcall]

It would be nice if you could use an array or even better would be wildcards for the org_id parameter in the ldap.toml file instead of having to duplicate the same data over and over for each org when a group is an admin/editor for multiple orgs.

[torkelo]

Just interested to know why you are using multiple orgs (to understand usecases). Do each org have their completely / isolated data sources or are they used more to segregate users and dashboards but the underlying time series store is the same?

[calebcall]

The latter, we are starting to get so many graphs/dashboards, it's nice to be able to organize them and the users associated with them in more ways than just using the tags (which are also great).

In this scenario, we have some groups (like our engineering group) that are admins on all orgs as they are the system maintainers. We also have our architecture group that are editors on all orgs as they need to be able to make changes. A wildcard would be best as that would allow a "dynamic" way to keep permissions up to date with new orgs.

Hope this helps.

[torkelo]

@calebcall thanks for the info, its important for me to understand how people use Grafana :)

[kurtabersold]

I also use organizations to divide dashboards among teams. It would be great to be able to add multiple org_ids to a single entry in ldap.toml

[natecarlson]

Ditto here. Most valuable for our usecase would be wildcard (one group needs access to all orgs dashboards, most other users only need to access a single org), but a list would also be easier than the current solution.

[anhlqn]

It would be great to have both a list of org_id and wildcard in my use case when I want group A to be Admin on multiple org, group B to be Editor on multiple org, and certain groups to be Viewer on some org. The data behind each org are different, JFYI.

[reecewebb]

This would be incredibly useful for us as well. All of our orgs currently use the same datasource, but we need to organize our different teams/groups into multiple orgs as some users should have Admin on everything, while others need Viewer on one org and Editor on another. Our ldap.toml has grown quite large.

[SimonHoenscheid]

@torkelo you closed the PR and wrote there will be an other solution. Can you please point out which way the user is supposed to take at this point? If there is no solution in place right now, I would be a big fan of merging the above pull request. the code can be removed when it becomes obsolete.

[calebcall]

I'm pretty sure they are making a change to allow folders within a single org and each folder will be able to have permissions assigned to it. This would 100% solve my use case for multiple orgs and would actually make it MUCH easier in that you could make that one org the default and allow anonymous access to that one org. Then only Editor and Admin would need to explicitly be set.

[torkelo]

yes we are working on folders and user groups. Ldap sync with user groups is not on the road map however and is likely many months away

[grafanabot]

This feature request has been open for a long time with few received upvotes or comments, so we are closing it. We're trying to limit open GitHub issues in order to better track planned work and features.

This doesn't mean that we'll never ever implement it or that we will never accept a PR for it. A closed issue can still attract upvotes and act as a ticket to track feature demand/interest.

Thank You to you for taking the time to create this issue!

[atkrv]

Hey @torkelo 👋

Are there any movements here?

We're using dozens of orgs to let our teams their own nested Grafanas, but want to grant a Viewer access to all these orgs for all the people.

I assume that there's no support for:

[[servers.group_mappings]]
group_dn = "*"
org_role = "Viewer"
org_id = *

or

[[servers.group_mappings]]
group_dn = "*"
org_role = "Viewer"
org_id = ["org1", "org2"]

In case there were no enhancements regarding this request are there any workarounds to help us to achieve our goal (looks like we're not alone in such needs)?

Thanks!

[calebcall]

If you use folders instead of orgs, it will solve your problem. It’s cleaner and less work to allow viewer to all and only have to add editor/admin when needed. @altokarev

[atkrv]

If you use folders instead of orgs, it will solve your problem. It’s cleaner and less work to allow viewer to all and only have to add editor/admin when needed. @altokarev

The crucial point is to give the teams the ability to manage their own data sources.

We don't want be involved in situations when all the teams has their own admins which could affect (or even delete) on data source of the other team.

The isolation in case of orgs much better that folders/teams.

And one more thing - isn't LDAP sync for the folders/teams is available only on Enterprise paid plan?

[atkrv]

@calebcall

[calebcall]

isn't LDAP sync for the folders/teams is available only on Enterprise paid plan?

The sync in Enterprise is like a pre-sync. It happens without users having to log in. However, in non-enterprise, when. user logs in it will sync and they'll have their proper permissions for the folders. As an Enterprise customer we actually ended up turning off the ldap sync due to it triggering a bug at the suggestion of support and we never re-enabled it.

The isolation in case of orgs much better that folders/teams.

Absolutely the isolation is better. However, the only real valuable one is the datasource isolation like you called out. We ended up finding that as a con though. We found majority of our teams wanted to use the same handful of datasources so with orgs, we were having to setup the same ones over and over, or help over and over. With folders/teams, we set them up once and was done. Naming was then consistent as well as a bonus. We found that once we got through the switch from orgs to folders, we weren't setting up new datasources all that often so it wasn't a big deal. Folders also made it nice to share dashboards where anonymous read access was appropriate (like companywide dashboards, exec dashboards, etc) because only one org can be enabled for anonymous access. So with orgs, if you had a dashboard you wanted to share, you either needed to duplicate it and add it to your main org (the one with anonymous enabled) and maintain that same dashboard twice, or just move it to the other org, which then means the team that owns that dashboard is now having to work in multiple orgs.

I certainly agree orgs are nice in some ways, but we found the folders to overall be much a nicer experience.

[diasdmhub]

This would be a nice addition to LDAP mapping.