ZBXNEXT-1390 and ZBXNEXT-1138 related to this one

There seems to be a ton of interest in this, not only by the related and duplicate reports but by the vote and watch count for this issue alone. What's this waiting on? In my issue I even noted that supporting code for this feature already seems to exist so perhaps this is purely a cosmetic oversight? Thanks for your time.

I agree, LDAP filters are such an easy and essential feature, please add it!

This is extremely necessary, please prioritize this

Another vote to implement this enhancement request. Would be great to have LDAP / Active Directory groups be able to map to user groups in Zabbix. Will make administration a whole lot easier. Thank you, Devon, IBM.

Another vote for this please. A much needed option. Thanks.

As an interm solution, I recommend checking out https://github.com/dnaeon/zabbix-ldap-sync. I've been using it in production, works great.

+1

This is really necessary for anything larger than small LDAP integrations. Perhaps add a LDAP group in the "User groups" section so users logging in via LDAP will get matched to a group?

+1 for how important this is to us - my (800+user) org cannot adopt zabbix the way we want to unless we can overcome this limitaiton

please use the voting feature instead of adding "+1" comments
see http://zabbix.org/wiki/Docs/bug_reporting_guidelines#Reporting_an_issue for more detail

I hope we can implement this feature in Zabbix 3.4. At least it's in our roadmap now.

ZBXNEXT-1390 would integrate nicely with this. If LDAP authentication is successful, autocreate the user with the groups from LDAP.

ruckc, that would probably a bit more complicated. for example, if ldap groups change, it would be very undesirable for the zabbix permissions not to reflect it.

Actually we're considering a new background process, which would periodically synchronize (one way, LDAP -> Zabbix) users, groups and their relationship. I think that Zabbix should also support an optional mapping between LDAP and Zabbix user groups for extra flexibility.

Couldn't the group membership sync of the user be done on login? At the time the user logs in using LDAP, Zabbix syncs its groups and checks if the user is still the member of the groups it needs to be able to login into Zabbix. What is also important is that this sync would create all LDAP groups which the user is a member of as well.

Of course if it's easier to do this sync of groups periodically, that's fine as well, but I usually like it when the changes made in LDAP are instant.

Also could you please add support for specifying a backup LDAP server? LDAP doesn't have any failover mechanism, so the clients need to implement it themselves. This would be only a few lines of code, but would make everyone's life a lot easier.

Actually we're considering a new background process, which would periodically synchronize (one way, LDAP -> Zabbix) users, groups and their relationship. I think that Zabbix should also support an optional mapping between LDAP and Zabbix user groups for extra flexibility.

alexei so, basically, what you're doing is something like this https://github.com/dnaeon/zabbix-ldap-sync? I'm using this in production, and it is very reliable. I run it in a cron job two times a day and added a frontend script to run it on demand. It basically search three groups in our ldap server recursively, and add every member to its respective Zabbix group (Super Admin, Admin, or Normal Users) using the Zabbix API.

As long as it handles group access removal i think it is fine. I still would prefer just having filter because and maybe even group support for ldap groups. Having separate groups in zabbix is kind of annoying as well.

My ideal scenario would be: admin credentials from somewhere in the config for the initial setup. Then all groups/users are taken directly from ldap without having to have matching groups in zabbix.

exi I don't know if your reply was to me, but the Python script that I posted do support ldap group removals. It will delete the user from Zabbix if it is removed from the ldap group.
About separate groups, it actually create the groups on Zabbix exactly like they are in the ldap, but for the access level, it is not controlled by the groups. In Zabbix, the access level is controlled individually per user. So the script will just create the user as "Zabbix User", "Zabbix Admin" or "Zabbix Super Admin" as per your configuration.

