The error ldap_add: Constraint violation (19)
with the specific message structuralObjectClass: no user modification allowed
occurs because OpenLDAP is preventing modification of operational attributes during entry creation. The structuralObjectClass
is an operational attribute maintained by the server itself.
During LDAP entry creation, the server automatically generates certain operational attributes including:
structuralObjectClass
entryUUID
creatorsName
createTimestamp
entryCSN
modifiersName
modifyTimestamp
The error suggests your LDIF file is trying to explicitly set these operational attributes, which violates OpenLDAP's default constraints.
Remove all operational attributes from your LDIF file. Here's what a proper LDIF should look like:
dn: mail=john.merrell@example.org,ou=People,dc=example,dc=org
objectClass: top
objectClass: person
objectClass: inetOrgPerson
uid: John.Merrell
mail: john.merrell@example.org
cn: John D Merrell
userPassword: 2678u8yyy
givenName: John D
sn: Merrell
Although your ACL appears correct, you should verify the binding user's permissions with:
ldapwhoami -x -D "cn=drupal,ou=Apps,dc=example,dc=org" -W
Then check effective permissions for a test entry:
ldapsearch -Y EXTERNAL -H ldapi:/// -b "ou=People,dc=example,dc=org" "(uid=testuser)" aclRights
If you must include operational attributes (not recommended), you can modify your slapd configuration:
dn: cn=config
changetype: modify
add: olcAllows
olcAllows: bind_v2
Or adjust access controls specifically for operational attributes:
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {3}to attrs=structuralObjectClass by * none
- Use
ldapadd -v
for verbose output - Check server logs (
/var/log/slapd.log
) - Test with simple entries first
- Verify schema compliance with
slaptest
Here's a complete working example for user creation:
dn: uid=jdoe,ou=People,dc=example,dc=org
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: jdoe
cn: John Doe
sn: Doe
givenName: John
mail: jdoe@example.org
userPassword: {SSHA}hashedpasswordhere
The error message ldap_add: Constraint violation (19)
with the additional info structuralObjectClass: no user modification allowed
typically occurs when trying to add or modify entries in OpenLDAP where the structuralObjectClass
attribute is involved. This is a special operational attribute that's automatically managed by the LDAP server and cannot be manually modified.
In your case, the issue appears when importing LDIF files containing the structuralObjectClass
attribute. This attribute is system-generated and should never be included in your LDIF files. The error occurs because:
- The LDIF file includes operational attributes (
structuralObjectClass
,entryUUID
, etc.) - OpenLDAP enforces strict schema validation
- Even with manage permissions, some operational attributes cannot be modified
Remove all operational attributes from your LDIF file before import. Here's how your cleaned entry should look:
dn: mail=john.merrell@example.org,ou=People,dc=example,dc=org
objectClass: top
objectClass: person
objectClass: inetOrgPerson
uid: John.Merrell
mail: john.merrell@example.org
cn: John D Merrell
userPassword: 2678u8yyy
givenName: John D
sn: Merrell
For bulk operations, use this Perl script to clean your LDIF files:
#!/usr/bin/perl
use strict;
use warnings;
my @operational_attrs = qw(
structuralObjectClass
entryUUID
creatorsName
createTimestamp
entryCSN
modifiersName
modifyTimestamp
);
while (<>) {
next if grep { $_ } map { /^$_:/i } @operational_attrs;
print;
}
If you're exporting data from another LDAP server, use ldapsearch
with filters to exclude operational attributes:
ldapsearch -LLL -x -D "cn=admin,dc=example,dc=org" -W -b "ou=People,dc=example,dc=org" \
"(objectClass=inetOrgPerson)" \
dn objectClass uid mail cn userPassword givenName sn > clean_export.ldif
While your ACL configuration appears correct, verify it with:
ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config \
"(olcDatabase={1}hdb)" olcAccess
Ensure your import user has both manage
permission on the target DN and write
permission on the attributes you're modifying.
Enable OpenLDAP's debug logging temporarily to get more details:
sudo slapd -d 16383 -h "ldap:/// ldapi:///"
Then attempt your import in another terminal to see detailed logs about the constraint violation.