The LDAP Server for NDS

     

LDAP is an Internet communications protocol standard that lets client applications access directory information. It is based on the X.500 Directory Access Protocol (DAP) but is much less complex (thus "Lightweight") than a traditional DAP client and can be used with any other directory service that follows the X.500 standard.

To provide LDAP connectivity to NDS/eDirectory, Novell has been shipping LDAP Services for Novell NDS since NetWare 4.10. This server application lets LDAP clients access information stored in NDS/eDirectory. The current version is LDAP v3 compliant.

NOTE

LDAP servers are specific to the back-end database they support. For instance, you cannot use the Novell LDAP server for Windows (included with eDirectory for Windows) to access Active Directory, even when both are running on the same Windows server. The LDAP server basically serves as the translator between the (Internet standard) LDAP client and the (proprietary) directory service database; this is very similar to the concept of using Open Database Connectivity ( ODBC ) drivers to access databases.

In Novell documentation, the LDAP server for NDS /eDirectory is sometimes referred to as the LDAP agent for eDirectory because it acts on your behalf to access information from eDirectory.

NOTE

The LDAP server modules shipped with eDirectory are NLDAP.NLM for NetWare; nldap.dlm for Windows 2000/NT; libnldap.so for Linux, Solaris, and AIX systems; and libnldap.sl for HP -UX systems. Except on the NetWare platform, the LDAP server for eDirectory runs as a task under DHost. Therefore, you will not find a process called nldap.dlm in Task Manager on Windows servers, for instance. (DHost is discussed earlier in this chapter, in the section "DHost.")

The following LDAP tools are included with LDAP Services to help you manage the LDAP server:

NOTE

On Unix/Linux, the LDAP tools are stored in /usr/ldaptools/bin (except ice , which is stored in /usr/bin ). On Windows all but ndsindex are found in the \Novell\ConsoleOne\1.2\bin directory ( ndsindex is located in \Novell\NDS instead). On NetWare, all but ndsindex are in the SYS:PUBLIC\mgmt\ConsoleOne\1.2\bin directory; ndsindex is implemented as NINDEX.NLM and is located in SYS:SYSTEM .

• ice ” Imports entries from a file to an LDAP directory, modifies the entries in a directory from a file, exports the entries to a file, and adds attribute and class definitions from a file.

• ldapadd ” Adds new entries to an LDAP directory.

• ldapdelete ” Deletes entries from an LDAP directory server. The ldapdelete tool opens a connection to an LDAP server and binds and deletes one or more entries.

• ldapmodify ” Opens a connection to an LDAP server and binds and modifies or adds entries.

• ldapmodrdn ” Modifies the RDNs of entries in an LDAP directory server. Opens a connection to an LDAP server and binds and modifies the RDNs of entries.

• ldapsearch ” Searches entries in an LDAP directory server. Opens a connection to an LDAP server and binds and performs a search, using the specified filter. The filter should conform to the string representation for LDAP filters, as defined in RFC 2254.

• ndsindex ” Creates, lists, suspends, resumes, or deletes indexes for NDS servers. This tool is useful in performance tuning (see Chapter 16).

Table 2.8 summarizes the availability of features in various releases of the LDAP server for NDS. The various features are discussed in the sections that follow.

Table 2.8. LDAP Server for NDS Feature Comparison

LDAP FEATURE	EDIRECTORY 8.7	EDIRECTORY 8.6	EDIRECTORY 8.5	EDIRECTORY 8	NDS 8	NDS 7
Support for LDAP v2	x	x	x	x	x	x
Support for LDAP v3	x	x	x	x	x
Authentication (anonymous, clear-text, and Secure Sockets Layer [SSL]/Transport Layer Security [TLS])	x	x	x	x	x	x
Mutual authentication	x	x	x
Simple Authentication and Security Layer (SASL) authentication	x	x (usingX.509 certificates)
Digest-MD5 bind	x
NMAS_LOGIN bind	x
Configuration of port for secure bind	x	x	x
Enforcement of NDS-based connection management policies (for example, concurrent connections and time restrictions)	x	x	x
Enforcement of NDS-based password restrictions (for example, password length, grace logins, expiration, and uniqueness)	x	x	x
Entry management (search, modify, compare, rename, add, delete)	x	x	x	x	x	x
User self-password management	x	x	x	x	x	Must be changed by administrator
NDS partition and replica management	x	x	x
Setting of (NDS) indexes for faster searching	x	x	x
LDAP controls (query root DSE for supported controls)	x	x	x	x	x
Support for LDAP extensions	x	x	x	x
Referrals and traversals	x	x	x	x	x	With restrictions
Readable root DSE (to determine supported features)	x	x	x	x	x	x
Reading and writing of schema (that is, writable root DSE)	x	x	x	x	Read only
Modification of existing schema definitions	x	x	x
Auxiliary class support	x	x	x	x	x
Valid LDAP names requiring no mapping	x	x	x	x
Generated LDAP name for each NDS name that is not mapped or that is not valid	x	x	x
Access to NDS compound syntaxes	x	x	x	Selected
LDAP and NDS operational attributes	x	x	x
Support for NDS dynamic groups	x	x
Persistent search	x	x
Refreshing of LDAP server from LDAP	x	x	x	Must use NCP calls
Superior referrals	x
Referrals for non-search operations	x
TLS (SSL) encryption	x	x	x	x	x
Start/stop TLS	x
Extensible match search filters	x
NDS events notification	x

NOTE

LDAP server features are server-centric. Therefore, for an application to use a particular LDAP feature, the application must attach to an LDAP server running a version of NDS or eDirectory that supports the feature. For example, the client cannot bind to an LDAP server for eDirectory 8.6 to receive DS event notification.

LDAP and NDS/eDirectory Terminology

