[Samba] working well with sssd

[Patrick Goetz]

Thanks, everyone. Didn't mean to start a big argument, but there is a 
definite use case for having Samba (file server) work with idmap_sss. 
Also pretty sure a Samba DC doesn't care if a bound computer is using 
winbind or sssd, but someone can correct me if I'm wrong.

Lots of people these days are using sssd to bind linux machines to AD; 
pretty sure redhat suggests this as well. So in say a typical 
environment where most people are running windows bound to an AD they 
don't control, your friendly neighborhood linux admin starts binding 
linux machines to AD using sssd, since it's just for authentication. 
I've been doing this in addition to having a Samba 4.7 file server, and 
this is all working perfectly. The Samba 4.7 file server is of course 
also bound to the domain by sssd.

But now I have a rather large investment (> 0.7 PB) in filesystems with 
POSIX permissions based on sssd-generated UIDs and attempting to change 
all those UIDs could be, as they say, "career limiting". Maintaining a 
consistent UID mapping is essential.

Now take the above scenario in a group (research, engineers, etc.) where 
to date everyone has a linux workstation. Oops, someone wrote a mission 
critical program which only runs on Windows and requires 2-4 GPUs*, so 
now you have to add a Windows workstation to your collection and a Samba 
file server so the Windows machine can access your data (i.e. your NFS 
server is now providing cifs service as well).  The NFS server is bound 
to the domain with sssd because you weren't even thinking about Windows 
previously. In many (based on my experience, most) instances where you 
have a PC controlling an instrument, the vendor's control software only 
runs on windows. You need to be able to transfer data from the control 
PC to your linux fileserver serving up this data to linux workstations 
for processing and analysis. So again, the fileserver needs to be able 
to run Samba while the workstations (and the fileserver) are bound to a 
domain using sssd.

I can probably come up with additional examples, but you get the point. 
Samba is a player in a ecosystem. Incompatibilities pop up all the time 
and you work them out.** That's my life, unfortunately.  I should have 
stayed in math; the theorems never change, just the fonts used print 
them.  Huge headache to find out I'm going to have to jump through hoops 
to get newer Samba versions to work with sssd on Ubuntu.  Would be 
awesome if Louis tackled this. If anyone needs to me lay out a bounty to 
help facilitate this, just ask or point me to the web page.

There's no question that smbd works seamlessly with winbind and that 
using sssd for id mapping is more of a headache; that's irrelevant in 
most cases.


* Yes, you could do this using a VM with PCIe passthrough, but that's 
still pretty bleeding edge for most people. Way simpler to set this up 
bare metal and use Samba for data access. Also, performance.

** The sssd people are very nice and responsive; pretty sure they don't 
bite. I talk to them all the time and haven't been bitten once.



On 9/23/21 04:18, L. van Belle via samba wrote:
> ... And i trown away my own mail responce on this subject..
> 
> Andrew, on this i 100% agree.
> I leave it to that, all im saying for now..
> 
> And guys..
> 
> Its ok if you, agree to disagree on things..
> but its never worth fighting over it.
> 
> 
> Greetz,
> 
> Louis
> 
> 
> 
>> -----Oorspronkelijk bericht-----
>> Van: samba [mailto:samba-bounces at lists.samba.org] Namens
>> Andrew Bartlett via samba
>> Verzonden: donderdag 23 september 2021 11:04
>> Aan: Ralph Boehme; Rowland Penny; sambalist
>> Onderwerp: [Samba] working well with sssd
>>
>> On Thu, 2021-09-23 at 10:53 +0200, Ralph Boehme via samba wrote:
>>>
>>> There is a real need.
>>>
>>> -slow
>>
>> There is also a real need for us to move past this 'we don't even try
>> to work with sssd' thing.  That is both in terms of working
>> in the code
>> to make this 'just work' as much as can be done, with clear
>> limitations
>> specified, and in the practice on the list when queries come up.
>>
>> sssd has become established in terms of being the AD connector for
>> Linux workstations and servers that don't run Samba.  We should
>> congratulate their team for their achievements.  We were in the race,
>> but didn't win this time.
>>
>> Shockingly we find that Samba isn't always the centre of the universe,
>> and sometimes we will need to fit in with the organisational
>> arrangements where 'best for Samba' isn't the primary criteria.  (Just
>> as we exist to help linux systems fit into otherwise windows
>> networks).
>>
>> I would also really love Samba AD to be an even better server to sssd,
>> and while also a code question, moving past this mode of
>> interaction is
>> an important step also.
>>
>> Andrew Bartlett
>> -- 
>> Andrew Bartlett (he/him)       https://samba.org/~abartlet/
>> Samba Team Member (since 2001) https://samba.org
>> Samba Team Lead, Catalyst IT   https://catalyst.net.nz/services/samba
>>
>> Samba Development and Support, Catalyst IT - Expert Open Source
>> Solutions
>>
>>
>> -- 
>> To unsubscribe from this list go to the following URL and read the
>> instructions:  https://lists.samba.org/mailman/options/samba
>>
>>
> 
>