-----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.