Multireplication

This chapter describes how to set up a directory service based only on shadowing in which pieces of a DIT held by two different DSAs are replicated to each DSA.The chapter describes a sample shadow configuration with the following characteristics:

The first DSA is the sample stand-alone DSA established in the chapter “Setting up the DirX Directory Service”.It holds the master My-Company entries that are replicated to the DSA established in the chapter “Distributing the DIT across Multiple DSAs“, and also holds shadow entries from this DSA.
The second DSA is another stand-alone DSA that masters entries from another company.These entries are replicated to the first DSA.The second DSA also holds as shadow all entries from the first DSA.

This chapter continues to use the fictitious company “My-Company” to illustrate the planning decisions and administrative tasks necessary to set up this sample shadow configuration.

Tcl scripts for building this sample shadow configuration and adding the extensions to it can be found in the directory install]path/_scripts/multireplication.These scripts contain all the commands and procedures discussed in this chapter.

Planning the Shadow Configuration

My-Company has acquired a sales partner in the United States: the STU company in Boston, Massachusetts.My-Company has already established a single stand-alone DSA at the company’s Munich headquarters that contains the employee directory of its Sales and Development departments.The STU company has also established a stand-alone DSA in Boston that contains its company employee directory.

In order to optimize the contacts and speed the work coordination between the two companies, My-Company and STU decide that My-Company’s Sales and Development employee directories and STU’s entire employee directory should be available locally at each site.They also determine that My-Company’s Manufacturing employee directory, located on a DSA in Durach, need not be as highly available to the STU company as its Sales and Development directories.Consequently, the My-Company and STU companies decide to replicate My-Company’s Sales and Development employee directory on the DSA in Boston, and to replicate the STU company’s employee directory on the DSA in Munich.The following figure illustrates this solution.

Figure 1. My-Company-STU Shadow Configuration

Building the Shadow Configuration

Recall from the chapter “Creating a Shadow DSA” that a DSA that holds the information to be replicated is the supplier DSA, while the DSA that receives the information is the consumer DSA.In this case, each DSA plays both supplier and consumer roles:

DSA1 is a supplier of DSA4, since it holds the master My-Company employee entries that will be replicated to DSA4, and is also a consumer of DSA4, since it holds shadows of the STU employee entries that DSA4 masters.
DSA4 is a supplier of DSA1, since it holds the master STU employee entries that will be replicated to DSA1, and a consumer of DSA1, since it holds shadows of the My-Company Sales and Development entries that DSA1 masters.

Recall from section “Shadowing in a Heterogeneous Network” in the chapter “Creating a Shadow DSA“, that DirX Directory supports two kinds of shadowing: central shadowing administration (CENTRALADMIN) and X.500 compliant shadowing (X500).Central shadowing administration is easier to handle than X.500 compliant shadowing because shadowing agreements are administrated once on a single DSA and distributed by shadowing itself.My-Company’s DSA1 is already the DSA for the central shadowing administration.STU also uses DirX Directory and DSA4 is not yet part of any other central shadowing.The administrators decide to connect DSA4 to the already established central shadowing.

The administrator for DSA1 must therefore create two shadowing agreements:

A shadowing agreement in which DSA1 is the supplier and DSA4 is the consumer and in which the information to be replicated is the Sales and Development organizational-units of the subtree /O=My-Company.The Manufacturing employee subtree OU=Manufacturing, which resides on DSA3 in Durach, will not be replicated to the STU DSA.
A shadowing agreement in which DSA4 is the supplier and DSA1 is the consumer and in which the information to be replicated is the subtree /O=STU.

The administrator can perform these steps locally on his DSA by binding to the DSA with the dirxadm bind command and then issuing dirxadm commands.Alternatively, the administrators can use DirX Directory Manager from a Windows system to bind to DSA1 to perform these tasks.The next sections describe how to perform these tasks with dirxadm.

Negotiating the Shadowing Agreements

The administrators of DSA1 and DSA4 must first establish the details of the two shadowing agreements between their two DSAs.These details include:

Determining the DSA roles and identifying the names, presentation addresses, and passwords of each DSA
Determining the units of replication
Determining the shadowing agreement Ids
Determining the update strategy

Determining the DSA Roles

For My-Company in Munich, DSA1 is to be both a supplier DSA and a consumer DSA. Its distinguished name is /CN=DirX-DSA-host1 and it has the following presentation address:

Transport selector:

DSA1

Network address:

Internet address:

123.45.67.89

port number:

19999

For STU in Boston, DSA4 is to be both a supplier DSA and a consumer DSA. Its distinguished name is /CN=DirX-DSA-host4, and it has the following presentation address:

Transport selector:

DSA4

Network address:

Internet address:

111.22.33.55

port number:

24444

The password for DSA1 is M8921DSA1 and the password for DSA4 is B4321DSA4.

Determining the Unit of Replication

For My-Company in Munich, the unit of replication is the entire naming context /O=My-Company. All entries within this naming context will be duplicated and all attributes will be duplicated. (The Organizational-Unit Manufacturing is a separate naming context that resides in another DSA).

For STU in Boston, the unit of replication is the entire naming context /O=STU, which will be replicated to the My-Company DSA in Munich (DSA1).

Determining the Agreement Ids

In this shadow configuration, DSA1 and DSA4 share two agreements: one in which the partner DSA is the consumer, and one in which the partner DSA is the supplier.The administrators of DSA1 and DSA4 must choose unique identifiers for each of these agreements.The administrators select:

ID 14,0 to identify the shadowing agreements in which DSA1 is the supplier and DSA4 is the consumer
ID 41,0 to identify the shadowing agreements in which DSA1 is the consumer and DSA4 is the supplier

After creating these shadowing agreements on DSA1 they are distributed to DSA4 by shadowing itself.

Using dirxadm to Prepare DSA4 for Shadowing

Now the two administrators have negotiated the details of the shadowing agreements.Even though that the shadowing agreements are all administered on My-Company’s DSA1 the administrator of STU’s DSA4 must prepare his DSA for shadowing operations.So his next step is to use dirxadm to:

Perform an authenticated administrator bind to DSA4, which is the local DSA
Create a DSA policy on DSA4 that allows DSA1 to initiate a DISP communication with DSA4.
Change the default password on DSA4.

Binding with Authentication to DSA4

In the process of setting up the STU stand-alone DSA, the STU administrator has:

Established himself as the default administrator with the distinguished name /O=STU/CN=admin
Selected to use simple authentication using the password dirx
Added his distinguished name to the DirX Directory administrators attribute on DSA4 to allow him to bind with dirxadm

The STU administrator must now bind with authentication to DSA4 in order to use dirxadm to set up the DSA for shadowing.

To bind to a local DSA, use the dirxadm command:

bind -user username -password password -authentication auth_]method

To bind with simple authentication to the local DSA, which in this case is DSA4, the STU administrator issues the dirxadm command:

bind -user /O=STU/CN=admin -password dirx -auth SIMPLE

Creating the DSA Policy on DSA4

Recall from the chapter “Creating a Shadow DSA” that DSAs must be protected from unknown or untrustworthy DSAs trying to connect to them for unknown purposes. When the administrator for DSA1 establishes the shadowing agreement, DSA1 will try to contact DSA4 to start the total update. Consequently, DSA4 needs a mechanism to identify whether the connecting DSA is DSA1 or whether it should reject the connection.

The mechanism used to screen connecting DSAs is the DSA policy, which contains the names and passwords of all DSAs permitted to connect to a given DSA. To enable DSA4 to recognize DSA1, the administrator of DSA4 creates a DSA policy that contains DSA1’s name and password.

To create a DSA policy, use the dirxadm command:

dirxadm> [dse] modify / -addattribute attribute]list_

The modify operation is performed on the root DSE because the DSA-policy structured attribute (DSAP) is an attribute of the root DSE.

The attribute list must contain the DSA-policy (DSAP) attribute with the following components:

The DSA-name component (DSA), which in this example has the value /CN=DirX-DSA-host1, which is DSA1’s name.
The password (PWD) subcomponent of the authentication-policy (AP) component which in this example has the value M8921DSA1, which is DSA1’s password.

The following dirxadm command creates STU-DSA4’s DSA policy:

modify / -addattr \
			 {DSAP={DSA={/CN=DirX-DSA-host1},   \
		           AP={PWD=M8921DSA1}
               }
         }

Changing the Default Password on DSA4

Recall from the chapter "Creating a Shadow DSA" that every DirX Directory DSA has, after its installation, the default password DSA; this value is hard-coded and is not visible. Since the My-Company and STU administrators have decided to use different passwords for their DSAs and the DSA policy for DSA1 will be set up to expect a password from DSA4 of B431DSA4, the administrator on DSA4 needs to modify the DSA policy to contain this password.

To change a DSA password, use the dirxadm command:

[dse] modify / -addattribute attribute]list_

The STU DSA4 administrator must specify the following:

The DSA-policy (DSAP) attribute in attribute]list_ with the following values:
- The / character in the DSA-name (DSA) component. The DSAP attribute can contain several types of policies (it is a multivalued attribute). If the name of a DSA is explicitly specified, the policy applies only to the named DSA. If “/” is specified as the DSA name, this policy applies to all other DSAs; that is, those DSAs for which no specific policy exists.
- The password (PWD) component contains the value B4321DSA4, which is the password for DSA4

The following dirxadm command establishes DSA4’s password:

   modify / -addattr {DSAP{DSA={/},
                           AP={PWD=B4321DSA4}
                     }

Using dirxadm to Prepare DSA1 for Shadowing

The administrator of My-Company’s DSA1 must perform the same procedures on DSA1 as the STU DSA4 administrator has done on DSA4. Since the My-Company DSA1 administrator has already changed DSA1’s default password to M8921DSA1 when he created the shadowing agreement with DSA2 described in the chapter “Creating a Shadow DSA”, he need only:

Perform an authenticated administrator bind to DSA1, which is the local DSA
Create a DSA policy on DSA1 that allows DSA4 to initiate a DISP connection with DSA1.
Create two shadowing agreements on DSA1, one for the consumer role and one for the supplier role.

Binding with Authentication to DSA1

In the process of setting up the My-Company stand-alone DSA DirX-DSA-host1 described in the section "Setting up the DSA" in the chapter "Setting up the DirX Directory Service", the My-Company administrator has:

Established himself as the default administrator with the distinguished name /O=My-Company/CN=admin
Selected to use simple authentication using the password dirx
Added his distinguished name to the DirX Directory administrators attribute on DSA1 to allow him to bind with dirxadm

The My-Company administrator must now bind with authentication to DSA1 in order to use dirxadm to set up the DSA for shadowing.

To bind with simple authentication to the local DSA, which in this case is DSA1, the My-Company administrator issues the dirxadm command:

bind -user /O=My-Company/CN=admin -password dirx -auth SIMPLE

Creating the DSA Policy on DSA1

To create the DSA policy on DSA1, the My-Company DSA1 administrator uses the same dirxadm command as the STU DSA4 administrator used on DSA4:

dirxadm> [dse] modify / -addattribute attribute]list_

For DSA1, the attribute list must contain the DSA-policy (DSAP) attribute with the following components and values:

The DSA-name component (DSA) with the value /CN=DirX-DSA-host4, which is DSA4’s name.
The password (PWD) subcomponent of the authentication-policy (AP) component with DSA4’s password B4321DSA4.

The following dirxadm command creates My-Company-DSA1’s DSA policy:

modify / -addattr \
			 {DSAP={DSA={/CN=DirX-DSA-host4},
		           AP={PWD=B4321DSA1}
               }
         }

Creating the Shadowing Agreements on DSA1

To create the two shadowing agreements on DSA1, the My-Company DSA1 administrator uses the dirxadm sob create command.

Creating the Agreement for O=My-Company Shadowed From DSA1 to DSA4

To create the shadowing agreement on DSA1 that describes DSA1 as a supplier and DSA4 as a consumer, the administrator supplies the following values:

The name of DSA4 to the -consumer option
The presentation address of DSA4 to the -consumerpsap option
The keyword CENTRALADMIN to the -consumerkind option, which specifies a DirX-Directory-compliant/asynchronous shadowing
The agreement identifier 14,0
The keyword COOPERATIVE to the -status option, which means that DSA1 will be ready to send a total update to DSA4 immediately
The shadowing-subject (SS) operational attribute to the -agreement option, which defines:
- The name of the context prefix (CP) to be replicated in the AREA component. In this agreement, it is DSA1’s context prefix /O=My-Company.
- The entries belonging to this naming context to be replicated in the replication-area (RA) subcomponent. In this agreement, the value is DEF=TRUE, which means that the whole naming context must be replicated.
- The attributes to be replicated in the ATT subcomponent. In this agreement, the value is DEF=TRUE to indicate that all attributes are to be replicated.
- The update mode in the update-mode (UM) component. In this agreement, the value is SI (supplier-initiated).
- The update strategy in periodic-strategy (PS) of the update-mode (UM) component. In this agreement, the strategy specifies a one-hour window in which DSA4 will accept updates (specified as 3600 seconds in the window-size (WS) subcomponent and schedules subsequent incremental updates once every 24 hours (specified as 82800 seconds in the update-interval (UI) subcomponent)

The administrator can omit the -supplier option (the name of DSA1) and the -supplierpsap option (presentation address of DSA1) because DSA1 is the supplier DSA and the administrator is bound to DSA1.

The following dirxadm command creates this shadowing agreement on DSA1:

sob create
-consumer {/CN=DirX-DSA-host4 }     \
-consumerpsap "TS=DSA4,NA='TCP/IP!internet=111.22.33.55+port=24444'"  \
-consumerkind CENTRALADMIN \
-agreementid 14,0       \
-status COOPERATIVE \
-agreement {SS={AREA={CP={/O=My-Company},
                      RA={DEF=TRUE}
                     },
                ATT={DEF=TRUE}
               }
           },         \
           UM={SI={S={PS={WS=3600,
                          UI=82800
                         }
                      }
                  }
              }

Creating the Agreement for O=STU Shadowed From DSA4 to DSA1

To create the agreement that describes DSA1 as a consumer and DSA4 as a supplier, the administrator supplies the following values. (Keep in mind that this agreement is also created on DSA1.):

The name of DSA4 to the -supplier option
The name of DSA1 to the -consumer option
The agreement identifier 41,0
The keyword NONCOOPERATIVE to the -status option, which postpones the first total update from DSA4 to DSA1 until the DSA1 administrator explicitly activates it by establishing the shadowing agreement.
The shadowing-subject (SS) operational attribute to the -agreement option, which defines:
- The name of the context prefix (CP) to be replicated in the AREA component. For this agreement, it is DSA4’s context prefix, which is /O=STU.
- The entries belonging to this naming context to be replicated in the replication-area (RA) subcomponent. For this agreement, the value is DEF=TRUE, which means that the whole naming context must be replicated.
- The attributes to be replicated in the ATT subcomponent. For this agreement, the value is DEF=TRUE to indicate that all attributes are to be replicated.
- The update mode and periodic update strategy in the update-mode (UM) component. For this agreement, the update mode is supplier-initiated, with incremental updates occurring every 24 hours and a one-hour window during which DSA1 will accept the updates.

The administrator can omit the -supplierpsap option (presentation address of DSA4) because this attribute was already administered when creating the agreement where DSA4 is consumer. He also can omit the -consumerpsap option because this attribute was already administered.

The following dirxadm command creates this shadowing agreement on DSA1:

sob create
-supplier {/CN=DirX-DSA-host4 }     \
-consumer {/CN=DirX-DSA-host1 }      \
-agreementid 41,0       \
-status NONCOOPERATIVE \
-agreement {SS={AREA={CP={/O=STU},
                      RA={DEF=TRUE}
                     },
                ATT={DEF=TRUE}
               }
           },         \
           UM={SI={S={PS={WS=3600,
                       UI=82800
                         }
                      }
                  }
              }

Using dirxadm to Activate the Shadowing Agreements

When the administrator created the shadowing agreements that described DSA1’s consumer role, the administrator postponed shadowing activation by specifying the keyword NONCOOPERATIVE in the -status option to the dirxadm sob create command.Both administrators must now explicitly activate the shadowing agreement with the dirxadm command:

sob establish –agreementid agreementid -consumer dsa]name_

My-Company’s DSA1 administrator uses the following dirxadm command to start the total update from DSA4 to DSA1:

sob establish -agreementid 41,0      \
-consumer {/CN=DirX-DSA-host4 }

Setting DUA Service Controls for Binds to Consumer DSAs

As described in the chapter “Creating a Shadow DSA”, DUAs that bind to a consumer DSA to get local shadowed information from it should set two service controls:

dontUseCopy to FALSE; if the value is TRUE, the consumer DSA understands that the DUA wants master Information and chains to the supplier DSA.
copyShallDo to TRUE, which means that the consumer DSA will perform a query even if some information is missing in the shadow copy.If the consumer DSA is not able to completely satisfy the query, it will set IncompleteEntry in the returned entry information.

When using dirxcp as a DUA, these service controls can be set with the following dirxcp command:

args modify -dontusecopy FALSE -copyshalldo TRUE