--On Wednesday, September 05, 2018 5:49 PM -0400 Dave Steiner steiner@rutgers.edu wrote:
Hi Dave,
$ ldapsearch ... -H ldap://ldapmaster.rutgers.edu uid=XXXX postalAddress createTimestamp modifyTimestamp entryCSN dn: uid=XXXX,ou=People,dc=rutgers,dc=edu createTimestamp: 20121220100700Z postalAddress: Business And Science Bldg$227 Penn Street$Camden, NJ 081021656 entryCSN: 20180505002024.083133Z#000000#001#000000 modifyTimestamp: 20180505002024Z
$ ldapsearch ... -H ldap://ldapconsumer3.rutgers.edu uid=XXXX postalAddress createTimestamp modifyTimestamp entryCSN dn: uid=XXXX,ou=People,dc=rutgers,dc=edu createTimestamp: 20121220100700Z postalAddress: BUSINESS AND SCIENCE BLDG$227 PENN STREET$CAMDEN, NJ 081021656 entryCSN: 20180505002024.083133Z#000000#001#000000 modifyTimestamp: 20180505002024Z
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, ???) and 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:
dn: ... changetype: modify replace: postalAddress postalAddress: ...
That should correct the value on the providers and consumers to match case.
Warm regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com