Selected LDAPv3 Extensions

   

Numerous LDAPv3 extensions are in common use today. In this section we describe some of the controls, extended operations, and SASL mechanisms supported by Netscape Directory Server 6. We also tell how you can take advantage of these features using command-line utilities and C and Java SDKs. The command-line utilities are included with Netscape Directory Server, and the SDKs are available for download from the http://enterprise.netscape.com Web site. Both SDKs are also available as source code from http://www.mozilla.org.

Note

You may encounter other versions of the ldapsearch and ldapmodify command-line utilities. For example, the Solaris 8 operating system ships with versions of these utilities that are slightly different from the Netscape versions. If you find that the examples in this chapter don't behave as expected, make sure that you are using the Netscape version.


In the following descriptions, any Internet Drafts or RFC documents may be obtained from the IETF's Web site at http://www.ietf.org.

The ManageDSAIT Control

A client uses the ManageDSAIT control when it wants to directly manipulate referral information in the directory. Normally, if an entry contains a referral (in a ref attribute), the server returns to the client a referral instead of the entry containing the referral. However, if the client attaches the ManageDSAIT control to the operation, the server knows that the client wants to retrieve or manipulate any ref attributes directly. This control is useful for updating or retrieving referral information.

The ManageDSAIT control is identified by the OID 2.16.840.1.113730.3.4.2 and is defined in the Internet Draft Named Subordinate References in Lightweight Directory Access Protocol ( LDAP ) Directories (http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-namedref-05.txt). Servers that support this control will advertise this capability with the value 2.16.840.1.113730.3.4.2 in the supportedControl attribute of the root DSE.

To use the ManageDSAIT control with the ldapsearch and ldapmodify command-line utilities, add the “ M (uppercase) flag to the other command-line options.

To use the ManageDSAIT control with the C SDK, create an LDAPControl structure and set its ldctl_oid field to the OID for the control: 2.16.840.1.113730.3.4.2 . In the Java SDK, create an LDAPControl object, passing the OID to the object constructor function.

The Persistent Search Request and Entry Change Notification Response Controls

The Persistent Search Request control allows a client to receive notification when entries in the directory are changed. Normally a server responds to a search request by sending all the matching entries and a result message. When the Persistent Search Request control is included, the server does not send the result message. Instead, whenever the directory is updated, the server sends the updated entry to the client if the entry matches the search criteria. The persistent search normally does not terminate until the client abandons the operation, although the server is free to terminate the operation if it is short on resources.

For example, a client might be interested in knowing when the e-mail address of any person in the directory changes. To obtain this information, the client can issue a persistent search for all entries that contain an e-mail address. As new entries are added to the directory, or as entries have their e-mail addresses updated, the server sends these updated entries to the client, assuming that the client has access to the entries.

When constructing a Persistent Search Request control, the client can include several options to fine-tune the persistent search behavior:

  • The client may indicate that it is interested in entries only if they are the result of a particular LDAP update type or types. For example, a client can request that it be notified only when entries are added to or removed from the directory. The server will not notify the client of changes that arise from LDAP modify or modify DN operations in this example. By default, the server will notify the client about all changes to the directory.

  • The client may request that the server not return the initial set of matching entries. The client may want to suppress the initial set of entries if it is interested in learning only about changes to the directory and is uninterested in the current set of matching entries. By default, the server returns all entries that match the search request at the time it is received.

When the server returns entries that result from a persistent search to a client, it includes an Entry Change Notification Response control. This control contains additional information about the operation that caused the entry to be returned to the client:

  • The type of change made to the entry (add, delete, modify, or modify DN).

  • The previous DN of the entry (included only and useful only if the entry was renamed ).

  • The change number, a sequential number assigned to each change. The server may not send this information if it is not configured to support an LDAP changelog , a special database that tracks changes made to the directory.

These additional pieces of information can be useful to certain types of clients ”in particular, clients that maintain copies of all or part of a directory.

The Persistent Search Request control, which is sent from the client to the server, is identified by the OID 2.16.840.1.113730.3.4.3 . The Entry Change Notification Response control, which is sent from the server to the client, is identified by the OID 2.16.840.1.113730.3.4.7 . Servers that support these controls will advertise this capability with the values 2.16.840.1.113730.3.4.3 and 2.16.840.1.113730.3.4.7 in the supportedControl attribute of the root DSE.

