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: Paul Engle <>
  • To: Tom Zeller <>
  • Cc:
  • Subject: Re: [grouper-users] ldappcng & capitalization
  • Date: Tue, 27 Sep 2011 08:14:24 -0500

Thanks for looking into it. I agree that the ideal solution is a case-sensitivity flag per-attribute for maximum flexibility. As a short-term workaround, doing a delete before add will avoid hitting the error I'm seeing.

I tried your suggestion of manually removing the entire uniqueMember attribute (all values) from the group this morning. That seems to have bypassed the silly ldap server caching issue I was seeing when deleting a single value. After another sync, the value now has the expected capitalization. So, my specific issue is fixed.

As always, thanks for the help!


--On Monday, September 26, 2011 5:13 PM -0500 Tom Zeller <> wrote:

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

The ldap DN canonicalizer transforms




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 ?


On Mon, Sep 26, 2011 at 4:11 PM, Tom Zeller
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

 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:

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

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 D. Engle              |  Rice University
Sr. Systems Administrator  |  Information Technology - MS119
(713)348-4702              |  PO Box 1892

           |  Houston, TX 77252-1892

Paul D. Engle | Rice University
Sr. Systems Administrator | Information Technology - MS119
(713)348-4702 | PO Box 1892

| Houston, TX 77252-1892

Attachment: pgpuEglLXZWil.pgp
Description: PGP signature

Archive powered by MHonArc 2.6.16.

Top of Page