Novell is now a part of Micro Focus

New Features of NDS in NetWare 5

Articles and Tips: article

JUDY WILSON
Technical Writer
Novell Products Group

JOHN WILLIAMS
Technical Writer
Novell Products Group

01 Sep 1998


Describes new or enhanced NDS features and NDS-enabled applications that are integrated with NetWare 5.

Introduction

NetWare 5 has many new features independent of NDS. These include such features as a new high-performance kernel, enhanced memory protection, a new storage and access system for storing large files, and new, faster, more manageable print services (called Novell Distributed Print Services). For more information about all the features in NetWare 5, see Novell's Web site at http://www.novell.com.

This article describes only those features that affect NDS: new or enhanced NDS features and NDS-enabled applications that are integrated with NetWare 5.

New or Enhanced NDS Features

NDS in NetWare 5 has been enhanced to support:

  • Protocol independence (enabling TCP/IP)

  • New schema objects and attributes

  • New inheritance rules

  • Enhanced security with Public Key Infrastructure

  • Enhanced management features and better management tools and utilities

  • Multiple interfaces for application development

The sections below describe these features.

Native TCP/IP

NetWare 5 has made NCP independent of IPX so that the NetWare server can be configured to support IPX/SPX, TCP/IP, or both. Since the NDS protocol is build on top of NCP, NDS shares protocol independence with NCP.

In NetWare 4.x, NDS depends on SAP to discover NDS trees and to advertise NDS tree names. When a network is configured only for IP with NetWare 5, NDS can rely on SLP to discover NDS tree names or it can be manually configured to know NDS tree names.

To make managing IP networks and IP addresses easier, NetWare 5 includes a DHCP (Dynamic Host Configuration Protocol) server. The DHCP server provides dynamic IP address assignment so that many devices can share a limited address space. Using NDS, the DHCP server makes it easier to administer IP address and device configuration information and passes this information to the hosts (DHCP clients) on the TCP/IP network.

For NDS to work in a mixed IP and IPX network, NDS made the following modifications:

  • Changed its synchronization algorithms to transitive synchronization

  • Replaced back links with distributed reference links

See the following sections for more information.

Transitive Synchronization

In current releases, NDS synchronization processes require that all servers in a replica list be able to communicate and synchronize with each server in the replica list. Each server must be able to query all the servers in the replica list, obtain their synchronization status, and send updates if the server is not synchronized. Transitive synchronization changes this procedure.

A source server checks the replica list and each target server's transitive vector. If the source server's transitive vector is more recent than a target server's vector, the source server does not need to synchronize with that target server. This procedure reduces synchronization traffic.

In addition, the procedure allows changes made on one replica to be synchronized to other replicas through intermediaries. This is a requirement with the introduction of IP support. For example, a server that supports only IP cannot communicate with a server that supports only IPX. The only requirement in a mixed IP and IPX network is that one server in the replica list support both IP and IPX. Figure 1 illustrates the process of synchronizing through an intermediary.

Figure 1: Transitive synchronization on a mixed IPX and IP network.

In Figure 1, Server 1 cannot synchronize directly with Server 3 because they are using different protocols. However, both Server 1 and Server 3 can synchronize with Server 2, which supports both protocols. Server 2 becomes the intermediator. For example, Server 1 sends its updates to Server 2. Server 2 then relays these updates to Server 3 and then updates its transitive vector to indicate that Server 3 has received the updates from Server 1. The next time Server 1 and Server 2 synchronize, Server 1 examines Server 2's transitive vector and then updates its own transitive vector to indicate that Server 3 has been synchronized.

In a mixed NetWare 5 and NetWare 4.x network, NetWare 5 servers automatically detect which servers are NetWare 4 servers and use NetWare 4.x synchronization procedures with them.

Distributed Reference Links

In NetWare 5, distributed reference links (DRLs) replace the back links used in NetWare 4.x. Back links require a server to communicate with every server that contains a read/write replica of the partition that holds the back link. The links are maintained at the server level because back links contain the name of the server.

In NetWare 5, DRLs are maintained at the partition level and contain the distinguished name of the partition rather than a server name. Any read/write replica of the partition can be queried to find out what objects in the partition have DRLs.

