LDAP Feature request: custom Group-Member association LDAP attribute

[ismailyenigul]

In Advanced LDAP settings Group-Member association parameter accepts predefined values (uniqueMember,memberuid,member.) We have custom LDAP settings and use different ldap attribute. It would be great, if we can define custom ldap attribute name

[karlitschek]

@blizzz

[blizzz]

The reason why there are hard-coded attributes is that they follow a certain format which is taken care of in the code. So customization would require to make the setting more complex. For ownCloud 6 it actually will disappear, because it is detected automatically.

What is your motivation to use a custom attribute for group-member association?

[ismailyenigul]

Hi,

If you use zimbra's or qmail's LDAP backend and if you want to integrate owncloud with these system LDAP backend, there is no member or memberof attribute for groups.
Group members are represented with zimbraMailForwardingAddress in Zimbra and MailForwardingAddress or rfc822member in mailing lists. Or people would like to use their customized ldap attributes.

Thanks

[blizzz]

Okay. I tend to build it in, so it can be autodetected as well. Could you show me examples of the attribute's value for both Zimbra and qmail (and additionally specifiy to which user attribute the value is linked)?

@davidak you should be affected by this too, right?

[ismailyenigul]

First of all, the group in qmail ldap and zimbra is no same as group in active directory. When we refer to group for qmail and zimbra, we usually talk about mail groups rather than people group in generic LDAP.

Zimbra examples:

dn: uid=devlist,ou=people,dc=dev,dc=example,dc=com
zimbraMailStatus: enabled
objectClass: zimbraDistributionList
objectClass: zimbraMailRecipient
zimbraId: 5cbacb34-224c-4124-86c0-479d2d060258
zimbraCreateTimestamp: 20130226134502Z
mail: devlist@dev.example.com
zimbraMailAlias: devlist@dev.example.com
uid: devlist
zimbraMailForwardingAddress: user1@example.com
zimbraMailForwardingAddress: user2@example.com

attributes in qmail.schema

attributetype ( 1.3.6.1.4.1.7914.1.3.1.2 NAME 'rfc822member'
DESC 'Group member specified as normal rf822 email address.'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

For custom ldap attribute mapping, openfire xmmp server configuration is really good example

a quote from http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/ldap-guide.html

Group Settings

provider.group.className ** -- set the value to "org.jivesoftware.openfire.ldap.LdapGroupProvider".
ldap.groupNameField ** -- the field name that the groupname lookups will be performed on. If this property is not set, the default value is cn.
ldap.groupMemberField -- the field name that holds the members in a group. If this property is not set, the default value is member.
ldap.groupDescriptionField -- the field name that holds the description a group. If this property is not set, the default value is description.
ldap.posixMode ** -- a value of "true" means that users are stored within the group by their user name alone. A value of "false" means that users are stored by their entire DN within the group. If this property is not set, the default value is false. The posix mode must be set correctly for your server in order for group integration to work. Posix modes for common LDAP servers:

ActiveDirectory: false

ldap.groupSearchFilter -- an optional search filter to append to the default filter when loading groups. The default group search filter is created using the attribute specified by ldap.groupNameField. For example, if the group name field is "cn", then the default group search filter would be "(cn={0})" where {0} is dynamically replaced with the group name being searched for.

The most common usage of a search filter is to limit the entries that are groups based on objectClass. For example, a reasonable search filter for a default Active Directory installation is "(objectClass=group)". When combined with the default filter, the actual search executed would be "(&(cn={0})(objectClass=group))".

[davidak]

@blizzz yes. we also need this to associate users with groups.

here is a screenshot of the group support:

the members are there with thair e-mail-adress, not thair uid. in the users entry, the e-mail is in the attribute mail.

[blizzz]

I am sorry I did not manage to work on it yet, also due to busyness with the release. Now, I am on vacation, back on 2nd week of Jan. At least you know the issue is not forgotten ;) Have a good time and happy holidays.

[davidak]

@blizzz thanks for informing us. have a good vacation! :)

[blizzz]

fyi, i had another longer time-out, still on my backlog

[VeselaHouba]

Hello,
I just came over the same issue - zimbra group membership integration. If you have time to look at this it would be great. Or if it's possible to hard-code it somewhere (of course with all negative aspects which come with this aproach) please let us know and we can modify it ourselves in our local versions.

Thanks in advance

[blizzz]

Oh my, this comes up from the deep…

given the info above, we need to use zimbraMailForwardingAddress as associative attribute. Since it referes to email addresses, that match to a users mail attribute, we need custom handling of this. Because so far we can deal with DNs and uids.

For this we need to adjust the usersInGroup in the GROUP_LDAP class. The easy/hotfix approach would be to check whether zimbraMailForwardingAddress and add another if-block where we compile a filter that returns the users matching to the mail attribute so we can retrieve the DN and get the locally used name out of it.

The better approach would be to come up with a more generic approach that let's us easily define such associations on the fly. The basic pattern is we have an attribute that has a list of values that match against a users attribute. We have a special case where it matches to the DN (makes things easier) and we have a special case where we can match the value against a user-defined or detected attribute (what happens here with uid witch is checked against the login filter, which actually could cause issues when the login filter does not allow login against the matched attribute).

This can be consolidated into a class of it's own, custom associations could be then configured in the settings and instantiated on run time except of being hardcoded.

If someone is willng to do either of those (first solution as hotfix, preferred second solution as clean, maintainable and better testable solution) I would be happy to see Pull Requests so we can include this here :)

[VeselaHouba]

I'm actually using "zimbraMailDeliveryAddress" attribute as user ID in login filter, which should make it much simpler to map user as group member based on "zimbraMailForwardingAddress", because we don't have to resolve DN from user. But I have only very brief knowledge of owncloud structure and maybe I'm understanding the LDAP processing wrong.

For pull requests I don't think I can be any help, because I don't have developing experience and my code would be probably piece of garbage.

EDIT:
Seems like voytoo already figured hotfix out.
http://forum.owncloud.org/viewtopic.php?f=3&t=2825#p51692
Tested and working.

[mohamedhagag]

@blizzz anyway to get zimbra or custom Group-Member attribute ?

any solution ?

[blizzz]

@mohamedhagag nothing on the horizon, and also I do not have a zimbra instance. If there is something special that needs to be done about it, then a pull requested should be provided to get this introduced. I don't see me implementing this in a foreseeable future, sorry.

[PVince81]

Isn't that possibly with "dynamic group membership" ? I'm not an LDAP expert but I remember checking out this fix from @alexweirig #23344 and remembered seeing a "membership URL" attribute somewhere where one could specify an LDAP URL (or attribute?) to specify custom memberships ?

[alexweirig]

@PVince81 that's correct, but as far as I remember the code to support dynamic group membership was never added to the 8.2 release ... but maybe I just missed it.
Therefore I thought backporting it to 8.2 could be helpful.

[PVince81]

If the feature did not exist in 8.2, we don't backport features but only bugfixes.

[alexweirig]

@PVince81 OK no problem then

[PVince81]

Please reopen in the user_ldap app repo if the issue persists with 10.0.4 and the latest version of the user_ldap app from the marketplace.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.