Why not simply allow users to specify a group to group and group to user-level mapping, instead? Meaning, specify that an LDAP group "Domain Admins" maps to "Zabbix Super Admins", for user level. Similarly, LDAP group "Sales Users" maps to a zabbix group "Sales Hosts". This would involve a simple LDAP query for user group membership after a successful login. It also allows to maintain separation between authentication and authorization, so an internal web server authentication can get the user in, and then LDAP-based authorization would use PHP_USER attribute to determine group membership(s) and run those against pre-defined map.

I'm all for LDAP Group -> User level mapping, since I don't see a better way of setting the user level in LDAP on the user object. But, I'm against LDAP Group -> Zabbix Group mapping. It's much easier just to create/sync LDAP groups with Zabbix, so when you create a group in LDAP it's automatically available in Zabbix without any need of modifying Zabbix settings to configure mapping.

The concept of a group is different between LDAP & Zabbix. In LDAP, a group represents a collection of users and/or other user groups. In Zabbix, a group represents a collection of users with specific permissions to a set of host groups. Thus, there has to be a mapping between an LDAP Group and Zabbix Host Group->Zabbix host permissions.

If we simply synchronize the groups from LDAP to Zabbix, following is a list of issues:

• What do you do when a user changes the name of the group in LDAP? In order for this to work, you would need to also keep track of the object-SID for AD groups, but what do you do for other LDAP-based deployments that might not have this concept?
• How do you maintain a distinct list of LDAP Groups and internal Zabbix Groups? How do you avoid name-space collisions between the two?
• What do you do when someone deletes a group? Do you delete it from Zabbix as well?
• What do you do when someone wants to give multiple LDAP Group's access to the same Zabbix Host Group with the same permissions? Do you copy the same list of groups+permissions between two groups? If so, then you have to synchronize changes to this list.

Having a mapping that says: LDAP Group Name = Zabbix Group Name eliminates all of the above issues. It also eliminates the need to keep on synchronizing data between two because the only thing Zabbix will care about is your group membership at the time of login, which if missing will be treated as an empty list.

[email protected], it seems like the concept is similar enough - " In LDAP, a group represents a collection of users and/or other user groups. In Zabbix, a group represents a collection of users". permissions is an extra property that is often applied by ldap consumers.

nevertheless, your first item is valid. as a naive first implementation, zabbix could just ignore this possibility.

not sure about your second item - got an example of a problem case ?

your third item is "that's a good question" - zabbix group could be deleted, but what if that was the only group for some user... maybe a fallback group of "none" is assigned to all abandoned users or something.

your fourth item - that seems to be the same as when somebody would want to give multiple zabbix user groups access to the same hostgroup.

While the group concepts seem similar, the notion of permissions assigned to specific host groups is not usually present in LDAP. And even if it was, the hosts and host groups in LDAP might not match the ones in Zabbix. That means that one would need to synchronize the groups from LDAP before assigning host groups and permissions to them for that group. Depending on the environment, this approach would also generate a potentially large set of unnecessary groups in Zabbix.

Finally, in environments with multiple AD domains and forests, it would mean that multiple Global Catalogues would need be synchronized. This would also require Zabbix to allow multiple LDAP server configurations, and support for LDAP references.

The second point was about user groups that are local to Zabbix as opposed to the ones synchronized from LDAP. Unless the intention is to eliminate local groups if LDAP sync is enabled, there will always be a possibility of name space collision. I.e., group called "my users" defined in Zabbix having specific permissions, and identically named one that would be synchronized from the LDAP.

It seems to me that local Zabbix groups + group to LDAP group mapping is a lot easier to implement and support than synchronization.

right, the hostgroups is a completely different area. i believe a logical step is to handle syncing / looking up of user groups, while the host group assignment is done in zabbix still.
unnecessary groups being in zabbix is possible, although it could be mitigated by only syncing the groups users are in, or even providing an ability to filter by group (like "zabbix").

multiple ldap servers is a bit out of scope - it is more practical to implement a simpler approach first

group name collision - i suppose there could be an easy decision on that. for example, always matching the groups by name, no matter their origin (manually created or auto-created from ldap).