For backward compatibility with NetWare 4.x servers, NDS maintains back links with 4.x servers. However, these 4.x servers must be running at least NDS version 599a in a mixed NetWare 4.x and NetWare 5 network.

Schema Enhancements

The NDS base schema in NetWare 5 has added new attributes and one object class. The new object class is Tree Root, which changes containment rules because Tree Root can be the base object of the tree. For backward compatibility, a Country or Organization object can also be the base object of the tree. When NetWare 4.x servers are upgraded to NetWare 5, Tree Root becomes the base object of the tree. This new class in NetWare 5 allows the tree name to be part of the distinguished names of objects in the NDS tree.

Most of the new attributes have been added to support the new core features in NDS such as transitive synchronization and distributed reference links. Others enable password management, bindery restrictions, and guaranteed globally unique IDs (GUIDs).

Inheritance Enhancements

In NetWare 4, NDS blocks the inheritance of rights to specific attributes and always allows the inheritance of rights to all attributes and to objects. NetWare 5 changes this algorithm and allows network supervisors to configure inheritance.

The network supervisor determines whether the rights granted in an ACL are inheritable. The rights bit mask has a new right, Inheritance Control, which determines whether the other rights in the bit mask are inheritable and can apply to subordinate objects.

This new feature allows network supervisors to set up managers who can manage specific attributes, such as phone numbers, addresses, and passwords, without granting Supervisor rights to the objects. If the ACL to a specific attribute is granted at the container level, the right can be inheritable to an entire branch of an NDS tree.

The Password Management attribute was added to the NDS base schema specifically so network supervisors could set up password managers for an entire NDS tree or portions of the tree.

In NetWare 5, the Novell utilities that grant NDS rights are configured so that, by default, ACL inheritance works as it did in NetWare 4.x. However, the Inheritance Control right is displayed and can be set or removed to enable the NetWare 5 features.

Public Key Infrastructure

Novell's implementation of Public Key Infrastructure (PKI) services enables the use of public key cryptography and digital certificates with NetWare services. Of particular importance for NDS, PKI allows administrators to establish a Certificate Authority (CA) management domain within NDS. This enables certificate-based security services such as Secure Socket Layer (SSL) security for LDAP servers.

Novell's implementation of PKI has the following major features:

  • Provides snap-ins to the NetWare Administrator utility for management tasks such as certificate creation, renewal, suspension, and installation

  • Supports public key cryptography that is exportable worldwide

  • Provides secure private key management

  • Supports the X.509v3 digital certificate and PKCS#10 certificate request standards

Programming Interface for NDS

In NetWare 4.x, application developers could access NDS through a set of C-interface functions. These functions were available on the server for NLM applications and on Novell clients for client applications.

Soon after NetWare 4.11 shipped, Novell made LDAP Services for NDS available. This product made the NDS Directory accessible by LDAP-compatible applications, such as Netscape.

In NetWare 5, NDS is accessible through multiple interfaces. Figure 2 illustrates how the old and the new interfaces are related.

Figure 2: NDS interfaces.

For developers who prefer scripting, NDS has the following interfaces:

  • JavaBeans: This interface is a set of high-level abstractions of Java code that are packaged as functional, reusable components that can be run on any platform. The NDS JavaBean allows applications to use NDS for management, authentication, and access control.

  • ActiveX: This interface is used by many visual programming tools such as Visual Basic and Delphi. The first set of ActiveX controls for NDS will allow application developers to log in and out of the NDS tree, to read, write, and modify information in the NDS tree, and to access the NDS schema so that they can create new objects and new attributes for existing objects.

  • ODBC: This interface is a driver that enables SQL to access NDS using visual programming tools such as Visual Basic and Delphi. It allows developers to use standard database utilities for reporting, graphing, and charting NDS information.

  • NetBasic: This interface allows applications to access NDS through a Visual Basic script-compatible language called NetBasic. System administrators, integrators, and resellers can use NetBasic to build custom scripts to handle administrative tasks.

For developers who prefer object-oriented programming, the following interfaces are available:

  • JNDI: The Java Naming and Directory Interface is an addition to the JavaSoft's Enterprise API set and provides an easier way within Java to discover network resources.

  • ADSI: This is the Microsoft interface to directory services. Novell's implementation allows the ADSI APIs to access NDS information.