To use the Persistent Search Request control with the ldapsearch utility provided with Netscape Directory Server 6 and later versions (earlier versions of the ldapsearch utility do not support this option), use the “ C option. The syntax is

 -C ps:changetype[:changesonly][:entrynotificationcontrols] 

where

  • changetype is one of add , delete , modify , rename , or any and indicates the types of changes that should be reported .

  • changesonly is true or false . true indicates that the client does not want to receive the initial set of matching entries; false (the default) indicates that the client wants to receive the initial set of matching entries.

  • entrynotificationcontrols is true or false . true indicates that the client wants to receive entry notification controls. false indicates that the client is not interested in receiving entry notification controls.

For example, the following ldapsearch command:

 ldapsearch h ldap.example.com b "dc=example, dc=com" s sub C ps:modify:true:true "(  mail=*)" 

performs a persistent search that returns modified entries that also contain an e-mail address ( mail attribute value). Entry Change Notification Response controls are included.

The C SDK has a convenience function, ldap_create_persistentsearch_ control() , for creating a Persistent Search Request control; and another function, ldap_parse_entrychange_control() , for parsing an Entry Change Notification Response control returned from the server.

The Java SDK has two classes ” LDAPPersistSearchControl and LDAPEntryChangeControl ”used for creating persistent search requests and parsing entry notification responses.

The Server-Side Sorting Request and Response Controls

The Server-Side Sorting Request control is used to request that the server sort the search results before sending them to the client. If the server has indexes that can satisfy the sort order requested by the client, it can sort the results much faster than the client can.

The Server-Side Sorting Request control carries one or more sets of an attribute type and a sort order ( ascending or descending) to use when sorting on that attribute. This control allows you, for example, to sort by surname first and then by given name , to produce a correctly sorted list of people from a white pages directory.

Sent from the server to the client after a Server-Side Sorting Request control is processed , the Server-Side Sorting Response control carries status and error codes from the sort operation.

