Re: Understanding LDAP structures
On Sun, 2003-04-20 at 05:45, Alan Chandler wrote:
> 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?
The "schema" are defined in various files. Under Debian, I
believe these are under /etc/openldap/schema/, but that location
may be wrong. `find /etc -type d -name schema` should get you
in the right spot fairly quick.
> 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
posixAccount is what is used to define a user account, IIRC.
When you have user accounts stored in LDAP, the "userPassword"
attribute basically contains what would normally be in the
password field in /etc/shadow. The above declaration specifies
that the attribute userPassword:
- is writable by the admin LDAP user (by dn="cn=admin"...)
- not sure about the second one ("by anonymous auth")
- is writable by one's self, e.g. you can update your own
password ("by self write")
- and not accessible by anyone else ("by * none")
This restricts access to the userPassword attribute. You
don't want just anyone to be able to connect to your LDAP
server and retrieve each user's hashed password.
> 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.
Not running OpenLDAP on Debian anymore, so I can't comment
on this.
> 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.
You can create any organizationalUnit's that you want. You're
not confined to any one hierarchy. Imagine a company with
three departments: advertising, sales, and management. You
could quite easily separate the people in those departments by
putting them in separate organizationalUnits:
ou=advertising,dc=bigcompany,dc=com
ou=sales,dc=bigcompany,dc=com
ou=management,dc=bigcompany,dc=com
> 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?
You can have your entries be "members" of multiple objectclasses.
LDAP gives you alot of freedom to do what you want. The objectclass
posixAccount simply allow you to declare that a person is a user
with login capabilities.
> 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?
That's where the different organizationalUnits come into play.
You could easily declare three separate, distinct ou's for these:
"ou=users", "ou=mailonly", "web", for example.
> > 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.
They used to have a package called "migration tools", which would
take your passwd, shadow, and group files (and possibly some others
now) and convert them into LDIF (LDAP Interchange Format, or some
such) that can easily be imported into an LDAP server. IIRC, these
were all Perl scripts, so you can easily go through them and see
what they do. It might be useful to play with these and look at
the resulting LDIF files to see how things work.
HTH,
j.
--
Jeremy L. Gaddis <jeremy@gaddis.org> <http://www.gaddis.org>
Reply to: