LDAP Directories Explained

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ]

•

Table of C ontents

LDAP Directories Explained: An Introduction and Analysis By Brian Arkills Publisher

: Addison Wesley

Pub Date

: February 21, 2003

ISBN

: 0-201-78792-X

Pages

: 432

Directory technology promises to solve the problem of decentralized information that has arisen with the explosion of distributed computing. Lightweight Directory Access Protocol (LDAP) is a set of protocols that has become the Internet standard for accessing information directories. Until now, however, those curious about LDAP had no introductory source to learn how the technology can help them centrally manage information and reduce the cost of computing services. LDAP Directories Explained provides technical managers and those new to directory services with a fundamental introduction to LDAP. This concise guide examines how the technology works and gives an overview of the most successful directory products in an easy-to-reference format. Key topics include:

 

An overview of LDAP, including how directories differ from databases The LDAP namespace, with an overview of DNS, LDAP object structure, and LDAP object naming



Client LDAP operations, including directory-enabled services and applications, searches, and the LDAP protocol

 

LDAP schema, including object classes, attributes, syntaxes, matching rules, and more Directory management, including directory integration strategies, metadirectories, security, and more

 

LDAP vendors OpenLDAP, Microsoft Active Directory, and Directory Server A case study of Stanford University's directory architecture, which illustrates how integral an LDAP directory can become to a business

If you are an information technology manager, LDAP Directories Explained will provide the technical foundation you need to make sound business decisions about LDAP. If you're a developer, this straightforward reference will bring you quickly up to speed on LDAP and directories.

Page 1

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ]

Page 2

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ]

•

Table of C ontents

LDAP Directories Explained: An Introduction and Analysis By Brian Arkills Publisher

: Addison Wesley

Pub Date

: February 21, 2003

ISBN

: 0-201-78792-X

Pages

: 432

C opyright Independent Technology Guides Foreword Preface Audience About the Book Appendixes Acknowledgments Part I. How LDAP Works C hapter 1. Overview of LDAP Introducing Directories Introducing LDAP Vendor LDAP Products Why C hoose LDAP? C hapter 2. LDAP Namespace DNS LDAP Object Structure LDAP Object Naming Special LDAP Structural C oncepts Summary C hapter 3. C lient LDAP Operations Directory-Enabled Services and Applications Search LDAP Protocol APIs Summary Appendix Material C hapter 4. LDAP Schema

Page 3

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html Object C lasses Attributes Syntaxes Matching Rules OIDs Schema C hecking Extended Schema Definitions Summary Appendix Material C hapter 5. Directory Management Replication Referrals Aliases Distributed Directory Integrating Independent Directories Moving Data Between Directories Directory Security Administrative Server Parameters Other Directory Management Tasks Summary

Part II. How Vendors Have Implemented LDAP C hapter 6. OpenLDAP Namespace Operations and C lients Schema Management Security Why OpenLDAP? C hapter 7. Microsoft Active Directory Namespace Operations and C lients Schema Management Security Why Active Directory? C hapter 8. Directory Server Namespace Operations and C lients Schema Management Security Why Directory Server?

Appendixes Appendix A. C lient LDAP Operations Appendix Draft C ontrols C language API Appendix B. Schema Appendix Schema Formats C ommon Syntaxes C ommon Matching Rules Appendix C . Stanford University Directory Architecture Environment Source Systems Stanford Registry

Page 4

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html Directory Harvester Stanford Directory Active Directory Harvester Summary Appendix D. OpenLDAP Access C ontrol Element Element Element Evaluation of Access C omprehensive Example Appendix E. Active Directory C ontrols Appendix Appendix F. Directory Server Appendix Default Indexes Access C ontrol Instructions (AC Is) Plug-ins Appendix G. Online Reference Material C hapter 1 Topics C hapter 2 Topics C hapter 3 Topics C hapter 4 Topics C hapter 5 Topics C hapter 6 Topics C hapter 7 Topics C hapter 8 Topics

[ Tea m LiB ]

Page 5

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] Copyright Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and Addison-Wesley was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. The publisher offers discounts on this book when ordered in quantity for bulk purchases and special sales. For more information, please contact: U.S. Corporate and Government Sales (800) 382-3419 [email protected] For sales outside of the U.S., please contact: International Sales (317) 581-3793 [email protected] Visit Addison-Wesley on the Web: www.awprofessional.com Library of Congress Cataloging-in-Publication Data Arkills, Brian. LDAP directories explained : an introduction and analysis / Brian Arkills. p. cm. Includes index. ISBN 0-201-78792-X (alk. paper) 1. LDAP (Computer network protocol) I. Title. TK5105.5725 .A75 2003 004.6'2

dc21

2002038354 Copyright © 2003 by Pearson Education, Inc. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. Printed in the United States of America.

Page 6

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html Published simultaneously in Canada. For information on obtaining permission for use of material from this work, please submit a written request to: Pearson Education, Inc. Rights and Contracts Department 75 Arlington Street, Suite 300 Boston, MA 02116 Fax: (617) 848-7047 Text printed on recycled paper 1 2 3 4 5 6 7 8 9 10

MA 0706050403

First printing, March 2003

Dedication To my wife, Janet, who gave me support when I didn't believe in myself. I look forward to returning the favor on your book. Hopefully, it won't be a saga of the lark and the owl. And to Zooba Dooba I won't know who won the race for another couple months, but you already have my heart in chains.

[ Team LiB ]

Page 7

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] Independent Technology Guides David Chappell, Series Editor The Independent Technology Guides offer serious technical descriptions of important new software technologies of interest to enterprise developers and technical managers. These books focus on how that technology works and what it can be used for, taking an independent perspective rather than reflecting the position of any particular vendor. These are ideal first books for developers with a wide range of backgrounds, the perfect place to begin mastering a new area and laying a solid foundation for further study. They also go into enough depth to enable technical managers to make good decisions without delving too deeply into implementation details. The books in this series cover a broad range of topics, from networking protocols to development platforms, and are written by experts in the field. They have a fresh design created to make learning a new technology easier. All titles in the series are guided by the principle that, in order to use a technology well, you must first understand how and why that technology works. Titles in the Series Brian Arkills, LDAP Directories Explained: An Introduction and Analysis, 0-201-78792-X David Chappell, Understanding .NET: A Tutorial and Analysis, 0-201-74162-8 Eric Newcomer, Understanding Web Services: XML, WSDL, SOAP, and UDDI, 0-201-75081-3 For more information check out http://www.awprofessional.com/

[ Team LiB ]

Page 8

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] Foreword LDAP recently celebrated its tenth birthday. For comparison, that's about the same age as the World Wide Web, half as old as the domain naming system, and around a third as old as the Internet itself. In its relatively short life, LDAP has grown from its obscure roots as an easier way to access the X.500 directory into the Internet standard for directories, used by virtually every e-mail client, browser, and a host of other applications, with more being developed every day. Like any successful technology, LDAP has taken on a life of its own, being used in ways its designers never imagined. I, for one, never thought when helping to design LDAP ten years ago that it would be used in the diversity of applications that it is today. When I started work on LDAP, my ambitions were much smaller. I was simply trying to solve a problem on my own campus at the University of Michigan. I wanted to give desktops across the campus access to the central university-wide directory, which was based on X.500. This desire led to the creation of a protocol similar to LDAP called DIXIE. The popularity of DIXIE among a small community of similarly minded directory developers led to my joining forces with Steve Kille and Weng Yeong and to the creation of a standard version in LDAP. LDAP's breakthrough to the mainstream, so to speak, came in 1996 when Netscape galvanized the industry around adopting LDAP as the Internet's commercially accepted directory protocol. Soon, all major vendors were on board, announcing plans to develop their own LDAP implementation, and LDAP was on its way to being a part of most users' everyday computing lives. Often people that use LDAP are not even aware they are using it. It is the protocol used to access your corporate e-mail directory; LDAP may be consulted every time you access a private Web page; LDAP often stores configuration for the services you access. In these applications and others, LDAP provides the behind-the-scenes support needed to control access to resources and look up information. LDAP has also been used for applications ranging from storing and retrieving images to calculating chess moves. In this book Brian Arkills has put together a broad treatment of LDAP for readers of varying technical backgrounds. It should prove useful to those seeking a more accessible introduction to the topic than has been previously available. As for me, I look forward to seeing what the next ten years will bring for LDAP. Timothy A. Howes, Ph.D. Opsware Inc. Co-creator of LDAP

[ Team LiB ]

Page 9

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] Preface Lightweight Directory Access Protocol (LDAP) is the predominant protocol used to communicate with directories. These days, directories are everywhere. Many enterprise software packages require a directory, for example, and companies seeking to reduce costs and streamline their business also implement a directory. Not so long ago, I knew nothing about LDAP. Because Stanford University, my employer, was implementing and integrating Active Directory with its existing directory, I needed to understand LDAP and how directories worked. However, I found that the resources for a novice were sparse and hard to find, and that none of the books on the subject took me from novice to competency. During the course of the Stanford project, I met David Chappell and worked closely with him. This led to an invitation from Addison-Wesley, and I embarked on writing this book. I hope it fills the gap I found.

[ Team LiB ]

Page 10

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] Audience This book is part of the Independent Technology Guide series, which focuses on providing an independent look at a technology combined with a no-nonsense approach. David Chappell, the series editor, likes to say that the series should be called "Big Pictures 'R' Us." Each of the books in the series explains how the technology fits into the larger world. Technical managers turn to this series for explanations of all the acronyms and buzzwords they hear. This book is also appropriate for someone who is more technically savvy, but looking to break into LDAP and directories. Almost every LDAP book on the market is written for developers, and those who don't write code are left in the dark. This book takes a different approach by providing a thorough introduction for newcomers regardless of their orientation or technical background. Once you've finished this book, you might turn to Understanding and Deploying LDAP Directory Services by Tim Howes, Mark Smith, and Gordon Good to continue learning about LDAP, especially in the context of developing LDAP code.

[ Team LiB ]

Page 11

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] About the Book The book is divided into two parts. Part I explores how LDAP and directories work in general. This book is unique in its approach to the topic from a standards-based, non-product-centric perspective. Part II explores three products to highlight how LDAP is used. If you don't have a lot of time to do research, this overview of the most popular LDAP products will help you compare existing products.

[ Team LiB ]

Page 12

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] Appendixes There are also several appendixes to augment the material presented in the chapters. When additional material is available, I have included references in the relevant chapter. I'd like to call your attention to two of the appendixes in particular. Appendix C is a case study of Stanford University's directory architecture. It is intended to give you a real-world sense of how integral an LDAP directory can become to your business. Appendix G contains URLs for all the online reference material that I used while writing this book. Many people have indicated to me how invaluable this compilation of online resources was to their research. Brian Arkills, October 2002

[ Team LiB ]

Page 13

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] Acknowledgments I'd like to thank David Chappell, whose friendship and guidance made this book possible. David's openness about his own technical writing and interest in my writing led to this book. He also provided feedback on the organization of this book that was priceless. My editor Stephane Thomas was unfailingly supportive, as were all the production staff at Addison-Wesley. Special thanks go to Elizabeth Collins for the detailed copyediting. Thank you all! There are many reviewers whose contributions significantly improved the quality of writing and technical accuracy. Many thanks to Rob Weltman for reviewing the entire book from start to finish. Other reviewers include: Megan Conklin, Gabor Liptack, Jim Sermersheim, Ian Redfern, Jeff A. Dunkelberger, and Howard Lee Harkness. Ross Wilper made several significant contributions to the Active Directory chapter through his technical expertise. I'd like to thank two good friends, Brad Judy and Michael Snook, who both gave invaluable feedback throughout the book. Your honest comments and friendship mean a lot. I'd also like to thank my father and mother. The discipline and positive attitude you instilled in me were invaluable in helping me finish this book. Finally, to my high school English teacher Mrs. Perri, who endured my inane comments about how studying English lacked importance. You were ultimately right; I use English skills far more now than the math skills I so highly valued then. Thank you for your persistence, and all the difficult writing assignments.

[ Team LiB ]

Page 14

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ]

Part I: How LDAP Works Chapter 1. Overview of LDAP Chapter 2. LDAP Namespace Chapter 3. Client LDAP Operations Chapter 4. LDAP Schema Chapter 5. Directory Management

[ Team LiB ]

Page 15

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] Chapter 1. Overview of LDAP Introducing Directories Introducing LDAP Vendor LDAP Products Why Choose LDAP?

[ Team LiB ]

