Re: structuralObjectClass operational attribute

[Quanah Gibson-Mount <quanah@stanford.edu>]

--On Wednesday, April 23, 2003 11:59 AM +0200 Jeroen Vriesman 
<jeroen.vriesman@experian.nl> wrote:

> [root@ids ldap]# ldapadd -c -x -w password -D "cn=admin,o=Organization"
> -f user.ldif adding new entry "cn=Test User, ou=Nederland, o=Organization"
> ldapadd: update failed: cn=Test User, ou=Nederland, o=Organization
> ldap_add: Internal (implementation specific) error (80)
>         additional info: no structuralObjectClass operational attribute
>
> My ldif file looks like this:
>
> dn: cn=Test User, ou=Nederland, o=Experian
> mailMessageStore: /vmail/test.user/Maildir/
> mobile: 12345
> givenName: Test
> telephoneNumber: 1234
> sn: Test
> userPassword:: e2NIPX1jSldnZkxKNnRSVHBvYlBCdGNJMuJkeC9AeU07
> departmentNumber: 2
> mailAlternateAddress: test@organization.nl
> ou: Nederland
> mailReplyText: Blurp
> mail: test.user@organization.nl
> uid: tuser
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> objectClass: qmailUser
> accountStatus: active
> title: Programmer IS development
> cn: Test User
>
> Any ideas what the message means?

Jeroen,

This message actually means exactly what it says... You have no structural 
objectClass in your chain for your user tree.  I ran into this same problem 
when changing the definitions for my user chain at one point.  Somewhere 
off in RFC land for LDAP, it specifies that you must have at least one 
structural objectClass defined.

Also, doing an ldapsearch will not show your structuralObjectclass for a 
particular entry unless you add the + sign to then end of your search, i.e.,

ldapsearch uid=quanah + on our system:

dn: uid=quanah,cn=Accounts,dc=Stanford,dc=edu
structuralObjectClass: suaccount
entryUUID: be7d553a-f847-1026-8bbe-842ea2b3f12b
creatorsName: cn=manager,dc=stanford,dc=edu
modifiersName: cn=manager,dc=stanford,dc=edu
createTimestamp: 20030401044001Z
modifyTimestamp: 20030401044001Z
entryCSN: 2003040104:40:01Z#0x001c#0#0000
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE

Note the STRUCTURAL declaration below:


objectclass (1.3.6.1.4.1.299.11.3.100 NAME 'suAccount'
       DESC 'Stanford University Account'
       SUP ( account $ suOperational )
       STRUCTURAL
               MUST ( uid $ suName $ suAccountStatus )
               MAY ( owner $ suDescription $ suService $ suIdentifies )
       )

--Quanah

--
Quanah Gibson-Mount
Senior Systems Administrator
ITSS/TSS/Computing Systems
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html