Chapter 5

The Directory Service and associated protocols


All OSI standards differentiate between the service and the protocols. The service is the functionality offered by the standard to users of the standard. In the case of the Directory Standard, the service is the functionality that is provided to a DUA by the Directory. The service provides a simple capability to modify and retrieve information stored in the Directory.

Note. The Standard calls the service the Directory Abstract Service, since the service interface is defined in abstract terms, using ASN.1. Real OSI implementations may provide a service to the user using programming language constructs, such as C procedures and data structures (or APIs).

The protocol is the mechanism that is used to relay a user's service request between OSI entities. In the case of the Directory, the protocol used by a DUA to relay a request to a DSA, is the directory access protocol (DAP). The DAP is built up from the parameters of the Directory service, as well as from those of two other OSI application services, namely the remote operations service (ROSE) [4.5] and the association control service (ACSE) [4.6]. The DUA can choose to operate in either synchronous mode or asynchronous mode. In synchronous mode, only one request at a time can be submitted to the Directory. The reply must arrive before the next request is submitted. In asynchronous mode, there can be many outstanding requests at any point in time.

Note.  The Remote Operations Service provides a simple request-reply type of service. The user provides a request to the ROSE, and it packages the request correctly, sends it off, and gives the user the reply when it arrives. All Directory requests are carried via the ROSE.

Note. The ACSE provides the service that connects two remote applications together. The connection (or association) has to be made before any other messages can be passed. ACSE is therefore a necessary element of all OSI application protocols.

When a DSA relays a user's request to another DSA, it also needs a service and protocol. The parameters of the DSA service are the same as those of the Directory service, but in addition the chaining parameters have been added. The directory system protocol (DSP) is therefore similar to the DAP, but DSP requests also contain Chaining Arguments, and DSP results also contain Chaining Results (Chapter 9). One further difference, is the way in which the DSP uses the ROSE. With the DSP, either DSA may send requests to (invoke operations on) the other DSA. With the DAP, only the DUA may issue requests. (It would clearly be a nonsense for a DSA to try to retrieve directory information from a DUA!) Furthermore, DSAs can only operate in asynchronous mode.

