Bug 671033

Summary: range sharing between server breaks when SASL/GSSAPI auth is used between replicas
Product: [Retired] 389 Reporter: Simo Sorce <ssorce>
Component: Server - DNA Plug-inAssignee: Nathan Kinder <nkinder>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: medium Docs Contact:
Priority: low    
Version: 1.2.7CC: amsharma, nhosoi, rmeggins, sramling
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-07 16:47:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 639035, 656390    
Attachments:
Description Flags
Patch nhosoi: review+

Description Simo Sorce 2011-01-19 23:56:05 UTC 
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.
Comment 1 Simo Sorce 2011-01-20 00:02:42 UTC 
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.
Comment 2 Nathan Kinder 2011-01-20 19:37:40 UTC 
Created attachment 474520 [details]
Patch
Comment 3 Nathan Kinder 2011-01-20 22:08:35 UTC 
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)
To ssh://git.fedorahosted.org/git/389/ds.git
   68bc0a4..bd71726  master -> master
Comment 5 Rich Megginson 2011-07-26 15:12:24 UTC 
Does this only affect SASL/GSSAPI or is it possible to reproduce this problem and verify the fix without SASL/GSSAPI?
Comment 6 Nathan Kinder 2011-07-26 16:00:20 UTC 
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.
Comment 7 Noriko Hosoi 2011-07-26 21:33:19 UTC 
Nathan provided the steps.  Clearing the needinfo flag...
Comment 8 Sankar Ramalingam 2011-11-28 11:57:00 UTC 
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.