System Object Properties - Active Directory Lightweight Services (AD LDS) cross-domain replication

Windows Active Directory Lightweight Services (AD LDS) Replication does not provide replication across non-trusted domain boundaries. For example, the boundary between the production system and a decision support system running within the demilitarized zone, unless it's the same username and password, are reused between the non-trusted domains. As the username and password synchronization between systems is considered unacceptable, a different method of replicating AD LDS data between non-trusted systems is needed. To resolve this issue, the AVEVA Enterprise SCADA AD LDS Cross-Domain Replication is used to transfer changes made to select AD LDS objects (for example, Area of Responsibility [AOR] Areas, AOR Groups) to other systems across non-trusted domain boundaries.

The AD LDS replication occurs in only one direction, from a sending system out to any receiving system configured to receive the AD LDS data. With each AD LDS object creation, deletion, or modification at the receiving system, a Windows Event Log message is recorded in the same event log location that the Network Management Console (NMC) messages are stored (for example, within the Applications and Services Logs for Active Directory Application Mode (ADAM) (OASySDNACore)). Because AD LDS replication relies on the Inter-System Publish/Subscribe (ISPS) service, the ISPS health state topic is monitored and Windows Events are logged when the ISPS health state changes.

AD LDS Cross-Domain Replication does not include object memberships that are Windows Groups / Users from the sending system (as they are domain specific). Memberships that are Private OASyS DNA Groups / Users are transferred to the cross-domain receiving systems. However, they are not automatically removed at the receiving system and require manual removal by the System Administrator after confirming that no users at the cross-domain receiving system rely on the Private OASyS DNA Group / User membership.

The NMC at the receiving system disables action menu items and properties in order to prevent actions that will be overwritten by replication from the sending system. If the folder node is configured to receive data from the AD LDS Cross-Domain Replication, then the NMC will only allow changes to object memberships and the AD LDS Cross-Domain Replication action menu items to request replication updates.

The AD LDS Cross-Domain Replication sender periodically compares a snapshot of the AD LDS objects configured for replication against the current AD LDS contents. If recent NMC changes need to be immediately replicated, the NMC action at the object’s folder node can be used to force the sender to immediately compare and send changes.

The AD LDS Cross-Domain Replication receiver operates using one of two modes; it receives updates either automatically or only when manually requested using the NMC.

Important: If an AD LDS client can receive data within the current ADLDS realm from the desired sender, do not configure this system as a receiver, as this can cause undesired circular replication.

Notes: After changing the AD LDS Cross-Domain Replication configuration, the affected sending and/or receiving host should be restarted for the replication changes to take effect. If the host represents a redundant host, then both hosts will need to be restarted.

To prevent conflicts and duplicated groups or areas on domains with more than one system, it is necessary that only one system per domain is configured to receive data from another domain. This system will synchronize groups and areas with all others automatically.