Novell is now a part of Micro Focus

Developing an LDAP Client for Novell Directory Services

Articles and Tips: article

NANCY C. MCLAIN
Senior Technical Writer
Developer Information

01 Jul 1998


Introduces basic LDAP concepts, discusses LDAP versions 2 and 3 and discusses the LDAP support by Novell's LDAP Services for NDS.

Introduction

This is the first of three articles which will discuss the issues involved in developing an LDAP client for Novell Directory Services (NDS). This article provides a basic introduction to LDAP and to Novell's LDAP services for NDS. The second article will discuss configuring Novell's LDAP services for NDS v 3, and the third article will describe the protocol issues between the LDAP client and LDAP Services v 3 for NDS.

Novell is currently shipping LDAP Services for NDS v 1. NetWare 5 will include LDAP Services v 3. You can download beta versions of LDAP Services v 3 from http://www.developernet.com.

X.500 Directory Services

The Lightweight Directory Access Protocol (LDAP) is becoming an increasingly important part of the directory services world. Directory services differ from each other in the way their information is represented, searched for, and accessed. They also differ as to whether the information can be extended and how and if the information can be updated. The X.500 directory services standard was defined in an attempt to create some consistent guidelines for directory services that would allow interoperability.

The X.500 standard defines a comprehensive directory service to store data. It also defines the Directory Access Protocol (DAP) that clients can use to access the directory. In a pure X.500 environment, DAP uses the OSI protocol stack for network communications. DAP is a full OSI protocol with extensive functionality. It is much more complex than most TCP/IP stack implementations and requires more code and power to run. This makes it very difficult to run without bogging down the system. X.500's heavy protocol requirement has been a main factor in limiting its acceptance. And, because the OSI networking infrastructure has not yet been fully developed, few pure X.500 directory services exist.

But, a number of X.500-like directory services do exist. These X.500-like directory services are not X.500 compatible on the protocol level because they have usually implemented a proprietary protocol, rather than use DAP. However, these directory services are compatible on the application level. This means that once the protocols between two X.500-like directory services are mapped to each other, their APIs are compatible. The protocol mapping is usually accomplished with a interface that sits between the two directory services.

Lightweight Directory Access Protocol

Because DAP is too heavyweight and difficult to easily implement, the University of Michigan, with help from the ISODE Consortium, designed and developed LDAP. LDAP is a protocol that defines a directory service and the access to that service. It is designed to remove some of the X.500 burden from clients by removing DAP's overhead and little-used features, emulating its complex operations, and simplifying its access. As a result, LDAP queries are much smaller than DAP's and its source code is about 4.4 times smaller than DAP's. (Howes, Timothy A. "The Lightweight Directory Access Protocol: X.500 Lite," 27 July 1995, http://www-leland.stanford.edu/group/networking/directory/doc/ldap/ldap.html.)

This means that the directory is now accessible on most platforms.

LDAP is simple to work with and has features that enable it to support any kind of application. It allows directory information to be queried and managed. It has searching capabilities that allow complex searches on portions of the directory. In addition, it has an extensible information model that allows the stored information to be dynamically extended.

LDAP's defaults are also set in such a way that applications must make very few calls to set session options.

LDAP simplifies DAP in four areas:

  • Transport. LDAP runs over the TCP/IP protocol stack.

  • Functionality. LDAP simplifies DAP's functionality by leaving out infrequently used and redundant operations. This means that it lacks some of DAP's functionality, but it also means that PCs and Macintoshes can run the LDAP protocol to access and manipulate X.500 directory services. PCs and Macintoshes can also be more easily used to store a directory service.

  • Data representation. LDAP uses strings to represent data. DAP uses a more complex data representation.

  • Encoding. LDAP uses a simpler version of X.500's Basic Encoding Rules (BER). LDAP v 2 restricts BER to use only the definite form of length encoding and encode all bit string, octet strings, and character strings in primitive form only. Clients should be able to display non-binary values with little or no translation.

