The root cause is that the ObjectClass for manipulating data in LDAP is the same as in the original LDAP when adding, deleting, or altering it.
First, inconsistent ObjectClass type causes the reason for the addition failure
Entry, which is a directory managed object, is the most basic particle in LDAP. Generally, the addition, deletion, change, and retrieval of LDAP are based on entries. Each entry can have many attributes. An ObjectClass (ObjectClass) is a collection of properties.
Object classes make it easy to define entry types. Each entry can inherit directly from multiple object classes, thus inheriting various properties. If two object classes have the same property, only one property will be retained after the entry is inherited. The object class also specifies which attributes are essential information and Must or Required: which attributes are extensibility information and May or Optional.
Each Entry in the LDAP directory tree must belong to its own conditional objectClass, objectClass, then define its Entry attributes and corresponding values, and objectClass corresponds to Java as class. In Java, Class can be roughly divided into Abstract and Concrete, and only concrete Class can generate instance. In LDAP, objectClass is divided into three classes: Abstract, Structural, and Auxiliary. The specific definition is as follows:
Abstract object classes are only intended to be extended by other object classes. An entry must not contain any abstract classes unless it also contains a structure or helper class from which Dervies derive an abstract class (that is, including non-abstract object classes, an inheritance chain of abstract classes). All entries must contain at least a “top” abstract object class and their structural classes in the inheritance chain. They may or may not contain other abstract classes in the inheritance chain in the structural class or in any of their helper classes. **Structural: ** Structured object classes are designed to define the key that an item represents. Each entry must contain a structured object class chain, and the root of the chain must ultimately be a “Top” abstract object class. Changes to the entry’s structural object class are not allowed. **Auxiliary: **Auxiliary object classes are intended to define the additional qualities of items. An entry may contain zero or more helper classes, and the set of helper classes associated with an entry may change over time.
The object classes themselves can inherit from each other, so the root of the object class is the top abstract object class. Take access control devices as an example, their inheritance relationship is shown in the figure below:

DAP entry attributes can be added depending on whether the objectClass inherited by the entry contains this attribute. ObjectClass has an inheritance relationship, that is, the attributes added to the entry ultimately depend on the collection of all objectclasses that it inherits.
The objectClass and attributes are specified by the schema file, which is stored in the /etc/openldap/schema directory. The schema file specifies the composition of the objectClass and the corresponding relationships between attributes and values in the directory tree. You can generate the objectClass by defining a schema file to generate the required attributes. The relationships determined before the ObjectClass, AttributeType and Syntax are shown in the figure below:

so if the added property is not in the scope of objectClass, the directory server is not allowed to add the property. To do so, you must add the schema file to produce the properties corresponding to the objectClass.