schestev,
setting up an LDAP infrastructure using SLES11 is both easy and
complex:
Easy, because you can set up an LDAP server (openldap) with a few
clicks within yast.
Complex, because that initially set up LDAP server won’t bring you
anywhere.
LDAP servers are tree-structured databases, accessed via the LDAP
protocol. But as with any database, it’s your job to structure the
database and fill in the data. Of course, typically the “end programs”
(like the mentioned Moodle, PowerSchool etc, and even SLES itself) have
their requirements concerning the structure of the database, in order to
use it. And once the database is set up according to that structure, the
programs usually help you fill the database.
A simple sample is SLES itself: Within YaST, you can both set up an
LDAP server and configure SLES to use it to ie. store account data. The
“passwd” program will automatically change the passwords in the LDAP
directory, PAM will access the info etc.
Things get potentionally nasty when you try to “integrate” multiple
applications to use the same database - they have to agree on a common
structure, where all participating programs access a common set of
records.
Within LDAP directories, a “record” (identified by its DN -
“distinguished name”) has fields (“attributes”) that need to be
described in a schema definition, sort of like a “data type”. It’s
rather common that a certain application brings it’s own definitions
with it - fortunately, a single record can reference multiple
definitions. Again an easy example: You can store user accounts in the
LDAP tree, where each user has attributes (the “fields”) from the base
account definition, SaMBa definitions and i.e. Postfix mail store
information.
It’s your job as the admin to find out what type of information each
application can store / look up in the directory, what definitions are
required and to configure the LDAP server accordingly. Then you define
the tree with all the information you’d like to have stored (partly in
independent trees, partly in combined records) and to configure each
application with the information where in the tree to look up what
information.
Now while this is confusing at first, I recommend to start with setting
up the SLES user accounts within LDAP, using the “standard” locations as
recommended by YaST, and then trying to integrate one application at a
time. That way you have a learning curve not too steep, while still
having moments of success.
Be prepared to re-design your tree after a while, as you notice that
your tree as created so far is sub-optimum and will not allow you to
integrate the application you’re looking at at that moment.
And when you have your structure ready & running, you’ll notice with
deep concern that you have not yet implemented any security measures -
neither redundancy nor access security. When you
“integrate”/“centralize”, you create greater dependency on availablitiy
and integrity of the information provided… typically, access control
goes first: You’ll have to decide what part of the tree may be visibile
to anyone, what part only to identified users (or even those of a
certain group) and who may update what.
And if you made it there and have even added redundancy and data backup
- then and only then you should actually implement this in a production
environment 
Regards,
Jens
PS: If you’re already running OES, you most likely already have the
eDirectory set up - I’m no OES guy, but from what I’ve read that’s the
part I referred to with setting up the LDAP server and using it for SLES
accounts, so you’d have that already.
–
from the times when today’s “old school” was “new school” :eek:
jmozdzen’s Profile: http://forums.novell.com/member.php?userid=32246
View this thread: http://forums.novell.com/showthread.php?t=447515
Its not as if your users will say “Wow, that is one mighty