When combining two technologies, there is often conflict between the meanings of the terms used. This is true in the case of integrating LDAP with NDS/eDirectory. In LDAP documentation, an entry consistently means a record in the directory database. On the other hand, in DS documentation, such a record is fairly consistently called an object . Because the term object becomes ambiguous when describing object-oriented programming languages, DS developer documentation is beginning to use the LDAP term ” entries ”but not completely. Some functions, attribute names, and class names still use the term object . Novell product documentation for DS utilities and applications continues to use the DS term, objects .

In most DS documentation, attributes refers to the fields of a record. LDAP and X.500 conform to this standard. However, a lot of LDAP documentation also uses the word attribute to refer to the attribute's value; NDS/eDirectory programming documentation, for example, uses attribute . However, Novell product documentation for NDS/eDirectory utilities and applications uses the term properties to describe fields in a record.

In DS, a partition is a branch of the DS tree with only one parent that is hosted on a server. In LDAP parlance, this is called a naming context . Figure 2.20 illustrates a simple hierarchical tree with four naming contexts:

• O=Universal_Export

• OU=Customer_Service , O=Universal_Export

• OU=Gadgets , O=Universal_Export

• OU=M , OU=Gadgets , O=Universal_Export

Figure 2.20. LDAP naming context example.

Just as with DS partitions, LDAP's naming context is named by the DN of the root container. The exception is the [Root] naming context. LDAP's root object is called a DSA -specific Entry (DSE) , or root DSE , and is not part of any naming context. Each LDAP server can have different attribute values in the root DSE. (Directory system agent [DSA] is an X.500 term for the directory server.)

REAL WORLD: Root DSE Explained

Root DSE is a pseudo, unnamed, entry at the root of the directory tree. Because it is not a named entry in the tree, an LDAP server does not return root DSE to the client as part of any normal search operation.

Root DSE holds information that is specific to the server that you are connected to. The following is some of the information you can obtain by querying root DSE:

• namingContexts ” Naming contexts held in the server.

• subschemaSubentry ” Subschema entries (or subentries) ”classes and attributes ”known by this server.

• altServer ” Alternative servers in case this one is later unavailable.

• supportedExtension ” List of supported extended operations.

• supportedControl ” List of supported controls.

• supportedSASLMechanisms ” List of supported SASL security features.

• supportedLDAPVersion ” LDAP versions implemented by the server.

Additional information about root DSE and schema attribute definitions can be found in RFCs 2251 and 2252, respectively.

LDAP and eDirectory Integration

The LDAP server included with eDirectory supports the following features:

• Authentication support. Standard LDAP authentication methods include anonymous binds, clear-text binds, SSL and SASL (RFC 2222) binds. From DS's perspective, these LDAP authentication methods mean the following:

  • An anonymous bind is an unauthenticated connection with public access to the directory.

  • A clear-text bind is an authentication over an unencrypted channel. The client sends a username and a clear-text password. The LDAP server must be configured to accept unencrypted passwords.

  • An SSL bind is an authentication over an encrypted channel (secured by an SSL certificate). All data, including the password, is encrypted. DS clients have access to SSL binds only through LDAP.

• Adding, modifying, and deleting of entries and attributes in the directory.

• Reading, sorting, and searching of entries and attributes in the directory.

• Reading, adding, and deleting of schema definitions (object classes and attributes). The LDAP server for eDirectory 8.5 and higher supports the modification of class definitions and attribute definitions as long as the modifications increase functionality rather than restrict it.

LDAP Extensions and Controls

The standard LDAP protocol specification does not yet support access to replication, partition, and synchronization services. However, these services are available through (Novell-specific) LDAP extensions that are available for eDirectory 8.5 and higher.

NOTE

LDAP v3 provides a method for extending its functionality through LDAP controls and extensions. For example, RFC 2891 defines two LDAP v3 controls for server-side sorting of results; this instructs the LDAP server to sort the search results before sending them back to the client. An LDAP control is a command sequence that contains a predefined object ID (OID) that the LDAP server understands as an extension, and instructions specific for the requested action.

Keep in mind that some LDAP controls and extensions are vendor specific, and controls that are common among some vendors may not be implemented alike.

Tables 2.9, 2.10, and 2.11 show controls and extensions supported by eDirectory 8.5 and higher that allow LDAP clients to perform the following request:

• Naming contexts: split, join, return number of entries, abort operation

• Replicas: add, remove, change type, enumerate number of replicas on a server, retrieve replica information

• Replica synchronization: to a specified server, to all replicas, at a specified time

• Synchronize schemas

• Get effective NDS rights for attributes

• Get DN of logged in caller

• Restart the LDAP server

• Change Simple passwords via LDAP

• Monitor events (some extensions require eDirectory 8.7 and higher)

Table 2.9. LDAP Extensions Supported by eDirectory