not sure how group mapping would help here - it seems like most of the mentioned concerns would be valid for such a case, too.

An approach that I have seen in another solutions is:
Groups should be created in Zabbix first and users are synced at login time. The groups should be create exactly like they are in ldap, then Zabbix assign the user to the internal group with the same name. If the user is removed from the ldap group, at next login, he is removed from Zabbix group of same name.
This would solve the host permissions, and for the Zabbix RBAC permissions, which is only 3 today (Admin, Super Admin and Normal User), we could have an option in the configuration to specify an ldap group for each role.

markkrj, that would work too. I would also urge not creating local Zabbix users if LDAP integration is enabled. This way there would be no need to remove them afterwards...

If an application requires group mapping, that's just bad design and lazy programing. Zabbix shouldn't invent the wheel and just copy this from other well know applications (one of them could be Jira, since it's used here). As far as I know Jira works like this:

• Multiple directories can be used at the same time (local, LDAP, Crowd) and they have priorities. Priority is needed when you have the same user in both directories.
• You can specify user search filters and group search filters so that only users/groups you want will be synced from LDAP.
• Sync is done periodically, but it can also be configured that user group sync is done on each login, so that on login the user has the latest groups.
• Since more directories can be active, if you have groups with the same name in multiple directories, their members are merged from all directories.
• Application has something like General permissions or Roles, in which you define what each user/group has access to (in case of Zabbix this would be e.g. access to hosts/hostgroups).

Since Zabbix also has the notion of type of user (Super Admin, Admin, User) and because LDAP doesn't have something like that, this could also be controlled by LDAP groups and in Zabbix by a search filter and mapping. For example in LDAP you could create two groups: zabbix-superadmin, zabbix-admin} and {{zabbix-user; in Zabbix you would define by a LDAP search filter for user type which would match zabbix-* groups only and you would map each group to the Super Admin, Admin and User roles in Zabbix. We could probably even drop a special filter for these groups and just use the regular groups which Zabbix syncs and choose which of those map to Zabbix roles.

Having a setup like this would be awesome because you would only need to set Zabbix RBAC mapping, while group creating and management would be done in LDAP and Zabbix would only be used for setting permissions for those groups.

Should we synchronize every Zabbix user from LDAP into Zabbix DB ?

Every user in Zabbix DB has some customizable individual settings, like Language, Theme, Auto-logout, Refresh (in seconds), Rows per page, URL (after login), Media (type, send to, when active) etc. Also, there are number of Zabbix DB tables with various things related to a particular user (e.g. maps, screens, slideshows, membership in user groups, alerts) – theoretically those settings could be stored in LDAP server. Practically the concept of individual user with all settings in Zabbix DB tables is deeply rooted in Zabbix code – moving things to LDAP seems not worth the effort.

So, all users authenticated via LDAP should have accounts in Zabbix DB as well. That means we need to develop a synchronization tool to create users in Zabbix DB from LDAP data.

Is there a query now (or stored procedure) to set up a user in Zabbix? It shouldn't be too hard to script a tool that can at least do this behind the scenes until such time it can be done through a web interface. I'd like to take a crack at building one for Microsoft Active Directory. I'd then imagine groups marked internal in Zabbix would also be synced to a respective group in AD (such as ZabbixUsers) and member verification could be directed to AD for lookup instead of Zabbix.

I really think a proper LDAP Support is really essential for the use of ZABBIX, it would be really great to see some work on this!

Cheers!

Andris,
I think the best method would be to link a user template to an LDAP group so when a member of that group logs on for the first time a user account is created based on the template. From that point the account would act as they currently do and be in the database.

"Should we synchronize every Zabbix user from LDAP into Zabbix DB ?
Every user in Zabbix DB has some customizable individual settings, like Language, Theme, Auto-logout, Refresh (in seconds), Rows per page, URL (after login), Media (type, send to, when active) etc. Also, there are number of Zabbix DB tables with various things related to a particular user (e.g. maps, screens, slideshows, membership in user groups, alerts) – theoretically those settings could be stored in LDAP server. Practically the concept of individual user with all settings in Zabbix DB tables is deeply rooted in Zabbix code – moving things to LDAP seems not worth the effort.
So, all users authenticated via LDAP should have accounts in Zabbix DB as well. That means we need to develop a synchronization tool to create users in Zabbix DB from LDAP data."

How about to create two-way integration?

We can add an additional option like "Integration type" with two possible values "Read" (LDAP > Zabbix) and "Read/Write" (LDAP <> Zabbix). The "Read/Write" example (assuming that BindDN has required permissions):

• new user added in Zabbix means that it will be created in LDAP
• user updated First name in Frontend, Zabbix will change it in LDAP also

I've attached a quick modification to CLDAP.php that uses a switch case to determine the users domain and changes the LDAP server, basedn and search attributes respectively. Obviously this isn't a permanent solution but allows the use of different LDAP servers while waiting for an official (and better) implementation. 

patch.diff

From a purely Zabbix Admin perspective, I would rather administrate Zabbix (Hosts, Host Groups etc) than manage userid's.  While its relatively easy to add users, we have not way to knowing when a user has left the company and needs to be removed.  Further, at least in our AD set up, we are able to tell who the manager of each team/group is.  If there was a way to include that in any integration, that would make contact from the Admin to user base so much easier.

This should be done in the same way as Grafana is doing it, thus not forcing a POSIX compliant LDAP server.

Assuming that the group names in LDAP are exactly the same as in Zabbix is naive and ignores the fact that LDAP servers might have grown over time and can not always be set up in a green field approach. So a mapping will be necessary.

Very cool, external authentication not done right after 9+ years
Also, still no oauth support and no authenticated user auto sign up

Watched this ticket for a while and decided to share my solution. It's primitive but works well for us, at least we don't have a headache to create all the users manually. Initially I wanted to authenticate users against AD map them to internal Zabbix User Groups without user creation but hit huge roadblock in the face of how Zabbix handles users' session, bottom line - you must have User ID to keep session active, so here is my solution.

1) LDAP authentication is selected as 'Default authentication' at Administration->Authentication.
2) Zabbix Administrator creates mappings 'AD group' to 'Zabbix User Group(s)' at Administration->AD Groups in WebUI. For every AD group a 'User type' is defined (User/Admin/Super Admin).
In my case I see membership information as an array of records with format 'CN=<cn_name>,OU=<ouX>,OU=<ouY>...etc'. We use only CN field to map groups.
3) If a user logs in and it does exist in internal Zabbix database (Administration->Users) then no change in behaviour - it is authenticated against LDAP server.
3) If a user logs in and does not exist in internal Zabbix dataase (Administration->Users) then:
3.1) Zabbix performs authentication against LDAP server (password verification).
3.2) Zabbix pulls the user's AD groups membership information from LDAP server.
3.3) Zabbix compares groups received in 3.2) to internal mappings created in 2) and compiles a list of internal Zabbix User Groups.
3.4) If no AD group found authentication fails.
3.5) A user is created belonging to Zabbix User Groups found in 3.3) with 'User type' defined for matched 'AD group'. If multiple AD Groups found then the highest level of 'User type' applied.

