To view the Report card.
The third criterion is how well the directory provides bidirectional services, both at t
he operational and managerial levels. For example, it's not enough for a system to show you print queues; users also should be able to print to them--and you should be able to manage them--without having to load additional software. Although these services are typically provided by application gateways or the underlying NOS, without them the directory itself is useless.
Finally, in the unlikely event that multiple products offer the exact set of capabilities you require, you'll want to examine the architecture of the directory itself. Some of the limitations to watch for: Does the directory architecture support any industry standards, such as the Lightweight Directory Access Protocol (LDAP) or X.500, or directory gateways, so you can publish your directory for outsiders to see? What kind of limits can you set on that access?
Tracking Resources
Suppose
you want a unified directory that defines workstation access filters for client logins. First, you'll need to define the workstations on your ne
twork, then the servers that will be logged into and the users who will log into them. These three levels of resources--physical devices, network services and users--are the fundamental building blocks of the network; without them you cannot implement any reasonable enterprisewide directory or any other services that depend on consistent management of this information.
At the physical level, you face myriad details that must be tracked. You will have hardware addresses for systems on your network, protocol-specific addresses, and the details that go along with each of the specific protocols--such as IP route, Domain Name Service (DNS) server, AppleTalk zone and NetBIOS domain. Although products exist that do this already, they keep this information in their own databases, which doesn't do you any good at all.
By contrast, having a directory that stores information about the devices on your network means services, such as those independent-minded asset-tracking programs, could use it as a repository. Oth
er services, like the NOS login security system, also could take advantage of it. Unfortunately, most directories lack these resource-management mechanisms, forcing administrators to manage this duplicated information in multiple instances.
By design, NIS+ lets administrators track the devices on a network--but only those devices running TCP/IP. SunSoft's SolarNet PC-Admin, an add-on product, can manage the IP addresses of those devices, but its support is similarly limited to those systems running only PC-Admin client software. PC-Admin is actually a comprehensive product, providing a tremendous amount of functionality to the PC-Admin clients that can use it.
DSS automatically collects information about Distributed Computing Environment (DCE)-based systems, but it does not manage the transport protocols underneath the DCE services. Since DCE is protocol-independen
t, it leaves management of the underlying protocols to tools specific to them. Consequently, it doesn't make for a strong resource-managemen
t platform, even though additional IBM Warp Server products provide integrated DNS-Dynamic Host Configuration Protocol (DHCP) management tools that solve the problem for IP systems interoperating with IBM's directory tools. Additionally, some vendors sell remote DCE configuration tools to manage the DCE-specific configuration information on those systems, with the changes reflected in the DCE directory.
NDS is rather weak in this area. Although NDS automatically locates any NetWare 4.x servers in the current tree, you cannot configure the network portions of the servers using these tools. Instead, you must use external tools that can vary wildly from server to server. Also, although you can manually add other devices, such as PCs or NetWare 3.x systems, to the directory, you can't do much with the information. NetWare's own security and backup technologies don't tap into these manually built databases, rendering the process of building it a complete waste of time.
Banyan Systems StreetTalk servers autom
atically add themselves to the directory--and some StreetTalk clients can be configured to register automatically with the directory, thereby making themselves visible to administrators. However, StreetTalk does not allow for the remote configuration of the remote system's network-specific settings, requiring you to visit each and every system on the network when you want to change a transport parameter. We could find no mechanisms in StreetTalk for adding foreign devices to the directory manually.
|
Novell's Market-Leading Directory Services
Pros: Ex
cellent third-party support; extensible management console; aliased resources; best client support; integrated Network Information Service (NIS); 15-level X.500-style naming; gives users simultaneous access to multiple independent trees; robust replication capabilities; excellent performance; market leader
Cons: Weak device management tools; weak service management tools; weak server-platform support; poor performance without careful planning; no support for Domain Name System (DNS) or X.500 as directory locator protocols
Best Used In: Corporate networks that need to establish hierarchical network directories, with absolute control at the top and distributed authority through the organization; companies with heavily mixed network infrastructures that need to manage resources across platform lines
The primary reason Novell Directory Service (NDS) is the market leader--and the reason it has a huge base of third-party support--is that it comes from Novell. Although it does not provide all the features o
f the other products we tested, it does provide exceptional integration with third-party offerings and a broad base of services--elements derived from Novell's relationships w
ith the industry's key players--as well as backward support for NetWare 3.x.
Though NDS has the strongest base of third-party support for integrated security and directory services, it does not support everything we would desire in a directory. Most of NetWare's own management tools and services do not take advantage of NDS, much less most of the products that support NDS by way of NetWare 4.x's bindery emulation capabilities.
Additionally, although the underlying NetWare 4.x OS provides the highest level of system integration services of any NOS, the directory service itself is available only on UnixWare, Novell's formerly owned Unix subsidiary.
NDS is exceptionally well-architected, offering 15 levels of resource segmentation and flexible replication options. This lends itself to incorporation in complete, top-to-bottom corp
orate infrastructures that support millions of users and resources. However, because there are few services for joining multiple directory trees dynamically, these trees must coexist on the network with duplicated accounts and security restrictions.
Still, NDS was the only directory we tested that provides a Web-based view of the directory. However, this directory is not searchable, and offers only rudimentary information about the data in the directory.
|