For C programmers, the following interfaces are available:

  • NDS C Interface: This interface allows access to all the features of NDS: read, write, and modify NDS object and attribute information; schema extensions; and partition and replica management. The functions are available for the development of both NDS client applications and NDS server NLMs.

  • LDAP C Interface: Novell does not provide either a server or client LDAP C interface, but a number of client interfaces are available off the Web for free.

For additional information on, and access to, these interfaces, see the Novell Web site at http://developer.novell.com.

Java Management Utilities

NetWare 5 supports the Java Virtual Machine (JVM) technology and supplies a JVM engine that enables Java applications to run on the server. NetWare 5 also includes the following Java-based utilities: SERVMAN, MONITOR, and RCONSOLE. Because NetWare 5 supports both IPX and IP, RCONSOLE supports both protocols. The IPX version runs only on Windows, but the IP version runs on any platform that supplies a JVM such as UNIX, OS/2, Macintosh, and Windows.

DSDIAG Utility

The DSDIAG utility provides a set of diagnostic tools and reports for different NDS processes. It is included as an NLM for the NetWare operating system. It consists of configuration default options and report-generation options.

The configuration default options allow you to manage the context and identity, which control the diagnostic reports that you want to generate. The context management module allows you to set the input and output context. The input and output context can be set to be the same, or they may be set to be different. The identity parameter is the distinguished name by which you want to be authenticated. Selections can be made to control the identity distinguished name delimiter style (slash, dot, or user defined) to be used in the diagnostic reports.

The report generation module allows you to produce reports on replica ring comparisons, partition status, and NDS versions. DSDIAG has the following options:

  • The Check NDS Background Process Status allows you to check the status of synchronization, obituary processing, external reference synchronization, the Limber process, or all of these processes.

  • The Compare Replica Ring option allows you to compare a replica ring with all other replicas to ensure that they are identical.

  • The List Replica Rings option walks the tree and finds all the replica rings in the Directory.

  • The List Server Partition Table option lists the partition table from a server, which shows all the partition replicas that server holds.

  • The Partition Status option checks the partition replica, the partition creation time, the servers holding replicas of the partition, and the servers' tuned names.

  • The Version option checks the NDS version on all servers in the replica ring.

The results of these diagnostics can be saved to a file (overwritten or appended to) in either text (readable) or data (spread sheet) format, or the report can be output to the screen.

NDS-Enabled Applications and Services

Novell will provide the following NDS-enabled applications and services with NetWare 5:

  • LDAP Services for NDS v3.0

  • NDS Catalog Services

  • WAN Traffic Manager

LDAP Services for NDS

LDAP Services for NDS v3.0 is LDAP v3.0 compliant. This means that LDAP clients can perform a v3.0 bind as described in the LDAP v3.0 specification.

It also means that the Novell implementation understands the v3.0 protocol and can respond to requests that

  • Discover available features (authentication mechanisms, controls, schema)

  • Demand or request controls

  • Support extended requests

In this release, controls and extended requests receive a "this feature is not supported" response. Schema information requests return information about the LDAP schema mappings to the NDS schema.

LDAP v3.0 compliance also means that the Novell implementation supports the following features:

  • Auxiliary classes which, in this release, are limited to the classes required by Netscape and Entrust

  • Modified distinguished name requests that allow users to rename an object or move it to another place in the NDS tree

  • UTF8 support for internationalization

  • Referrals in the v3.0 format

LDAP Services for NDS v3.0 solves the security problems of Novell's first implementation of LDAP. LDAP Services for NDS v1.0 required clear-text passwords to be transmitted across the wire. The Secure Socket Layer (SSL), which is an Internet protocol, establishes and maintains secure communication between SSL-enabled servers and clients. SSL allows a client and server to establish a communication channel that prevents eavesdropping, tampering, and forgery.

Also, in the previous release, all requests were processed on the same thread, which allowed only one LDAP request to be processed at a time. LDAP is now tightly integrated with NDS which allows multiple threads to assume multiple NDS personalities. These features improve performance and allow multiple client requests to be processed in parallel, on multiple server threads.

LDAP Services for NDS v3.0 is integrated with NDS Catalog Services to improve performance on search requests. LDAP is integrated with NDS so that LDAP can use the following resources to fulfill client requests:

  • Local NDS replicas

  • Catalog Services catalog (search only)

  • Remote NDS replicas

