> developer > dnu > courses > beginning eDirectory page 24

eDirectory for the Beginner

February 2002

DeveloperNet University Course

Reader Rating    from ratings

More eDirectory Benefits

iMonitor

iMonitor is a Web-based management tool that you can use to assess the health of your eDirectory tree from any location, equipped with only a Web browser and Internet access. Using NDS iMonitor, you can quickly identify potential problems and troubleshoot them before they become noticeable to your users. iMonitor runs on the same platforms as eDirectory 8.5 (all platforms- NW versions 4.11 or above).

iMonitor only has to be installed on a single server. From there, it can assess the health of the other network servers and return the results to your Web browser. Flexible and versatile, iMonitor frees you from trips to the server room; it gives you the convenient web-based access you need to keep your network running smoothly, regardless of your location.

You can run NDS iMonitor in two ways:

• Typing in the URL of a server running iMonitor, followed by /nds (for example: http://ServerName/nds or http://ipAddress/nds).
  
  
• Through the NetWare Management Portal NLM (PORTAL.NLM). From the Portal screen, you select NDS iMonitor from the NDS Management menu in the left column.
  
  

Figure 23: iMonitor.

Some of the things you can check with iMonitor:

• directory schema, classes and attributes, OIDs
  
  
• known servers
  
  
• known replicas and their state
  
  
• partitions
  
  
• and much much more!
  
  

Federation

In the past, the namespace of an eDirectory tree was whatever the original installer specified. It was an independent, self-contained namespace and did not conform to the Internet standard DNS name format. eDirectory tree federation actually moves toward adopting the DNS naming standard in the directory. Figure 24 shows an example of this concept.

Figure 24: Objects in a federated NDS eDirectory tree can adopt DNS Naming structures.

A DNS-rooted tree is an eDirectory tree installed with a tree name of DNS. The objects in such a tree exist in the DNS namespace, but are managed in the same manner as objects in today's eDirectory tree. The result is that a user in one federated eDirectory tree can be granted rights to access and use objects in another eDirectory tree in the same federation without having to have a copy of his or her user object in the second tree. See Figure 25.

Figure 25: A users in one federated eDirectory tree can be granted rights to access and use objects in anther eDirectory tree in the same federation without copying user object.

Federation of eDirectory trees via DNS requires that entries be made in a DNS server so that other processes can resolve to the tree. One of two types of DNS entries can be used. The preferred method is to add at least one Service Location (SRV) resource record (RR) for the tree's domain in the DNS server servicing the tree's namespace. eDirectory 8.5 uses the service name _ndap which represents the Novell Directory Access Protocol. In our example an SRV record for acme.com might look like this: _ndap._tcp.acme.com IN SRV 0 0 524 trooper.acme.com

This indicates that the server whose internet host name is trooper.acme.com is an NDS server in Acme's tree, and can be connected via TCP port 524.

Once the necessary DNS records are exposed, the DNS-rooted tree is available for federation by any other DNS-rooted tree on the Internet. eDirectory objects may now be referenced from other eDirectory trees.

For example, the eDirectory Group object called MktWebUsers.bizco.com in Bizco's DNS-rooted tree. Assume this group's administrator attempts to add the user jack.acme.com from Acme's DNS-rooted tree into the MktWebUsers group. Once eDirectory at Bizco fails to resolve jack.acme.com in the bizco tree, it requests referrals from DNS (in the form of SRV or ARRs) for acme.com, which it uses to connect to the acme tree and resolve jack. Figure 26 shows this configuration.

Figure 26: The eDirectory Group object called MKTWebUsers.bizco.com in Bizco's DNS-rooted tree.

A reference to the user jack.acme.com is then added as a member of the MktWebUsers.bizco.com group, in much the same manner that a user object from another partition of the Bizco tree would be added to the group. Similarly, if jack is removed from the acme tree, his reference in the MktWebUsers group at bizco will also be removed when the appropriate background processes run as scheduled.

In order to use NDS, your eDirectory installations needs to be a new eDirectory installation, you can't migrate an existing eDirectory tree to DNS at this time.

Also, federation points must be peers, not subordinate of one another.

Filtered Replication

Filtered replication enables you selectively copy and distribute any part of a partition, including objects and their attributes.

They are generated by a replication filter that you create in eDirectory 8.5. Creating the filter is an easy process: you simply select the object classes and attributes that you want the filter to accept. Once the filter is created, you select a partition or set of partitions to filter and determine whether you want either a read-write filtered replica or a read-only filtered replica.

Benefits of filtered replication include:

• reducing the amount of information stored in a particular eDirectory database and being able to tailor the information to a particular audience
  
  
• decreases the size of the database which reduces hardware needs
  
  
• improved performance: improves the speed at which information is accessed
  
  

For example, Credit Card Company XYZ's customer service department has an application that manages customer information. The application runs on a server that receives both real replicas and updates to attributes that are not desired for the application. Because the customer service representatives only need access to account information--not individual credit ratings or credit application criteria--administrators can set up a filter to create a replica that holds only account information.

Public Key Infrastructure (PKI)

Novell PKI Services enables the use of public key cryptography and public key certificates in an eDirectory-enabled network. The Novell Certificate Server API furnishes you with a directory-centered, public key infrastructure to create, manage, and access X.509 certificates. PKI Services also works with most commercial certificate authorities such as VeriSign and with the major certificate authority software, such as Netscape CA Server.

Novell Certificate Server (PKI services) requires the cryptography services of Novell International Cryptographic Infrastructure (NICI) which provides the cryptographic algorithms. NICI availability and cryptography strength is restricted if your network is located in an entity listed on the U.S. Government Restricted Party List or in a country with import controls on cryptography products or technologies.

PKI services is installed during eDirectory installation. It also defines several new objects in the schema, they follow:

Certificate Authority Object.  This object contains the public key, private key, public key certificate, certificate chain, and other configuration information for the eDirectory tree Certificate Authority object. The private key is stored in the Certificate Authority object in encrypted form. Once a server is configured to provide the certificate authority service, it performs that service for the entire eDirectory tree.

Key Material Object.  This object contains the public key, private key, public key certificate, and certificate chain. The private key is stored in the Key Material object in encrypted form. A server can have many Key Material objects. Any security applications running on a particular server that require keying material for their operation can be configured to use any one of the Key Material objects. You can create and place Key Material objects only in the container where the server resides.

Security Container.  This container holds security-related objects for the eDirectory tree, which include the eDirectory tree CA object. The container physically resides at the top of the eDirectory tree.

This API set is provided entirely in the C programming language to provide the best cross-platform support for all platforms integrated with eDirectory. Future versions of the Novell Certificate Server API will offer Java interfaces, as well as support for eDirectory for NT, for Solaris, and other popular varieties of UNIX.

As mentioned, Novell's PKI services supports external certificate authorities. If you decide to use an external certificate authority to sign the certificate, the server with which the Key Material object is associated will generate a CSR that you will need to submit to the external certificate authority. After the certificate is signed and returned to you, you will need to install it into the Key Material object, along with the trusted root for the external certificate authority. This process is depicted in Figure 27.

Figure 27: Novell's PKI services supports external certificate authorities.

1. From the client, send a request to the server to generate a Key Material object using NetWare Administrator.
   
   
2. The server generates a key pair and stores it in a new Key Material object. The server creates a CSR and sends it back to the client.
   
   
3. The CSR is routed to the external CA by e-mail, http, or another similar mechanism.
   
   
4. The external CA validates the request, signs the certificate, and returns the certificate and trusted root to the user by e-mail, http, or another similar mechanism.
   
   
5. The trusted root and public key certificate are stored in the Key Material object using NetWare Administrator.
   
   

When creating a Key Material object with a public key certificate that is signed by the eDirectory tree CA, similar steps as described for the external CA occur, except the entire process is automated.

DirXML

DirXML is a powerful data-sharing and synchronization solution, which automatically distributes new and updated information across every designated application and directory on your network.

DirXML is flexible enough to accommodate any application, database, or directory. DirXML extends the data replication and synchronization capabilities of eDirectory to other data sources, eliminating the isolation of your data among your various applications.

DirXML uses drivers to enable communication between eDirectory and other applications. For example, a DirXML driver allows applications (such as Lotus Notes, Microsoft Exchange, Microsoft Active Directory, or Netscape directories) to share and synchronize data through eDirectory.

These applications can use DirXML drivers to synchronize pertinent data (e.g., user names, titles, phone numbers, IP addresses, etc.) across platforms and networks, significantly reducing application-specific administration costs.

Figure 28: Synchronizes pertinent data across platforms and networks.

The DirXML engine and the DirXML drivers are the key components that implement the publisher and subscriber channels and thus connect eDirectory with the other application.

All data is exchanged in XML (eXtensible Mark-up Language) documents. The DirXML engine translates an eDirectory event into an XML document and uses rules to determine how the modification is sent to the application. The engine (see the Figure 29) uses the following types of rules and style sheets:

Figure 29: Data Path for DirXML.

• Mapping rules which map eDirectory object class names and attribute names with an application's schema names.
  
  
• Matching rules which match an eDirectory entry with an entry in the application.
  
  
• Create rules which place conditions on creating new entries in eDirectory or the application.
  
  
• Placement rules which determine where in the eDirectory or application hierarchy the new entry is created.
  
  
• Style sheets which transform input or output commands into a different command, change an event from one type to another, or perform other arbitrary XML transformations.
  
  

Figure 30: DirXML System Processes.

For more information on DirXML see the DirXML Driver Installation Course and the Custom DirXML Driver Development Course on the DeveloperNet University web site.

Novell Import Convert Export Utility (ICE)

The Novell Import Convert Export utility lets you:

• Import and export LDIF files
  
  
• Import and export comma-delimited data files
  
  
• Migrate data between LDAP servers
  
  

The Novell Import Convert Export is compatible with eDirectory 8.5 or higher. The utility includes two LDAP extension modules that are automatically loaded when the LDAP server starts, and a client utility that runs as a snap-in to ConsoleOne. The utility replaces both the BULKLOAD and ZoneImport utilities included with previous versions of NDS.

What really distinguishes ICE from other vendors' management utilities is its ability to use XML rules to process data. Using these rules, you can migrate data directly between two LDAP servers--no intermediate LDIF conversion is necessary.

You can use the utility as either a command line utility or a graphical utility.

From ConsoleOne: Wizard->NDS Import/Export

Figure 31: Starting up ICE from ConsoleOne.

Using the Command Line Interface

The comma-delimited data handler is a command line utility only. You can use the command line version of the utility to perform the following:

• LDIF imports
  
  
• LDIF exports
  
  
• Comma-delimited data imports
  
  
• Comma-delimited data exports
  
  
• Data migration between LDAP servers
  
  

The utility is installed as part of ConsoleOne. A Win32 version (ICE.EXE), a NetWare version (ICE.NLM), Solaris version (ICE), and Linux version (ICE) are included in the installation.