Thanks for the suggestion, but after commenting out loginShell, which it didn't like, I'm still getting the same problem--for objectClass: value #0 in this case.
My slapd.conf file contains the following includes from the current OpenLDAP schema files, which should take care of posixAccount include ./schema/core.schema include ./schema/cosine.schema include ./schema/nis.schema I'm using the Java LDAP Browser/Editor from gawojar at the University of Chicago, and it (or maybe OpenLDAP itself, I'm no expert) generated the unload ldif file, which included the account objectClass. The browser defaults to this structure when creating a new posixAccount entry, and it worked with the older version of OpenLDAP. Also, uid is a synonym for userid. JFE. "Joshua M. Miller" <[EMAIL PROTECTED]> 06/19/2007 09:02 AM To Jack Emmerichs <[EMAIL PROTECTED]> cc [email protected] Subject Re: [ldap] syntax for posixAccount The following syntax works for me with OpenLDAP 2.3.35: # Test Account, People, example.com dn: cn=Test Account,ou=People,dc=example,dc=com givenName: Test sn: Account cn: Test Account uid: testaccount userPassword:: <passwd here> uidNumber: <uid> gidNumber: <gid> homeDirectory: /tmp loginShell: /bin/bash objectClass: inetOrgPerson objectClass: posixAccount objectClass: top Also, why are you using the account objectClass? From what I understand it's primarily for computer accounts. From cosine.schema definition: # 8.3.3. Account # # The Account object class is used to define entries representing # computer accounts. The userid attribute should be used for naming # entries of this object class. So, from my schema that I have loaded, you would be missing the userid attribute which is a requirement for that objectClass: objectclass ( 0.9.2342.19200300.100.4.5 NAME 'account' SUP top STRUCTURAL MUST userid MAY ( description $ seeAlso $ localityName $ organizationName $ organizationalUnitName $ host ) ) HTH, -- Joshua M. Miller - RHCE,VCP Jack Emmerichs wrote: > We are upgrading from OpenLDAP 2.2.29 to the current 2.3.32. The build > seems to work, and the basic database structure seems okay and displays > as: > > # extended LDIF > # > # LDAPv3 > # base <dc=my-domain,dc=com> with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # my-domain.com > dn: dc=my-domain,dc=com > dc: my-domain > objectClass: top > objectClass: dcObject > objectClass: organization > o: OrgName > > # people, my-domain.com > dn: ou=people,dc=my-domain,dc=com > ou: people > objectClass: top > objectClass: organizationalUnit > > # Manager, my-domain.com > dn: cn=Manager,dc=my-domain,dc=com > objectClass: organizationalRole > cn: Manager > > # search result > search: 2 > result: 0 Success > > > The problem is that I cannot find a syntax for posixAccount entries the > LDAP will accept without throwing an error such as: > > LDAP error code 21 - objectClass: value #1 invalid per syntax > > The ldif format exported by the old version looks like this (it's a > Windows system with dummy data for Unix items uid#, gid#, homeDirectory, > etc.): > > > dn: cn=AWS User 1,ou=people, dc=my-domain,dc=com > gidNumber: 100 > userPassword:: e1NIQX1pK1BKUTdGZ24vKy94UnF0Wm0wS0JLMzRQSjA9 > uidNumber: 100 > uid: awsuser1 > objectClass: top > objectClass: account > objectClass: posixAccount > homeDirectory: notUsed > cn: AWS User 1 > > I've looked at and tried lots of examples containing from 3 to 5 > objectClass entries, but I always get the same error on some objectClass > value #. > > Questions: > Is this in fact an improper definition for posixAccount? If so, what > should we use instead? > > Are there any known restrictions using OpenLDAP that would make it reject > this entry if it is not an error? > > Thanks for any help that anyone can offer. > > JFE. > > > > --- > You are currently subscribed to [EMAIL PROTECTED] as: [EMAIL PROTECTED] > To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message. > --- You are currently subscribed to [EMAIL PROTECTED] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
