[Samba] sssd not a good idea

[vincent at cojot.name]

Hi Robert & Rowland,

So, I reached out to one of the developpers of 'sssd' that I know 
personally. He assured me that 'sssd' is fully supported by RedHat and he 
also said that they only test against MS-AD, not Samba-AD. He thought that 
since Samba-AD aims for retro-compatibility with MS-AD, things "should just 
work" with Samba-AD but again the term 'Supported' is only for sssd in 
regard to MS-AD.

(That also matches my personal experience but then again I have a very 
simple AD domain on Samba 4.10.x with RHEL7).

Also, since sssd has seen a lot of changes in recent times, it is highly 
possible that some of the post-GA docs might not have been updated to 
reflect this.. If there are other such bugs, please feel free to let met 
know or open a documentation BZ directly on https://bugzilla.redhat.com.

This is just my 2c, I don't speak for 'Red Hat', I just work for them (in 
a different field) and I run RHEL at home with self-built rpms on top. 
that's it.

Vincent


On Wed, 12 Jun 2019, Robert Marcano via samba wrote:

> On 6/12/19 12:23 PM, Vincent S. Cojot via samba wrote:
>>
>>  Oh woaaaahhh (Sorry, I lack the words). I am sure that one must be
>>  re-visited for 7.6+, though since 7.6+ had a good overhaul of sssd to make
>>  it work better with AD (I heard that from the developper). Perhaps I'm
>>  going slightly insane here...
>
> I wish they (Red Hat) clarified their position. There are many confusing 
> signals. Let me explain the change's timeline and how I interpret them:
>
> 1. Older Samba releases allowed you to run a domain member server without 
> using winbind. Samba had an alternate code path that when winbind wasn't 
> running it did some things in the same process. 4.8 release changed that, or 
> was 4.7?, I don't remember the details.
>
> 2. On those older releases you could even run a domain member server without 
> ever configuring NSS (/etc/nsswitch.conf) to use winbind. you could have a 
> not common setup like creating domain users locally on the server and Samba 
> didn't care from where those users and groups entries came from. I used this 
> many years ago, before Samba AD, to manage users using the first FreeIPA 
> releases that had zero AD integration support. Think about it as LDAP 
> provider of users and groups. You could even write a custom NSS module that 
> provided the users like the domain needed and a Samba server could work 
> without winbind running.
>
> 3. Now that Samba requires winbind to be running, using winbind without NSS 
> is still possible.  I have many domains running winbind for everything that 
> it is used for, without using it for NSS, SSSD is used for that. I have only 
> one reason for this and is the this request for enhancement "Implement 
> synthetic private groups" [1]
>
> I think all this comes from this, RH updated Samba on RHEL 7 to Samba 4.8. So 
> they must tell their customers winbind is needed to be running on Samba 
> server, because it is.
>
> I hope future Samba releases don't break the current behavior of don't caring 
> from where the Unix user and group mapping come from, if NSS reports it 
> exists, it use it. If the Samba developers ever add a direct way to winbind 
> without using NSS, My current setup will break, unless they implement my RFE 
> and I move to winbind ;-). Losing other features like managing of login 
> policies to the server via Windows GPOs :-(
>
>
> [1] https://bugzilla.samba.org/show_bug.cgi?id=13946
>
>
>
>>
>>  Vincent
>>
>>  On Wed, 12 Jun 2019, Rowland penny via samba wrote:
>>
>>>  On 12/06/2019 16:56, Vincent S. Cojot via samba wrote:
>>>>
>>>>   https://bugzilla.redhat.com/show_bug.cgi?id=1719824
>>>>
>>>  I counter that with:
>>>
>>>  https://bugzilla.redhat.com/show_bug.cgi?id=1663323
>>>
>>>  Rowland
>>> 
>>>
>>>  --
>>>  To unsubscribe from this list go to the following URL and read the
>>>  instructions:  https://lists.samba.org/mailman/options/samba
>>> 
>>>
>> 
>
>
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>
>