Add another objectClass to groups.

[zerocrash]

Hi. I'm trying to modify or add in some place of the code to add another objectClass to default group creation.
I want to add the organizationalPerson objectClass to the groups created with the zentyal interface.
I need the attributes of this class to store more information about the group.

I have already tried to add the objectClass in line 137 of /usr/share/zentyal-samba/samba-ldap and don't work.
In line 99 of the same file works but only for the Mandatory Groups. Creating a group using zentyal interface after that don't append this objectClass to the Groups.

Anyone can help or give me a tip to make it work?

[christian]

 
Extract from RFC4519:

Code: [Select]

The 'organizationalPerson' object class is the basis of an entry that
   represents a person in relation to an organization.
   (Source: X.521 [X.521])

      ( 2.5.6.7 NAME 'organizationalPerson'
         SUP person
         STRUCTURAL
         MAY ( title $ x121Address $ registeredAddress $
               destinationIndicator $ preferredDeliveryMethod $
               telexNumber $ teletexTerminalIdentifier $
               telephoneNumber $ internationalISDNNumber $
               facsimileTelephoneNumber $ street $ postOfficeBox $
               postalCode $ postalAddress $ physicalDeliveryOfficeName $
               ou $ st $ l ) )

Which means, basically, that such objectclass is supposed to be used for....a person 
Therefore my question, as I'm curious  :
what are the attributes you want to use, from this objectclass, to qualify groups

This said, assuming you still want to add THIS objectclass to each and every group, the easiest, although I don't know yet where in Zentyal code this has to be done, is to tweak Zentyal so that objectclass is added at the time group is created. (look at SambaLdapUser.pm)

[zerocrash]

I want to store information to the groups as if they are a division that have atributtes like adress, phone number, country, state, email and others usefull informations.
I really liked the way of zentyal interface for maneging groups to PDC, would be more productive having access to this kind of information directly from ldap directory.

Thanks for the tip. I will take a look on that file to see what can be done without breaking the future updates. What I find I will post here to share who needs some kind of more information about users and groups.

[christian]

- mail address: you can add it already, using mail alias feature. It will distribute received mails to each group member
- phone:    what do you expect? to have received calls triggering ring on each member's phone device    I'm joking, kind of but what I want to express is that phone number can hardly be group attribute, in real life.
Same for location: having group of people sharing same location does make sense but this is something qualifying members, not group itself.

Anyway, this is philosophical debate more than a technical one. You can obviously do it.

[zerocrash]

I really understand what are you saying. But the structure that i'm building for example have the TI department located at building n1, that have his adress. Have another department, sales for example. Located at building n2. A can put the office information on each member detais, as phone too. But i will repeat this information and change in user everytime he changes from a department. If i change de department address I will need to change each member eather. I think that would be better store the information on his primary group, the department that he really will be at the moment.

Both strategies works. The solution wich you suggested would be easier because already have the attributes on user schema, but for manegering would be a lot more harder to male changes. Understand why I'm oppting to add attributes to group?

[christian]

Yes, I do understand but I can also tell you that this is not the way LDAP is supposed to be used 
Let me try to explain this to you.
To make a long explanation short, you are going to use LDAP like if it was RDBM, which is not (whatever backend behind).

I hope you will understand better my point with real life example:
say you have internal application (e.g. Tomcat based application) for which you want different kind of access depending on user profile.
You want people from purchasing department being able to access some features while you want people from given location able to access restricted information dedicated to this location.
- You can do it managing group (more or less like what you describe): this is known as explicit profiling because you do have to manage group membership to get accurate result. Group doesn't need to store any information like "purchasing department" because you will have to explicitly code in you application "access to THIS feature is authorized to THIS group"
- another way to achieve similar result is to implement "implicit profiling": you store and manage, for each entry, attribute describing department and location. Then in your application, you only implement one simple LDAP filter based on "department=purchasing" or "location=HQ". No need to maintain group 
When user move to another location or to another organization, changing his/her attribute is enough to impact all applications implementing implicit profiling.
This is what real Identity Management provides 

Back to your example, as there is no "join" request with LDAP protocol, you can prompt user for authentication and check his group membership in same LDAP request while this is straightforward if you use implicit profiling thank to LDAP filter.

This being said, Zentyal doesn't aim at proving this kind of stuff    Zentyal LDAP backend targets Zentyal modules. It can be obviously used for authentication from external applications but with no IDM feature in mind.