Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] ldappcng & capitalization

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] ldappcng & capitalization

Chronological Thread 
  • From: Tom Barton <>
  • To:
  • Subject: Re: [grouper-users] ldappcng & capitalization
  • Date: Mon, 26 Sep 2011 17:27:33 -0500

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

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
>> 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

Archive powered by MHonArc 2.6.16.

Top of Page