Bug 671033 - range sharing between server breaks when SASL/GSSAPI auth is used between replicas
Summary: range sharing between server breaks when SASL/GSSAPI auth is used between rep...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Server - DNA Plug-in
Version: 1.2.7
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 639035 389_1.2.8
TreeView+ depends on / blocked
 
Reported: 2011-01-19 23:56 UTC by Simo Sorce
Modified: 2015-12-07 16:47 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-07 16:47:12 UTC
Embargoed:


Attachments (Terms of Use)
Patch (3.65 KB, patch)
2011-01-20 19:37 UTC, Nathan Kinder
nhosoi: review+
Details | Diff

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.


Note You need to log in before you can comment on or make changes to this bug.