Re: Understanding LDAP structures
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 20 Apr 2003 9:04 am, Michael Heironimus wrote:
>
> LDAP is sort of a hybrid of object-oriented and hierarchical data. LDAP
> entries are organized in a hierarchy, but each entry is an object with
> one or more parent classes (multiple inheritance, if you're a
> programmer). The objectClass attribute(s) specify the parent class(es).
I understand
>
> An objectClass is defined in a schema, it's what specifies what
> attributes (data) are mandatory (MUST) and what attributes are optional
> (MAY). An objectClass can be defined as structural or auxiliary, as I
> recall each LDAP entry must have at least one structural objectClass.
> Not all LDAP servers enforce that rule, though - I think OpenLDAP 2.0
> doesn't and 2.1 does.
What this means, I guess is that its crucial to have a list of what standard
objectClasses are and what attributes they expose. Is there such a list with
reasonable friendly explanations?
>
> > So far I have set up whats there with standard debian install. This
> > asks me what the base suffix is, and thats set
> >
> > dc=chandlerfamily, dc=org, dc=uk
> >
> > I can now browse what I have with gq and this seems to have three sub
> > sections below this. There are
> >
> > cn=admin ou=people, and ou=roaming
> >
> > Now, why are these particular two letters used (ie cn, or ou) and
> > where do I find out what they are. If I go to anyone of them there
> > are a whole set of parameters set - again I have no idea what they
> > are.
>
> cn=admin is an object representing your administrative account on the
> LDAP server (the full DN is cn=admin,dc=chandlerfamily,dc=org,dc=uk).
Does this mean that the attributes cn and dc are defined within some form of
objectClass? gq appears to say that dc belongs to dcObject - but under
cn=admin there are two objectClasses (organisationalRole and
simpleSecurityObject)
> It's an LDAP user account. Using the cn for the distinguished name is
> really just a convention, in the past I've set up accounts using uid for
> the distinguished name. That was for Websphere authentication, not for
> UNIX user accounts, but I think it should work either way as long as all
> the attributes are set up correctly.
So what is it about the cn definition that defines it as a ldap user account -
is this entries in the slapd.conf file? Is this it?
access to attribute=userPassword
by dn="cn=admin,dc=chandlerfamily,dc=org,dc=uk" write
by anonymous auth
by self write
by * none
I am slightly confused by what debian has done here. Other HOWTOs seem to
imply that I need keywords rootdn and rootpw in the slapd.conf file but there
is no such entry in mine. I did try dpkg-reconfigure to find out, but I
can't run it without starting again.
>
> ou means the entry is an "organizational unit". ou is a structural
> object that logically fits under an organization (o), but doesn't
> actually have to go under one in the LDAP hierarchy. An ou (and other
> parts of the tree like o and dc) has its own attributes, but is also a
> part of the hierachical arrangement of the data and can have other LDAP
> entries under it. ou=people is the standard tree for UNIX user accounts
> stored in LDAP with the NIS-compatible schema.
So if I get this correctly, ou is an attribute of the objectClass
organisationalUnit - and ou=people defines an instance of this objectClass in
which I can put instances of some other records related to people.
At this point I am a bit stuck again. It appears that objectClass
posixAccount is one that I would want, but some of the guides also include
other objectsClass (mailRecipient being one). I half understand that,
although there seems to be a mystery objectClass called top that I need as
well. How do I get a complete list?
The other thing puzzling me is that I want subsets of people
- - those with unix accounts and mail addresses on my domain
- - those with mail addresses (with a forwarding address) but no unix account
- - those that belong to some group name which defines which area of my web site
they can see, or whether they are allowed access to cvs.
How do I handle that?
>
> If you want to know more about the NIS schema for LDAP and the standard
> way things are set up you should probably look at padl.com's
> documentation.
Not sure specifically which documentation, there is loads there. I've been
going through some of it - and its helped me get as far as I have.
- --
Alan Chandler
alan@chandlerfamily.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+onpAuFHxcV2FFoIRAh9MAJ484IzPOHrsUM07s8xNBe+hZVqT2QCeJkJ1
eqywzua2FmmGHmwCWFwYfZk=
=fE/m
-----END PGP SIGNATURE-----
Reply to: