Linux – LDAP + Zimbra authentication

cn=admin,dc=domain,dc=com is the administrator for your main database, but probably not for the OLC. By default, connecting as the root user over ldapi:// allows you to manage the configuration.

As root: ldapsearch -Y EXTERNAL -H ldapi:// -b cn=config

Alright, let's clean things up a bit:

1. ldapmodify can both create and modify nodes within your LDAP tree. This behaviour is identified by the parameter changetype. So if you use changetype: add you try to add a new node. Obviously you would need to give that new node an object class, therefore you got the error ldap_add: Object class violation (65) additional info: no objectClass attribute (still this operation would have been unsuccessful because the dn cn=config already exists).
2. You first of all need to find out, which node holds the object class (for example my node cn={0}core,cn=schema,cn=config holds the object class 'person', whereas 'inetOrgPerson' lies in cn={3}inetorgperson,cn=schema,cn=config). The curly brackets in front of the first dn attribute (in this case 'core' or 'inetorgperson') are set by OpenLDAP in order to determine the order in which the nodes are loaded. BTW: that's the reason why you received ldap_modify: No such object (32) when looking for cn=core,... - you missed the brackets :)
3. Object classes and attribute types are stored in nodes with the object class of olcSchemaConfig as attributes with the attribute type of olcObjectClasses or olcAttributeTypes respectively. Just look at your schemes (e.g. ldapsearch -xLLLWD cn=admin,cn=config -b cn=schema,cn=config -s one or ldapsearch -xLLLWD cn=admin,cn=config -b cn={0}core,cn=schema,cn=config -s base) and you get an idea what this looks like. So be clear what you want to do: You are trying to modify a node in the form that you replace one of the olcObjectClasses' attributes (in the form that you redefine it including your attribute type. If the attribute type has not been defined before, you would need to add it as another attribute of type olcAttributeTypes either in the same node or another olcSchemaConfig). You would do this with

dn: cn={0}core,cn=schema,cn=config changetype: modify replace: olcObjectClasses olcObjectClasses: {4}( 2.5.6.6 NAME 'person'...

HOWEVER:

You don't want to do this. Seriously, don't. It is never a good idea to mess with the preexisting classes and attributes.

Instead, there are better options, which are way cleaner and should be chosen instead:

1. The quick way: When creating the next user node, you could use a structural object class (e.g. 'person') and add the auxiliary object class 'extensibleObject' to the mix; this let's you add attributes of any existing attribute type.
2. The right way: You can easily define your own object classes. What you would want to do in this way is either create your own structural class (which can inherit from any other object class and be extended by your attribute) which you would then use for your node as the only object class, or you could also create an auxiliary object class which holds the attribute and which would be used as an additional object class. If you choose this way, please make sure that you use a namespace (the numbers in the definition, like '2.5.4.66') which will not conflict with the existing classes and/or attributes. This is what this would look like:

ldapadd -xWD cn=admin,cn=config dn: cn=<schemaName>,cn=schema,cn=config objectClass: olcSchemaConfig cn: <schemaName> olcAttributeTypes: ( <your namespace>.01.01 NAME <attributeTypeName> DESC <description> EQUALITY <equalitySettings> SYNTAX <syntaxSettings> ) olcObjectClasses: ( <your namespace>.02.01 NAME <objectClassName> DESC <description> AUXILIARY MUST <attributeTypeName> )

Learning how to handle cn=config might be a little confusing at first, but once you understand the concepts behind it, you realize it is way cooler than the way it was before. It's definitely worth learning it.

Have fun!