On 03/09/2020 20:01, Andrew Walker wrote:> Whoops, fumbled my response a bit. slice size by default is 200,000, > and to clarify the SID passed into murmur3() is the domain SID, not > SID?of individual user. Though, manpage for sssd-ad should be > consulted for precise details. My understanding though is as long as > everything fits in one slice, then you can just use RID. If you have > multiple slices, you're stuck with?non-deterministic behavior from > SSSD and so can continue to use RID in winbind config. Although, I'm > happy for someone to prove me wrong (which is the way things usually > happen when you open your mouth). :)I don't think this is going to work, from my understanding sssd calculates the Unix ID from the SID and the result may not be deterministic and there is is certainly no way that you could reproduce this with the winbind 'rid' backend. Can we please forget that sssd exists ? It doesn't work with Samba any more (even red-hat admits that). Rowland
On Thu, Sep 3, 2020 at 3:15 PM Rowland penny via samba < samba at lists.samba.org> wrote:> On 03/09/2020 20:01, Andrew Walker wrote: > > Whoops, fumbled my response a bit. slice size by default is 200,000, > > and to clarify the SID passed into murmur3() is the domain SID, not > > SID of individual user. Though, manpage for sssd-ad should be > > consulted for precise details. My understanding though is as long as > > everything fits in one slice, then you can just use RID. If you have > > multiple slices, you're stuck with non-deterministic behavior from > > SSSD and so can continue to use RID in winbind config. Although, I'm > > happy for someone to prove me wrong (which is the way things usually > > happen when you open your mouth). :) > > I don't think this is going to work, from my understanding sssd > calculates the Unix ID from the SID and the result may not be > deterministic and there is is certainly no way that you could reproduce > this with the winbind 'rid' backend. > > Can we please forget that sssd exists ? It doesn't work with Samba any > more (even red-hat admits that). > > Rowland >I wish things worked that way. Then I wouldn't have to worry about MacOS compatibility anymore. :)) This is more of an issue with making sure that end-users can make id-mapping as consistent as possible in an environment. Think of the case of MS AD domain with multiple Samba file servers (some with SSSD for domain join and some with winbind). src/lib/idmap/sss_idmap.c indicates that ids are calculated based on the RIDs that are covered by a particular slice: ``` static bool comp_id(struct idmap_range_params *range_params, long long rid, uint32_t *_id) { uint32_t id; if (rid >= range_params->first_rid && ((UINT32_MAX - range_params->min_id) > (rid - range_params->first_rid))) { id = range_params->min_id + (rid - range_params->first_rid); if (id <= range_params->max_id) { *_id = id; return true; } } return false; } ``` So pretty easy fit with idmap_rid if the domain's highest RID is < slice_size in SSSD. So it might be helpful for people to at least try "id DOMAIN\\administrator" on Linux client with SSSD joined to a Windows AD domain (assuming that this is an issue of trying to make sure that clients with SSSD and Winbind end up with similar ID mapping), subtract 500 from from the ID, then set that as the RID low range. It's not perfect, but it works for most environments.
On 03/09/2020 21:06, Andrew Walker wrote:> > > On Thu, Sep 3, 2020 at 3:15 PM Rowland penny via samba > <samba at lists.samba.org <mailto:samba at lists.samba.org>> wrote: > > On 03/09/2020 20:01, Andrew Walker wrote: > > Whoops, fumbled my response a bit. slice size by default is > 200,000, > > and to clarify the SID passed into murmur3() is the domain SID, not > > SID?of individual user. Though, manpage for sssd-ad should be > > consulted for precise details. My understanding though is as > long as > > everything fits in one slice, then you can just use RID. If you > have > > multiple slices, you're stuck with?non-deterministic behavior from > > SSSD and so can continue to use RID in winbind config. Although, > I'm > > happy for someone to prove me wrong (which is the way things > usually > > happen when you open your mouth). :) > > I don't think this is going to work, from my understanding sssd > calculates the Unix ID from the SID and the result may not be > deterministic and there is is certainly no way that you could > reproduce > this with the winbind 'rid' backend. > > Can we please forget that sssd exists ? It doesn't work with Samba > any > more (even red-hat admits that). > > Rowland > > I wish things worked that way. Then I wouldn't have to worry about > MacOS compatibility anymore. :)) > > This is more of an issue with making sure that end-users can make > id-mapping as consistent as possible in an environment. Think of > the?case of MS AD domain with multiple Samba file servers (some with > SSSD for domain join and some with winbind). > > src/lib/idmap/sss_idmap.c indicates that ids are calculated based on > the RIDs that are covered by a particular slice: > ``` > ?static bool comp_id(struct idmap_range_params *range_params, long > long rid, > ? ? ? ? ? ? ? ? ? ? uint32_t *_id) > { > ? ? uint32_t id; > > ? ? if (rid >= range_params->first_rid > ? ? ? ? ? ? && ((UINT32_MAX - range_params->min_id) > > ? ? ? ? ? ? ? ?(rid - range_params->first_rid))) { > ? ? ? ? id = range_params->min_id + (rid - range_params->first_rid); > ? ? ? ? if (id <= range_params->max_id) { > ? ? ? ? ? ? *_id = id; > ? ? ? ? ? ? return true; > ? ? ? ? } > ? ? } > ? ? return false; > } > ``` > So pretty easy fit with idmap_rid if the domain's highest RID is < > slice_size in SSSD. So it might be helpful for people to at least try > "id DOMAIN\\administrator" on Linux client with SSSD joined to a > Windows AD domain (assuming that this is an issue of trying to make > sure that clients with SSSD and Winbind end up with similar ID > mapping), subtract?500 from from the ID, then set that as the RID low > range. It's not perfect, but it works for most environments. >It is easy, if you use Samba >= 4.8.0 on a Unix domain member (and you should be), you cannot use sssd with Samba, so if you are using sssd with Samba, STOP Before Samba 4.8.0, smbd used to be able to fall back to the DC, this was removed at 4.8.0 and now if you have 'security = ADS', you must run winbind. There is also the problem that sssd doesn't have ACL support or use NTLM. I cannot understand why anybody uses sssd with Samba, once they understand how easy it is to set up smb.conf, why setup two conf files when one is sufficient ? Rowland