Page 16

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] Introducing Directories Directories are designed to help people find their way. We've all entered an unfamiliar building and used the building's directory. Without the directory, we'd have to wander the building in search of our destination. We rely on that directory without thinking much about it, unless the information leads us to the wrong place. Directories help people by organizing information With the advent of computers, there is no end of information that needs organizing so people can easily find it. Computers have always relied on directories. Even early operating systems such as DOS had a file directory so a user could keep track of data files. Directories seem to be everywhere online today, with directories that list contact information for high school graduating classes, directories that list all the movies showing, and so on. All directories have the same goal of helping us eliminate aimless searching for the information we seek. Directories allow data to be managed However, a directory should be more than just an efficient way to find information; it should also provide an efficient means of managing that information. If there are many sources for the information we seek, we may get contradictory or out-of-date information, and sifting through can be just as frustrating as aimless browsing. The directory should be a centrally managed repository. It's important to have a single, authoritative source for a particular type of information. That way, we don't have to search in several places for the information we want, and then painstakingly decide which information is correct. Many applications and services can take advantage of data that is centralized in a directory There are many uses for a directory, beyond the direct interaction a person has when manually looking up information. Application software can leverage the information in a directory to provide a more informed and better experience. Backroom services that work without our being aware of them can also make use of centralized information. These services provide the foundation that lets us interact in the digital world, identifying us to others, establishing our authority, allowing us to communicate with each other, even protecting us. Each of these foundational services, sometimes called infrastructure, must either have its own source of information about identities or rely on a common set of information. Clearly there is a benefit to having only a single set of information to manage, along with a clearly defined method of accessing this data. And there are many uses for the same piece of data, as the example that follows shows. The directory can streamline your business processes A directory should enable an organization to manage its business processes better. Imagine the following scenario as an example of why directories are making such an impact. An important new executive joins your place of business. On her first day, the security officer stops her at the front door to request a long list of information for her security badge. Once she has passed by the security officer, her first visit is to the HR department, where she is asked to fill out a form with her name, social security number, birth date, home address, department, supervisor, and so forth so she can be added to the payroll system. Then she is shown to her office. There a young technician gives her a user account and password for accessing network resources. The technician needs her name and department to give her access to the appropriate network resources. Throughout the day, administrative assistants stop by for information. One needs to take down the asset information for her new computer and assign it to her by name. Another is from the HR

Page 17

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html department again with a form for benefits. Another is from the budget department, to give her the proper budget codes for requisitions and spending accounts. The forms don't seem to stop … and much of the information is requested on multiple forms. Naturally the executive wonders why all these people can't share her information. Ideally, she would enter the information into the directory and then other people who needed the information could query the directory without wasting her valuable time. The people performing these business tasks could manually query the directory for the appropriate information, or better yet software could be used to interact directly with the directory and automate the entire process after the executive entered the personal data. The LDAP standard has been widely accepted as the ideal solution There are as many uses for a directory as there are types of information to organize. The amount of information being stored on computers is increasing at an exponential rate, so finding a good directory solution has become more important than ever. Fortunately for the computer industry, a common standard for directories has emerged in LDAP. This chapter introduces LDAP, highlights its capabilities, and explains why it has garnered widespread support as the best directory solution. To this point, I have discussed directories through common examples in everyday experience. Now it is time to look at what a directory is, and what is unique about the directory structure that makes it useful. This examination focuses on two properties:

My Company Won't Buy a Directory Maybe it should. The potential savings over the long run are more substantial than you think. For example, think of all the business processes that are keyed to correct and up-to-date contact information. When my contact information changed recently, I notified all the companies with which I did business. But I still had a difficult time because many businesses didn't use a single, unified repository for tracking that information. In some cases, I stopped doing business with them because I didn't appreciate spending my time troubleshooting their poor business process. On another track, your company may just as easily end up with a directory because it is a required component for implementing some other essential product. Directories are becoming a common prerequisite. For example, almost all network operating systems require a directory to get the most out of product features. A lot of server software requires a directory to store its configuration information. So even if your company wouldn't buy a directory to actively solve a business need, you will probably end up with one.



Structure

How does a directory store information?



Content and usefulness

What can be put in a directory, and why would someone choose

a directory over something else? This general examination of directories sets the stage for the following introduction to LDAP.

Structure The entry is the unit of the directory A directory is composed of entries. The entry is the basic unit of the directory. These entries usually contain a similar kind of information. For example, my directory could have entries about people (commonly called person entries) that include a person's name along with a phone number, and perhaps other relevant personal information. There would be an entry for each person, and each entry would consist of all the personal information known by the directory about that person. The

Page 18

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html term "entry" is synonymous with the term record or directory object; these terms are used interchangeably in the literature on the subject. The entry is composed of a set of attributes The information associated with an entry is called the attributes or properties of the entry. Again, the literature is not uniform; "attribute" and "property" are used interchangeably. An entry is essentially a collection of attributes. For a person entry, the person's name is one of the attributes, as is the phone number. Depending on how the directory is defined, entries can have a set of mandatory attributes as well as a set of optional attributes. For example, my directory might have entries with mandatory common name (full name) and surname (last name) attributes along with optional phone number, fax number, and e-mail address attributes. The entry is incomplete, and therefore not allowed, without the presence of every mandatory attribute. Figure 1-1 shows an example entry for myself. Figure 1-1. A person entry with two attributes

The attribute is composed of a type and value pair Each attribute is composed of a pair of elements. The attribute type is a label for the kind of information being stored. The attribute value is the actual data being stored. For example, cn=Brian Arkills is an attribute pair, where cn (or common name) is the attribute type, and

Brian Arkills is the attribute value. Incidentally, some attributes can have multiple values, which is an important feature for maximizing the flexibility of the data structure. The ability to have multiple values is a key advantage that LDAP possesses over common database solutions. Figure 1-2 shows an entry with a multivalued cn attribute. Figure 1-2. A person entry with a multivalued attribute

The objectclass attribute defines what rules the entry follows

Page 19

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html There is a special attribute that is mandatory to all entries, called the objectclass attribute. This attribute determines what rules the entry follows. These rules govern the content of the entry by specifying the set of attributes that are mandatory and another set that is optional. The objectclass attribute is multivalued, so the set of mandatory and optional attributes for an entry is the union of all the values of the objectclass attribute. The rules may also include the possibility of restrictions on where entries of that object class can be created. At the most basic level, the object class defines what attributes can be used in the entry. The schema of the directory determines which object classes are available in the directory. The schema essentially defines the set of rules the directory data must follow. Many types of entries are possible A directory can have many different types of entries. A directory can have person entries with name attributes, phone attributes, and others. But it can also have entries that represent products with a name, UPN serial number, and manufacturer attributes. You could delineate these different types of entries by using different object classes, or you could set up the entries to share the same object class, depending on the class's flexibility. The example shown in Figure 1-3 uses different object classes. Despite what is shown in Figure 1-3, different types of entries can exist side by side as long as structural rules don't prohibit such juxtaposition. Figure 1-3. Person and product entries in separate directory containers

What's the Difference Between Object Class and Objectclass? The terms are closely connected and very similar. Objectclass is an attribute of an entry; you use the term only when you refer to a specific entry. Every entry in a directory has the objectclass attribute with one or more values that denote the object classes to which the entry belongs. An object class is a definition of rules that an entry of that object class will follow. The term "object class" is used to abstractly discuss a set of entries that follow the same rules. All of these entries have the same objectclass attribute value. It isn't the entries themselves that are being referenced; it is the set of rules that define that class of entries. Container entries provide a structure for organization and management

Page 20

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html There is a special type of entry known as a container. A container helps to organize other entries by establishing a parent/child relationship. A commonly used container object class is ou, organizational unit. In my directory, we might want to place all of the person entries in a container named People while placing all the product entries in a container named Products. In general, this choice might make it easier to find or manage entries; however, in our example, you could just as easily find all the product entries by searching the directory for entries with the objectclass attribute equal to "part". But separating all the product and person entries into different containers makes it easy to delegate management of the entries to different people. For example, I might delegate management of the People OU to the HR department and of the Products OU to the product manager. Containers have rules, but you decide how to use them to organize Containers can have other containers as children, but child entries can have only a single container as a parent. So a pyramid (or upside-down tree) organizational structure is possible, but web or hub structures are not possible. To what extent containers are used is left to the details of implementation. You could choose to have an extensive structure of containers to provide critical organization, an arbitrary structure of containers, or no containers at all.

Content and Usefulness The leading alternative to a directory is a database, and comparing the two helps illustrate both the nature of a directory and its usefulness. After this comparison, this section provides some examples to highlight typical directory content. Note that the comparison considers only relational databases. Object databases are similar to directories, but the technology is not widely adopted.

Directories Versus Databases Directory=read; database=read and write A directory usually contains entries that are static or change infrequently, because it is designed to provide very fast response to searches and lookups. A database often contains entries that can change frequently. Databases are designed to provide data that can be easily manipulated and sustain intense processing, with both reading and writing of that data. So if you want to keep track of your company's sales, you'd pick a database, not a directory, because (one hopes that) your company would be constantly writing new sales quotes. In contrast, your company's sales contacts would be best suited for a directory, because this information doesn't change often. In general, if the entries you'd like to store change less than once a day, a directory is probably the best solution. Relational databases and directories have key structural differences Relational databases and directories also differ in terms of internal structure, and looking at this difference provides another measure of both what a directory is as well as how it is useful. Entries in databases have certain attributes that are called keys. Keys provide critical functionality for database technology by allowing you to sort entries. Additionally, you can use the keys to cross-reference information about an entry in one table to information about an entry in another table. The entries in a database have no inherent structural relationship to one another, and they don't really have names, aside from the keys (special attributes) that must be unique among all records in that table. In contrast, a directory is extremely structured. Each directory entry has a name that also defines that entry's location in a hierarchy. This relationship is discussed in more detail shortly. Another structural difference is that the attributes of a directory entry regularly have multiple values, whereas only denormalized relational databases have multiple values per attribute. The structural differences highlight special uses of databases and directories

Page 21

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html These key structural differences mean that each technology has strengths and weaknesses that predispose it toward specific uses. Databases excel at storing objects that can be sorted in different ways. Databases usually implement a locking mechanism to prevent two parties from writing the same information, whereas directories don't. Complex queries that cross-reference multiple entries are typically quicker in a database than in a directory. Databases manage large data objects pretty well, whereas a directory is not designed for this purpose. The structure of a database lends itself to tables, whereas a directory is not well suited to store tables. Databases let you store procedures for efficient processing of complex requests. Directories are suited for several commonly required purposes Directories are really specialized data storage systems. Directories are much more suited for objects that need a hierarchy. Directories can be replicated across servers to allow access from multiple locations. They are more than a name service, because they allow both searching and retrieval, whereas name services just perform retrieval. Text-based information is particularly well suited for a directory because it can be easily searched; however, any type of data can be stored in a directory. Directories manage user attributes and policies well, because most services simply need to search and retrieve these attributes. Directories also manage information for machines and applications well, especially when the information is configuration-centered or is management information. Directories usually support a very fine level of access control, allowing information to be restricted as desired.

Do I Need to Choose Between a Database and a Directory? No. They simply have different strengths and weaknesses. Each has a valid place, and it is likely that you will have both databases and directories. In fact, directories usually have a specially configured database running behind them. It might help you to think of a directory as a layer on top of a database, except that you can't access the database directly through normal means. In some cases, your company may want to synchronize some of the data elements stored in a directory and a database. For an example, see Appendix C.

Typical Directory Use You can use directories for information about people or real-world objects You can use a directory to organize or manage just about any kind of information so people can easily find that information. Directories are most commonly used for personal information, but they can be used just as readily for information about any real-world object. For example, you could have a directory with products from your place of business. People could search the directory, based on the part number or type of product, to find information about the product they need and its physical location in a store. The directory could include pictures of the products and have a nice application interface (maybe Web-based) integrated with other functionality, such as an online ordering system, so products could be ordered. Important personal information abounds, and a directory excels at storing it The directory excels at storing personal information because information about people is fairly constant. Again, the directory is optimized to respond to queries about information that remains constant over time. Person-related information is of high value to the clients of a directory, whether they are people or applications. Person-related information also has a great need to be centrally managed so it is consistent, up-to-date, and secure. Think about personal contact information. The list is lengthy: a postal address, home address, office address, multiple phone numbers, e-mail addresses, a URL to a homepage, and so on. Obviously, there is more personal information than just contact information. However, personal contact information illustrates one inherent problem

