Re: Implementing organizational "accounts" with LDAP

["Graeme Joyce" <openldap-list@jade.co.nz>]

> 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