Overall, the LDAP data and name space model is essentially the same as X.500's. Like X.500, the LDAP data model is based on entries that contain information about objects. The entries are composed of attributes that have a type and one or more values. Each attribute has a syntax that determines what kind of values it allows, such as ASCII characters, octet strings, or jpeg, and how those values behave during directory operations. And, like the X.500 name space, the LDAP name space is hierarchal and uses similar object classes such as country and organizational unit.

LDAP Communication Model

LDAP uses a client/server request/reply model. That is, clients send a request describing a desired operation to a server. The server then performs the operations on the directory that are necessary to complete the request. The server then responds to the client with the results. Figure 1 illustrates this communication model.

Figure 1: LDAP client communicating with X.500 directory services.

In the model shown above, the LDAP server maps LDAP APIs and protocols to the X.500 directory service's APIs and protocols. As I explain later, this is the model used by Novell's LDAP Services for NDS. LDAP Services is really an LDAP interface that runs on a Novell server.

LDAP is becoming widely accepted as a stand-alone directory service. In this case, the communication model is the same, except that the LDAP client queries an LDAP directory service as the next picture shows. As with any distributed directory service, the reply always references the same entry, regardless of which server is queried.

Figure 2: LDAP client communicating with LDAP directory services.

LDAP Application Model

LDAP supplies APIs for:

  • Searching and retrieving entries from the directory

  • Adding new entries to the directory

  • Updating entries in the directory

  • Deleting entries from the directory

  • Renaming entries in the directory

  • Binding operations

  • Abandoning operations

LDAP uses its search function to emulate the more complex X.500 operations such as list and read. LDAP's search function is very similar to the DAP search. You specify a base object to be searched for and the portion (or scope) of the tree to search. A filter specifies which conditions must be met in order for the search to match a particular entry. The LDAP search operation offers identical functionality to DAP's, but is encoded in a simpler form.

The LDAP API allows applications to perform operations either synchronously or asynchronously depending upon whether you want to wait for one operation to complete before receiving the return value of a previous function. All LDAP operations in LDAP Services for NDS are asynchronous.

LDAP applications typically perform 5 general steps:

  1. Open a connection to the LDAP server. This step involves initializing the session, setting session preferences and binding to the server. Usually the session preferences involve defining:

    • maximum number of entries returned in a search

    • maximum number of seconds spent on a search

    • how aliases are handled

    • how referrals are handled

    • whether the client is threaded

    • security preferences

    Once the application is bound to the server it receives a connection handle to use for the remainder of the session. The use of connection handles allows a client to have several connections open at once. LDAP v 3 negotiates and opens Secure Socket Layer (SSL) connections at this point.

  2. Authenticate to the server. The client can authenticate either anonymously with public rights, or fully with a password. Novell's LDAP Services v 3 requires an SSL connection for full authentication. By default, Novell LDAP Services v 3 will not allow passwords over an open or non-secure connection.

  3. Perform the operations and obtain the results. This step usually involves searching the directory services data. It frequently also involves manipulating the directory services data as well.

  4. Process the results. This step involves making use of the returned information. Applications often have very little work besides parsing.

  5. Close the session. This step involves unbinding from the server and disposing the session handle.

Updating a distinguished name provides a simple example of this five-step model:

  1. The client application requests a session and binds to the LDAP server. The LDAP server returns a connection handle to the client application.

  2. The client application submits a request to modify an entry. The request contains the connection handle, the distinguished name of the entry, the updated attribute information and any other pertinent information to the LDAP server.

  3. The LDAP server uses this information to locate the entry and performs the modify operation to update the entry. It returns the result to the client.

  4. The application processes the results to determine whether the attempt was successful or unsuccessful.

  5. The application then closes the session, unbinds from the server and disposes of the session handle.

Differences between LDAP versions 1, 2 and 3

RFC 1487 defines LDAP v 1. This version did not define inter-server communication, replication or provide strong security. It also depended on the DAP protocols to maintain the directory tree and to update the servers.

