Designing Directories

You have your Fedora Directory Server (FDS) set up nicely
(see article in PCQuest March 2006). You are now comfortable with the Java
interface to manage it. What next? Here is a list of things you can start with:

• Live Address Book: Almost all email clients come
  equipped to use an LDAP based address book out of the box. All you need to
  specify are the details of the directory-Hostname/IP address, Port and
  Base DN to search from and you are ready to go. The more polished among the
  email clients will autocomplete the address for you.
  

• Web mail clients like Squirrelmail require plugins for
  the auto complete feature to work.
  

• Centralized Authentication: You can store user
  passwords in the directory and use it as the single point for
  authentication. Directory passwords are stored in an encrypted form where
  the encryption method can be specified by pre-pending the encrypted password
  with strings of the form {CRYPT} or {SHA1} to describe the encryption
  scheme.
  

• Per-User mail configuration: Any users mail
  configuration involves assigning values to some attributes such as email
  address and aliases, mailbox store folder and formats like mbox or maildir,
  if incoming mail is forwarded to a public POP server and vacation auto
  responders.
  

These and a host of other user configuration parameters can
be stored in the directory. All popular SMTP agents-Postfix, Qmail and
Sendmail can access these parameters.

Design considerations

Redhat has made available some very useful documentation on Designing a
Directory at http://www.redhat.com/docs/ manuals/dir-server/deploy/7.1/deployTOC.html
and we will only describe basic principles here. The manual referred to is
extremely detailed making it a very valuable resource to both new uesrs and to
professionals who are migrating to the Fedora Directory Server from Active
Directory environments or other LDAP solutions

 The design of your directory structure or
'schema' is crucial if you want your directory to do these things
efficiently. Much has been written about 'design' and most of it sounds
vague and preachy to most newbies who are looking for specific instructions and
guidelines during the design activity. Designing, however, can be an
intellectually stimulating and exciting activity when done systematically and
with clear goals and requirements in mind. It holds true for any designing
activity-designing a workflow for your organization, designing an application
interface, a transaction database or an enterprise directory. The principles
remain the same.

What for should the directory be used?

Understanding the principle use that your directory is going to be put to is
crucial. As mentioned in the the earlier article, the

directory structure is a tree with branches (sub-trees) and leaves (end-points).
If your design puts the most sought information (user's password for example)
deeply nested to about 3 or 4 levels, your client application will waste a lot
of system resources for searching and getting to the data. So the first
principle is-put your data so that the most common search will get to it fast.
Here are two examples-one is more 'structured' but marginally slower (you
can index the entries to speed up the search), the other is less structured but
retrieves results faster.

How will my directory look like?

The only thing constant in the Enterprise IT services world is that
everything changes and changes fast. It is therefore imperative that your
directory be flexible to respond to these changes. Here are a few situations
that will require to be accommodated to ensure that your directory continues to
serve even in the face of change.

Addition of new users, new locations

Estimate the rate at which your workforce is growing and make a reasonable
guess of the number of users. A design that makes a directory tree grow
laterally rather than vertically is often more flexible. A few other changes
that you can expect are creation of new locations and reassigning of users from
one location to another when they are relocated. Can your design respond quickly
to

these changes?

Addition and migration of services

Dynamic organizations that embrace change and progress enthusiastically.
This is not only reflected in the growing number of IT services that such an
organization offers to users but more importantly is reflected in better IT
service management and security. For example, if your organization puts an
authenticated proxy in place, how easy would it be to get the authentication
module to point to your directory?  Or for that matter, if your
organization migrates from Exchange to Postfix (or the other way around) how
easy would it be to migrate your mail configuration to the existing directory.
Typical problems you will face is the naming convention for your attributes.
Postfix and Qmail will by default look at different attribute names to locate
each configuration parameter for example. However Postfix can be configured to
map an attribute to a configuration parameter. The same flexibility is lacking
in Qmail which uses a custom schema that can be incorporated through a ldif

file that is distributed with the qmail-ldap package.

New and unanticipated use

Once a directory server is in place, you must try to maximize its use as the
single and ultimate repository of all authoritative information about your
organization. Organizations that are not mindful of this quickly find that they
are inundated with multiple data stores of conflicting information-one to
authenticate POP, another to authenticate SQUID and a third to authenticate
custom developed applications. Once this happens, you will waste precious
resources in keeping these disparate data stores synchronized and your users
will be forced to maintain different passwords.  One of the great features
of the FDS is its scalability (which means that if the number of objects in your
directory doubles, the impact on performance is at worst twice), extensibility
(which means that newer applications can be deployed on top of this with minimal
effort). FDS lets you easily add new attributes to describe new services and
incorporate these changes at a click of a mouse. Happily, you don't have to
register new attributes and objects with an international body — though you
must make it a practice to do this. For example imagine a situation where you
give access to certain application to a selected set of people. You have two
choices here-one create a group and add people to that group or introduce a
new attribute 'CanAccess ApplicationX' which can be false by default but is
set to true for certain users. The application can now check this property to
grant access.

Moving towards greater autonomy

If your organization has multiple branches, then consider building your
schema moving autonomous branches corresponding to each location to a server
located there. FDS can be configured using referrals so that your organization
can be viewed as a giant tree constructed out of these distinct branches. Each
branch will be under the control of the local system administrator.

RedHat has made available as a part of the deployment
documentation-a template schema for two kinds of organizations- one a large
enterprise with distributed locations and the second a small business situation.
Both come with a schema ideally suited for  for each situation. 

Gurunandan Bhat