[ldapdata] LDAp Newsletter (02-05)

  • From: "General Information" <info@xxxxxxxxxxx>
  • To: <ldapdata@xxxxxxxxxxxxx>
  • Date: Sat, 5 Feb 2005 12:23:55 -0500

Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable

-- Attached file included as plaintext by Ecartis --
-- File: newsletter020505.txt

Topics:   A Catalog of Anxiety:
What Can Go Wrong With LDAP Administration: Part 2

Issue Contents:

* A Catalog of Anxiety: What Can Go Wrong With LDAP
  Administration: Part 2
* Next Time: * A Catalog of Anxiety: What Can Go Wrong With LDAP
  Administration: Part 3
This newsletter is sponsored by Alessea Consulting.

Business/IT Services for small and medium businesses.
Specializing in network identity, project management, and
business development.

Visit us and read more about the Alessea difference.

URL:   http://www.alessea.com
Mail:  info@xxxxxxxxxxx
RSS:   http://www.alessea.com/feed.xml
Phone: 860-346-9121
By Hallett German

Topic: A Catalog of Anxiety: What Can Go Wrong With LDAP
  Administration: Part 2

[We continue running a new series. It was inspired by a real
LDAP outage caused by a software bug.]

There are many things under the sun, both big and small, that
can cause a healthy LDAP server to fail and a LDAP Administrator
to lose a good deal of sleep. In our travels throughout the LDAP universe,
we haven't found these completely documented in one place. Here is our
modest attempt to correct this and provide suggested solutions as well.


Even if your hardware, infrastructure, and staff are functioning at 100%, there
are many things that can still go wrong with your software. Below is a short 

1) Software bugs
As we have seen from the LDAP Browser Developer interviews, the amount of
quality assurance testing that goes in before a product release greatly varies.
This is often due to time, resource, and financial constraints. In spite of a
developer's or development team's best efforts, software bugs do slip into 
(And also in products they interface with.) The impact on LDAP administration 
vary -- from LDAP services to fully/partially non-functioning, not returning
expecting error codes, corrupt backups, and the awful data issues (such as loss 
data, data corruption, duplicate or "zombie" records). The list is endless. 
why you the administrator should do your own rigorous testing before deploying
your directory- or security-related product suite.

2) Database Corruption/Backup
All LDAP servers use some type of database back-end to store directory data.

Eventually a good many of these will corrupt due to some event such as data 
LDAP search queries or numerous other factors. Heavy use of a system may also
contribute to database corruption. If this happens, one is forced to rely on the
kindness of your vendor's recovery/restore software and your backups -- both
which are likely to be previously untested. To avoid this scenario, one should 
redundant LDAP servers, periodically test the data and procedures of your
backup/restore process, and continuously improve your disaster recovery effort.
We hope that directory vendors continue to enhance their products in this area.

3) Replication Issues
If you have more than one directory, then you use some type of replication
to keep them both synchronized. But this synchronization may stop due to 
DNS, software, hardware, or other causes. Once detected, you should attempt to
resolve as soon as possible. Failure to do so will mean "an out of sync" 
that may require a complete rebuild. Long-term fixes may be more directory 
an improved replication design including application modification, and better
monitoring using real-time detection of when the replication first fails.

4) Access Control Lists (or Equivalent)
Standardizing the Access Control List (ACL) syntax in LDAP is making progress.
Until then, each vendor relies on their own name and syntax for access control
list. Problems that can occur are access control lists displaying more/less
than expected/or nothing at all, ACLs being so stringent as to stop all/some
operations, or ACLs not working at all. These problems may be due to the
ACL placement, ACL permissions target, an overriding ACL, a complex ACL with
unintended effects, and more.

ACLs should be tested first in a development environment to see if the above
conditions occur. They should be approved by a change control review process
so key LDAP users/administrators know when they take effect.

5) Logging Issues
Typically, each LDAP server has unique logging schemes including name, content,
and logging levels. (Although the LDAP standard does specify error codes and
messages.)Logging problems include corruption, no logs at all, or too much 
in logs. Periodically review your log's usefulness and adjust your logging
configuration settings.

6) Bad Data/Bad Imports
Data Management is the "dirty little secret" of LDAP directories. Usually 
do not have "data czars" to review the quality of data and currency in existing 
There is little effort to fix existing data issues and to ensure that future 
data is correct.
Also, given little direction or incentive, data input providers load their 
entries with
duplicates and misleading information. Bad data in LDAP directories is 
expensive in
terms of wasted time and energy in getting correct contact information.

We hope that these issues do not shortly occur for you. We will continue 
looking at
more LDAP hazards next month.

Here are some representative references:


Microsoft Site-Server LDAP Troubleshooting Guide
Good information that applies to most LDAP servers and problem situations.

LDAP Errors and What They Mean
A listing of the standard LDAP error messages and what they mean.

Sun - LDAP Troubleshooting
Some good things to check on UNIX LDAP servers

IBM Notes/Domino LDAP Troubleshooting
This may apply to other LDAP servers as well

Troubleshooting Novell's eDirectory
Book with Sample Chapter

LDAP Connection with BEA WebLogic Server
Again, there may be ideas here that apply across LDAP servers.


OpenLdap Bugs Mailing List
With a searchable archive back to 1998. Typical of sort of bugs that
happen for LDAP servers.

Active Directory Backup Bug: Microsoft Comes Clean
A good overview on how bugs can be detected and dealt with.

          DATA ISSUES

Wanted Chief Data Officer
More on how to manage the data rather cleanse it. However, data cleansing
should be part of the CDO's responsibilities.

The Real Cost of Bad Data
Shows it is cheaper to fix the data then to do nothing

Next Time: What Can Go Wrong with LDAP Administration and
Directories: Part 3

We will continue the series that first appeared in the December
2004 issue. The focus will be on software, application, and security

Topic: Articles and Comments Welcome

I welcome 100-800 word articles for inclusion in future
issues. Vendors and LDAP data administrators are
particularly welcome. Of course, you receive full credit and
ownership of your article. Thanks in advance for your help.

Please feel free to comment on how useful it was and what
you would like to see in the future.
Contact me at hallett.german@xxxxxxxxxxxx
About Hal German

Hallett German has 20 years experience in a variety of
IT positions and in implementing stable infrastructures.
This includes directories/messaging architecture,
desktop support, and IT management. Hal is the founder
of the Northeast SAS Users Group and former President
of the REXX Language Association. He is the author of
three books on scripting languages. Periodically, he
writes articles on various business and IT topics.

Contacting Hal German/Past Issues

Mail: hallett.german@xxxxxxxxxxx

Archive of the LDAP Administration Newsletter:

Copyright Alessea Consulting 2005

Other related posts:

  • » [ldapdata] LDAp Newsletter (02-05)