Ldap – Openldap problems with adding attribute

ldapopenldap

I'm new to serverfault but I've alredy use google and serverfault searchs but cannot find answer to my problem. I need to add new attribute in ldap called permission and be able to set privilige levels.

Found several "ways to do" but non of them working. Stuck exacly like here add new attribute to ldap users and submit to ldap

Trying

dn: cn=core,cn=schema,cn=config
changetype: modify
add: olcAttributeTypes
olcAttributeTypes: <new value>

dn: cn=core,cn=schema,cn=config
changetype: modify
add: olcAttributeTypes
olcAttributeTypes: ( 1.2.3.4.5.6.7 
 NAME ( 'test' 'test' ) 
 DESC 'test' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
 SINGLE-VALUE )

But in the best way I get

modifying entry "cn=core,cn=schema,cn=config"
ldap_modify: No such object (32)
    matched DN: cn=schema,cn=config 

ldap_modify: Invalid syntax (21)
additional info: attributetypes: value #0 normalization failed

or

ldap_add: Undefined attribute type (17)
    additional info: add: attribute type undefined

And I'm out of ideas how to add this attribute :/

Since I must to do this I still trying (also create new server ) and getting following results
dn: cn=config
changetype: add
olcAttributeTypes: ( 2.5.4.66 NAME 'permission'
DESC 'RFC2256: For Supermicro user'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} )

ldap_add: Object class violation (65)
additional info: no objectClass attribute

So adding a objectClass
ldap_add: Object class violation (65)
additional info: object class 'person' requires attribute 'sn'

And now what ? Of course I want that permission be a part of person objectclass as MAY but still no idea how to modify objectclass
Result of
ldapsearch -H ldap://ldap.ogicom.net -x -s base -b "" +
base <> with scope baseObject
# filter: (objectclass=*)
# requesting: +
dn:
structuralObjectClass: OpenLDAProotDSE
configContext: cn=config
namingContexts: private
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 1.3.6.1.4.1.4203.1.10.1
supportedControl: 1.3.6.1.1.22
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.2.826.0.1.3344810.2.3
supportedControl: 1.3.6.1.1.13.2
supportedControl: 1.3.6.1.1.13.1
supportedControl: 1.3.6.1.1.12
supportedExtension: 1.3.6.1.4.1.1466.20037
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedExtension: 1.3.6.1.4.1.4203.1.11.3
supportedExtension: 1.3.6.1.1.8
supportedFeatures: 1.3.6.1.1.14
supportedFeatures: 1.3.6.1.4.1.4203.1.5.1
supportedFeatures: 1.3.6.1.4.1.4203.1.5.2
supportedFeatures: 1.3.6.1.4.1.4203.1.5.3
supportedFeatures: 1.3.6.1.4.1.4203.1.5.4
supportedFeatures: 1.3.6.1.4.1.4203.1.5.5
supportedLDAPVersion: 3
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: CRAM-MD5
entryDN:
subschemaSubentry: cn=Subschema

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Best Answer

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!