Page 22

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html that a directory helps solve, in that I must first be in contact with you in order to get your contact information. A directory can let you store your personal contact information for easy retrieval by others subject, of course, to the access controls applied to protect that contact information from untrustworthy folks who might use it to spam or harass you. Applications use the directory on our behalf However, the directory isn't just useful for others to find out about us. Often there are computer applications that need to check information associated with us. These applications do work for us behind the scenes. For example, it's fairly common for an e-mail service to query a directory with your e-mail address to find out which server your mailbox resides on, so it can deliver your e-mail to you. Additionally, some e-mail services automatically create an address book (which is stored in a central directory) so the user can simply pick a name instead of remembering an e-mail address. Many other applications and services are capable of looking up information in a directory, and some even provide an interface so people can modify directory information. Authentication credentials can be placed in a directory As another example, almost every time you log in, you are authenticating to some form of a directory. The directory validates the credentials you provide (a password or a ticket encrypted with your password) so everyone else on the network knows for certain that you are who you say you are. This authentication is critically important because it prevents someone else from impersonating you. Many network operating systems (NOSs) use LDAP as the basis of their internal directory functionality. This close integration can be an incredible benefit but also can have some drawbacks. I'll look a bit more at how a NOS might use LDAP shortly. People are more productive with a directory to support them Without the directory behind the example situations I've explored, people would be much less productive. Managing e-mail addresses and authenticating to every network resource (instead of authenticating just once) are tasks that people don't want to be bothered with, and the directory helps people manage this information. Directories have many of these behind-the-scenes uses, which ultimately benefit all of us. In fact, the major benefits of a directory are behind-the-scenes types of services, with a computer application or a computer running more smoothly because the directory is there. Machine and computer management information belong in a directory Another perfect use for a directory is in managing machines. Networked machines inevitably have configurations that need to be managed. These configurations are largely static, but keeping the information centrally lets changes be easily implemented. Networked computers have even more specialized uses for a directory. Computers that are members of a NOS service usually need to authenticate themselves. This information needs to be centrally maintained. Computers also have many characteristics such as software, environment configuration, and access privileges. Network administrators appreciate any tool that will help them manage this information, which generally changes infrequently. Microsoft's Active Directory (an extension of Windows 2000 Server) provides a good example of a specific implementation of this type of use. For example, Active Directory allows a directory administrator to define group policy directory entries that are a set of configuration information, and apply these policy entries to computer entries. This process facilitates computer management and demonstrates one way in which LDAP can be used. Directory management of computers helps people Users also experience the benefit of machine management via a directory. The previous examples may appear to benefit only computers and computer support personnel, but they also benefit other

Page 23

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html employees and customers of the company. Users don't want to memorize obscure naming conventions in order to find a network resource. Directories can help address this issue by helping users locate network resources via the directory. Imagine, if you will, the harried user who desperately needs to print a document for an important presentation in a remote location at your place of business. How does she find a printer? There are no support personnel at hand. The directory comes to the rescue, because it knows where all the printers are and the user can easily ask the directory for a printer at that location. The directory might interface with the user's laptop to configure the needed printer settings. The directory might further address the issue of multiple obscure naming conventions by providing a unified and user-friendly naming convention that hides the real naming conventions being used.

Benefits of a Directory Many IT personnel know that implementing a directory is important for their business but don't quite know how to justify the cost and effort required to their managers. Benefits 1-1 consolidates the relevant points into a useful form that you can use in such a situation. Benefits 1-2 later in the chapter is a similar summary that focuses on the benefits unique to LDAP. Use Benefits 1-1, Benefits 1-2, and Figure 1-4 to begin to build a case to your manager for implementing an LDAP directory. Benefits 1-1 Benefits of a directory



Make network administration easier - Central management of people information - Central management of computer and machine configuration - Central management of user accounts - Reduced support costs from centralized management



Unify access to network resources - Uniform naming convention - Potential for single login to network resources



Provide single destination for users to search for information - Contact information - Central location of network resources - Potential as a catalog for any data, for example, product documentation



Improve data management - Improve the consistency of data that is widely used - Provide centrally managed security for business-critical data - Organize data in a logical structure



Help streamline business processes



Provide repository and lookup for application and service data

Page 24

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

[ Team LiB ]

Page 25

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] Introducing LDAP How does LDAP work? Why has LDAP been adopted as the directory standard by so many large companies, as well as by all the major software vendors? This section provides an overview of how LDAP technology functions and why LDAP is considered so highly by the industry. Later chapters in the book expound on this overview in more detail. LDAP came from X.500 LDAP (Lightweight Directory Access Protocol) originated out of the X.500 series of International Telecommunication Union (ITU) recommendations. ITU is an international standards body, and X.500 is a set of recommendations about directories. Because of this relationship, the structure of X.500 and LDAP directories is similar. LDAP directory implementations are often also X.500 compliant, and gateways between the two directories are also plentiful. LDAP was pioneered at the University of Michigan, and there is still a free implementation available from their Web site, along with documentation, source code, and other resources. A set of nine RFC documents defines LDAP LDAP is defined by a set of published Internet standards, commonly referenced by their Request For Comment (RFC) number as published at the IETF Web site: http://www.ietf.org. The Internet Engineering Task Force (IETF) helps manage a rigorous proposal process in which ideas such as LDAP are reviewed in drafts until they are ready to be published as an Internet standard. Don't be confused about the number of RFC documents associated with LDAP. LDAP version 3 (v3) is defined by nine RFC documents. RFC's 2251 through 2256 give the core details, and were later followed by RFC 2829 and 2830. RFC 3377 followed shortly prior to the time this book went to press. It tied all of these RFCs together as the official LDAP v3 standard. In addition to these nine documents, you will find many other documents that address technology based on the core LDAP standard. LDAP comprises a wide set of technology and continues to be developed, so several documents are needed to help define its many facets. This book includes coverage of the material in the core RFCs as well as most of the other LDAP RFCs. Although the RFC documents define the standards, they don't tell the whole story, and they are certainly not enjoyable reading. But for further reference, when the RFC documents provide more detail than is appropriate for this book, they will be cited.

What Happened to X.500? There were a host of problems with X.500. It was too tied to the OSI (Open Systems Interconnection) protocols, and so wasn't well suited for the TCP-dominated world that emerged. It used a complicated encoding mechanism (although to be fair, LDAP uses pretty much the same one). Its creators were very ambitious, and so X.500 was probably too complicated for the kinds of problems that people really wanted to solve. And finally, X.500 was meant to be a global directory service, even though it wasn't clear that everyone thought this was a good problem to solve. In short, LDAP and the Domain Naming System (DNS) solved in a simpler fashion the real problems that people faced. To summarize LDAP, we'll be looking at four areas:



Namespace



Client operations



Schema

Page 26

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html



Management

These four areas coincide with the next four chapters of the book, which expand the summary information found here in greater detail. In the second section of the book, each of the chapters looks at specific vendor implementations. These chapters also use these four primary areas to organize the information.

Mycompany.com Prior to looking at the four LDAP areas, I need to introduce the example company that is used throughout the book to provide a concrete context for abstract concepts. Mycompany.com is a typical company, with sophisticated technical requirements for carrying out its business. I've intentionally left the profile of Mycompany generic, to maximize the relevance of the example. Figure 1-4 shows a representative sample of the types of business applications and IT infrastructure services that Mycompany has deployed and would like to integrate with an LDAP directory. Figure 1-4. Integration of Mycompany.com's applications and infrastructure with LDAP

Trying to Read the RFCs? If you try to read the RFCs on the IETF Web site, you may encounter several problems. You may come across references to X.500 documents that you can't find online. This is because X.500 is maintained by the ITU international standards body. ITU asks that you pay to receive a copy of its standards, and you can order a copy online from its Web site. Alternatively, I've listed a few online X.500 references at the back of the book, including an entire online book on X.500. Second, you may not understand the special coding system used in some of the definitions. It is called Backus-Naur Form (BNF), and you can

Page 27

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

read more about it in RFC 822. The RFC is oriented toward simplifying the encoding of e-mail; but if you skip several of the messaging-specific parts, you can get an idea of how to use the BNF format. Mycompany would like to use an LDAP directory to tie these applications and services together to simplify data management, cut development and support costs, and provide a single point of IT infrastructure management. Figure 1-4 further shows how each of these applications, databases, and services might interact with data in the LDAP directory. Arrows out of the directory represent a search operation (also called a query) that is the source of information for the service or application. Arrows into the directory represent a source of directory data or potential modification of existing directory data.

Namespace To find information in a directory, a common set of naming rules is needed; these rules are called a namespace Every directory needs a namespace. What, you might ask, is a namespace? As you might expect, namespace refers primarily to how entries are named. However, it can also imply other things, such as an organizational structure for the entries. Incidentally, the term "namespace" can also be used in a general sense to refer to all the objects in a specific container. The namespace serves two functions: to identify objects and to define the hierarchical structure In general, the LDAP namespace is the system used to reference objects in an LDAP directory. Each object must have a name, and the name of each object serves two purposes. First, it allows the object to be referenced. Second, it allows the object to be organized into a logical structure. Understanding the namespace is the key to understanding the structure of the directory. Because each entry indicates a location in the directory, its name must be unique Each entry in the directory needs a name for the purposes of referencing that entry. These names must be unique in an LDAP directory so you can designate a specific entry. But instead of simply naming each entry with a unique name, the namespace goes a step further and designates where in the directory's organizational structure each entry belongs. So if you know the name of an entry, you also know where that entry resides in the directory structure. Namespace hierarchy allows management control Because the namespace is organized in a hierarchical fashion, management control can be delegated at multiple points in the hierarchical structure. The hierarchy that is inherent in the namespace conveniently provides an effective means for cooperative delegation of management. This is a significant advantage of LDAP over databases, and it is usually one of the primary factors in deciding how to organize data in the directory. DNS is one common namespace Many of the directories you may have used share a common namespace, which happens to be an Internet standard: DNS. For example, when you send an e-mail to another person's mailbox across the Internet, you address it in a way ([email protected]) that conforms to the DNS namespace. The e-mail is delivered to only one person because the mail service using the DNS namespace also enforces uniqueness of names. DNS provides a namespace for many computer services. The LDAP namespace is very similar to DNS, and DNS can be employed DNS is by definition hierarchical in nature. The LDAP namespace is hierarchical too. Because the

Page 28

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html namespaces are so similar, many LDAP directories leverage the DNS namespace, so the LDAP namespace works seamlessly with DNS. This reliance helps make LDAP more attractive and provides for future development of globally integrated LDAP directories. LDAP vendors that adopt DNS compatibility allow for the possibility of seemingly independent directories being more easily connected in a global hierarchy at a later time, just as an intranet-based DNS zone might be connected to the global DNS namespace. Chapter 5 examines the integration of independent directories, and Chapter 2 introduces some of the primary concepts. Formalizing the relationship of LDAP to DNS is one of the tasks of an IETF working group; Chapter 2 also examines this relationship. DNS is not required but usually is preferred With some directory servers, clients or users can automatically locate directory servers for their local DNS zone without any prior knowledge or configuration (for more detail, see Chapter 2). But to be clear, LDAP does not require that DNS be used in forming a directory namespace. With the help of a name resolution service like DNS, a client locates a directory server on the network. Other name resolution services can be used to locate the LDAP server; however, the trend is definitely to implement LDAP with a reliance on the DNS namespace. The benefits of doing so are greater than the alternative, but there are reasons not to do so as well. These reasons are usually limited to LDAP directories with an isolated use. The root of the directory has a name Figure 1-5 shows a simple version of Mycompany's directory. The name of the root of the directory is known as the directory's base DN. The directory root is not necessarily a directory entry. The server's base DN typically matches the DNS name of the directory server and uses the domain components (dc) attribute to represent the DNS zones. However, the server's base DN does not necessarily have to coincide with the server's DNS name. The directory server's base DN might be different to allow greater flexibility in designing a distributed directory architecture across multiple directory servers. The flexibility to create a distributed directory via the namespace is a key advantage of LDAP over databases. Chapter 2 covers some of the foundational concepts behind a distributed directory architecture, like referrals, replication, and the full details of namespace. Chapter 5 addresses distributed directory architecture models, as well as the issues and solutions to integrating directories. Figure 1-5. Person and part records with DNs in an LDAP directory that integrates with the DNS namespace

Page 29

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

The DN is the name of an entry But how do you reference an entry within my LDAP directory? Each entry in the directory has a unique name known as the distinguished name (DN). Each entry also has a name local to its immediate container known as the relative distinguished name (RDN). The RDN is unique among all entries in that container. For now, think of a container as being similar to a directory or folder in a file system; Chapter 2 covers containers in more detail. The DN of each entry is formed by concatenating the RDN of the entry with the RDN of the containers between the entry and the directory root. There is a comma between the RDNs in the DN. Neither the DN nor the RDN is an attribute of the entry, but the RDN consists of one of the attributes of the entry. The RDN is the local name of an entry The RDN is an attribute type and value pair. More precisely, it can be any attribute pair (or combination of attributes) that is unique in the entry's immediate directory container. The RDN does not have to be unique across the entire directory. You can compare the RDN to the hostname, like myserver, which is unique within the mycompany.com DNS zone, but is not necessarily unique among all DNS zones in the world. Example to illustrate DN usage The DN of the person entry shown in Figure 1-5 could have been cn=Brian

