Grouper Users - Open Discussion List

[Tom Barton <>]

If I recall correctly, the DSA implements matching rules as determined
by its schema. Ie, it's up to the DSA to enforce case sensitivity or
case insensitivity on an attribute-by-attribute basis. In other words, I
wonder if your LDAP server is treating ou=People as distinct from
ou=people. I also wonder if other LDAP clients in your environment will
have difficulty with this entry, eg, if a search for uid=foo based in
ou=People,dc=rice,dc=edu will return the entry for
uid=foo,ou=people,dc=rice,dc=edu.

TomB (not TomZ!)

On 9/26/2011 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