Grouper Developers Forum

[Tom Zeller <>]

In summary : when provisioning memberships, AttributeModifier uses the number of values, not the values themselves, of the currently provisioned attribute to determine whether or not to replace or add/delete values - really not a good idea.

To highlight this issue of ldappc incorrectly provisioning memberships after an incomplete run under 'special' circumstances, I created two groups, each with one and the same member:

groupA

members: subjectA

groupB

members: subjectA

I then provisioned via ldappc :

cn=subjectA

isMemberOf : groupA

isMemberOf : groupB

I then deleted via ldap one of the isMemberOf values :

cn=subjectA

isMemberOf : groupA

After provisioning via ldappc -memberships :

cn=subjectA

isMemberOf : groupB

and again after ldappc -memberships

cn=subjectA

isMemberOf : groupA

ad nauseum.

When provisioning the group whose membership was deleted out-of-band, ldappc will replace instead of adding values. When creating the AttributeModifier, ldappc searches using

(&(uid=*)(isMemberOf=groupB)(objectClass=eduMember))

which will return 0 in this case. Since the AttributeModifier is initialized with 0 entries, AttributeModifier.deletes is empty and AttributeModifier.deletesCnt = 0, and AttributeModifier.adds contains 1 item, cn=subjectA. Then, since 'if (deletes.size == deletesCnt)' evaluates to true in AttributeModifier.getModifications(), attribute values are replaced !

On Thu, Feb 19, 2009 at 10:59 AM, Tom Barton <> wrote:

Tom,

I'm not sure I understand the difference between the LDAP entry needing 2 memberships added because of a previous Ldappc crash, or because the corresponding Subject was added to 2 new groups since the previous Ldappc cycle. Can you explain?

Thanks,
Tom

Tom Zeller wrote:

At first I thought there was an error in the ldappc code, but that's not really the case. The 'bug' is that ldappc assumes it is the only-cook-in-the-kitchen, and that all-recipes-complete-successfully.

Perhaps a solution is to provide a command line option which instructs ldappc whether or not to always add and delete attribute values, instead of trying to optimize using replace, e.g. --donotreplace.

So, someone could always use --donotreplace, or only after ldappc fails to complete successfully.

Thoughts?

On Wed, Feb 18, 2009 at 5:15 AM, Arnaud Deman < <mailto:>> wrote:

   Hi Tom,

   I have made a temporary fix by replacing REPLACE_ATTRIBUTE with
   ADD_ATTRIBUTE in the part of  AttributeModifier.getModifications()
   below.
   This seems to work in our case but it's not clean as I don't know if
   it will not introduce a bug elsewhere.

        if (adds.size() > 0)
               {
                   //
                   // Replace the current value(s) with the additions
                   //
                   modItem = new ModificationItem(DirContext.ADD_ATTRIBUTE,
                           makeAttribute(adds));
               }

   Arnaud.

   Tom Zeller a écrit :

   Looks like a bug indeed in AttributeModifier. I don't have a fix
   in mind yet, we'll see.

   https://bugs.internet2.edu/jira/browse/GRP-227

   2009/2/17 Arnaud Deman <

   <mailto:>>

       Hi everyone,

       I have got a problem with ldappc when restarting it after a
       crash, when the people branch is not completely provisionned.
       When I restart ldappc, if a person has only a part of its
       groups in the attribute isMemberOf, then there is a swap
       between these groups and the missing ones.

       For instance, the user F08001ph is member of the  groups :
            is a member of : Groupesco:sarapis:local:sarapis_GIP_RECIA
            is an indirect member of :
       Groupesco:sarapis:local:sarapis_CLAUDE DE FRANCE_0410017W
            is an indirect member of :
       Groupesco:sarapis:local:sarapis_LEONARD DE VINCI_0370001A
            is a member of : Groupesco:sarapis:central

       The content of the attribute isMemeberOf, for the ldap entry
       before running ldappc is:
            isMemberOf: esco:sarapis:local:sarapis_LEONARD DE
       VINCI_0370001A
            isMemberOf: esco:sarapis:local:sarapis_GIP_RECIA

       And the result of the run of ldappc is:
           isMemberOf: esco:sarapis:central
           isMemberOf: esco:sarapis:local:sarapis_CLAUDE DE
       FRANCE_0410017W

       The content of the temporary file used by the process is :
           uid=F08001ph,ou=people,dc=esco-centre,dc=fr     2              esco:sarapis:central
           uid=F08001ph,ou=people,dc=esco-centre,dc=fr     2              esco:sarapis:local:sarapis_CLAUDE DE FRANCE_0410017W

       I think the "2" which mean "Replace Attribute" in this file
       should be "1" (Add attribute). I would say it is related to
       the method AttributeModifier.getModifications() but I can't go
       further because I dont understand very well the method. In
       fact, I even don't understand when a Replace operation should
       be used as we are working on multi-valued attributes.

       I have done this test with ldappc in the grouper 1.4.1 package
       but I will have also to fixe it for the 1.2.1 version as we
       use it in production.



       Thanks for your help,
       Arnaud.










       --
       Arnaud Deman
       GIP RECIA
       Parc d'activités les Aulnaies
       151 rue de la Juine - 45160 OLIVET
       Tel : 02 38 42 14 63

       <mailto:>

   --
   Arnaud Deman
   GIP RECIA
   Parc d'activités les Aulnaies
   151 rue de la Juine - 45160 OLIVET

   Tel : 02 38 42 14 63     <mailto:>