Novell is now a part of Micro Focus

NDS Services

Articles and Tips: article

JUDY WILSON
Technical Writer
Novell Products Group

JOHN WILLIAMS
Technical Writer
Novell Products Group

01 Jun 1998


Continuing our series on NDS, this article describes to of the core NDS components: the NDS protocol and the NDS schema. It also includes information regarding support services that allow NDS to be integrated with other network services such as network management and internationalization.

Introduction

This article describes the other two core NDS components (the NDS protocol and the NDS schema) and the supporting services that allow NDS to be integrated with other network services such as network management and internationalization.

NDS consists of the following core components:

  • Objects and object management

  • Distributed database operations

  • Novell Directory Access Protocol

  • Schema

  • Supporting services for internationalization and management

The first two components have been described in previous issues of Novell Developer Notes. (Refer to "NDS Technical Overview" in the April issue, and "NDS Database Operations" in the May issue). This article describes the remaining components and the following NDS-enabled application that are available from Novell's corporate Web site:

  • RADIUS services for NDS

  • LDAP services for NDS

  • NAL (soon to be included as part of the ZENworks product)

  • NDS for NT integration products (Novell Administrator for Windows NT and NDS for NT)

NDS Protocol

The NDS protocol, called the Novell Directory Access Protocol (NDAP), is a wire protocol that allows NDS to service client requests and to send client requests to other NDS servers. NDAP is built on top of NCP. Like NCP, NDAP is a request/reply protocol, but unlike NCP, it is a messaging protocol. Since an NDS request or reply can be larger than a single packet, NDS messages can be fragmented across multiple packets and reassembled by NCP before NCP hands the message to the NDS agent.

NCP is not a transport protocol, and thus relies on other protocols to transport packets on the wire. Since NDAP is built on top of NCP, any transport protocol supported by NCP is automatically supported by NDS protocol. Currently, NCP supports IPX and IPX encapsulated by IP (called NetWare/IP). NetWare 5 will support NCP over IP.

Schema

The NDS schema consists of the set of rules governing the structure of the Directory tree. It defines the objects that can exist in the tree, including how entries can be constructed, which attribute values are permitted, how distinguished names can be built, and other characteristics of use to the Directory itself. These object and attribute rules are specified through a data dictionary that provides a standard set of data types from which objects can be created.

Every object in the Directory belongs to an object class that specifies the attributes that can be associated with the object. All attributes are based on a set of standard attribute types, which in turn are based on standard attribute syntaxes.

The Directory schema controls the structure of individual objects and the relationship among objects in the tree. In controlling this relationship, the schema specifies subordination among object classes.

Object Classes

