Understanding LDAP structures
Alan Chandler
Hash: SHA1
I am struggling to understand the concepts behind ldap databases. All the
HOWTOs that I've read seem to start with the assumption that you already
understand the concept, or you can design your own structure.
Let me explain what I want to do, and perhaps someone can tell me how I should
structure my ldap database.
I want an ldap server to help me manage the people I know about and to control
access to my home network.
There will be several classes of user/access needed.
a) Admin access - access to me to configure and control things I need my own
account and access to root.
b) General family access account - a pseudo account with no password, so that
the whole family access shared machines (like a win98 family machine) - or
samba can provide a general fileshare or access to printers
c) Specific family member accounts - mainly to provide controlled access to
mail (stored in Unix account home dir/Maildirs) with pop3 and imap login.
This needs to include me. I would like these people to have the same
accounts on a number of linux machines. I would also like them to be able to
control the cupsys printer through its web interface by entering the same
password as the mail accounts. I will probably also put up webmail at some
point and want the same access control for that.
d) General family member accounts - mainly to share my domain name among my
relatives for mail but to forward the mail on to their normal isp.
e) Groups of people (including family members, but potentially friends as
well) who I can set up to use ldap to control access to different parts of my
internal web site.
f) Groups of people (different possibly from the web access above) who can
have an account on my main server to have ssh access in through my firewall.
I would like to be able to store their public ssh keys in the ldap database.
I do not want them to have general access to any other machines in my network
(except I want access in and be able to ssh about the internal machines). I
am thinking here about such things as controlled access to cvs or equivalent
in an open source project.
g) A general e-mail address book for the family with e-mail addresses and
other values. I would like to synchonise my palm pilot with a subset of it.
I think I can figure out how to use the ldap database for the different
things, but I must admit I am totally confused about how to set up the data
that is in it. Most of the documentation throws around terms like "dn", "dc"
and "cn" and concepts like objectclasses and top and posixAccount and
attributes etc as though you already know what they mean and the relationship
to each other.
How should I structure the database, and what are the relationship between the
various parts.
I have installed the debian ldap packages including libpam-ldap and
libnss-ldap but how to I populate the database and what is the relationship
between its contents and files like /etc/passwd (which have a whole load more
accounts than I am particularly interested in).
- --
Alan Chandler
al...@chandlerfamily.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+oba3uFHxcV2FFoIRAvK5AJ4vuMyu4s244AeIHFICc0ybuIC/UwCgrdIs
m+B2iLPPj47MGn8dOEPLEq8=
=Wh0K
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
nate
> I am struggling to understand the concepts behind ldap databases. All the
> HOWTOs that I've read seem to start with the assumption that you already
> understand the concept, or you can design your own structure.
have you seen mine ?
http://howto.aphroland.de/HOWTO/LDAP
I try to explain it in great detail.
> a) Admin access - access to me to configure and control things I need my
> own account and access to root.
> b) General family access account - a pseudo account with no password, so
> that the whole family access shared machines (like a win98 family
> machine) - or samba can provide a general fileshare or access to printers
> c) Specific family member accounts - mainly to provide controlled access
> to mail (stored in Unix account home dir/Maildirs) with pop3 and imap
> login. This needs to include me. I would like these people to have the
> same accounts on a number of linux machines. I would also like them to
> be able to control the cupsys printer through its web interface by
> entering the same password as the mail accounts. I will probably also
> put up webmail at some point and want the same access control for that.
everything above is easy except cups, I haven't investigated much
but the only way that cups is allowed to be controlled by default is
with the root password. maybe cups can support PAM, not sure.
> I think I can figure out how to use the ldap database for the different
> things, but I must admit I am totally confused about how to set up the
> data that is in it. Most of the documentation throws around terms like
> "dn", "dc" and "cn" and concepts like objectclasses and top and
> posixAccount and attributes etc as though you already know what they mean
> and the relationship to each other.
my howto covers those concepts for the most part. Pretty much everything
you want to do is possible with LDAP, though the one questionmark other
then cups is storing SSH keys in LDAP, I wouldn't reccomend this. Unless
you somehow have a version of SSH that can extract keys from LDAP
automatically(in which case send me a copy).
don't expect to have such a system in place overnight, it will take
some time to learn how things work. check out my howto, get your
database up, get PAM and NSS running, get postfix or whatever MTA you
prefer(postfix is covered in my howto) talking to LDAP..check out the
host acl section for restricting access to hosts/services..
> I have installed the debian ldap packages including libpam-ldap and
> libnss-ldap but how to I populate the database and what is the
> relationship between its contents and files like /etc/passwd (which have
> a whole load more accounts than I am particularly interested in).
I strongly reccomend recompiling all of the packages with SSL support,
this too is covered in my howto, though be sure to get the source
packages from security.debian.org not the normal distribution sites
since they were updated a few months ago.
and of course if you have questions or have feedback, almost all of
the pages on my howto site allow users to post comments.
nate
Jamie Lawrence
> my howto covers those concepts for the most part. Pretty much everything
> you want to do is possible with LDAP, though the one questionmark other
> then cups is storing SSH keys in LDAP, I wouldn't reccomend this. Unless
> you somehow have a version of SSH that can extract keys from LDAP
> automatically(in which case send me a copy).
You might look at
http://freshmeat.net/projects/ldappubkey/
I believe this is only for public keys, as the name would indicate. I
haven't used it yet, but keep meaning to. Let me know how it goes if you
use the patch.
-j
--
Jamie Lawrence j...@jal.org
Computer Science is Applied Philosophy.
Alan Chandler
Hash: SHA1
On Saturday 19 Apr 2003 10:31 pm, nate wrote:
>
> http://howto.aphroland.de/HOWTO/LDAP
Yes - one of the clearer ones. But I note you seem to be having some
conceptial problems - you say you are not really sure what objectClass is
all about.
However, in the section on configuring the database you list out what you have
done and what each of the fields mean, but you don't say WHY you have done it
that way. Without that information I can't design my own structure rather
than just copy yours.
I also think I am getting confused between information that defines the
structure and the actual records themselves.
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.
Now if I am to extend beyond whats there and add new sections, then I
obviously need to understand enough of whats there and why so that I can add
my bits.
I wrote the following things I am trying to do ...
> > a) Admin access - access to me to configure and control things I need my
> > own account and access to root.
What I mean by that is that if I login as root, it will prompt and check for a
password which it looks up in the ldap server. If I login as "alan" then the
same password will be looked up.
So what I want to do is setup a record for me in the ldap server (under
people?) which somehow links the unix account "root" and the unix account
"alan" to this record.
> > b) General family access account - a pseudo account with no password, so
> > that the whole family access shared machines (like a win98 family
> > machine) - or samba can provide a general fileshare or access to
> > printers
I see this as a special entry under people with the name like guest. But
because here is a difference between this entry and the one from a) above
would I have to somehow create sub-sections of people in order to have
different parameters?
> > c) Specific family member accounts - mainly to provide
> > controlled access to mail (stored in Unix account home dir/Maildirs)
> > with pop3 and imap login. This needs to include me. I would like these
> > people to have the same accounts on a number of linux machines. I would
> > also like them to be able to control the cupsys printer through its web
> > interface by entering the same password as the mail accounts. I will
> > probably also put up webmail at some point and want the same access
> > control for that.
>
> everything above is easy except cups, I haven't investigated much
> but the only way that cups is allowed to be controlled by default is
> with the root password. maybe cups can support PAM, not sure.
I am not so much worried about the mechanisms to support the ldap access -
although its not set at the moment and I would have to work it through. What
I don't understand is how to put a record in the database that says this
particular entry is allowed cups access.
...
and so on -
- --
Alan Chandler
al...@chandlerfamily.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+ojwruFHxcV2FFoIRAkDLAKChqU9Q+1dafqBB5JL68+5AH/RrBACgtdLn
VmehdxwDrZwE/i3sFYZAZ1Y=
=rN47
-----END PGP SIGNATURE-----
Kevin McKinley
"nate" <debia...@aphroland.org> wrote:
> everything above is easy except cups, I haven't investigated much
> but the only way that cups is allowed to be controlled by default is
> with the root password. maybe cups can support PAM, not sure.
Nah. Members of lpadmin can administer CUPS.
Kevin
Tran Tuan Anh
I notice the font redering in Mozilla is not as good as in IE.
I remembered one of my friend told me that was because in Linux
we don't have some font technologies.
Is it still true now? or just because I don't config fonts setting
properly?
THanks!
TUan Anh
Tran Tuan Anh
I've been using Debian for 3 weeks.
But No SOUND CARD installed yet :P
Now I fixed up much of the things, and want some music for fun.
Could anyone tell me how to install sound card, or which
documents about that?
Thanks a lot!
Tuan Anh
Matthias Hentges
> Hi all:
>
> I've been using Debian for 3 weeks.
> But No SOUND CARD installed yet :P
> Now I fixed up much of the things, and want some music for fun.
> Could anyone tell me how to install sound card, or which
> documents about that?
Hard to tell since you do not give us *any* useful information about
your soundcard...
Do an "lspci" as root and look for the chipset of your soundcard.
When you have the output of lspci, your SC manufacturer and model, write
again.
--
Matthias Hentges
Cologne / Germany
[www.hentges.net] -> PGP welcome, HTML tolerated
ICQ: 97 26 97 4 -> No files, no URL's
My OS: Debian Woody: Geek by Nature, Linux by Choice
Michael Heironimus
> On Saturday 19 Apr 2003 10:31 pm, nate wrote:
> > http://howto.aphroland.de/HOWTO/LDAP
>
> Yes - one of the clearer ones. But I note you seem to be having some
> conceptial problems - you say you are not really sure what
> objectClass is all about.
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).
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.
> 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).
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.
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.
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. Most of the names and structure is really just a matter
of convention or standardization - it's not the only way you could do
it, it may not even be the best way, but it's the way software will
expect things to be and using anything else will make life difficult.
padl.com also has some scripts to automate migrating existing accounts
and data to LDAP.
--
Michael Heironimus
Tran Tuan Anh
>
>Hard to tell since you do not give us *any* useful information about
>your soundcard...
>
>Do an "lspci" as root and look for the chipset of your soundcard.
>
>When you have the output of lspci, your SC manufacturer and model, write
>again.
>
>
this is what I got from lspci:
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS]
SiS7012 PCI Audio Accelerator (rev a0)
Subsystem: Giga-byte Technology: Unknown device a001
Flags: bus master, medium devsel, latency 32, IRQ 9
I/O ports at d800
I/O ports at dc00
Capabilities: [48] Power Management version 2
Last time i used RH, hence I know nothing about how to install soundcard.
Thanks!
Tuan ANh
Alan Chandler
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
al...@chandlerfamily.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+onpAuFHxcV2FFoIRAh9MAJ484IzPOHrsUM07s8xNBe+hZVqT2QCeJkJ1
eqywzua2FmmGHmwCWFwYfZk=
=fE/m
-----END PGP SIGNATURE-----
Matthias Hentges
> >
> >
> >Hard to tell since you do not give us *any* useful information about
> >your soundcard...
> >
> sorry :P
>
> >Do an "lspci" as root and look for the chipset of your soundcard.
> >
> >When you have the output of lspci, your SC manufacturer and model, write
> >again.
> >
> >
> this is what I got from lspci:
>
> 00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS]
> SiS7012 PCI Audio Accelerator (rev a0)
> Subsystem: Giga-byte Technology: Unknown device a001
> Flags: bus master, medium devsel, latency 32, IRQ 9
> I/O ports at d800
> I/O ports at dc00
> Capabilities: [48] Power Management version 2
A quick google check shows that you need at least kernel 2.4.18.
modprobe i810_audio should activate your soundcard. If everything works
do an echo "i810_audio" >> /etc/modules to load the driver at boot time.
HTH
Shyamal Prasad
Matthias> Am Son, 2003-04-20 um 12.01 schrieb Tran Tuan Anh:
>> this is what I got from lspci:
>>
>> 00:02.7 Multimedia audio controller: Silicon Integrated Systems
>> [SiS] SiS7012 PCI Audio Accelerator (rev a0) Subsystem:
Matthias> A quick google check shows that you need at least kernel
Matthias> 2.4.18.
Matthias> modprobe i810_audio should activate your soundcard. If
Matthias> everything works do an echo "i810_audio" >> /etc/modules
Matthias> to load the driver at boot time.
Tran,
Of that works, your next step is to add the users who want to use the
audio driver to the 'audio' group (man adduser). Then, have the
user(s) logout and log back in. Now go ahead and learn what your
options are for audio applications. If you are using GNOME or KDE I
guess you get a bunch by default. I personally use xmms with esd
(yeah, I know it sucks) under a generic window manager (usually xfce
these days). Google away....
Cheers!
Shyamal
nate
> However, in the section on configuring the database you list out what you
> have done and what each of the fields mean, but you don't say WHY you
> have done it that way. Without that information I can't design my own
> structure rather than just copy yours.
well I did it that way to get as much info in there as I could.
> 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 is "common name" i think and it defines a ldap object(lack of better
term), the "leaf of a branch", the ou is Organizational unit and defines
a tree branch.
as for what the ou= entries are they can be anything you want them to
be, the roaming ou entrie is intended for use with Netscape roaming
profiles but theres no restriction, you can store netscape roaming profiles
in an ou named "IBM Thinkpads" if you wanted. You can store samba info
in ou=roaming if you want, it just comes down to telling the client apps
where to search for the data they will need.
> What I mean by that is that if I login as root, it will prompt and check
> for a password which it looks up in the ldap server. If I login as
> "alan" then the same password will be looked up.
>
> So what I want to do is setup a record for me in the ldap server (under
> people?) which somehow links the unix account "root" and the unix account
> "alan" to this record.
I am not sure if openldap can do this. not sure why you would want
to, your saying you want to be logged in as root even though your telling
the system to log you in as alan ?? authenticating offa LDAP is easy
with PAM and NSS, which is explained in detail in my howto, but linking
of entries to other entries I think I remember this as not being supported
in openldap at the moment(at least 2.0.x maybe 2.1.x is different). Though
I think it is technically possible(some other LDAP servers perhaps NDS
can do this).
> I see this as a special entry under people with the name like guest. But
> because here is a difference between this entry and the one from a) above
> would I have to somehow create sub-sections of people in order to have
> different parameters?
yes. what I do is create the first entry then use ldapexplorer to
make new ones, just change the existing data and hit the 'new/add' button.
> I am not so much worried about the mechanisms to support the ldap access -
> although its not set at the moment and I would have to work it through.
> What I don't understand is how to put a record in the database that says
> this particular entry is allowed cups access.
someone else pointed out that cups can be managed by users that belong
to the group lpadmin. Never tried this myself but will eventually that
would be cool if it worked. if this is the case just put them in the
group lpadmin, create a group called lpadmin and add memberUid attributes
with have the usernames of the people to belong to that group(1 memberUid
attribute per username).
nate
Jeremy Gaddis
> 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 <jer...@gaddis.org> <http://www.gaddis.org>
Alan Chandler
Hash: SHA1
On Sunday 20 Apr 2003 9:20 pm, Jeremy Gaddis wrote:
> 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.
I found the schema files ok, they are in /etc/ldap/schema - but they are not
exactly light reading:-(
I have searched the web from several directions but there is not one document
that I have been able to find that gives a summary of the objectClasses and
what they are for. I can't believe that nobody has found the need
...
> > 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.
I've sussed this now - only needed when you first create entries - but as soon
as you have the admin cn then you use the access control in slapd.conf by
binding to the database with the admin cn.
...
> > that, although there seems to be a mystery objectClass called top that I
That I still can't understand. Its being used all over the place but there is
never an explanation, only an instruction to use it.
- --
Alan Chandler
al...@chandlerfamily.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+ow7guFHxcV2FFoIRAp9VAJ9BwHoxdPEBrR2GcEe/We5Z2/E/NgCfUdxS
rxX339PQ7IaiiUFxAFq79Q4=
=14Ew
-----END PGP SIGNATURE-----
Dave Carrigan
... snip ldap questions...
First of all, a quick ldap tutorial.
An entry in an ldap directory is basically a set of key/value pairs. In
theory, those keys could be anything if your ldap server is not
validating the entries. I.e., the following is a perfectly valid entry
in a non-validating server:
cn: My Name
iLikeFrogs: yes
fuzzyRabbits: cute
In addition to the data in the entry, an entry also has to have a
name. Think of it as a filesystem: there's two important pieces of
information in the filesystem, the file's name and the file's
contents. In LDAP, the name is called the "distinguished name", or DN
(this is the name that distinguishes this entry from all others).
The DN of the above entry could be
something=foo, somethingelse=bar, andsomethingelse=bat
Note that nothing in the DN actually matches the contents of the entry
above. This is also technically OK, although I believed that later
versions of openldap have started disallowing this. Also, you read the
path from right to left, so 'andsomethingelse=bat' is the top of the
hierarchy.
Also, just like your filesystem needs a root name (/), so does an LDAP
directory. Since there are thousands of LDAP directories in the world,
they can't all use /, so you have to pick something else. The current
practice is to use dc=mydomain, dc=com (assuming that your domain name
is mydomain.com; dc means domain component). This is a guideline, and is
important if your directory will ever merge with someone else's. But,
you don't have to use your domain name; you can choose anything. For
example, using 'o=My House' is a perfectly valid root. The technical
name for this root is the "Base Distinguished Name" or BaseDN.
Getting back to the contents of a directory entry, it's usually bad
practice to allow any king of data in there, because mistakes can be
made, and inconsistencies can be found. Thus, enter the schema. The
schema just describes what data can be stored in the directory. An LDAP
schema describes two things:
1. What kind of attributes are allowed. This is things like cn, ou, etc,
plus what syntax they have, how the should be compared (i.e., case
sensitive or not) and a bunch of other stuff.
2. What king of objects are allowed. This is things like
organizationalUnit, country, locality, etc.
A schema definition starts by defining the attributes, then defining the
object classes. An object class tells ldap what attributes are allowed
in that class. For example, the country object class requires the 'c'
(country) attribute, and also allows the 'searchGuide' and 'description'
attributes.
If your ldap server is enforcing a schema, all entries must belong to at
least one object class. This is what the entry's objectClass attribute
is for. Second, for each object class that the entry belongs to, it will
be required to have certain attributes (specified in the class
definition), it may be allowed to have certain other optional
attributes, and it is not allowed to have any attributes that the object
classes don't allow.
You can use any schema you want, but the standard ldap schema is
typically what you want to use. In Debian, this is defined in
slapd.conf, which in turn includes files in /etc/ldap/schema. The most
important one is core.schema, which codifies the Internet RFC's for LDAP
schemas. Other interesting ones are inetorgperson.schema and nis.schema.
Object classes allow inheritance, and in the standard schema, every
object class inherits from a class called 'top'. For you, the most
interesting object class is probably inetOrgPerson, which describes a
person in an organization that's connected to the Internet.
inetOrgPerson allows a whole bunch of attributes, including mail,
givenName, homePhone, etc. In addition, it inherits from
'organizationalPerson', which allows a whole bunch of other attributes,
including street, ou (organizational unit, i.e., department), etc. In
turn, organizationalPerson inherits from 'person' which allows sn
(surname) and cn (common name), and which in turn inberits from 'top'.
Reading a schema file isn't that hard. Skip past all the the
attributetype stuff and find the objectclass definitions. Those list
what attributes an entry in that objectclass must have, and what
attributes it may have. For example, the "person" object class looks
like
objectclass ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
This says that "person" inherits from top, and an entry with objectclass
of "person" must have sn and cn attributes, and may also have
userPassword, telephoneNumber, seeAlso and description attributes. Any
other attributes are not allowed. So, a person could look like:
objectclass: person
sn: Carrigan
cn: Dave Carrigan
userPassword: foobar
I can't have a mail attribute in this entry, because 'person'
objectclass doesn't allow 'mail' attribute. However, all I need to do is
add inetOrgPerson object class to the entry, and this lets me add a
whole bunch new attributes, including mail:
objectclass: person
objectclass: inetOrgPerson
sn: Carrigan
cn: Dave Carrigan
userPassword: foobar
mail: da...@rudedog.org
initials: dhc
Technically, I can lose the objectclass: person, because inetorgperson's
inheritance tree can trace back to person. Some versions of openldap
require both, however, while I believe that later versions will actually
disallow both.
Once you've decided on the contents of the entry, you have to give it a
name. Just like a filesystem, you can go flat (all the files in the root
directory) or you can go deep.
If your directory is small, then just go flat for simplicity's sake. So,
for the above entry, pick one attribute that's likely to be unique, and
use that for its name. Your Base DN is configured in slapd.conf (the
suffix attribute). All names must be rooted at your base DN. Assuming
that I configured my directory with a Base DN of "o=Chez Carrigan" ('o'
means "organization"), then the name of the above entry could be
dn: cn=Dave Carrigan, o=Chez Carrigan
With the above entry, the following names would be just as valid:
dn: sn=Carrigan, o=Chez Carrigan
dn: cn=Dave Carrigan, o=Chez Carrigan
dn: userPassword=foobar, o=Chez Carrigan
dn: mail=da...@rudedog.org, o=Chez Carrigan
dn: initials=dhc, o=Chez Carrigan
Some of these are better choices than others. For example, I don't
recommend using userPassword in the DN :-)
Also, you don't have to use the same attribute with every every entry in
the directory. For example, I could have the following two entries:
dn: cn=Dave Carrigan, o=Chez Carrigan
dn: mail=fr...@rudedog.org, o=Chez Carrigan
If you want to go deep, it's just a question of adding more
"subdirectories":
dn: cn=Dave Carrigan, ou=Mail Stuff, o=Chez Carrigan
Here, ou is organizationalUnitName, which is commonly used as a
placeholder for lots of different things. You can use any attribute you
want, but ou is usually a good choice.
I seem to recall that later versions of openldap require that you create
the intermediate entries (i.e. you need to create a ou=Mail Stuff
entry):
dn: ou=Mail Stuff, o=Chez Carrigan
objectclass: organizationalUnit
ou: Mail Stuff
For simplicity, don't go deep until you know what you're doing.
Going back to your original queries:
A. Admin access
Create an entry for the administrator:
dn: cn=admin, o=Chez Carrigan
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: admin
userPassword: somepass
I use organizationalRole because I need a cn attribute, and I use
simpleSecurityObject because I need a userPassword attribute.
Second, in slapd.conf, set an acl on that entry so that it can change
stuff in the directory:
access to * by dn="cn=admin,o=Chez Carrigan" write by * read
B. Samba general account
I haven't done anything with ldap and samba, so I don't know.
C. Unix accounts
You will need to set up your nsswitch.conf and pam.d stuff to use ldap,
plus you need to create ldap entries with object classes of posixAccount
and shadowAccount, defined in nis.schema, plus create posixGroup entries
to represent the unix groups. A lot depends on which software you're
planning to use. For example, cyrus imap uses saslauthd, which can be
configured with a ldap backend, and doesn't use pam at all.
D. Mail forwarding
Very dependent on your mail software. I use Postfix in conjunction with
the inetLocalMailRecipient schema to control delivery. Every mail
address resolves to either a standard RFC822 address, or it resolves to
na...@local.transport. The relevant fragment of the ldap entry for
forwarding mail is
dn: mailLocalAddress=uncl...@rudedog.org, o=Chez Carrigan
objectClass: inetlocalmailrecipient
mailLocalAddress: uncl...@rudedog.org
mailRoutingAddress: unc...@some.otherisp.com
The relevant fragment for local delivery is
dn: cn=Dave Carrigan
objectClass: inetlocalmailrecipient
mailLocalAddress: da...@rudedog.org
mailRoutingAddress: da...@local.cyrus
The relevant fragment of /etc/postfix/transport is
local.cyrus lmtp:unix:/var/spool/cyrus/socket/lmtp
I define a bunch of other transports, such as local.file,
local.autoresponder, etc., and
The relevant fragment of /etc/postfix/main.cf is
virtual_maps=ldap:ldapvdomains
ldapvdomains_server_host=pern
ldapvdomains_search_base=o=Chez Carrigan
ldapvdomains_query_filter=(&(|(objectclass=inetlocalmailrecipient)(objectclass=groupofuniquenames))(maillocaladdress=%s))
ldapvdomains_domain=hash:/etc/postfix/ldap-domains
ldapvdomains_result_attribute=mailroutingaddress,mgrprfc822mailmember
ldapvdomains_special_result_attribute=member,uniquemember
And /etc/postfix/ldap-domains contains
Before setting up your mail software to use ldap for mail routing, you
will definitely need to get a solid grasp on ldap and your mail
software, because there is no real standard in that area.
E. Web access.
With Apache, you will need something like auth_ldap at
http://www.rudedog.org/auth_ldap/ (shameless plug). The Debian package
is named libapache-auth-ldap. I usually do something like this in
httpd.conf:
AuthLDAPUrl ldap:://ldap.rudedog.org/o=Chez Carrigan?cn??ou=Protected Area 1
require valid-user
Then, the fragment of the ldap entry looks like:
dn: cn=Dave Carrigan, o=Chez Carrigan
...
ou: Protected Area 1
To sign on to Apache, I use my cn (Dave Carrigan) for my user name.
F. Complicated ssh stuff with keys.
Wait a while until you understand ldap better :-)
G. Address book.
This is just a question of adding inetOrgPerson entries for anyone you
want in your address book. Give them extra ou entries in order to
classify them in other ways.
-----
As a postscript, in case you're interested, here's my LDAP entry at work
that covers a lot of the above stuff. It does include attributes from
locally-created schemas, in addition to some of the standard
schemas, so just ignore the pda* attributes and object classes. I've
also munged the mail addresses to thwart spam harvesters.
dn: uid=dave, ou=People, dc=pdaverticals, dc=com
objectClass: pdamailaccount
objectClass: pdaperson
objectClass: posixaccount
objectClass: shadowaccount
objectClass: inetlocalmailrecipient
sn: Carrigan
uid: dave
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/dave
loginShell: /bin/bash
telephoneNumber: +1 000 000 0000
title: Lead Technical Architect
ou: PDA Verticals Personnel
ou: Vertical Database Administrator
gecos: Dave Carrigan
userPassword: <elided>
pdaEmployeeType: staff
givenName: Dave
mailRoutingAddress: da...@local.cyrus
mailLocalAddress: hostm...@pdaxvxexrxticals.com
mailLocalAddress: domain-adm...@pdaxvxexrxticals.com
mailLocalAddress: domain-t...@pdaxvxexrxticals.com
mailLocalAddress: postm...@pdaxvxexrxticals.com
mailLocalAddress: postm...@pxdxaxmd.com
mailLocalAddress: postm...@pxdxaxre.com
mailLocalAddress: postm...@pxdxaxjd.com
mailLocalAddress: postm...@pxdxaxfn.com
mailLocalAddress: da...@pdaxvxexrxticals.com
mailLocalAddress: da...@pxdxaxmd.com
mailLocalAddress: da...@pxdxaxjd.com
mailLocalAddress: da...@pxdxaxre.com
mailLocalAddress: da...@pxdxaxfn.com
mailLocalAddress: c...@pdaxvxexrxticals.com
mailLocalAddress: www-...@pdaxvxexrxticals.com
mailLocalAddress: www-...@pxdxaxmd.com
mailLocalAddress: www-...@pxdxaxjd.com
mailLocalAddress: www-...@pxdxaxre.com
mailLocalAddress: www-...@pxdxaxfn.com
mailLocalAddress: da...@qxuxixzapp.com
mailLocalAddress: csma...@pdaxvxexrxticals.com
mailLocalAddress: secu...@pdaxvxexrxticals.com
mailLocalAddress: domain-...@pdaxvxexrxticals.com
mailLocalAddress: domain-...@pxdxaxmd.com
mailLocalAddress: cri...@pdaxvxexrxticals.com
mailLocalAddress: post...@pdaxvxexrxticals.com
mailLocalAddress: csbo...@pdaxvxexrxticals.com
pdalegalName: David
mail: da...@pdaxvxexrxticals.com
cn: Dave Carrigan
cn: David Carrigan
dn: cn=dave, ou=Groups, dc=pdaverticals, dc=com
objectClass: posixgroup
cn: dave
gidNumber: 1000
--
Dave Carrigan
Seattle, WA, USA
da...@rudedog.org | http://www.rudedog.org/ | ICQ:161669680
UNIX-Apache-Perl-Linux-Firewalls-LDAP-C-C++-DNS-PalmOS-PostgreSQL-MySQL
Alan Chandler
Hash: SHA1
On Monday 21 Apr 2003 7:52 pm, Dave Carrigan wrote:
>
> First of all, a quick ldap tutorial.
BRILLIANT - thank you very much. This was exactly the explanation of was
looking for. It would be really good if you submitted something like this
for adding into the howto LDAP-Implementation.
[I have spent the last couple of days from morning to night slowly working out
much of what you had said with some help from nate's reference, trial and
error and "gq" to play with. Its good to see I wasn't far wrong]
...
>
> dn: mailLocalAddress=uncl...@rudedog.org, o=Chez Carrigan
> objectClass: inetlocalmailrecipient
> mailLocalAddress: uncl...@rudedog.org
> mailRoutingAddress: unc...@some.otherisp.com
>
> The relevant fragment for local delivery is
>
> dn: cn=Dave Carrigan
> objectClass: inetlocalmailrecipient
> mailLocalAddress: da...@rudedog.org
> mailRoutingAddress: da...@local.cyrus
Where can I get the schema for inetlocalmailrecipient (or
inetLocalMailRecipient). Its not in the standard slapd setup according to
gq.
- --
Alan Chandler
al...@chandlerfamily.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+pFS/uFHxcV2FFoIRAloBAKCrjXgaGOdMcl/MvehEixjSvuiEvACgrYKX
s93fFfqDbkiV//0iwdbrGsA=
=LHIP
-----END PGP SIGNATURE-----
Dave Carrigan
> Where can I get the schema for inetlocalmailrecipient (or
> inetLocalMailRecipient). Its not in the standard slapd setup according to
> gq.
It's in /etc/ldap/schema/misc.schema. I believe that it's not included
by /etc/ldap/slapd.conf, so you'll have to change that file. My version
of slapd is 2.0.27.
--
Dave Carrigan
Seattle, WA, USA
da...@rudedog.org | http://www.rudedog.org/ | ICQ:161669680
UNIX-Apache-Perl-Linux-Firewalls-LDAP-C-C++-DNS-PalmOS-PostgreSQL-MySQL
Dave is currently listening to Blue Aeroplanes - Dark (Rough Music)