[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: schema design and schema restrictions

On Wed, Nov 26, 2008 at 01:47:31PM -0400, Mansour Al Akeel wrote:

> True, but it's not required (MUST). the password is optional (MAY). I 
> will consider extending inetOrgPerson and make the password MUST.

I would advise against it - see my earlier message. Remember that the
lack of a password atribute means that the account *cannot* authenticate:
it is not the same as having an empty password field in a passwd file.

> >You only need account (or hostObject) if you want the host attribute.
> >
> >  
> I couldn't find objectClass: hostObject any where. What do you mean by 
> host attribute? I am going to need additional AUX objectClass for the 
> home directory, login scripts, .... etc. AFAIK account is structural and 
> not to be combined with inetOrgPerson.

RFC2307 defines posixAccount:

        ( nisSchema.2.0 NAME 'posixAccount' SUP top AUXILIARY
          DESC 'Abstraction of an account with POSIX attributes'
          MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
          MAY ( userPassword $ loginShell $ gecos $ description ) )

There is your AUX class containing the Unix attributes.

I would expect to define an AUX class of your own as well, to
permit attributes of local significance.

The 'account' object class is probably not very useful. It is one of
the very early COSINE classes, defined before anyone had much
experience of LDAP/X.500 in production.

|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |