Using Isolated Replicas

An isolated replica is a directory server that can accept changes from other replicas for replay but cannot send changes to the replication server to which it is connected. An isolated replica cannot be the source of data updates to the topology. You can use isolated replicas to separate a directory server from the rest of the replication topology.

Every directory server in the topology has a trusted configuration property that is set to true by default. Isolated replicas are identified as such by configuring them as untrusted servers in the topology, that is, by setting the trusted configuration property to false. Data that comes from an untrusted directory server is discarded by a replication server. This ensures that an isolated replica cannot be the source of data updates in the replication topology.

Only directory servers are configured as trusted or untrusted. Replication servers do not have the trusted configuration flag.

To configure a directory server as untrusted, use the dsreplication set-trust command, as follows:

$ dsreplication --adminUID admin --adminPassword password -X \
  set-trust --trustedHost host1 --trustedPort 4444 \
  --modifiedHost host2 --modifiedPort 5444 --trustValue untrusted

The dsreplication set-trust command is supported in both interactive and non-interactive modes.

• You can only configure the trust flag of a directory server from another trusted server in the topology. You cannot configure the trust flag from that server itself. The –trustedHost and --modifiedHost options can therefore not refer to the same directory server.

• When you modify a directory server from untrusted to trusted, the host that is being modified must be running, otherwise the command will fail.

• When you modify a directory server from untrusted to trusted, the host that is being modified must not contain any untrusted changes. An untrusted change is a change that has been made on an untrusted directory server and has therefore not been propagated to the rest of the topology. If the host that is being modified contains untrusted changes, the affected suffixes should be re-initialized with an appropriate data set from one of the trusted servers in the topology before the host is modified to trusted.

Use the dsreplication status command to determine whether a directory server is trusted or untrusted. For example:

$ dsreplication status --adminUID admin --adminPassword password -X \
 --hostname host1 --port 4444

dc=example,dc=com - Replication Enabled
=======================================
Server    :Entries:M.C.[1]:A.O.M.C.[2]:Port[3]:Encryption[4]:Trust [5]:U.C.[6]:Status[7]
----------:-------:-------:-----------:-------:-------------:---------:-------:---------
host1:4444:2002   :0      :N/A        :8989   :Disabled     :Trusted  :N/A    :Normal
host2:5444:2002   :0      :N/A        :8989   :Disabled     :Untrusted:0      :Normal

[1] The number of changes that are still missing on this server (and that have been 
    applied to at least one other server).
[2] Age of oldest missing change: the date on which the oldest change that has not 
    arrived on this server was generated.
[3] The port used to communicate between the servers whose contents are being 
    replicated.
[4] Whether the replication communication through the replication port is encrypted 
    or not.
[5] Whether this directory server is trusted or not. Updates coming from an untrusted 
    server are discarded and not propagated.
[6] The number of untrusted changes. These are changes generated on this server while 
    it is untrusted. Those changes are not propagated to the rest of the topology but 
    are effective on the untrusted server.
[7] The status of the replication domain on this directory server.

Deployment Scenarios for Isolated Replicas

There are two main scenarios for using isolated replicas in a replication topology:

• Providing additional security in a demilitarized zone (DMZ)

• Testing client applications in a staging area

Using Isolated Replicas in a DMZ

A demilitarized zone (DMZ) is the area in an enterprise network that is exposed to an untrusted network, such as the Internet. A DMZ provides a layer of protection because it stands between a trusted and untrusted network. Direct access from the outside is limited to the equipment located inside the DMZ. The following figure shows how isolated replicas can be used in a DMZ.

By placing read-only directory servers in the DMZ, you can prevent compromised data from being transmitted to the replication servers in the private area of your network. The servers in the DMZ must be configured to be untrusted to safeguard against malicious data being accepted from them. The servers inside the private area are configured to have read and write access. This configuration ensures that data changes are propagated throughout the replication topology, only by the directory servers in the private area. The read-only directory servers in the DMZ obtain data changes from the replication servers located inside the private network. If an outside attacker attempts to compromise data, the direct access point is a read-only server inside the DMZ. Malicious data cannot be transmitted because directory servers in the DMZ are untrusted. The integrity of the server data inside the private enterprise LAN is therefore protected.

This scenario has the following configuration requirements:

• Each directory server in the DMZ is configured as untrusted and as read-only.

• Each replication server in the topology is located inside the private enterprise LAN.

• Each directory server in the private enterprise LAN is configured as a trusted server with read-write access.

Each trusted directory server in this topology has the following access rights:

• Can send changes to the replication server to which it is connected. Those changes will be propagated to all other directory servers in the topology.

• Can replay changes sent by the replication server to which it is connected.

• Can be the source of an online full update operation to initialize other servers with its data.

Each untrusted directory server in this topology has the following access limitations:

• Is not authorized to send changes to the replication server to which it is connected. If an untrusted directory server sends changes, the changes are evaluated as compromised data, and the replication server discards the changes.

• Can replay changes sent by the replication server to which it is connected.

• Cannot be the source of an online full update operation to initialize other servers with its data.

Using Isolated Replicas for Testing

Isolated replicas can be useful to test an application against live data in a staging area. This can be accomplished by configuring the isolated replicas to be untrusted, but with read and write access. The application's access point is the isolated replica and data is written only to the isolated replicas in the staging area.

The following figure shows how isolated replicas can be used in a staging area.