--On Wednesday, September 05, 2018 5:49 PM -0400 Dave Steiner
$ ldapsearch ... -H ldap://ldapmaster.rutgers.edu
createTimestamp modifyTimestamp entryCSN
postalAddress: Business And Science Bldg$227 Penn Street$Camden, NJ
$ ldapsearch ... -H ldap://ldapconsumer3.rutgers.edu
postalAddress createTimestamp modifyTimestamp entryCSN
postalAddress: BUSINESS AND SCIENCE BLDG$227 PENN STREET$CAMDEN, NJ
Those entries appear identical to me. I assume you believe they are not
identical because the case doesn't match. However, postalAddress uses
caseIgnore normalization rules, so they are in fact identical as far as
LDAP is concerned.
Also, given the entry was created in 2012 and there's no indication of when
the postalAddress attribute was modified, it's impossible to determine
when/how the divergence in capitalization occurred. You also don't provide
any information about the underlying database in use, which could be very
relevant, history wise.
So I'm trying to figure out why this happens (config issue, bug,
second, if I can't use the contextCSN to report that everything is fine,
what else can I do besides trying to compare ldif dumps.
So far, everything appears fine from a technical standpoint (the values
match per LDAP SYNTAX rules).
I would suggest the following if you would like the case to match:
That should correct the value on the providers and consumers to match case.
Packaged, certified, and supported LDAP solutions powered by OpenLDAP: