Emmanuel Dreyfus wrote:
Hello
After exchanging a few private messages with Pierangelo Masarati, I just posted ITD#6475:
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: ftp://ftp.openldap.org/incoming/ldapotp.tgz
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.
p.