OID	EXTENSION NAME
1.3.6.1.4.1.1466.20037	startTLS (eDirectory 8.7 and higher)
2.16.840.1.113719.1.27.100.1	ndsToLdapResponse
2.16.840.1.113719.1.27.100.2	ndsToLdapRequest
2.16.840.1.113719.1.27.100.3	createNamingContextRequest (also known as SplitPartitionRequest )
2.16.840.1.113719.1.27.100.4	createNamingContextResponse (also known as SplitPartitionResponse )
2.16.840.1.113719.1.27.100.5	mergeNamingContextRequest (also known as MergePartitionRequest )
2.16.840.1.113719.1.27.100.6	mergeNamingContextResponse (also known as MergePartitionResponse )
2.16.840.1.113719.1.27.100.7	addReplicaRequest
2.16.840.1.113719.1.27.100.8	addReplicaResponse
2.16.840.1.113719.1.27.100.9	refreshLDAPServerRequest
2.16.840.1.113719.1.27.100.10	refreshLDAPServerResponse
2.16.840.1.113719.1.27.100.11	removeReplicaRequest
2.16.840.1.113719.1.27.100.12	removeReplicaResponse
2.16.840.1.113719.1.27.100.13	namingContextEntryCountRequest (also known as PatitionEntryCountRequest )
2.16.840.1.113719.1.27.100.14	namingContextEntryCountResponse (also known as PartitionEntryCountResponse )
2.16.840.1.113719.1.27.100.15	changeReplicaTypeRequest
2.16.840.1.113719.1.27.100.16	changeReplicaTypeResponse
2.16.840.1.113719.1.27.100.17	getReplicaInfoRequest
2.16.840.1.113719.1.27.100.18	getReplicaInfoResponse
2.16.840.1.113719.1.27.100.19	listReplicaRequest
2.16.840.1.113719.1.27.100.20	listReplicaResponse
2.16.840.1.113719.1.27.100.21	receiveAllUpdatesRequest
2.16.840.1.113719.1.27.100.22	receiveAllUpdatesResponse
2.16.840.1.113719.1.27.100.23	sendAllUpdatesRequest
2.16.840.1.113719.1.27.100.24	sendAllUpdatesResponse
2.16.840.1.113719.1.27.100.25	requestNamingContextSyncRequest (also known as RequestPartitionSyncRequest )
2.16.840.1.113719.1.27.100.26	requestNamingContextSyncResponse (also known as RequestPartitionSyncRequest )
2.16.840.1.113719.1.27.100.27	requestSchemaSyncRequest
2.16.840.1.113719.1.27.100.28	requestSchemaSyncResponse
2.16.840.1.113719.1.27.100.29	abortNamingContextOperationRequest (also known as AbortPartitionOperationRequest )
2.16.840.1.113719.1.27.100.30	abortNamingContextOperationResponse (also known as AbortPartitionOperationRequest )
2.16.840.1.113719.1.27.100.31	getContextIdentityNameRequest (also known as GetBindDNRequest )
2.16.840.1.113719.1.27.100.32	getContextIdentityNameResponse (also known as GetBindDNResponse )
2.16.840.1.113719.1.27.100.33	getEffectivePrivilegesRequest
2.16.840.1.113719.1.27.100.34	getEffectivePrivilegesResponse
2.16.840.1.113719.1.27.100.35	setReplicationFilterRequest
2.16.840.1.113719.1.27.100.36	setReplicationFilterResponse
2.16.840.1.113719.1.27.100.37	getReplicationFilterRequest
2.16.840.1.113719.1.27.100.38	getReplicationFilterResponse
2.16.840.1.113719.1.27.100.39	CreateOrphanPartitionRequest
2.16.840.1.113719.1.27.100.40	CreateOrphanPartitionResponse
2.16.840.1.113719.1.27.100.41	RemoveOrphanPartitionRequest (also known as splitOrphanPartitionRequest )
2.16.840.1.113719.1.27.100.42	RemoveOrphanPartitionResponse (also known as splitOrphanPartitionResponse )
2.16.840.1.113719.1.27.100.43	triggerBackLinkerRequest
2.16.840.1.113719.1.27.100.44	triggerBackLinkerResponse
2.16.840.1.113719.1.27.100.45	triggerDRLProcessRequest
2.16.840.1.113719.1.27.100.46	triggerDRLProcessResponse
2.16.840.1.113719.1.27.100.47	triggerJanitorRequest
2.16.840.1.113719.1.27.100.48	triggerJanitorResponse
2.16.840.1.113719.1.27.100.49	triggerLimberRequest
2.16.840.1.113719.1.27.100.50	triggerLimberResponse
2.16.840.1.113719.1.27.100.51	triggerSkulkerRequest
2.16.840.1.113719.1.27.100.52	triggerSkulkerResponse
2.16.840.1.113719.1.27.100.53	triggerSchemaSyncRequest
2.16.840.1.113719.1.27.100.54	triggerSchemaSyncResponse
2.16.840.1.113719.1.27.100.55	triggerPartitionPurgeRequest
2.16.840.1.113719.1.27.100.56	triggerPartitionPurgeResponse
2.16.840.1.113719.1.27.100.79	MonitorEventRequest (eDirectory 8.7 and higher)
2.16.840.1.113719.1.27.100.80	MonitorEventResponse (eDirectory 8.7 and higher)
2.16.840.1.113719.1.27.100.81	FilteredMonitorEventRequest
2.16.840.1.113719.1.27.100.84	Undocumented (eDirectory 8.7 and higher)
2.16.840.1.113719. 1.27.103.1	CreateGroupingRequest
2.16.840.1.113719.1.27.103.2	EndGroupingRequest
2.16.840.1.113719.1.39.42.100.1 through 2.16.840.1.113719.1.39.42.100.12	Undocumented (eDirectory 8.7 and higher)
2.16.840.1.113719.1.39.42.100.13 through 2.16.840.1.113719.1.39.42.100.22	Undocumented (eDirectory 8.7.3 and higher)

Table 2.10 lists the extensions used by the Novell Import Convert Export (ICE) utility. They are not general extensions designed for developer use but are designed to support the LDAP Bulk Update Replication Protocol (LBURP).

Table 2.10. ICE-Specific LDAP Extensions for eDirectory 8.5 and Higher

OID	EXTENSION NAME
2.16.840.1.113719.1.142.100.1	StartFramedProtocolRequest (also known as startLburpRequest )
2.16.840.1.113719.1.142.100.2	StartFramedProtocolResponse (also known as startLburpResponse )
2.16.840.1.113719.1.142.100.4	EndFramedProtocolRequest (also known as endLburpRequest )
2.16.840.1.113719.1.142.100.5	EndFramedProtocolResponse (also known as endLburpResponse )
2.16.840.1.113719.1.142.100.6	LburpOperationRequest (also known as lburpOperation )
2.16.840.1.113719.1.142.100.7	LburpOperationResponse (also known as lburpOperationDone )

Table 2.11. DAP Controls Supported by eDirectory

