-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/16/2013 07:15 PM, Russell Jones wrote:
On 4/16/2013 1:40 PM, Stephen Gallagher wrote:
> Looking at that SID, the RID portion of it is is *really* large.
> The last section there is 1153286127 (split up, that's
> 1,153,286,127).
>
> Given that you've set an ldap_idmap_range_max of 1,000,000, this
> pretty much explains why you can't convert this user. The
> conversion of this should be 1153286127+100000 (your
> ldap_idmap_range_min is the base, which leaves it at
> 1,153,386,127, which is FAR above the 1,000,000 you have
> allocated.
>
> I'm at a loss to explain why some of your users have IDs in the
> billion-RID range, but if you want these to be handled properly,
> I think you're going to need to set the following values:
>
> ldap_idmap_range_min = 100000 ldap_idmap_range_max = 2000100000
> ldap_idmap_range_size = 2000000000
>
> This will allow you to convert all entries in this domain.
> However, because it requires reserving all 2 billion possible IDs
> for one domain, you won't be able to handle a multi-domain
> forest.
>
> I'd contact your Microsoft representatives to figure out why you
> have entries with such high RID values.
Thank Stephen,
I've resolved the issue with that - the original server I was
querying was returning bad SID data.
On another note, I'm slightly confused reading the man page on how
slices get assigned and used, and would like to understand it
further. For example, here's a clean start for SSSD, with
enumeration disabled, and the caches cleared. In other words, brand
new:
(Tue Apr 16 15:49:51 2013) [sssd[be[LDAP]]]
[sdap_idmap_add_domain] (0x0100): Adding domain
[S-1-5-21-1289899112-135578405-1515013291] as slice [20] (Tue Apr
16 15:49:52 2013) [sssd[be[LDAP]]] [sdap_idmap_add_domain]
(0x0100): Adding domain [S-1-5-21-241006572-1396723338-2091147243]
as slice [8]
When doing an "ID" on a user, the number that gets prepended to
their userid is not the slice numbers being shown above. It appears
to be "41" in this instance:
[root@server db]# id USER uid=4165522(USER) gid=4100513
The "65522" remains the same no matter how I edit the
idmap_range_max, but the numbers before them (41) change. What do
the slice numbers up above, and the "41" here, represent?
Thanks for your help!
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).
I hope this has been informative.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlFuJ6AACgkQeiVVYja6o6MJVwCgkMr8RwYUrebReBeXHqzFNZ6H
IqQAn3N/fHCR6qB7zxXyawDdJ9lM9e1L
=6aE+
-----END PGP SIGNATURE-----