Schema design - multiple structural objectclasses

[D.J.Morriss@hw.ac.uk]

Hi,

I need to build a directory which contains both "White Pages"-style
information and account info (for authentication and NIS emulation). I want
there to be a common password for both (since one of the objects is "single
sign-on").

Researches up until now have led me to believe that:

    - the "White Pages" info is best structured as a container called
      "ou=People,..." where entries use objectclasses such as top, person,
      organizationalPerson and inetOrgPerson. A number of clients I have
      seen tend to perform searches of the style:
      (&(objectclass=person)(|(cn=xyz)(sn=xyz)(uid=xyz)))

    - the account info is best laid out as entries using objectclasses such
      as account and posixAccount. Clients seem to expect DNs of the form
      "uid=userid,ou=People,..." (at least Netscape's Directory Server says
      it does), and they are inclined to perform searches such as:
      (&(objectclass=posixAccount)(uid=xyz))

This leads me to the conclusion that a single entry per person would be a
good idea from the management point of view, using all of the above
objectclasses concatenated together. I plan to use access control to give
alternative "views" of the same data

However, this seems to go against the recommendations in Howes, Smith, &
Good's excellent (but weighty) book. I don't really understand why multiple
structural objectclasses in an entry aren't a good idea. Anyone care to
comment?

Is my "smash it all together" design going to haunt me in future?

Dave


--  
David Morriss, Computing Services,           | Tel: +44 (0)131 451 3262 (DDI)
Heriot-Watt University, Edinburgh, EH14 4AS, | FAX: +44 (0)131 451 3261
Scotland, UK                                 | D.J.Morriss@hw.ac.uk