Here is the code https://github.com/BGmot/zabbix

Don't kick me too hard -)

Please add this feature!

Please make this a priority, I love your product but it's really shameful you don't have this simple feature

Wow - ten years have passed.

Question: why does this depend on https://support.zabbix.com/browse/ZBXNEXT-2289? They are completely unrelated, other than both being related to LDAP, and honestly the ZBNEXT-2289 seems more complicated because of the consistency and clashing errors you have to check for. That will delay this, and this ticket is already old enough. 

IMHO there is no need to invest time and effort to any LDAP<–>Zabbix synchronization.

LDAP directory should be considered only as third party authentication provider.

+1 for Grafana way to handle LDAP user/groups handling see: https://grafana.com/docs/grafana/latest/auth/ldap/#group-mappings

Please consider at least adding the ability to manually adjust filter expression in LDAP configuration form, the expression which is passed to ldap_search for being able to unitize memberOf attribute like so:

ldapsearch -D "uid=ldap_search,cn=groups,cn=accounts,dc=example,dc=com" -W "(&(objectClass=inetOrgPerson)(memberOf=cn=prod_zabbix,cn=groups,cn=accounts,dc=example,dc=com))" -LLL

which results selection of users which are members of defined LDAP group.

For now it can only be achieved by changing code of include/classes/ldap/CLdap.php but those changes are not survive during updates. 