LDAP started being widely accepted with v 2, defined in RFCs 1777 and 1778. As LDAP v 2 became more widely accepted, its limitations became more apparent. Because it had only limited security and did not support references, protocol extensions, and internationalization, it was not promoted to the status of a full Internet standard.

LDAP v 3 was designed to overcome those limitations and was promoted to Proposed Standard status by the Internet Engineering Steering Group (IESG) in December 1997.

LDAP v 3 includes these new features:

  • Referrals

  • Security enhancements

  • Unicode character support

  • Protocol extensions

  • Schema-defined data

LDAP v 3 also improves compatibility with X.500 directory services and specifies LDAP's interactions with non-X.500 and standalone directories.

Referrals

X.500 specifies that whenever a server cannot find the requested information within its own directory services, its reply can contain a referral to another server that does have the desired information, if the original server knows about it. The client then makes a new request to the other server. For example, if the directory services server at ACME Industry receives a request for information from State University, the ACME industry server can refer the client to the directory services server at State University. In this way, two directory services can appear to be a single directory service.

LDAP v 2

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

LDAP v 3

LDAP v 3 supports referrals by specifying that the LDAP server must either return the referral to the client or resolve the referral and return the desired information to the client. Figure 3 shows both models of referral resolution.

Figure 3: LDAP server resolving the referral.

Figure 4: LDAP client resolving the referral.

LDAP v 3 does not provide a method that allows multiple trees to learn about each other and their contents. Currently, any index or referral information is configured manually.

A server might also use a referral to allow the client to communicate with a closer replica of the data, as shown in Figure 5.

Figure 5: Referral to closer replica.

Security and Enhancements

As LDAP became more and more accepted, its authentication and security limitations became more pronounced.

LDAP v 2

