Managing eDirectory

Test Objectives Covered:

3. Describe the purpose of eDirectory.

4. Describe how eDirectory works.

5. Perform eDirectory administration tasks .

6. Manage User objects with iManager.

Up to this point, we've briefly brushed up against the topic of eDirectory several times. Each time I've said, "Don't worry, we'll discuss this in detail later." Fortunately, later is finally here. It's time to talk eDirectory.

It is absolutely critical that you master the concepts and skills presented in this part of this chapter. As we will discuss in a minute, eDirectory is the backbone of NNLS. If you don't understand eDirectory, you won't be able to manage an NNLS system effectively.

Even if you are already familiar with eDirectory, I would strongly suggest that you read this content anyway. Chances are you learned eDirectory (or its predecessor Novell Directory Services) on the NetWare platform. Most of the concepts are the same with eDirectory on Linux. There are, however, some key differences that can trip you up if you're not aware of them.

Without any more delay, let's dig into the world of eDirectory.

What Is a Directory Anyway?

If you're new to eDirectory, you may be asking, "What's this directory thing all about, anyway?" If you learned to manage user accounts using Windows NT domains or Linux passwd files, you'll be surprised at what you can do with directory services.

Essentially, a directory service is a hierarchical database that is used to store information about network resources.

Note

The directory services we are discussing here are those that are based on the X.500 directory service standard. You may hear these types of directories referred to as full-service directories . Many software vendors over the years have tried to pass off their flat-file user databases as "directories."

The first time I heard the term directory back in the mid-1990s, the image of a phone book came to my mind. That analogy isn't far off. A full-service directory, however, can store more than just user information.

Let's take a few steps back into history. Recall that in an earlier chapter I related a story about my first networking job where I was responsible for an organization's NetWare 3 network.

NetWare 3 (and earlier versions of NetWare as well) used a flat-file database called the bindery to store user accounts and groups. Each server in my network had its own bindery. My organization had about 1200 users, each with his or her own account. Each needed access to resources hosted by each of the NetWare servers I was responsible for.

That required me to keep the user accounts and passwords synchronized on all servers in the organization. Needless to say, for the first couple of months on the job, that's about all I did. My users simply expected to have a single password to access all network resources.

If they changed their password in one bindery user account, they expected that password to work when accessing other servers in the network. Eventually, that would be so, but only after I fielded their complaint and manually changed the account information on the other servers.

After a couple of months, I became very annoyed with the situation and wrote some nifty little programs that could be used to synchronize accounts between servers; but it was still a manual process. If I forgot to run them, the accounts would quickly go out of sync and the help desk calls would start rolling in.

This situation also presented a problem when a new individual would join or leave the organization. I had to either create multiple accounts or delete multiple accounts on all the servers.

In addition, each version of the user's account had different trustee assignments and login scripts. Talk about job security.

If you've ever managed a Linux network that employed multiple servers, you've faced a similar issue. Remember that Linux users and groups are local to the server. To get around this, many Linux administrators employ the NIS+ service, which synchronizes user accounts among Linux servers.

eDirectory changes all that. With this service, all the servers on your network are installed into the eDirectory tree. User accounts are also created in the tree. Users have one single account that gives them access to network resources.

Instead of logging in to a specific server, users authenticate to the eDirectory tree. From there, they can access any network data or resource they have been granted access to, regardless of what server is hosting the resource.

In addition, applications can be easily written that access directory information. As you will see later in this book, all NNLS components do just that. They use eDirectory information to control access, display information, and provide services.

eDirectory fills the following primary roles:

• Storing network data in a central repository

• Organizing network data into a logical structure

• Providing standardized methods for accessing network data

• Controlling access to network data

• Securing network data

Let's now discuss how eDirectory works.

How eDirectory Works

When discussing how eDirectory works, we're going to stay at the conceptual level. Recently, I had the opportunity to spend time with the software developers at Novell who actually wrote the eDirectory code, learning about the inner workings of the product. My head was swimming after only a few minutes (and I had considered myself an eDirectory veteran!). We will discuss the following topics:

• The structure of the eDirectory tree

• How eDirectory naming conventions work

• How eDirectory rights work

• How eDirectory embraces the Lightweight Directory Access Protocol(LDAP) standard