I personally like the way Rundeck handled LDAP integration.

Users are created in Rundeck on first login, access is provided based on AD groups.

Very easy to admin.

This feature would we super useful for me as well!

Awesome, 11 years from the creation. So frenetic rhythm adding useful features

@luis you can code yourself what you think is the right implementation of this feature and submit a Pull Request.

@javier as I've done with other 12 tools and custom scripts, workflows and implementations that I'm using... but in a any point in the future I need to focus to my business.

If for core team is not a priority, delete the issue, decrease the level of priority. It's hard to understand still opened during more than 10 years...

Having been away from the Zabbix world for a couple of years, i'm kind of astounded that LDAP auth (and role delineation) on LDAP groups is still not present in Zabbix.  Any tool advertising itself as Enterprise must also allow external enterprise-level authentication.  Why has an obvious win like this languished for so long?

csawyerzs, great to see you, welcome back!

I am with you! It is a shame that this functionality is not implemented yet despite high popularity and many votes. We have made our first attempt of implementing it a few years ago but it appeared that we over-engineered it, so the development was stopped. Now I am planning detailed roadmap of Zabbix 6.2 and I think that this functionality has all chances to be part of it.

I will keep you updated about any progress.

The topic is not as simple as might seem but at least basic functionality would satisfy 90% of Zabbix' users. This is exactly as it is done in Grafana plus comparing to Grafana you don't need to modify any configuration files creating "mappings" between AD groups and Zabbix User Groups - everything is in WebUI. Just take a look (as a first shot at the problem) at https://bgmot.com/zabbix_ldap_groups_52 - very simple and straightforward (sorry for implicit advertising but this is the only place where I have this demo). I would have done it as a Module long time ago but unfortunately I don't know how to bypass index.php invocation + some DB changes are needed. Please do something in 6.0 while it is still not released.

BGmot , I am afraid this functionality will not be part of Zabbix 6.0, which is about to be released.

Will be great if Zabbix take emails and phone number from synced users for notifications purposes.

Hi, is it possible to include same support for SAML and add OIDC auth? I saw SAML is on roadmap feature description for 6.2 but I didn't find references here.

@Evgeny - Only today I discovered your post/work and I think is a great Idea!!

@Alexei - This ZBXNEXT seems was not updated to reflect the Zabbix roadmap 6.2, is correct or do you think this feature will not be a part of 6.2 release?

Thanks so much

dimitri.bellini, we are still aiming for Zabbix 6.2.

@Alexei - Good! Thanks so much

> @Evgeny - Only today I discovered your post/work and I think is a great Idea!!

@Dimitri, my "solution" has been around since 4.2 -)

@Evgeny - Yes, now I know Thanks so much for your great work!

This functionality was moved to Zabbix 6.4. It was extended to support a combination of SAML+SCIM, stay tuned.

To add, I hope this functions in ways that for example Jira's LDAP sync does. Allowing you to sync both users and groups based off separate LDAP filters.

For example, syncing users based on a memberOf at some interval.

