Novell eDirectory
This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter covers the following testing objectives for Novell Course 3001: Foundations of Novell Networking:
Identify basic Directory Service tasks.
Identify common Directory Service uses.
Describe how a Directory is structured.
Identify the role and benefits of eDirectory.
Identify how eDirectory 8.6 works.
Identify and describe the composition of eDirectory.
Identify and describe eDirectory object classes.
Identify the flow and design of the eDirectory tree.
NetWare 6 introduces eDirectory 8.6, the greatest version to date of Novell's world-class directory service.
eDirectory is the world's leading Directory service. It provides a unifying, cross-platform infrastructure for managing, securing, accessing, and developing all major components of your network. eDirectory scales to the largest network environments, including the Internet. Because it is based on the X.500 standard, eDirectory supports Lightweight Directory Access Protocol (LDAP), Hypertext Transfer Protocol (HTTP), and the Java programming environment.
eDirectory can store and manage millions of objects in a seamless ballet of communications. It also provides the foundation network service for all NetWare servers and network resources. In fact, after network communications, it is the most fundamental network service offered by NetWare 6.
With all this in mind, I'm sure you would agree that eDirectory management is one of your key responsibilities as a Novell CNA (Certified Network Administrator). In this chapter, you will explore four important lessons regarding eDirectory management:
Introduction to Directory Services—You'll begin with a brief introduction to the basics of Directory services, including some common uses and how a Directory is structured.
Understanding eDirectory 8.6—Then you'll explore the architecture of Novell eDirectory version 8.6 and compare it to its predecessor, Novell Directory Services (NDS).
Using eDirectory Objects—You'll dig into the basics behind eDirectory's three types of objects: the Tree object, container objects, and leaf objects.
Implementing eDirectory 8.6 Naming—Finally, you'll learn about naming conventions used in eDirectory, including naming context rules and inheritance.
As you can see, there's a lot to learn in this chapter and when it's all done, you'll be an accomplished eDirectory administrator. So, let's get started!
Introduction to Directory Services
Test Objectives Covered:
Identify basic Directory Service tasks.
Identify common Directory Service uses.
Describe how a Directory is structured.
Identify the role and benefits of eDirectory.
The Directory Service is one of the most fundamental network services provided by all NetWare 6 servers. In fact, it represents the communications hub for administrative connectivity between all servers in a large NetWare 6 network. As such, Directory Service management is one of your key responsibilities as the network administrator.
As its name implies, the Directory service provides access to a database, called eDirectory, that contains all resources for the entire network. This object-oriented database is organized into a hierarchical structure called the tree. eDirectory provides the basic foundation for the Directory service, including capabilities for replication and distribution. Directory is capitalized in this case to differentiate it from the directory (or folder) in the file system. In fact, these two "directories" define the two major roles of a NetWare 6 CNA: File System Administrator (directories and files) and eDirectory Administrator (The Directory).
The Directory service is your friend. It may seem a little intimidating at first, but when you get to know the Directory service (and eDirectory, for that matter), it's actually fun. Really.
How Directory Services Work
A Directory service classifies all network resources into a finite number of objects. These objects can be organized by function, location, size, type, or color—it doesn't matter. The point is, a Directory service organizes network resources independently from their physical locations. For example, servers are organized according to function. Then users are placed in the appropriate containers to simplify connectivity. This increases productivity because users are near the resources they need. When a user logs in to the network, the user can access any object in the Tree, regardless of its location. This provides a slick means for managing not only users, but also all their hardware and applications. Of course, in the eDirectory tree (as in life), it is best to place User objects and their resources (Printers, Servers, and Volumes) in close proximity to each other.
A Directory service performs several basic tasks, including the following:
Connecting disparate systems—A Directory service integrates and organizes heterogeneous systems to allow them to share common management. In today's business world, such systems are required not only to communicate with each other, but also to share information and use common services to meet the objectives of the organization.
Satisfying the needs of the user, organization, and business—The network must be flexible enough to provide a set of unique services based on individual needs.
Emulating all business relationships—The network must be capable of ensuring that trusted relationships are built and maintained between people, business, the company's intranet, and the World Wide Web.
Coordinating information flow—Information may emanate either from the business (procedural) or from the network (technical). A Directory service coordinates information flow, no matter what the source or type of information.
Ensuring information availability—A Directory service provides a means for making all network information available to users, devices, applications, or other resources.
TIP
A Directory and a Relational Database Management System (RDBMS) are two separate entities with different functions. Even though a Directory is a collection of information, it does not replace the traditional RDBMS. Directories and databases complement one another, even though they serve different purposes.
Typically, a Directory service may be used in the following ways:
Organizing data—A Directory service organizes data or information for the network. In NetWare 6, eDirectory stores all user, server, printer, and other network device information.
Accessing information easily—Similar to the file-and-folder system used on a computer, a Directory service makes information about network resources available to users, devices, and applications. A Directory service provides employees with global access to network resources. Businesses and organizations also use Directory services to provide user authentication and authorization for using these network resources and services. For organizations with large numbers of mobile users, eDirectory provides a means for storing user information required by some applications. (Such applications are described as Directory-enabled.) From the user's point of view, a Directory service provides a global view of all network resources, such as users, applications, services, system resources, and devices.
Providing security—A Directory service uniquely identifies network resources, locates network objects when required, supports robust security features, and controls the user access to network resources.
Providing services to customers—For organizations taking advantage of the features of electronic business transactions, Directory services can help organize multiple databases while helping to mesh disparate network systems. This provides better management of processes between customers, employees, and supply-chain partners. The resulting benefits are as follows: reduced costs for administration and hardware, faster access to data and information, and secure network access with superior fault tolerance.
From a general perspective, Directory services can also provide electronic provisioning, enhanced security, customer profiling, electronic wallets, automated notification systems, customized Web interfaces, and virtual private networks (VPNs).
Note
A virtual private network (VPN) often is used to transfer sensitive company information across an untrusted network (such as the Internet) in a secure fashion (typically by encapsulating and encrypting data).
So, what do you think? Is a Directory service for you? Who knows—you might even like it.
Directory Architecture
As you recall, the Directory service provides access to the eDirectory database, which contains all resources for the entire network. What exactly does eDirectory look like? From the outside, it looks like a big cloud hovering over your network. On the inside, however, it follows a hierarchical tree structure similar to the Internet domain system. That is, starting at the WWW Root and expanding to ".com" domains and eventually to servers. In NetWare 6, this design is referred to as the Directory Information Tree, which is shortened to the "tree" for purposes of our discussion.
Think of the tree as actually being inverted. As in nature, the eDirectory tree starts with the Tree object (called the Tree Root) and builds from there. Next, it sprouts container objects, which are branches reaching toward the sky. Finally, leaf objects provide network functionality to users, servers, and the file system. As you can see in Figure 3.1, the tree analogy is alive and well.
)
Figure
3.1 The figurative Directory services tree.
The real eDirectory tree is made up of logical network objects. eDirectory objects define logical or physical entities that provide organizational or technical function to the network. As you will see later in this chapter, they come in three flavors:
Tree Root
Container objects
Leaf objects
The Tree Root is the very top of the eDirectory tree. Because it represents the opening porthole to the eDirectory world, its icon is appropriately a picture of a tree. Container objects define the organizational boundaries of the eDirectory tree and house other container objects and/or leaf objects. When a container object contains other objects, it is called a parent object.
Finally, leaf objects are the physical or logical network resources that provide technical services and network functionality. Leaf objects define the lowest level of the eDirectory structure. You'll learn about the most interesting leaf objects later in this chapter.
The structure of the Directory is governed by a set of rules collectively known as the Directory schema. These rules define the type of data, the syntax of that data, and the objects the Directory can contain. Schema rules fall into two broad categories:
Object class definitions—These define the type of objects and the attributes of those objects.
Attribute definitions—These define the structure (syntax and constraints) of an attribute. Simply stated, the attribute value is the actual content or data.
Remember when I told you that eDirectory was based on the X.500 standard? Before you go tree climbing and explore the dynamics of eDirectory, take a quick look at that standard to see what that all means. I think you'll spot some amazing similarities between X.500 and what you've just learned about Directory services.
Understanding X.500
X.500 is an international standard for naming services. A variety of industry standards, such as DNA (Digital Network Architecture), use X.500 with their own naming services to provide address-to-name resolution and directory services. This enables these distributed machines to exist in a large hierarchical management system.
X.500 organizes network resources (such as users and servers) into a globally accessible Directory. The X.500 specification establishes guidelines for representing, accessing, and using information stored in a directory database. In fact, eDirectory is Novell's implementation of the following X.500 features:
Scalability—Large databases can be subdivided into smaller Directory System Agents (DSAs). A DSA can represent either a single organization or multiple organizations, and its contents may be distributed across multiple Directory servers. eDirectory calls them partitions.
Replication—This feature allows the Directory database, or portions thereof, to be replicated on backup Directory servers located throughout the network.
Synchronization—Because X.500 must manage a loosely coupled, distributed database, each server must be able to synchronize its database contents with other servers. Directory database updates may be made either at the original master database (master-shadow arrangement) or at any writable replica (peer-to-peer mechanism). In either case, X.500 propagates Directory database change information to all servers holding replicas of the database or a DSA.
The X.500 Directory is represented by a Directory Information Tree (DIT) and Directory Information Base (DIB). At least one of those should sound familiar. The DIB consists of objects (or nodes) and their associated properties and values. Intermediate objects act as containers that aid in organizing the DIT. Leaf objects represent individual network entities, such as servers, printers, and so on. Refer to Figure 3.2 for an illustration of the X.500 Directory architecture.
The rules that determine the type of information that may be stored in the DIB are held in the Directory's schema. (Now this should be sounding really familiar.) Each object in an X.500 DIT has a unique name that is referred to as its distinguished name, or DN, (that is, complete name). Each object may also be referred to by a relative distinguished name, or RDN, (that is, partial name).
Directory database access is managed by a DSA running on a local server. Users access the database through a Directory User Agent (DUA). DUAs are available in command-line, forms-based, and browser-style interfaces. DSAs and DUAs communicate with each other using the Directory Access Protocol (DAP). Furthermore, DSAs may communicate with one another using the Directory System Protocol (DSP), Directory Information Shadowing Protocol (DISP), or the Directory Operational Binding Management Protocol (DOP).
)
Figure
3.2 X.500 Directory architecture.
Now that you know where Directory services came from and generally how they work in NetWare 6, it's time to do some tree climbing! Sounds like that fun I promised you, doesn't it?