On 04/17/2013 10:50 AM, Russell Jones wrote:
On 4/16/2013 11:40 PM, Stephen Gallagher wrote:
> In the default configuration of SSSD, we create 10,000 slices, each
> capable of handling up to 200,000 IDs. When we see a new user/group
> objectSID, we parse it into two pieces; the first seven components of
> data in the objectSID (S-1-5-21-1289899112-135578405-1515013291)
> identifies the domain that the user belongs to. What we do is take
> this value and pass it through a hashing function. This hashing
> function will give us a predictable slice ID, one of the 10,000 slices
> we created at startup. This slice ID defines the base value for
> UIDs/GIDs in that domain. So if your domain hashes to slice 20, in the
> default configuration this means that the base ID value would be
> (200,000 + 20*200,000) (ldap_idmap_range_min plus twenty times the
> ldap_idmap_range_size value). or: 4200000
> I'm guessing that you modified the idmap_range_min to be 100000
> instead of the default 200000 (like I had originally recommended), and
> that's why your range was starting at 4100000
> Once we have the base ID value identified by the hashing algorithm, we
> look at the remaining part of the objectSID, which is called the RID
> (relative ID). We take this number and just use it as an offset from
> the base ID value. So the end result is base_value + RID.
> When you tweak the size of the idmap_range_*, it alters the total
> number of slices that are available to the configuration, which means
> that the hashing algorithm will end up returning a different slice
> value. (In technical terms, after we hash the domain SID, we take its
> modulus with the total available slices in order to figure out which
> slice to assign it).
Thank you Stephen, that was very thorough and informative, much
One additional question for you regarding how collisions are handled.
Reading the man page, I understand how they can happen, but I am not
understanding how configuring a default domain to ensure at least one
is always consistent in the slice it is given resolves the issue.
For arguments sake, if we have default domain "A", and normal domain
"B" as slice 0 and 1 respectively on both clients 1 and 2, and then
domain C on client 1 and domain D on client 2 collide with their hash
and are both given the next available slice, slice 2, it seems like we
would still have a problem.
Where am I going wrong in my understanding of the scenario?
Slices are not given out by the clients.
Let me try to illustrate.
Imagine that your slices are storage containers in a storage facility.
Each slice has a number.
You come in and you want to use a container. Which one?
We then take you name, SSN, eye color, DOB etc. and hash. As a result we
get a number. This number is the number of your storage container.
Same here. The part of the SID is the unique identifier that identities
the domain. The hash of it will always have number X. This number will
always define which storage container (slice) would be used for your
domain. There is a chance that some other domain would have the same
number but the probability is very low.
No you can configure how big slices are. The bigger the slice the
smaller the number of the slices. So X might map to a different
container if you start re-configuring things and reducing the width of
sssd-users mailing list
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
Looking to carve out IT costs?