The Server-Side Sorting Request control, which is sent from the client to the server, is identified by the OID 1.2.840.113556.1.4.473 . The Server-Side Sorting Response control, which is sent from the server to the client, is identified by the OID 1.2.840.113556.1.4.474 . Both controls are defined in RFC 2891, LDAP Control Extension for Server Side Sorting of Search Results (http://www.ietf.org/rfc/rfc2891.txt). This document is currently a proposed standard. Servers that support these controls will advertise this capability with the values 1.2.840.113556.1.4.473 and 1.2.840.113556.1.4.474 in the supportedControl attribute of the root DSE.

For server side sorting with the ldapsearch command-line utility, the “ S (uppercase) and “ x options must be used together. The “ S option is used to specify the sort attribute(s) and sort order, and the “ x flag is used to indicate that the server should perform the sorting. If you use the “ S option without the “ x option, the command-line utility will perform the sorting.

The argument to the “ S option is a single attribute type, optionally prefixed with a dash to indicate reverse sort order. You may use multiple “ S options if you want to sort on multiple attributes. The “ S options are processed in the order they appear on the command line.

For example, to search the directory for all people, sorting the results by surname first and then given name, use this syntax:

 ldapsearch -h host -s sub -b "dc=example,dc=com" -S sn -S givenname -x "(  objectclass=person)" 

To search the directory for all people, sorting in reverse order by the uid ( user ID) attribute, use this syntax:

 ldapsearch -h localhost -s sub -b "dc=example,dc=com" -S -uid -x "(objectclass=person)" 

The C SDK contains the convenience function ldap_create_sort_keylist() , which creates the sort ordering, and the ldap_create_sort_control() function, which creates the Server-Side Sorting Request control. Because the server returns a control to the client with additional information about the search request, the C SDK contains the ldap_parse_sort_control() function, which interprets the Server-Side Sorting Response control.

The Java SDK features several classes used to support Server-Side Sorting Request and Response controls. The LDAPSortKey class is used to specify the sort order, and the LDAPSortControl class is attached to the search operation to request server side sorting. The Java SDK makes the Server-Side Sorting Response control data available as an object of type LDAPSortControl .

The Virtual List View Request and Response Controls

The Virtual List View (VLV) Request control allows an LDAP client to request that the server send search results in small, manageable chunks . It also allows a client to move forward and backward through the results of a search operation. A GUI client that displays results in a window can use the VLV Request control to request that only enough entries to fill the window be sent, and it can page forward and backward through the result set. The Netscape Communicator version 4 address book fully supports VLV.

The VLV Request control, which is sent from the client to the server, is identified by the OID 2.16.840.1.113730.3.4.9 . The VLV Response control, which is sent from the server to the client, is identified by the OID 2.16.840.1.113730.3.4.10 . Both controls are defined in the Internet Draft LDAP Extensions for Scrolling View Browsing of Search Results (http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-09.txt). Servers that support these controls will advertise this capability with the values 2.16.840.1.113730.3.4.9 and 2.16.840.1.113730.3.4.10 in the supportedControl attribute of the root DSE.

To use VLV correctly with the command-line utilities, you must combine server side sorting (discussed in the previous section) with a VLV specification. The sorting information tells the server how to sort the result set, and the VLV specification tells the server which part of the result set to send.

There are two types of VLV specifications. The first allows you to specify an absolute position in the result set. For example, if the result set has 150 entries, you can specify that you want the server to send you entries 10 through 20. This feature is used most frequently by a GUI client that presents an interface that allows a user to page through a complete list of all entries. Imagine a directory with 10,000 user entries. Without VLV, the client would need to retrieve all 10,000 entries, sort them, and cache the sorted list. With VLV, the client can retrieve only as many entries as will fill its window, and it can retrieve the next set of entries as the user navigates forward and backward through the list.

To use this type of VLV specification with the Netscape command-line utility, you must specify a sort order and a VLV specification. For information about sort ordering, review the previous section, The Server-Side Sorting Request and Response Controls. The VLV specification takes the following form:

 before:after:index:content_count 

where

  • before is the number of entries before the target to include.

  • after is the number of entries after the target to include.

  • index is the offset of the target entry within the result set. An index of 1 always means the first entry. If index and content_count are equal, the last entry in the result set is selected.

  • content_count is the expected size of the result set. If (zero) is provided for content_count , the actual size of the result set, as computed by the server, is used. A client might use for content_count if it does not know the size of the result set. If the client specifies a nonzero content_count , the server uses this information, along with the other parameters, to return entries at a relative offset within the result set. The reason that content_count exists is so that client applications can implement interfaces that allow users to jump around a long list using a scroll bar. With an index of 33 and a count of 100, the application can jump 33 percent of the way into the list. The scroll bar can be mapped to the coordinate space of the result set, or vice versa.

Suppose that you want to display in a window the first five directory entries, sorted by surname. The ldapsearch command shown in Listing 3.2 illustrates how to do this.

Listing 3.2 Using VLV to Retrieve the First Five Entries, Sorted by Surname
 ldapsearch -D "uid=kvaughan,ou=people,dc=example,dc=com" -w bribery -s sub b "ou=People,  dc=example,dc=com" -S sn -x -G 0:4:1:0 "(objectclass=*)" sn version: 1 dn: uid=dakers, ou=People, dc=example,dc=com sn: Akers dn: uid=falbers, ou=People, dc=example,dc=com sn: Albers dn: uid=calexand, ou=People, dc=example,dc=com sn: Alexander dn: uid=ealexand, ou=People, dc=example,dc=com sn: Alexander dn: uid=rbannist, ou=People, dc=example,dc=com sn: Bannister index 1 content count 151 

The sort specification ( -S sn “x ) tells the server that you want to sort on the surname attribute and that the server should perform the sorting. The VLV specification ( -G 0:4:1:0 ) tells the server that you want to show 0 entries before and 4 entries after the target entry at index 1. Because the client does not know the size of the result set, content_count is .

Now suppose that the user presses the Page Down key and the client wants to scroll down through the list, positioning at the top the entry that was previously at the bottom of the list. By changing the VLV specification to “ G 0:4:5:0 , the client can request entries 5, 6, 7, 8, and 9, as shown in Listing 3.3.

Listing 3.3 Using VLV to Retrieve the Next Five Entries, with Overlap
 ldapsearch -D "uid=kvaughan,ou=people,dc=example,dc=com" -w bribery -s sub b "ou=People,  dc=example,dc=com" -S sn -x -G 0:4:5:0 "(objectclass=*)" sn version: 1 dn: uid=rbannist, ou=People, dc=example,dc=com sn: Bannister dn: uid=abarnes, ou=People, dc=example,dc=com sn: Barnes dn: uid=abergin, ou=People, dc=example,dc=com sn: Bergin dn: uid=jbourke, ou=People, dc=example,dc=com sn: Bourke dn: uid=jbrown, ou=People, dc=example,dc=com sn: Brown index 5 content count 151 

Notice that the entry uid=rbannist,ou=People,dc=example,dc=com becomes the top entry in the result set. Also note that each VLV search set also includes a final line of output: index x content count y . When the server processes a VLV Request control, it returns to the client, in another control, the index of the target entry and an indication of the total number of entries in the result set. The index is useful in an application that implements type-down addressing, in which the press of a key takes the user to the first entry in a list matching that key; for example, an address book application could jump to the first person whose surname starts with "s" when the user presses the S key. In this case, the client would issue a VLV specification of the second form ( before:after:search_value ), take note of the index reported by the server, and then issue a VLV specification of the first form ( before:after:index:content_count ).

The second type of VLV specification allows a client to jump to a particular matching entry and is most commonly used to implement type-down addressing. Specifically, it allows the client to jump to the first entry in the result set where the prefix of the sort value is equal to or greater than the value provided by the user. For example, if a GUI client presents a list of directory entries to a user, the user can type the letter "j" to jump to the first name that begins with the letter "j." The ldapsearch command shown in Listing 3.4 performs this VLV search. This VLV specification instructs the server to locate the first entry with a surname beginning with "j," returning 0 entries before and 4 entries after the target entry.

Listing 3.4 Using VLV to Retrieve the First Five Entries Where the Surname Begins with "j"
 ldapsearch -D "uid=kvaughan,ou=people,dc=example,dc=com" -w bribery -s sub b "ou=People,  dc=example,dc=com" -S sn -x -G 0:4:j "(objectclass=*)" sn version: 1 dn: uid=mjablons, ou=People, dc=example,dc=com sn: Jablonski dn: uid=bjablons, ou=People, dc=example,dc=com sn: Jablonski dn: uid=tjames, ou=People, dc=example,dc=com sn: James dn: uid=kjensen, ou=People, dc=example,dc=com sn: Jensen dn: uid=bjensen, ou=People, dc=example,dc=com sn: Jensen index 48 content count 151 

If reverse sorting is used, the server makes the target entry the first entry in the result set where the prefix of the sort value is equal to or less than the value provided by the user, as you would expect.

The content count returned by the server can be valuable to GUI clients that display a scroll bar. The content count can be used to appropriately position the scroll bar and size the scroll bar "thumb." The content count is not guaranteed to be accurate, however, because the server may not have sufficient resources to calculate the result set size. The server can return a content count of zero in this case, and clients should be prepared to deal with this.

Both the C and Java SDKs provide convenience functions that help you create VLV Request controls to send to the server and convenience functions that help you parse VLV Response controls returned to the client. The C SDK contains the ldap_create_ virtuallist_control() function, which helps you create the VLV Request control, and the ldap_parse_virtuallist_control() function to parse the VLV Response control sent back to the client. The Java SDK contains the LDAPVirtualListControl class, which can be used to create a VLV Request control, and the LDAPVirtualListResponse class, which can be used to parse the VLV Response control sent back to the client.

The Proxied Authorization Control

The Proxied Authorization control allows an LDAP client to impersonate another entry for a specific operation. For example, if a client has authenticated to a directory server as a particular user, it can use the Proxied Authorization control to perform an operation as if it had authenticated as a different user. To take advantage of this option, the client must initially authenticate as a user who has permission to use the Proxied Authorization control.

The Proxied Authorization control is most useful in trusted applications that need to perform operations on behalf of many different users. By using the Proxied Authorization control, an application can avoid having to reauthenticate for each operation. As a result, the application's performance improves because now it is unnecessary to send a bind operation each time a new authorization identity is required.

The Proxied Authorization control is identified by the OID 2.16.840.1.113730.3.4.18 and is defined in the Internet Draft LDAP Proxied Authorization Control (http://www.ietf.org/internet-drafts/draft-weltman-ldapv3-proxy-11.txt). Servers that support this control will advertise this capability with the value 2.16.840.1.113730.3.4.18 in the supportedControl attribute of the root DSE.

To use the Proxied Authorization control with the ldapsearch command-line utility, use the “ Y option to specify the DN of the entry to be impersonated. For example, to bind to the directory as the user jvedder and perform a search operation as the user bjablons , use the following command. Note that the actual proxy DN must be preceded by the string "dn:" :

 ldapsearch -D "uid=jvedder,ou=people,dc=example,dc=com" -w befitting Y "dn:uid=bjablons,  ou=people,dc=example,dc=com" -h localhost -s sub -b "dc=example,dc=com" "(uid=jvedder)"  userpassword 

Note that the user jvedder must have appropriate permission within the subtree dc=example,dc=com to use the Proxied Authorization control. If this permission has not been granted, an LDAP error 50, "insufficient access rights," will be returned to the client. For Netscape Directory Server, this right is called the proxy right . For more information on granting proxy rights, see the Netscape Directory Server Administrator's Guide .

Both the C and Java SDKs provide convenience functions that help you construct Proxied Authorization controls. The C SDK contains a convenience function, ldap_create_proxyauth_control() , which assists you in setting up the Proxied Authorization control. The Java SDK includes the LDAPProxiedAuthControl class, which can be added to the search constraints of any LDAP operation.

Password Expiration Controls

Netscape Directory Server has a password policy feature that allows you to enforce restrictions on passwords, including maximum password age and password quality. Passwords can be set to expire at a particular point in time. After a password expires , the only LDAP operation permitted is to set a new password. The password policy feature uses LDAP controls to send information about impending password expiration and expired passwords to the client.

Unlike other controls, these LDAP controls are sent from the server to the client to inform it that a password is about to expire and how far in the future the expiration will occur, or that a password has expired. Your application should check for these controls and inform the user about password expiration.

The Password Expiring control is sent from the server to the client to indicate that a password is about to expire. It is identified by the OID 2.16.840.1.113730.3.4.5 . The Password Expired control is sent from the server to the client to indicate that a password has expired. It is identified by the OID 2.16.840.1.113730.3.4.4 . Both controls are defined in the Internet Draft Password Policy for LDAP Directories (http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-07.txt). Servers that support these controls will advertise this capability with the values 2.16.840.1.113730.3.4.5 and 2.16.840.1.113730.3.4.4 in the supportedControl attribute of the root DSE.

If a Password Expiring control is received from the server, the Netscape LDAP command-line tools display a message like this:

 Warning ! Your password will expire after 30 days. 

You do not need to specify any command-line options to enable recognition of the Password Expiring and Password Expired controls.

The C and Java SDKs both allow you to recognize when Password Expiring or Password Expired controls are returned with a bind result. With the C SDK, applications can use the ldap_parse_result() call and check for the presence of either of these two controls. If the Password Expiring control is present, applications can examine the ldctl_value field, which contains the number of seconds until the password expires.

In the Java SDK, applications should use the getResponseControls() method to get all the controls returned from the server and check for the presence of either the Password Expiring or the Password Expired control. If an LDAPPasswordExpiringControl object is present, the getSecondsToExpiration() method can be called to determine the number of seconds until the password expires.

Bulk Import Extended Operations

The bulk import extended operations allow a client to rapidly import a series of entries into the directory, using the LDAP protocol. With previous versions of Netscape Directory Server, if you needed to replace the contents of the directory, you had to log in to the server machine and use the ldif2db utility. Now, with the bulk import extended operations, you can use an LDAP client to replace the contents of the directory while taking advantage of the high-speed import capabilities of the server.

There are two extended operations: Bulk Import Start and Bulk Import Finished. The Bulk Import Start extended operation carries a DN that denotes the top of the subtree that the client wants to replace. If the server does not hold the given subtree, it returns an error to the client. Otherwise, the server prepares to receive a bulk update. The client then sends a series of LDAP add operations and finishes the bulk update with the Bulk Import Finished extended operation.

The bulk import capabilities are useful in an environment where the directory contents are replaced periodically ”for example, when directory data is periodically regenerated from an external data source like a relational database. A bulk update allows rapid replacement of the server contents, through use of a remote LDAP client.

Note

When Netscape Directory Server is servicing a bulk update operation, the database's contents are taken offline and are not available for searching. Clients that attempt to search the directory are returned an error.


The Bulk Import Start extended operation is identified by the OID 2.16.840.1.113730.3.5.7 . The Bulk Import Finished extended operation is identified by the OID 2.16.840.1.113730.3.5.8 . Neither of these extended operations is currently defined in a standards document. Servers that support these operations will advertise this capability with the values 2.16.840.1.113730.3.5.7 and 2.16.840.1.113730.3.5.8 in the supportedExtension attribute of the root DSE.

To perform a bulk import using the ldapmodify command-line utility, use the “ B option to specify the subtree that will be bulk-loaded. Otherwise the command line is the same as if you were adding the entries to an empty directory. For example, if you have an LDAP Data Interchange Format (LDIF) file containing data for the dc=example,dc=com subtree in the file example.ldif , you can perform a bulk import with the following command:

 ldapmodify D "cn=Directory Manager" w password a B "dc=example, dc=com" < example.ldif 

The “ B option causes the ldapmodify command to bracket the updates with Bulk Update Start and Bulk Update Finished extended operations, specifying that the subtree dc=example,dc=com is to be replaced. The “ a option is required if your LDIF file consists of LDAP entry data instead of LDIF update statements (update statements contain changetype: add immediately after the entry DN). Netscape Directory Server supports only bulk add operations. It does not support bulk application of modify, delete, or rename operations.

Note

Netscape Directory Server processes a bulk update by replacing the entire content of the directory database containing the entry named by the “ B option. It is not possible to replace only a portion of a directory database. For example, if the entire dc=example,dc=com subtree is held in a single database, it's not possible to bulk-load only a subtree like ou=people,dc=example,dc=com . Even if you supply ou=people,dc=example,dc=com for the “ B option, the entire content of the database will be replaced with the data you provide.


Neither the C nor the Java SDK provides any specific support for the bulk import extended operations at this time, although the basic, low-level extended operation facilities included in the SDKs can be used to create the needed extended operations.

The EXTERNAL SASL Mechanism

The EXTERNAL SASL mechanism allows a client to reuse authentication credentials already established by another protocol. For example, if the LDAP connection has been established by LDAP-over-SSL or LDAP-over-TLS, the server may have already established the client's identity using certificate-based client authentication. The SASL EXTERNAL mechanism allows a client to request that those credentials be used.

The EXTERNAL SASL mechanism is identified by the string "EXTERNAL" and is defined in RFC 2222, Simple Authentication and Security Layer ( SASL ) (http://www.ietf.org/rfc/rfc2222.txt). Servers that support this SASL mechanism will advertise this capability with the value EXTERNAL in the supportedSASLMechanisms attribute of the root DSE.

The command-line utilities fully support SSL client authentication, which uses the EXTERNAL SASL mechanism. SSL client authentication requires use of the following command-line options:

  • -Z. The instruction telling the utility to use SSL.

  • -P <pathname> . The path to the SSL certificate database.

  • -N <certname> . The name of the certificate to use for client authentication.

  • -W . The SSL key password.

For example, if the SSL certificate database is in the file /home/bjensen/.netscape/cert7.db , the certificate name is bjensencertname , and the password protecting the key database is "secret," an ldapsearch command using SSL client authentication will look like this:

 ldapsearch -h hostname -p 636 -b "dc=example,dc=com" N "bjensenscertname" Z -P /home/  bjensen/.netscape/cert7.db -W secret "(uid=gjensen)" 
SDK Support

To use SSL client authentication and the SASL EXTERNAL bind method with the C SDK, use the ldapssl_clientauth_init() and ldapssl_init() functions to initialize the SSL library and an LDAP session. Then use the ldap_sasl_bind() or ldap_ sasl_bind_s() functions to authenticate to the directory.

With the Java SDK, you use the LDAPSSLSocketFactory class, along with a class that you provide that supports SSL. You then use one of the LDAPConnection.authenticate() methods that support SASL authentication, supplying EXTERNAL as the mechanism name. For more information, consult the Java SDK documentation.

The DIGEST-MD5 SASL Mechanism

The DIGEST-MD5 SASL mechanism authenticates a client to a directory server. This authentication method is secure from eavesdroppers because it does not send the bind password in the clear over the network. All LDAPv3-compliant servers must support this authentication method.

The DIGEST-MD5 SASL mechanism is identified by the string "DIGEST-MD5" and is defined in RFC 2831, Using Digest Authentication as a SASL Mechanism (http://www.ietf.org/rfc/rfc2831.txt). Servers that support this SASL mechanism will advertise this capability with the value DIGEST-MD5 in the supportedSASLMechanisms attribute of the root DSE. At this time, support for the DIGEST-MD5 SASL mechanism is not available in either the command-line utilities or the LDAP SDKs.

   


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

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