Not all mapped LDAP groups being updated - LDAP User Import Application

[mouhb]

We have an issue with the "LDAP User Import" Application (version 1.5.6), the issue is that several mapped LDAP groups are not updated by the "Mapped groups daily updater" Job, the corresponding XWiki groups are empty knowing that the LDAP groups are not empty.

Note that the XWiki LDAP Authenticator supports 3 types of groups :

• 1: LDAP static groups (users/subgroups are listed statically in the group object)
• 2: LDAP organization units (users/subgroups are sub object of the provided organization unit)
• 3: LDAP filter (users/groups are object found in a search with the provided filter)

Based on that I managed to correctly update the empty groups with a workaround, the workaround consists of updating the mapping (on XWiki.XWikiPreferences) of the groups to replace the group DN in the mapping with an LDAP filter (type 3).

Example :

Mapping generated by the LDAP User Import Application

xwiki:XWiki.TestGroup=CN=Employees,OU=Groups,OU=ABC,DC=example,DC=com

Replaced with

xwiki:XWiki.TestGroup=MemberOf=CN=Employees,OU=Groups,OU=ABC,DC=example,DC=com

So, it seems that we are in the situation where the LDAP group do not directly contains its members but it is the users who are associated with the group (via an attribute (ex : memberOf)).

So, for the moment only LDAP static groups (type 1) is supported by the LDAP User Import Application.

The objective of this ticket is to add support for the other group types (2 and 3) on the LDAP User Import application.

[trrenty]

Hello, Mohamed. After some testing and investigating, I have the following observations.

The authenticator supports three types of ldap groups and so does the ldap user import app.

The second type of groups 2: LDAP organization units (users/subgroups are sub object of the provided organization unit), from what I understand, refer to users/groups that are hierarchically located under our mapped group.

For example, if we have the following ldap group and users:

# Group
dn: cn=Group1,dc=e,dc=c
member: cn=User1,dc=e,dc=c
# User that has its dn hierarchically located under the dn of the group
dn: cn=User2,cn=Group1,dc=e,dc=c

It is expected that the daily updater job will create/update both the User1 and the User2. User2 belonging to the TYPE 2 case. And it works as expected.

What we could do as an improvement to the application is to also list the organizational units when associating a xwiki group to a ldap entity. I will create an issue in that regard.

The third type of groups 3: LDAP filter (users/groups are object found in a search with the provided filter), in the context of the authenticator, translates to the fact that the user_group maps also supports a custom filter in addition to the dn of a group. This is the workaround you used. Instead of mapping an XWiki group to a ldap group dn, you mapped it to a filter. If you wanted to allow those ldap users to authenticate to XWiki, you would have to do the same thing in the xwiki properties.

Now, in the context of the User Import App, I understand that the clients expects that when you associate a XWiki group to a LDAP group i.e. xwiki:XWiki.TestGroup=CN=Employees,OU=Groups,OU=ABC,DC=example,DC=com the update job should update/create the three types of users: 1. found in the member attribute of mapped group, 2. hierarchically under the mapped group, 3. the users that have some attribute with the value equal to the mapped group dn. Well, the third type of user is the outlier. The authenticator supports that type of users only if you configure it manually. To give an example for the ldap group , if you want all three types of users to be able to authenticate into xwiki you would have to have the following property in the xwiki.properties file: xwiki.authentication.ldap.user_group=CN=Employees,OU=Groups,OU=ABC,DC=example,DC=com|memberOf=CN=Employees,OU=Groups,OU=ABC,DC=example,DC=com. The first value beind a dn and the second being a filter.

Currently, the User Import App, doesn't give the user the possibility to associate a group with a filter but you can easily do that in the Active Directory administration section, under the advanced configuration. However, if we want to keep the applications separate, it is a good improvement. I will create an issue for this as well.

To give a solution to this issue, I added a new configuration property where the admin can specify an attribute (such as memberOf) where the group updating jobs should also look for when resolving user membership to a group. Now, if you associate a xwiki group to a ldap group and specify the memberOf attribute in the configuration, the updater job will look for all the members inside that mappped group but also for all the members that have the value of the attribute equal to the mapped group.

[mouhb]

Thank you for the improvement @trrenty