Issue with setting Grafana roles via LDAP

Grafana
1

Hello, I’m trying to set up LDAP for authorization for Grafana. It’s mostly working, in that Grafana is getting the info about the account from our LDAP server, but what won’t work is assigning permissions based on LDAP group membership. We’re running Grafana 4.6.3 on CentOS 7.3.

Some (mildly sanitized) config and results of testing:

grafana.ini:

#################################### Auth LDAP      ##########################
[auth.ldap]
enabled = true
;config_file = /etc/grafana/ldap.toml
;allow_sign_up = true

ldap.toml:

# User search filter, for example "(cn=%s)" or "(sAMAccountName=%s)" or "(uid=%s)"
search_filter = "(uid=%s)"

# An array of base dns to search through
search_base_dns = ["ou=people,dc=our,dc=domain,dc=here"]

## Group search filter, to retrieve the groups of which the user is a member (only set if memberOf attribute is not available)
group_search_filter = "(&(objectclass=groupOfNames)(member=uid=%s,ou=people,dc=our,dc=domain,dc=here))"

## An array of the base DNs to search through for groups. Typically uses ou=groups
group_search_base_dns = ["ou=webapps,dc=our,dc=domain,dc=here"]

# Specify names of the ldap attributes your ldap uses
[servers.attributes]
name = "givenName"
surname = "sn"
username = "uid"
member_of = "cn"
email =  "mail"

# Map ldap groups to grafana org roles
[[servers.group_mappings]]
group_dn = "cn=grafana-admins,ou=webapps,dc=our,dc=domain,dc=here"
org_role = "Admin"

[[servers.group_mappings]]
# If you want to match all (or no ldap groups) then you can use wildcard
group_dn = "*"
org_role = "Viewer"

This setup pulls the user’s info correctly and allows it to log in, but will not set Admin permissions when the user is a member of the “grafana-admins” group, as I would expect.

sqlite> select * from user where login="userid";
2|0|userid|userid@my.email.com|First Last|||||1|0|0||2017-12-01 18:09:36|2017-12-14 21:04:56|0|2018-01-09 21:38:40

The name and email info have never been entered into Grafana, so I know it’s getting them from the LDAP server. The user does get logged in, but only has “Viewer” permissions.

I turned Grafana’s LDAP logging to debug mode, and it looks like it is populating “MemberOf” correctly, with group names that exist on our LDAP server.

t=2018-01-09T21:38:40+0000 lvl=dbug msg="Got Ldap User Info" logger=ldap user="(*login.LdapUserInfo)(0xc4209e8850)({\n DN: (string) (len=43) \"uid=userid,ou=people,dc=our,dc=domain,dc=here\",\n FirstName: (string) (len=7) \"First\",\n LastName: (string) (len=6) \"Last\",\n Username: (string) (len=7) \"userid\",\n Email: (string) (len=24) \"userid@my.email.com\",\n MemberOf: ([]string) (len=172 cap=256) {\n  (string) (len=14) \"real-ldap-group-names-redacted\",\n  (string) (len=14) \"grafana-admins\"\n }\n})\n"

I’m guessing there is something about that response from the LDAP server that Grafana isn’t quite matching on, so the user gets in with “Viewer” perms but not “Admin”. Does anyone know what I’m missing to get it to match correctly?

Thanks in advance!

2

The part that jumped out at me is the member_of attribute - should it be cn?

If you test without the wildcard for viewer, does it work for grafana admins then?

P.S. Just in case you didn’t know, semicolon means the line is commented out - not sure if that is anything to do with your problem though.

3

I have member_of = "cn" because of this part of the config file:

# In POSIX LDAP schemas, without memberOf attribute a secondary query must be made for groups.
# This is done by enabling group_search_filter below. You must also set member_of= "cn"
# in [servers.attributes] below.

As that is true for my environment.

I tried removing the wildcard, but my explicit rule still fails to math. So I get authenticated, but am still unauthorized, it acts as if I belong to no organizations.

I had those lines commented because my understanding is those were the default values that were being set anyway. I did try uncommenting them just now but there was no change in behavior

Thanks for helping take a look at it.

4

So we resolved this issue. We needed to change:

group_dn = "cn=grafana-admins,ou=webapps,dc=our,dc=domain,dc=here"

to:

group_dn = "grafana-admins"

Unfortunately we then ran into this bug.

Mainly just posting this for the benefit of anyone else who comes across this issue.

1 Like