The set of rules that controls the creation of a particular object type is called an object class. Each object class is defined in terms of attributes (NetWare utilities refer to attributes as properties. Figure 1 illustrates the relationship between the schema and the objects and attributes in the Directory.

Figure 1: Relationship between the schema and the Directory.

The attribute syntaxes define the primary data types for values stored in the Directory. Attribute types are defined from the attribute syntaxes and define the possible attributes an object can have.

Object classes are defined using a subset of the possible attributes and determine the types of objects that can be in the tree. The tree structure rules define how the object classes can be organized and nested in the tree and therefore determine the tree's structure.

The schema dictates the requirements, the limits, and relationships of objects and their attributes. Therefore, it controls what can be created and used in the Directory. It also dictates object containment, or how objects can be placed in the tree and their relationship to each other.

Dynamic Schema

The schema is extensible and dynamic; administrators and developers can define new object classes and attributes in addition to those provided by the base schema. The schema can be extended by modifying or creating new object definitions (attribute or object class) and then adding these new definitions to the base schema.

A schema maintenance utility, Schema Manager, allows administrators to easily modify the NDS operational schema. Schema Manager allows administrators to view, extend, modify, print, compare, and diagnose their NDS schemas. It also provides support for developers and ISVs who need to extend the schema for their applications.

Supporting Services

NDS supporting services use standard interfaces or methods so that NDS can be integrated with other network or operating system services such as internationalization, network management, and auditing.

Internationalization with Unicode

Internationalization is the process that accommodates differences in languages and cultures and allows software to use multiple languages. To make NDS language independent, NDS stores all strings (such as object RDNs, attribute names, and character attribute values) in Unicode format.

Unicode is a 16-bit character code capable of storing over 65,000 characters and therefore capable of storing languages with large character requirements, such as Japanese and Chinese.

NDS supports a Unicode interface that translates the Unicode strings into the code page supported by the local operating system. Most operating systems use code pages to handle the character differences between languages.

Simple Network Management Protocol (SNMP)

SNMP is a public domain protocol which is built on top of TCP/IP and designed to manage network devices manufactured by multiple vendors. NDS has been instrumented to support SNMP and can be configured to interact with the SNMP agent of the host operating system. The SNMP agent of the NetWare operating system can be configured to run over either IPX or IP.

To display the actual data gathered by the SNMP agent, the SNMP agent must be configured to interact with a management system, such as ManageWise.

NDS Event Services

The NDS event services provide a way to monitor the activity of NDS on an individual server. These event services can track local events and some global events. Auditing services can be integrated so that they audit the events produced by the NDS event services.

When specified NDS events occur, a monitoring NLM can examine them and determine what action to take. The event services can notify the NLM during or after the event. Using the event services, an NLM application can register one or more functions to be called when specific events occur. These events stay registered until the NLM application specifically unregisters them.

The event-reporting mechanism consists of two kinds of routines:

  • Event reporter routines allow event information to be reported back to an entity needing that information. These routines report events and optionally the information and results associated with those events, including the event type, size of data, and the actual data.

  • Event consumer routines allow network entities to register and unregister events to be reported. An NLM can use these routines to register a function that will be called when a specific event occurs.

Filtering Event Data. The NDS event services must determine if data it is reporting contains information that the NLM application wants to use. Currently, NDS event services filter at the generic attribute level. While the object names in the Directory are global, the local IDs for entries on individual servers are not. Each object on a server is identified by a local ID (called an entry ID) that is relevant only on that server.

The object's local ID on another server may or may not be the same. Local IDs are also used to identify attributes and object classes. These local IDs also improve reporting speed since comparing two 32-bit IDs is faster than comparing two strings. In most cases, the filter can use local IDs because data structures in the callback's data parameter use IDs rather than names.

Auditing. Auditing allows administrators to audit how network resources are being used. NDS auditing uses the NDS event services. Auditing is managed with the AUDITCON utility. This utility is a client utility that allows an auditor to audit any NDS containers in an NDS tree.

AUDITCON provides the following options:

  • NDS auditing: NDS container auditing (NDS related auditing)

  • Volume auditing: Volume object auditing (file system related)

  • Audit configuration: Audit data file and error recovery configuration

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

  • Generate audit reports: Generated from different audit files

  • External auditing: Record workstation audit records and history

Tracing and Logging. NDS provides tracing and logging features driven by certain NDS events. Tracing and logging can be configured to provide information or to trigger management utilities based on user-defined events. The DSTrace NLM allows administrators to set groups of events that can be traced on the server console, logged to a file, or both. DSTrace uses the NDS event services to register for the events specified by the user and to display the data on the trace screen (or log file) as requested.

DSTrace displays or logs text associated with the events; however, some internal events contain text which cannot be localized, since the text is embedded within DS.NLM itself. These events are used only for internal debug purposes. There is no programming interface to the DSTrace NLM. It provides no accessible APIs.

NDS Management Services

NDS provides several services that allow users and administrators to manage and modify an NDS tree. These tools provide operations for

  • Managing objects and attributes, partitions and replicas, schema object classes and attributes

  • Maintaining the database by repairing it, by logging and tracing operations, and by merging two NDS trees

  • Configuring the database and its operations during installation and afterwards

  • Backing up and restoring NDS data and the NDS database

Management Tools

The management tools provide the operations necessary for the day-to-day management of the NDS tree and include the following:

  • NetWare Administrator-management of objects and their attributes

  • NDS Manager-management of partitions, their replicas, and types

  • Schema Manager-management of object classes and their attributes

These tools run on Windows 95 and Windows NT workstations. The tasks that can be completed depend upon the rights that have been granted to the user or system administrator.

NetWare Administrator

The NetWare Administrator (NWAdmin) is a GUI utility that allows system administrators to manage NDS objects and their attributes. With this utility, administrators can view, create, move, and delete leaf and container objects in the tree. They can modify attribute values and assign rights to objects and their attributes.

The functions that can be performed by the administrators depend on the level of administrative rights given. Most individuals using NWAdmin are administrators with management rights over container objects. Users will usually use this utility only when they need to change their user login script or some other user attribute.

NDS Manager

NDS Manager is a GUI utility that allows system administrators to see and manipulate the structure of their tree. Some operations require management rights to a read/write replica; others require read and write rights to the master replica of a partition.

The major components of this utility are illustrated in Figure 2.

Figure 2: Diagram of NDS Manager features.

This diagram represents a logical view of the software components within NDS Manager. The browser component is the center of activity as it interacts with all other components. The browser is the user's interface to NDS Manager. From the browser, a user activates the other components.

The NDS component provides an interface to the actual NDS system and supplies information for the browser. The replica, server, and print operation components handle requests such as add replica, delete replica, print, and print setup.

The repair component handles displaying replica rings, checking time synchronization information, gathering and displaying NDS synchronization data, and managing repair operations.

The partition component handles requests for viewing a server's partitions, viewing replicas of a partition, creating a new partition, merging two partitions, moving a partition, splitting a partition, and performing partition continuity.

The NDS version component handles requests to update NetWare servers to a newer version of NDS.

Schema Manager

Schema Manager allows the system administrator to maintain and manage the NDS schema. The utility includes operations for browsing, viewing, extending, modifying, printing, comparing, and diagnosing the schema classes and attributes. The utility is provided as an executable and as a DLL snap-in for the NDS Manager and NWAdmin utilities.

The NDS Schema Manager is configurable to display one of two views of the schema:

  • Class view

  • Attribute view

The class view is the default view and allows administrators to browse through the classes with a display of the selected classes' mandatory attributes, optional attributes, class containment, naming attributes, class flags, and class hierarchy (superclasses).

From the class view, you can add (create) new classes or remove classes from the schema, add attributes (mandatory or optional) to a class, compare two schemas, examine schema extensions and statistics, and print selected class or attribute information or print the entire schema.

From the attribute view of the schema, administrators can browse through the attributes. Once they have selected an attribute, they can display the syntax, attribute flags, and classes. From the attribute view, administrators can also create a new attribute definition or delete an attribute.

Configuration Tools

The configuration tools provide operations that are infrequently required and include the following:

  • Install-installation and configuration of NDS when a server is first installed into an NDS tree

  • SET and SERVMAN-configuring of NDS database operations after installation

These tools run on the NetWare server console.

Install Utility

The Install utility is a C-Worthy NLM and is used to install the NetWare operating system. This utility calls the NDS install loadable module which installs NDS onto a server.

Specifically, this tool performs the following tasks on the first server in the NDS tree:

  • Creates a master root partition for the tree

  • Installs the Directory Information Base (DIB)

  • Creates the Admin user for the tree with a user-defined password

  • Sets up the bindery context for bindery services

  • Configures the server as a reference time server

Subsequent servers installed into the tree are installed, by default, as secondary time servers. The second two servers, after the first server is installed in the tree, automatically receive replicas of the [Root] partition. All other servers must be manually configured to hold replicas of partitions.

SET and SERVMAN

SET is a console command and SERVMAN is a C-Worthy NLM. Both configure the following NDS features:

  • Version management-allows the administrator to list the NDS version that the NDS tree will synchronize with

  • Bindery context-allows the administrator to specify which containers can be used for bindery logins

  • Synchronization parameters-allows the administrator to specify intervals for the following synchronization processes: replica heartbeat, janitor, back link

  • External references-allows administrators to specify the life span of unused external references

Maintenance Tools

The maintenance tools provide the operations necessary for repairing and troubleshooting the NDS database. They include the following:

  • DSMerge- merges two NDS trees

  • DSRepair- repairs the NDS database and local replicas

  • DSTrace- logs and traces NDS operations

These tools run on the NetWare server console.

DSMerge

The DSMerge utility allows administrators to merge NDS trees. It is implemented as an NLM and is written with the C-Worthy user interface using the nwsnut.nlm library module. This library module is autoloaded when DSMerge is loaded on the server.

DSMerge provides the following NDS operations:

  • Checks the status of the servers in the NDS tree

  • Checks time synchronization on the servers in the tree

  • Renames the NDS tree

  • Merges a source NDS tree into a target NDS tree

To check server status or time synchronization, you must load DSMerge on a server containing a replica of the source tree's [Root] partition. To merge two NDS trees or to rename an NDS tree, you must load DSMerge on the server that holds the master replica of the source tree's [Root] partition.

Checking Servers. This operation verifies the status and the NDS version of each server in the local NDS tree. This operation should be selected before renaming an NDS tree or merging two trees to ensure that all servers involved have the correct tree name. The operation should be selected after renaming a tree or merging two trees to verify that all servers have received and accepted the new tree name.

This operation performs the following steps:

  1. Ensures that the current server holds a replica of the [Root] partition.

  2. Attempts to find all servers in the tree and creates an array.

  3. Contacts each server in the array to obtain the server name, the tree name, and the NDS version and build number.

  4. Builds a list of servers and displays the list with the server's distinguished name, NDS version and build number, and the status of the server.

Checking Time Synchronization. This operation checks and displays all servers in the tree along with their time server type and time synchronization status. This operation should be selected before merging two trees to ensure that all servers in both trees are synchronized and that they refer to the same time source.

This operation performs the following steps:

  1. Ensures that the local server holds a replica of the [Root] partition.

  2. Attempts to find all servers in the tree.

  3. Contacts each server to obtain the server name, the NDS version and build number, and the time synchronization information. This information includes what the server claims its time synchronization status is as well as a time delta, which is the difference between the time on the local server running DSMerge and the server you are getting the time information from.

  4. Builds a list of servers and displays the list with the server's distinguished name, time server type, synchronization status, and time delta.

Renaming the Tree. This operation allows the administrator to rename the local tree. DSMerge must be loaded on the server that holds the master replica of the source tree's [Root] partition.

This operation performs the following steps:

  1. Validates that the tree name can be changed by ensuring that the server contains the Master [Root] partition, that the proposed name is a valid tree name, and that the tree name does not exist on the network.

  2. Initiates the rename process by attempting to find all servers in the tree and their addresses, changing the name on the local server, and sending a tree name change request to all servers it found.

  3. Completes the process by starting a background synchronization process.

Merging Two Trees. This operation merges two NDS trees so that the source tree becomes part of the target tree. DSMerge must be loaded on the server that holds the master replica of the source tree's [Root] partition.

This operation performs the following steps:

  1. Checks that the merge can take place by performing the following operations:

    1. Ensures that the server contains the master [Root] partition and that the database on the local server is open

    2. Logs in as Admin on the source and target servers

    3. Verifies that the two trees have the same version of NDS, have the same time, and use the same schema

    4. Checks that all servers in the source tree and target tree with replicas of the [Root] partition are available

  2. Initiates the merge process by removing all replicas of the [Root] partition from the source tree servers and splitting all container objects subordinate to the [Root] partition into separate partitions.

  3. Merges the trees by performing the following operations:

    1. Sets up server-to-server communication and tree browsing

    2. Modifies the [Root] object of the source tree so that it becomes a subordinate container to the [Root] container on the target tree

    3. Changes the tree name of the [Root] object of the source tree to the tree name of the target tree

  4. Completes the process by sending a tree name change request to all servers in the source tree and scheduling the following synchronization processes: replica, janitor, back link, and flat cleaner.

DSRepair

The DSRepair utility allows system administrators to analyze and fix anomalies in an NDS tree. The scope of DSRepair is primarily limited to the server on which DSRepair is running; however, in some instances, remote repairs can be done. The utility is implemented as an NLM and is written with the C-Worthy user interface using the nwsnut.nlm library module. This library module is autoloaded when DSRepair is loaded on the server.

DSRepair can be loaded on any server in the NDS tree. It provides the following primary operations:

  • Unattended full repair

  • Time synchronization

  • Replica synchronization

  • Log file viewing and configuring

  • Advanced options

Unattended Full Repair. This option automatically performs all possible repair operations that do not require operator assistance. The log file records all actions during this repair. During the repair, the local NDS database is locked until the repair is completed. When it is finished, DSRepair unlocks the database and performs the following repair procedures:

  • Repairs all network addresses

  • Verifies all remote server IDs

  • Repairs all replicas

The advanced options allow you to select these procedures individually and configure their operations.

Time Synchronization. This operation contacts every server known to the local server's database and requests information about the server's NDS version, replica depth, time synchronization, and server status. This information is displayed on the screen and written to the log file.

Replica Synchronization. This operation synchronizes all partitions that have a replica stored on the local server. For each replica stored on the server, the operation contacts each server in the replica ring and requests that the server synchronize with every other server in the replica ring. If DSRepair finds any errors, they are displayed on the screen and written to the log file.

Log File Viewing and Configuring. This option allows you to view the log file, which contains the results of the operations performed by the utility. The default location for the dsrepair.log file is the sys:\system directory. The log file becomes active whenever DSRepair is loaded. The information from each operation selected is appended to the file. Advance Repair Options has options to turn off logging and to delete the file.

Advance Options. These options allow system administrators to perform the following tasks:

  • Configure log file operations

  • Control how the local NDS database files are repaired

  • Display a list of servers known to the local NDS database

  • Display a list of remote server IDs and verify them

  • Display a list of replicas on the local server and perform the following replica operations: view, synchronize, repair, and remove

  • Synchronize security equivalence attributes

  • Verify that all servers in the NDS tree contain the same NDS schema

  • Copy the NDS database files to a NetWare volume in compressed format for off-line diagnostics

DSTrace Utility

The DSTrace utility is a SET command that allows system administrators to analyze NDS and see how it is functioning. It has commands for the following operations:

  • Turn on or off the display of NDS messages on the DSTRACE screen

  • Log NDS messages to a file

  • Reset the log file to be overwritten by new information

  • Display all NDS debug messages

  • Select a group or groups of messages for display such as replica synchronization or schema synchronization

  • Set synchronization processes to run as soon as possible

  • Configure the synchronization processes to run at new intervals

  • Display tunable parameters and their current values

Directory TSA (Backup/Restore)

Novell's Storage Management Services (SMS) modules provide effective backup and restore capabilities for NDS.

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 NDS TSA backs up the NDS schema and the NDS replicas.

The NDS TSAs back up and restore all extensions to the NDS schema. All objects those defined by both the base schema and the extended schema are sent to the backup program to be backed up. 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 the TSAs can't find a replica containing necessary information, they store the names of unavailable objects in a log file and continue to back up as much of your NDS tree as possible rather than reporting an error and stopping the backup process.

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 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.

NDS-Enabled Applications and Services

In addition to the features provided by NDS, applications can be built on top of NDS and use NDS to provide their services. Novell provides the following NDS-enabled services:

  • RADIUS Services for NDS

  • LDAP Services for NDS

  • NAL (soon to be included as part of the ZENworks product)

  • NDS and NT integration products (Novell Administrator for Windows NT and NDS for NT)

These applications are currently available for downloading from Novell's corporate Web site.

RADIUS Services for NDS

Remote Authentication Dial-In User Service (RADIUS) is an emerging Internet standard that has been adopted by Novell and many leading dial-in and router hardware vendors. RADIUS Services for NDS extends the role of NDS by allowing administrators to consolidate their dial-access user database with their NDS 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.

RADIUS Services for NDS supports network access servers from multiple vendors. This feature allows customers to buy any RADIUS-compliant network access server that will work with the network access servers they already have and any they might want to buy.

RADIUS Services for NDS provides the following benefits:

  • Single sign on. A user logs in once and can access all assigned resources without entering other passwords. If the user has access to more than one network access server, NDS authenticates the user in the background without prompting for the password again.

  • Single point administration. Since RADIUS users are NDS users, the same tool, NetWare Administrator, can be used to manage the users and their NDS and RADIUS information. Without RADIUS Services for NDS, each network access server requires its own database of users, and this database is typically a text file edited with a text editor.

  • Reliability. RADIUS Services for NDS allows for multiple remote-access servers. One is configured as the Primary RADIUS server, and any number as backup servers. With this redundancy, users should always have access to a RADIUS server. Also, since the NDS database can be distributed and replicated across multiple servers, users should always have access to a replica with their login information.

LDAP Services for NDS

LDAP Services for NDS allow applications that use the Lightweight Directory Access Protocol (LDAP) to access data in the NDS database. When an LDAP client sends a request from an LDAP application, NDS completes the request for only the attributes which the LDAP client has the appropriate access rights.

Authentication

Currently, LDAP Services for NDS supports three types of authentication:

  • Anonymous bind. This type of authentication does not require a username or password. The LDAP user has the equivalent rights of the NDS [Public] user. Default rights assignments allow [Public] to browse the names of all objects in the NDS tree, but without additional rights assignments, [Public] cannot view any attribute information.

  • Proxy user anonymous bind. This type allows authentication with an NDS username, but no password can be required. For LDAP, this is an anonymous bind which enforces the password restriction. For NDS, the user is an NDS object that can be assigned additional rights just as any other NDS object.

  • NDS user bind. This type allows LDAP clients to authenticate to NDS using their NDS usernames and passwords. Since passwords are sent as clear text on the wire, they can be captured and used to access the NDS tree unless you use security features which filter IP addresses.

Since passwords are not secure in this implementation, using one of the anonymous binds is the preferred mode of authentication. In the next release, this security problem will be resolved.

NDS and LDAP Schemas

The LDAP schema (based on X.500) and the NDS schema (X.500-compatible) are mapped to correspond to each other, allowing an LDAP client to browse the NDS directory. LDAP administrators can configure the mapping between these two schemas.

The LDAP schema supports only a subset of the available NDS syntaxes, attributes, and object classes. Containment of object classes in LDAP corresponds to the containment of the NDS classes to which the LDAP classes map. The NDS schema does not currently include all LDAP schema classes and attributes.

LDAP ACLs

LDAP Services for NDS provides ACLs that extend the functionality of the NDS ACLs. These ACLs allow you to do the following:

  • Restrict access using such properties as IP addresses or a range of IP addresses

  • Reduce NDS access traffic by not forwarding NDS connection requests that are rejected by the IP address restrictions

  • Allow objects to inherit attribute rights from containers

LDAP Software Modules

LDAP Services for NDS uses a setup program on a Windows 95 or Windows NT machine for installation. This setup program performs the following tasks:

  • Installs a configuration file in the sys:\etc directory

  • Installs a snap-in to the NetWare Administrator tool that allows the system administrator to configure LDAP Services for NDS

  • Expands the NDS schema to include LDAP configuration objects

  • Creates two LDAP objects (LDAP Server and LDAP Group)

LDAP Services for NDS relies on the TCP/IP sockets interface, but it also runs on the WinSock interface to Windows NT.

NAL

Novell Application Launcher (NAL) uses NDS to provide fast and efficient software distribution and application management for the network. As you install the application on the server or servers, you use a NAL tool to profile the application or configuration process. You then use a snap-in to NetWare Administrator to configure how you want the application distributed and how you want the application run from the user's desktop. The last step is to associate the users with the application so that they can access it.

This process allows you to distribute software without visiting each workstation on the network and enforce simplified, standard desktops for your users.

NAL uses NDS to provide the following services:

  • Simplified user access to applications. Since access is tied to NDS User objects rather than the users' workstations, wherever they log in from on the network from their office, a colleague's office, or a remote site they have access to the same applications.

  • Easy management of user access to applications. Since NAL uses NDS for access rights, you can use any of the management features of NDS to grant access rights. You can assign rights to individual users, to groups of users, or to containers with their users. As users change jobs or new users are added, you can add them to the appropriate groups or containers to give them access to the applications they need.

  • Flexible distribution policies. NAL can be configured to install the application on the user's workstation and dynamically update it when patches or new versions are available. NAL can also be configured so that the user runs the application from the server.

  • Protection from user errors. If the users are running the application from the server, users cannot accidentally delete application files or configuration files because NDS security protects these files. If the user is running the application from the workstation, NAL can be configured to reinstall them.

  • Location independence. Since NDS stores where the application is located rather than the user, the location can change without any reconfiguration on the user's part.

  • Simplified distribution of software updates and new applications.

The next version of NAL will be part of the ZENworks product that includes

  • Workstation Manager. This application allows network administrators to use NDS to track hardware, to dynamically distribute and update print drivers, to centralize and manage user profiles, and to view and update client workstation configurations from NDS rather than from each individual workstation.

  • NAL. This version allows network administrators to use NAL to grant file rights to both NDS and NT users. It also allows network administrators to use time limits to restrict access to applications.

  • Workstation Maintenance. These applications use NDS so maintenance personnel can authenticate and remotely control a workstation, so network administrators can set up policies that help users supply pertinent information about themselves and their workstation to the help desk, and so network administrators can set up policies for importing workstation information into NDS.

NDS and NT Integration Products

Novell provides two products to integrate NT application servers with NDS:

  • Novell Administrator for Windows NT

  • NDS for NT

Each is briefly described below. For more information, see Novell's Web site at http://www.novell.com.

Novell Administrator for Windows NT

This product gives network managers a single, centralized point of administration for users and groups in a mixed NetWare and Windows NT environment. It allows user information to be created and maintained in NDS and synchronized automatically with the NT domain.

User accounts are automatically granted access rights as "Domain users." If the NT server is set up to allow "Domain user" group members the right to access a common area where applications are located, the users automatically inherit the rights to use the applications. Network managers can grant access to restricted applications by creating a group for these selected users.

Users are given a single-login view of the network because the Novell Administrator for Windows NT synchronizes user passwords. This simplifies network access for those users that need both NT and NDS services, increases productivity, and reduces calls to the help desk.

NDS for NT

This product eliminates the need to synchronize the domain information with NDS by actually storing the domain information as NDS data. NT management is done through a snap-in for the NetWare Administrator utility.

NDS for NT provides an installation process which moves the domain data into the NDS directory where it can be maintained using standard NDS tools. NDS can be used to grant users access to NT servers throughout the network without the need for "trusted links." Each user needs only one User object, and this User object can be assigned access to network resources on both NetWare and NT servers. It also means that the user needs to log in only once, to the NDS tree, rather than twice once to the NT operating system and once to the NetWare operating system.

When any user or application seeks domain information, the NDS for NT product transparently provides the data from the secure, replicated NDS database.

* 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