Administrators can specify which resources LDAP uses. Restricting LDAP to use only the catalog can strictly limit the data LDAP clients can access. Figure 3 illustrates this process.

Figure 3: LDAP and NDS integration.

The LDAP server can be configured to use only the catalog, only NDS, or either depending on the search request. Figure 1 illustrates the LDAP server examining the request and then sending the request to the catalog or NDS according to its configuration parameters.

The LDAP can only use the catalog for search requests. All other types of requests must go to NDS.

When LDAP is first installed into the NDS tree, LDAP extends the schema by creating three NDS object classes:

  • LDAP Server, which stores LDAP configuration information for the log file, SSL certificate information, status and error messages, and LDAP server information. The LDAP Server object also contains the information required to find the LDAP catalog and the configuration information on how the catalog should be used during LDAP requests.

  • LDAP Group, which maps the LDAP schema objects and attributes to NDS objects and attributes found in the base schema.

  • LDAP Catalog, which stores the catalog and its configuration. LDAP comes with a default configuration of the most likely objects and attributes that are required for LDAP requests. This default configuration may be modified to fit other requirements.

The catalog speeds up LDAP's response to client requests for NDS information because the catalog gathers the NDS information from all remote replicas and stores it locally. All information is also indexed for quicker access except for the few queries where indexing provides no performance gains.

NDS Catalog Services

NDS Catalog Services stores information about NDS objects in a catalog database, which allows administrators to access Directory information without walking the NDS tree. Figure 4 illustrates this process.

Figure 4: NDS Catalog Services and NDS interaction.

Figure 4 illustrates how a catalog client can search the catalog and get information about Object G from one location, the catalog. A similar NDS search would require walking the tree, up through root and down to Partition E.

Figure 4 illustrates the catalog server building the catalog with all known container objects except the catalog server and catalog objects. The catalog can be configured to include any type of object and any or all of its attributes. The advantage of the catalog search over an NDS search is that the catalog information is in one location and has been indexed for faster searches. Also, since the catalog is configured to contain only specific information, a catalog search has fewer items to search through.

NDS Catalog Services provides operations for creating, accessing, and querying the catalog and for extending the NDS schema to store catalog information.

Creating a Catalog

This operation stores a catalog database as a stream attribute of a catalog object in NDS.

The administrator controls which NDS objects and attributes are included in the catalog. These controls use the following:

  • Container Objects: The administrator selects which container objects are the starting points for the catalog. The administrator can choose to have the catalog include only the immediate subordinate objects of the container object or the entire subtree beneath the container object.

  • Filters: An administrator can use filters to specify which object types and attributes to include.

  • NDS Rights: The Catalog object is assigned NDS rights just as any other object, and NDS enforces any assigned restrictions. The Catalog must have Read rights to the objects and attributes that are included in the Catalog. If the Catalog is denied Read rights to objects and attributes, they are skipped and not included.

At set intervals, the NDS catalog builder NLM regenerates the catalog database and updates the Catalog object.

Accessing the Catalog

A user can open a catalog database by accessing the NDS Catalog object that represents that database through catalog query functions. Users access the Catalog object through the normal NDS access control rights. When a catalog is created with the NWADMIN utility, the utility gives the host server Supervisor rights to the Catalog object.

Querying the Catalog

NDS Catalog Services provides a set of catalog query functions that allow developers to write applications that search, retrieve, and sort the information collected in the catalog.

Catalog Service Objects. NDS Catalog Services uses four NDS objects:

  • NCP Server

  • Catalog

  • Master Catalog

  • Slave Catalog

NCP Server Object. The NCP Server object has been modified to include a Catalog List attribute, which stores a list of the catalogs maintained by that server. Because the list is stored on the server, the Catalog Services NLM can access it for use when creating catalog databases.

The Catalog List attribute lists the distinguished names of the catalogs the server maintains. It is a multivalued list of distinguished names.

Catalog Object. The Catalog object is a non-effective class that defines the attributes and object class characteristics that both the Master Catalog and Slave Catalog objects have in common. Both define Catalog Object as their super class.

The Catalog object is a subclass of Top and Resource. The Resource class provides for the Common Name, Description, Location, Department, and Organization attributes.

