The issue seem to be in the dna_get_replica_bind_creds() function.
This function frees all return arguments including bind_method if either bind_dn or bind_passwd are not available, so the followin slapi_sasl_bind() function simply ends up trying an anoymous bind instead of a SASL/GSSAPI protected bind.
With SASL/GSSAPI neither dn or password are set.
Just found that in order for the range sharing extop to work, the dna_is_replica_bind_dn() function also need to be changed to cope with the DNA_REPL_BIND_DN being multivalued. Currently it checks only the first dn returned in that attribute.
Created attachment 474520 [details]
Pushed to master. Thanks to Noriko for her review!
Counting objects: 13, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 1.34 KiB, done.
Total 7 (delta 5), reused 0 (delta 0)
68bc0a4..bd71726 master -> master
Does this only affect SASL/GSSAPI or is it possible to reproduce this problem and verify the fix without SASL/GSSAPI?
To verify, you must configure replication to use a method that doesn't use a bind DN and/or password. This means you need to use SASL/GSSAPI or client certificate authentication. The steps to verify are:
- Configure replication between 2 masters using SASL/GSSAPI for the server->server connections.
- Configure DNA with a shared range between the two masters. You will want to give one of the masters a very small range (say 5 values), while the other has a large reserve of values (say 500).
- Exhaust the values on the master that only has 5 values by adding 6 entries that trigger DNA to assign values from the range. The 6th add should succeed and have a value from the range due to a successful range transfer between the masters.
Nathan provided the steps. Clearing the needinfo flag...
Configured MMR with SASL GSSAPI. Configured DNA plugin also with the shared ranges as mentioned by Nathan.
Entries are replicated without any problems. Hence marking the bug as Verified.