The Structure of the eDirectory Tree

Recall that I mentioned earlier that eDirectory is a hierarchical database. Before discussing what this is, let's talk about what it is not.

Windows NT domains, the Linux passwd file, and NetWare binderies are all considered flat-file databases (that is, nonhierarchical). This is because entries in these databases can't contain other database entries.

Many new to directory services contend that this isn't entirely true because, they argue, groups in these databases are composed of user accounts. This isn't correct. A group in one of these databases has users who are members of the group. The actual user account itself resides outside the group; user accounts aren't actually contained within the group.

The hierarchical eDirectory database, on the other hand, handles things in a very different manner. You must first understand that entries in the eDirectory database are called objects . There are two general categories of objects within the database:

• Container objects ” Container objects can contain other database objects. To draw a simple comparison, container objects are similar to directories within a file system. File system directories can contain files or other directories.

  Likewise, an eDirectory container object can contain other container objects, or leaf objects . Container objects are used to organize directory data. Container objects can be used to organize data by geographical location, business unit, or organizational function.

• Leaf objects ” Leaf objects represent network resources in the eDirectory database. These can be physical resources, such as users, printers, and servers. Or, they can be logical network resources such as groups, profiles, and templates.

  Carrying on the analogy started earlier, leaf objects are similar to files within the file system. In the file system, files contain real data. Files can't contain directories or other files.

  Likewise, leaf objects in the eDirectory database can't contain any other objects.

All eDirectory objects, both container and leaf, are contained within the eDirectory tree. Each eDirectory tree has a set of rules that defines the types of objects that can exist in the tree and where they can reside. This set of rules is called the schema . A very simple eDirectory tree is shown in Figure 5.28.

Figure 5.28. eDirectory tree.

Figure 5.28 depicts the eDirectory tree you installed in an earlier lab exercise. Notice that the name of the eDirectory tree is CLE-TREE . The tree is the topmost container in the hierarchy. Within the tree is a container object called CLE . Inside of CLE is another container object named IF . Within IF are several leaf objects, including the admin user object and the RCD Group object you created.

This brings up an issue that I've observed over the years. Because many network administrators who move to eDirectory come from a Windows NT, NetWare bindery, or Linux/Unix passwd file background, they make a key error when installing eDirectory.

Generally speaking, an organization should have one eDirectory tree. Because of their previous experience with these other flat-file databases, however, administrators install each eDirectory server in their organization into its own tree.

A Novell technical support engineer once related to me an instance when she received a support call from an individual who had made this very mistake. After asking several exploratory questions trying to discern the customer's problem, she discovered that the administrator had more than 50 eDirectory servers in his network and had installed each one into its own tree.

If you do this, you're stuck with a system that isn't much better than the flat-file database systems you migrated from. Each tree operates completely independent of the other trees in your network. Remember that you can (and should) install all your servers into the same eDirectory tree.

You've probably noticed in Figure 5.28 that the icons representing the CLE and the IF containers are different. That's because they represent different types of container objects. In eDirectory, there are three types of containers within the tree container:

• Country object ” Country objects can only reside at the top of the tree, directly within the tree object itself. Country objects can only contain Organization objects or alias objects. Country objects can only be named using standardized two-character country abbreviations, such as US, FR, and UK.

  Use of Country objects is optional. Notice that we didn't use a Country object in the eDirectory tree we configured when we installed NNLS.

• Organization object ” Organization objects can reside only within tree objects or within Country objects. Organization objects can contain any other eDirectory objects, except for Country objects and other Organization objects. They can contain Organizational Unit objects and any leaf objects defined in the tree's schema.

  Notice in the tree you installed that the CLE container is an Organization object.

• Organizational Unit object ” Organizational Unit objects are container objects that can reside only with Organization objects or other Organizational Unit objects. Organizational Unit objects can contain any other objects defined in the eDirectory schema, except for Country and Organization objects. They can even contain other Organizational Unit objects.

Given the rules associated with these objects, a couple of standard tree designs are frequently used by eDirectory implementers. The first, and most common, is the one you used to create your eDirectory tree. Beneath the tree are one or more Organization objects.

Within each Organization object are one or more Organizational Unit objects, each containing the various leaf objects that comprise the tree as well as other Organizational Unit objects.

You could also design your tree such that you have one or more Country objects directly beneath the tree object. Within each Country object are Organization objects that each contain Organizational Unit objects.

You could also design your tree such that you have one or more Organization objects at the root of the tree that each contain leaf objects.

Which is the best design? That's a very subjective question. The design that works best for your organization may not work well at all for a different organization. There are some general rules you should adhere to when designing your eDirectory tree.

First, you should organize the upper layers of the tree by geography, business unit, division, or some other organizational criteria. For example, if your organization has offices in Denver, Boise, and Annapolis, you could create Organization objects at the top of your tree for each location.

If your organization has offices in several countries , you could create Country objects at the top of your eDirectory tree that represents each one.

You don't have to use geography to design the top layer of your tree. You could also use logical criteria, such as a business unit or function. For example, if your company resides in a single location, but has five different business units, you could create five Organizational Units at the top of your tree.

This is the metaphor we used when we installed our tree. Notice that our topmost container is an Organization named CLE. Our topmost layer is organized by certification type. Using this standard, we could expand our tree to include Organizations for CNE, CNA, and LPI, for example.

Once you have the top layers of your tree designed, you need to design the lower layers of your tree. As with the upper layers of the tree, you should use some organizational criteria to design the lower layers of the tree. These criteria could be business function, geographic location, or business unit.

In our eDirectory tree, we chose to organize the lower layers of our tree by geography. Our only Organizational Unit is IF, which represents the city of Idaho Falls, Idaho. As we go through this book, we will add more Organizational Units representing geographical locations.

A full review of all the eDirectory design rules and guidelines is beyond the scope of this book. If you follow the basic rules presented here, though, you'll be in good shape.

As mentioned earlier, eDirectory also uses leaf objects in addition to container objects. There are a multitude of different types of leaf objects in a typical eDirectory tree. We don't have the time or space to review them all here. We will, however, discuss some of the most commonly used types:

• User objects ” User objects are perhaps the most commonly used type of eDirectory object. A user object represents a user in the tree. Users use these objects to authenticate to the tree. Access to network resources is controlled by the rights you grant to these objects.

• Group objects ” Group objects are special objects you can populate with user objects. Group objects help make the administration of your tree much easier. Suppose you have 150 users who all need exactly the same access to the same network resources. Without group objects, you would have to manually configure rights assignments for each and every user object.

  By making these 150 users members of a single group object, however, you can assign rights to the group object. The users who are members of the group automatically receive the rights that have been assigned. Managing one set of assignments is much easier than managing 150.

• Template objects ” The standard eDirectory schema includes a template object. Template objects make the process of adding new users more efficient. You add information that is common to all users to the template object.

  This could include information such as business address and fax number. Then, when you create a new user, you associate it with the template object, which automatically populates the new user object with this information, which saves you a lot of typing.

• Organizational role objects ” Organizational role objects are very useful. To understand how these objects work, consider the following: Suppose you need to delegate some administrative authority to a user in your eDirectory tree. You want this individual to be able to add new users to the tree when they are hired .

  One option you have would be to assign the necessary rights to the user you want to delegate this authority to. But suppose this user were to move somewhere else within the organization. You would have to remember to unassign the rights you gave him or her and reassign them to someone else.

  Organizational role objects make this much easier. Instead of assigning rights to the user object, you assign the necessary rights to an organizational role object. Then you make the user you want to delegate authority to an occupant of that role.

  When you do this, the user automatically receives the rights assigned to the organizational role object. If you need to change the delegation to a different employee, you simply remove the previous occupant from the role and add the new user.

• Alias objects ” Alias objects are similar to shortcut files on a Windows system or link files on a Linux system. Both of these files serve as pointers to a resource somewhere else in the file system. The pointer files themselves contain very little information.

  Alias objects in the eDirectory tree work in much the same manner. They are placeholders that point to an object somewhere else in the tree. They are frequently used for user objects.

  Suppose you have a user named LMorgan. Her user object resides in .IF.CLE . She has recently been promoted and has moved to an office in Salt Lake City, Utah. You moved her user object to .SLC.CLE . However, she keeps trying to authenticate to the tree as LMorgan.IF.CLE . If you were to create an alias object for LMorgan in the IF.CLE container that pointed to her user object in its new location, she would be able to log in.

• Server objects ” Server objects represent eDirectory servers that have been installed into the tree. Notice in Figure 5.28 that the CLE1 server we installed has an object in the tree.

• Printer objects ” Printer objects represent a physical printer in the network.

There are a multitude of other types of eDirectory objects, such as LDAP objects, SAS object, KMO objects, SSL objects, license objects, and so on. We're not going to cover them here. If you happen upon an object that you're just dying to learn more about, check out the eDirectory 8.7.3 documentation available at http://www.novell.com.

eDirectory Naming Conventions

If you're new to eDirectory, you're probably scratching your head over the way we're referencing eDirectory objects. For example, we used the object names LMorgan.IF.CLE and CN=admin.OU=IF.O=CLE . Let's review what all this means. We'll start with the concept of context .

eDirectory Contexts

The term context simply refers to the object's location in the tree. It is the list of container objects that contain the object in question.

Context is very similar to the concept of full path in the Linux file system. For example, the full path to the slpd init script in your Linux file system is /etc/init.d/ . The full path is simply the list of directories in order, starting at the root directory, that contains the particular file. In this example, slpd exists in the init.d directory, which exists within the etc directory. The etc directory itself resides in the root directory ( / ).

eDirectory objects are referenced in the same way. The difference is in the direction of the path. In the Linux file system, you start with the root directory on the left side and drill down to the file moving to the right. eDirectory object context moves in the opposite direction.

Let's look at the admin.IF.CLE object (refer to Figure 5.28). The LMorgan object resides in the IF container, which resides in the CLE container. Containers are separated by a period (.).

One nice feature of eDirectory is the fact that object names and contexts aren't case-sensitive. The name lmorgan.if.cle is considered to be exactly the same as LMORGAN.IF.CLE .

Now let's look at typeful and typeless naming.

Typeful and Typeless Naming

There are two ways to refer to eDirectory objects. One is referred to as typeful and the other as typeless .

Remember when you were installing NNLS and were asked to provide the name of your tree's admin user? You were directed to enter CN=admin.OU=IF.O=CLE . This is an example of typeful naming.

Typeful naming requires you to specify the type of object in the name. All leaf objects have a typeful designator of CN= . Organizational Unit objects have a typeful designator of OU= . Organization objects have a typeful designator of O= . Country objects (which aren't used very often) have a typeful designator of C= .

Suppose you created a group object named Engineers in the SLC.CLE context. It's typeful name would be CN=Engineers.OU=SLC.O=CLE .

If you were to use typeless naming, you would refer to this object simply as Engineers.SLC.CLE . This is pretty easy stuff so far. Now it's time to confuse you with relative and distinguished names.

Relative vs. Distinguished Names

I've been teaching eDirectory since the mid-1990s (back then it was called NDS), and one of the hardest concepts for new eDirectory administrators to grasp is the concepts of relative and distinguished names .

To understand these concepts, you must first understand the notion of current context . The easiest way to understand this idea is to compare it to current context as implemented in the Linux file system. If you were to use the cd command to change to the /etc directory, your file system current context is /etc . It's where you are currently "at" in the hierarchical directory structure.

It works the same way in the eDirectory tree. Your current context is where you are "at" in the tree.

With that in mind, let's talk about distinguished names in the tree. A distinguished name lists the object name and its context all the way back to the root of the tree. Distinguished names always begin with a period ( . ).

For example, the distinguished name of the admin user in the eDirectory tree you just installed is .admin.IF.CLE . This name begins with a period, then it lists the name of the object itself (admin) and then provides the context of the object up to the root of the tree (.IF.CLE).

This is what constitutes a distinguished name. A typeful distinguished name adds the type designations to the distinguished name. For example, .CN=admin.OU=IF.O=CLE is the typeful distinguished name for your admin user object.

A relative name, on the other hand, is the name of the object concatenated with the containers it resides in up to the current context instead of the root of the tree. Relative names do not begin with a period.

For example, if your current eDirectory context is .IF.CLE , the relative name of your admin user is simply admin . That's because it resides within the current context.

Suppose, however, that the current eDirectory context is now .CLE . The relative name for your admin object is the name of the object (admin) plus the containers the object resides in up to the current context (.IF). Therefore, if your current context is CLE, your admin user object's relative name is admin.IF .

As with distinguished names, relative names can be typeful or typeless. The relative name admin.IF is an example of a typeless relative name. The typeful version of this relative name is CN=admin.OU=IF . Remember that relative names do not begin with a period, whereas distinguished names do.

With that we're ready to move on to a discussion of eDirectory rights .

Working with eDirectory Rights

Earlier I mentioned that one of the key roles of eDirectory was to control access to network resources. Assigning eDirectory rights does this.

eDirectory rights are similar in some ways to Linux file and directory permissions. Permissions specify what specific users and groups can do with a file or directory in the file system.

eDirectory rights specify what one object in the tree can do to another. When one object is granted rights to another object, the first object is said to be a trustee of the second. For example, if you were to grant LMorgan rights to the Engineers group object, the LMorgan user object becomes a trustee of the Engineers object. eDirectory rights include the following:

• Supervisor ” The supervisor right grants all rights to the trustee. The trustee can create, delete, or modify the object. This is a very powerful right and is assigned only on very rare occasions.

• Browse ” The browse right allows the trustee to see the object in the tree.

• Create ” When a trustee of a container object is assigned the create right, the trustee can create new objects in the container. You can't assign the create right to a trustee of a leaf object.

• Rename ” This right allows a trustee to modify the name of an object.

• Delete ” This right allows a trustee to delete an object.

Tip

Object rights are also referred to as entry rights . Older versions of eDirectory use the former term; later versions use the latter .

There's also a second set of rights you can manage in eDirectory. These are called property rights .

Tip

Property rights are also referred to as attribute rights .

To understand property rights, you need to understand that every eDirectory object has properties. Each property, in turn , has at least one value. For example, a user object has properties such as First Name, Last Name, Title, Location, Phone Number, Fax Number, Address, and so on.

Object rights specify how a trustee can manipulate the actual objects. Property rights specify what the trustee can do with the values of the object's properties.

For example, you could grant your organization's administrative assistant rights to modify user objects' Phone Number, Fax Number, and Address properties.

The following are the property rights that can be assigned to trustees:

• Supervisor ” The supervisor property right allows the trustee full access to the specified property.

• Compare ” The compare property right allows the trustee to query the value of the specified property using a Boolean expression. For example, you could query the object to see if its phone number value is equal to 555-555-5555. The compare right only returns a TRUE or FALSE response. The compare right doesn't allow you to see the actual value of the property.

• Read ” The read property right allows the trustee to view the value of the specified property. It doesn't allow the trustee to modify the property in any way.

• Write ” The write property right allows the trustee to modify the value of the specified property.

• Add Self ” The add self property right is an interesting one. It allows the trustee limited access to the value of a property. It only allows the trustee to set the value of the specified property to the name of the trustee object (hence the term add self ).

There's one more key aspect of eDirectory rights that you need to understand: inheritance .

Managing Inheritance

It is vital that you understand that eDirectory rights, by default, flow down the tree in what is called inheritance . The best way to understand inheritance is through an example.

Suppose your organization has grown very large and you need help managing the eDirectory tree. You decide to grant user LMorgan.IF.CLE the browse, create, and rename rights to the CLE container in your tree so she can create, delete, and modify objects in the tree.

The rights assignment you made to the CLE container flow down the tree to objects beneath CLE in the hierarchy. In other words, LMorgan.IF.CLE receives rights to all other objects below CLE through inheritance. For example, if there is a user object named VHammer in the SLC.CLE context, LMorgan.IF.CLE has browse, create, and rename rights to the VHammer.SLC.CLE object, even though she hasn't been explicitly granted rights to it.

Rights that a trustee receives to an object through inheritance and not through an explicit rights assignment are called effective rights .

This is how your admin object receives rights to the entire eDirectory tree. Consider Figure 5.29.

Figure 5.29. Admin as a trustee of the tree object.

During installation of NNLS, your admin user object was made a trustee of the tree object and granted supervisor rights. This assignment flows down the tree to all subcontainers and leaf objects within those containers.

This allows the admin user object to have supervisor effective rights to the entire eDirectory tree.

This concept of inheritance is also used with the [ Public ] account. [Public] is not a user object. It's an account that provides guest access to the eDirectory tree. Notice in Figure 5.30 that [Public] has been granted the browse right to the tree object.

Figure 5.30. [Public] rights to the tree.

Because [Public] is a guest user account that doesn't require authentication, this rights assignment allows unauthenticated users to browse the tree. It doesn't allow them to log in or to modify data in the tree any way. This feature is used by eDirectory client workstations during login. Users can browse the tree to find their context and their server objects so they can log in.

The concept of inheritance in an eDirectory tree makes managing the tree much easier. Imagine how much work it would take if you had to make explicit rights assignments to every object every time you wanted to make a trustee assignment.

There may be times, however, when you don't want these rights to flow down the tree. Going back to the previous example, remember that we granted LMorgan.IF.CLE browse, create, and rename rights to the CLE container in our tree. Suppose that within the IF container is a container named Finance, where your organization's financial officers' user objects reside. For security reasons, you don't want LMorgan.IF.CLE to have rights other than the browse right to this container.

With eDirectory, you can block inheritance. This is done in two ways, the first of which is to make an explicit rights assignment at the level where you want the inheritance to end. Consider Figure 5.31.

Figure 5.31. Blocking rights with an explicit rights assignment.

Here, LMorgan.IF.CLE has been made a trustee of the Finance Organizational Unit object and has been granted only the browse right to it. This explicit assignment overwrites and blocks the rights LMorgan.IF.CLE received to the container through inheritance.

Inherited rights can also be blocked using an Inherited Rights Filter (IRF). IRFs are used to block specific rights from being inherited by a given object. Consider Figure 5.32.

Figure 5.32. Implementing IRFs.

In Figure 5.32, an IRF has been placed on the Finance container object. Rights that have a check mark next to them are allowed to flow through and be inherited. Rights that are not marked are blocked and are not inherited. IRFs have no impact on rights that are explicitly granted to a trustee.

For example, if you were to grant a different user object browse, create, and rename rights to the Finance container, he or she would have received those rights in spite of the IRF. IRFs only affect rights that are inherited from somewhere above in the tree hierarchy.

IRFs must be used with caution. Imagine what would happen if you were to block all the rights to the given container and there wasn't anyone else in the tree who had explicit assignment to the container: all access for everyone, including admin, would be cut off.

In the "old days" of NDS, the administrative tools in use at the time would allow you to do just that. Every now and then, you would hear horror stories about someone cutting off an entire branch of the eDirectory with an IRF, and he or she couldn't get it back.

Today, if you try to do this with a utility such as iManager, you will get a nasty warning indicating that if you implement the IRF, there's no one else in the tree who will be able to access the container.

You've just been given a crash course into the basics of eDirectory. As with Chapters 2 and 3, you've been given just enough to get you going.

Now, we're now going to change course and discuss two deeper eDirectory concepts: partitioning and replication .

Managing eDirectory Partitioning and Replication

To understand eDirectory partitioning and replication, you must first realize that eDirectory is a distributed and replicated database. This is probably very different from other types of databases you have used in the past. It's definitely different from the way Linux and Windows NT user accounts are managed.

The eDirectory database can be run on a single server, but it doesn't necessarily have to be. It can be distributed among several servers. This is what happens when a server is installed into the eDirectory tree.

The eDirectory tree can also be partitioned . Like the concept of relative naming mentioned earlier, partitioning is one of the hardest concepts for new eDirectory administrators to understand.

Essentially, partitioning allows you to divide the database into several parts , each called a partition . The partitions are created logically in the tree at the container level. The topmost container in a partition is called the partition root .

Consider the tree we installed when we implemented NNLS. We could potentially create a partition at three different levels in the tree ”one at the tree root, one at the CLE Organization object level, and one at the IF Organizational Unit level.

Each partition can be placed on a different server in the eDirectory tree. The reason for doing this is performance. Imagine what would happen if you had a huge network with users all around the world. If eDirectory ran on a single server, every user would have to access that server every time he or she wanted to log in or use a network resource. Remote users would have to consume expensive WAN bandwidth to do this.

With partitioning, you can divide the eDirectory database into several parts and place those parts on different servers. This distributes the load among those servers, improving performance. It also allows you to place partitions on local servers containing the data that the users in a given location need.

For example, if your organization has offices in Denver, Boise, and Annapolis, you could place partitions of your eDirectory tree containing Boise-specific users and data on a server in Boise (and likewise for Denver and Annapolis). Then, when users need to log in or use a network resource, they don't have to cross WAN links. The information they need is local to them.

You also need to understand parent and child relationships in partitioning. Referring to our previous example, we could potentially create three partitions in the tree we configured earlier. Notice that the partitions exist in a hierarchical fashion; the tree root partition, at the top of the eDirectory tree, has two partitions below it ”one at the CLE container level and one at the IF container level.

In this situation, the tree root partition is said to be a "parent" of the CLE partition because it resides higher in the tree hierarchy. The CLE partition is said to be a "child partition" of the root partition. Likewise, the CLE partition is the parent of the IF partition and the IF partition is a child of the CLE partition.

In eDirectory, parent/child relationships only go up or down one level, so the IF partition is not a child, or grandchild, of the tree root partition.

The first time I learned about partitioning back in the early 1990s, it scared me to death. I had some experience with hardware crashes, and the thought of taking a database and dividing it up among several servers made me cringe. What if one of the servers went down? The whole database could end up getting corrupted because a chunk of it would disappear.

Novell wisely accommodates for this reality. In addition to dividing up the eDirectory database into partitions, you can also place multiple copies of each partition on different servers. Each copy is called a replica .

eDirectory is designed such that changes made by an administrator (changing a password, for example) to one replica are quickly replicated to all the other replicas of that partition. All the servers that host a replica of a given partition are said to be members of the replica ring . Each replica has an attribute called Replica . This attribute contains a list of all the other servers in the replica ring for the given partition.

eDirectory uses this to make sure the data in all replicas of a given partition is always synchronized so that no matter what replica is used for a given network action, the data is always up to date.

For any given partition, four different types of replicas can be placed on servers in the tree:

• Master replica ” The Master replica is created when a partition is defined. There can be only one Master replica per partition. As you can see in Figure 5.33, one partition was automatically created when you installed eDirectory that encompasses the whole tree. By default, your CLE1 server had a Master replica of the partition placed on it.

  Figure 5.33. Default partitioning and replication.

  

  
  

  Because CLE1 is the only server in the tree, there is only one replica of the partition. All major partition operations, such as moves, merges, and creates, must be initiated from the Master replica.

• Read/Write replica ” Read/Write replicas are exact copies of the Master replica. Read/Write replicas can be used to authenticate to the tree and make changes to objects in the tree. The changes made are synchronized around to the other replicas of the partition, including the Master replica.

  You can create as many Read/Write replicas of a partition as you wish. Novell recommends, however, that you don't create more than about 10 in order to keep the synchronization traffic on your network to a minimum.

  Read/Write partitions can be configured as Filtered replicas. In a regular Read/Write partition, all data from the Master replica is synchronized. In a Filtered replica, you configure replication such that only specific data is replicated from the Master. For example, you may want a partition to only contain user objects. You can configure a filter on the replica that prevents anything, except for user objects, from being copied to the Filtered replica.

• Read-Only replica ” Read-Only replicas are just like Read/Write replicas, except for the fact that they can't be used to make changes to the objects in the tree. That's because they can only receive updates from the Master replica; they can't send them. Read-Only replicas aren't used very often. As with Read/Write replicas, you can create Filtered Read-Only replicas. They aren't all that useful, however ”I've never actually seen anyone use one.

• Subordinate Reference ” The Subordinate Reference (SR) is a tricky entity to understand. SRs aren't really replicas. They contain no partition data. They are really more of a shortcut or a pointer that provides a reference to the location where the real data can be found.

  SRs are automatically created. You can't create them yourself. They are only created when a replica of a partition exists on a given server and that partition has one or more child partitions, but the server does not have a replica of those child partitions. The SR simply points to the servers where a real replica of the child partitions are placed.

The advantages to this partitioning and replication scheme are considerable. The partition aspect distributes the load among several servers, dramatically improving network performance. Replication ensures that multiple copies of each partition are placed on multiple servers in the network.

If one server goes down, the other servers holding replicas of the partition it contains automatically step in and service any network requests . The end user is able to keep working as though nothing happened .

Let's practice working with basic eDirectory concepts in Lab Exercise 5.5.