NDS eDirectory
Articles and Tips: article
01 Jul 2000
Unless you've been living in a cave during the last year, you're familiar with the latest industry buzzword: e-business. In its most elementary definition, e-business refers to the praictice of using Internet technologies to conduct business. For example, e-business includes web-enabling your company's applications and databases. At least part of the point of e-business is to create new or improve existing business relationships--not only with customers, but also with suppliers, partners, and anyone else with whom your company does business.
Given the widespread interest in e-business, you may not have been surprised when Novell released NDS eDirectory last November. After all, NDS eDirectory is ostensibly designed for the e-business market. Of course, if you're inclined to be skeptical, you may wonder whether it is the product or only its name that is designed for the e-business market. Naturally, Novell claims that this new version of its seven-year-old directory service powers not only your Network Operating System (NOS) but also your e-business. But if you're likely to be cynical, you probably question such claims. In other words, if you're the doubting sort, Novell's renaming and repositioning NDS as NDS eDirectory has left you asking the proverbial question, "What's in a name?" A NOS directory service by any other name remains the same, right?
Right. But NDS eDirectory is more than a NOS directory service with a new name. Like NDS 8, NDS eDirectory is based on open Internet standards. However, unlike any previous version of NDS, NDS eDirectory is also a platform-independent directory service. To this underlying change, NDS eDirectory 8.5, the upcoming version of NDS eDirectory, adds several new features, including Domain Naming System (DNS) federation, filtered replication, and a web-based monitoring tool. (For a definition of these terms and other terms in this article, see "Glossary of Terms.") Together, these changes make NDS eDirectory 8.5, which is due to be released this fall, an ideal directory service for e-business. (For more information about what NDS eDirectory can do for your company's e-business, see "Did You Know?")
PICK YOUR PLATFORM
NDS eDirectory might not be such a great e-business tool if it could run only on NetWare. After all, many companies, including yours perhaps, are already using Solaris, Windows NT, or Linux to run their web servers. Incorporating NDS eDirectory--or any e-business directory service or application--into your company's overall e-business strategy isn't even an option if doing so means having to port your company's web site to a new platform. The cost, time, and hassle of such an undertaking are prohibitive. Not surprisingly then, NDS eDirectory is cross-platform and platform independent.
Both of these terms, cross-platform and platform independent, are overused industry jargon, but what do they mean, and what's the difference between them?
Because NDS eDirectory is cross-platform, you can run it on platforms other than NetWare, the operating system for which NDS was originally designed. Specifically, you can run NDS eDirectory 8.5 on the platforms you'd likely find on companies' Internet borders, including the following:
Solaris 2.6 and above
Windows NT 4.0 with Service Pack 4 and above
Windows 2000
Linux (Linux Kernel 2.2.12 or 2.2.15 and Linux GLIBC 2.1.3)
NetWare 5 (with Support Pack 4) and above
In addition, Novell plans to port NDS eDirectory to Tru64 UNIX, which will run on Compaq's new AlphaServer GS series systems. Novell expects NDS eDirectory licenses for the Tru64 UNIX platform to be available in the second half of 2000. (For more information, see the press release posted at http://www.novell.com/press/archive/2000/05/pr00069.html.)
Saying NDS is cross-platform is not terribly new nor, therefore, exciting news. After all, NDS has been cross-platform for most of its product life span. However, prior to NDS eDirectory, NDS was still dependent on NetWare for support systems, as Novell product manager Ed Anderson points out.
For example, Anderson explains, when NDS was merely cross-platform, "if you ran [NDS] on UNIX, you still needed NetWare to perform certain management operations." As a result, you would have to either run NetWare on the same server or at least have a NetWare server somewhere in the same network.
Furthermore, because some of the utilities required to manage NDS were available only on NetWare, you had to complete many administrative tasks from a NetWare server, regardless of your platform preference. In other words, Anderson says, although you could have NDS running on multiple platforms, the master NDS replica had to be on a NetWare server. "So that's cross-platform," Anderson sums up, "but it's not platform independence."
WITH OR WITHOUT NETWARE
Saying that NDS eDirectory is platform independent implies a couple of important points: For one thing (and as you could guess), it implies that NDS is no longer dependent on NetWare in any way. Not only can you run NDS on platforms other than NetWare, but you can also do so without a NetWare server in sight. You don't need NetWare, nor for that matter do you need to know anything about NetWare to use NDS eDirectory.
To make NDS independent from NetWare, Novell created a common source code base that compiles and runs on multiple platforms. This source code is the same, regardless of the platform on which you are running NDS eDirectory. A platform-specific layer of code between the NDS source code and the specific operating system enables NDS eDirectory to run on various platforms.
Because the NDS eDirectory source code is the same across all platforms, communications between NDS servers will work smoothly regardless of the combination of platforms your company is running. For example, NDS eDirectory running on Solaris can share information with NDS eDirectory running on Linux as easily as it can share information with another Solaris server running NDS eDirectory.
If you are planning to take full advantage of NDS eDirectory's cross-platform feature by running NDS eDirectory 8.5 on multiple platforms, you should investigate another Novell product: NDS Corporate Edition. NDS Corporate Edition eliminates the boundaries between separate platforms and enables you to manage these platforms as one Net. That is, NDS Corporate Edition enables you to manage from a single location all user accounts and all resources on each separate platform running NDS eDirectory 8.5. As a result, you can create and manage one user account for each user, and you can grant that user access to whatever resources he or she needs--regardless of the platform on which those resources reside. Without Novell Corporate Edition, you have to separately create and maintain user accounts for each platform running NDS eDirectory 8.5.
NDS Corporate Edition, like NDS eDirectory, is designed to operate independently of NetWare: For example, if you are running a mixed Windows NT/Solaris environment, you can use NDS Corporate Edition to manage both platforms as one Net. (For more information about Novell Corporate Edition, see http://www.novell.com/products/nds/ndscorporateedition.)
ALMOST-NEW LDAP IMPLEMENTATION
In addition to being platform independent, NDS eDirectory supports open Internet standards, including Lightweight Directory Access Protocol (LDAP) 3. NDS eDirectory 8.5 runs LDAP 3 over Secure Sockets Layer (SSL) connections, which use digital certificates based on the X.509 v3 standard. (For more information about Novell's support for X.509 certificates, see http://www.nwconnection.com/past.)
Saying NDS eDirectory supports LDAP 3 is actually an understatement. Like NDS 8 but unlike versions earlier than NDS 8, NDS eDirectory uses LDAP 3 natively. As a result, NDS eDirectory does not use an LDAP 3 gateway to translate LDAP 3 into NDS protocols so it can then consume and process LDAP 3 queries. Rather, NDS eDirectory incorporates the LDAP 3 protocol and therefore consumes and processes LDAP 3 queries using LDAP.
In other words, NDS eDirectory does not need an LDAP 3 gateway because NDS eDirectory speaks and understands LDAP 3. Basically, NDS eDirectory runs both LDAP 3 and NDS protocols (including, of course, the NDS protocols for authentication, server-to-server replication, and dynamic inheritance access control that NDS has used since it began shipping in April 1993).
Among other things, this fact implies that you can access NDS eDirectory by way of NDS client applications, such as the NetWare Administrator (NWADMIN) utility and ConsoleOne, and by way of LDAP 3 applications, such as Novell eGuide.
THIRD-PARTY APP ACCESS
What is perhaps more interesting is that you can also access NDS eDirectory via third-party LDAP 3 applications (preferably those that are Novell Yes, Tested and Approved). Using an LDAP 3 application, you can access information stored in NDS eDirectory without running NetWare client software. For example, you can access NDS eDirectory using Corporate Services Automation Solution (CSA) 3.6 from Oblix Inc. (CSA is a web-based application that allows you to manage and publish information stored in NDS eDirectory via the Internet. For more information about CSA, visit http://www.oblix.com.)
By default, NDS eDirectory communicates with third-party LDAP 3 applications by listening for Protocol Data Unit (PDU) packets on port 389 and port 636 (the port usually used for SSL transmissions). Essentially, NDS eDirectory uses LDAP 3 to pass these PDU requests straight through to the NDS database, which accesses the requested information and then returns that information using LDAP 3.
Of course, these PDU requests often include references to LDAP 3 object classes that are not identical to NDS object classes. NDS eDirectory can understand the LDAP 3 object classes because it includes both an LDAP 3 and NDS schema definition, which, as you would expect, are mapped. (See Figure 1.) For example, NDS eDirectory maps the LDAP 3 InetOrgPerson object class to the NDS User object class. (For more information about how NDS supports LDAP, see "LDAP and NDS: A Relationship You Can Count On," NetWare Connection, Nov. 1999, pp. 18-30. You can download this article from http://www.nwconnection.com/past.)
Figure 1: NDS eDirectory maps LDAP 3 object classes to NDS eDirectory object classes. You can view the mapped object classes by clicking the LDAP group object in the NWADMIN utility or ConsoleOne.
OPEN UP
Natively supporting LDAP 3 also makes it easier for developers to create applications for NDS eDirectory. Developers can still use the NDS software developer kit (SDK), of course, but they can also use Novell LDAP Libraries for C SDK. The Novell LDAP Libraries for C SDK is based on the C libraries from the OpenLDAP Foundation's OpenLDAP Project. (For more information about the OpenLDAP project, see http://www.nwconnection.com/past.)
The Novell LDAP Libraries for C SDK go a long way toward simplifying the development of directory-based applications. Such applications are essential, of course, to the success of NDS eDirectory in the e-business arena. After all, no matter how wonderful NDS eDirectory is, "all of its services are academic," Anderson points out, unless developers can develop applications that make use of those services.
The Novell LDAP Libraries for C SDK should appeal to developers for at least a couple of reasons. For one thing, if developers use this standards-based SDK to write applications for NDS eDirectory, those applications should run on other LDAP directories.
In addition, this SDK makes it simple to access NDS eDirectory's primary functions--that is, "the things people really use directories for," says Anderson. For example, it is far easier to search the NDS database using the LDAP Libraries for C SDK than it is to search the NDS database using the NDS SDK. The NDS SDK includes a rather complex search mechanism that, among other things, requires setting your NDS context, then setting up buffers and iterators, and finally parsing the return information. The LDAP Libraries for C SDK, in contrast, include application programming interfaces (APIs) that "basically enable you to set a search parameter, make a call, and get back your results," says Anderson.
WHEN O=NOVELL MEETS O=NOVELL.COM
In addition to providing native support for LDAP 3, NDS eDirectory 8.5 also offers native support for DNS, the de facto Internet naming standard. As you may know, the naming system that a directory service supports enables that directory service to resolve object names using the rules of that particular naming system. For example, versions of NDS earlier than NDS eDirectory 8.5 use NDS naming standards to resolve object names such as CN=Joe.OU=Admin.OU=RIO.O=PDQ. This name indicates that the user with the common name Joe resides in the Admin Organizational Unit (OU) container, which is in the RIO OU container of the Organization container named PDQ.
Using traditional NDS naming conventions, an NDS tree can resolve only the names of objects located within that tree. In other words, using NDS naming, the PDQ NDS tree cannot locate another NDS tree, say XYZ's tree, let alone objects within XYZ's tree.
In NDS eDirectory 8.5, the DNS and NDS name spaces have been federated (that is, joined or united). As a result, an NDS tree that is based on NDS eDirectory 8.5 can use both the NDS naming system and DNS (depending on how you install the NDS tree). In essence, this DNS federation enables your NDS tree to use DNS when it cannot use the NDS naming system. More specifically, if you set up an NDS tree to support DNS federation, that tree can potentially use DNS to locate other NDS trees.
YOUR ROOTS ARE SHOWING!
NDS eDirectory 8.5 enables you to take the first of what will eventually be several optional approaches to DNS federation. Specifically, NDS eDirectory 8.5 federates the DNS and NDS name spaces when you install a DNS-rooted tree.
A DNS-rooted tree supports the DNS name space by relying on an existing DNS server (for example, a BIND server). You can only make an NDS tree a DNS-rooted tree by installing it as such. (In other words, you cannot currently convert an existing NDS tree into a DNS-rooted tree.) The NDS eDirectory 8.5 installation prompts you to specify how you would like to install the NDS tree, giving you four choices, the gist of which are as follows:
Install a new tree
Install into an existing tree
Install a new DNS-rooted tree
Install into an existing DNS-rooted tree
By supporting the DNS name space, a DNS-rooted tree can find other DNS-rooted trees that are included in its DNS name space. (See Figure 2.) For example, suppose you worked for pdq.com and you got supplies for your company from xyz.com. Further suppose that you installed the pdq.com tree as a DNS-rooted tree and that xyz.com installed its tree as a DNS-rooted tree. Assuming you included xyz.com in your company's DNS name space and xyz.com included pdq.com in its DNS name space, your company's tree could locate the xyz.com tree using DNS, and the xyz.com tree could locate your company's tree also using DNS.
Figure 2: A DNS-rooted tree uses DNS to locate other DNS-rooted trees when resolving names outside of its own name space.
Furthermore, if you were managing pdq.com and had the necessary rights, you could view the xyz.com tree side-by-side with your company's tree using ConsoleOne or the NWADMIN utility. With the pdq.com tree in one view and the xyz.com tree in another view, you could then drag-and-drop User objects from the xyz.com tree to select resources in your tree to grant users rights to these resources.
POTENTIAL SAVINGS
In future versions of NDS eDirectory, you will have the option to set up a DNS-integrated tree. A DNS-integrated tree is a DNS-rooted tree in which you install a directory-enabled DNS server. (Novell plans to make this feature available later this year.) Unlike a DNS-rooted tree, a DNS-integrated tree will be able to use DNS to resolve object names not only to the tree level but also to the individual object level.
Whether you configure an NDS tree as a DNS-rooted tree or a DNS-integrated tree, the potential use of DNS federation for business-to-business purposes is exciting. For example, if you and your business partner both install DNS-rooted trees, you can grant users in your partner's tree rights to objects in your company's tree--without having to create User objects for those users. Likewise, your partner can grant users in your company's tree rights to objects in their tree--also without having to create new User objects.
Being able to grant users from another tree rights to resources within your company's tree without having to create and manage new User objects can save both you and your partner considerable administrative costs. With only one User object per user, rather than one User object per tree, managing User objects--whether they have access to resources in one tree or in ten trees--requires no more administrative time than managing User objects that have access to only one tree.
DISTRIBUTING SELECT PIECES OF THE EDIRECTORY PIE
Of course, before you make portions of your company's NDS tree available to partners (or anyone else) outside your company's network, you must ensure that the information stored in those portions of the tree is correct and current. To do so, you can use Novell's new metadirectory tool, DirXML, also due to be released this summer.
DirXML enables you to synchronize some or all of the information stored in your network and application directories. Essentially, DirXML relies on NDS eDirectory 8.5 as the central information hub. All other directories send (or publish) their changes to NDS eDirectory, receive (or subscribe to) changes made to NDS eDirectory, or both. As a result, when you change a directory that publishes to NDS eDirectory, DirXML can automatically push those changes through to other directories that subscribe to NDS eDirectory. (For more information about DirXML, see http://www.nwconnection.com/past.)
To update the directories running on servers at different locations throughout your company's network, DirXML uses NDS replication. For example, you may want to synchronize the user data in PeopleSoft, Lotus Notes, and NDS eDirectory. In this case, the servers running PeopleSoft and Lotus Notes need to access user profile data, which is typically stored in multiple if not all partitions of an NDS tree. What can you do to ensure these servers have access to the information they need?
If you're using any version of NDS earlier than NDS eDirectory 8.5, you have essentially two equally unattractive options: You can place full replicas of partitions A, B, C, and D on the server running the application that needs only the user profile data, or you can write a distributed application that walks the NDS tree to find the user profile information.
However, as Novell development manager and architect Nick Nikols points out, placing full replicas of four partitions on a server is not "the optimal solution for replication." A distributed application that walks the NDS tree is also prohibitively slow, not to mention difficult to write. "So you're left in a quandary," Nikols says. "What are you going to do?"
THE NEW FILTERED REPLICA TYPE
With NDS eDirectory 8.5, in sharp contrast, your options look considerably better. NDS eDirectory 8.5 includes a new replica type called a filtered replica. A filtered replica, as the name clearly suggests, is a replica of a given partition that holds only select object classes and attributes from a particular partition. The object classes and attributes this filtered replica holds depend, as you can guess, upon the replication filter you create.
You create a replication filter on an NDS eDirectory 8.5 server using the filtered replica or Partition Manager snap-in modules for ConsoleOne or the NWADMIN utility, which are included with NDS eDirectory 8.5. (You can create only one replication filter per server.) Creating this filter is as simple as clicking the object classes and attributes you want this filter to allow to pass. (See Figure 3.) For example, you may select the User object class and a specific subset of attributes, such as first and last names and telephone numbers.
Figure 3: For applications that require access to select information from all parts of your tree, you can store filtered replicas on the servers running those applications. To store a filtered replica on a server, you first create a replication filter for that server by clicking the object classes and attributes you want the filter to allow to pass.
After you have created the replication filter, you select a partition or a set of partitions to which you want to apply this filter. For example, you can select partitions A, B, C, and D. To apply the filter, you first issue an "Add Replica." When you add a replica, as you know, you select from a list the type of replica you want to add. The new snap-in modules add two new replica types to the existing list of replica types from which you can choose: read-write filtered replica and read-only filtered replica.
After you click to add the filtered replica type you want, you're done. The filtered replicas you create preserve the directory structure, but because of the filter, the container objects within that structure hold only User objects and their first and last names and telephone numbers. As you would expect, a filter applies only to the server where you create it and, of course, only to the replicas that you identify as being of the filtered type.
You can have both filtered replicas and full replicas on a server. For example, a server may hold a full read-write replica of Partition A and read-only filtered replicas of partitions B, C, and D.
NDS eDirectory 8.5 servers can apply filters before sending replication events to a server that holds a filtered replica, thereby reducing unwanted replication traffic. However, servers running versions of NDS earlier than NDS eDirectory 8.5 are not aware that the servers holding filtered replicas are any different than servers running full replicas. Consequently, these servers do not apply filters before sending replication events. In this case, the server holding the filtered replica enforces its filter by applying only the changes it receives that pass its replication filter.
Of course, DirXML is not the only application that benefits from the new filtered replica type. Any application that requires only select information from multiple partitions, such as a white pages application, can potentially benefit from filtered replicas. However, only applications (such as DirXML) that use the latest version of the ResolveName and ResolveWithConstraint calls are able to recognize filtered replicas. Applications that do not use these new object resolution calls cannot see filtered views and will instead resolve to full replicas.
The good news is that the LDAP 3 functionality in NDS eDirectory 8.5 uses filtered replicas. Consequently, Anderson notes, all LDAP 3 applications "inherit this capability."
IMONITORING YOUR EDIRECTORY
NDS eDirectory 8.5 also includes a new web-based management tool called NDS iMonitor, which is installed automatically when you install NDS eDirectory 8.5. NDS iMonitor enables you to navigate your company's NDS tree to view and determine the health of its elements, including its partitions, replicas, objects, and servers. You (and anyone else with the appropriate NDS rights) can access NDS iMonitor when it is running on one or more servers on your company's network.
Arguably the best news about NDS iMonitor is how convenient it is to access: You can access NDS iMonitor from anywhere you have access to a standard HTML 3 web browser, namely Netscape Navigator 4.06 or above or Microsoft Internet Explorer 4.0 or above.
The whole point of NDS iMonitor (as its name suggests) is to help you find and troubleshoot problems quickly and effectively and, thus, keep your company's tree healthy, which is no small matter. After all, when you use NDS eDirectory to power business-to-customer applications, the health of your company's NDS tree is particularly important. Your tree's uninterrupted healthy state helps you provide uninterrupted services and, thus, helps ensure that your company's e-business customers are satisfied. And when it comes to keeping your NDS eDirectory tree healthy, "finding and diagnosing problems," says Novell senior software engineer Tom Doman, "is the majority of the battle--and that's where NDS iMonitor is focused."
Perhaps the second best news about NDS iMonitor is that you can use it to monitor virtually any version of NDS. Specifically, NDS iMonitor can monitor the following NDS versions:
All NDS eDirectory versions on any platform (including Linux)
All NDS versions running on NetWare 4.11 or above
All versions of NDS for NT
All versions of NDS for Solaris
To use NDS iMonitor, you need to install the NDS iMonitor software (which is included on the NDS eDirectory 8.5 CD-ROM) on at least one server on your company's network. As you may expect, NDS iMonitor runs on the same platforms that NDS eDirectory 8.5 runs on, namely the following:
Solaris 2.6 and above
Windows NT 4.0 with Service Pack 4 and above
Windows 2000
Linux (Linux Kernel 2.2.12 or 2.2.15 and Linux GLIBC 2.1.3)
NetWare 5 (with Support Pack 4) and above
Regardless of the platform on which it is running, NDS iMonitor supports HTTP 1.0 natively. In fact, NDS iMonitor uses its own HTTP stack on Windows NT, Windows 2000, Solaris, and Linux. On NetWare, NDS iMonitor uses the NetWare HTTP stack (HTTPSTK.NLM). Because NDS iMonitor supports HTTP natively, you do not need to run this tool on top of a web server. On the other hand, if you are running a web server, NDS iMonitor will peacefully coexist with that web server.
You can access NDS iMonitor in one of two ways: You can access NDS iMonitor directly by typing the URL of a server running NDS iMonitor, followed by /nds (for example, http://yourservername/nds). Alternately, you can access NDS iMonitor indirectly by way of the NetWare Management Portal NetWare Loadable Module (PORTAL.NLM). If you are running the NetWare Management Portal, you can type the URL for the Portal server (for example, http://yourservername). From the NetWare Management Portal screen, you then select NDS iMonitor from the NDS Management menu.
The NDS iMonitor screen is divided into three frames: the navigator frame, the assistant frame, and the data frame (See Figure 4.) From within the navigator frame, you navigate your company's NDS tree and then choose from the assistant frame what you would like to do. For example, if you choose the Agent Synchronization Summary, NDS iMonitor returns basic health information about the NDS environment. This information appears in the data frame.
Figure 4: The NDS iMonitor screen is divided into three frames: the navigator, assistance, and data frames. The Agent Synchronization Summary screen shown here reveals a basic health summary of an NDS environment.
Other NDS iMonitor screens are designed to help you diagnose problems. For example, suppose you are viewing the Agent Synchronization Summary screen. If you click either Known Servers List from the menu in the assistant frame or Known Servers from the summary displayed in the data frame, NDS iMonitor returns the Known Servers screen. Under the Status column on the Known Servers screen, NDS iMonitor uses either a green light or a red light to indicate a healthy server or a server with a problem, respectively. (See Figure 5.)
Figure 5: NDS iMonitor uses red lights (as opposed to green lights) to alert you of problems.
When you click on an error, NDS iMonitor takes you to online NDS error documentation that describes the error and gives you possible causes and solutions. NDS iMonitor also provides links to related Technical Information Documents (TIDs) and white papers. In case you are unable to access these links for any reason, NDS iMonitor also ships with a printed copy of the error documentation.
Easily Monitor NDS Servers
As stated earlier, you do not have to run NDS iMonitor on every NDS server to monitor those servers. Because NDS iMonitor has inherent proxy services, you can view information about all of your company's NDS servers by accessing only one NDS iMonitor server.
NDS iMonitor uses traditional NDS protocols to communicate with other servers in your company's NDS tree. NDS iMonitor makes requests to other servers and feeds back the results to the server running NDS iMonitor. In turn, this server returns the results to your browser in HTTP. These inherent proxy capabilities enable you to monitor older versions of NDS and also allow for a single point of dial-in access.
However, you can acquire more information about a server where NDS iMonitor is running than you can about a server that NDS iMonitor merely accesses. If NDS iMonitor is running on a server, you can use all of the NDS iMonitor features including server-centric features, such as the DSTRACE and DSREPAIR utilities. If iMonitor is not running on the server about which you want information, you can use all NDS iMonitor features except server-centric features.
SAME RELIABILITY, SCALABILITY, AND HIGH PERFORMANCE
Despite its new tools and features, NDS eDirectory 8.5 is in many respects the same old NDS--and that's a good thing. Like previous versions of NDS, NDS eDirectory continues to be reliable, due to its distributed, replicated nature, which provides built-in fault tolerance. In addition, NDS eDirectory 8.5 is highly scalable. In fact, an NDS tree based on NDS eDirectory 8.5 can hold as many as one billion objects, as demonstrated at BrainShare 1999, where Novell engineers stored one hundred million objects on each of ten servers running NDS 8. More recently, Novell demonstrated one billion objects running on a single Solaris server, Anderson reports.
Also, like NDS 8, NDS eDirectory 8.5 uses a superior data storage system (formerly code-named SKADS) that enables fast LDAP searches and responses--whether your company's NDS tree includes one hundred or one billion objects. This new storage system has indexing capabilities that enable NDS eDirectory to search for objects by checking a flat index rather than traversing the hierarchical (and thus layered) structure of an NDS tree. This approach compares to finding each instance of a concept in a book by checking a book's index for the appropriate page numbers versus manually searching every page in each chapter of the book.
CONCLUSION
The reliability, scalability, and high performance of NDS eDirectory 8.5 are a good basis for an e-business directory service--but alone are not enough. Thus, Novell changed NDS--made it platform independent, included support for open Internet standards, and added new tools and features--to create a directory service that no longer suits your NOS directory needs alone but now also suits your e-business directory needs.
So what's in a name? In the case of NDS eDirectory, what's in its name is the essence of what it is: an eDirectory for e-business.
Linda Kennard works for Niche Associates, which is located in Sandy, Utah.
Glossary of Terms
Domain Naming System (DNS). A distributed, replicated, data query service used primarily on the Internet for mapping DNS-style hostnames, as in something.com, to IP addresses.
DNS Federation. An NDS eDirectory 8.5 feature that unites the NDS and DNS name spaces. DNS federation enables your company's NDS tree to use a shared DNS name space to resolve the names of NDS trees (and possibly objects, depending on the approach to DNS federation) outside of its own NDS name space.
DNS-Rooted Tree. One of what will in the future be several options for setting up DNS federation. A DNS-rooted tree is an NDS eDirectory 8.5 tree that can use a shared DNS name space to resolve the names of other DNS-rooted trees.
Filtered Replica. A new replica type in NDS eDirectory 8.5 that enables you to store on an NDS server selected object classes and attributes from multiple partitions in an NDS tree. This feature is useful for any application that requires a specific subset of information (such as user profile information) that is typically located in all parts of your company's NDS tree.
Lightweight Directory Access Protocol (LDAP) 3. A relatively simple protocol for updating and searching directories running over TCP/IP.
NDS iMonitor. An NDS eDirectory 8.5 web-based management tool that enables you to use a browser to navigate your company's NDS tree for the purpose of viewing and determining the health of its elements, including partitions, replicas, objects, and servers. You (and anyone else with the appropriate NDS rights) can access NDS iMonitor when it is running on one or more servers on your company's network.
Protocol Data Unit (PDU). A standard method for transporting LDAP messages over TCP/IP.
Secure Sockets Layer (SSL). A standard for enabling encrypted communications between Internet servers and clients.
DID YOU KNOW?
CNN Interactive currently uses NDS eDirectory to store information about the interests and preferences of its millions of worldwide users. (CNN Interactive is responsible for several web sites, including CNN.com, CNNfn.com, and CNNSI.com.) With a directory service to store these digital profiles, CNN Interactive can personalize users' web experience. "NDS eDirectory allows us to tailor content and services to the individual needs of our users," explains Monty Mullig, vice president of CNN Internet Technologies. "We deliver nearly seven billion page views to our web sites each year," Mullig adds, "and NDS [eDirectory] is able to provide the performance to sustain this high volume of traffic." (For more information, read the CNN success story posted at http://www.novell.com/showcase/cnn.html.)
* Originally published in Novell Connection Magazine
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.