Or just sync users from the groups you specify in the groups config page in Zabbix since they have an LDAP dropdown already. Then people don't need to mess with filters.

Very much looking forward to this feature for 10 years hehe. I'm so glad it's finally on the roadmap! Thanks!

Thank you dpcahill for your interest in this feature.

There will be difference between Zabbix implementation and JIRA.

• Zabbix will not pull/sync all users from LDAP user directory. User with super administrator privileges can start such task manually, for selected set of users created from LDAP.
• LDAP user will be created in Zabbix on user login, when there is match between LDAP groups and Zabbix groups.
• LDAP user data is synchronized when user is logging in, logging out and once per defined interval when user is working with API or Frontend.
• User data to be synchronized: name, surname, medias, groups.
• User will be removed from Zabbix when were created by LDAP and because of changes in LDAP groups do not have any group in Zabbix.

LDAP group property attribute, such as memberOf, can be defined or special group filter to search for in LDAP tree.

P.S. Described above is also applicable to Active Directory users synchronization.

Another +1 for the provisioning of SAML users. Currently adding users takes lots of time.

Nice to have would be the roles feature, for example in azure AD. 

But just groups would already be a lifesaver!

Hello,

What is the latest with this please?

We really need the functionality to add an Active Directory Group and give it access to specific Hosts/Host Groups without having to manually create each user or get them to login first then create an additional group in Zabbix.

Thanks

craig.pryor, we are aiming to support this feature in Zabbix 6.4. Currently no indicators that it could be postponed.

Amazing - Thank you!

This is great!

Implemented in:

• 6.4.0beta4 (master) 324c6f1893f

Why it is so quiet here? 🥳 The functionality (btw, the most voted feature request!) has been implemented and coming in Zabbix 6.4 soon! Grab the latest beta and see check how it works for you. 😀

Wow... what a leap forward.... awesome.. going to try it out soon

@Alexei I guess that everyone was sitting tight, seeing this feature request finally implemented.

Seriously, it's awesome that it's here now, so congrats on making this work.

I'm happy to see this happening after 12+ years of waiting! I'm sure it will not only make my own (work) life easier and more convenient, but also the lifes of many Zabbix admins around the globe. 

Next step for me is then to pressure the operations team to upgrade to Zabbix 6.4  

Many thanks!

Thanks a lot for this! I'd wish you'd start backporting nice things to LTS when they are proven stable. In a large environment, you can't just upgrade to every new version all the time.

Thanks to all who have now made the implementation possible 🥳 🍾🎊🎉. I'm sure we will give it a try soon.

Updated documentation:

• What's new
• LDAP authentication
• SAML authentication
• SAML setup with Okta
• Authentication
• Users

Updated API documentation:

• Authentication:
  • > Authentication object
  • authentication.get
• User:
  • > User object
  • user.get
  • user.create
  • user.update
  • (new) user.provision
• User group:
  • > User group object
  • usergroup.delete
• User directory:
  • > User directory object
  • userdirectory.get
  • userdirectory.test
  • userdirectory.create
  • userdirectory.update
• Appendix 2. Changes from 6.2 to 6.4

Hi, I've installed zabbix 6.4beta5 and testing ldap authentication with JIT provisioning enabled following this 2 LDAP, the settings were saved well, but I don't see the LDAP users into Zabbix after a day. So questions:

1) Is there any zabbix log to see if this feature is really running? 

2) In the documentation, could you please post an example of how the user/group ldap scheme should be to work with the new feature? 

For instant my users ldap scheme does not have a group attribute for in what group the user belongs, but I have a separated group OU that contains the attribute memberUID with the  user attibutes  "cn" to correlate group and users. 

For users:

ou=People, dc=domain,dc=com
           uid=myuser,ou=People, dc=domain,dc=com
                cn=myuser
                passwd=xxxx

           uid=binduser,ou=People, dc=domain,dc=com
                cn=binduser
               passwd=xxxx