Master Catalog Object. The Master Catalog object class is an effective class and defines the Catalog object as its super class. It has attributes which store information about the following:

  • The server providing the catalog service.

  • How and when the catalog is to be created and updated.

  • Statistics on when the catalog was created and the number of objects and attributes included.

  • Any associated Slave Catalogs.

Attributes are also used to store the catalog data in the NDS database and to grant rights to do the search through the Security Equals attribute. By making the Master Catalog object security equivalent to another NDS object, the Master Catalog gains access to the same NDS information as the other object.

Slave Catalog Object. The Slave Catalog Object is an effective class and defines the Catalog object as its super class. It has an attribute that allows it to store the distinguished name of its Master Catalog.

The slave catalog contains an exact duplicate of the master catalog. After the catalog builder writes the master catalog, it writes any slave catalogs. Whenever the master catalog is updated, a new copy is written to the slaves.

Slave catalogs can be stored anywhere in the NDS tree and are used to improve performance. For example in Figure 3, partition F might include a slave catalog so that clients in this area do not need to contact partition B to get catalog information.

WAN Traffic Manager

NDS can generate a great deal of wire traffic through synchronization and requests and replies. Over a wide-area network (WAN), such traffic can be expensive and slow the network considerably. WAN Traffic Manager allows administrators to reduce traffic by creating network policies that restrict packet exchanges over the wire. For example, backlink traffic can be limited to off hours to reduce traffic during peak network usage.

WAN Traffic Manager can be accessed by NDS and any other NLM that causes WAN traffic to determine policies that will reduce wire traffic. For example, if a server receives a request to synchronize an NDS replica, it first calls an API provided by WAN Traffic Manager to determine when that traffic should be sent. WAN Traffic Manager responds by returning a message indicating whether the traffic is to be sent or not. Figure 5 illustrates this process.

Figure 5: NDS and WAN Traffic Manager interaction.

WAN Traffic Manager is queried for groups of packets to the same destination, not for each packet individually. WAN Traffic Manager does not enforce policies by preventing communication but provides policies to be followed. These policies are stored in NDS and cached as needed by WAN Traffic Manager.

Policy

A policy is text stored as an attribute on either the Server or the LAN Area entry. Each policy contains two sections: the policy's name and the body of the policy.

The policy's name differentiates that policy from other policies so that it can be edited, deleted, or renamed as needed.

The body of the policy is interpreted according to a simple processing language. The body of the policy is broken into three sections:

  • Declarations

  • Selector

  • Provider

Each of these sections is described below.

Declarations. The declarations section defines all variables other than system variables. Any variable used that is not in this section is considered a syntax error. A variable is defined by giving a usage class, a type, an identifier, and, based on the type, an initial value.

Usage classes can be defined by one of the following keywords:

  • Required: This is a named parameter coming in from a client that must be passed in order for the policy to be processed.

  • Optional: This denotes a parameter that may be passed in from the client.

  • Local: This denotes a variable that is local to the policy. Local variables exist only for a particular policy; that is, their values are not returned to the calling client.

A variable can be a 32-bit integer, a network address (either IP or IPX), or a Boolean value. All variables are given an initial value.

Selector. The selector consists of a statement list that is processed to determine how applicable the given policy is to the request being processed.

The selector portions of all the currently loaded policies are run, and the one returning the greatest weight is selected.

Provider. The provider section also consists of a list of statements, the result of which is a value representing the policy's suggestion to SEND or DONT_SEND. For a given request, only the provider for the selected policy is run. The provider determines the suggestion to be returned to the client.

Loading Policies

The WAN Policy attribute on either the Server object or the LAN Area object contains the policies. When WTM.NLM is loaded on a server, it logs in as the Server object of the local server. The Server object is then read to see if it has a Wan Policy attribute. If one is present, it is read and WTM.NLM loads the policies. The Server object is then checked for a LAN Area Membership attribute, which holds the name of the LAN Area object that the server belongs to. This attribute is single valued: a server can belong to only a single LAN Area. If the server belongs to a LAN Area, the LAN Area object will be read for a WAN Policy attribute. If a WAN Policy attribute is found on the LAN Area, WTM.NLM loads the policies it contains. The policies read from this sequence of events are the set of policies that are checked when a Get Wan Policy request comes in.

* 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