Grouper Users - Open Discussion List

[Tom Zeller <>]

Looks like all I can offer you right now is a bug report.

The ldap DN canonicalizer transforms

 cn=foo,DC=Edu

to

 cn=foo,dc=Edu

So this doesn't help you.

As far as modification order, looks like I punted because I wasn't sure

 public List<Modification> getReferenceModification() throws Spml2Exception {
    // TODO add or delete first ?

Perhaps delete-first is preferable over add-first.

Finally, there should be a case-sensitivity flag on attributes for
comparison, but case-sensitivity was not part of the spml spec so I
left it out for the time being.

Can you delete the uniqueMember attribute and then sync ?

TomZ

On Mon, Sep 26, 2011 at 4:11 PM, Tom Zeller 
<>
 wrote:
> I took care when comparing DNs to use a canonical representation to
> avoid issues with case. I could have made a mistake.
>
> I think I have a junit test for this, let me look ...
>
> On Mon, Sep 26, 2011 at 4:03 PM, Paul Engle 
> <>
>  wrote:
>>
>> Greetings,
>>  I'm running into a vexing problem with ldappcng that I think may be a bug.
>> I'm running version 1.6.3 & provisioning into a FedoraDS server. Groups are
>> groupOfUniqueNames and the DN of group members are stored as uniqueMember
>> values. The problem is that at some point when the provisioner was offline,
>> a person was manually entered into LDAP as a quick workaround. The DN 
>> string
>> was entered as all lowercase: uid=foo,ou=people,dc=rice,dc=edu.
>>
>> Ever since, when the group tries to sync via ldappcng, it fails. In the 
>> LDAP
>> server logs, it's throwing an attribute exists error for the group object.
>>
>> Running the ldappcng as a one-off diff for that group shows that it wants 
>> to
>> do an add of "uid=foo,ou=People,dc=rice,dc=edu" and a delete of
>> "uid=foo,ou=people,dc=rice,dc=edu" (!)
>>
>> I can manually delete that uniqueMember value, and the sync works fine. 
>> BUT,
>> the ldap server is doing some funky caching so the value that actually gets
>> stored is still all lowercase. Grr.
>>
>> I wouldn't have expected a simple case mismatch to have triggered a
>> modification event. If that's not a bug, then I would petition that the
>> modification order be deletes before adds to avoid hitting the attribute
>> exists error on the ldap server.
>>
>> I'm going to fight with the ldap server some more to see if I can get it to
>> forget the lowercase value. Even manually deleteting it and re-adding it
>> with uppercase doesn't seem to work, so I know the caching issue is not on
>> the grouper side. I think the next step is to just delete the whole group
>> object and sync it fresh. Any other suggestions are welcome.
>>
>>
>>  -paul
>>
>> --
>> Paul D. Engle              |  Rice University
>> Sr. Systems Administrator  |  Information Technology - MS119
>> (713)348-4702              |  PO Box 1892
>> 
>>             |  Houston, TX 77252-1892
>