For Groups:

ou=Group, dc=domain,dc=com
           cn=ForZabbixSynx, ou=Group, dc=domain,dc=com
                      memberUID: myuser
                      memberUID: myuser2
                      memberUID: myuser3

Thanks,

Hi verde, please ensure you have set following settings:

• "Deprovisioned users group" is defined. Selected group should be disabled, "Enabled" checkbox is not set in group configuration form.
• "Enable JIT provisioning" checkbox set in LDAP servers list
• "Configure JIT provisioning" checkbox set and "User group mapping" defined. For testing purpose you can create group mapping with LDAP group pattern equal "*" with "User groups" set to frontend groups you want to assign to user and "User role" set to user role you want to assign to user.

You can use "Test" button in LDAP server configuration form to ensure that configured mapping work. On successful match you will see user groups and role which will be assigned automatically to user when user will try to login for first time.

Documentation is in review/merge and will be published soon. Below is example of test AD server, hope it will help.

With regards to User group mapping, i think we also need a priority, as some users can be member of multiple groups.

If user is member of multiple group mappings, all groups from all matched mappings will be added, therefor priority/order is not necessary.

can we confirm group matching is already working correctly in 6.4.0beta6?

I have tried both Group configuration methods with no matching results

memberOf:

Even though my test user is both part of zabbix-administrators & zabbix-guests, in the test authentication works, media type mapping as well, but group matching doesn't yet

Please try to set "Group name attribute" and "User group membership attribute" with all lowercase letters.

I already tried upper and lowercase letters for the attribute without any change... Group mappings are not matched...

