On 2/16/10 10:29 PM, Emmanuel Dreyfus wrote:
After exchanging a few private messages with Pierangelo Masarati, I just
> When binding using SASL OTP to a replica, the bind works, but the
> cmusaslsecretOTP attribute is modified on the replica and fail to be
> propagated to the master. On the next modification, the master will
> overwrite the replica's updated cmusaslsecretOTP value.
> Here is a script that exhibit the behaviour:
> That require SASL enabled OpenLDAP, with the OTP plugin installed. The
> PATH in run.sh must probably be adjusted.
The problem is in sasl_auxprop_store(), who bypass the replication
process. The easier fix to me seems to send a referal to the master on
any SASL OTP bind, Any other idea?
I was experimenting with SASL OTP a few months ago and thought
replication seemed problematic in general.
In a single provider, single consumer setup, it would seem that if the
cmusaslsecretOTP was written to on the provider (as above), there would
be a chance for a client to perform another SASL OTP bind against the
consumer before the cmusaslsecretOTP was replicated. In such a
situation, the password could be replayed.
In the current implementation, this cannot happen on a single consumer,
as the SASL libraries prevent binding until the cmusaslsecretOTP has
been written. Of course, if the entry with an old cmusaslsecretOTP is
replicated, the password can be replayed.
Multi-consumer setups suffer from the same problem. Passwords can be
used multiple times on different consumers.
I'm not sure how this problem can be solved. It would seem that in a
replicated environment a SASL OTP bind would have to block across all
providers until they are all updated to prevent passwords from being
replayed. This seems difficult, to say the least.