Arkills,ou=People,dc=mycompany,dc=com instead of uid=barkills,ou=People,dc=mycompany,dc=com. Notice that each RDN component includes both the attribute type and value. For example, the single component cn=Brian Arkills has both the attribute type cn and the attribute value Brian Arkills. The attribute value without the attribute type would not be sufficient to distinguish the entry, because the value might refer to different attribute types on many entries. The common name (cn) of the entry in Figure 1-5 is Brian Arkills. Note that cn=Brian Arkills must be unique among all entries in the container ou=People to qualify as an RDN. As you might realize, uniqueness of a person's name isn't guaranteed, so another attribute is often used instead as the RDN. Mycompany might choose the user iden-tity uid=barkills instead as the entry's RDN, because login IDs are unique within Mycompany. The DN uid=barkills, ou=People,dc=mycompany,dc=com refers to exactly the same record in the

Page 30

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html directory namespace as the DN above. This second DN simply uses a different RDN to identify the entry desired, where the uid is my user identity or account name. Based on the desired integration noted in Figure 1-4, Mycompany's directory namespace might look something like Figure 1-6. For simplicity, almost no directory entries have been shown, but each of the containers shown (open circles) would have entries (closed circles) and possibly additional containers for further organization or delegation. For example, the People namespace might be divided with containers by department, with the entire Sales department in a container and the entire Engineering department in another. The layout shown in Figure 1-6 could be implemented differently and still meet the desired integration requirements. Figure 1-6. Mycompany directory namespace

LDAP's namespace provides many advantages The namespace that LDAP employs has substantial benefits. First, it provides a naming model that uniquely identifies entries but is flexible in that more than one name may be valid. Second, it is inherently hierarchical. This allows entries with the same naming attribute to exist in the directory in different containers. It provides a vehicle for delegation of management, application of access controls, and organization of data. Third, it usually leverages DNS, which gives an LDAP directory an advantage in integrating with other technologies, and service location resolution from anywhere. Fourth, the namespace allows LDAP to distribute a directory across multiple servers. For more detail on this topic, see Chapter 5. This benefit is significant because greater reliability, distributed load, and localized directory data are additional benefits that can be realized from this distribution.

Protocol LDAP is primarily a set of server operations At its heart, LDAP defines a set of server operations (the directory access protocols) used to manipulate the data stored by the directory. But there are many other aspects to LDAP, and people are hard at work developing draft standards that might be added to the accepted Internet standards that comprise LDAP. Some of these extensions may comprise the rules that govern the method in which data is stored in an LDAP directory, extensions of the protocol and server operations, standards for secure client authorization, architecture for ensuring directory reliability, and so forth.

Client-Server Model TCP/IP is required for LDAP

Page 31

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html As an Internet protocol, LDAP uses TCP/IP for its communications. For a client to be able to connect to an LDAP directory, it must open a TCP/IP session with the LDAP server. LDAP minimizes the overhead to establish a session allowing multiple operations from the same client session. It also gains traffic efficiencies from compression because the majority of data stored in the directory is discrete text-based information. LDAP employs BER encoding to encode the attribute value data passed between the server and client. This overly complicated encoding method is retained from LDAP's X.500 roots. Any LDAP client can speak with any LDAP server Interestingly enough, the set of LDAP operations correspond one to one to a set of standard application programming interfaces (APIs) in different languages. An API is a set of functions that programmers can use in writing software. These functions provide a higher-level deliverable by hiding the messy guts of the code from those that use it. Some APIs are closed source, meaning that the guts are intentionally hidden from everyone. Others are open source, meaning that anyone can view the details and even contribute improvements. The LDAP APIs are all open source. For an example of a function from an LDAP API, take the server operation used to add entries. There is a standard LDAP function ldap_add() in the C language API that an application would use to ask the server to perform the add operation. Similarly, the standard APIs define functions for each of the server operations defined by the LDAP specifications. Any application that used an LDAP API to interact with an LDAP server is called LDAP-enabled. The standard C language version of the API is documented in RFC 1823.

Clients The LDAP client can be standalone or integrated software The LDAP client can be either standalone software that a person interacts with by typing in the syntax as required, or it can be an integrated piece of software with much of the operation automated and the syntax requirements hidden from the user. For example, the Windows 2000 operating system has integrated the LDAP client functionality into several of its core applications. In Windows 2000, you can choose the Search option from the Start menu, and look up person or printer entries in the Microsoft Active Directory (in other words, the LDAP server) to which the computer is connected. There are many LDAP-enabled Web sites that provide a single interface (sometimes called portals) for people to use in searching and modifying entries in their company's LDAP server. In addition to these Web sites, most modern browsers support the LDAP protocol and are completely functional clients for retrieving information from LDAP. The flexibility of integration is one of the primary reasons why many software companies have embraced the LDAP protocol. The open standards model means LDAP is very easy to integrate The beauty of the LDAP open standard becomes evident when you realize that any LDAP client or LDAP-enabled application can successfully communicate with any LDAP server, regardless of the client's or server's particular operating system. The open standard, multiple-platform model makes integration easy, in a marketplace that makes integration difficult. This means that implementing LDAP in a complex, nonhomogeneous operating system environment is significantly easier than implementing other technology.

Operations LDAP has only ten operations, and this is good There are ten LDAP operations. The limited number of operations is quite important, in that client programs that interact with the directory are much simpler than client programs that interact with other similar technologies. These operations can be grouped into three basic categories with one

Page 32

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html outlier, as shown in Table 1-1. Table 1-1. LDAP operations Category

LDAP Operations

Client Session Operations

Bind, unbind, and abandon

Query and Retrieval Operations

Search and compare

Modification Operations

Add, modify, modifyRDN, and delete

Extended

Extended

The extended operation is unique among the operations. The extended operation is a placeholder for specific directory implementations to extend the functionality of the protocol but still have a predefined syntax for doing so. The LDAP designers showed a lot of forethought by including the extended operation. By standardizing a way to expand the operational functionality, they eliminated any perceived liability in the limited number of operations. Session operations affect how the client interacts with the directory The client session operations help to control the client-server session context for all subsequent LDAP operation requests from that client. The bind and unbind operations allow the client to establish an identity with the directory. This identity can be used by the directory to determine authorization to perform the other operations, and can be used to control access to directory information. The abandon operation allows the client to cancel an outstanding operation request. Query operations allow data to be found and retrieved The query operations allow the client to look up information in the directory. Most readers new to LDAP need to know how to intelligently search an LDAP directory. The search operation is the most frequently used, and skill in using it will be repeatedly valuable. The search operation has many parameters, in fact, more parameters than any other operation. This greater complexity is worthwhile, however, because it allows the user to designate sophisticated queries in a search for data within the directory. Because of the importance of the search operation, be sure to closely peruse the details and examples provided in Chapter 3. The compare operation allows a client to request a verification of the information associated with an entry. The client sends the purported value(s) of the entry, and the server responds with success if it matches or failure if it doesn't. Modification operations allow a variety of changes to be made The modification operations allow the client to change information in the directory. These operations might be restricted in some instances, for example, in the case of a public read-only directory. Of these operations, the modifyRDN operation is the only one in need of any summary explanation. The modifyRDN operation allows the client to change the name of an entry and possibly move the entry to a different container. Referrals and Unicode support extend the functionality of LDAP Two other notable protocol features of LDAP are referrals and Unicode UTF-8 support. Referrals allow an LDAP server to redirect a client to a different LDAP server to locate the data the client requests. This functionality enables integration or cooperation between directory servers and even independent directories. Unicode is a specific method of representing data in character sets that are specific to a language or locale. This means that any written language can be represented if

Page 33

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html Unicode is used to encode the data. Not all data is represented in Unicode; for example, you may have heard of ASCII encoding. Data encoded in ASCII would not allow most of the languages in the world to be represented. Unicode support extends the usefulness of LDAP to virtually any language, making LDAP a global solution. For details of the LDAP protocol, see Chapter 3 .

Schema The schema defines the rules A game without rules is chaotic and subject to the players' whims. The popular comic strip Calvin and Hobbes's "Calvinball" game zealously demonstrates how out of control life can be without rules. In this game, Calvin and Hobbes make up the rules as they play, which inevitably leads to disaster. The set of rules that defines what types of entries can be in the directory is known as the schema. If a particular object class isn't in the schema, you can't create an entry with that object class. You extend the schema to include a new object class or to allow new optional attributes on an existing object class. The schema further defines pertinent rules like what type of value can be placed in an attribute, and what operators are valid for those attributes. The operators are what the directory uses to compare one attribute's data value to another value. Greater than, less than, and equality are examples of common data operators.

Is LDAP the Final Word for Directories? Probably not. In fact, there is evidence that the Web services movement with the XML standards may add something significant to the future of directories. A new standard called DSML is emerging. This standard, however, assumes the presence of an LDAP directory. Perhaps in the future it will evolve beyond this. For more information on DSML, see Chapter 5 .

Schema Checking All new entries must pass the schema-checking process The addition of any new entry in your directory is subject to a schema-checking process. Should any of the data not meet the applicable definitions, the addition of the entire entry fails. The schema is not something one can ignore it has teeth that bite! Some LDAP implementations allow you to turn off this schema checking, but doing so is not wise. The data would lose its uniformity.

Default Schema The LDAP schema comes from X.500 The minimum set of schema objects required by the LDAP standard, as listed in RFC 2252 and 2256, will give Mycompany a functional directory. The minimum LDAP schema is largely formed from the set of X.500-defined schema objects and follows the basic rules for the X.500 schema. This is the key reason why so many LDAP products can also be X.500 compliant. Directory vendors take care of implementing this minimum set of schema objects, so you only need to be familiar with what these schema objects are and how you might use them. Most software vendors that leverage a directory find this minimum set insufficient for their purposes and further extend the schema with their own definitions.

Extending the Schema Schema syntax is hard to read, but it is very flexible Although the schema is arcane because of its syntax format, it is also the source of most of the flexibility of LDAP. Mycompany's directory can implement schema extensions to include whatever

Page 34

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html types of data the company deems necessary. The schema also lets you define new ways to interact with the directory and new ways to work with the data. Chapter 4 considers schema extensions that others have found significant. The schema is published so clients know what is supported LDAP publishes the directory schema so any client can determine what definitions and rules the server employs. The location where the schema is published is stored on every entry, and this information tells you where to look for the schema. The location is called the root DSE (Directory Systems Agent Specific Entry) container. Most LDAP directories have a single schema that applies to the whole directory, so the location is the same for all entries. Some LDAP servers may allow the definition of unique schemas for different parts of the directory. Here is a sample schema definition for the person object class:

person OBJECT-CLASS ::= { SUBCLASS OF { top } KIND abstract MUST CONTAIN { sn, | cn} MAY CONTAIN { userPassword | telephoneNumber | seeAlso | description } ID 2.5.6.6} If your curiosity is piqued, see Chapter 4, which addresses the schema in more detail.

Management Information that is centrally organized in an LDAP directory lends itself to management. In fact, an LDAP directory can become the hub of IT management. Figure 1-4 shows how centrally important the LDAP directory is to Mycompany.com, and you can easily imagine how this architecture would make management tasks easier. The support for LDAP directory management functionality is therefore very important. Management functionality that is easy to use or provides ways to simplify integration is highly desirable. Some directory management functionality is not addressed by the LDAP standards. For example, LDAP leaves the implementation of storing and retrieving the data on the server up to the vendor. Usually, a specialized database is used. This functionality can introduce a variety of management tasks and functionality, depending on what software component is chosen. In most cases, management tools are best left to vendors and market-driven competition.

Does the Schema Look Complex and Tedious? For the most part, it is both complex and tedious. Don't underestimate the importance of the schema. You may feel like the schema is boring, and the syntax not worth learning. However, the schema employed by LDAP is one of the greatest features of LDAP, because it lets you design how data is represented, what data is allowed, where it is allowed, and what additional operations can be performed on that data. The other areas of LDAP may be flashy, but they all derive their functionality from definitions in the schema. Without the flexible model LDAP uses with the schema, a lot of the flashiness and all of the extensibility would be gone.

Distributed Directory The LDAP standard leaves the implementation of replication to vendors Possessing a fault-tolerant directory is of high importance to Mycompany because the company wants to make the directory a central focus of critical business data and processes. Most vendors

Page 35

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html have implemented some form of replication to allow portions of the directory to be copied to multiple servers. Employing replication copies a directory or portions of a directory across multiple LDAP servers. Distribution via replication provides several advantages, including load distribution and protection against data loss. For more details on replication, see Chapter 5 . A distributed directory has many advantages However, replication is not the only way to have a distributed directory. Different LDAP servers can host different portions of the directory namespace with references to the other LDAP servers. The namespace can be divided in any way desired. This type of distribution provides advantages, such as storing information about your European office on LDAP servers located in that office. This would decrease the dependency on long-distance connectivity between geographical locations. Another advantage might allow politically divergent departments to run their own server. This would enable separate management of information that each department feels that it owns. The flexibility that LDAP provides in terms of namespace provides benefits in simplified management.

