structuralObjectClass issues between master and slave servers

[Peter Traub <peter@vindicia.com>]

Hello,

I'm encountering an odd issue, whereby if I add an LDAP entry to our 
master LDAP server and the entry contains an attribute specifying which 
objectClass is the structuralObjectClass, then the server won't add it, 
and exits with an error. Yet the exact opposite happens when adding the 
test entry to any slave or standalone server. The LDIF test file is as 
follows:

dn: cn=bobdobbs,ou=People,dc=test,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: bobdobbs
sn: dobbs
structuralObjectClass: inetOrgPerson

When I add this using ldapadd on the master LDAP server, it exits with 
the following error:

adding new entry "cn=bobdobbs,ou=People,dc=test,dc=com"
ldapadd: update failed: cn=bobdobbs,ou=People,dc=test,dc=com
ldap_add: Constraint violation (19)
       additional info: structuralObjectClass: no user modification allowed

When I remove the 'structuralObjectClass' attribute, it adds just fine. 
When this file is added directly to any of the slave servers, or to my 
personal workstation server, which is a standalone that does not slave 
or replicate, it adds fine WITH the 'structuralObjectClass' attribute 
defined. However, if I remove that line, it exits with the following error:

adding new entry "cn=bobdobbs,ou=People,dc=test,dc=com"
ldapadd: update failed: cn=bobdobbs,ou=People,dc=test,dc=com
ldap_add: Internal (implementation specific) error (80)
       additional info: no structuralObjectClass operational attribute

So basically, the master server fails if that line is present, and slave 
or standalone servers fail if that line is not present. All are running 
openldap 2.1.25 on RH9. The slave slapd.conf files are identical to the 
master slapd.conf file minus the replication directives. Any insight 
would be greatly appreciated. Many thanks.

Peter