Configuration looks valid but in this case group mapping depends on valid attribute names and on value of DN`s passed in "memberOf" from external service. What is DN for "zabbix-administrators" group?

From our LDAP Explorer (where we left out the Base DN in the screenshot for security/privacy reasons):

So lets say our Base DN is something like this: DC=ad,DC=company,DC=example

The full DN path then would be:

memberOf: CN=zabbix-administrators,OU=zabbix,OU=Groups,OU=Cloud,DC=ad,DC=company,DC=example

Also tested against default MS AD groups (updating the Zabbix group mapping) without result:

CN=Administrators,CN=Builtin,DC=ad,DC=company,DC=example

CN=Domain Admins,CN=Users,DC=ad,DC=company,DC=example

PS: how to deal with spaces? We can just add the following LDAP group pattern? (this is just an example): Domain Admins

DEBUG

Is there a way to debug the group mapping in a Zabbix DEBUG mode to see what's going on?

LDAP Mapping working in other applications we use

We are using many other LDAP enabled applications against these DCs with correct group mappings, working in both formats (memberOf & member)

For service returning user attribute memberOf as strings "CN=zabbix-administrators, ..." following settings will match group mapping having LDAP group pattern equal "zabbix-administrators":

Group name attribute:            CN
User group membership attribute: memberof

^{Pay attention to letter case mode in the values.}

I got it working now for both memberOf and groupOfNames groupmembership configuration.

To help people out making sure they don't fall in the same pitfall, it might be helpful to add this to the documentation.

Because the predefined group member attribute (shown in the configuration) mentions: memberOf

However for matching to work on MS AD:

• Group name attribute & reference attributes need to be UPPERcase (CN)
• group member attribute (memberof / member) need to be in lowercase
• media mapping attributes like mail, sn,displayName need to be lowercase

Are nested groups supported?

Let's say I have a ZABBIX-ADMINS group which only have other (organizational) groups as members, can I then use ZABBIX-ADMINS to populate a zabbix user group using JIT provisioning?

@Göran Eriksson For nested groups in AD or Samba, you should use Zabbix's `groupOfNames` option with OID 1.2.840.113556.1.4.1941 (LDAP_MATCHING_RULE_IN_CHAIN), like this:

Group name attribute: sAMAccountName
Group member attribute: member
Reference attribute: distinguishedName
Group filter: (&(objectclass=group)(%{groupattr}:1.2.840.113556.1.4.1941:=%{ref}))

I'd suggest putting all Zabbix specific groups in a separated OU, and use that OU as the `Group base DN` because nested LDAP queries could get quite slow with wide scope and/or bad queries.

I'd suggest putting all Zabbix specific groups in a separated OU, and use that OU as the `Group base DN` because nested LDAP queries could get quite slow with wide scope and/or bad queries.

That would be an easy option for MS AD users, but for those using an IdP which doesn't typically use OUs for group membership (for example FreeIPA / RedHat IdM), this is not so easy as they use OUs to identify different organisations. Meaning most deployments only have one OU and all groups are CN based.

Well, FreeIPA/Red Hat idM do not have support for LDAP_MATCHING_RULE_IN_CHAIN anyways, so it obviously does not apply to them... Nested groups support for other/any LDAP implementations must be done on client side, querying for groups recursively, which is expensive and so, hardly anyone does that!

I was under the impression that test would take the shown configuration, apparently it doesn't always.

Changing the configuration before testing requires to first change the existing configuration AND PRESS UPDATE, otherwise test will sometimes seem to use the previous configuration (i ran into caching problems only discovered doing browser debug)

Saving a configuration, logging out, login again and the previous LDAP server configuration is shown again.

I guess we need an LDAP Debug tool built in the test to show what is actually replaced and (not) matched to resolve cases like this faster, as currently it is invisible what is happening within Zabbix, turning on DEBUG does not show LDAP debug output.

Nested groups:

Group name attribute, can be either: CN or sAMAccountname

Group member attribute: member:1.2.840.113556.1.4.1941:

Reference attribute must be: distinguishedName

Group filter: (&(objectclass=group)(%{groupattr}=%{ref})) or (%{groupattr}=%{ref})

My config is like this: 

It works!

jdegraeve configuration test button uses values from configuration form, not from the database. The values from configuration form are taken and send to userdirectory.test API, no need to update and/or do login/logout.

Note to anyone coming here because they can't get JIT provisioning to work in Zabbix 7 with FreeIPA:

The thing that was preventing it from working for me was the "User group membership attribute". 

• By default, it has 'memberOf' filled in, but in grey. 
  • In most UIs, that would indicate that 'memberOf' is the default value.
• Here, you must type 'memberOf' over top of the grey 'memberOf'.

Final form:

LDAP Server

• Name: any cosmetic name
• Host: ip address or hostname of your ldap server
• Port: 389 (for ldap), or 636 (for ldaps, but I didn't test it yet)
• Base DN: cn=accounts,dc=EXAMPLE,dc=COM
• Search attribute: uid
• Bind DN: uid=zabbix-service-account,cn=users,cn=accounts,dc=EXAMPLE,dc=COM
• Bind password: fill in the password for zabbix-service-account
• Description: anything
• Configure JIT provisioning: checked
• Group configuration: select memberOf
• Group name attribute: cn
• User group membership attribute: memberOf     <<<==== VITAL LAST PIECE: YOU MUST TYPE THIS YOURSELF
• User name attribute: givenName
• User last name attribute: sn
• User group mapping:
  • LDAP group pattern: some ldap group name, wildcard allowed
  • User groups: the zabbix group to put them in
  • User role: the zabbix role to grant them
• Media type mapping:
  • Name: the ldap attribute to map, like 'mail'
  • Media type: which zabbix media type are we talking to, like 'Email (HTML)'
  • Attribute: which zabbix attribute to give as a parameter to that media type, like 'email address' (I haven't tested this yet)

The best tool for debugging this is the LDAP server logs, in my case /var/log/syslog/dirsrv/slapd-EXAMPLE-COM/access.

The worst tool is /var/log/zabbix/zabbix_server.log, since it doesn't say anything about authentication problems even at DebugLevel=5.

Hope this helps!