Skip Navigation Links | |
Exit Print View | |
Oracle Fusion Middleware Administration Guide for Oracle Unified Directory 11g Release 1 (11.1.1) |
1. Starting and Stopping the Server
2. Configuring the Server Instance
3. Configuring the Proxy Components
4. Configuring Security Between Clients and Servers
5. Configuring Security Between the Proxy and the Data Source
6. Managing Oracle Unified Directory With Oracle Directory Services Manager
Configuring Data Replication With dsreplication
To Enable Replication Between Two Servers
To Initialize a Replicated Server
To Initialize an Entire Topology
To Obtain the Status of a Replicated Topology
To Merge Two Existing Replicated Topologies
To Disable Replication For a Specific Replication Domain
Configuring Large Replication Topologies
To Configure a Dedicated Replication Server
Modifying the Replication Configuration With dsconfig
Retrieving the Replication Domain Name
Changing the Replication Purge Delay
How Replication Changes Are Purged
To Change the Replication Purge Delay
Changing the Initialization Window Size
To Change the Initialization Window Size
Changing the Heartbeat Interval
To Change the Heartbeat Interval
To Change the Isolation Policy
Configuring Encrypted Replication
To Configure Encrypted Replication
Configuring Replication Groups
To Configure a Replication Group
Configuring Assured Replication
To Configure Assured Replication in Safe Data Mode
To Configure Assured Replication in Safe Read Mode
Configuring Fractional Replication
To Configure Exclusive Fractional Replication
To Configure Inclusive Fractional Replication
To Configure and Initialize a Fractional Domain
Configuring Replication Status
To Configure the Degraded Status Threshold
Configuring the Replication Server Weight
Initializing a Replicated Server With Data
Initializing a Single Replicated Server
Initializing a New Replicated Topology
Adding a Directory Server to an Existing Replicated Topology
Changing the Data Set in an Existing Replicated Topology
To Change the Data Set With import-ldif or Binary Copy
Appending Data in an Existing Replicated Topology
Enabling the External Change Log in Oracle Unified Directory
How a Client Application Uses the External Change Log in Cookie Mode
Format of External Change Log Entries
To Specify the Attributes to be Included in the External Change Log
Initializing Client Applications to Use the External Change Log
To Initialize a Client Application to Use the External Change Log
Reinitializing a Client Application When a Domain is Added
Reinitializing a Client Application When a Domain is Removed or Disabled
Controlling Access to the External Change Log
Purging the External Change Log
To Disable the External Change Log for a Domain
Configuring Schema Replication
To Specify That Schema Should Not Be Replicated
Replicating to a Read-Only Server
To Configure a Replica as Read-Only
Detecting and Resolving Replication Inconsistencies
Types of Replication Inconsistencies
Purging Historical Replication Data
Replicating Between Oracle Directory Server Enterprise Edition and Oracle Unified Directory
To Migrate the Oracle Directory Server Enterprise Edition Schema and Configuration
To Initialize the Oracle Unified Directory with Oracle Directory Server Enterprise Edition Data
10. Managing Users and Groups With dsconfig
11. Managing Password Policies
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.
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
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.
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.