> Also, why are you using the account objectClass? From what I understand > it's primarily for computer accounts. > # 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.
Eh? I think you are confusing the phrase "computer accounts" with
"machine accounts" ala CIFS or Kerberos. I think it means generically
an account on a computer system.
Minus "account" his object has no structural objectclass, since
posixAccount is auxillary.
> From cosine.schema definition:
> 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 )
> )
No he isn't.
attributetype ( 0.9.2342.19200300.100.1.1
NAME ( 'uid' 'userid' )
DESC 'RFC1274: user identifier'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
"uid" and "userid" are on and the same.
I don't know of the top of his head why his LDIF doesn't load; our
transition from 2.2.x to 2.3.x was utterly painless. and we use
posixAccount et al. Superficially at least his LDIF looks OK - but I
only gave it a once over.
Perhaps posixAccount isn't even defined in the schema of the 2.3.x
server?
signature.asc
Description: This is a digitally signed message part
--- 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.
