Thomas Dodge manages the Lightweight Directory Access Protocol (LDAP) directory support for a medium-sized insurance company. Recently, he noticed an increasing number of e-mails and calls from frustrated users complaining about slow access to their software systems.
Since he knows that the LDAP directory is used for application authentication, he quickly discovers that the LDAP searches used in the process are a major cause of the problem. Many of the applications do not provide true LDAP replication, so each user query returns all the business unit records instead of just the specific one that they need to authenticate. How can he balance directory performance while still meeting business requirements?
New graduate Bess Flint was recently hired as an IT administrator for a small Missouri service company that uses an LDAP-based corporate directory. She discovered that LDAP has a powerful query engine that would allow her to prepare a variety of valuable reports, including the number of active employees, who last modified a contractor’s record and much more. What she needs now is a way to learn more about using the search tools.
Like Dodge and Flint, many network administrators have discovered LDAP is a more than just a wonderful tool for creating a variety of distributed databases. It is particularly popular as a user authentication utility, because of its flexibility and robust architecture. How many of you are aware that it also has a powerful search and query engine in the package as well? LDAP searches, if properly written, are powerful tools in analyzing your company employees, networks, and security capabilities from your LDAP directories.
This week, we will introduce you to the LDAP search capabilities and teach you to use them to deliver data reports easily and flexibly. First, you will learn the basics of the LDAP search and planning. After that, we will introduce search tips, tricks, and traps. If you do not already have a basic working knowledge of the LDAP Protocol and directory concepts, please read our previous articles on LDAP and Active Directory to orient yourself. It is time to search for that perfect LDAP query!
LDAP Search Overview and Planning
One of the reasons LDAP search is so important is because the protocol does not have a read operation. What that means for you is this is frequently the only way to find the desired information. Planning for a LDAP query is a bit like doing an online search for a library book. You need to have some idea of what you are hunting for. If you do not know what you are looking for, you are unlikely to stumble on anything useful. You need to ask yourself the following questions:
- What data am I expecting from the search? Am I limiting the number of search matches by my criteria properly?
- Which library/database am I searching?
- Which search criteria am I using? Author, Call Number, Subject, Title,
- What are the values for the search criteria? Mark Twain, 623, Business, “Lectures That Have Bored Me: Vol. 1”
Translating this example into planning an LDAP query, some of the things you need to think about include the following:
- What am I expecting to be returned? You may need to test a query of a specific record as a dry run to see what results to expect.
- Will this query take a long time? Maybe it should be run off-hours or be broken down into multiple smaller queries.
- Is another application or person running this query already? If so, maybe you do not need to duplicate the effort.
(Continued on Page 2: LDAP Search Details)
LDAP Search Details
Once you have determined what data you are looking for, you can then create the search criteria itself. At the minimum, every LDAP Search operation involves the following steps:
- Authentication as anonymous or as a specific user
- A query sent by the LDAP client/application
- A response from the LDAP server: either the appropriate values, error codes, or the server where the information can be located.
This query-response sequence may go on for several iterations and involve other servers before the search data is found and returned. To get you started with creating your own LDAP queries, the following is a list of the LDAP search equivalents. Each of these elements can be combined to create the search criteria for the query.
Directory Basics
- Directory to search – The fully qualified name or IP address and IP port number, since there may be multiple directories on one server each using different ports. The default port is 389.
- Search base – Sets where in the directory hierarchy that you want to start your search. The usual place is at the top or root. For example, ou=luthcomputer, o=us or dc=luthcomputer, dc=com.
- Scope — How far down the directory tree do you want to search? The choices are base, returning a single entry equal to the distinguished name or the unique search path to find your directory entry. One, retrieve one or more entries immediately below the search base, and sub, retrieves one or more values from the search base until reaching the bottom of the directory tree.
- Account – This is used to bind the directory for the search operation.
Search response settings
- Number of records returned or maximum search time — The default is 0 or no limit. Note that the maximum user setting may be overwritten by a system setting that ensures user searches have time limits to minimize the likelihood that a misconstrued search does not accidentally overwhelm the system resources.
- List of attributes returned — By default, all attributes found for a record are returned. The Access Control must allow for the search and attribute return to occur.
- Attributes only — This can be useful in exploring or debugging directories. It lists the attribute names that are found in a specified record but not their value.
Object/Attribute search filter criteria will be covered in a following article. In addition, there may be other advanced and product—specific settings such as LDAP extensions that give you even more powerful and useful possibilities. Read the product documentation for more information about specific tools.
(Continued on Page 3: LDAP Search Tips, Tricks and Traps)
LDAP Search Tips, Tricks and Traps
Some tips for administrators. Many LDAP searches also provide administrators with operational attribute settings, which can affect overall performance. These operational attribute settings are generally not accessible to most users. Persistent search returns results only when an attribute value changes (such as a telephone number). Finally, Virtual List View (VLV) sends the search results in subsets, which users can browse. LDAP searches can also be initiated from your Web browser as a URL. See RFC 2255 for more details.
You may want to confirm which LDAP 3 extensions are supported by your server. These could influence search time and results. For example, server-side sorting operations complete before the search result is sent back to the user.
Are you regularly checking your logs to determine what searches are running, who is running them, and the time to completion? This will give you an idea if your CPU/disk space/directory configuration settings are optimized. Most directories have log analysis utilities to aid you. Are you looking at the directory statistics to understand which searches initiated completed, and what the search entries returned? If you are having trouble with your search failing or returning incorrect data, check the following:
- Is my scope incorrect, too vague or too restrictive?
- Does the record and attributes actually exist?
- Is the record found under my search base?
- Do I have the right directory, port, or bind id?
- Is there a firewall blocking access from servers to complete the search?
- Is the directory and directory replication operational at this time?
- Is there an access control list overriding my query search or response?
Just Getting Started with LDAP Search
We have just started exploring the power and promise of the LDAP search tools. Now that you have had a taste of the ease of using LDAP utilities to manage your user ID databases, over the next set of articles, we will cover search filters, the meat of the search mechanism: the search filter syntax, and searching with popular browsing and messaging software. Just think about the power LDAP searches give you to find buried treasure in your company’s LDAP directories.
Additional Resources
http://www.hawaii.edu/brownbags/ldap/ldap2.pdf — Good presentation on LDAP and LDAP search.
http://www.hawaii.edu/ldap/details.html — Good overview of LDAP URL syntax with examples.
RFCs
The LDAP search syntax and operation is covered in detail in RFCs 2251 and 2254. A revised version of the search filter syntax is being prepared by the IETF LDAPBIS group.
http://perl—ldap.sourceforge.net/rfc.html — One location (of many) to find LDAP information
http://www.ietf.org/ids.by.wg/ldapbis — An IETF standard group revising the LDAP v3 protocol. You can join their active mailing list to stay current.
LDAP Public Directories
http://www.emailman.com/ldap/public.html — List of public directories available for testing queries.
Beth Cohen is president of Luth Computer Specialists Inc., a consulting practice specializing in IT infrastructure for smaller companies. She has been in the trenches supporting company IT infrastructure for over 20 years in a number of different fields including architecture, construction, engineering, software, telecommunications, and research. She is currently consulting, teaching college IT courses, and writing articles and a book about IT for the small enterprise.
Hallett German will soon launch Alessea Consulting — focusing on network identity, electronic directories/messaging consulting. He has twenty years experience in a variety of IT positions and in implementing stable infrastructures. He is the founder of the Northeast SAS Users Group and former President of the REXX Language Association. Hal is the author of three books on scripting languages. He is always on the lookout for challenging opportunities that will expand his directory, networking and security skills.
»
See All Articles by Columnist Beth Cohen