Integration and Data Manipulation Integrating independent LDAP directories and servers from rogue departments or mergers will further empower the value of Mycompany's directory. As discussed previously, LDAP supports referrals that allow one LDAP server to reference another. These referrals can be used to connect servers. Integration via other methods can also be critical to keeping data consistent and authoritatively controlled across your organization. For some other methods, see Chapter 5 . LDIF and other features allow duplication of data between servers There is also an LDAP standard that allows directory data to be copied between servers. The LDAP Data Interchange Format (LDIF) standard provides a means for a directory administrator to move directory data between servers in a file format. The LDIF standard also gives the administrator a way to make batch modifications to many entries using search-and-replace text-manipulation tools. For more detail on the solutions LDAP provides in this area, see Chapter 5 .

Security Authentication, authorization, and encryption are needed to secure information The term "security" is used in a broad sense in the computer industry. In discussions of computer security, typically two areas are of concern: authentication and authorization. Authentication is the means of proving we are who we say we are.Authorization is the means of designating access permissions to users. When we add the complexity of operating on a network, there is a third area of concern: privacy. Privacy is the means of ensuring that data is kept safe so that it is available only to those for whom it is intended. Some form of encryption is usually used to keep data private. LDAP supports cleartext, Kerberos, and SASL for authentication LDAP supports many authentication methods. LDAP v2 and v3 both support simple authentication (cleartext), Kerberos, and digital certificates. LDAP v2 supports Kerberos v4, whereas LDAP v3 adds support for Kerberos v5 via Simple Authentication and Security Layer (SASL). You can find the standard designation for Kerberos under RFC 1510 and 1964. LDAP v3 also supports the SASL. SASL offers a way to add authentication mechanisms to any protocol. Examples of such mechanisms are Kerberos 5 and DIGEST-MD5. The SASL standard designation is specified in RFC 2222. LDAP v3 identifies Transport Layer Security (TLS), the successor to Secure Sockets Layer (SSL), as the way to authenticate with digital certificates. TLS is documented in RFC 2246. Given that LDAP is an Internet standard, you are probably not surprised to learn that Kerberos, SASL, and TLS are also Internet standards.

Page 36

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html Implementation of authorization is left to the vendor Currently, LDAP has no specifications for authorization. With authorization or access control, you can control access to entries and even attributes. You can allow or deny specific users or groups of users access to entries. The access levels vary between permission levels such as being able to read or write to the entry. Because there is no agreement on authorization in the LDAP standard, vendors are left to implement their own authorization model. Discussion and work is under way in the IETF on this subject, so in the future this may be part of the LDAP standard. This lack of standardization means that this is one of the areas Mycompany will want to scrutinize closely with respect to its choice of a vendor. LDAP supports SSL and TLS for data encryption privacy LDAP also supports session encryption for privacy. All information that is communicated during the client-server session can be encrypted so eavesdroppers are foiled. Both SSL and TLS are supported. TLS is the successor to SSL, and can be thought of as SSL v3.1. Both SSL and TLS are based on public key certificate technology, which depends on the server having a certificate from a trusted certificate authority server. Additionally, clients can obtain certificates and in some cases use them as a valid form of identification (authentication). Although this requirement may pose some hurdles, including management of certificates, the resulting security can be deemed well worth the trouble. Encrypting the session can provide privacy to the directory information passed over the wire. The information in your organization's directory may be some of the most sensitive data you have, possibly personal and proprietary, and your organization won't want this information passed "in the clear" for the advantage of outsiders. Session encryption is critically important if simple authentication (cleartext) is the only available authentication method for a specific client.

Does LDAP Provide Security? I often talk to people who confuse LDAP as a generalized solution to security concerns. There is a perception that "LDAP" is a security buzzword. LDAP is a directory technology, not a security technology. LDAP directories commonly use security technology, like Kerberos, to provide secure access to the directory, and they may also be used to store security-related information such as X.509 certificates or authorization information. But LDAP itself doesn't provide any security services. LDAP as a standard or a protocol still has room to grow before I'd associate security with it. Don't get me wrong, in most products it is implemented relatively securely. However, the IETF should standardize many of the security features that vendors have implemented. Additionally, the protocol should require some input stream validation mechanism so a client can't pass commands to the directory server via a buffer overflow or other nastiness.

[ Team LiB ]

Page 37

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] Vendor LDAP Products Part II covers several of the most popular LDAP products. A few notes about the trends and diversity of offerings are worth mentioning here. Vendors often use a directory to enable their network operating system One strong trend has vendors using LDAP to support their network operating system (NOS). This is innovative and provides nice opportunities to integrate many infrastructure services with all the benefits of LDAP. However, the offerings from these companies usually limit the integration with products outside that vendor's software suite. This is made worse when you must employ the vendor's NOS to use the LDAP directory. Integration is nice, but not integration without freedom to choose the best components. LDAP has a strong open source movement Another trend that has continued throughout LDAP's history is the open source movement. This movement is important in light of the previous trend. The open source movement has helped ensure that some minimum level of integration is kept standard and, in turn, has put pressure on vendors to work with others. Open source LDAP software offers the ability to choose components and eliminate dependence on a single vendor. There are a lot of LDAP product offerings available A final trend to note is that almost every large software company has an LDAP directory offering. In addition, several small company offerings also offer LDAP directory products. This diversity of products is great for the consumer, because it provides greater choice and means that vendors have to provide real competitive advantages to capture our attention. Table 1-2 lists most of the LDAP server offerings.

[ Team LiB ]

Page 38

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] Why Choose LDAP? The reasons to use LDAP are overwhelming. Simply put, LDAP is the best show in town if you want to use a directory. Consider the many companies and organizations that have already adopted the technology. Benefits 1-2 summarizes a list of advantages of LDAP, but you probably are already familiar with them. This list, together with Benefits 1-1 and Figure 1-4, would make a good start on justification for deploying a directory. Table 1-2. LDAP servers Vendor

Product Name

Computer Associates

eTrust Directory

Critical Path

CP Directory Server

IBM

SecureWay

Sun AND Netscape

Directory Server (used to be iPlanet and Netscape Directory Server)

Microsoft

Exchange 5.5 AND Active Directory

Netscape

Directory Server (no longer offered)

Novell

eDirectory (formerly NDS)

OpenLDAP

OpenLDAP

Oracle

Internet Directory

Syntegra

Global Directory AND Aphelion Directory

University of Michigan

Slapd

Benefits 1-2 Summary of LDAP Advantages



Entries are organized in a distinct hierarchy. This provides the means to delegate administration, apply access controls, and enjoy other information management benefits. Even the name of an entry reveals information about the entry.



Attributes of an entry can have more than one value. The structure of an entry doesn't need to be extended to permit additional data. An entry can also have multiple names, each of which is unique across the directory.



An LDAP directory can be distributed across multiple servers. This design distributes the load and provides other management benefits.



LDAP is an open standard, with multiple-platform support. An LDAP client on any platform can communicate with any LDAP server. So there is less reliance on a single vendor.



The LDAP client requires very few resources to run, and it can easily be integrated into other software. The LDAP operations are few in number, which makes it easy to interact with the directory. Session traffic is encoded and uses TCP, so network communications are

Page 39

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html economical.



LDAP has a standardized API for multiple platforms. As a result, your developers can leverage the information in the directory when developing new applications instead of having to rebuild this information. This saves money and time, while opening up the possibility for new cross-functional applications based on access to data that was not previously available.



LDAP provides easy integration with existing standards because LDAP uses other accepted standards, including TCP/IP and DNS. Standardization of integration methods with other standards is an ongoing process. Later chapters note the results of this process.



LDAP supports strong authentication and encryption methods.



LDAP uses Unicode UTF-8 so almost any language character set can be represented. This makes an LDAP directory capable of supporting international organizations in the native language.



LDAP employs an extensible schema, which allows further operability to be added. Operations and data must conform to the schema, which improves the quality of data.



The usefulness of LDAP is being extended constantly, because of the widespread adoption of the view that it is the future of directory services.

Cross-technology integration has become a strength of LDAP Most organizations are now taking the next step and looking for further ways to integrate LDAP with existing technologies. This step extends the usefulness and value of the investment made in LDAP. There are many examples of leveraging other technologies to extend the usefulness of LDAP. This is because LDAP is based on a clear standard that easily integrates with other existing standards.

[ Team LiB ]

Page 40

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] Chapter 2. LDAP Namespace "Namespace" implies that a name is not simply a name, but holds meaning in terms of structure as well. The term takes two different aspects of the directory and seeks to tie them together: how to name things and how to organize them. The definition of a service's namespace is critical. It may be obvious, but a namespace lets you find things. Namespace is the set of conventions used to identify all the objects in a given environment; in other words, it is the naming system. Without a namespace that we agree on, you and I might be referring to the same thing, but using different languages. A good namespace also ensures that one object's name doesn't conflict with that of another object. Namespace is probably the hardest concept presented in this book, so take solace if it seems confusing. To help introduce the concept of namespaces, the next section examines some examples and the properties of namespaces. The rest of the chapter focuses on the namespace that LDAP employs. The namespace includes more information than just the immediate identifier A good analogy that illustrates the use of a namespace in the real world is the postal address system used worldwide. In the postal namespace, a letter is addressed (or named if you will) as follows: Person's name Street number Street City, State/Province/Region Zip code Country This name (address) tells us many things by the way it is constructed and the value of each component, while also uniquely designating the recipient. We know that the person lives in the country listed, in the state listed, in the city listed, on the street listed, and so on. We further know the letter is intended for the person who lives at this address, not a person by the same name who lives elsewhere. By using a hierarchical namespace, you can delegate information management But consider another point that is well illustrated by this postal example. Because this namespace is organized in a hierarchical fashion with locales of diminishing scope clearly designated, management involving the object (in other words, the recipient) can be delegated. In other words, when the reader drops a letter in the mailbox to this person, it can first be sent to the postal service responsible for the country listed. After that, it can be sent to the state postal service, and so on, until it reaches the local post office and can be delivered. The hierarchy that is inherent in this namespace conveniently provides an effective means for cooperative delegation of management. You can use the namespace for other management purposes The postal example illustrates a namespace that is used to uniquely identify objects and establish structured relationships between those objects. Besides identification and structure, the namespace can be involved in accomplishing several other directory management operations. As examples of such functionality, most vendors implement data partitioning and replication. Chapter 5 covers these and other special structural concepts. Namespace can also refer to a specific directory implementation

Page 41

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html When the term "namespace" is used in the context of a specific directory namespace, a slightly different meaning is intended. In this context, it isn't the naming system being referenced. In this context, the term refers to all the objects in that directory and the specific structure that was chosen. With LDAP, there are seemingly two names for every directory term, so be prepared for a multitude of new vocabulary words with duplicate meanings. You may hear the term directory information tree (DIT) being used to refer to a specific directory namespace.

[ Team LiB ]

Page 42

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] DNS The server's DNS name is the basis for the name of the root of the LDAP directory The domain naming system forms a portion of the foundation for the LDAP namespace, and it is also a good example of a namespace. Exploring how DNS works will help underline key points about LDAP. As noted in Chapter 1, the DNS name of the LDAP directory server can be particularly important in determining the name of the root of the directory, which is the directory's base DN. Whether DNS is used in naming affects the implementation of an LDAP namespace. A directory's base DN doesn't have to match the DNS name of the directory server, and usually the two don't match when a directory distributed across multiple servers is desired. Aside from this connection to the namespace, DNS can also play a critical role in the process of the LDAP client locating the LDAP directory server. DNS does not have to be used in the location of the server, but frequently it is. DNS maps a human-readable name to a computer-readable name DNS is a distributed directory service that is maintained by thousands of servers across the globe. There are billions of records in this directory, which map an IP address to a computer name and vice versa. IP addresses are numbers that are the "name" that one computer uses to refer to another computer. People know computers by alphanumeric names. A sample record could be

host.mycompany.com. IN A 127.42.12.6. This record denotes that host.mycompany.com is the human-readable name of the computer at the IP address 127.42.12.6.

DNS Hierarchy A hierarchy is employed to provide a clear basis for authoritative name resolution These records are distributed across millions of files called zones. Each zone holds a copy of records for the DNS namespace for which it is authoritative. In other words, each zone allows changes to only a small portion of the entire DNS namespace. The host.mycompany.com computer record belongs to the mycompany zone. The mycompany zone belongs to the com zone. The com zone belongs to the root zone. The root zone is the topmost zone in all of DNS. Figure 2-1 shows a diagram of the hierarchy of DNS zones. The zone file is kept on the authoritative DNS server for that zone. Each parent zone is the authority for distinguishing which DNS server is authoritative for any child zone. A single root zone holds the authoritative records for each of the first-level DNS zones. This forms a hierarchy, which client computers can query with a reasonable assurance of getting authoritative name resolution. Figure 2-1. Hierarchy of DNS zones (the DNS namespace)

Page 43

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

