The following constrains are imposed by the customer:
- Two "read-only" directories in the Internet DMZ network
- Two "read-write" directories in the Internal DMZ network
- All directories must be synchronized at all times
- Internal C# WS is updating "read-write" directories using the following operations:
- Create user, delete user, must change password, temp password, etc'..
- SiteMinder authenticates users against "read-only" directory
- SiteMinder password services are enabled and enforced on "read-only" directory
- SiteMinder must have write permissions to a number of user fields in the "read-only" directories for Password Services to operate as expected
- on "read-only" directories, SiteMinder has to be able to change password blob data and user disabled status
- Directory ports are open between "read-write" directories
- Directory ports are open between "read-only" directories
- Directory ports are open from "read-write" directories to "read-only" directories (not vise-versa)
- Directory ports are open from SiteMinder Policy Servers to "read-only" directories
- No directory routers were implemented
Multi-write with DISP recovery was implemented between all 4 (four) directories
During SiteMinder load tests, we've encountered that the "read-only" directories are trying to sync information from it to "read-write" directories with multiple failures
Although "read-write" directory changes were synced to "read-only" directories instantly, our belief is that those "read-only" multi-write sync failures are causing the changes to queue up in "read-only" directories' queues and by that impact authentication performance
A workaround to multi-write was created using replication agreements, known to all 4 (four) directories.
In that satiation, "read-only" directories do not try to sync "read-write" directories back, but our tests showed lags of couple of seconds to a minute with the replication.
This is a concern to the customer for out-of-sync information for instance in a case of a user changing his password (done against "read-write") but unable to login because "read-only" directory did not sync yet.
Another issue we have noticed in log files, is that the directories are logging "loop detected" in a process of syncing all the directories.
In addition, with further testing, we have seen that during replication (Password data updates from SiteMinder password services), the replicating directory is unavailable for bindings and updates.
What is the best approach to ensure data integrity with above constrains, taking in mind performance?