10

I'm having issues importing users with ldapadd and ldif files. The error I'm getting is:

ldap_add: Constraint violation (19)
additional info: structuralObjectClass: no user modification allowed

The users imported are all part of ou=People,dc=example,dc=org. The LDAP server already contains this base DN.

The /etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif file contains the following ACL entry:

olcAccess: {2}to dn.base="ou=People,dc=example,dc=org" attrs=children by gr
 oup.exact="cn=Manager,ou=Roles,dc=example,dc=org" manage

The ldif file is imported as follows:

ldapadd -f import.ldif -xv -D "cn=drupal,ou=Apps,dc=example,dc=org" -h localhost -W

The cn=drupal,ou=Apps[...] entry is a member of cn=Manager,ou=Roles,dc=example,dc=org so accordingly it should have sufficient permissions to write (since manage is the highest level of permissions available).

When I issue the ldapadd command the import fails on the very first ldif entry. The full command output is then:

add objectClass:
    top
    person
    inetOrgPerson
add uid:
    John.Merrell
add mail:
    john.merrell@example.org
add cn:
    John D Merrell
add structuralObjectClass:
    inetOrgPerson
add entryUUID:
    65236c42-09b7-1020-9318-9fca7c043dfc
add creatorsName:
    cn=drupal,ou=Apps,dc=bidnetwork,dc=org
add createTimestamp:
    20110503095643Z
add userPassword:
    2678u8yyy
add givenName:
    John D
add sn:
    Merrell
add entryCSN:
    20110629121956.880164Z#000000#000#000000
add modifiersName:
    cn=drupal,ou=Apps,dc=bidnetwork,dc=org
add modifyTimestamp:
    20110629121956Z
adding new entry "mail=john.merrell@example.org,ou=People,dc=example,dc=org"
ldap_add: Constraint violation (19)
    additional info: structuralObjectClass: no user modification allowed

I've tested importing users that did or did not exist on the LDAP and I get the aforementioned error in either case.

Can someone explain the origin of the problem and how it may be circumvented?

Max
  • 3,373
  • 15
  • 51
  • 71

5 Answers5

13

How did you generate those LDIF files? structuralObjectClass is one of the internal values in OpenLDAP and user - even administrator - cannot normally modify those.

Either remove those structuralObjectClass lines from your LDIF or import the entries back with slapadd (I bet you generated the LDIF files with slapcat).

Janne Pikkarainen
  • 31,454
  • 4
  • 56
  • 78
  • I did generate my LDIF files with `slapcat`. If there is a better way please advise. Following your advise I had to remove the following fields for the import to work: `structuralObjectClass`, `entryUUID`, `creatorsName`, `createTimestamp`, `entryCSN`, `modifiersName`, `modifyTimestamp`. – Max Jul 14 '11 at 10:05
  • 3
    You should use `slapadd` if you need to restore an LDIF file generated with `slapcat`. The `slapadd` man page says: "The output of slapcat is intended to be used as input to slapadd(8). The output of slapcat cannot generally be used as input to ldapadd(1) or other LDAP clients with‐ out first editing the output. This editing would normally include reordering the records into superior first order and removing no-user-modification operational attributes." – Janne Pikkarainen Jul 14 '11 at 10:14
  • Oh - you can generate an `ldapadd` compatible LDIF with `ldapsearch -L [your_other_options] >your_data.ldif` – Janne Pikkarainen Jul 14 '11 at 10:16
  • Indeed, that's what I'm going to be using. – Max Jul 14 '11 at 10:25
2

If you are using tools like http://phpldapadmin.sourceforge.net/wiki/index.php/Main_Page to export the data, don't choose Include system attributes in the web UI:

enter image description here

jsvisa
  • 121
  • 2
1

A script is provided here. Usage: bash SCRIPTNAME a.ldif. Remember to backup the ldif beforehand.

#!/bin/bash

for i in structuralObjectClass entryUUID creatorsName createTimestamp entryCSN modifiersName modifyTimestamp contextCSN
do
  sed -i /$i/d $1
done
silencej
  • 111
  • 3
  • 2
    Seems to be the same as `grep -Ev (structuralObjectClass|entryUUID|creatorsName|createTimestamp|entryCSN|modifiersName|modifyTimestamp|contextCSN)`. – Andrew Schulman Mar 05 '21 at 11:35
  • 1
    Yes, better: `grep -Ev "(structuralObjectClass|entryUUID|creatorsName|createTimestamp|entryCSN|modifiersName|modifyTimestamp|contextCSN)" $i > $i.new.ldif` – silencej Mar 06 '21 at 04:49
1

you need delete the following lines in the ldif file:

structuralObjectClass: 
entryUUID: 
creatorsName: 
createTimestamp: 
entryCSN: 
modifiersName: 
modifyTimestamp:
Jakuje
  • 9,145
  • 2
  • 40
  • 44
user335858
  • 21
  • 1
  • 2
    Full answers are preferred here. A 'try this' answer without explanation isn't really useful on a question several years old. – richardb Feb 05 '16 at 11:04
0

Below is not solution to question, but utility code to remove structural elements. Sample python code remove structural elements. Use out.ldif

structural_elements = ["structuralObjectClass","entryUUID", "creatorsName","createTimestamp","entryCSN", "modifiersName","modifyTimestamp"]
    with open("ldap_data_out.ldif","w+") as outfile:
        with open("ldap_data_in.ldif", "r") as infile:
            lines = infile.readlines()
            for line in lines:
                print line.split(":")[0]
                if line.split(":")[0] in structural_elements:
                    print "ignoring ,", line
                else:
                    outfile.write(line)
sreemanth pulagam
  • 101
  • 1