OID	DESCRIPTION
1.2.840.113556.1.4.473	Server-side sort control request. Returns results from a search operation in sorted order. This can be used to offload processing from the client or if you cannot sort the results on the client. (NDS 8 and higher.)
1.2.840.113556.1.4.474	Server-side sort control response. (NDS 8 and higher.)
2.16.840.1.113719.1.27.101.5	NMAS simple password request.
2.16.840.1.113719.1.27.101.6	Create forward reference request. (When an entry is going to be created before its parent exists, a placeholder called a forward reference is created for the entry's parent to allow the entry to be successfully created. If a later operation creates the parent, the forward reference is changed into a normal entry.)
2.16.840.1.113719.1.27.103.7	Server-side grouping control that provides a general mechanism for grouping related LDAP operations. Grouping of operations can be used to support replication, proxies, and high-level operations such as transactions. This is currently an Internet Draft: www.ietf.org/internet-drafts/draft-zeilenga-ldap-grouping-06.txt. (eDirectory 8.7 and higher.)
2.16.840.1.113730.3.4.2	ManageDsaIT control request. This causes directory-specific entries, regardless of type, to be treated as normal entries. See RFC 3296 for details. (eDirectory 8.7 and higher.)
2.16.840.1.113730.3.4.3	Persistent search request. Performs continuous search operations. (eDirectory 8.6 and higher.)
2.16.840.1.113730.3.4.7	Entry change notification. It is a response to a persistent search request. (eDirectory 8.7 and higher.)

Persistent search is an LDAP v3 extension that enables applications to maintain a connection to an LDAP-compliant directory even after that directory has returned the results of a search request. For example, say that an LDAP application searches for all entries in the tree for which the CN attribute has a value beginning with the letter A , and 500 hits are expected. However, this application supports increments of only 10 search results. Using persistent search, this application could receive search results for this request in increments of 10 CN attributes without having to establish a new connection to the directory for each increment. Otherwise , this application would have to establish a new connection and issue a new search request for each increment.

NOTE

Two LDAP controls, 2.16.840.1.113730.3.4.9 (Virtual List View [VLV] request) and 2.16.840.1.113730.3.4.10 (VLV response), working in conjunction with the server-side sort control to provide a dynamic view of a scrolling list, are not fully supported by eDirectory. Refer to TID #10084069 for details on the limitations.

If you are unsure what extensions and controls are supported by the version of the LDAP server for eDirectory that you have, you can query its root DSE by using an LDAP search tool. For example, this is the syntax for using ldapsearch :

 ldapsearch -h  host  -b "" -s base -D  cn=admin,o=org  -w  password  objectclass=*  supportedcontrol supportedextension 

The following is an example of some of the output from this command, showing just the supported extensions and controls, from a Windows 2000 server running eDirectory 8.7.3:

 dn: supportedExtension: 2.16.840.1.113719.1.142.100.1 supportedExtension: 2.16.840.1.113719.1.142.100.2 supportedExtension: 2.16.840.1.113719.1.142.100.4 supportedExtension: 2.16.840.1.113719.1.142.100.5 supportedExtension: 2.16.840.1.113719.1.142.100.6 supportedExtension: 2.16.840.1.113719.1.142.100.7 supportedExtension: 2.16.840.1.113719.1.27.100.1 supportedExtension: 2.16.840.1.113719.1.27.100.2 supportedExtension: 2.16.840.1.113719.1.27.100.3 supportedExtension: 2.16.840.1.113719.1.27.100.4 supportedExtension: 2.16.840.1.113719.1.27.100.5 supportedExtension: 2.16.840.1.113719.1.27.100.6 supportedExtension: 2.16.840.1.113719.1.27.100.7 supportedExtension: 2.16.840.1.113719.1.27.100.8 supportedExtension: 2.16.840.1.113719.1.27.100.11 supportedExtension: 2.16.840.1.113719.1.27.100.12 supportedExtension: 2.16.840.1.113719.1.27.100.13 supportedExtension: 2.16.840.1.113719.1.27.100.14 supportedExtension: 2.16.840.1.113719.1.27.100.15 supportedExtension: 2.16.840.1.113719.1.27.100.16 supportedExtension: 2.16.840.1.113719.1.27.100.17 supportedExtension: 2.16.840.1.113719.1.27.100.18 supportedExtension: 2.16.840.1.113719.1.27.100.19 supportedExtension: 2.16.840.1.113719.1.27.100.20 supportedExtension: 2.16.840.1.113719.1.27.100.21 supportedExtension: 2.16.840.1.113719.1.27.100.22 supportedExtension: 2.16.840.1.113719.1.27.100.23 supportedExtension: 2.16.840.1.113719.1.27.100.24 supportedExtension: 2.16.840.1.113719.1.27.100.25 supportedExtension: 2.16.840.1.113719.1.27.100.26 supportedExtension: 2.16.840.1.113719.1.27.100.27 supportedExtension: 2.16.840.1.113719.1.27.100.28 supportedExtension: 2.16.840.1.113719.1.27.100.29 supportedExtension: 2.16.840.1.113719.1.27.100.30 supportedExtension: 2.16.840.1.113719.1.27.100.31 supportedExtension: 2.16.840.1.113719.1.27.100.32 supportedExtension: 2.16.840.1.113719.1.27.100.33 supportedExtension: 2.16.840.1.113719.1.27.100.34 supportedExtension: 2.16.840.1.113719.1.27.100.35 supportedExtension: 2.16.840.1.113719.1.27.100.36 supportedExtension: 2.16.840.1.113719.1.27.100.37 supportedExtension: 2.16.840.1.113719.1.27.100.38 supportedExtension: 2.16.840.1.113719.1.27.100.39 supportedExtension: 2.16.840.1.113719.1.27.100.40 supportedExtension: 2.16.840.1.113719.1.27.100.41 supportedExtension: 2.16.840.1.113719.1.27.100.42 supportedExtension: 2.16.840.1.113719.1.39.42.100.1 supportedExtension: 2.16.840.1.113719.1.39.42.100.2 supportedExtension: 2.16.840.1.113719.1.39.42.100.3 supportedExtension: 2.16.840.1.113719.1.39.42.100.4 supportedExtension: 2.16.840.1.113719.1.39.42.100.5 supportedExtension: 2.16.840.1.113719.1.39.42.100.6 supportedExtension: 2.16.840.1.113719.1.39.42.100.7 supportedExtension: 2.16.840.1.113719.1.39.42.100.8 supportedExtension: 2.16.840.1.113719.1.39.42.100.9 supportedExtension: 2.16.840.1.113719.1.39.42.100.10 supportedExtension: 2.16.840.1.113719.1.39.42.100.11 supportedExtension: 2.16.840.1.113719.1.39.42.100.12 supportedExtension: 2.16.840.1.113719.1.39.42.100.13 supportedExtension: 2.16.840.1.113719.1.39.42.100.14 supportedExtension: 2.16.840.1.113719.1.39.42.100.15 supportedExtension: 2.16.840.1.113719.1.39.42.100.16 supportedExtension: 2.16.840.1.113719.1.39.42.100.17 supportedExtension: 2.16.840.1.113719.1.39.42.100.18 supportedExtension: 2.16.840.1.113719.1.39.42.100.19 supportedExtension: 2.16.840.1.113719.1.39.42.100.20 supportedExtension: 2.16.840.1.113719.1.39.42.100.21 supportedExtension: 2.16.840.1.113719.1.39.42.100.22 supportedExtension: 2.16.840.1.113719.1.27.100.9 supportedExtension: 2.16.840.1.113719.1.27.100.10 supportedExtension: 2.16.840.1.113719.1.27.100.43 supportedExtension: 2.16.840.1.113719.1.27.100.44 supportedExtension: 2.16.840.1.113719.1.27.100.45 supportedExtension: 2.16.840.1.113719.1.27.100.46 supportedExtension: 2.16.840.1.113719.1.27.100.47 supportedExtension: 2.16.840.1.113719.1.27.100.48 supportedExtension: 2.16.840.1.113719.1.27.100.49 supportedExtension: 2.16.840.1.113719.1.27.100.50 supportedExtension: 2.16.840.1.113719.1.27.100.51 supportedExtension: 2.16.840.1.113719.1.27.100.52 supportedExtension: 2.16.840.1.113719.1.27.100.53 supportedExtension: 2.16.840.1.113719.1.27.100.54 supportedExtension: 2.16.840.1.113719.1.27.100.55 supportedExtension: 2.16.840.1.113719.1.27.100.56 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 2.16.840.1.113719.1.27.100.79 supportedExtension: 2.16.840.1.113719.1.27.100.80 supportedExtension: 2.16.840.1.113719.1.27.100.84 supportedExtension: 2.16.840.1.113719.1.27.100.80 supportedExtension: 2.16.840.1.113719.1.27.103.1 supportedExtension: 2.16.840.1.113719.1.27.103.2 supportedControl: 2.16.840.1.113719.1.27.101.6 supportedControl: 2.16.840.1.113719.1.27.101.5 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.7 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113719.1.27.103.7 

The LDAP Server object has a multivalued attribute called extensionInfo , which contains the list of supported controls and extensions supported by that server, as shown in Figure 2.21. To access this screen, you select the LDAP Server object in ConsoleOne and then right-click and select the Properties option from the context menu. Next , you select the Other tab, open the extensionInfo listing, and click the Extended Editor button, which is denoted by an ellipsis ( ).

Figure 2.21. The extensionInfo attribute of the LDAP Server object.

You can deselect an extension from being supported by the server by deleting the attribute value that corresponds to the extension in question. However, because the attribute value is an octet string ( SYN_OCTET_STRING ), it could be cumbersome to put it back at a later time. (Note that this is not supported by Novell.) Alternatively, you can edit the value and change the starting E to a D (or basically anything other than E ). This deselects the extension. Then you restart the LDAP server for the change to take effect. To reselect the extension at a later time, you change the D back to an E and restart the LDAP server.

NOTE

The server-side sort controls (1.2.840.113556.1.4.473 and 1.2.840.113556.1.4.474) are supported by the eDirectory LDAP server. However, they do not show up in the supportedControl listing shown earlier in this section.

LDAP Bind Methods

LDAP requires a client to employ a two-step process to connect with and authenticate to its back-end directory service. You first need to establish a connection to the LDAP server. This can be either an insecure , clear-text connection (with the default port 389) or a secured, encrypted connection (with the default port 636). Then the client has to perform a bind , the LDAP term for sending user information and password for the purpose of authentication, with the LDAP server. In the case of eDirectory, the supplied user credential is used for authentication against eDirectory, and the level of access is subject to eDirectory security (this includes user-level restrictions such as login time restriction and account lockout due to intrusion detection).

TIP

eDirectory's LDAP server uses the following attributes, not just the userPassword attribute (which is essentially mapped to the public/private key pair), to control access to an account:

• Locked By Intruder

• Login Allowed Time Map (this is the login time restriction)

• Login Disabled

• Login Expiration Time

• Login Maximum Simultaneous

• Password Expiration Interval

• Password Required

If a user is having difficulty accessing eDirectory via LDAP and the password is verified as being valid, you should check these attributes to help determine why the client cannot access the account.

LDAP supports a number of bind methods involving just the use of usernames and passwords. The bind methods defined in RFC 2829, "Authentication Methods for LDAP," are as follows:

• In an anonymous bind , the client sends empty strings for the DN/password pair. The eDirectory LDAP server establishes the client as [Public] or as the proxy user that you have configured. (The proxy user must not have a password.)

  NOTE

  If the LDAP connection was made by anonymous bind, the ldap_get_context_identity_name API function returns an empty string rather than [Public] .

  
  

• In a simple bind , the client sends non-null strings for the DN/password pair. However, the data is sent as clear text across the wire when using port 389. The eDirectory LDAP server establishes the client as the supplied DN. This method is called simple bind because using identity/password pairs is simple (that is, not complicated compared to using X.509 security certificates, for instance).

  NOTE

  Because clear-text passwords can be easily captured off the wire with network traffic sniffer software that is easy to obtain these days, the eDirectory LDAP server accepts only TLS/SSL encrypted passwords by default. You need to specifically enable the clear-text support by unchecking the Require TLS for Simple Binds with Passwords check box either during the LDAP server installation process or in the General Information Properties tab of the LDAP Group object in ConsoleOne or iManager.

  
  

• In a secure bind , the DN/password pair is sent over TLS/SSL using port 636. This method is often considered a bind method, but technically, the TLS/SSL encryption sitting on top of the LDAP simple bind is securing the data; the heart of the operation is still a simple bind.

  NOTE

  If you have not disabled TLS/SSL for simple bind, your LDAP application may report an " ldap_bind: Confidentiality required " error. If you look in DSTrace with the +LDAP filter enabled, you will see something like this:

   Error: "Rejecting unencrypted bind on cleartext port in         nds_back_bind, err[equal]13" 

  
  

  This is because the application is not using TLS/SSL when the LDAP server expects it.

  
  

  NOTE

  SSL 3.1 was released through Netscape. However, the Internet Engineering Task Force (IETF) took ownership for that standard by implementing TLS 1.0. As a result, Novell documentation often uses the two terms interchangeably or together: TLS/SSL.

  
  

• SASL bind uses the SASL specification as defined in RFC 2222. SASL is really a method for adding authentication support to connection-based protocols, and it does not dictate the mechanism to be used. The SASL protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating a security layer for subsequent protocol interactions. The command has a required argument that identifies a SASL mechanism. (SASL mechanisms are named by text strings, ranging from 1 to 20 characters in length, consisting of uppercase letters , digits, hyphens, and/or underscores. SASL mechanism names must be registered with the Internet Assigned Numbers Authority [IANA].) Therefore, SASL binds are implementation specific.

  The LDAP server for eDirectory 8.7.1 and higher supports Digest-MD5 (RFC 2831) and NMAS_LOGIN as SASL bind methods; NMAS_LOGIN provides support for the biometrics capability in NMAS. eDirectory 8.5/8.6 supports the EXTERNAL SASL mechanism, in which the client presents an X.509 user certificate to the server, and the server checks that the certificate is signed by the eDirectory tree's Certificate Authority (CA).

NOTE

Digest-MD5 is a required authentication method defined for LDAP v3 (RFC 2829). The LDAP servers for eDirectory prior to 8.7 did not support Digest-MD5, nor did they support extensible match search filters (discussed in the following section). Therefore, they are not fully LDAP v3 compliant; however, because most installations use SSL/TLS anyway, instead of SASL, this is not a major issue.

Every LDAP operation requires the client to be bound before the operation is attempted. After the completion of the operation (be it successful or failed), the connection is automatically terminated . Therefore, to perform an add entry operation and then a modify entry operation, you must bind twice. The exception to this rule is if you are using persistent search, where you need to bind only once to retrieve all the search results.

Access Control

Another feature introduced in LDAP v3 is the ability to apply access control. Access control determines who has rights to entry information in a directory. In an NDS tree, every entry has an ACL attribute, which contains the explicit trustee assignments that have been made to the entry and its attributes. In addition, NDS allows rights to be inherited, so that an assignment in a parent container can allow additional trustees to have access to an entry. Functions that calculate effective rights gather information from these parent containers as well as from the ACL attribute. When an LDAP client queries for effective rights, the result returned by an eDirectory LDAP server is based on the explicit assignments as well as the inherited rights. Directories that do not allow the inheritance of rights implement the functions to return only explicit trustee assignments.

The LDAP server for eDirectory 8.7 also implements support for extensible match search filtering, as defined in RFC 2251. An extensible match allows an LDAP client to specify multiple match rules for the same type of data and to include dn attribute elements in the search criteria. For example, the following extensible match filter searches for all User objects in containers that have OU=Grade5 as part of their DNs:

 (&(ou:dn:=Grade5)(objectClass=user)) 

As you can imagine, this feature allows applications to perform complex searches much more easily. Without it, the client itself has to provide more processing in order to filter out the desired data.

LDAP Event Services

Perhaps the most useful feature of the LDAP Server is LDAP Event Services, which was added to the Novell LDAP server for eDirectory 8.7. LDAP Event Services provides a way, via the standard LDAP extension mechanism, for applications to monitor the activity of eDirectory on an individual server.

LDAP Event Services supports more than 200 events that are divided into the following event types or categories:

• Bindery events ” These events indicate the occurrence of bindery object creation or deletion operations.

• Change server address events ” These events indicate the detection of a server address change.

• Connection change events ” These events indicate that the state of a connection has changed (perhaps from unauthenticated to authenticated).

• Dataless events ” This classification includes all events that do not have associated data (for instance, a bindery context was set on a server).

• Debug events ” These events indicate the occurrence of debugging messages sent by various NDS background processes, such as Limber.

• Entry events ” These events indicate the occurrence of individual entry operations such as creating or deleting an object.

• General DS events ” These are general events used to indicate a wide variety of DS operations, such as a partition join operation or a user login.

• Module state events ” These events indicate the change of state (from active to inactive, for example) of a DHost module.

• Network address events ” These events indicate a possible communication problem. It is triggered if DS reports a remote server down or an NCP retry timed out.

• Security Equivalence events ” These events indicate that an entry's security equivalence vector (SEV) is being checked.

• Value events ” These events indicate the occurrence of attribute value operations such as deleting or adding a value.

The event system extension allows a client to specify the events for which it wants to receive notification. This information is sent in the extension request. If the extension request specifies valid events, the LDAP server keeps the connection open (through the use of the persistent search feature) and uses the intermediate extended response to notify the client when events occur. Any data associated with an event is also sent in the response. This feature provides an easy mechanism for network management applications to include eDirectory in their list of managed services.

NOTE

Although any LDAP client can register to monitor any event, access restrictions are enforced at the time of event notification. If the authenticated client does not have sufficient access rights to view all the information in the event (such as Browse rights to attributes of interest), the event will not be sent. The one exception to this rule is the perpetrator DN : If the client does not have rights to the perpetrator object, the object will be sent as a zero-length string and represented as a NULL pointer value at the client. The event notification, however, will still be sent.

Schema Mapping Between LDAP and eDirectory

The LDAP server for eDirectory automatically maps the DS attributes and classes that are defined in RFC 2256 to their LDAP-equivalent names. Alas, not all DS names can be mapped to LDAP names due to naming convention incompatibility , as discussed earlier in this chapter, in the section "Naming Rules and Restrictions." If LDAP clients need access to DS classes and attributes that have incompatible names, you need to manually map them to LDAP-compatible names by using ConsoleOne. Even if a name is compatible with LDAP conventions, an LDAP client may still not be able to access a certain attribute because the LDAP server does not support that attribute's syntax.

eDirectory 8.5 and higher map inetOrgPerson to the DS object class User by default. LDAP clients can access this class by using the LDAP names inetOrgPerson or user . In NDS 7 and NDS 8, by default, the User class definition does not contain all the standard attributes for inetOrgPerson . To add these attributes to the User class definition, you must update the schema by using a schema file ( nov_inet.sch ), available from Novell. With eDirectory 8.5 and later, however, this is all done automatically for you.

The LDAP server allows LDAP access to DS attributes if the DS attribute uses LDAP-compatible syntax. For example, any DS attribute that uses the case ignore string syntax ( SYN_CI_STRING ) is available through LDAP because LDAP supports this syntax (which is called directoryString in LDAP). DS attributes that use a compound syntax (such as the timestamp syntax, SYN_TIMESTAMP , with its fields for time, replica number, and event identifier) are not automatically accessible through LDAP. Instead, the LDAP server converts such a syntax to case ignore strings, using dollar ( $ ) signs to separate fields of the same data type and ( # ) signs to separate fields of different data types. For example, the ACL is represented as follows:

 acl: 2#subtree#cn=admin,o=testing#[All Attributes Rights] 

where the first field is the trustee rights value ( 2 = Read), the next field indicates that it applies to the whole object ( subtree ), the next field is the object that has been granted the rights ( cn=admin,o=testing ), and the last field is the attribute name ( [All Attributes Rights] ). Postal Address is an example of an attribute that uses $ as data field delimiters (because all its data fields are of the type CI string):

 postalAddress: CN$Street$Post Office Box$City$State$Zip Code 

REAL WORLD: Base-64 Encoding of Attribute Values

The LDAP server encodes the values of attributes that use either SYN_STREAM or SYN_NET_ADDRESS , using the Base-64 Content-Transfer-Encoding mechanism (RFC 3548) before sending them to the client. Base-64 encoding is designed to represent arbitrary sequences of octet data streams in a printable (ASCII) format. base-64 uses a 64-character subset of US-ASCII (hence the name base 64) such that the characters are represented identically in all versions of ISO 646, including US-ASCII. All characters in the subset are also represented identically in all versions of EBCDIC. A 65th character, = , is used for padding and appears only at the end of the encoded output data stream, if ever.

When you query eDirectory for a login script, you get back something that looks like this:

 loginScript:: d3JpdGUgIkhlbGxvIHdvcmxkISIN 

When you run that through a Base-64 decoder (there are many available on the Internet), the preceding (without the loginScript:: part) translates to this:

 write "Hello world!" 

It gets a little more complicated when you're deciphering the networkAddress attribute. Typical output looks like this:

 networkAddress:: MSNaBAQE 

Decoding this produces 6 bytes of data, 3 bytes of which are none-printable characters. You need to actually look at the decoded information in hexadecimal format:

 31 23 5A 04 04 04 

The first byte represents the transport type. 0x31 is ASCII character 1, so the transport type is 1, or TCP/ IP . The next byte is the # delimiter used by the LDAP server to separate fields of different data types. The last four bytes are the IP address 90.4.4.4.

The LDAP server converts the DS time information (which uses the SYN_TIME syntax) to the LDAP format specified by X.208, which includes the year, month, day, hour , minute, optionally seconds, and time zone (GMT is recommended by X.208 for the time zone and uses Z as its symbol). The Login Time attribute would have a value similar to the following:

 loginTime: 20031217051015Z 

NOTE

The SYN_HOLD syntax is not supported through LDAP and is being phased out from use in NDS /eDirectory.

If you need to look up the attribute and class mapping between LDAP and NDS, from ConsoleOne you open the LDAP Group object, and from its Properties page, you check the Attribute Mappings (see Figure 2.22) and Class Mappings (see Figure 2.23) tabs, respectively. You can also use these tabs to add, delete, or modify the mapping assignments.

Figure 2.22. The Attributes Mappings tab of the LDAP Group object.

Figure 2.23. The Class Mappings tab of the LDAP Group object.

LDAP Name Resolution Models

Almost every LDAP operation takes a DN identifying a target entry as a parameter. The first step in performing an LDAP operation is to find a copy of the target entry somewhere in the eDirectory tree. LDAP v3 supports two basic name resolution models ”chaining and referral ”that are discussed in the following sections. Also discussed in the following sections is how the eDirectory LDAP server uses eDirectory knowledge references for name resolution.

NOTE

DS maintains certain information in the replica rings of each partition root object (by using the Replica attribute) and keeps track of subordinate references to partition roots. This information includes the server's ID, address, and transport type (such as IP or IPX ), and the replica type that is stored on that server. This information is termed NDS knowledge references .

Chaining

Sometimes when an LDAP client issues a request to an LDAP server, the server may not contain the target entry of the operation in its local database. However, the server can use the NDS knowledge references that it has about partitions and other servers in the eDirectory tree to contact another LDAP server that knows more about the DN. This process is called chaining , and it is a server-based form of name resolution. If necessary, the chaining 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. The LDAP server performs all this on behalf of the client. Therefore, unaware of the server-to-server operations, the client assumes that the first server completed the request.

NOTE

Earlier versions of the NDS LDAP server used the term traversal instead of chaining in the NWAdmin and ConsoleOne snap-ins. The current implementation consistently uses chaining in both the administration tools and documentation.

Through chaining, an LDAP server provides the following advantages:

• It hides all name-resolution/ tree-walking details from the client.

• It automatically takes care of remote authentication to other LDAP servers, using the same identity with which the LDAP client is bound.

• It acts as a proxy for the client and requests the remote server to complete the operation. Then it reports the result to the client as though the entry were stored locally.

• It works seamlessly, even when some servers in the eDirectory tree don't support LDAP services.

Chaining has disadvantages as well as advantages. For instance, 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 processing the operation, different servers might process two requests to operate on the same entry. In 99% of the cases, this is not an issue. However, depending on the type of operation, the client may receive an erroneous indication that the requested operation ”say, deletion of an entry ”failed (due to duplicate processing).

Chaining can be bandwidth- intensive for large LDAP search operations. This is because in the chaining mode, the first LDAP server acts as the proxy to the client, where it receives the search results from another LDAP server and then passes the results back to the client; the data is transmitted on the network twice.

NOTE

eDirectory attempts to sort the servers by the cost associated with contacting them (such as hop count). For load balancing, when there is more than one server available, eDirectory randomly selects among the servers with the lowest cost.

In a way, LDAP chaining is similar to NDS's tree-walking mechanism. However, there is a difference between the two in terms of performance. LDAP chaining requires a bind every time a server is chained to. If the chained-to server does not have the required entry, the overhead spent on the bind operation is wasted , and another bind has to be made to the next server. (The way around this is for the client to first do an anonymous bind to search for the target entry before binding to perform the operation. This does not always work, however, because the anonymous user may not have the necessary browse rights to the target entry, and the client application will have to be smart.) NDS tree-walking, on the other hand, does not require authentication. Only when the target object is located is an authenticated connection made to that server.

TIP

In an NDS tree where not all servers are running the LDAP service and the LDAP servers do not have partitions of the whole tree, the chaining method works better than tree-walking because the LDAP server can access the whole tree on behalf of the clients.

Referrals

Referrals are a client-based name resolution method in which the client decides what to do if the target LDAP server does not have a local copy of the target entry. In this model, whenever a server cannot find the requested DN within its local database, it uses the knowledge reference it has to generate a referral to another server that does have the desired information or knows more about the target DN. The client then makes a new request to the referred server and retries the operation. If the second LDAP server has the target DN for the operation, it performs the request; otherwise, it also sends a referral back to the client. This continues until the client contacts a server that has the entry and can perform the desired operation or until an LDAP server returns an error that the entry cannot be found. The client can also decide to not connect to the next referred server and return an error instead or prompt the user before contacting the referred server.

The main advantage of the referrals-based method is that the client has total control. When the server returns a referral to the client, the referral contains information for each of these other servers. To continue the operations, the client can be smart about which server it picks from the list, or it can prompt the user for a selection. Another advantage is that when the client knows where an entry is located, it can go directly to the server that has the entry for additional operation requests, thus increasing efficiency and reducing network traffic.

The main downside of the referral method is that the client has to be smart and know how to handle and then follow referrals. The other drawback is that an LDAP server must service every partition in the NDS tree. Otherwise, some entries will not be accessible by LDAP clients because no referrals can be generated for data in the partitions that are not serviced by an LDAP server.

NOTE

LDAP v2 does not support referrals. If the LDAP server cannot find the requested information in its local data store, it fails the search and returns an error. The University of Michigan created an extension to LDAP that allows LDAP v2 to return referrals to clients as error messages. This adds complexity to the client because it must follow the referrals, but the server retains simplicity.

LDAP v3 introduced a new type of referral call superior referrals . Superior referrals enable an eDirectory tree to refer directory requests to other directories (such as a separate eDirectory tree or one hosted on a Netscape directory server). This capability enables eDirectory to function as part of a larger directory tree that comprises two or more separate directory trees. In other words, this feature can help companies federate two or more directory trees to function as a single directory tree. For example, suppose your company acquired a subsidiary that is using eDirectory. Your company is not using eDirectory but is using an LDAP v3 “compliant directory. Your company wants to add the subsidiary's directory tree as a branch of its corporate tree. By using superior referrals, you can configure eDirectory to consult your company's corporate directory to fulfill requests for information that resides in that directory. Superior referrals are supported by eDirectory 8.7 and higher.

LDAP Objects in NDS/eDirectory

When LDAP Services for eDirectory is installed, it creates two objects in the tree: an LDAP Group object and an LDAP Server object in the same container as the NCP Server object. These objects initially contain the default configuration for LDAP Services:

• The LDAP Server object (called LDAP Server “ servername ) represents server-specific configuration data, such as the port numbers to be used for clear-text and TLS/SSL bind, and whether the server supports anonymous binds from LDAP clients.

• The LDAP Group object (called LDAP Group “ servername ) provides common configuration data for a group of LDAP servers, such as the proxy user to be used for an anonymous bind.

You can associate multiple LDAP Server objects with one LDAP Group object. All the associated LDAP servers then get their server-specific configuration from their LDAP Server object but get common or shared information from the LDAP Group object.

The LDAP Services installation program creates these objects by default. Later, you can associate multiple LDAP Server objects with a single LDAP Group object (and perhaps rename the LDAP Group object to something more meaningful that does not contain the server name). You can modify the default configuration by using either the ConsoleOne LDAP snap-in or the LDAP Management task in Novell iManager. On Unix/Linux, you can also use the ldapconfig utility.

NOTE

With iManager 2.x, there is also an LDAPManagement object under the Extend container (see Figure 2.24). However, this object does not contain configuration information for LDAP Services.

Figure 2.24. The Extend container created by iManager 2.x.

WARNING

Although it is possible to associate newer versions of an LDAP Server object with older versions of LDAP Group objects, Novell does not recommend that you mix versions due to the fact that certain feature sets are only available to newer versions of LDAP Services. For example, you should avoid associating an LDAP Group object for eDirectory 8.5 with an LDAP Server object for eDirectory 8.7. However, it is okay to include eDirectory 8.7.0 and 8.7.1 LDAP Server objects with the same eDirectory 8.7.1 LDAP Group object.