Advertisment

Designing Directories

author-image
PCQ Bureau
New Update

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:

Advertisment
  • 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.

Direct

Hit!
Applies to:

Network administrators

USP:

Some key questions to ask while designing directory based applications 
Links:

http://tinyurl.com/hoj26 
Google keywords:Fedora Directory Server

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.

Advertisment

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.

Advertisment

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.

Advertisment

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

Advertisment