Clients and Servers

LDAP Client---An application (for example, Netscape* Communicator*, Internet Explorer, or Novell Import Conversion Export utility).

LDAP Server---A server where nldap.nlm (for NetWare^®), nldap.dlm (for Windows 2000/NT), libnldap.so (for Linux, Solaris and AIX systems), or libnldap.sl (for HP-UX systems) is running.

Objects

LDAP Group object---Sets up and manages the Novell LDAP properties on an LDAP server.

This object is created when you install eDirectory. An LDAP Group object contains configuration information that can be conveniently shared among multiple LDAP servers.

LDAP Server Object---Sets up and manages the way LDAP clients access and use the information on a Novell LDAP server.

This object is created when you install eDirectory. An LDAP Server object represents server-specific configuration data.

The following figure illustrates an LDAP Server object in Novell iManager.

Referrals

Referral---A message that the LDAP server sends to the LDAP client telling the client that this server can't provide complete results and that more data might be on another LDAP server.

The referral contains all the information needed to progress the operation.

Scenario: An LDAP client issues a request to an LDAP server but the server can't find the target entry of the operation locally. Using the knowledge references that it has about partitions and other servers, the LDAP server identifies another server that knows more about the entry. The LDAP server sends that information to the client.

The client establishes a new LDAP connection with the identified server and retries the operation.

Referrals have the following advantages:

• The LDAP client keeps control of the operation.

  Because the client always knows what is happening, it can make better decisions and provide feedback to the user. Also, the client can opt not to follow through on a referral, or prompt a user before following it.

• Referrals often use network resources more efficiently than chaining.

  In chaining, a requested search operation with many entries could be transmitted across the network twice. The first transmission would come from the server holding the data to the server doing the chaining. The second transmission would come to the client from the server doing the chaining.

  With a referral, the client gets the data directly from the server that held the data, in one transmission.

• When a client knows where an entry is stored, the client can go directly to the server that has the data.

  Chaining hides details from the client. Not knowing where data came from previously, the client most likely won't go directly to the server holding the data.

Referrals have the following disadvantages:

• The client must be able to recognize referrals and know how to follow them.
• LDAPv2 clients don't recognize referrals, or they use an obsolete, non-standard method for recognizing them.
• Every eDirectory partition must be serviced by an LDAP server.

  Otherwise, referrals won't be sent for data in that partition.

Superior Referral---A referral to a server that holds data higher in the tree than the server being communicated with. See Configuring for Superior Referrals.

Superior referrals deal with requests concerning objects that are in a higher or contiguous non-eDirectory partition of a multi-vendor tree.

To enable an eDirectory server to participate in this type of tree, eDirectory holds the hierarchical data above it in a partition marked as "nonauthoritative." The objects in the non-authoritative area consist only of those entries needed to build the correct DN hierarchy. These entries are analogous to X.500 "Glue" entries.

eDirectory allows the placement of knowledge information in the form of LDAP referral data within the nonauthoritative area. This information is used to return referrals to the LDAP client.

When an LDAP operation takes place in a nonauthoritative area of the eDirectory tree, the LDAP server locates the correct reference data and returns a referral to the client.

Chaining---A server-based name-resolution protocol.

An LDAP client issues a request to an LDAP server, but the server can't find the target entry of the operation locally. Using the knowledge references that it has about partitions and other servers in the eDirectory tree, the LDAP server identifies another LDAP server that knows more about the DN. The first LDAP server then contacts the identified (second) LDAP server.

If necessary, this process continues until the first server contacts a server that holds a replica of the entry. eDirectory then handles all the details to complete the operation. Unaware of the server-to-server operations, the client assumes that the first server completed the request.

Through chaining, an LDAP server provides the following advantages:

• Hides all name-resolution details from the client
• Automatically takes care of reauthentication
• Acts as a proxy for the client
• Works seamlessly, even when some servers in the eDirectory tree don't support LDAP Services.

Chaining has the following disadvantages:

• The client might have to wait for some time without any feedback from the server, while the server chains to resolve the name.
• If the operation requires the LDAP server to send many entries across a WAN link, the operation might be very time consuming.
• If several servers are equally capable of progressing the operation, different servers might process two requests to operate on the same entry.

  eDirectory attempts to sort the servers by the cost associated with contacting them. For load balancing, eDirectory randomly selects among servers with the lowest cost.