Novell is now a part of Micro Focus

NDS Technical Overview: Novell Layered Services

Articles and Tips: article

JOHN WILLIAMS
Technical Writer
Internet/Intranet Division

NANCY CROSSEN
Technical Writer
Internet/Intranet Division

SELBY HERRIN
Software Engineer
Internet/Intranet Division

01 Aug 1997


Describes the following services, which can be layered on top of NDS: Directory TSA, Catalog Services, WAN Traffic Management Services, RADIUS server, Auditing.

Introduction

This is the third in a series of articles on NDS. For more information, see "Overview of NDS," (March, 1997, p. 42) and "Overview of NDS Scale" (April, 1997, p. 15).

In addition to the features provided by the NDS and ScalePack products, several other services can be layered on top of Novell Directory Services and are available at additional price. These layered services include:

  • Directory TSA (backup and restore)

  • Catalog Services

  • WAN Traffic Management Services

  • RADIUS server

  • Auditing

Directory TSA (Backup/Restore)

Novell's Storage Management Services (SMS) modules provide effective backup and restore capabilities for Novell Directory Services (NDS), as well as efficient server recovery after a failure.

The Target Service Agents (TSAs) have been enhanced to simplify backup and restore procedures. To use the Target Service Agents, you simply install the TSAs, and any SMS-compatible backup program can take advantage of the functionality they provide. The SMS file system TSAs are designed to facilitate server recovery from a server or SYS volume failure by preserving trustee rights assignments, ownership information, and other NetWare attributes.

There are two ways to back up the server-specific information. The first way is to select "Server Specific Info" from the Resource list when doing a file system backup. The second way is to simply select a full file system backup of the entire NetWare server-the server-specific information is included by default. When "Server Specific Info" is restored, the server specific files are placed by default in a subdirectory of SYS:SYSTEM on the target server. The subdirectory name is derived from the source server name (the server that was backed up).

The TSAs back up and restore all extensions to the NDS schema. All objects-those defined by both native and extended schema-are sent to the backup program for backup. The resulting backup contains the information for objects defined in an extended schema, as well as the extended schema that defined those objects. The extensions to the NDS schema are backed up and restored by default.

If you have partitioned your NDS database, the TSAs will probably have to access more than one server to build a complete picture of your NDS tree. When unable to find a replica containing necessary information, rather than reporting an error and stopping the backup process, the TSAs store the names of unavailable objects in a log file and continue to back up as much of your NDS tree as possible. Because the backup process does not stop, you will have a complete backup of all the portions of your tree that were available when you made the backup.

If a problem occurs and the backup is incomplete, the error log will be displayed. You can then use this information to correct any network errors, such as an unavailable WAN link, or any procedural problems, such as a local administrator who needs additional rights to the tree.

For the best protection of your NDS data, you should perform a full Directory backup, which backs up the NDS schema and all containers in the tree starting with the [Root] container. However, at times you might prefer to begin backing up NDS from a container other than [Root].

When backing up a portion of the NDS tree, a local administrator must tell the backup program where to begin the backup. The administrator can specify the starting container either by browsing the tree and finding the appropriate container, or by typing the container's complete name.

To make it easier to back up portions of the NDS tree, a configuration file is provided, which allows you to specify the names of containers where you want backups to begin. When a local administrator chooses to back up NDS, the TSAs read the configuration file and present the containers listed in the file as additional backup options.

The configuration file eliminates the need for a local backup administrator to have the Supervisor right to the entire NDS tree. It can also be useful if the starting container is several levels down below the [Root] container, or if the starting container's name is long. If the starting container's name is included in the configuration file, the local administrator can quickly choose the starting container from a list instead of having to browse the tree or type the complete name.

The current NetWare release of SMS includes a new TSA for Windows 95 workstations. This TSA enables you to back up and restore information from workstations running Windows 95 and Novell's NetWare Client 32 for Windows 95. Also included is the TSA for Macintosh clients that enables you to back up and restore workstations running the Macintosh operating system and MacIPX, part of the NetWare Client for Macintosh.

Catalog Services

Catalog Services stores information about Novell Directory Services objects in a catalog database, which allows administrators to access Directory information without walking the NDS tree.

Creating a Catalog

This operation stores a catalog database on the server in the SYS:\catalog subdirectory or a user-specified directory and file. The user creating the catalog must have sufficient rights to the server on which it will be stored.

The contents included in a catalog database at creation depend on their context in the Directory. If the context is the [Root] object, the catalog is created for the entire tree; if the context is a particular container, the catalog is generated only for that container's subordinate objects.

At set intervals, the Catalog Services 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. Each Catalog object gives the host server Supervisor rights to the Catalog object. Users access the Catalog object through the normal NDS access control rights.

Catalog Service Objects

Catalog Services uses two NDS objects:

  • The NCP Server object

  • The Catalog object

NCP Server Object. The NDS NCP Server object has been modified to include a Catalog List attribute, which stores a linked 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 a catalog database. The Catalog List attribute lists the Distinguished Names of the catalogs stored on the server. It is a multivalued list of Typed Name structures containing a pointer to the Distinguished Name and an identifier.

Catalog Object. The Catalog object is a subclass of Top and Resource. The Resource class provides for the Common Name, Description, Location, Department, and Organization attributes. The Catalog object class stores information about the server providing the catalog service and information about how and when the catalog is to be created and updated.

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. NDS WAN Traffic Manager NLM (WANMAN.NLM) can help reduce traffic by determining which network policies will reduce packet exchanges over the wire. Currently, WAN Traffic Manager is available only on NetWare.

