3. An Introduction to LDAP

Understanding and Deploying LDAP Directory Services > 3. An Introduction to LDAP > The LDAP Models

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053055078209010182096028064086020

The LDAP Models

LDAP 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 Model

The 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 Schemas

Any 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 Model

The 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 Quoting

You'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
Character Decimal Value Escaped as
Space at the beginning or end of a DN or RDN 32 \ <space>
Octothorpe ( # ) character at the beginning of a DN or RDN 35 \#
Comma ( , ) 44 \,
Plus sign ( + ) 43 \+
Double-quote ( " ) 34 \"
Backslash ( \ ) 92 \\
Less-than symbol ( < ) 60 \<
Greater-than symbol ( > ) 62 \>
Semicolon ( ; ) 59 \;
Aliases

Alias 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 Model

Now 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 Operations

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

  • neverDerefAliases ”Do not dereference aliases in searching or in locating the base object of the search.

  • derefInSearching ”Dereference aliases in subordinates of the base object in searching, but not in locating the base object of the search.

  • derefFindingBaseObject ”Dereference aliases in locating the base object of the search, but not when searching subordinates of the base object.

  • derefAlways ”Dereference aliases both in searching and in locating the base object of the search.

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 Filters

An 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 Filters

When 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 Filters

In 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" Filters

LDAP 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 Filters

Another 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 Matching

The 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

  • An attribute name. If omitted, any attribute type that supports the given matching rule is compared against the value.

  • The optional string : dn , which indicates that the attributes forming the entry's DN are to be treated as attributes of the entry during the search.

  • An optional colon and matching rule identifier that identifies the particular matching rule to be used. If no matching rule is provided, the default matching rule for the attribute being searched should be used. If the attribute name is omitted, the colon and matching rule must be present.

  • The string " := ".

  • An attribute value to be compared against.

Formally, the grammar for the extensible search filter is

 attr [":dn"] [":" matchingrule] ":=" value 

The elements of this syntax are as follows :

attr is an attribute name.

matchingrule is usually given by an Object Identifier (OID), although if a descriptive name has been assigned to the matching rule, that may be used as well. The OIDs of the matching rules supported by your directory server will be given in its documentation.

value is an attribute value to be used for comparison.

Object Identifiers

Object Identifiers, commonly referred to as OIDs, are unique identifiers assigned to objects. They are used to uniquely identify many different types of things, such as X.500 directory object and attribute types. In fact, just about everything in the X.500 directory system is identified by an OID. OIDs are also used to uniquely identify objects in other protocols, such as the Simple Network Management Protocol (SNMP).

OIDs are written as strings of dotted decimal numbers . Each part of an OID represents a node in a hierarchical OID tree. This hierarchy allows an arbitrarily large number of objects to be named, and it supports delegation of the namespace. For example, all the user attribute types defined by the X.500 standards begin with 2.5.4. The cn attribute is assigned the OID 2.5.4.3, and the sn attribute is assigned the OID 2.5.4.4.

An individual subtree of the OID tree is called an arc . Individual arcs may be assigned to organizations, which can then further divide the arc into subarcs, if so desired. For example, Netscape Communications has been assigned an arc of the OID namespace for its own use. Internally, it has divided that arc into a number of subarcs for use by the various product teams . By delegating the management of the OID namespace in this fashion, conflicts can be avoided.

The X.500 protocol makes extensive use of OIDs to uniquely identify various protocol elements. LDAP, on the other hand, favors short, textual names for things: cn to describe the common name attribute and person to identify the person object class, for example. To maintain compatibility with X.500, LDAP allows a string representation of an OID to be used interchangeably with the short name for the item. For example, the search filters (cn=Barbara Jensen) and (2.5.4.3=Barbara Jensen) are equivalent. Unless you are working with an LDAP-based gateway into an X.500 system, you should generally avoid using OIDs in your directory-enabled applications.

Although LDAP largely does away with the mandatory use of OIDs, you will see them from time to time, especially if you use extensible matching rules or if you design your own schema extensions. The topic of extending your directory schema is discussed in Chapter 7.

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.

Negation

Any 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 Terms

Filters 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
Filter Type Format Example Matches
Equality (attr=value) (sn=jensen) Surnames exactly equal to jensen
Substring (attr=[leading] *[any]*[trailing] (sn=*jensen*) Surnames contain ing the string jensen
    (sn=jensen*) Surnames starting with the string jensen
    (sn=*jensen) Surnames ending with the string jensen
    (sn=jen*s*en) Surnames starting with jen , containing an s , and ending with en
Approximate (attr~=value) (sn~=jensin) Surnames approximately equal to Jensin (for example, surnames that sound like Jensin ”note the misspelling)
Greater than or equal to (attr>=value) (sn>=Jensen) Surnames lexicographically greater than or equal to Jensen
Less than or equal to (attr<=value) (sn<=Jensen) Surnames lexicographically less than or equal to Jensen
Presence (attr=*) (sn=*) All surnames
AND (&(filter1) (filter2) )) (&(sn=Jensen) (objectclass=person)) Entries with an object class of person and surname exactly equal to Jensen
OR ((filter1) (filter2) )) ((sn~=Jensin) (sn=*jensin)) Entries with a sur “name approximately equal to Jensin orcommon name ending in jensin
NOT (!(filter) (!(mail=*)) All entities without a mail attribute
Quoting in Search Filters

If 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
Character Value (Decimal) Value (Hex) Escape Sequence
* (asterisk) 42 0x2A \2A
( (left parenthesis) 40 0x28 \28
) (right parenthesis) 41 0x29 \29
\ (backslash) 92 0x5C \5C
NUL (the null byte) 0x00 \00

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 Returned

As 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
Attribute List Attributes Returned
cn, sn, givenname cn , sn , and givenname only
* All user attributes
1.1 No attributes
modifiersname modifiersname only (an operational attribute)
*, modifiersname All user attributes plus modifiersname
Common Types of Searches

Although the LDAP search operation is extremely flexible, there are some types of searches that you'll probably use more frequently than others:

  • Retrieving a single entry ”   To retrieve a particular directory entry, you use a scope of base , a search base equal to the DN of the entry you want to retrieve, and a filter of ( objectclass=*) . The filter, which is a presence filter on the objectclass attribute, will match any entry that contains at least one value in its objectclass attribute. Because every entry in the directory must have an objectclass attribute, this filter is guaranteed to match any directory entry. And because you've specified a scope of base , only one entry will be returned by the search (if the entry exists at all). This is how you use the search operation to read a particular entry.

  • Listing all entries directly below an entry ”   To list all the directory entries at a particular level in the tree, you use the same filter (objectclass=*) as when retrieving a particular entry; but you use a scope of onelevel and a search base equal to the DN just above the level you want to list. All the entries immediately below the searchbase entry are returned. The search base entry itself is not returned in a onelevel search. (The search base entry is returned in a base or subtree search if it matches the search filter.)

  • Searching for matching entries within a subtree ”   Another common search operation occurs within a subtree of the directory for all entries that match some search criteria. To perform this type of search, use a filter that selects the entries you are interested in retrieving ”or ( objectclass=*) if you want all entries ”along with a scope of subtree and a search base equal to the DN of the entry at the top of the tree you want to search.

Hiding LDAP Filters from Users

You 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 Operation

The 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 Operations

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

  • The parent of the new entry must already exist in the directory.

  • There must not be an entry of the same name.

  • The new entry must conform to the schema in effect.

  • Access control must permit the operation.

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:

  • The entry to be deleted must exist.

  • It must have no children.

  • Access control must permit the entry to be deleted.

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:

  • The entry being renamed must exist.

  • The new name for the entry must not already be in use by another entry.

  • Access control must permit the operation.

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:

  • The entry to be modified must exist.

  • All of the attribute modifications must succeed.

  • The resulting entry must obey the schema in effect.

  • Access control must allow the update.

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 Operations

There 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 Model

We'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 Models

It 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 TLS

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



Understanding and Deploying LDAP Directory Services,  2002 New Riders Publishing
<  BACK CONTINUE  >

Index terms contained in this section

abandon operation
          functional 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.



Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 1997
Pages: 245

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net