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 _______________________________________________________________