DNS Resolution The hierarchy provides an efficient way for a client computer to perform name resolution The DNS namespace provides a system both for organizing computer name records and for resolving the location of the computer name. The client computer is typically directed to query the authoritative DNS server of the local zone for name resolution. For example, the computer host.mycompany.com would be configured to query the DNS server for mycompany.com. Should host.mycompany.com want to know the IP address for unknown.whitehouse.gov, it would first ask the DNS server at mycompany.com. mycompany.com would refer it to the com DNS server. The com DNS server would refer it to the root DNS server. The root DNS server would refer it to the gov DNS server. The gov DNS server would refer it to the whitehouse.gov DNS server. The whitehouse.gov DNS server would then reply to the client with the IP address of unknown.whitehouse.gov. Usually DNS servers cache information about important zones like the root and first-level DNS servers, so in reality the process described would follow a much shorter path.

Basic DNS Record Types There are several basic types of DNS records. Table 2-1 lists these records along with a short explanation.

How LDAP Uses DNS Chapter 1 describes an informal connection between LDAP and DNS. This connection primarily provides a mechanism for an LDAP client to locate the directory server for a particular directory. The RFCs that define LDAP don't refer to DNS, but they allude to it. For example, RFC 2255 defines the LDAP URL syntax, which I return to later in this chapter. On close examination, you would find that the hostname component of this syntax clearly relies on DNS, although DNS isn't mentioned. So the reliance on DNS is informal, but in practice every LDAP product expects LDAP clients to use DNS to locate their LDAP directory server. There are good reasons for this dependency. One reason is that DNS is the dominant name resolution standard, and another is that the transmission protocol that LDAP uses is TCP, which relies on DNS. Table 2-1. Basic types of DNS records Record Type

Class

Explanation

Address

A

Address records simply map a computer name to an IP address. More than one IP address can be assigned to a computer name by using a second A record. More than one computer name can be assigned to a single IP address,

Page 44

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

but you should use a canonical name record for this purpose. Canonical Name

CNAME The canonical name record is sometimes known as the alias record. It is used to allow a computer to be referred to by more than one name; the secondary name is entered in a record with the IP address of the primary name. Multiple canonical name records are allowed.

Mail Exchange

MX

The mail exchange record is used to indicate the IP address e-mail for a given name. You can designate that all mail for a zone should be delivered to a single IP address.

Pointer

PTR

The pointer record has the opposite function of an address record. It maps an IP address to a computer name. This allows computer services to verify that a request coming from a client is not being hijacked by a nonauthorized computer.

Name Server

NS

The name server record is used to denote the authoritative name servers for the zone.

Start of Authority

SOA

The start of authority record is used to communicate with other authoritative name servers in the DNS hierarchy. Information on how often to check for updates is stored in this record.

Service

SRV

The service record is used to indicate a network service. Several LDAP vendors use this record to provide client location of a server.

DNS is used to register a directory service One important implication of LDAP using the DNS namespace is that by registering a DNS domain name to connect a host or zone of hosts to the Internet, you may inadvertently also register for a directory service namespace. There is a parallel in the e-mail delivery namespace with the MX record and many other network-based services. When I register an A record for mycompany.com with an authoritative DNS server, mycompany.com may become a valid directory service namespace. Most vendors currently expect that your LDAP directory has an A record for each directory server. Some vendors further expect that if you deploy a directory that is distributed across multiple directory servers, you will make each of the directory servers subordinate in the DNS namespace. So for example, if I distributed the mycompany.com directory, the directory servers might have A records of dir1.mycompany.com, dir2.mycompany.com, and so on. LDAP is making increasing use of DNS for its namespace functionality In addition to the informal expectations that have become practice, there has been some formal work with regard to the relationship between DNS and LDAP. RFC 2247 provides a clear standard for DNS to easily be incorporated into the namespace that LDAP uses within the directory. The domain component (dc) attribute is defined, and it can be used as a naming attribute in the directory for container objects. Within the IETF, there is other extensive work on using DNS to extend the LDAP namespace functionality. Draft documents include a proposal to use DNS SRV records for clients to locate an LDAP directory for a given namespace. This proposal has gained significant support, as Microsoft's directory implementation of it demonstrates. It will probably supplant the existing informal practice within a few years. Another proposal suggests using DNS SRV records with referrals. Chapter 5 discusses referrals.

[ Team LiB ]

Page 45

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] LDAP Object Structure The internal structure of an LDAP directory primarily provides organization of entries via a hierarchy. The structure is critical to the usability and manageability of the directory. The structure can also allow the benefits listed in Benefits 2-1 to be easily provided. Benefits 2-1 LDAP namespace benefits



The structure can make it easier to distribute information across multiple servers. A directory distributed across multiple servers in turn provides greater reliability and the possibility of locating directory information close to remote locations.



The structure can make management of access control simpler.



The structure can enable applications with specific directory requirements to be integrated into your directory.



The structure can simplify directory maintenance by grouping similar entries together.

The structure itself does not provide these benefits. For Mycompany to realize these benefits depends on its directory implementation and design of the namespace. How each of these benefits is provided is a topic in itself (see Chapter 5). A namespace with a hierarchy of structure has other benefits As noted in the postal example, organizing directory objects hierarchically provides an effective means for delegating management of the entries. To add entries, you would need some type of delegated authority in the appropriate place in the directory. The layer of management that is created by the existence of a structure helps to enforce consistent data in entries. Containers enable structure A hierarchy is possible in the LDAP directory because of container entries. Container entries are special entries that allow other entries to be placed hierarchically beneath them. An entry beneath a container is sometimes called a child of the container, or a subordinate entry to the container. The container is sometimes called the parent of the entries beneath it. You can also refer to the relationship between the container and entries beneath it by saying the entries are contained by the parent.

Allowed Structures Only a specific kind of structure is allowed in LDAP The namespace in an LDAP directory allows no arbitrary connections within the structure. Structures similar to the linked relationship between Web pages (in other words, a Web structure) are not allowed. More specifically, a container can have only a single parent directly above it. A container can have multiple child containers, but only a single parent. This type of structure is commonly called a tree structure. This term may remind you of the alternate term for namespace: directory information tree (DIT). Figures 2-2 and 2-3 show examples of valid and invalid namespace structures. The regulated approach to the structure leads to little service disruption when new entries are added, because only the new entry is written, and no existing entries must be modified. Figure 2-2. Example of valid hierarchical namespaces in an LDAP directory

Page 46

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

Figure 2-3. Examples of invalid hierarchical namespaces in an LDAP directory

LDAP Containers With LDAP, any entry can become a container You may assume that containers in an LDAP directory have an attribute that identifies the entry as a container. But this isn't the case. An entry becomes a container when entries are placed under it, but the LDAP directory makes no modification of the container entry when this happens. With LDAP, every entry holds the possibility of becoming a container, and this design supports many hierarchical opportunities. You create a container by creating an entry below another entry You might also assume that container entries have an attribute that lists all the entries that are contained within that container. This also isn't the case. The hierarchical structure is not stored by any special mechanisms aside from the name of each entry. You create a container by creating an entry beneath another entry! This concept takes some getting used to, as logic suggests that the container entry would need to be modified. However, specific LDAP implementations may go beyond the LDAP specification and have special attributes for child information in order to offer additional

Page 47

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html management functionality. Although every entry can be a container, some object classes may make more sense In some LDAP server implementations, there may be restrictions on which object classes an entry must have to become a container. These restrictions are called structure rules (for more details, see Chapter 4). In general, there are several object classes that are regularly used as containers for historical reasons. These object classes are favorites because they are the only allowed containers in X.500. Table 2-2 lists these object classes with a short description of each object class along with why they might be useful as a container. Among these object classes, the organizational unit is used most widely. It is frequently employed for a wider variety of purposes than simply political structure. You don't have to use these object classes as the containers in your directory, but you may find that there are good reasons why these classes are favored.

Structure Rules Structure rules restrict where an entry of an object class can be created LDAP also supports structure rules specific to an object class (for detail beyond what's here, see Chapter 4). This functionality is not necessarily part of the LDAP standard, but it is implemented by several vendors. Object class structure rules impose restrictions on where an entry of a particular object class may be created. For example, I might associate a structure rule with the organizational unit object class. This structure rule might require that all entries of objectclass=organizationalUnit be immediate children of entries of

objectclass=organization. This rule imposes an additional restriction in the namespace, and it also limits functionality. Structure rules are enforced by the schema-checking process. Mycompany will want to review any structure rules specific to its chosen vendor. Table 2-2. Common object classes used for containers Object Class Type

Attribute Name

Country

c

The country entry can provide geographical structure. As such, you typically use them when you want to split directory information across servers based on geography.

Locale

l

The locality entry also provides geographical structure to subdivide the country container.

Organization

o

The organization entry provides a political structure.

Organizational Unit

ou

The organizational unit entry also provides a political structure.

Explanation of Use

Naming Contexts Naming contexts are used to refer to portions of a directory The name of each top-level container has the distinction of also being called a naming context. The naming context is greater than just the container, though. A naming context is a contiguous subtree beginning at a top-level container. For example, if you referred to the Accounts naming context in Mycompany, you would mean the Accounts container, all its child entries, and all containers and

Page 48

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html entries beneath the Accounts container, as shown in Figure 2-4. In this way, you can conveniently refer to portions of the directory. The naming context is the same terminology as a directory suffix (or a context prefix in X.500). The Accounts naming context is the Accounts suffix. Figure 2-4. Example of naming contexts in an LDAP directory

The directory has no single root entry; instead, all the naming contexts are peers connected by the root DSE There is really no directory object at the root of an LDAP directory. Instead, there is a special entry that is like a root object, called the root DSE entry, that lists all the naming contexts on the directory server. The directory uses the naming contexts to quickly differentiate whether a request for an entry is within the known naming contexts. A flat namespace allows quick growth In a directory with a flat structure, organization and management are typically disregarded, while adding new entries is increasingly easy. As you can see in Figure 2-5, the lack of structure encourages easy growth because there is only a single organizational container in use, with little to no restriction placed on additions. But in this model, consistency and scalability can become a nightmare. Scalability becomes an issue when generic queries regularly return large numbers of entries. Scalability can also be an issue when the number of useful unique names reaches its limit. This limit may be reached because only one entry in any particular container can be named with any specific name. A hierarchical model sidesteps these problems by organizing entries at multiple levels in the hierarchy. Figure 2-5. A flat namespace in an LDAP directory

Page 49

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

Don't Be Fooled by the Figures Note that the figures throughout the book include a root entry, when in actuality there is no such entry. This is purely to allow you to know the context of the namespace being pictured. It is a common practice in diagramming directory namespaces, but it fooled me for a long time into thinking there really was a root entry. There are four basic divisions of a directory namespace that are useful: 1.

Political/functional

Dividing information based on an organization, or difference in

functional needs. For example, you might separate the HR directory information from the Marketing directory information. 2.

Geographic

Dividing information based on the location of the clients who will be accessing

the information or based on the location of the real objects that the information in the directory represents. For example, you might separate the personal information for individuals in Europe from the same information for U.S. citizens. 3.

Resource-based

Dividing information based on the type of resource. For example, you

might separate the printer information from the server information, or separate public resources from private resources. 4.

User classification

Dividing information based on users' needs. For example, you might

separate information for managers from information for staff.

How Do I Decide How to Structure My Directory? The decision on how to structure a directory can be a difficult one. Equally hard can be the decision as to when to divide up a flat structure or a single container. Hybrid combinations of the four basic divisions of a namespace can frequently fit a situation very well. Usually a geographical division is accompanied by distributing the directory namespace across multiple servers. Chapter 5 covers distributed directory servers in more detail. Another factor in the decision is a requirement to provide certain kinds of directory data in a more fault-tolerant manner by replicating it across multiple servers. LDAP vendors have differing requirements on what the smallest unit of replication can be, and this will affect design decisions. Keep in mind that the single biggest reason to implement structure is to simplify management of the information. If you implement a structure with no clear management goal, you will come to regret your choices. While looking at each of the models for

Page 50

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

implementing a hierarchy, you should consider the following questions:



Will users of the directory need different levels of access to the information? If so, what structure can be implemented to simplify the access management?



Does the directory help to provide management of computers or other devices? If so, are there compelling reasons to manage specific computers differently from others?



Are the political or organizational divisions under consideration? If so, make sure that you make it easier to manage resources, users, or directory information. The most frequent mistake is to blindly implement the structure based on internal organizational boundaries that require no different level of management.



For every new container, ask, "What administrative management purpose does this container serve?"

Try to keep your directory as flat as possible, while having enough structure to delegate management and accomplish other goals like those in Benefits 2-1. Too much structure can be restrictive in future situations. For example, if an extensive political structure is used as the basis of division of the namespace, a later reorganization or company merger may pose serious issues. Interestingly, the LDAP standard has a requirement that also may influence the design you implement. LDAP clients are only required to support a hierarchy with ten levels between the root and any entry. If you implement something more complex, it may not work! These guidelines may not create your structure for you, but they should help.

[ Team LiB ]

Page 51

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] LDAP Object Naming With a firm grasp on DNS and the acceptable structures allowed in an LDAP directory, you are ready to consider the internal details of the LDAP namespace. The namespace that LDAP employs is highly flexible, allowing for multiple names for each entry and the possibility that different attributes can be used in forming the name. The naming flexibility LDAP provides doesn't come at the cost of ensuring that each entry has a name that is unique across the directory.

Relative Distinguished Name (RDN) The RDN is an entry's naming attribute; it has a unique value in the container of the entry The relative distinguished name attribute provides a unique name identifier for each entry within a container. For example, Figure 2-6 shows a person entry with an RDN of cn=Brian Arkills. There cannot be two entries with the same RDN value within the same container. So there can be no other person entry in the People container with cn=Brian Arkills, and within any specific container the cn attribute value must be unique for subordinate person entries to that container. The RDN attribute is one of the entry's attributes, known as the naming attribute for that type of entry. But generally speaking, the naming attribute for any particular object class is not forced to be a specific attribute. In the object class definition, some LDAP vendors do force a specific attribute to be the naming attribute, but this is not part of the LDAP standard. In the example in Figure 2-6, the cn (common name) attribute is the naming attribute of the person object class. Figure 2-6. An example of an RDN

You can substitute a unique string of numbers called an object identifier for the attribute type in an RDN You can use a special string of numbers called an object identifier (OID) in place of the attribute type. Every attribute type has a unique OID assigned to it. For example, the cn attribute's OID is

2.5.4.3. The OID is used to uniquely identify an attribute type. For example, you might define an attribute type called myattribute. I might also define an attribute type called myattribute. How can we know if they are the same attribute? By comparing the OIDs of the two attributes. For more detail on OIDs, turn to Chapter 4; for now, you need to know that an OID can be substituted for the name of an attribute type. The OID is relevant to namespace when an OID is used as the naming attribute. For example, a valid RDN of the entry in Figure 2-6 is 2.5.4.3=Brian Arkills.

cn is frequently used in RDNs, but other types are possible

Page 52

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html The cn attribute is the most commonly used naming attribute; however, there are several other attribute types that are commonly used (see Table 2-3).

Naming Attributes You can use any attribute with a unique value in the RDN You can form the RDN using any attribute type on the entry that has a unique value among the entries in that container. Although this rule may seem confusing, it allows the client more flexibility to identify an entry in an unexpected form. Generally speaking, the schema checker must ensure that each new entry or modification to an existing entry leaves the entry with at least one unique RDN, so the entry has a unique name. Some LDAP implementations do standardize the naming attribute for any given object class; and in this case, attributes that are designated as naming attributes must meet the uniqueness rule that the schema checker enforces. Either way, there is a guarantee that every entry has a name that is unique across the directory. Table 2-3. Common attributes used as naming attributes Attribute Type

Attribute Used For:

cn

common name

l

locality name

st

state or province name

o

organization name

ou

organizational unit name

c

country name

street

street address

dc

domain component

uid

user identity

You can also use more than one attribute in the RDN. This is called a multivalued RDN. This functionality lets you specify a unique entry with an intersection of two attribute values when one or both of the attribute values doesn't meet the uniqueness requirement. For example, consider the situation shown in Figure 2-7. There are two people with the same phone number, and two people with the same surname. You can't use either the phone number or the surname attribute to uniquely indicate Luke Skywalker's entry, but a combination of both attribute types will create a unique combination. The RDN would be sn=Skywalker+telephoneNumber=+1 222 222 2222. Of course, in this case you could more easily use cn=Luke Skywalker as the RDN; but there might be instances in which you do not know the cn value, so it would be more efficient to use the multivalued RDN. Not all vendor implementations fully support this functionality. Use it only with careful planning. Figure 2-7. An example of a multivalued RDN

Page 53

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

Distinguished Name (DN) A DN provides a name for users to uniquely refer to each directory entry The DN provides a fully qualified name to each entry, so it is clear exactly which entry is referenced, and also where in the hierarchical structure that entry is located. Under the LDAP specification, each entry does not store its DN, nor does the directory index the DNs of directory entries. Instead, a DN is primarily for the users of the directory to be able to indicate to the directory which entry is desired. A DN is presented by a client operation request, and the directory dynamically looks to see whether an entry matches this purported DN. Specific vendors may store the DN as an attribute of the entry or index all the DNs, but this is neither required nor expected. The DN is a concatenation of the entry's RDN and the RDN of every container between the entry and the directory root Forming a DN can be a bit tricky because the user must know the RDNs of all the containers above the entry. The DN is a string composed of the RDN of the entry concatenated with the RDN of the container of the entry concatenated with each RDN of every container above that container. Commas delimit each component. Here is a simpler, recursive definition of a DN: The DN is the string composed of the RDN of the entry concatenated with the DN of its container. As shown in Figure 2-7 , the entry on the right has two possible DNs:

cn=Luke Skywalker,ou=People,dc=mycompany,dc=com or:

sn=Skywalker+telephoneNumber=+1 222 222 2222,ou=People,dc=mycompany,dc=com What's This Phone Number? Attributes that express a phone number have a commonly accepted syntax so users around the world will understand the number. The accepted syntax begins with a plus sign and the country code, followed by the national phone number. There are two plus signs in the previous multivalued RDN example. One is part of the multivalued RDN syntax to link the two RDNs into a single DN, and the other plus sign is expected in a

Page 54

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

phone attribute.

Using Naming Attributes Appropriately Naming attributes are critically important to your directory. The users of your directory will constantly be referencing the values of these attributes to find and modify entries. This design has several implications. The value of these attributes should not contain information that is considered private. Otherwise, you will need to place access controls on the attribute, and this will prevent the attribute from being used as an RDN. Using access controls can also lead to some entries being left out of critical business processes. Both vendors and deployment teams alike can make the mistake of using an attribute with information that may be considered private as the naming attribute of a critically important object class. The value of the naming attribute should be static. Changes to a name can cause undesirable behavior in programs that have been "hardcoded" to use a specific name. Just as a program is hardcoded, so are people. They won't always know when a name change has been made, and they can have difficulty finding this renamed entry or knowing that the renamed entry is the same as the original. One way to sidestep both of these problems is to use an arbitrary, public, but unique value in the naming attribute. This approach may feel wrong from a design perspective because the name is less personal, but it is effective. It guarantees that everyone can query all the entries, and that the entry's name won't change.

Naming Special Characters You should treat some special characters differently when they are used in a DN You must treat several characters specially when they are used in a DN. You can store these special characters as naming attribute values without the escape character; but when referring to these characters in a DN, you must escape them. You specially notate these characters by preceding them with a backslash character (\) to avoid mistakes in meaning. This is sometimes called commenting or escaping. For example, designating a DN with an RDN that has a comma in its value would cause confusion because the directory uses commas in the DN to separate the DN components. Treat the characters listed in Table 2-4 specially by escaping them in DNs. RFC 2253 makes it clear that vendors can make other characters special, so take care to examine vendor implementations for special cases. Table 2-4. Special characters in distinguished names Character

Escaped Character

Comma (,)

\,

Plus (+)

\+

Double quotation marks (")

\"

Backslash (\)

\\

Less than ()

\>

Page 55

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

Semicolon (;)

\;

Space at beginning or end of an RDN

\

Octothorp (#) at beginning of an RDN

\#

LDAP Hacking: Possible Code Injection? Code injection and format string attacks are common security exploits in other technologies these days. SQL, printf, Web servers, and homegrown Web applications have all exhibited this vulnerability in recent years. These types of vulnerabilities are based on poor coding of exceptions or parsing of user input, and they allow a malicious attacker to insert commands or code on a server. These types of vulnerabilities usually surround special characters and ambiguous behavior on what to do with these special characters when a user presents them as input. Although there are no known LDAP vulnerabilities in this area, I have to believe that there will be exploits discovered in the near future. With more organizations centralizing data into LDAP directories, more scrutiny will produce the trial and error needed to discover the coding mistakes behind these vulnerabilities.

URL Naming When using a Web browser as an LDAP client, you should use a special naming format Most Web browsers today support LDAP client functionality. As a result, you can perform searches conveniently via a browser. The naming format of the LDAP URL is fully specified in RFC 2255. This format is slightly different from that used by standard LDAP clients. URLs have a large set of special characters that must be treated in a special way as designated in RFC 1738, and the different format accommodates this. The LDAP URL-naming format is not exclusively used by Web browsers; standard LDAP clients must also be able to use it to support referrals. How to use LDAP URL syntax An LDAP URL begins with the protocol designation ldap://, followed by the hostname and port of the directory server, then the base DN and other designations, such as the scope, filter, and attributes desired. The syntax is

ldap://[hostname][/dn[?[attributes][?[scope] [?[filter][?[extensions]]]]] The components of the syntax are



hostname

The hostname specifies the LDAP server and the TCP/IP port used by the LDAP

server. As indicated by the brackets, both the hostname and port are optional. A default of port 389 is used if the port isn't specified. If the hostname isn't specified, the client must have prior knowledge of which server to contact. Separate the hostname and port with a colon, mycompany.com:389, as specified in RFC 1738.

Page 56

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html



DN



attributes

The DN component specifies the base distinguished name for the search. The attribute component specifies the attribute types to return from the

entries that match the search parameters. If left unspecified, all attributes are returned.



scope

The scope component specifies the scope of directory entries to return. As with

typical LDAP searches, base, one, and sub are possible values. If the value is left unspecified, sub is assumed.



filter

The filter component specifies a limiting filter on which entries should be returned.

It follows the same syntax as typical LDAP searches. If left unspecified, (objectclass=*) is assumed, so that all entries are returned.



extensions

The extensions component specifies optional LDAP URL extensions. These

extensions can be defined as needed, and they don't necessarily correspond to LDAP extended operations. Only one such extension has been standardized, called the bindname extension. The bindname extension allows the client to specify the DN of a directory entry to use in authenticating to the directory. A subsequent authentication challenge would then be initiated. You can find more details in Section 4 of RFC 2255. Here is an example of an LDAP URL:

ldap://mycompany.com:389/cn=Brian Arkills,ou=People,dc=Mycompany,dc=com?sn Given the sample directory shown in Figure 2-6, this search would return the sn attribute of the entry cn=Brian Arkills,ou=People,dc=mycompany,dc=com. The search has the subtree scope, but the entry at the specified base DN has no children, so only one entry is returned. Special URL characters must be treated in a unique way There are several illegal and special URL characters. These characters include the special characters noted earlier in this chapter as well as almost all nonalphanumeric characters (the notable exceptions include $-_.!*'()). You must escape these characters when you use them in an LDAP URL component. The escape method is fully described in RFC 1738, but it amounts to substituting the % character and the two-digit hexadecimal ASCII code for the character in question. Most browsers automatically translate illegal URL characters into the escaped version.

LDAP v2 Naming Conventions LDAP v3 must support all LDAP v2 naming conventions In addition to the special naming syntax restrictions defined by the LDAP v3 standard, LDAP v3-compliant implementations must also support LDAP v2-compliant naming. LDAP v3 implementations can't generate LDAP v2-compliant names, but they must accept and process those names by translating the names to the LDAP v3-compliant standard. RFC 2253 Section 4 spells out this compatibility. There are distinct differences between the two versions. LDAP v2 differs from LDAP v3 on the following points of syntax:



LDAP v2 uses semicolons as RDN separators.



LDAP v2 allows spaces before and after each of the following: - RDN separators (either comma or semicolon)

Page 57

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html - Equal signs between the attribute type and value - Plus signs in a multivalued RDN



LDAP v2 allows quotation marks at the beginning and end of an RDN value, which are not part of the RDN attribute value. If you use quotation marks in this way, all the special DN characters that usually require escaping do not need to be escaped.



LDAP v2 allows the text OID. or oid. to prefix an OID attribute type string.

Again, an LDAP v3-compliant directory accepts all these differences in syntax, but it automatically translates them to the correct LDAP v3-compliant syntax for processing.

Designing Your Directory to Be People Friendly Although you can store the special characters listed in Table 2-4 as naming attribute values, carefully consider the alternatives. For example, imagine that you are planning to store the cn of a person object in the format lastname, firstname. Because of the comma in the CN, searches for those person entries would have to escape the comma to successfully find the entry. Users would have to be familiar with the characters that are considered special so they could successfully use the directory. Avoiding special characters in naming attribute values isn't required, but by doing so you will create a more friendly experience for your users.

[ Team LiB ]

Page 58

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] Special LDAP Structural Concepts As LDAP has matured, extensions to the structural functionality have rapidly developed to reflect the distributed computing model. Certain structural features are needed to support a directory housed on multiple servers, greater directory reliability, integration with other directories, and localizing directory data on a geographical basis. Replication, referrals, and aliases are the advanced features used to enable this functionality. Some of these special features are part of the LDAP standard, while others are available only in certain vendor implementations. To explore further how to extend the LDAP namespace, see Chapter 5, which focuses on directory management.

[ Team LiB ]

Page 59

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] Summary The namespace provides the structure to store and find directory information In summary, the namespace employed by LDAP directories follows an ordered hierarchical model. The preexisting DNS namespace at an organization is usually used to augment this model. The hierarchical model provides many advantages, but perhaps the most critical is that knowing the name of an entry tells you where the entry is located within the directory structure.

[ Team LiB ]

Page 60

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] Chapter 3. Client LDAP Operations While crafting the namespace structure is critical to the directory administrator, the LDAP operations are at the heart of the client-to-server interaction. The LDAP operations are therefore what the typical user of your directory needs to know about, although good client software abstracts even this interaction from view. Users probably need only the search operation, which happens to be the most detailed operation. There are ten primary operations defined by the LDAP standard. Administrators and programmers use this full set as they manage directory information and create special business processes that interact with the directory information. This chapter describes the purpose of each of the ten operations, and along the way I discuss issues that relate to the client-server interaction. The LDAP client is what a user sees of a directory One of the most obvious topics involved in the client-server interaction is the LDAP client itself. The client software is the key to people finding the LDAP directory useful and easy to use. If the client software requires people to understand this book, or even a fraction of this chapter, they won't use the directory. Therefore, well-designed applications that hide LDAP from users are important. Because the search operation is the most prominent operation, it is addressed early in the chapter. You can explore how to create complex searches, how to use comparison operators, and what client options affect the search operation. By understanding how the client should work and what the common client configuration options are, you can educate users even if the client software isn't friendly. LDAP operations, extensions, client services, and APIs are examined After addressing the topics of immediate concern to users, I turn next to other standard operations and technical topics connected with the LDAP operations. In addition, I examine some extended operations and controls that can make an LDAP directory more valuable. The chapter ends with a look at the details of using an LDAP API. An organization that is developing a directory-enabled application or service needs to look at these details. Directory users will employ LDAP client software that was written using these underlying APIs, but typical users won't need to know about the API. For example, a programmer might design a program that automatically fills out all the paper forms needed when a new employee joins the organization. The new executive at Mycompany that was introduced in Chapter 1 would have a less painful first day with such a program in place. These standard APIs are the primary reason why LDAP is such a popular choice, because they work regardless of the client's operating system, making a multiplatform implementation possible. Appendix A summarizes the standard C version of the API, as defined in RFC 1823. In addition, this chapter takes a brief look at some of the functions in the C version of the API.

Client Software The typical user cannot be expected to remember LDAP syntax. Good client software is necessary to help users interact with the directory. You need to review a vendor's client software just as carefully as you review the server features. The client software should focus on making the search operation, especially the creation of a search filter, easy to perform. If a good client isn't available, your organization may have to create a client interface that fits its needs. A programmer can design a client with search filter options that include a user-friendly version of the filter and match operators desired.

[ Team LiB ]

Page 61

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

Page 62

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] Directory-Enabled Services and Applications Many applications benefit from being able to interact with the directory to find information. An application or service that is capable of being an LDAP client is called directory-enabled. Applications that can interact with a directory are called directory-enabled Many e-mail services are directory-enabled Among the most common directory-enabled applications are e-mail services. When an e-mail server receives an e-mail, it can query the directory to find out whether the e-mail address recipient resides at the local site and what e-mail server that person's mailbox resides on. Centralizing this information in the directory simplifies the administration of the e-mail servers by eliminating the need for a synchronized copy of this information on each e-mail server. For example, sendmail is a common UNIX mail server that can be directory-enabled (for more details, see Appendix C). Microsoft recognized the importance of directory-enabling their mail server, Microsoft Exchange 2000, and has integrated it with Active Directory (see Chapter 7). E-mail clients can also be directory-enabled Similarly, e-mail clients can be directory-enabled, and they provide a valuable service by looking up a destination e-mail address given a person's name. Several e-mail clients allow the user to browse a directory via an interface within the e-mail application and pick out recipients for an e-mail.

A Web-Based Client Interface Many organizations implement a Web-based client interface for their directory. This approach removes the cost of distributing client software and locating an adequate client for every platform. It can even help provide some limited integration of multiple directories. However, if you want to maximize the potential benefits of a directory, implementing more than a Web-based client interface would be wise. A Web-based client integrates poorly with other software. Restricting the client interface to a browser limits the usefulness of the data obtained by searching the directory. Extending the functionality of existing user applications is a good way to help users take advantage of the directory. For example, if you configured the users' mail application to search the directory for an e-mail address through a simple command, users would see how the directory benefits them. The limits of directory-enabled services haven't been reached yet Directory-enabled services have few boundaries. For example, you could use an LDAP directory



As a certificate authority store associated with public-private certificate technology. This also allows you to provide a service to verify the validity of those certificates.



To catalog the location of HTML and other types of electronic documents. You could then query and return a list of appropriate documents, just as a library catalog would do.

Microsoft's Active Directory LDAP implementation is a good example of how a variety of directory-enabled services can be integrated. Via Microsoft's Active Directory, software can be distributed to computers, user and computer configurations can be set, printers can be advertised to clients, and so on. Clearly, there are significant benefits to centralizing information in a directory, especially information that helps manage resources.

Page 63

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html Mycompany simply needs creativity and integrated services that take advantage of the directory to realize this potential.

[ Team LiB ]

Page 64

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html [ Team LiB ] Search An LDAP operation consists of a client request, server work, and the results All the LDAP operations consist of the client sending the operation request along with parameters to the server. The server then performs the operation and sends a result code back to the client. The result code indicates the success or failure of the operation. When the operation is a search operation, the server sends all the entries that match the search parameters prior to sending the result code. There is no read operation, so if a directory user wants to read a specific entry, she must perform a search operation specifying the entry. Search parameters define what entries the server returns to the client and how it finds those entries The search operation has many parameters that modify how the server performs the operation. There are mandatory parameters that are required or the search will fail, and there are optional parameters that have default values if not set otherwise. The search parameters affect only the single search operation for which they are set. Should you want to modify all LDAP operations for a session, you must use an LDAP option, if there is an appropriate one. LDAP options are discussed a little later in this chapter. Do not confuse LDAP options with optional search parameters or the attribute options introduced in Chapter 4 .

Mandatory Search Parameters Where does the server begin looking? The mandatory search parameters are



A base DN to begin your search

An idea of how the directory is structured is helpful here.

In other words, if you want to look up person entries, are they all in a common container? The base DN is sometimes also called the baseObject. If I didn't know where to begin, I could start at the root of the directory. In Mycompany's directory, this would be dc=mycompany,dc=com. So at a minimum, I must know the naming contexts of the directory. How far does the server look?



The scope of the search

There are three options for the scope. A base scope means to

search only the single entry at the base DN. A one scope means to search all entries at the same level in the hierarchy within the container of the base DN. A subtree scope means to search the base DN and all entries beneath the base DN, regardless of their level in the hierarchy. What special characteristics do the entries have?



A search filter

Search filters are composed of an attribute type, a comparison operator,

and an attribute value. These three components are surrounded by parentheses and form a search filter item. The simple syntax of the search filter item is "("attributetype

operator attributevalue")" with no spaces between any of these mandatory elements. The quotation marks enclose text that is constant in the syntax. For example, (objectclass=person) would be a valid search filter item. One or more search filter items can be combined with filter operators to form the search filter, so the example is also a valid search filter. Filter operators are introduced shortly.

Page 65

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html To illustrate the use of a search filter, if I wanted to find my entry as shown in Figure 3-1, I might use the following search parameters: Base DN:

dc=mycompany, dc=com

Scope:

Subtree

Search Filter:

(cn=Brian Arkills) Figure 3-1. Mycompany with my person entry

You can use filter operators to combine filters You can combine filter items within the search filter parameter by using filter operators. Filter operators can modify a filter item specified within the search filter parameter, and they can be used to combine multiple filters to designate intricate sets of entries. The filter operators available are



& AND



| OR



! NOT

These operators should precede the filter they modify. This precession is very similar to how functions in the LISP language or operations in reverse polish calculators are represented. The following filters illustrate the use of the filter operators with the directory shown in Figure 3-2. All the examples provided assume a base DN at the root of the directory, along with a subtree scope. Figure 3-2. Mycompany example for search filter operators

Page 66

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html

The filter

(|(cn=Brian Arkills)(cn=Chewbacca)) returns the entries of Chewbacca and me. The filter

(!(|(cn=Brian Arkills)(cn= Chewbacca))) returns all entries in the entire directory except Chewbacca or my entry, so it would return the entries of cn=Princess Leia, cn=Han Solo, uid=barkills, upn=441276, upn=239316, as well as the ten ou entries pictured. Containers are still entries. The filter

(&(!(|(cn=Brian Arkills)(cn=Chewbacca)))(objectclass=inetOrgPerson)) finds all the inetOrgPerson entries except Chewbacca's or my entry, so it would return the entries of Princess Leia and Han Solo.

The Search Operation Is Too Complicated for My Users Explaining how the search operation works and the valid values for the mandatory parameters (and the optional parameters that haven't been introduced yet) is a daunting task. Most users won't understand (or worse, will be intimidated and won't try) even with good documentation for reference. This is where client software comes into play. Good client software might have the most common search types already defined. For example, a user could simply enter a name to search for a person. The software would recognize the type of search and would supply the correct parameters to the directory. For example, the Pine e-mail program (UNIX, Windows, or Web-based) can be preconfigured to search your directory with a given base DN and scope. A user enters a name on the To: field of a new e-mail, and the program looks up the address in the directory and enters it in the e-mail message. Search filters are the most dynamic and interesting parameter in the LDAP search operation. For

Page 67

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html more details on search filters, see the following section, Search Filters.

Optional Search Parameters Should the server return the entire entry or just some of the attributes? The optional search parameters are



What attribute information to return

If you don't specify what you want, all the

attributes of the entries the server finds will be returned. You can list the attribute types you want in a list separated by commas. The operational attributes, which are the attributes that the directory uses for its own purposes, are never returned unless explicitly specified. You can also specify that no attributes should be returned by denoting the attribute 1.1. This designation holds significance as a special OID number that is not associated with any attribute type. See Chapter 4 for more information on both operational attributes and OID numbers. How should the server treat alias entries?



derefAliases

Denotes how to deal with alias entries. An alias entry is a dummy entry

that references or points to another entry. Dereferencing an alias simply instructs the server to go to the object that the alias references, and for the purposes of the search, treat the referenced object as if it were the alias object. The following options are available (for more information on alias entries, see Chapter 5): - neverDerefAliases Don't look up any alias reference. - derefInSearching Look up all alias references except on the baseObject. - derefFindingBaseObj Look up alias references only on the baseObject. - derefAlways Look up all alias references. How many entries should the server return?



sizeLimit

Limits the number of entries to return on the search. The default value of 0

denotes no limit. If a search finds more entries than what is specified as the limit, only the first set number is returned. In this case, a result code of LDAP_SIZELIMIT_EXCEEDED is returned to indicate that more results were available. Settings in other places can modify the effects of this parameter Many LDAP server implementations allow the directory administrator to set a mandatory upper sizeLimit for all client operations. In this case, the client can set a limit with a lower value, but limits greater than the server limit are disregarded. Some LDAP servers have a special user that can override the size limit. Another modifier called an LDAP control can be used to tell the server to send the results back to the client in pages. For example, the directory might have a sizeLimit of 50, and a search that yields 100 entries normally only returns the first 50. But if I ask for a page size of 50, the server would send the first 50 entries to my client, then the second 50, and I'd see all the entries. LDAP controls are modifiers that apply to a single LDAP operation. LDAP controls, including this one, are discussed later in this chapter. How long should the server work on this request?

Page 68

ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html



timeLimit

Limits the time in seconds allowed to complete the search. The default value

of 0 denotes no limit. If a search operation takes longer to complete than the specified limit, the operation will finish at the time limit. Only the entries found in this time period are returned. In this case, a result code of LDAP_TIMELIMIT_EXCEEDED is returned to indicate that more results were available. Some LDAP server implementations allow the directory administrator to set a mandatory upper timeLimit for all client operations. Some LDAP servers have a special user that can override the server time limit. The client can set a limit with a lower value, but limits greater than the server limit are disregarded. Does the client want the attribute pair or just the type?



typesOnly

If set to true, the results will list only the attribute types, not the values. The

default value of false denotes that both the attribute types and values should be returned.

Search Filters You use match operators to limit the attribute values specified in the search filter In addition to the filter operators, other operators, called match operators or comparison operators, can modify the search filter. Most documentation on the subject confuses match operators with filter operators. But match operators do not operate on the entire filter expression, only on the attribute value. The match operators are usually common mathematical operators, such as equality or greater than or equal. You use match operators to help designate the entries that match the attribute value parameters desired. The operations used to match vary depending on the specific type of data stored in the attribute. Most attributes store some type of string value, in other words, text. Therefore, the most common match operators you will use are string match operators. Here are the string match operators:



= Equality

We have already looked at a few examples together.

