Losing last two attributes when importing entry of type objectclass: inetOrgPerson from OpenLDAP 1.2.7+ into Netscape Communicator 4.7.

[Yash Khemani <yash@khemani.com>]

Hello,

I think my subject line covers the issue pretty well for the convenience
of those doing a search on this matter later :-).

Here is more information about the issue.

We have tried OpenLDAP 1.2.8 on Solaris 7 and OpenLDAP 1.2.7 on Linux
2.2.12-20 (RH61).  The same results are achieved with both servers

The LDAP client is Netscape Communicator 4.7 on Linux and Windows NT.

The test data is loaded from LDIF files into the LDAP server.  Those LDIF
files are presented below:

-- start init.ldif - loaded first --
dn: dc=khemani, dc=com
dc: khemani
o: Khemani Enterprises
objectclass: organization
objectclass: dcObject

dn: cn=root, dc=khemani, dc=com
cn: root
sn: root
objectclass: person
-- end init.ldif

-- start addressbook_base.ldif - loaded second --
dn: ou=People,dc=khemani,dc=com
ou: People
objectClass: top
objectClass: organizationalUnit
-- end base.ldif --

-- start addressbook.ldif -- loaded last --
dn: userid=khemani,ou=People,dc=khemani,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
ou: People
cn: Yash L. Khemani
givenname: Yash L.
sn: Khemani
o: Amazing Media, Inc.
businesscategory: Infrastructure
title: Systems Administrator
userid: khemani
mail: nospam@nospam.com
telephonenumber: +1.555.555.5555
facsimiletelephonenumber: +1.555.555.5555
mobile: +1.555.555.5555
homephone: +1.555.555.5555
postalAddress: 555 Main Street
l: Anytown
st: DC
postalCode: 55555
c: US
pager: n/a
labeledURI: http://www.mainstreet.com/ Me

-- end addressbook.ldif --

The Netscape client is configured to interact appropriately with OpenLDAP
as per a recommendation posted on this openldap-general list:

http://www.openldap.org/lists/openldap-general/199902/msg00098.html

This did not seem to make a difference with this situation, however.  The
issue this message addressed was with regard to server timeouts.  The
configuration details are mentioned below.

-- being relevant portion of liprefs.js on linux client --
user_pref("ldap_2.servers.qaz.csid", "UTF-8");
user_pref("ldap_2.servers.qaz.description", "qaz");
user_pref("ldap_2.servers.qaz.filename", "qaz.na2");
user_pref("ldap_2.servers.qaz.position", 2);
user_pref("ldap_2.servers.qaz.searchBase", "dc=khemani,dc=com");
user_pref("ldap_2.servers.qaz.serverName", "10.0.0.2");
user_pref("ldap_2.servers.qaz.auth.enabled", false);
user_pref("ldap_2.servers.qaz.auth.savePassword", false);
user_pref("ldap_2.servers.qaz.autoComplete.enabled", true);
user_pref("ldap_2.servers.qaz.autoComplete.filter", "cn=%1 %2");
user_pref("ldap_2.servers.qaz.efficientWildcards", false);
user_pref("ldap_2.servers.qaz.filter1.repeatFilterForWords", true);
user_pref("ldap_2.servers.qaz.filter1.string", "(|(cn=%s)(sn=%s))");
user_pref("ldap_2.servers.qaz.replication.enabled", false);
user_pref("ldap_2.servers.qaz.replication.lastChangeNumber", 0);
user_pref("ldap_2.servers.qaz.vlvDisabled", true);
-- end relevant portion of liprefs.js --


The data is successfully loaded into the LDAP server.  All of the data is
viewable from the Netscape Addressbook client when it examines the ldap
server.  However, if you import a record into the local addressbook, the
last two attributes of the record are not imported.  This happens
regardless of the ordering of the attributes in the original LDIF file.
So for example, if attributes (l) and (st) were last, they would not be
imported.  Or if (postalAddress) and (pager) were last, they would not be
imported.

One temporary solution is to pad the LDIF file with two non-essential
attributes at the end.  But this clearly isn't a long term solution.

In addition, it appears that the country (c) is never imported into the
local addressbook.  Is this because the base is dc=khemani,dc=com vs.
something like o=Amazing Media Inc.,c=US ?  If you do not define country
in your base, is there some other way to include country when you import
into Netscape?  Or is the issue strictly one with Netscape's addressbook
client?

Interestingly, the problems I describe above do not appear with Outlook
Express 5.00.2919.6600 on Windows NT.  The country value is picked up;
the last two attributes are also incorporated.  I am curious if the issue
is Netscape specific, and what can be done to address it.

Hope I've covered all of the details.  Any guidance would be much
appreciated.

Thanks,
Yash