[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;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



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

LDAP: ACCESS & DATA ADMINISTRATION NEWSLETTER
2/05/05
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.

SOFTWARE AND LDAP OPERATIONS: FRIEND OR FIEND?

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 
list:

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 
products.
(And also in products they interface with.) The impact on LDAP administration 
will
vary -- from LDAP services to fully/partially non-functioning, not returning
expecting error codes, corrupt backups, and the awful data issues (such as loss 
of
data, data corruption, duplicate or "zombie" records). The list is endless. 
That's
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 
imports,
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 
have
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 
network,
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" 
database
that may require a complete rebuild. Long-term fixes may be more directory 
servers,
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 
detail
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 
companies
do not have "data czars" to review the quality of data and currency in existing 
systems.
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.

References:
Here are some representative references:

    TROUBLESHOOTING

Microsoft Site-Server LDAP Troubleshooting Guide
Good information that applies to most LDAP servers and problem situations.
http://www.microsoft.com/technet/prodtechnol/sscomm/reskit/ldaptsho.mspx

LDAP Errors and What They Mean
A listing of the standard LDAP error messages and what they mean.
http://www.bemsel.com/Technology/Troubleshooting/LDAP_Troubleshooting/body_ldap_troubleshooting.html

Sun - LDAP Troubleshooting
Some good things to check on UNIX LDAP servers
http://docs.sun.com/app/docs/doc/816-7511/6mdgu0h3s?a=view


IBM Notes/Domino LDAP Troubleshooting
This may apply to other LDAP servers as well
http://www-12.lotus.com/ldd/doc/domino_notes/Rnext/help6_admin.nsf/f4b82fbb75e942a6852566ac0037f284/35e2e32969a22e5985256c1d0039da76?OpenDocument

Troubleshooting Novell's eDirectory
Book with Sample Chapter
http://www.informit.com/title/0789731460

LDAP Connection with BEA WebLogic Server
Again, there may be ideas here that apply across LDAP servers.
http://www.fawcette.com/weblogicpro/2004_09/magazine/columns/troubleshootersdiary/default_pf.aspx

          SOFTWARE BUGS

OpenLdap Bugs Mailing List
With a searchable archive back to 1998. Typical of sort of bugs that
happen for LDAP servers.
http://www.openldap.org/lists/openldap-bugs/

Active Directory Backup Bug: Microsoft Comes Clean
A good overview on how bugs can be detected and dealt with.
http://www.windowsitpro.com/Windows/Article/ArticleID/21853/21853.html

          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.
http://www.mail-archive.com/archive@xxxxxxx/msg76467.html

The Real Cost of Bad Data
Shows it is cheaper to fix the data then to do nothing
http://www.melissadata.com/enews/articles/0105/9.htm


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
problems.

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:
http://www.alessea.com/newsletters.htm
_______________________________________________________________


Copyright Alessea Consulting 2005
_______________________________________________________________


Other related posts:

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