I'd think that to indicate the topology you would create some administrative name, perhaps a simple string "sales west" or "cluster one" to indicate a topological region, and you would specify for each DSA which administrative name or topology it is logically part of. Then this administrative region name + unique identifier of the principal in question, could be used as a key to hold a simple locked / unlocked boolean value on the replica's parent.

Above would give course grained control with little overhead. All DSA's could keep track of password failures locally, and report up / push up the lock value up to it's provider only if retries have been exceeded for a particular principal and adminsitative domain on a particular server, thus locking all other principal use under the same administrative region. This administrative "lock" value would be replicated downward to other DSA's in the administrative domain, used for locking that principal on all DSA's in each administrative domain.

Alternatively for more fine grained capture of password failure counts, the could push a key containing administrative name + unique identifier of the principal in question + it's replica id, with a simple count of password failures. The value would be stored locally, but pushed up to the provider only when the value changes, and as each consumer would have it's own private namespace on the provider, there would be no collisions not any need to wait for exclusive access to write to it.

The provider could aggregate these values periodically without the need for an exclusive lock, and the aggregated value could then be replicated downwards to the replicas for use in controlling access to accounts.

Cheers
Brett