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?
Let me elaborate a bit. The scenario is an authentication procedure
that involves modifications to the account. These modifications need to
be done on the real data, cannot be local (much like many fields related
to password policy, for instance).
The "right" approach would be to propagate the modifications to the
master, wait for their replication and continue with the bind.
The real right approach would be to centralize binds, basically
defeating the purpose of having replicas (with respect to
authentication, at least).
I'm not a fan of OTP, but I believe this problem is worth being
discussed not only with respect to OTP, but also because it may share
issues with other auth methods where the directory stores auth-related
data (like SASL auxprops).
When everything is set up correctly, a client should not direct binds
with this type of mech to a replica.
When clients do not know that a DSA is in fact a shadow, the shadow DSA
should be able to handle this type of requests seamlessly, although
possibly not as efficiently as the master would. In this latter case,
the auth procedure should be able to understand that the request will
modify centrally administered info, and refuse to proceed. The frontend
should be able to intercept this (much like when it receives a write
request, or a request with the dontUseCopy control), and either give up
or perform the write to the master, wait for success, and continue.
Note that "continue" might imply waiting for replication to finalize,
otherwise a subsequent request for stored auxprops would return invalid
values. The above could be implemented at minimal cost using the chain
mechanism already available to support writes to shadow databases, but
binds do not return referrals by design.
In short, I believe this really messes up with the mess involved with
distributed procedures. Either we solve it consistently (at the cost of
performances) or consistently prevent things from messing up (like it is
now); the latter might be the only viable solution if fixing things
consistently is not worth because of excessive performance penalties.