Much confusion exists about the Directory Enabled Networks (DEN) initiative. The Desktop Management Task Force's (DMTF's) adoption of DEN 3.02 has brought DEN into the spotlight, but the media coverage doesn't provide much insight into what DEN is. You need to understand what DEN is and how it might affect your network.
Password Synchronization
Historically, users lacked an adequate means of synchronizing NT and UNIX passwords because each OS uses a different method to obscure and store passwords. Fortunately, Microsoft has included one-way password synchronization software in the add-on pack. Screen 1 shows the password synchronization configuration file.
One-way password synchronization software hooks into NT and lets NT and UNIX systems share passwords. When users change their password on an NT system, the UNIX system automatically receives the new password. Unfortunately, the software only synchronizes NT passwords to UNIX.
Why didn't Microsoft include the ability to synchronize passwords from UNIX to NT? The answer probably resides in the notion that Microsoft wants NT to be the platform of choice, and having systems administrators manage user account information on an NT system forces UNIX users to use an NT system. Microsoft's plan makes good marketing sense; however, the plan also opens the market to third-party vendors who want to produce software that synchronizes UNIX passwords to NT.
The add-on pack introduces much-needed interoperability between UNIX and NT systems. However, the add-on pack doesn't include an NT-based X-Windows client or server, and the KornShell and associated scripts and binaries don't provide all the functionality a user needs.
Third-party vendors will benefit from the add-on pack. For instance, Softway Systems expects the add-on pack to stimulate sales of the company's Interix middleware solution (formerly OpenNT). Interix lets you run UNIX-based applications on NT without having to rewrite program code and introduces X-server capabilities to NT.
NetManage is working with Microsoft to ensure that its Chameleon UNIX Link software is compatible with the add-on pack. One of Chameleon UNIX Link's best features is a tool that lets users access UNIX-style X-terminal-based applications with a Web browser. Chameleon UNIX Link also includes an NFS server, an FTP client, and terminal emulators.
The Future
Will the add-on pack become part of Windows 2000 (Win2K, formerly NT 5.0)? Based on Microsoft's interest in penetrating the UNIX server market, my guess is that Microsoft will bundle the add-on pack and a lot of other software with Win2K.
Officially, DEN is a specification for a directory schema to provide a common taxonomy and organization of network elements and the policies to manage them. The underlying information model used to describe and relate the various classes and attributes is defined by and extends the Common Information Model (CIM) 2.0 as outlined by the DMTF.
If you are thinking, "Huh?" you're not alone. Perhaps a better place to begin describing this hard-to-grasp concept is to look at what DEN is not: DEN is not a protocol, API, technology, or product; DEN is not proprietary. DEN is a draft specification that addresses the need for better integration and interoperability between directory services and network management applications. DEN provides a framework for network management applications to communicate with existing network devices (such as hubs, routers, and switches) through common protocols (such as Simple Network Management Protocol—SNMP) and relate reported information back to the directory. In other words, like a Rosetta stone, DEN is the key that lets a directory service and a network management application communicate with each other. This communication, in turn, lets you integrate the directory service and network management applications to improve network operations.
When you read about DEN, you'll likely come across the terms profile and policy. Cisco, one of DEN's founders (see the "DEN's Roots" sidebar), has succinctly described these terms and their role in DEN:
"The directory-enabled network uses directory services to store critical information to facilitate access, management, and search operations. Users, applications, and services can be abstracted through profiles. A profile is a template of attributes and behaviors that describe an object or a set of objects. Profiles can be applied to a single user or a group of users. Profiles provide a higher level of abstraction for important system components--group, service, and network--while still providing the ability to model and operate on the fundamental building blocks of user, computer, and device. Put another way, profiles tell the system what needs to be done, not the specific steps necessary to do it.
"Policies define desired behavior between two or more objects. It is important to note that policy is separate from enforcement or auditing. In a network, policies apply to a broad range of different services, such as configuration, routing and switching, access control, and usage of services such as encryption and QoS. Centralized policies are the key to overall management of the network. Today, implementing and enforcing consistent policy of any type across a corporation manually is an expensive, labor-intensive, and error-prone proposition. This is due to the inherent complexity of managing many interdependent features across many different types of network elements.
"The DEN specification defines a standard way of storing the policies and profiles (the schema) as well as an information model that defines the desired interaction between objects on the network. The directory also represents objects that consume these network resources, such as users and applications. This allows directory-enabled network elements and applications to discover and enforce policy at the point where resources are consumed. This enables this specification to control the implementation of policy at the group or user level; the administrator can then personalize the network (in terms of what services are available) for individuals and groups of users and devices."
DEN's profiles, or schema, and information models represent your network's elements and services in a directory. In particular, the specification defines a set of data models for typical network devices and implements these models as extensions to the directory service's schema. DEN identifies devices on your network, populates the directory with instances of those devices (i.e., creates objects for those devices), and sets the objects' properties (i.e., policies). Figure 1 shows the object classes in DEN's base schema. DEN derives several object classes from existing X.500 and CIM classes. DEN doesn't influence how you implement an X.500 directory, but it specifies how you represent network objects in an X.500 directory. The changes that DEN imposes are largely refinements of syntax to more accurately describe network objects.
Because DEN integrates network information into the directory, you can associate specific users with network properties. This combination lets you dynamically configure your network to support each user's needs. For example, suppose a company authorizes certain employees to use the network for videoconferencing. No matter where these employees log on to the network, they need secure conference paths. With DEN, you can automatically establish these paths by integrating network provisioning software (a network management application) and a common data store (a directory and its networking extensions) that contains the tools to authenticate and authorize applications and services for the user. DEN provides a focal point for the administration, management, and use of these tools and the provisioning application.
How DEN Might Affect Your Network
With DEN, a directory becomes a common repository for all networking devices and their configuration information, regardless of vendor, device type, or BIOS level. This common repository lets you perform more sophisticated modeling and analysis to get the most out of your current environment. With DEN, you can also consistently and automatically apply policy and configuration settings throughout the enterprise if you set up the network management applications to read information from the directory.
For example, you can create one policy to block UDP packets in the directory and then globally enforce that policy on all routers in the affected containers. The advantage to using this approach is that DEN applies the policy regardless of hardware manufacturer or software revision level of the device. DEN will apply the UDP policy to all models and revision levels of routers. The DEN compliant-network management application will access the directory to read the configuration rules in the policy object and the device-specific configuration methods in the network device object. The management application can then intelligently match the changes that the policy dictates to the configuration method appropriate to the device. In some cases, the management application might establish a Telnet session to apply the policy; in other cases, it might use SNMP or even Lightweight Directory Access Protocol (LDAP) to communicate with the network device. The result is consistent, automated application of policy, even in heterogeneous environments.
Eventually, vendors will develop networking hardware that takes advantage of DEN specifications. This hardware will receive configuration information or other event-driven notifications directly from the policy objects stored in the directory. This level of integration will enable Quality of Service (QoS) policies to be enforced dynamically based on user logon, bandwidth saturation, or other events. (For more information about QoS, see Tao Zhou, "Build a Better Network with QoS," November 1998.) This capability will also allow for end-to-end bandwidth provisioning and security based on application or user policies.
Although implementing DEN will be beneficial, you will need to conduct much research and planning to reap the rewards of successfully combining directory services and network management applications. The base schema are fairly straightforward to implement, but the concept of modeling network elements to fit into a hierarchy isn't. In general, directories are repositories for nonvolatile information with many reads and few writes. Network elements, however, sometimes don't fit into this category. Network elements exist in a dynamic, event-driven environment and constantly change their state to adapt. Thus, you will need to maintain many configuration attributes outside the directory to maintain responsiveness. You will need to determine through trial and error how much configuration state information to store in the directory to provide meaningful analysis without creating synchronization difficulties.
Another consideration is that the directory you use will also likely replicate across your WAN. You will need to balance the additional bandwidth requirement for replication against the manageability that DEN provides. Another area of consideration is access to information. Although LDAP is the most common method for accessing directory data (and the method that DEN specifies), LDAP is not a panacea and will not solve all of your object query woes.
The key to a successful implementation will be collaboration between your network designers and directory designers. Initially, understanding the directory concepts will be critical to take advantage of DEN. However, as vendors make more network devices LDAP-enabled and store and configure more network elements via the directory, you will need a better understanding of the underlying networking infrastructure to provide appropriate functionality and responsiveness. (For more information about vendors' proposed offerings, see the sidebar "Many Vendors Getting on the Bandwagon," page 103.)
DEN and AD
DEN will work with any directory that supports LDAP 3.0 and has an extensible schema, including the Windows 2000 (Win2K—formerly NT 5.0) Active Directory. AD contains the DEN-specified classes and attributes as part of its default schema. In addition, many of Win2K's networking services use AD's policy inheritence information. For example, packet-level encryption (IP Security--IPSec) uses AD's user and group policy information. In fact, the user attributes store the x.509 certificate that IPSec uses. (For more information about IPSec, see Tao Zhou, "Internet Protocol Security in NT 5.0," August 1998.)
Another networking service that uses policy information stored in AD is the QoS protocol Resource Reservation Setup Protocol (RSVP). By exposing network element attributes and user policy information through component object model (COM) objects, developers can write directory-enabled applications that can provision their bandwidth and encryption based on internal events. Such applications will conserve resources on network devices because resource provisioning will no longer need to take place at the IP address or subnet level.
For example, developers could write a directory-enabled application for a brokerage house that provisions bandwidth and encryption based on the type of user request. If Web users request research information from the company's Web site, the application provisions only enough bandwidth (low-priority packets) to guarantee a response within a few moments. However, for a trade execution, the same application uses the same infrastructure to provision appropriate bandwidth (highest-priority packets) to guarantee instant response while also encrypting the session to secure the transaction. The packets for the trading transaction go through first, and the packets for the information request must wait. Developers could also write an application that performs more detailed provisioning by having the application examine the Web user's profile or analyze the content of the trade execution before it provisions packets. The key is that the application dictates the behavior of the network devices over which its transactions travel. The application treats the network as an integral part of the system. This behavior is similar to capabilities that have previously existed only in the mainframe world through message queueing and transaction monitoring.
Figure 2 illustrates RSVP in a directory-enabled network. The figure depicts the flow of low-priority traffic (from an FTP stream) interacting with high-priority traffic (from streaming video) across a directory-enabled network using RSVP to provision resources appropriately for each application.
Add DEN to Your List
Can you take advantage of DEN today? No, but you need to add DEN to the list of tools to consider as you plan for Win2K. You also need to consider DEN if you are planning to purchase hardware, such as routers and bridges.
As you plan for AD, start thinking about groups of users and applications that can benefit from consistent policies and profiles. Ask networking vendors what they intend to do about DEN and have them explain how DEN might benefit your network. Whether or not DEN makes sense for your network, you need to understand this draft specification and its implications because directory services and network management applications are converging. Directory-enabled networks will do for applications what the LAN did for PCs.
| Windows NT Services for UNIX Add-On Pack |
|
Contact: Microsoft * 800-426-9400 Web: http://www.microsoft.com Related Web Addresses For more information about the add-on pack, third-party upgrade options, and other complementary software packages, visit the following URLs: http://www.microsoft.com/ windows/news/september1998/ ntserv4unix.asp http://www.microsoft.com/ntserver http://www.integraph.com http://www.mks.com http://www.interix.com http://www.netmanage.com/ products/unixlink |