WANMAN.NLM can be accessed by NDS and any other NLM that causes WAN traffic to determine policies that will reduce wire traffic. For example, if NDS needs to synchronize a replica, it first calls an API provided by WANMAN to determine when that traffic should be sent. WANMAN is queried for groups of packets to the same destination, not for each packet individually. WANMAN does not enforce policies by preventing communication but provides policies to be followed. These policies are stored in NDS and cached as needed in WANMAN.

Policy

A policy is text stored as an attribute on the Server or the LAN Area entries. In the name base, the attribute is stored as a list of sublists where each sublist makes up an individual policy. The first node in the list contains the name of the policy. The second node in the list will contain the text making up the body of the policy. The body of the policy will be interpreted according to a simple processing language.

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

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 Class. Usage classes can be defined by one of the following keywords:


Keyword
Definition

Required

A named parameter coming in from a client that must be passed in order for the policy to be processed.

Optional

Thisdenotes a parameter that may be passed in from the client.

Local

Thisdenotes a variable that is local to the policy.

System

This usage class is specified, but is not available to users. It is used for system variablesthat are put in the symbol table.

Type. The type specified determines the initial value given to a variable.

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

Policy load order is not guaranteed, so if you have policies that continue to collide, you may use one one time and the other the next time.

The selector portion of all the currently loaded policies are run, and the one returning the greatest weight is considered to be selected. As a side effect, named parameters may be manipulated within the selector or provider. Named parameters used in the policy have their values copied from the symbol table back into the block of named parameters passed in.

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.

Named parameters may be manipulated within the selector or provider. The parameters used in the policy have their values copied from the symbol table back into the block of named parameters passed in.

Loading Policies. The Wan Policy attribute on the Server object or the LAN Area object contain the policies. When the WANMAN.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 the policies loaded by WANMAN.

The server 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 may only belong to 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 the policies it contains are loaded by WANMAN. The policies read from this sequence of events are the set of policies that are checked when a GetWanPolicy request comes in.

A policy is loaded by parsing the policy body according to the processing language. This generates a symbol table and expression trees for the selector and provider. The results are held as a node in a policy list and the text of the policy is freed. This list of cached policies is used until either a refresh interval is encountered or a refresh immediate is issued from the console. If either of these two things occur the cached list is released and a new list generated by repeating the process above.

RADIUS Server

The NDS RADIUS Server extends the role of Novell Directory Services by allowing administrators to consolidate their dial-access user database with their NetWare user database, enabling a single point of user administration for these two services. In addition, the distribution, replication, and administration benefits of NDS become available to dial-access administrators.

The NDS RADIUS Server supports network access servers from multiple vendors. This feature allows customers to buy one type of RADIUS server that will work with all the network access servers they already have and any they might want to buy.

The NDS RADIUS Server is provided as a free service to all NDS users. The RADIUS server uses existing tools (NWADMIN) and directory objects to manage network access server users.

NDS RADIUS Server Benefits

The NDS RADIUS server provides the following benefits:

  • Provides a single administration and authentication solution for multiple network access servers

  • Provides a single administration tool (NWADMIN) for all services, allowing RADIUS Server administrators to benefit from an easy-to-use single point of user administration for both RADIUS and NDS services.

  • Uses a standard directory (NDS) that may already be installed or may be extended for other network services such as file, print, and internet (LDAP) directory communications.

  • NDS Directory distribution and replication simplifies administration of a distributed RADIUS service, increasing reliability and enabling effective WAN traffic management. It also minimizes data redundancy between that required for the RADIUS server and that required for NDS.

  • Provides the ability to administer users as a group

  • Supports RADIUS-compliant products from any vendor and enables use of a heterogeneous set of network access servers. Users use the same name and password to access any network access server to which they have rights.

  • NetWare foundation improves reliability when disk duplexing, disk mirroring, or NetWare 4.1 SFT III is used.

Single Database for the NAS

When client workstations dial a RADIUS compatible network access server (NAS), the NAS passes the username and password to the RADIUS server, which authenticates or rejects the request. The advantage of a RADIUS server is that the single database in the RADIUS server is used for all network access servers. The alternative is to have a database in each NAS, which would most likely contain redundant data.

Existing RADIUS solutions, require administrators to maintain a RADIUS dial-user database, which is typically a text file on a UNIX system. The primary administration tool is a text editor.

Auditing

NDS auditing allows administrators to audit how network resources are being used. Specifically, an administrator can use two types of NDS auditing:

  • NDS container auditing to audit NDS-related transactions

  • Volume auditing toaudit server related activities.

NDS auditing also allows an auditor to view, generate reports, and maintain and configure audit data files on different NDS trees and different volumes. This utility supports multiple trees and any new NDS events added to later versions of NDS in addition to the functionalities provided in AUDITCON. Available options are:

  • Novell Directory Services auditing: NDS container auditing (NDS-related auditing)

  • Volume auditing: Volumeobject auditing (file-system related auditing)

  • Auditing configuration: Audit data file and error recovery configuration

  • Audit files maintenance: Audit file and audit history files maintenance

  • Auditing reports generating: Auditing report generated from different audit files

  • External Auditing: Record W/S for events for auditing

Currently, auditing is available on NetWare.

* 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