0

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
Community
  • 1
dawidos160
  • 1
  • 1
  • 1
  • 5
  • Can you check is `core` schema exists: `ldapsearch --hostname --port --baseDN "cn=schema,cn=config" --searchScope base "(objectclass=*)"` and post it? – Slipeer Nov 17 '16 at 13:32
  • @Slipeer After doing it I've got ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: no secret in database – dawidos160 Nov 17 '16 at 14:00
  • Of course it was necessary to execute a command with authorization `ldapsearch --hostname --port -x -D -W --baseDN "cn=schema,cn=config" --searchScope base "(objectclass=*)"` – Slipeer Nov 17 '16 at 14:03
  • Ehh my mistake - I did not think that user may be different that admin ;) # extended LDIF # # LDAPv3 # base with scope baseObject # filter: cn=schema,cn=config # requesting: (objectclass=*) # # search result search: 2 result: 34 Invalid DN syntax text: invalid DN # numResponses: 1 – dawidos160 Nov 17 '16 at 14:15
  • Strange result. Try other query: `ldapsearch -x -h -b "" -s base \* +` note - the authorization is not needed. This request will give data about available baseDN. – Slipeer Nov 17 '16 at 14:23
  • # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: * + # # dn: objectClass: top objectClass: OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: dc=removed,dc=removed subschemaSubentry: cn=Subschema Also additional question - how to greyed text? Maybe I misunderstanding help but it wrotes about 4 spaces to create an escaped 
      block but this dont work
     – dawidos160 Nov 17 '16 at 14:31
  • Ehh and another mistake in cli - the correct result of your first command # extended LDIF # # LDAPv3 # base with scope baseObject # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 32 No such object – dawidos160 Nov 17 '16 at 15:14
  • I edited the original post – dawidos160 Nov 22 '16 at 13:41

2 Answers2

2

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!

randomnickname
  • 513
  • 2
  • 11
  • If you want to learn the concepts, I suggest you check out Zytrax' guide at http://zytrax.com/books/ldap/ – randomnickname Dec 01 '16 at 14:38
  • Thansk for instruction but still got the same error - DN not available H=4 and I don't know how to handle with this and without this attribute cannot login to Supermicro IPMI by ldap :/ – dawidos160 Dec 19 '16 at 12:28
-1

Well it not my idea but I've got an aswer. I do it maunally

· Edit config file,

$ vim /etc/ldap/schema/core.schema

· Add attribute type,

attributetype ( 2.5.4.66 NAME 'permission'

        DESC 'my desc '

        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} )

· add 'permission' to objectclass 'person'

objectclass ( 2.5.6.6 NAME 'person'

        DESC 'RFC2256: a person'

        SUP top STRUCTURAL

        MUST ( sn $ cn )

        MAY ( userPassword $ telephoneNumber $ seeAlso $ description $ permission ) )

· Create core.conf file

$ vim /etc/ldap/core.conf

· Add below line to core.conf

include /etc/ldap/schema/core.schema

· Remove or backup old /etc/ldap/slapd.d/cn=config/cn=schema/cn={0}core.ldif file

$ rm /etc/ldap/slapd.d/cn=config/cn=schema/cn={0}core.ldif

· Generate new /etc/ldap/slapd.d/cn=config/cn=sch 

$ slaptest -f /etc/ldap/core.conf -F /etc/ldap/slapd.d
dawidos160
  • 1
  • 1
  • 1
  • 5