1

I have an LDAP server running on OpenBSD 7.1 using the native ldapd implementation. I've created a basic DIT, and when attempting to add a user, I get:

# ldapadd -vv -H ldaps://hypnos.spookyinternet.com/ -f /tmp/users.ldif -D cn=admin,dc=spookyinternet,dc=com -w 'correct horse battery staple'
ldap_initialize( ldaps://hypnos.spookyinternet.com:636/??base )
add objectClass:
  inetOrgPerson
add uid:
  jessejames
adding new entry "uid=jessejames,ou=users,ou=accounts,ou=spookyinternet,dc=spookyinternet,dc=com"
ldap_add: Object class violation (65)

where /tmp/users.ldif is:

dn: uid=jessejames,ou=users,ou=accounts,ou=spookyinternet,dc=spookyinternet,dc=com
objectClass: inetOrgPerson
uid: jessejames

I've looked at the inetOrgPerson schema, and can't see what part of the class I'm violating, especially since none of the fields are a MUST:

objectclass ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson'
  SUP organizationalPerson
  STRUCTURAL
  MAY ( audio $ businessCategory $ carLicense $ departmentNumber $
    displayName $ employeeNumber $ employeeType $ givenName $
    homePhone $ homePostalAddress $ initials $ jpegPhoto $
    labeledURI $ mail $ manager $ mobile $ o $ pager $
    roomNumber $ secretary $ uid $ x500uniqueIdentifier $
    preferredLanguage $ userSMIMECertificate $ userPKCS12 ) )

All instances I could find online of ldap_add: Object class violation (65) all came with an accompanying message to indicate what the violation was, but unfortunately I haven't been able to get anything more specific from my client (from the openldap-client package).

1 Answer 1

2

The inetOrgPerson objectClass supplements organizationalPerson, which supplements person, which in turn supplements top. This means, it inherits all the attributes that defined in those objectClasses. Some of these attributes are declared as MUST, and you need to specify them all. See RFC2798 (also look into RFC4519)

For instance, it inherits from person: MUST (sn $ cn), and from top: MUST ( objectClass ). So you need to define all of them too in your LDIF.

Also, some directories require that you specify all objectClasses up to the top:

dn: uid=jessejames,ou=users,ou=accounts,ou=spookyinternet,dc=spookyinternet,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: jessejames
cn: Jesse
sn: James

This LDIF should work (provided you've already added all the containers: ou=users, ou=accounts, etc.). However, this is clearly redundant and I suggest you to try with only inetOrgPerson class declared and see if it works like that.


If you're only interested in uid attribute and don't want to add sn and cn, you should not use the inetOrgPerson objectClass at all. You can take other route and use the uidObject auxiliary objectClass which only contains this uid attribute:

dn: uid=jessejames,ou=users,ou=accounts,ou=spookyinternet,dc=spookyinternet,dc=com
objectClass: top
objectClass: uidObject
uid: jessejames

In this case you must specify both objectClasses in a LDIF because uidObject is not a structural objectClass, and the simplest structural objectClass out there is the base, top. And you can always add inetOrgPerson (or any other) with all its required attributes later.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .