Understanding and Deploying LDAP Directory Services > 3. An Introduction to LDAP > The LDAP Models |
The LDAP ModelsLDAP defines four basic models that fully describe its operation, what data can be stored in LDAP directories, and what can be done with that data. These models are described in the following sections. The LDAP Information ModelThe LDAP information model defines the types of data and basic units of information you can store in your directory. In other words, the LDAP information model describes the building blocks you can use to create your directory. The basic unit of information in the directory is the entry , a collection of information about an object. Often, the information in an entry describes some real-world object such as a person, but this is not required by the model. If you look at a typical directory, you'll find thousands of entries that correspond to people, departments, servers, printers, and other real-world objects in the organization served by the directory. Figure 3.7 shows a portion of a typical directory, with objects corresponding to some of the real-world objects in the organization. Figure 3.7 Part of a typical directory.An entry is composed of a set of attributes , each of which describes one particular trait of the object. Each attribute has a type and one or more values . The type describes the kind of information contained in the attribute, and the value contains the actual data. For example, Figure 3.8 zooms in on an entry describing a person, with attributes for the person's full name , surname (last name), telephone number, and email address. Figure 3.8 A directory entry showing attribute types and values.LDIF Throughout this book you'll see directory entries shown in the LDIF text format. This is a standard way of representing directory data in a textual format that is used when exporting data from and importing data into a directory server. LDIF files consist solely of ASCII text, making it possible to pass them through email systems that are not 8-bit clean. Because it's a legible and text-based format, LDIF is used in this book when we want to represent a directory entry . Let's look at a typical directory entry represented in LDIF: dn: uid=bjensen, dc=airius, dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: Barbara Jensen cn: Babs Jensen sn: Jensen mail: bjensen@airius.com telephoneNumber: +1 408 555 1212 description: A big sailing fan. An LDIF entry consists of a series of lines. It begins with dn:, followed by the distinguished name of the entry, all on one line. After this come the attributes of the entry, with one attribute value per line. Each attribute value is preceded by the attribute type and a colon ( : ). The order of the attribute values is not important; however, it makes the entry more readable if you place all the objectclass values first and keep all the attribute values of a given attribute type together . There are other, more-sophisticated things you can do with LDIF, including representing modifications to be applied to directory entries. We'll cover these more-sophisticated uses of LDIF later in this chapter . Attribute types also have an associated syntax , which describes the types of data that may be placed in attribute values of that type. It also defines how the directory compares values when searching. For example, the caseIgnoreString syntax specifies that strings are ordered lexicographically and that case is not significant when searching or comparing values. Hence, the values Smith and smith are considered equivalent if the syntax is caseIgnoreString . The caseExactString syntax, by contrast, specifies that case is significant when comparing values. Thus, Smith and smith are not equivalent values if the syntax is caseExactString . With both caseIgnoreString and caseExactString syntaxes, trailing and leading spaces are not significant, and multiple spaces are treated as a single space when searching or comparing. The rules for how attribute values of a particular syntax are compared are referred to as matching rules . X.500 servers typically support a number of different syntaxes that are either some primitive type (such as a string, integer, or Boolean value) or some complex data type built from sets or sequences of the primitive types. LDAP servers typically avoid this complicated abstraction layer and support only the primitive types. The Netscape Directory Server, for example, supports the case-ignore and case-exact string, distinguished name, integer, and binary syntaxes. However, a plug-in interface allows new syntaxes to be defined. Attributes are also classified broadly in two categories: user and operational. User attributes , the "normal" attributes of an entry, may be modified by the users of the directory (with appropriate permissions). Operational attributes are special attributes that either modify the operation of the directory server or reflect the operational status of the directory. An example of an operational attribute is the modifytimestamp attribute, which is automatically maintained by the directory and reflects the time that the entry was last modified. When an entry is sent to a client, operational attributes are not included unless the client requests them by name. Attribute values can also have additional constraints placed on them. Some server software allows the administrator to declare whether a given attribute type may hold multiple values or if only a single attribute value may be stored. For example, the givenName attribute is typically multivalued, for when a person may want to include more than one given name (e.g., Jim and James). On the other hand, an attribute holding an employee ID number is likely to be single-valued. The other type of attribute constraint is the size of the attribute. Some server software allows the administrator to set the maximum size value that a given attribute may hold. This can be used to prevent users of the directory from using unreasonable amounts of storage. Maintaining Order: Directory SchemasAny entry in the directory has a set of attribute types that are required and a set of attribute types that are allowed. For example, an entry describing a person is required to have a cn (common name) attribute and an sn (surname) attribute. A number of other attributes are allowed, but not required, for person entries. Any other attribute type not explicitly required or allowed is prohibited . The collections of all information about required and allowed attributes are called the directory schemas . Directory schemas, which are discussed in detail in Chapter 7, "Schema Design," allow you to retain control and maintain order over the types of information stored in your directory. In summary, the LDAP information model describes entries , which are the basic building blocks of your directory. Entries are composed of attributes , which are composed of an attribute type and one or more values . Attributes may have constraints that limit the type and length of data placed in attribute values. The directory schemas place restrictions on the attribute types that must be or are allowed to be contained in an entry. However, building blocks aren't very interesting unless you can actually use them to build something. The rules that govern how you arrange entries in a directory information tree are what comprise the LDAP naming model. The LDAP Naming ModelThe LDAP naming model defines how you organize and refer to your data. In other words, it describes the types of structures you can build out of your individual building blocks, which are the directory entries. After you've arranged your entries into a logical structure, the naming model also tells you how you can refer to any particular directory entry within that structure. The flexibility afforded by the LDAP naming model allows you to place your data in the directory in a way that is easy for you to manage. For example, you might choose to create one container that holds all the entries describing people in your organization, and another container that holds all your groups. Or, you might choose to arrange your directory in a way that reflects the hierarchy of your organizational structure. Chapter 8, "Namespace Design," guides you in making good choices when you design your directory hierarchy or namespace. The LDAP naming model specifies that entries are arranged in an inverted tree structure, as shown in Figure 3.9. Figure 3.9 A directory tree.Readers familiar with the hierarchical file system used by UNIX systems will note its similarities to this directory structure. Such a file system consists of a set of directories and files; each directory may have zero or more files or directories beneath it. Part of a typical UNIX file system is shown in Figure 3.10. Figure 3.10 Part of a typical UNIX file system.There are three significant differences between the UNIX file system hierarchy and the LDAP directory hierarchy, however. The first major difference between the two models is that there isn't really a root entry in the LDAP model. A file system, of course, has a root directory, which is the common ancestor of all files or directories in the file system hierarchy. In an LDAP directory hierarchy, on the other hand, the root entry is conceptual ”it doesn't exist as an entry you can place data into. There is a special entry called the root DSE that contains server-specific information, but it is not a normal directory entry. The second major difference is that in an LDAP directory every node contains data, and any node can be a container. This means that any LDAP entry may have child nodes underneath it. Contrast this with a file system, in which a given node is either a file or a directory, but not both. In the file system, only directories may have children, and only files may contain data. Another way of thinking of this is that an entry in a directory may be both a file and a directory simultaneously . The directory tree shown in Figure 3.11 illustrates this concept. Notice how the entries dc=airius , dc=com , ou=People , and ou=Devices all contain data (attributes) but are also containers with child nodes beneath them. Figure 3.11 Part of a typical LDAP directory.The third and final difference between the file system hierarchy and LDAP hierarchy is how individual nodes in the tree are named. LDAP names are backward relative to file system names. To illustrate this, let's consider the names of the shaded nodes in Figures 3.10 and 3.11. In Figure 3.10, the shaded node is a file with a complete filename of /usr/bin/grep . Notice that if you read the filename from left to right, you move from the top of the tree ( /) down to the specific file being named. Contrast this with the name of the shaded directory entry in Figure 3.11. Its name is uid=bjensen, ou=people, dc=airius, dc=com . Notice that, if you read from left to right, you move from the specific entry being named back up toward the top of the tree. As you've seen, LDAP supports a hierarchical arrangement of directory entries. It does not, however, mandate any particular type of hierarchy. Just as you're free to arrange your file system in a way that makes sense to you and is easy for you to manage, you're free to construct any type of directory hierarchy you desire . Of course, some directory structures are better than others, depending on your particular situation; we'll cover the topic of designing your directory namespace in Chapter 8. The one exception to this freedom is if your LDAP directory service is actually a front end to an X.500 service. The X.500 naming model is much more restrictive than the LDAP naming model. In the X.500 1993 standard, directory structure rules limit the types of hierarchies you can create. The standard accomplishes this by specifying what types of "objectclasses" may be direct children of an entry. For example, in the X.500 model, only entries representing countries , localities, or organizations may be placed at the root of the directory tree. The LDAP naming model, on the other hand, does not limit the tree structure in any way; any type of entry may be placed anywhere in the tree. In addition to specifying how you arrange your directory entries into hierarchical structures, the LDAP naming model describes how you refer to individual entries in the directory. We mentioned this briefly when we were discussing the similarities and differences between file system hierarchy and LDAP directory hierarchy. Now let's go into more detail about naming. Why Is Naming Important?A naming model is needed so that you can give a unique name to any entry in the directory, allowing you to refer to any entry unambiguously. In LDAP, distinguished names (DNs) are how you refer to entries. Like file system pathnames, the name of an LDAP entry is formed by connecting in a series all the individual names of the parent entries back to the root. For example, look back at the directory tree shown in Figure 3.11. The shaded entry's name is uid=bjensen, ou=People, dc=airius, dc=com . Reading this name from left to right, you can trace the path from the entry itself back to the root of the directory tree. The individual components of the name are separated by commas. Spaces after the commas are optional, so the following two distinguished names are equivalent: uid=bjensen, ou=People, dc=airius, dc=com uid=bjensen,ou=People,dc=airius,dc=com In any entry's DN, the leftmost component is called the relative distinguished name (RDN). Among a set of peer entries (those which share a common immediate parent), each RDN must be unique. This rule, when recursively applied to the entire directory tree, ensures that no two entries may have the same DN. If you attempt to add two entries with the same name, the directory server will reject the attempt to add the second entry; this is similar to a UNIX host, which will reject an attempt to create a file with the same name as an existing file within a directory. Note that RDNs have to be unique only if they share a common immediate parent. Look at the tree in Figure 3.12. Even though there are two entries with the RDN cn=John Smith in the directory, they are in different subtrees ”making the tree completely legal. Whether this is a good way to construct your directory is another matter, one we will address in Chapter 8. Figure 3.12 Entries with the same RDNs are permitted if they are in different parts of the tree.Messy RDN Topics: Multivalued RDNs and QuotingYou've probably noticed that each RDN we've shown is composed of two parts: an attribute name and a value, separated by an equal sign ( = ). It's also possible for an RDN to contain more than one such name/value pair. Such a construction, called a multivalued RDN , looks like the following: cn=John Smith + mail=jsmith@airius.com The RDN for this entry consists of two attribute = value pairs: cn=John Smith and mail=jsmith@airius.com . Multivalued RDNs can be used to distinguish RDNs that would otherwise be the same. For example, if there is more than one John Smith in the same container, a multivalued RDN would allow you to assign unique RDNs to each entry. However, you should generally avoid using multivalued RDNs in your directory. They tend to clutter your namespace, and there are better ways to arrive at unique names for your entries. (Approaches for uniquely naming your entries are discussed in Chapter 8.) Recall that the individual RDNs in a DN are separated by commas. You may be curious how to proceed if an RDN contains a comma. How do you tell which commas are contained in RDNs, and which commas separate the individual RDN components? For example, what if you have an entry named o=United Widgets, Ltd. in your directory? If you have DNs like this in your directory, you must escape all literal commas (those within an RDN) with a backslash. In our example, then, the DN would be o=United Widgets\, Ltd., c=GB Certain other characters must also be quoted when they appear within a component of a DN. Table 3.1 shows all the characters that must be quoted, according to the LDAPv3 specification. Table 3.1. Characters requiring quoting when contained in distinguished names
AliasesAlias entries in the LDAP directory allow one entry to point to another one, which means you can devise structures that are not strictly hierarchical. Alias entries perform a function like symbolic links in the UNIX file system or shortcuts in the Windows 95/NT file system. In Figure 3.13, the dotted entry is an alias entry pointing to the "real" entry. Figure 3.13 An alias entry points to another directory entry.To create an alias entry in the directory, you must first create an entry with the object class alias and an attribute named aliasedObjectName . The value of the aliasedObjectName attribute must be the DN of the entry you want this alias to point to. Not all LDAP directory servers support aliases. Because aliases can point to any directory entry, even one that is on a different server, aliases may exact a severe performance penalty. Consider the directory trees shown in Figure 3.13. Alias entries in one of the trees point to entries in the other tree, which is housed in another server. To support searching across the entire ou=Marketing, dc=airius,dc=com tree, Server A must contact Server B each time an alias entry is encountered while servicing the search operation. This can significantly slow down searches, which is the main reason certain software does not support aliases. Often, the goals you are trying to achieve by using aliases can be met by using referrals, or by placing LDAP URLs in entries that clients can use to chase down the referred-to information. More information on using referrals can be found in Chapter 9, "Topology Design." The LDAP Functional ModelNow that you understand the LDAP information and naming models, you need some way to actually access the data stored in the directory tree. The LDAP functional model describes the operations that you can perform on the directory using the LDAP protocol. The LDAP functional model consists of a set of operations divided into three groups. The interrogation operations allow you to search the directory and retrieve directory data. The update operations allow you to add, delete, rename, and change directory entries. The authentication and control operations allow clients to identify themselves to the directory and control certain aspects of a session. In addition to these three main groups of operations, version 3 of the LDAP protocol defines a framework for adding new operations to the protocol via LDAP extended operations . Extended operations allow the protocol to be extended in an orderly fashion to meet new marketplace needs as they emerge. Extended operations were described earlier in this chapter. The LDAP Interrogation OperationsThe two LDAP interrogation operations allow LDAP clients to search the directory and retrieve directory data. The LDAP search operation is used to search the directory for entries and retrieve individual directory entries. There is no LDAP read operation. When you want to read a particular entry, you must use a form of the search operation in which you restrict your search to just the entry you want to retrieve. Later in the chapter we'll discuss how to search the directory and retrieve specific entries, as well as how to list all the entries at a particular location in the tree. The LDAP search operation requires eight parameters. The first parameter is the base object for the search. This parameter, expressed as a DN, indicates the top of the tree you want to search. The second parameter is the scope. There are three types of scope. A scope of subtree indicates that you want to search the entire subtree from the base object all the way down to the leaves of the tree. A scope of onelevel indicates that you want to search only the immediate children of the entry at the top of the search base. A scope of base indicates that you want to limit your search to just the base object; this is used to retrieve one particular entry from the directory. Figure 3.14 depicts the three types of search scope. Figure 3.14 The three types of search scope.The third search parameter, derefAliases , tells the server whether aliases should be dereferenced when performing the search. There are four possible values for this parameter's value:
The fourth search parameter is the size limit. This parameter tells the server that the client is interested in receiving only a certain number of entries. For example, if the client passes a size limit of 100, but the server locates 500 matching entries, only the first 100 will be returned to the client, along with a result code of LDAP_SIZELIMIT_EXCEEDED . A size limit of 0 means that the client wants to receive all matching entries. (Note that servers may impose a maximum size limit that cannot be overridden by unprivileged clients.) The fifth search parameter is the time limit. This parameter tells the server the maximum time in seconds that it should spend trying to honor a search request. If the time limit is exceeded, the server will stop processing the request and send a result code of LDAP_TIMELIMIT_EXCEEDED to the client. A time limit of 0 indicates that no limit should be in effect. (Note that servers may impose a maximum time limit that cannot be overridden by unprivileged clients.) The sixth search parameter, the attrsOnly parameter, is a Boolean parameter. If it is set to true, the server will send only the attribute types to the client; attribute values will not be sent. This can be used if the client is interested in finding out which attributes are contained in an entry but not in receiving the actual values. If this parameter is set to false, attribute types and values are returned. The seventh search parameter is the search filter, an expression that describes the types of entries to be returned. The filter expressions used in LDAP search operations are very flexible, and are discussed in detail in the next section. The eighth and final search parameter is a list of attributes to be returned for each matching entry. You can specify that all attributes should be returned, or you can request that only specific attributes of an entry be returned. We'll focus on how to request specific attributes later in this chapter. First, though, let's look at the different types of LDAP filters you can use when searching the directory. An LDAP filter is a Boolean combination of attribute-value assertions. An attribute value assertion consists of two parts: an attribute name and a value assertion, which you can think of as a value with wildcards allowed. The following sections look at the various types of search filters. Equality FiltersAn equality filter allows you to look for entries that exactly match some value. Here's an example: (sn=smith) This filter matches entries in which the sn (surname) attribute contains a value that is exactly smith . Because the syntax of the sn attribute is a case-ignore string, the case of the attribute and the filter is not important when locating matching entries. Substring FiltersWhen you use wildcards in filters, they are called substring filters. Here's an example: (sn=smith*) This filter matches any entry that has an sn attribute value that begins with smith . Entries with a surname of Smith , Smithers , Smithsonian , and so on will be returned. Wildcards may appear anywhere in the filter expression, so the filter (sn=*smith) matches entries in which the surname ends with smith (e.g., Blacksmith ). The filter (sn=smi*th) matches entries in which the surname begins with smi and ends with th , and the filter (sn=*smith*) matches entries that contain the string smith in the surname attribute. Note that the wildcard character matches zero or more instances of any character, so the filter (sn=*smith*) would match the entry with the surname Smith as well as any surnames in which the string smith is embedded. Approximate FiltersIn addition to the equality and substring filters, servers support an approximate filter . For example, on most directory servers, the filter (sn~=jensen) returns entries in which the surname attribute has a value that sounds like jensen (for example, jenson ). Exactly how the server implements this is particular to each vendor and the languages supported by the server. The Netscape Directory Server, for example, uses the metaphone algorithm to locate entries when an approximate filter is used. Internationalization also throws an interesting wrinkle into the concept of approximate matching; each language may need its own particular sounds-like algorithm. "Greater Than or Equal To" and "Less Than or Equal To" FiltersLDAP servers also support "greater than or equal to" and "less than or equal to" filters on attributes that have some inherent ordering. For example, the filter (sn<=Smith) returns all entries in which the surname is less than or equal to Smith lexicographically. The ordering used depends on the ordering rules for the syntax of any particular attribute. The sn attribute, which has the case-ignore string syntax, is ordered lexicographically without respect to case. An attribute that has integer syntax would be ordered numerically . Attributes that have no inherent ordering, such as JPEG photos, cannot be searched for with this type of filter. If you find that you need a greater than or less than filter (without the equals part), note that "greater than" is the complement of "less than or equal to" and "less than" is the complement of "greater than or equal to." In other words, (age>21) is not a valid filter, but is equivalent to (!(age<=21)) Similarly, the filter (age<21) which is also not a valid LDAP filter, is equivalent to (!(age>=21)) In these cases, ! is the negation operator, which we will discuss in more detail shortly. Presence FiltersAnother type of search filter is the presence filter. It matches any entry that has at least one value for the attribute. For example, the filter (telephoneNumber=*) matches all entries that have a telephone number. Extensible MatchingThe last type of search filter is the extensible match filter. It is only supported by LDAPv3 servers. The purpose of an extensible match filter is to allow new matching rules to be implemented in servers and used by clients. Recall our earlier example involving the caseIgnoreString and caseExactString syntaxes. Each syntax has an associated method for comparing values, depending on whether case is to be considered significant when comparing values. When new attribute syntaxes are developed, it may also be necessary to define a new way of comparing values for equality. Extensible matching also allows language-specific matching rules to be defined so that values in languages other than English can be meaningfully compared. As an added benefit, extensible matching allows you to specify that the attributes that make up the DN of the entry should be searched. So, for example, using extensible matching you can locate all the entries in the directory that contain the attribute value assertion ou=Engineering anywhere in their DN. To see the usefulness of this feature, consider an entry named cn=Babs Jensen, ou=Engineering, dc=bigco, dc=com . Suppose you're interested in finding all the Babs Jensens in the engineering department, and you search from the top of your subtree using a search filter like (&(cn=Babs Jensen)(ou=engineering)) . Normally, this filter would not find Babs's entry unless it explicitly contained an ou attribute with a value of engineering . Using extensible matching feature, you can treat the attribute values contained in a DN as attribute values of the entry that can match the search. The syntax of an extensible matching filter is a bit complicated. It consists of five parts, three of which are optional. These parts are
Formally, the grammar for the extensible search filter is attr [":dn"] [":" matchingrule] ":=" value The elements of this syntax are as follows :
Let's look at some examples of extensible matching filters. The following filter specifies that the all entries in which the cn attribute matches the value Barbara Jensen should be returned: (cn:1.2.3.4.5.6:=Barbara Jensen) When comparing values, the matching rule given by the OID 1.2.3.4.5.6 should be used. The following filter specifies that all entries that contain the string jensen in the surname should be returned: (sn:dn:1.2.3.4.5.7:=jensen) The sn attributes within the DN are also searched. When comparing values, the matching rule given by the OID 1.2.3.4.5.7 should be used. The following filter returns any entries in which the o (organization) attribute exactly matches Airius and any entries in which o=Airius is one of the components of the DN: (o:dn:=Airius) The following filter returns any entries in which a DN component with a syntax appropriate to the given matching rule matches Airius : (:dn:1.2.3.4.5.8:=Airius) The matching rule given by the OID 1.2.3.4.5.8 should be used. NegationAny search element can be negated by preceding the filter with an exclamation point ( ! ). For example, the filter (!(sn=Smith)) matches all entries in which the sn attribute does not contain the value smith , including entries with no sn attribute at all. Combining Filter TermsFilters can also be combined using AND and OR operators. The AND operator is signified by an ampersand ( & ) symbol, and the OR operator is signified by the vertical bar ( ) symbol. When combining search filters, you use prefix notation , in which the operator precedes its arguments. Those familiar with the "reverse polish notation" common on Hewlett-Packard calculators will be familiar with this concept (although reverse polish is a postfix notation, not a prefix notation like that used in LDAP search filters). Let's look at some examples of combinations of LDAP search filters. The filter (&(sn=Smith)(l=Mountain View)) matches all entries with a surname of smith that also have an l (locality) attribute of Mountain View . In other words, this filter will find everyone named Smith in the Mountain View location. The filter ((sn=Smith)(sn=Jones)) matches everyone with a surname of Smith or Jones . You use parentheses to group more-complex filters to make the meaning of the filter unambiguous. For example, if you want to search the directory for all entries that have an email address but do not have a telephone number, you would use the filter (&(mail=*)(!(telephoneNumber=*))) Note that the parentheses bind the negation operator to the presence filter for telephone number. Technically speaking, parentheses are always required, even if the filter consists of only a single term . Some LDAP software allows you to omit the enclosing parentheses and inserts them for you before sending the search request to the server. However, if you are developing your own software using one of the available SDKs, you need to include the enclosing parentheses. Table 3.2 summarizes the six types of search filters and the three Boolean operators. Table 3.2. Types of LDAP search filters
Quoting in Search FiltersIf you need to search for an attribute value that contains one of five specific characters, you need to substitute the character with an escape sequence consisting of a backslash and a two-digit hexadecimal sequence representing the character's value. Table 3.3 shows the characters that must be escaped, along with the escape sequence you should use for each. Table 3.3. Characters that must be escaped if used in a search filter
For example, if you want to search for all entries in which the cn attribute exactly matches the value A*Star , you would use the filter (cn=A\2AStar) . Readers should note that the rules for quoting search filters and the rules for quoting distinguished names are different and not interchangeable. Specifying Which Attributes Are to Be ReturnedAs previously mentioned, the last search parameter is a list of attributes to be returned for each matching entry. If this list is empty, all user attributes are returned. The special value * also means that all user attributes are to be returned, but it allows you to specify additional nonuser (operational) attributes that should be returned. (Without this special value, there would be no way to request all user attributes plus some operational attributes.) If you want to retrieve no attributes at all, you should specify the attribute name 1.1 (there is no such attribute OID, so no attributes can be returned). Table 3.4 provides some examples of attribute lists and the attributes that are returned by the server. Table 3.4. Examples of attribute lists and corresponding attributes returned by the server
Common Types of SearchesAlthough the LDAP search operation is extremely flexible, there are some types of searches that you'll probably use more frequently than others:
Hiding LDAP Filters from UsersYou might justifiably be thinking that your users will never be able to understand LDAP filter syntax. The prefix notation it uses is hardly intuitive, after all! Bear in mind, though, that any good directory access GUI will hide the details of filter construction from end users. Instead of requiring users to type raw LDAP filters, a set of pop-up menus and text boxes is typically used to allow the user to specify the search criteria, and the GUI client constructs the filter for the user. For example, in Figure 3.15, Netscape Communicator's Search window uses the provided information to construct the filter (&(cn=*smith*)(l=*Dearborn*)) . Figure 3.15 A GUI interface for searching the directory.If you are a directory administrator, it's a good idea to become familiar with LDAP filter syntax. You can use this knowledge to provide complex "canned" queries for your end users, for example. Filter syntax also crops up in LDAP URLs and configuration files. Spending a little time understanding filter syntax is well worth the effort. The Compare OperationThe second of the two interrogation operations, the LDAP compare operation, is used to check whether a particular entry contains a particular attribute value. The client submits a compare request to the server, supplying a DN, an attribute name, and a value. The server returns an affirmative response to the client if the entry named by the DN contains the given value in the given attribute type. If not, a negative response is returned. It may seem odd that the compare operation even exists. After all, if you want to determine whether a particular entry contains a particular attribute value, you can just perform a search with a search base equal to the DN of the entry, a scope of base , and a filter expressing the test you want to make. If the entry is returned, the test was successful; if no entry is returned, the test was not successful. The reasons that the compare operation exists are historical and related to LDAP's roots in X.500. There is only one case in which the compare and search operations behave differently. If a comparison is attempted on an attribute, but the attribute is not present in the entry, the compare operation will return a special indication to the client that the attribute does not exist. The search operation, on the other hand, would simply not return the entry. This ability to distinguish between "the entry has the attribute but contains no matching value" and "the entry does not have the attribute at all" may be convenient in some situations. The other advantage of the compare operation is that it is more compact in terms of the number of protocol bytes exchanged between the client and the server. The LDAP Update OperationsThere are four LDAP update operations: add, delete, rename (modify DN), and modify. These four operations define the ways that you can manipulate the data in your directory. The add operation allows you to create new directory entries. It has two parameters: the distinguished name of the entry to be created and a set of attributes and attribute values that will comprise the new entry. In order for the add operation to complete successfully, four conditions must be met:
If all these conditions are met, the new entry is added to the directory. The delete operation removes an entry from the directory. It has a single parameter: the DN of the entry to be deleted. In order for the delete operation to complete successfully, three conditions must be met:
If these conditions are all met, the entry is removed from the directory. The rename, or modify DN operation, is used to rename and/or move entries in the directory. It has four parameters: the DN of the entry to be renamed , the new RDN for the entry, an optional argument giving the new parent of the entry, and the delete-old-RDN flag. In order for the modify DN operation to succeed, the following conditions must be met:
If all these conditions are met, the entry is renamed and/or moved. If the entry is to be renamed but will still have the same parent entry, the new parent argument is left blank. Otherwise, the new parent argument gives the DN of the container where the entry is to be moved. The delete-old-RDN flag is a Boolean flag that specifies whether the old RDN of the entry is to be retained as an attribute of the entry or removed. Figures 3.16 through 3.20 show the various combinations of renaming and moving entries that can be performed with the modify DN operation. Figure 3.16 Renaming an entry without moving it.Figure 3.17 Moving an entry without changing its RDN.Figure 3.18 Moving an entry and changing its RDN simultaneously.Figure 3.19 Renaming an entry, deleteoldrdn=true.Figure 3.20 Renaming an entry, deleteoldrdn=false.LDAPv2 did not have a modify DN operation ”it had only a modify RDN operation. As the name implies, modify RDN allows only the RDN of an entry to be changed. This means that an LDAPv2 server may rename an entry but may not move it to a new location in the tree. To accomplish a move with LDAPv2, you must copy the entry, along with any child entries underneath it, to the new location in the tree and delete the original entry or entries. The modify operation allows you to update an existing directory entry. It takes two parameters: the DN of the entry to be modified and a set of modifications to be applied. These modifications can specify that new attribute values are to be added to the entry, that specific attribute values are to be deleted from the entry, or that all attribute values for a given attribute are to be replaced with a new set of attribute values. The modify request can include as many attribute modifications as needed. In order for the modify operation to succeed, the following conditions must be met:
If all these conditions are met, the entry is modified. Note that all the modifications must succeed, or else the entire operation fails and the entry is not modified. This prevents inconsistencies that might arise from half-completed modify operations. This last point raises one additional but very important topic about the LDAP update operations: Each operation is atomic , meaning that the whole operation is processed as a single unit of work. This unit either completely succeeds or no modifications are performed. For example, a modify request that affects multiple attributes within an entry cannot half-succeed, with certain attributes updated and others not updated. If the client receives a success result from the server, then all the modifications were applied to the entry. If the server returns an error to the client, then none of the modifications were applied. The LDAP Authentication and Control OperationsThere are two LDAP authentication operations, bind and unbind, and one control operation, abandon. The bind operation is how a client authenticates itself to the directory. It does so by providing a distinguished name and a set of credentials. The server checks whether the credentials are correct for the given DN and, if they are, notes that the client is authenticated as long as the connection remains open or until the client re-authenticates. The server can grant privileges to the client based on its identity. There are several different types of bind methods . In a simplebind, the client presents a DN and a password in cleartext to the LDAP server. The server verifies that the password matches the password value stored in the userpassword attribute of the entry and, if so, returns a success code to the client. The simple bind does send the password over the network to the server in the clear. However, you can protect against eavesdroppers intercepting passwords by encrypting the connections using secure sockets layer (SSL) or TLS, which are discussed in the next section. In the future, LDAPv3 will include a digest-based authentication method that does not require that a cleartext password be sent to the server. LDAPv3 also includes a new type of bind operation, the SASL bind. SASL is an extensible, protocol-independent framework for performing authentication and negotiation of security parameters. With SASL, the client specifies the type of authentication protocol it wants to use. If the server supports the authentication protocol, the client and server perform the agreed-upon authentication protocol. For example, the client could specify that it wants to authenticate using the Kerberos protocol . If the server knows how to speak the Kerberos protocol, it indicates this to the client that sends a service ticket for the LDAP service. The server verifies the service ticket and returns a mutual authentication token to the client. Whenever the Kerberos authentication completes, the SASL bind is complete and the server returns a success code to the client. SASL can also support multistep authentication protocols such as S/KEY. Incorporation of SASL into LDAPv3 means that new authentication methods, such as smart cards or biometric authentication, can be easily implemented for LDAP without requiring a revision of the protocol. The second authentication operation is the unbind operation. The unbind operation has no parameters. When a client issues an unbind operation, the server discards any authentication information it has associated with the client's connection, terminates any outstanding LDAP operations, and disconnects from the client, thus closing the TCP connection. The abandon operation has a single parameter: the message ID of the LDAP operation to abandon. The client issues an abandon operation when it is no longer interested in obtaining the results of a previously initiated operation. Upon receiving an abandon request, the server terminates processing of the operation that corresponds to the message ID. The abandon request, typically used by GUI clients, is sent when the user cancels a long-running search request. Note that it's possible for the abandon request (coming from the client) and the results of the abandoned operation (going to the client) to pass each other in flight. The client needs to be prepared to receive (and discard) results from operations it has abandoned but the server sent anyway. If you are using an LDAP SDK, however, you don't need to worry about this; the SDK takes care of this for you. The LDAP Security ModelWe've discussed three of the four LDAP models so far. We have a set of directory entries, which are arranged into a hierarchy, and a set of protocol operations that allow us to authenticate to, search, and update the directory. All that remains is to provide a framework for protecting the information in the directory from unauthorized access. This is the purpose of the LDAP security model. The security model relies on the fact that LDAP is a connection-oriented protocol. In other words, an LDAP client opens a connection to an LDAP server and performs a number of protocol operations on the same connection. The LDAP client may authenticate to the directory server at some point during the lifetime of the connection, at which point it may be granted additional (or fewer) privileges. For example, a client might authenticate as a particular identity that has been granted read-write access to all the entries in the directory. Before this authentication, it has some limited set of privileges (usually a default set of privileges extended to all users of the directory). After it authenticates, however, it is granted expanded privileges as long as the connection remains open. What exactly is authentication? From the client's perspective, it is the process of proving to the server that the client is some entity. In other words, the client asserts that it has some identity and provides some credentials to prove this assertion. From the server's perspective, the process of authentication involves accepting the identity and credentials provided by the client and checking whether they prove that the client is who it claims to be. To illustrate this abstract concept with a concrete example, let's examine how LDAP simple authentication works. In simple authentication, an LDAP client provides to an LDAP server a distinguished name and a password, which are sent to the server in the clear (not hashed or encrypted in any way). The server locates the entry in the directory corresponding to the DN provided by the client and checks whether the password presented by the client matches the value stored in the userpassword attribute of the entry. If it does, the client is authenticated; if it does not, the authentication operation fails and an error code is returned to the client. The process of authenticating to the directory is called binding . An identity is bound to the connection when a successful authentication occurs via the bind operation we introduced in the previous section. If a client does not authenticate, or if it authenticates without providing any credentials, the client is bound anonymously. In other words, the server has no idea who the client is, so it grants some default set of privileges to the client. Usually, this default set of privileges is very minimal. In some instances, the default set of privileges is completely restrictive ”no part of the directory may be read or searched. How you treat anonymously bound clients is up to you and depends on the security policy appropriate to your organization. You can find more information on security and privacy in Chapter 11, "Privacy and Security Design." There are many different types of authentication systems available that are independent of LDAP. LDAP version 2 supported only simple authentication, in which a DN and password are transmitted in the clear from the client to the server. Note The previous statement is not completely correct because LDAPv2 also supported Kerberos version 4 authentication, which does not require that passwords be sent in the clear. However, KerberosV4 was not commercially successful and has been superseded by Kerberos version 5. Kerberos support was therefore dropped from the core LDAPv3 protocol, although it's entirely feasible to support it via an SASL mechanism. Acknowledging the need to support many different authentication methods, LDAPv3 has adopted the SASL framework. SASL provides a standard way for multiple authentication protocols to be supported by LDAPv3. Each type of authentication system corresponds to a particular SASL mechanism. An SASL mechanism is an identifier that describes the type of authentication protocol being supported. Note The IETF's Internet Engineering Steering Group (IESG) has requested that the LDAPv3 specification be altered to mandate that all clients and servers implement some authentication method more secure than sending cleartext passwords over the wire. The intent is to raise the bar for interoperability so that people using LDAPv3 clients and servers can be assured that their authentication credentials are not susceptible to network eavesdropping. As of September 1998, the details about the new mandatory-to-implement authentication methods were still to be worked out within the IETF. If you are considering purchase of LDAP software, you should ask your vendor about support for the final version of the LDAPv3 standard. After the server has verified the identity of the client, it can choose to grant additional privileges based on some site-specific policy. For example, you might have a policy that, when authenticated, users may search the directory, but that they may not modify their own directory entries. Or, you might have a more permissive policy that allows some authenticated users to modify certain attributes of their own entries whereas other users (your administrative staff) may modify any attribute of any entry. The way you describe the access rights, the entities to which those rights are granted, and the directory entries to which those rights apply is called access control . Access Control ModelsIt may come as somewhat of a disappointment to learn that LDAP does not currently define a standard access control model. However, this does not mean that individual LDAP server implementations have no access control model. In fact, any commercially successful server software must have such a model. The Netscape Directory Server, for example, has a rich access control model. The model works by describing what a given identity can do to some set of entries, with granularity down to the attribute level. For example, with the Netscape Server it is possible to specify an access control item (ACI) that allows a person to modify only the description attribute of his or her own entry. Or, the model can allow you to grant complete rights to the directory to all persons who are in a particular group. This allows easy creation of a set of directory administrators; a given person's rights can be easily revoked by removing them from the group. The model is fully documented in the Netscape Directory Server Administrator's Guide . Work has begun in the IETF on defining a standard access control model and a standard syntax for representing access control rights. The promise for the future is that you, as a directory deployer, will be able to deploy directory servers from several vendors and implement a consistent security policy across those servers ”whether they cooperate to serve a distributed directory or they are replicas of each other. Unfortunately, that is not the case today. You would be wise to document your access control policy in plain language so that you can adapt it to whatever model and syntax emerge from the standards bodies in the future. SSL and TLSSSL and TLS are new security technologies that encrypt all the data flowing between a client and a server. SSL, the older of the two technologies, has been a successful technology for the World Wide Web, securing electronic commerce and other transactions that depend on transmission of data being hidden from eavesdroppers. TLS, the follow-up to SSL, is an emerging Internet standard. LDAP offers a standard way for clients to begin encrypting all data flowing to and from LDAP on the connection using TLS. Just as SSL enabled a new class of applications on the Web, TLS will enable new uses of directory technology. For example, two companies in a trading partner relationship can allow directory queries from their trading partners to travel over the Internet. Because TLS encrypts these queries and the results, each company can rest assured that the directory data is protected while in transit over the Internet. Figure 3.21 depicts this scenario. Figure 3.21 TLS allows secure transmission of directory data over the Internet.In addition to allowing bulk encryption of all data flowing between clients and servers, SSL and TLS both allow mutual authentication using strong cryptography. Using X.509-based certificates, clients may prove their identity to servers while in turn verifying the identity of the server to which they are connected. This technology is already widely deployed on the World Wide Web. The Hypertext Transfer Protocol over SSL (HTTPS) is used to provide secure Web access and client authentication. In a similar fashion, LDAP over SSL (LDAPS) allows secure LDAP client access and client authentication facilities today. In the future, LDAPv3 clients can use the startTLS extended operation to begin encrypting an LDAP connection, and TLS to prove their identity to the server, as well as verify the server's identity.
|
Index terms contained in this sectionabandon operationfunctional model controls access control models 2nd add operation functional model update operations 2nd aliases naming model creating server support AND operator combining filters 2nd 3rd approximate filters functional model search operation atomic operations attributes information model entries 2nd 3rd directory schemas 2nd 3rd 4th operational 2nd types and values 2nd 3rd user 2nd values 2nd returning functional model search operation 2nd attrsOnly parameter (search operation) authentication 2nd IESG (Internet Engineering Steering Group) Kerberos protocol SASL support security model server-granted client privileges authentication operations functional model bind 2nd 3rd unbind bind operation functional model authentication SASL binds simple binds binding authentication clients default privileges combining filters functional model search operation 2nd 3rd compare operation functional model interrogation operations 2nd functional model update operations connections binding identities to constraints attribute values containers nodes control operations functional model abandon data functional model authentication operations 2nd 3rd 4th 5th control operations interrogation operations 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th update operations 2nd information model entries 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th naming model aliases 2nd 3rd DNs (distinguished names 2nd 3rd entries 2nd 3rd 4th 5th 6th X.500 nodes containers security model access control models 2nd SSL (Secure Sockets Layer) TLS default privileges authentication delete operation functional model update operations derefAliases parameter (search operation) values derefAlways value (derefAliases parameter) derefFindingBaseObject value (derefAliases parameter) derefInSearching value (derefAliases parameter) directories schemas information model entries 2nd distinguished names (DNs) naming model 2nd RDNs (relative distinguished names 2nd 3rd 4th 5th DNs (distinguished names) naming model 2nd RDNs (relative distinguished names) 2nd 3rd 4th 5th entries compare operation functional model interrogation operations 2nd functional model search operation types of searches 2nd 3rd functional model update operations add 2nd delete modify modify DN 2nd information model attributes 2nd 3rd 4th directory schemas 2nd LDIF text format 2nd 3rd 4th naming model aliases 2nd 3rd DNs (distinguished names) 2nd 3rd 4th 5th 6th 7th tree structure 2nd 3rd 4th 5th 6th root search operation functional model interrogation operations 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th equality filters functional model search operation escaped characters search filter quoting extensible match filters functional model search operation 2nd 3rd 4th syntax 2nd filters approximate functional model search operation combining functional model search operation 2nd 3rd equality functional model search operation extensible match functional model search operation 2nd 3rd 4th 5th 6th functional model search operation hiding from users 2nd presence functional model search operation quoting in functional model search operation 2nd substring functional model search operation 2nd formats entries LDIF text format 2nd 3rd 4th functional model authentication operations bind 2nd 3rd unbind control operations abandon interrogation operations compare 2nd search 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th update operations 2nd add 2nd delete modify modify DN 2nd hiding filters from users 2nd hierarchies 2nd UNIX vs. LDAP 2nd 3rd 4th X.500 naming model HTTPS (Hypertext Transfer Protocol over SSL) Hypertext Transfer Protocol over SSL (HTTPS) identities binding to connections IESG (Internet Engineering Steering Group) IETF IESG (Internet Engineering Steering Group) authentication information model entries 2nd 3rd 4th 5th directory schemas 2nd LDIF text format 2nd 3rd 4th Internet Engineering Steering Group, see IESG interrogation operations functional model compare 2nd search 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th Kerberos protocol Kerberos protocol (SASL binds) LDAP heirarchy vs. UNIX 2nd 3rd 4th LDAPv2 modify RDN operation models functional 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th information 2nd 3rd 4th 5th 6th naming 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th security 2nd 3rd 4th 5th 6th 7th LDAPv3 servers extensible match filters LDIF entries 2nd 3rd 4th models LDAP functional 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th information 2nd 3rd 4th 5th 6th naming 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th security 2nd 3rd 4th 5th 6th 7th modify DN operation functional model update operations 2nd modify operation functional model update operations modify RDN operation (LDAPv2) multivalued RDNs 2nd naming nodes naming model aliases creating server support DNs (distinguished names) 2nd 3rd entries tree structures 2nd 3rd 4th 5th 6th X.500 negation functional model search operation Netscape Directory Server 2nd Netscape Directory Server Administrator's Guide nodes naming object identifiers (OIDs) 2nd 3rd 4th objectclass attribute OIDs (object identifiers) 2nd 3rd 4th operational attributes operations atomic operators AND/OR combining filters 2nd 3rd OR operator combining filters 2nd 3rd parameters search operation attrsOnly base object derefAliases returning attribute list scope search filter size limits time limits prefix notation combining filters presence filters functional model search operation privileges default authentication protocols Kerberos SASL binds quoting RDNs 2nd search filters functional model search operation 2nd RDNs (relative distinguished names) naming model multivalued 2nd quoting 2nd relative distinguished names, see RDNs rename operation, see modify DN operation returning attributes functional model search operation 2nd returning attributes parameter (search operation) root entries SASL authentication support bind operations schemas directory information model entries 2nd scope parameter (search operation) search filter parameter (search operation) search operation functional model interrogation operations 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th approximate filters combining filters 2nd 3rd equality filters extensible match filters 2nd 3rd 4th 5th 6th hiding filters from users 2nd negation parameters 2nd 3rd 4th 5th 6th 7th 8th presence filters quoting in search filters 2nd returning attributed 2nd substring filters 2nd types of searches 2nd 3rd Secure Sockets Layer, see SSL security authentication 2nd IESG (Internet Engineering Steering Group) SASL support server-granted client privileges security model 2nd 3rd 4th 5th 6th access control models 2nd authentication 2nd IESG (Internet Engineering Steering Group) SASL support server-granted client privileges SSL (Secure Sockets Layer) TLS servers granting client privileges authentication granting default privileges LDAPv3 extensible match naming model alias support X.500 syntax support simple bind operations Simple Network Management Protocol (SNMP) size limit parameter (search operation) values SNMP (Simple Network Management Protocol) SSL (Secure Sockets Layer) security model standards X.500 naming model substring filters functional model search operation 2nd syntax extensible match filters search operation 2nd syntaxes attribute type X.500 server support attribute types time limit parameter (search operation) TLS security model types attribute information model entries 2nd 3rd search functional model search operation 2nd 3rd unbind operation functional model authentication UNIX hierarchy vs. LDAP 2nd 3rd 4th update operations functional model 2nd add 2nd delete modify modify DN 2nd users attributes hiding filters from functional model search operation 2nd values attribute constraints information model entries 2nd 3rd derefAliases parameter (search operation) X.500 naming model OIDs (object identifiers) 2nd 3rd 4th servers syntax support |
2002, O'Reilly & Associates, Inc. |