Implementing organizational "accounts" with LDAP

[Melissa Wauford <mwauford@utk.edu>]

Our existing ph directory and our Solaris system currently support
entries/accounts for organizational units used by University departments
and student organizations for web hosting and centralized email.
Obviously, these entities are neither people nor groups. And I am not
entirely certain the best approach to implementing them to enable the
maximum number of possible services now and in the future.

We want to assign a uid and userPassword, as well as location, phone, and
URL informtion for each "organizationalUnit". The organizationalUnit
objectclass does not contain a uid attribute. But it just doesn't seem
right to define these entities as People with all their associated
objectclasses. And due to the student in Math who worked for Computer
Science issue, we have defined a flat People namespace. Nonetheless, some
systems we will use want organizational accounts to be defined as People.

For example, we currently are transitioning to a SIMS mail server (yes, I
know its future is a little iffy, but we're already committed) which
basically only knows People and Groups. We also want to move toward
LDAP-based authentication for our Solaris systems. I'm not sure where
Solaris is going to expect these entries to be.

We can just bite the bullet and define them as people. We can put them in
a separate organizationalUnits subtree (at the People, Groups, Devices
level) and deal with the replication issues. We can do something I haven't
thought of yet.

Do any of you have ideas, pointers, etc.? What are others doing?

                                    Melissa Wauford
                                    Computing & Network Services
                                    The University of Tennessee
                                    mwauford@utk.edu