I did check out this URL as well as the two that Nelson had mention'd in his reply to your posting. These instructions are for the primary purpose of authentication rather than addressbook features although if done properly both can be accomplished in one step. It's just a matter of making sure your entry has the proper objectClass added to it and then adding the necessary attributes.
The one problem I've found thus far with OpenLDAP and the
various open-source LDAP management solutions is none of them produce a
proper valid LDAP entry that can pass schemacheck muster. I generaly
just use GQ and build out the entries themselves from my working
knowledge. The problem becomes very evident with the 2.1.x version of
OpenLDAP as I found out when I upgraded and had to spend a day bringing
my entire tree up to muster. The biggest problem is in the various
applications being able to follow a proper structural objectClass chain.
Many (directory-administrator and webmin) would try to include
objectClasses from two seperate STRUCTURAL objectClass chains. All the
objectClasses for an entry need to be in the same structural chain or
optionally include AUXILIARY objectClasses. Even the migration tools had
problems with this last time I recall checking on them. For me I use the
following objectClass definition for an account:
top (structural)
person (structural)
posixAccount (auxiliary)
inetLocalMailRecipient (auxiliary)
The person OC is stack'd on top, so to follow a proper chain any
other structural OC's must stack on 'person' not 'top' from this point.
Both of the auxiliary OC's stack on top which is fine. What you can't do
is what directory-administrator likes to try for host level access
control and include the account OC which is structural stack'd on top.
This violates the structural objectClass chain. You could add
organizationalPerson and inetOrgPerson if you wanted to include more
details as organizationalPerson stacks on person, and inetOrgPerson
stacks on organizationalPerson. That would give you a very detail'd
address book entry for a user. If they didn't need to have an account
referenced then you could get away with removing the posixAccount
auxiliary objectClass. The inetLocalMailRecipient is handy for smart
LDAP routing of email addresses.
I use my LDAP information rather extensively on my network as
user accounts are listed in there, as well my mail servers use it for
most of their configurations allowing them to be replaced with relative
ease. So my LDAP servers are hit pretty hard daily, as of me writing
this LDAP01 hashandled over 878K searches and LDAP02 another 867K and
those are just the slaves that the network rely on. My primary is just
used for management of the tree itself.
Regards,
Jeremy
On Wed, Mar 10, 2004 at 06:00:51PM +0000, Martin Ellis wrote:
> On Wed, Mar 10, 2004 at 04:43:45PM +0100, Nicos Gollan wrote:
> > > Is there any good tutorial on how to set up a very basic LDAP
> > > server for simple things like keeping an address book? I know
>
> On Wednesday 10 March 2004 17:13, Jeremy T. Bouse wrote:
> > I've been working with LDAP to handle the centralized
> > authentication of my home network, and now implimenting at work.
>
> There's a doc by Torsten Landschoff listed on the OpenLDAP pages on
> alioth that describes this (NSS/PAM with LDAP):
>
> http://alioth.debian.org/forum/forum.php?forum_id=771
>
> I don't know enough about the subject to know whether the default LDAP
> schema you'll get following this article is sufficient to form an
> address book - but it might be a good start?
>
> Martin
>
signature.asc
Description: Digital signature
