Implementing organisation model

["Simon Yuen" <eg_ymc@stu.ust.hk>]

Hi,

I am now doing a project to design an organization model that can be applied
to a company that contains many departments and groups. Would you minding
asking my questions, please? Thank you very much.

The problem I faced is that an entity has to build into two different
subtrees. For example, John is under financial department. So, the entity dn
may be like uid=john, ou=financial , ou=myCompany. However, he is also under
the other groups in other subtrees.


1. How can I design model that can be represented mulitdimension views?

2. Is it possible I design the model like the following?  The entity is
represented by an aliased object in the financial deparments while other
groups just refer it. The entity can still be searched in the other groups
subtree.

3. What would happen if the aliased object cause cyclic loop? Could it be
prevented during searching?

Yours sincerely,
Simon

----- Original Message -----
From: "Graeme Joyce" <openldap-list@jade.co.nz>
To: "Melissa Wauford" <mwauford@utk.edu>; <openldap-general@OpenLDAP.org>
Sent: Thursday, October 19, 2000 4:40 AM
Subject: Re: Implementing organizational "accounts" with LDAP


> > Do any of you have ideas, pointers, etc.? What are others doing?
>
> Melissa
>
> Based on recent messages, there are a number of people on this list
> grappling with how to define accounts in LDAP - welcome! There seem to be
> (at least) 2 approaches:
>
> 1) Define all your "accounts" in one place (ou=accounts) and then where
> relevant have a pointer (dn valued attribute) from an account entry to any
> real-world entities associated with it (eg to a person in ou=people).
And/or
> maybe a pointer in the other direction (from a person to each of their
> accounts). See:
> http://www.openldap.org/lists/openldap-general/200001/msg00043.html
>
> 2) For accounts that represent some real world entity (a person, your
> University org units, etc) - add the account related attributes (uid,
> userPassword etc) directly to that entry. Use auxilliary classes like
> posixAccount to allow this. For accounts that are only "accounts" and have
> no association with any other entry in the directory, put them in
> ou=accounts, with structural objectClass of account. Here's a relevant
> article on this method:
> http://sendmail.net/?feed=donnellydirtree
>
> We are slowly migrating more of our auth data and mechanisms to ldap -
using
> approach 2. We use an external OO database to generate/manage our ldap
data,
> which means we can use any tree structure we choose reasonably easily, so
> that wasn't a major consideration. Approach 2 just seemed simpler to us,
if
> possibly less flexible. Time will tell.
>
> Sounds like your mail server might impose some constraints on how you do
> this...but I would strongly suggest you don't define your org units as
> people or groups just to please one application. Can you fool it by using
> some suitable auxilliary classes? We've been strong on trying to get the
> structural objectclass for an entry "right". This forces you to really
> understand your data, and seems to lay a good foundation for future uses
of
> directory data. I'd put your orgUnits/departments in their own ou, with
> structural objectClass oraganizationalUnit, and deal with whatever other
> issues that causes as secondary considerations (sounds easy when you say
it
> fast :-)
>
> > I'm not sure where Solaris is going to expect these entries to be.
> Unless you specify othewrwise in your PAM config - it probably won't care.
I
> think it will just do a search like:
> (&(uid=%s)(objectClass=posixAccount))
>
> Graeme Joyce
> www.discoverjade.com
>
>