CA Directory Replication Issue

[Michael_Kipnis]

Dear all,

 

The following constrains are imposed by the customer:

1. Two "read-only" directories in the Internet DMZ network
2. Two "read-write" directories in the  Internal DMZ network
3. All directories must be synchronized at all times
4. Internal C# WS is updating "read-write" directories using the following operations:
   1. Create user, delete user, must change password, temp password, etc'..
5. SiteMinder authenticates users against "read-only" directory
6. SiteMinder password services are enabled and enforced on "read-only" directory
7. SiteMinder must have write permissions to a number of user fields in the "read-only" directories for Password Services to operate as expected
   1. on "read-only" directories, SiteMinder has to be able to change password blob data and user disabled status
8. Directory ports are open between "read-write" directories
9. Directory ports are open between "read-only" directories
10. Directory ports are open from "read-write"  directories to "read-only" directories (not vise-versa)
11. Directory ports are open from SiteMinder Policy Servers to "read-only" directories
12. 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?

 

Thanks,

Michael.

[mcdju01]

Hi Michael,

 

Over the last few months we've had many internal discussions about achieving what you are trying to achieve within the product. Unfortunately, as the product stands, achieving synchronous one-way replication with multi-write DISP recovery cannot be achieved.

 

The issue for CA Directory is that while multi-write replication can be set up to function in this way, DISP recovery doesn't function properly. Multi-write DISP recovery between the Internal and Internet DMZs is an agreement between all replicating DSAs, with each DSA responsible for keeping each other peer in synch. If the interaction is blocked from the Internet to the Internal DMZ, then this agreement falls down.

 

The solution to workaround this constraint, as you pointed out, is DISP. Unlike Multi-write, this is a write-behind replication scheme with on-change replication taking up to a minute between checkpoints.

 

Loop detected issues generally indicate a misconfiguration. These occur when DSA A sends a request to DSA B and at some point the request ends up back at DSA A.

 

During recovery, MW-DISP DSAs don't allow client binds. This prevents clients using and updating stale copies of the data. If you have multiple DSAs then using a routing layer support failover in the event that a DSA is recovering and not servicing requests.

 

One question, how are you achieving the SM blob updates on the DMZ Internet DSAs given they are read-only? Is the term read-only just indicating that the Internet DSAs aren't replication updates back to Internal?

 

Thanks,

 

Justin

[Michael_Kipnis]

Hello Justin,

 

Thanks for the detailed explanation.

 

Currently, "read-only" is just a concept which achieved by denying all updates except for SiteMinder user to update only the inetUserStatus and password blob fields.

In addition, no ports are open from the "read-only" directories to the "read-write" directories.

 

We are now exploring a different solution in which all "IDM" and login operations will be done against the "read-write" directory and all the actual user browsing, through the customers' site, will be done against the "read-only" directory, thus allowing us to mark the directories as native read-only.

 

Thanks,

Michael.