LDAP v 2 defines a simple method for authentication. It uses clear text passwords and Kerberos v 4. (Kerberos is a secret key authentication method developed by MIT. For more information http://web.mit.edu/kerberos/www/.) Version 2 LDAP servers can be set up to restrict permissions to the directory. Before LDAP clients can ask an LDAP server to perform an operation, the client must authenticate by supplying a distinguished name and password. If the client does not have sufficient rights to perform the operation, the server fails the operation and replies "unsuccessful."

LDAP v 3

Unlike LDAP v 2, LDAP v 3 supports SSL connections, strong authentication with X.509 certificates, and supports Access Control Lists (ACL).

LDAP v 3 also provides minimal authentication using only a clear text password, but it is not recommended to use this method over an open network with no authentication or encryption. Version 3 supports both anonymous and full authentication. If the client is using anonymous, or no authentication, it must choose the simple authentication method and use a NULL password. Typically, the Distinguished Name (DN) is also NULL, as well. An anonymous authentication grants only public rights. Some operations, such as general searches, only require public rights and therefore only need an anonymous connection, not a fully authenticated connection. To authenticate as a specific user (a fully authenticated connection), the client provides the user's DN and password. This authentication grants clients their specific rights.

If you are using a connection-oriented transport, such as TCP/IP, version 3 allows you to use simple authentication with a clear text password and the Simple Authentication and Security Layer (SASL) standard to secure access between the LDAP client and server. SASL enables full user authentication, data encryption and data integrity.

In this model, once a client authenticates to a server and negotiates the protection of subsequent interactions, a security layer defined by SASL is inserted between the LDAP protocol and the connection protocol. This picture shows the placement of SASL. After the client and server negotiate the use of a SASL layer, they send all subsequent data to be sent over the wire through this layer. (For more information about SASL, see RFC2222 at ftp://ds.internic.net/rfc/rfc2222.txt.)

Figure 6: Client/Server communication protocol without the SASL.

Figure 7: Client/Server communication protocol with the SASL.

SSL is a type of SASL.

By default Novell's LDAP Services v 3 for NDS requires an SSL connection for a full authentication using a password.

Unicode Character Support

LDAP v 2 did not support internationalization. Version 3 allows internationalization by supporting the ISO 10646 character set (popularly known as Unicode), transported in UTF8 format.

Protocol Extensions

The LDAP v 2 protocol was not extensible. So, it was not able to support new operations. Some extensions, such as the University of Michigan's extension to allow referrals, have been added, but they were not part of the version 2 standard.

LDAP v 3 supports protocol extensions so that it can eventually provide a full Internet directory service. These extensions allow LDAP to support new operations. Added controls can also extend existing operations.

Currently, LDAP is to be extended in these areas:

  • Access control and authentication

  • Replication and partitioning

  • Search results sorting and page retrieval

  • Dynamic directories

  • Schema, referral and knowledge reference maintenance

  • LDAP server discovery

LDAP v 3 can support other necessary extensions as well. For more information about planned extensions, see the Web site http://www.critical-angle.com/ldapworld/ldapext.html.

So that it can support protocol extensions, LDAP v 3 allows clients to determine which protocol version a server supports by reading the supportedLDAPVersion attribute from the root DSA-specific Entry (DSE). LDAP v 2 does not provide this attribute.

Schema-defined Data and rootDSE

Schemas define the way real-world and conceptual objects are defined in the directory. They define what attributes an object can have and what value types each attribute allows. LDAP v 2 supported an X.500 schema. But, the schema was not defined locally. LDAP v 3 exposes the schema through the Root's DSE SubSchema entry so that clients can access and use it.

Like X.500, LDAP's directory is called the Directory Information Tree (DIT). The DIT root is a DSE and is not part of any naming context (partition). The DSE contains "operational attributes." These are attributes the server uses to administer the directory system. The DSE also contains information which LDAP clients may request to determine a given DSE's supported characteristics. The LDAP client can retrieve these attributes with a base object search of DIT's root. The search requires a filter of "(objectClass = *)". Here is a list of rootDSE attributes defined by LDAP v 3.

LDAP v 3 rootDSE Attributes


Attribute
Attribute Values

namingContexts

Distinguished Names of the server's local naming contexts (or NetWare partition names). Novell's LDAP Services v 3 obtains this information from the NDS replica ring.

altServer

Other server's URLs to contact when this server becomes unavailable. This attribute is absent if the server does not know of any other servers to contact. Novell's LDAP version 3 currently provides raw IP addresses obtained from the NDS replica ring.

subschemaSubentry

Distinguished Name(s) of the entry(s) which controls the schema for this server's partitions. Novell LDAP Services v 3 always returns "cn=schema" because NDS only has one schema per DIT. This is the baseObject to use when requesting the subschemaSubentry information explained under "subschemaSubentry Information."

supportedExtension

Object identifiers (OIDs) identifying the supported extended operations the server supports. This attribute is absent if the server does not support any extensions. Novell LDAP Services v 3 does not currently support extensions.

supportedControl

Object identifiers (OID)s that identify the controls the server supports. This attribute is absent if the server does not support any controls. Novell LDAP Services v 3 does not currently support controls.

supportedSASLMechanisms

Names of the SASL mechanisms (such as X.511-Strong) the server supports. This attribute is absent if the server does not support any SASL mechanisms. Novell's LDAP Services v 3 does not currently support any SASL mechanisms.

supportedLDAPVersion

LDAP protocol versions the server implements. Novell LDAP Services version 3 supports LDAP versions 2 and 3.

subschemaSubentry Information

LDAP clients need to read the schema information describing a particular DIT because they can connect to a wide variety of directory servers developed by various OEMs. Each DSA's DIT has a different schema. LDAP v 3 defines a subschemaSubentry attribute to provide schema information so that clients can determine the object definitions in the DIT of each DSA they connect to.

Because some LDAP schema classes and attributes map directly to those already contained in NDS, Novell's LDAP Services v 3 uses the subschemaSubentry attribute to expose some of the NDS schema. The NDS schema has also been extended with additional LDAP attributes in order to support Netscape and Entrust products. You can also use NDSManager and NWAdmin to create and map additional classes and attributes between LDAP and NDS.

The subschemaSubentry request is made up of:

  • a base object search of a Distinguished Name found in the rootDSE subschemaSubentry attribute, typically "(cn=schema)"

  • a filter of "(objectClass = subschemaSubentry)."

The reply consists of a lengthy stream of concatenated LDAP classes and attributes.

Each LDAP class is defined by:

  • its registered OID

  • its cleartext name string

  • a cleartext description string

  • a list of its superior classes

  • a list of its mandatory attributes

  • a list of its optional attributes

This is an example of a class definition:

( 2.5.6.10

NAME  'inetOrgPerson'

DESC  'Standard ObjectClass'

SUP  'organizationalPerson' 'person' 'top'

MUST  ( cn $ sn $ objectClass )

MAY  ( mail $ UserCertificate;binary $ facsimileTelephoneNumber $ 1 $ ou 

     $ physicalDeliveryOfficeName $ postalAddress $ postalCode $ postOfficeBox 

     $ st $ street $ title $ description $ seeAlso $ telephoneNumber $ givenName 

     $ initials )

Each attribute is defined by:

  • its registered OID

  • its cleartext name string

  • a cleartext description string, and alias info if applicable

  • its registered syntax OID

Here is an example of an attribute definition:

(2.5.4.11

NAME   'organizationalUnitName'

DESC   'Standard Attribute, alias for ou'

SYNTAX   '1.3.6.1.4.1.1466.115.121.1.15')

The information returned from the subschemaSubentry request is difficult to read. Some text editors will not even display information redirected to a file because the lines are too long. To help with this, our LDAP engineers have written an utility to format the subschema data. This utility takes the glob of text returned from the subschema and formats it into readable lines by adding carriage returns and line feeds.

This utility searches the dump file for specific character sequences and replaces certain spaces with newline characters to break up the long lines and format the data in a more readable display.

The utility name is FORMATDMP.EXE. You can download it from our site at: http://www.novell.com/coolsolutions/tools/15626.html

To run the utility, use this sytnax:

FORMATDMP.EXE                    dump_file_name                    new_file_name

Be aware that Novell does not support this utility.

LDAP Requests for Comments (RFC)

LDAP is well-defined in a set of RFCs. In addition, it has a number of drafts associated with it. A draft is a working document that is not accepted by the standard committee as a standard. Because a draft is not a standard, LDAP implementations do not have to conform to it in order to be labeled LDAP-compliant. However, RFCs can be awarded Standards status. To be labeled LDAP-compliant, an LDAP implementation must conform to the standards described in an RFC.

This table lists the RFCs that define each LDAP version.


LDAP v 2
LDAP v 3

Protocol

RFC 1777ftp://ds.internic.net/rfc/rfc1777.txt

RFC 2251ftp://ds.internic.net/rfc/rfc2251.txt

Attribute Syntax Definitions

RFC 1778ftp://ds.internic.net/rfc/rfc1778.txt

RFC 2252ftp://ds.internic.net/rfc/rfc2252.txt

String Representation of Distinguished Names

RFC 1779ftp://ds.internic.net/rfc/rfc1779.txt

RFC 2253ftp://ds.internic.net/rfc/rfc2253.txt

String Representation of LDAP Search Filters

RFC 1960ftp://ds.internic.net/rfc/rfc1960.txt

RFC 2254ftp://ds.internic.net/rfc/rfc2254.txt

LDAP URL Format

RFC 1959ftp://ds.internic.net/rfc/rfc1959.txt

RFC 2255ftp://ds.internic.net/rfc/rfc2255.txt

User Schema

No schema RFC

RFC 2256ftp://ds.internic.net/rfc/rfc2256.txt

API

RFC 1823ftp://ds.internic.net/rfc/rfc1823.txt

RFC 1823ftp://ds.internic.net/rfc/rfc1823.txt

LDAP SDKs

RFC 1823 defines a C language API for LDAP. This API is designed to be powerful, yet extremely simple to use. RFC 1823 is not an Internet standard because other APIs could be designed that would enable the functionality required by RFCs 1777 and 1778. Netscape and the University of Michigan have both developed LDAP APIs and SDKs. The Netscape SDK supports LDAP v 3, and because LDAP 3 is completely backwards-compatible, this SDK supports LDAP v 2 as well. Netscape provides SDKS for both C and Java developers. The University of Michigan SDK only supports LDAP v 2 and is available only for C.

Novell's LDAP Services for NDS

To make NDS more easily accessible to more clients and customers, Novell is releasing Novell's LDAP Services for NDS to expose NDS to LDAP clients and applications.

With LDAP for NDS, you can use NDS to manage the information you are making available on the Internet or an intranet, and you can use NDS to control users' access to this information. You can use LDAP Services for NDS to perform directory management tasks such as adding or deleting users and groups from any workstation with an Internet connection and LDAP client software. And, your users can use LDAP Services for NDS to access any network resources they have NDS-based rights to. At this time, you cannot grant NDS rights through LDAP.

NDS/LDAP Communication Model

NDS is the most X.500-like directory services that is generally accepted in the industry. In other words, it has all the functionality of an X.500 directory service. But like many X.500-like directory services, it uses a proprietary protocol, rather than implement the complex DAP. Novell's LDAP Services for NDS (Novell's LDAP services) maps the NDS protocol to the LDAP protocol and allows LDAP-based applications to access NDS. Figure 8 shows the NDS/LDAP communication model. As you can see, LDAP is an interface running on a NetWare server and translating LDAP requests to NDS requests and NDS replies to LDAP replies. LDAP services allow LDAP clients to access the entire NDS tree. (LDAP Services v 1 must run on at least a NetWare 4.11 server; LDAP Services v 3 requires a NetWare 5.0 server.)

Figure 8: LDAP client communicating with NDS.

LDAP v 3 Support

Novell's LDAP Services v 3 for NDS supports LDAP v 3 with these exceptions:

  • Readable and Writeable Root DSE. Readable Root DSE is completely supported. Writeable Root DSE will be supported in a future release.

  • Protocol extensions. Novell's LDAP Services v 3 recognizes, but does not understand any extended requests and controls. In other words, our LDAP Services recognizes the LDAP extensions, but returns an error to the client stating that the extended request or control is unsupported.

  • Security. Novell's LDAP Services v 3 supports SSL.

  • Assumed Binds. Novell's LDAP Services v 3 assumes a bound client. In other words, the client can initiate an anonymous operation, such as a search, to LDAP Services. The server then automatically binds the client and sends back a connection handle.

  • Modify RDN and Modify DN. The Modify RDN operation renames an object in the same container. The Modify DN operation moves an object to a different container.

  • SSL support. In LDAP Services v 3, the default to allow the clear text password is off. This means that the default session connection is anonymous and the client will only receive public rights. If clients choose to allow their password to go across the wire, they can be fully authenticated and receive all their NDS rights.

  • Schema support. LDAP Services supports the LDAP schema by extending the NDS schema to match the common LDAP schema extensions.

ACL Support

LDAP Services for NDS versions 1 and 3 support NDS ACLs. An additional LDAP ACL will be able to restrict the LDAP client further than the client's NDS ACLs. But, the NDS ACL restrictions will override any LDAP permissions. In other words, the LDAP ACLs can be more restrictive than the NDS ACLs, but they can never be more permissive. Through LDAP, neither set of ACLs will allow the client any permissions or rights that one set denies.

Although you can use any LDAP SDK to write a suitable client for LDAP Services for NDS, Netscape's SDK supports LDAP v 3. You can download Netscape's SDK from the Web at http://developer.netscape.com/tech/directory.

LDAP's low overhead and simplicity makes it easy to run on desktop computers. This means that it is quickly gaining wide-spread acceptance. LDAP makes it possible to run fully-featured directory services on desktop computers and makes it easy to access and manage them. LDAP servers interfacing into directory services, could mean that as methods for advertising a directory service's specific information evolve, more and more directory services will be able to communicate together.

Novell's LDAP Services for NDS means that NDS can be even more easily managed and accessed across an Internet or an intranet. Any LDAP client can access the entire NDS tree through Novell's LDAP Services, making the NDS services more easily and readily available.

More Information

The Web provides a great deal of good information on LDAP and X.500. Typing "X.500", "LDAP", "LDAP RFC", or "LDAP SDK" in your favorite search engine will probably result in more information than you can sort through. I recommend starting with the following resources:

Books

Howes, Timothy A. and Smith, Mark C. LDAP: Programming Directory-Enabled Applications with Lightweight Directory Access Protocol. Macmillan Technical Publishing, 1997. ISBN 1-57870-000-0.

This book not only provides an excellent introduction to LDAP, but it also goes into detail about developing and coding LDAP applications. The authors provide step-by-step explanations of the sample code. The book contains plenty of sample code and clear examples. Appendix A of this book also provides a summary of LDAP-related WEB links.

Radicatti, Sara. X.500 Directory Services Technology and Deployment . Van Nostrand Reinhold, 1994. ISBN 0-442-018169.

This book is out of print, but I regularly refer to it and recommend hunting a copy down. It explains the X.500 directory services concepts in clear and precise detail.

Novell AppNotes

Herbon, Gamal B. "An Introduction to NetWare Directory Services," Novell AppNotes, April 1993.

This AppNote introduces the basic concepts behind NetWare Directory Services. After giving a quick overview of NDS, it discusses NDS objects and properties and explains how these objects form the Directory tree. It also explains about NDS partitions and replicas, bindery compatibility, and time synchronization.

Hughes, Jeffrey F. and Thomas, Blair W. "Learning and Applying the Rules of NDS Security," Novell AppNotes, August, 1997.

This AppNote clearly presents the basic rules of NDS security, along with numerous examples of how to implement it.

Lamb, Jason and Myers, Tim. "Understanding NetWare Directory Services Rights." Novell AppNotes, April 1993.

This AppNote lays out some fundamental concepts of the Directory rights structure. It starts with some definitions of the NDS structure, and proceeds to explain how rights are assigned using Access Control Lists. It also discusses inherited rights, security equivalences, and bindery emulation.

Mark, Alan. "Architecting a Full-Service Intranet with Novell's IntranetWare," Novell AppNotes, December 1996.

Describes how to build a full-service intranet to meet various communication and administrative needs within an organization

Novell Developer Notes

Crossen, Nancy, Williams, John and Herrin, Selby. "Overview of Novell Directory Services," Novell Developer Notes, March 1997.

Discusses the following features of NDS: schema, naming, entry management, relationship management, NDS personalities, local event services, authentication, and authorization.

Crossen, Nancy. "Understanding NetWare Directory Services," Novell Developer Notes, January/February 1995.

This DevNote defines basic concepts and operating theory that are necessary to understand NetWare Directory Services (NDS). Concepts covered include hierarchical naming, directory schema, inheritance, authentication, partitioning, replication, name resolution and synchronization.

Web Sites

See the table earlier in this article for the Web sites containing the LDAP RFCs.

LDAP SDKs

ftp://terminator.rs.itd.unich.edu/ldap/

You can download the University of Michigan's LDAP SDK at this site. The file name is ldap-3.3.tar.tar.z. The SDK version is 3.3, but it supports LDAP v 2. The SDK offers source code, examples and documentation.

http://developer.netscape.com/tech/directory

You can download Netscape's LDAP SDK at this site. This SDK supports LDAP v 3. The SDK offers source code, examples and documentation.

General LDAP information

http://www.critical-angle.com/ldapworld

This site offers a series of links to good LDAP and X.500 information.

http://www.kingsmountain.com/ldapRoadmap.shtml

This is an excellent site that has organized links into different categories and subcategories. It's an invaluable aid in navigating the LDAP information on the Web.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates