Installing and Configuring the DirXML eDirectory Driver

Test Objective Covered:

5. Implement the eDirectory driver for DirXML.

The DirXML eDirectory driver is a very useful tool. Consider the following hypothetical (although quite common) situation: Suppose ABC, Inc. purchases a smaller company and both companies have their own eDirectory trees populated with network information.

What would the network administrators need to do in order to manage the disparate trees? Prior to DirXML, there were three options:

• Do nothing and maintain separate trees. This isn't a good solution. To provide users in each tree access to network resources, they must maintain duplicate sets of accounts in each tree.

• Re-create data from one tree in the main tree. This can be done manually or by using LDIF export files. Either way, this represents a sizeable task.

• Merge the trees. Two eDirectory trees can be merged together. However, this can be a difficult and dangerous endeavor (ask anyone who has done it in a production environment).

DirXML offers a fourth option that is easier and safer than the others. Using the eDirectory driver, the ABC, Inc. administrator can synchronize data between the trees. He can configure one tree to be the authoritative data source, sending but not receiving updates. He can configure the other tree to be a data consumer, receiving but not sending updates.

Alternatively, he can configure a bidirectional system where changes in either tree are immediately synchronized to the other. Whichever approach is selected, this is done the same as with other DirXML drivers, by implementing publisher and subscriber channel filters.

This driver can be a useful tool in a variety of circumstances, including situations such as company acquisitions (mentioned earlier) and consolidating a multitree organization. It can also be implemented in situations where an organization has deployed an LDAP-compliant application that expects all directory information to reside in a single container (this happens frequently).

Using the eDirectory driver, you can configure a second tree in your organization and synchronize all directory data from your production tree (which is hierarchical) to the secondary tree (which is flat).

About the DirXML eDirectory Driver

The eDirectory driver is unique among the various DirXML drivers. With most drivers, there is a driver installed for the third-party database. Only one instance of DirXML is installed and configured, as shown in Figure 7.20.

Figure 7.20. Using DirXML with a third-party database.

When you're using the eDirectory driver, however, things are little bit different. First of all, DirXML is installed on both servers that have trees to be synchronized. Second, an eDirectory driver is configured on both servers, as shown in Figure 7.21.

Figure 7.21. Using DirXML with eDirectory.

Another (third) difference is in the way the publisher and subscriber channels are configured. To understand this, let's use the analogy of how to make a null modem cable out of a serial cable. All you have to do is rewire the cable plug such that the Tx (transmit) wire in the cable connects to the Rx (receive) wire in the serial port plug on the PC. Configured this way, transmitted data is sent from the Tx wire to the Rx wire in the port, and vice versa.

Essentially, you have the same situation with the DirXML eDirectory driver. Because you have two drivers and two DirXML engines, you have two publisher channels and two subscriber channels.

The eDirectory drivers are configured such that the publisher channel in one tree is connected to the subscriber channel in the other, and vice versa. This is depicted in Figure 7.21.

This can complicate things a bit for the NNLS implementer. It means that information travels first through the first tree's subscriber filter ”having all its rules and filters applied ”and then through the other tree's publisher channel ”having all its rules and filters applied.

Having set this kind of implementation up several times, I can tell you that if you can keep this one point in mind, it will make configuring the eDirectory driver much easier for you. My experience has been that it is very easy to think from the standpoint of one tree or the other, but not both at the same time. By forgetting that the subscriber channel becomes the publisher channel, and vice versa, you can potentially make grievous mistakes when configuring your drivers.

You also need to be concerned with object placement. With most other DirXML drivers (with the exception of the Active Directory driver), data is being synchronized with a flat-file database. Object placement in this situation is rather easy. If you're good with the XML markup language, you can even customize your placement rule such that placement is based on a particular attribute.

For example, you can configure the rule such that if the PeopleSoft database shows an employee's address to be in Idaho Falls, Idaho, DirXML automatically creates the associated user object in the IF.CLE container. If the employee's address is in Salt Lake City, Utah, on the other hand, the object is created in the SLC.CLE container.

The fact that one system in the implementation is flat makes this kind of configuration relatively easy. With the eDirectory driver, however, you're dealing with a hierarchical system on both ends of each driver. As a result, object placement becomes more complicated.

As mentioned, it is critical that you think systemically when configuring the eDirectory drivers' placement rules. You must consider how data flows in the system to properly configure the rules. If you don't, you're going to spend a lot of time looking at your tree wondering, "Why is that object being synchronized there?"

Because writing customized placement rules requires a fair amount of XML knowledge (which you don't need to know for the CLE exam), the eDirectory driver includes several predefined placement options that you can use. These options are what we will focus on in this book. They are listed in Table 7.3.

Table 7.3. DirXML eDirectory Driver Placement Options

OPTION	DESCRIPTION
Flat	This option allows you to define a base container for user objects and a base container for group objects in the destination tree.
	All objects (users and groups) from the source tree are placed in their respective base container in the destination tree, regardless of where they existed in the source tree's hierarchy.
	For example, suppose you specify that the base user container for the destination tree to be .IF.CLE. If you synchronized KRitter.IS.PROVO.NOVELL and JCarr.IS.CAMBRIDGE.NOVELL to this tree, they would both be synced to the IF.CLE container.
Mirrored	This option allows you to specify a base container in the destination tree. When data is synchronized, the original hierarchical structure from the source tree is replicated within the base container in the destination tree.
	For example, if you specified the base container to be IF.CLE and were to synchronize the same user objects listed previously, the result would be a user object named KRitter.IS.PROVO.NOVELL.IF.CLE and a user object named JCarr.IS.CAMBRIDGE.NOVELL.IF.CLE.
Department	This option is similar to the mirrored option. However, instead of the entire source tree hierarchy in the base container you specified in the destination tree being mirrored, only the parent container of the object is created.
	For example, if you configured a base container of IF.CLE and were to synchronize the same user objects listed previously from the source tree, the result would be a user object named KRitter.IS.IF.CLE and a user object named JCarr.IS.IF.CLE.

As with other DirXML drivers, the eDirectory driver requires that the server where DirXML is installed have either a Read/Write or a Master replica of the partition where the data to be synchronized resides. The DirXML engine needs to be able to write data as well as read it; therefore, Read Only or Subordinate Reference replicas won't work.

Let's discuss how to configure the eDirectory driver.

Configuring the eDirectory Driver

As with the Delimited Text driver, the eDirectory driver is automatically installed along with the DirXML component of NNLS. To configure this driver in a DirXML system, you would complete the following steps:

Warning

Wait until the upcoming lab exercise to implement this driver. The following steps are generic steps .

1. Run a web browser and open iManager by accessing https :// your_server_IP_address /nps/iManager.html.
   
   
2. Authenticate as your admin user.
   
   
3. Under the DirXML Management role, select the Create Driver task.
   
   
4. In the Create Driver Welcome screen, select the In a new driver set option and then click Next .
   
   
5. In the Name field, enter a name for your Driver Set object in the eDirectory tree.
   
   
6. In the Context field, browse to and select the container in your tree where you want your Driver Set object created.
   
   
7. In the Server field, browse to and select the server you want to associate with the Driver Set object.
   
   
8. Check Create a new partition on this driver set .
   
   
9. Click Next . The screen shown earlier in Figure 7.9 appears.
   
   
10. Mark Import a pre-configured driver from the server (.XML file) .
    
    
11. From the drop-down list, select the eDIR-Driver.xml driver.
    
    
12. Click Next . The screen shown in Figure 7.22 appears.
    
    

    Figure 7.22. Configuring the eDirectory driver.

    

    
    
13. In the Driver Name field, enter a name for this driver.
    
    
14. In the Remote Tree Address and Port fields, enter the IP address of the server running DirXML in the remote tree. The port number should be set to 8196 .
    
    
15. In the Configure Data Flow drop-down list, select the role the local server will play. You have the following options:
    
    

    • Bidirectional ” Selecting this option will configure the driver to send synchronization events to the remote tree and to accept incoming synchronization events.

    • Authoritative ” Selecting this option will configure the driver to send synchronization events to the remote tree, but it will not accept incoming synchronization events.

    • Subordinate ” Selecting this option will configure the driver to accept incoming synchronization events, but not to send them.

16. In the Configuration Option drop-down list, select the placement option you wish to use. You can select from the following:
    
    

    • Mirrored

    • Flat

    • Department

    The function of these options was presented earlier in this chapter. The one you choose depends on the way you want your DirXML system to work. The files that configure these placement options are located in /usr/lib/dirxml/rules/nds2nds .
    
    
17. If you selected the Mirrored option, enter the desired base container for synchronization in the Remote Base Container field.
    
    
18. In Base Container field, enter the base container for synchronization in the local tree. If you selected Mirrored , this is the local base container to mirror with the remote base container from step 17. If you selected Flat , this is the container to place users into. If you selected Department , this is the parent of the departmental containers.
    
    
19. If you selected the Flat option, enter the base container in the local tree to place synchronized groups into in the Group Container field.
    
    
20. Select Next . The screen shown in Figure 7.23 is displayed.
    
    

    Figure 7.23. Configuring security equivalences and exclusions for the eDirectory driver.

    

    
    
21. Assign rights to the driver object in the tree by completing the following steps:
    
    

    1. Select Define Security Equivalences .
       
       
    2. Click Add .
       
       
    3. Browse to and select a user object that has administrative rights to the tree.
       
       
    4. Click OK .
       
       
22. Keep your admin user object from being synchronized by completing the following steps:
    
    

    1. Select Exclude Administrative Roles .
       
       
    2. Click Add .
       
       
    3. Browse to and select your admin user object.
       
       
    4. Click OK .
       
       
23. Click Next . The summary screen shown in Figure 7.24 is displayed.
    
    

    Figure 7.24. The DirXML eDirectory Driver Summary screen.

    

    
    
24. Click Finish with Overview . The DirXML Overview screen is displayed, as shown in Figure 7.25.
    
    

    Figure 7.25. DirXML Overview with a stopped eDirectory driver.

    

    
    
25. Repeat all these steps to configure the eDirectory driver on the server in the other tree.
    
    
26. When configuration of both drivers is complete, start them by selecting the red circle with the minus sign icon; then select Start Driver .
    
    
27. Wait while the drivers start.
    
    
28. When the drivers have started, the red circle changes to a yin-yang icon.
    
    

Remember that the eDirectory driver is an evaluation driver. If you don't activate it within 90 days, the driver will shut down. To activate the driver, select the Activation Required link displayed in the top-right corner of the DirXML Overview page.

At this point, you should edit the filters and rules for each channel on each server to configure the dataflow in the manner you desire . Remember that DirXML is event driven. Just having the drivers installed and configured will not automatically synchronize the two trees. As you will see later in the chapter, you can initially synchronize the two trees using the Migrate from eDirectory and the Migrate to eDirectory options in iManager.

Let's practice implementing the DirXML eDirectory driver and configuring these parameters in Lab Exercise 7.3.