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 (loaded from the Complete_DB.ldif file).

  • 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.

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. 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 and STU’s entire employee directory should be available locally at each site. The My-Company and STU companies decide to replicate My-Company’s 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.

My-Company-STU Shadow Configuration
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 entries that DSA1 masters.

Recall from section Shadowing in a Heterogeneous Network, 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.

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 subtree /O=My-Company.

  • 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 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 of My-Company and a consumer DSA of STU. 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 of STU and a consumer DSA of My-Company. 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 DSA4’s password 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.

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 DSA1 and 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. The next steps use dirxload and dirxadm to:

  1. Create the DSA4 database with the STU employee entries.

  2. Perform an authenticated administrator bind to DSA4, which is the local DSA

  3. Create shadowing agreements on DSA1

  4. Start the replication by activating the agreement 41,0 on DSA1.

  5. Create DSA policies on DSA4 that allow DSA1 to initiate a DISP communication with DSA4.

  6. Change the default password on DSA4.

  7. Create DSA policies on DSA1.

Create the DSA4 Database with the STU Employee Entries

Create a new stand-alone DSA for the STU company. To fill the DSA with employee data take the _install_path\Directory\scripts\multireplication\STU_DB.ldif and use the following command to load the STU employee entries:

dirxload -f STU_DB.ldif

STU LDAP configuration must be different from the default LDAP configuration, because the LDAP server must know which configuration to use when it starts. DSA4 will use STU_LDAP_CFG. DSA1 will use the default ldapconfiguration. In STU_DB.ldif file the LDAP configuration is already set, but DirX service must be configured as follows on DSA4:

a) If you are using dirx server set DIRX_DEFAULT_LDAP_SERVER environment variable to STU_LDAP_CFG and restart dirx service.

b) If you start dirxldapv3 service manually use -n STU_LDAP_CFG option.

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

Binding with Authentication to DSA1

DSA1 is built up from the Complete_DB.ldif. In the process of setting up the My-Company stand-alone DSA DirX-DSA-host1 described in the section Setting up the DSA, 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 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 must set 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 is On Change (OC) update.

The following dirxadm command creates this shadowing agreement on DSA1:

sob create \
  -consumer {/CN=DirX-DSA-host4} \
  -consumerpsap "TS=DSA4,NA='TCP/IP_IDM!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={OC=TRUE
                     }
                 }
             }

After the agreement is created, the /my-company database will start replicating to DSA4.

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 must set 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 update strategy is On Change (OC) update.

The following dirxadm command creates this shadowing agreement on DSA1:

sob create \
  -supplier {/CN=DirX-DSA-host4} \
  -supplierpsap "TS=DSA4,NA='TCP/IP_IDM!internet=111.22.33.55+port=24444'" \
  -consumer {/CN=DirX-DSA-host1} \
  -consumerkind CENTRALADMIN \
  -consumerpsap "TS=DSA1,NA='TCP/IP_IDM!internet=123.45.67.89+port=19999'" \
  -agreementid 41,0 \
  -status NONCOOPERATIVE \
  -agreement {SS={AREA={CP={/O=STU},
                        RA={DEF=TRUE}
                       },
                  ATT={DEF=TRUE}
                 },
              UM={SI={OC=TRUE
                     }
                 }
             }

Activating the Shadowing Agreements

When creating the shadowing agreement for DSA1’s consumer role (agreement 41,0), the administrator specified -status NONCOOPERATIVE, which postpones the initial total update until it is explicitly activated.

To activate a postponed agreement, use the following dirxadm command:

dirxadm> sob establish -agreementid agreementid -supplier supplier_dsa_name -consumer _dsa_name

Since this configuration uses central shadowing administration (CENTRALADMIN), the command only needs to be run once — on DSA1, where all agreements are administered. The activation is then automatically distributed to DSA4.

The DSA1 administrator activates the agreement with:

sob establish -agreementid 41,0 -supplier {/cn=DirX-DSA-host4} -consumer {/CN=DirX-DSA-host1}
The -consumer option must specify the consumer DSA name exactly as it appears in the agreement (see the -consumer parameter in the sob create command). In agreement 41,0 DSA4 is the supplier and DSA1 (/CN=DirX-DSA-host1) is the consumer.

After activation, DSA4 initiates the total update and sends the /O=STU naming context to DSA1.

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:

[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 first dirxadm command creates DSA policy on DSA4:

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 B4321DSA4, 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. Specifying "/" as the DSA name creates a default policy that applies to any DSA for which no specific policy exists.

The following dirxadm command establishes DSA4’s password:

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

Using dirxadm to Create DSA Policy on DSA1

The administrator of My-Company’s DSA1 must perform the same procedures on DSA1 as the STU DSA4 administrator has done on DSA4. He needs to:

  1. Perform an authenticated administrator bind to DSA1, which is the local DSA

  2. Create a DSA policy on DSA1 that allows DSA4 to initiate a DISP connection with DSA1.

Creating the DSA Policy between DSA1 and DSA4

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=B4321DSA4}
               }
         }

The following command sets DSA1’s default password.

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

Replication of Subordinate References

If the naming context being shadowed contains a subordinate reference to a subtree mastered by another DSA, only the reference itself is replicated to the consumer DSA — the entries below it are not included.

This is because those entries belong to a separate naming context, mastered by a third DSA. In the example in the Distributing the DIT across Multiple DSAs, if DSA1’s /O=My-Company naming context contained a subordinate reference to /O=My-Company/OU=Manufacturing on DSA3, shadowing /O=My-Company to DSA4 would replicate the reference to DSA3, but not the Manufacturing entries themselves.

Access Control for Multireplication

Administrators of My-Company and STU must give access control to view the other company’s entries.

To grant administrators read and browse access rights to the /o=STU database subentries, the SACI attribute must be configured in the DSA4 /o=STU entry.

To grant administrators access to the /o=STU database entries the PACI value must be set in the /O=STU/CN=AccessControl-Subentry of DSA4.

DSA1 /o=my-company access must be set in the same way in DSA1 to give them access to the /o=STU subentries and entries with My-Company admin.

In our example in STU.ldif database these values are already set.

See details in Distributing the DIT across Multiple DSAs chapter under Building the Subordinate DSA.

Setting DUA Service Controls for Binds to Consumer DSAs

DUAs that query a consumer DSA should set two service controls to ensure they receive shadow data rather than being redirected to the master (see the chapter “Creating a Shadow DSA”):

  • dontUseCopy = FALSE — Tells the DSA that shadow (copy) data is acceptable. If set to TRUE, the consumer DSA chains the request to the supplier DSA to obtain master data instead.

  • copyShallDo = TRUE — Tells the DSA to answer the query even if some attributes are missing from the shadow copy. If the query cannot be fully satisfied, the DSA sets the IncompleteEntry flag in the response.

With dirxcp use the command:

args modify -dontusecopy FALSE -copyshalldo TRUE