The service, and hence the protocols, defined in the '88 edition of the Standard, have only been minimally affected by the '93 enhancements. This has been intentional, in that a design policy of the extension work was that '88 and '93 systems should be capable of interworking. Furthermore hooks were built into the '88 edition of the Standard so that the '93 enhancements could be easily slotted in later. (Examples of such hooks are the Security Error (Insufficient Access Rights) (§ 5.18.6) and the Service Control 'do not use copies of entries at all' (§ 5.4.1). It was known before the '88 Standard was finalised, that further work needed to be done, see Table 1.1.) Nevertheless, we did not get it 100% right in 1988, since it is always difficult to predict the future accurately. Consequently some 'rules for extensibility' had subsequently to be defined for the '93 protocols, that were also retrospectively applied to the '88 Standard via the defect mechanism. These rules are described at the end of this chapter (§ 5.19), and they should now ensure that any '96 or later enhancements to the Directory protocols, can be transparently handled by the earlier '88 and '93 implementations without them undergoing any further changes.

Because '88 implementations already exist, and will probably continue to exist for many years to come, the description of the service that is provided here differentiates between those features that are defined in the '88 edition of the Standard, and the additional features that are added by the '93 work.

The service consists of Bind and Unbind operations, four interrogation operations (two read-like operations and two search-like operations), an abandon operation, and four modification operations. Each will be described in turn. As we shall see later, human users are not always provided with the full functionality of this service, since a DUA implementation may choose not to make certain features available at its user interface (Fig. 4.1).


Before a user (via the DUA) can ask the Directory to perform any of its operations, the DUA must establish a connection (association) to a DSA. This is achieved via the Directory Bind operation. Before a DSA can chain an operation to another DSA, an association must be established between the DSAs via a DSA Bind operation. Both the Directory Bind and DSA Bind operations have identical parameters, which are: the credentials of the initiator, and the Directory protocol version number. The only difference between them, is that the Directory Bind establishes an association that talks the DAP, whilst a DSA Bind establishes an association that talks the DSP. Both Bind operations map onto the association control service element A-ASSOCIATE. The Standard gives details of how to set all of the A-ASSOCIATE parameters, so that the correct association can be established. The most important of these is obviously an identification of the protocol to be used i.e. either the DAP or the DSP.

The Directory protocol version number currently only has one defined value - version 1 - and so all implementations talk the same language. The rules for extensibility ensure that '88 and '93 implementations both understand the same protocol and can interwork successfully (w/w 5.1). One final small point about the protocol version number. It can be omitted altogether from the Bind operation, in which case it is implied that version 1 is the desired Directory protocol i.e. this is the default.

The credentials of the initiator is a complex parameter. It can be set to either simple credentials or strong credentials, or can carry parameters not defined by the Standard, or can be omitted altogether. In the latter case, the caller would be unidentified and unauthenticated by the Bind operation. This is the mode most often used by the current (mostly academic) pilot projects, which allow public access to a significant amount of data held in the Directory. It is doubtful if many commercial organisations will allow unauthenticated access by external users once a significant amount of their data is held in X.500 conformant systems, although some data e.g. telephone numbers, may remain public.

The catch all hook which allows private institutions, such as the DoD or NATO, to define their own authentication parameters, is there to encourage greater use of X.500 by organisations which may have strict rules about security, and who do not want even their authentication mechanisms to be widely known.

As explained more fully in Chapter 7, simple credentials consist of a user name and password (or protected password), whilst strong credentials are based on digital signatures. Table 5.1 lists the parameters that make up simple credentials, and Table 5.2 those that make up strong credentials. In order to understand them more fully, you must first read Chapter 7.

Table 5.1 The parameters of simple credentials
Parameter  ASN.1 Parameter Encoding  Mandatory/Optional
Sender's name DistinguishedName  Mandatory
Timestamp 1  UTCTime Optional
Timestamp 2  UTCTime  Optional
Random number 1 BIT STRING  Optional
Random number 2 BIT STRING  Optional
Password or Protected Password OCTET STRING or 


Note Values of the ASN.1 type SIGNATURE {OCTET STRING} consist of the object identifier of the one-way function(s) used to encode the password, plus any associated parameters used by the one-way function(s), as well as the protected password itself. SIGNATURE is an ASN.1 Macro/Information Object - shown in Figure 7.6 - and is simply a short-hand way of saying that the accompanying ASN.1 type (in this case an OCTET STRING) will be encoded (protected) prior to transfer, and that these other parameters (i.e. the object identifier of the encoding routine(s), plus their associated parameters) will accompany it.

Once the recipient has received the Bind operation, and successfully authenticated the initiator, the recipient sends a Bind Result reply to the initiator. The parameters of the Bind Result are identical to those of the Bind operation i.e. simple, strong, externally defined or no credentials. This allows the initiator to authenticate the recipient of the Bind operation. As explained in Chapter 7, a DSA will usually not send its password to the DUA, and so will either be unauthenticated or will use strong authentication.

If the authentication failed, a Security Error (either Inappropriate Authentication or Invalid Credentials - see § 5.18.6) can be returned to the initiator instead of a Bind Result.

If the recipient currently does not have sufficient resources with which to provide a service to the initiator, it may send a Service Error (Unavailable) -see § 5.18.3.

Table 5.2 The parameters of strong credentials
Parameter ASN.1 Parameter Encoding  Mandatory/Optional
Certification path from receiver to sender CertificationPath  Optional
Strong authentication token Digitally SIGNED SEQUENCE of: 

Signature Algorithm Identifier 

 DistinguishedName of Receiver 

 UTCTime (a timestamp) 

 BIT STRING (a random number) 

Requestor The name of the sender  Optional
Note SIGNED is also an ASN.1 Macro/Information Object, similar to SIGNATURE. The only difference between the two, is that a SIGNED {type} transfers the {type}, in the clear, in addition to all the other information carried in a SIGNATURE (Fig. 7.6).

5.2.1 Visibility of the Bind Operation to the User

Human users may not be aware of the Bind operation. Your DUA implementation may automatically Bind to the home DSA when you first log on to the application, or when you make your first directory request. If the DUA application requires you to identify yourself before you can use it, then the Bind will probably be established during this phase. More complex human interfaces could allow you to choose which DSA you wish to Bind to, although I am not aware of any such user friendly interfaces to date.

Note. A non-user friendly interface such as DISH, provided with the Quipu implementation, does allow the user to Bind to different DSAs.

(This text is a bit dated now, since LDAP DUAs usually do allow the user to choose which directory server to Bind to - Ed.)

Applications using standardised DUA interfaces such as XDS [9.1] do have the Bind operation available to them via an equivalent procedure call, and the full set of Bind parameters is usually available to them.

Note XDS is a standardised interface between a DUA and any application that uses the Directory. It has been defined by the X.400 API Association of the USA and X/Open Ltd of the UK. It is far more complex than the LDAP API.


After the user (DUA) has completed its series of requests to the Directory, and received all the results (or errors) to its operations, the final task is to close the connection to the DSA. This is achieved via the Directory Unbind operation. Similarly, after a DSA has completed chaining a series of requests to a remote DSA, and received all the responses, it may close the association via a DSA Unbind operation. Neither Unbind operation has any parameters, and neither Unbind operation can fail. The recipient is not allowed to send any information to the initiator of the Unbind operation. In many respects, the Unbind operation is very similar to replacing the telephone on its hook, after saying farewell to your communicant. The call is closed irrevocably, and neither party can stop it from happening, once the process has been started. You are of course, free to re-dial the person again, but this is equivalent to issuing another Bind operation.

The Unbind Operation maps onto the Association Control service element A-RELEASE.

5.3.1 Other Ways of Terminating a Directory Dialogue

If a user is no longer interested in querying the Directory, or in receiving replies to outstanding operations, then the dialogue can be terminated in several unclean ways. A human user could simply switch off the PC, or quit the DUA application (if such an exit has been programmed into the DUA). Switching off the PC would cause the remote DSA to receive an A-P-ABORT service, this being a notification that the association with the remote DUA has failed. Likewise, if the remote DSA crashed, the DUA software would receive an A-P-ABORT service. Quitting the DUA application could cause the DUA software to either spontaneously send an Unbind operation (if all queries have been replied to), or, if any user requests are still outstanding, an A-ABORT request. Likewise, the remote DSA software could decide to spontaneously close down its association with your DUA, by issuing an A-ABORT request.

5.3.2 Visibility of the Unbind Operation to the User

What termination facilities are actually available to the user very much depends upon the facilities of the DUA implementation. In most synchronous human user interfaces, i.e. ones in which the user can only make one request at a time to the Directory, the user is usually provided with a simple quit option. This will be mapped by the DUA software into an Unbind or A-Abort as explained above. Applications that use standard interfaces such as XDS, are provided with an Unbind service.

What effect received A- and A-P-ABORTs have on the service as perceived by the user, is again dependent on the DUA implementation. A DUA implementation could, for example, try to re-establish a terminated association automatically, thus shielding the user from its effects. Most interfaces will probably notify the user that a failure has occurred, for example, XDS passes communication failures to the application via a Communications-Error parameter.


Every operation (excluding Bind, Unbind and Abandon) has a set of common parameters that are used to qualify its invocation. These are shown in Table 5.3.

Table 5.3 The Common Arguments
Common Arguments Described in 
Service Controls 5.4.1
Security Parameters 5.4.2 
Distinguished Name of Requester (DUA) 7.8.1 
Operation Progress  9.13.4 
Aliased RDNs 9.13.6
Extensions 5.20

5.4.1 Service Controls

These parameters are ones that generally describe the quality of service that the user requires. They are shown in Table 5.4. Note that all the parameters are optional, but if they are missing they have a default value that is assumed, as shown in column 3 of the table. For the parameters which are encoded as bits in a BIT STRING, a parameter is made active by setting the corresponding bit to 1. If set to a zero, or missing, then the default is assumed.

A few of these parameters are worthy of further explanation. If local scope is set (bit 2), then the operation should only be executed within some locally pre-defined area, for example, the home DSA or the set of DSAs in the local management domain. The precise meaning of local scope is not standardised, and so each administrator will have to configure their DSA(s) to respond appropriately. If a user's query cannot be satisfied within the local area, then an error will need to be returned. Unfortunately the Standard does not suggest which error should be returned in this instance, but Service Error (Out Of Scope), or Name Error (No Such Object) might be appropriate.

The interaction of the copy flags (bits 3 and 6) works as follows. '88 DSAs do not recognise bit 6, and so if bit 3 is not set, they may return any (partial or complete) copy to the user. In '93 DSAs, bit 6 is only meaningful if bit 3 is not set. If bit 3 is set then entry copies will never be used. If neither bit is set, the Directory will only use copied data if it can guarantee (subject to the weak consistency of shadowing - see § 6.1) that the answer returned from an entry copy is the same as that which would be returned from the master entry, were that to be used. The attribute complete flag used in shadowing (§ 6.3.1) tells a shadow DSA that it has a complete copy of an entry, and so in this case it can guarantee that the answer is the same. If a DSA cannot guarantee that its copy is complete, then it will always chain or refer the request to the master DSA. If a user is happy with an entry copy that may be incomplete, but which is locally accessible (and therefore quicker and cheaper to access), then bit 6 should always be set. I recommend that bit 6 should normally be set for human users browsing the Directory. This is because there are certain circumstances when a query can never be satisfied by an entry copy unless bit 6 is set. For example, when a shadow copy is made of the most commonly accessed attributes of a person, such as Email address and telephone number, but not of less useful ones, such as a facsimile photograph, then a request to Read All Attributes would always be chained (or referred) to the master entry by the '93 DSA holding the copy (unless bit 6 was set).

The maximum elapsed time is the time which all DSAs collectively have to process a user's request. It includes processing, queuing and communication time. Clearly in a distributed environment, a count in seconds cannot be meaningfully passed between DSAs, and so the home DSA converts this into a date and time (UTCTime) before chaining it to the next DSA (§ 9.13.10).

The maximum attribute size in octets is an approximate measure of the size of a stored attribute (its type and all its values) at a DSA. The measure is imprecise because different DSA implementations will store the same attribute in different ways, due to local storage techniques and syntaxes. Nevertheless, the control gives the user a useful mechanism for eliminating large attributes from returned results. If such attributes are excluded, then the user is told of this via the incompleteEntry boolean (§ 5.6.3) in the result.

Table 5.4 The Service Controls
Parameter ASN.1 Parameter Encoding  Default
Prefer Chaining rather than Referrals Bit 0 of BIT STRING  No preference for either
Chaining is prohibited Bit 1 of BIT STRING  Chaining is OK
Operation should only be performed locally Bit 2 of BIT STRING  Operation can be performed globally 
Do not use copies of entries at all Bit 3 of BIT STRING  (Complete) copies of entries are OK
Do not dereference aliases during name resolution  Bit 4 of BIT STRING Aliases can be dereferenced 
*Access Subentries 

(List and Search only) 

Bit 5 of BIT STRING Subentries are inaccessible in List and Search operations 
*Partial copies of entries will do Bit 6 of BIT STRING  Only complete copies of entries are OK
Operation priority INTEGER (0=low, 1=medium, 2=high)  Medium Priority
Maximum elapsed time in seconds  INTEGER  Infinity
Maximum number of entries to be returned in a List or Search  INTEGER  Infinity
Only return referrals to INTEGER (0=the local domain, 1=this country)  Referrals to anywhere
*Maximum attribute size in octets  INTEGER  Infinity
* signifies parameters added in the '93 edition of the Standard

If the user asks for a level of service that is different from the one normally provided by the Directory (i.e. the service that would be provided if the service controls had not been set), then the Directory will flag a problem to the user in the result. For example, if the user said do not dereference aliases and an alias was encountered, then the Directory would return the error Name Error (Alias Dereferencing Problem); or if the user set the size limit below the actual number of entries that were capable of being returned, then the Directory would signal a Partial Result (Size Limit) and only return an arbitrary selection of entries up to the number requested. If however the user asks for a level of service that is equalled or surpassed by Directory, e.g. the user sets a time limit of 10 seconds, and the complete response is generated in 5 seconds, then no problem will be flagged.

5.4.2 Security Parameters

The security parameters are primarily there in order to aid strong authentication of each user request, and a full description of the first four can be found in Chapter 7. The complete set of parameters is shown in Table 5.5, and each one is optional.

Table 5.5 Security Parameters
Parameter ASN.1 Parameter Encoding 
Certification path from the recipient to the sender  CertificationPath
The name of the recipient DistinguishedName 
A Timestamp UTCTime
A Random number  BIT STRING 
Protection Request  INTEGER(0=none 1=signed) 
Protection Request is set by the user to indicate the degree of protection to be provided on the Operation Result. The DSA providing the response will not provide signed Operation Results unless requested to. If a DUA is incapable of deciphering digital signatures, then clearly it will not request them. Even if they are requested, signed results will only be returned if the DSA is capable of producing them. The default is always for unsigned results to be generated. If the DSA wishes to sign a result, but the user did not request it, then the DSA may return a Security Error (protection required).

When security parameters are present in Chaining Arguments, then protection request is set by the chaining DSA, and it indicates whether or not the chained result should be signed. Signatures on chained results are always removed by the receiving DSA as explained in § 7.6, and these are independent of the signature on the operation result (which is embedded in the chained result).

Protection request cannot be set in the security parameters of either Chaining Results or Common Results.

5.4.3 Visibility of Common Arguments to the User

Simple human user interfaces do not usually let the user know that such parameters exist. They may provide the system administrator with tools to configure in different values for the various service controls, or they may come pre-compiled with fixed values, usually the standardised defaults. Either way the user is normally oblivious of their existence. More sophisticated human interfaces do have configuration options, and these allow the user to set up values for the Common Arguments - primarily the service controls - prior to invoking any Directory operations.

The standardised API, XDS, allows the calling application to have full control of all the Common Arguments (except that the setting of security parameters is not standardised).


The four interrogation operations each have a common set of parameters, that are used to qualify the result. These are shown in Table 5.6.

Table 5.6 The parameters of Common Results
Common Results Described in 
Security Parameters  5.4.2 
Distinguished Name of the Result Originator  7.8.2
Alias Dereferenced Flag 5.5 
The alias deferenced flag is a boolean, which is set to True if the original name given in the request by the user, was actually the name of an alias of the target object. In this case (but subject to access controls - see § 8.6) the user will be given the distinguished name of the target object, so that this can be used by him in subsequent requests.


The Read operation - the first of the read-like operations - is a simple interrogation operation that returns the values of particular attributes held in an entry. The Read operation has the parameters shown in Table 5.7.

I have used the term purported name instead of distinguished name for the name of the entry, since the name presented by the user may not actually be the distinguished name of an entry. The purported name, which is syntactically the same as a distinguished name, is the user's best guess for the name of the entry, but it may or may not name an actual entry in the DIT. If it does name an entry in the DIT, then it truly was a distinguished name, and the user will receive a result. Alternatively, the purported name may reference an entry via one of its alias names, in which case the user will be informed of this in the result (via the alias dereferenced flag of Common Results).

Table 5.7 The parameters of the Read operation
Read Arguments Described in 
Purported Name of an Entry  5.6 
Entry Information Selection  5.6.1 
*Tell Me My Modify Rights  5.6 
Common Arguments 5.4
* signifies a parameter added in the '93 edition of the Standard

Similarly, the purported name may reference an entry via an alias of one of the superiors of the entry. Finally, the purported name may not reference any entry in the DIT. In this case the user would be sent an error diagnostic, most probably Name Error (No Such Object), instead of a result.

The parameter 'entry information selection' is a complex parameter which precisely describes the information that the user wants to retrieve from the entry. It is described in the next section.

'Tell me my modify rights' is a boolean, which if set to True by the user, will return the complete set of modification access rights that the user has to the particular entry. This new feature was added as a result of the access control work, which from reading Chapter 8, you will gather is quite complex. This boolean should allow users to simply find out what modification rights they possess to an entry.

Section 5.6.4 gives an example of a Read request and the returned result.

5.6.1 Entry Information Selection

Entry information selection is used by Read and Search operations, to select which information is to be returned from an entry. The parameter became more complex in '93, with the creation of operational attributes and the desire to let '88 DUAs access operational attributes in '93 DSAs. The interaction of selected attributes and selected extra attributes works as follows.

An '88 DUA implementation can select All User Attributes (w/w 5.6), which will return all the attributes held by an '88 DSA, or all those attributes held by a '93 DSA which are classified as user attributes. Remember that this is all the attributes defined in the '88 Standard, plus collective ones defined in the '93 Standard. So an '88 DUA will be able to retrieve more (user) attributes from a '93 DSA, than from an '88 DSA.

Table 5.8 The parameters of Entry Information Selection
Parameter Allowed Values  Default
Selected Attributes either All User Attributes or Specifically Named Attributes  All User Attributes
Selected Information either Attribute Types Only or Attribute Types and Values  Attribute Types and Values
*Selected Extra Attributes either All Operational Attributes or Specifically Named Attributes  None
* signifies a parameter added in the '93 edition of the Standard

Alternatively, the '88 DUA can individually specify which attributes are to be returned. If an empty set is specified by the user, then no attributes will be returned in the response. The specification can be for any type of attribute: user, collective or operational, but of course, the '88 DUA cannot tell the difference. When accessing a '93 DSA, increased functionality is gained by the '88 DUA, in that it can access operational attributes held by the '93 DSA. A '93 DUA has the same capability as the '88 DUA described above, but in addition, it can select extra attributes. An '88 DUA cannot select extra attributes, as it is not aware that this parameter exists. If an '88 DSA receives a request for extra attributes, it will ignore this unknown parameter (§ 5.19). It will only return those attributes already selected by the first parameter.

If the '93 DUA's request is for all operational attributes, then a '93 DSA will return all the operational attributes stored in the entry. This is in addition to the attributes already selected via selected attributes. An '88 DUA can only retrieve all the operational attributes held in a '93 entry, by specifically naming them all (you will agree that this is very tedious!).

Alternatively, the '93 DUA can specifically list the set of extra attributes to be returned. So for example, a '93 DUA can simultaneously request all user attributes and a selection of operational attributes. This latter task can only be achieved by an '88 DUA if it makes two Read requests to the Directory, one for all user attributes and one for specifically named operational attributes. If the '93 user lists two sets of attributes, using the first and third parameters, and mistakenly puts the same attribute in both lists, then the DSA may return it twice. In order to understand why the user may specify two lists of attributes, see w/w 5.7.

One final point about the attributes which will be returned. With the introduction of attribute hierarchies (§ 2.10), if the user specifically names an attribute super-type, then the super-type and all its sub-types will be returned by '93 DSAs, and the sub-types will be specifically identified. This might be confusing to an '88 DUA, which may receive more attributes from a '93 DSA than it actually asked for!

Having determined the attributes of interest, the user finally specifies whether the attribute types only (i.e. just the object identifiers) or the types and their values, are to be returned.

5.6.2 The Read Result

The information returned in the Read Result is listed in Table 5.9.

The returned modify rights requested by the user, lists the modify permissions that the user has for each attribute type and each attribute value stored in the entry, and also for those of the entry as a whole. See Chapter 8 for a full description of these permissions.

Table 5.9 The parameters of the Read Result
Read Result Described in 
The Entry Information requested  5.6.3 
*The Modify Rights requested 5.6.2 
Common Results 5.5
* signifies a parameter added in the '93 edition of the Standard

5.6.3 Entry Information

Entry information is returned in the results of Read and Search operations. The complete set of parameters comprising entry information is shown in Table 5.10.

'88 DSAs always return the distinguished name of the entry being read. '93 DSAs only return the distinguished name of the entry if the user has permission (grantReturnDN - see Chapter 8) to know it. If the user does not have permission, then the Directory will, in the case of a Read operation or the base object of a Search operation, return the purported name provided by the user on the request; or in the case of other entries selected by a Search operation, either return the name of an alias of the selected entry or omit the entry from the result.

Table 5.10 The parameters of Entry Information
Parameter ASN.1 Parameter Encoding 
The name of the entry  Distinguished Name 
Flags if the information was retrieved from the entry (rather than a copy)  BOOLEAN DEFAULT TRUE
The requested information SET OF either Attribute Types or Attribute Types and Values 
*Flags if the entry information is incomplete  BOOLEAN DEFAULT FALSE
* signifies a parameter added in the '93 edition of the Standard

The requested information of attribute types, or types and values, is returned in response to that which the user selected. A DSA will return as much information as is possible, subject to access controls and limits such as time and size. DSA implementations should allow administrators to set parameters which limit the amount of information that the DSA is willing to return to users, as well as to control the amount of processing time that the DSA will spend on behalf of users.

If a DSA cannot return anything that the user asked for, then in response to a Read operation, it will return the error Attribute Error (No Such Attribute Or Value), whereas in response to a Search operation it will return an empty set of information. '93 DSAs have the additional capability of flagging that the returned information is incomplete in some way. This can be used in situations where an attribute exceeds the requested attribute size (§ 5.4.1), or where a user does not have access rights to everything (Chapter 8).

If the information was retrieved from a shadow or cached copy of the entry, then the from entry boolean is set to False.

5.6.4 An Example of a Read Request

Figure 5.1 shows a hypothetical entry in the DIT. Suppose we wish to read the telephone and fax numbers of Jim Smith. (Suppose further that we would like to read the actual values stored in the entry, rather than copies of them held somewhere else.) Obviously it is not possible to show the interaction between the human user and the DUA, as this interface is not standardised, and many different user interfaces exist. However, the interface would need to extract the purported name from the user, and probably some indication of which attributes are required. (Simple human user interfaces often do not have this latter capability, and instead will read All User Attributes. More sophisticated human interfaces, and APIs such as XDS, do give complete control to the caller, allowing the user to request specific attributes.) We would also need to configure the interface to read (master) entries rather than copies.

Fig. 5.1 An example of a Read Request.

Supposing that all of this is achieved, then Fig. 5.1 shows the parameters that would be sent to the Directory in the Read operation. It also shows the parameters of the Read response that would be sent back to the DUA. If a parameter is not shown in the figure, then it means that the standardised default values are to be assumed by the recipient e.g. strong authentication is not being used in this example. Note that the syntax used in the example request and response messages is only a simple approximation of the ASN.1 values.


The Compare operation - the second of the read-like operations - is even simpler than the Read operation. Its purpose is to check whether or not an entry holds a particular attribute value - the purported attribute value presented by the user. The answer from the Directory is a qualified yes or no.

The Compare operation is really only of use in checking the value of attributes, such as passwords, that their owners do not wish the Directory to return to anyone. A fuller description of its role in this respect is described in Chapter 7.

The parameters of the Compare operation are shown in Table 5.11.

Table 5.11 The parameters of the Compare Argument
Compare Arguments Described in 
The Purported Name of an Entry  5.6 
The Purported Attribute Value 5.7 
Common Arguments 5.4
Matching is performed by comparing the purported attribute value presented by the user against the actual attribute values stored in the entry, using the equality matching rule defined for the attribute type. Thus if the equality matching rule defined for a string attribute, is the case ignore matching rule, then the case of the presented value will not be taken into account when performing the comparison. This is shown in the example in Fig. 5.2.

Fig. 5.2 An example of a Compare Request.

5.7.1 The Compare Result

The result of a Compare operation is shown in Table 5.12. The distinguished name of the entry is only returned if the user provided an alias name in the request. In this situation, '88 DSAs will always return the distinguished name of the entry, but '93 DSAs will only return it if the user has permission to know it (§ 8.6). If the user does not have permission to know the distinguished name of the entry, it will be omitted from the result, just as if the user had provided the distinguished name in the request.

Table 5.12 The parameters of the Compare Result
Compare Result ASN.1 Parameter Encoding 
The distinguished name of the entry DistinguishedName OPTIONAL 
The matched flag - indicates the result of the comparison  BOOLEAN
Flags if the information was retrieved from the entry  BOOLEAN DEFAULT TRUE
*The subtype used in the comparison AttributeType OPTIONAL 
Common Results see § 5.5 
* signifies a parameter added in the '93 edition of the Standard

The matched flag is set to True if the entry does contain the purported attribute value presented by the user, and to False if it does not. '93 DSAs will also return False, if the user does not have permission to compare against the actual attribute value (Chapter 8).

Because '93 DSAs support attribute hierarchies, they are also allowed to perform the comparison against sub-types of the presented attribute, which are held in the entry. If a match was obtained against a value of a sub-type rather than the presented type, then the matched flag would be set to True, but in addition, the actual sub-type of the attribute used in the comparison would be returned to the user. For example, if I asked the Directory if an entry held a password attribute with value FRED, a 93 DSA might reply Yes, but it is a login password attribute (assuming login password is an attribute sub-type of password).

'93 DSAs also support collective attributes. Because collective attributes appear to be in an entry just like the other user attributes, they can be used in the Compare operation just like the other attributes.

Finally, if the comparison was executed in a shadow or cached copy of the entry, then the from entry boolean is set to False.