[Samba] please confirm: sssd not a good idea :)

[Rowland penny]

On 12/06/2019 10:44, Nico Kadel-Garcia wrote:
> On Wed, Jun 12, 2019 at 4:38 AM Rowland penny via samba
> <samba at lists.samba.org> wrote:
>> On 10/06/2019 16:04, vincent at cojot.name wrote:
>>> There is probably some amount of redtape on this but AFAIK it works
>>> fine for me: My RHEL7.6 hypervisors are joined to my AD DC 4.10.4 VMs
>>> through use of realm '(and thus sssd):
>>>
>>> Here's a RHEL7.6 client:
>>> # realm list
>>> ad.lasthome.solace.krynn
>>>    type: kerberos
>>>    realm-name: AD.LASTHOME.SOLACE.KRYNN
>>>    domain-name: ad.lasthome.solace.krynn
>>>    configured: kerberos-member
>>>    server-software: active-directory
>>>    client-software: sssd
>>>    required-package: oddjob
>>>    required-package: oddjob-mkhomedir
>>>    required-package: sssd
>>>    required-package: adcli
>>>    required-package: samba-common-tools
>>>    login-formats: %U
>>>    login-policy: allow-realm-logins
>>>
>>> The AD domain above is two RHEL7.6 VMs with samba 4.10.4 and the rpms
>>> from there: http://nova.polymtl.ca/~coyote/dist/samba/samba-4.10.4/RHEL7
>>
>> Hi Vincent, I have never said that you cannot use sssd with Samba, I
>> just said that Samba doesn't support sssd.
>>
>> I have now found (whilst searching for something else) the red-hat
>> webpage I posted the link to earlier, this unequivocally says that
>> red-hat does not support the use of sssd with Samba.
>>
>> This (to myself) means that Samba cannot support the use of sssd,
>> because we do not produce it and red-hat (who do produce it) do not
>> support its use with Samba, so it looks like you are on your own if
>> something goes wrong.
>>
>> Moral of the story, stick to using winbindd instead ;-)
>>
>> Rowland
> sssd has other problems. I've worked with it in the last year. It has
> a variety of under-documented, complexly interwoven subdaemons whose
> configurations are centalized, erratically and often require
> hand-tuning, in the sssd.conf settings. It also has a *nasty* behavior
> with AD or SSSD: it pre-caches *everything* from the LDAP directories
> it is pointed to, and I mean *everything*. Its configuration supports
> structures that only search "onelevel" in an LDAP directory, but when
> designating this it precaches the entire LDAP directory containing the
> "onelevel" objects at startup time, with no way I ever found to turn
> off this misfeature. Hilarity ensues if if your LDAP server, whether
> Samba or AD, are not close enough to the clien thost. And if your LDAP
> is big, that local cache gets *bulky*, even if the "onelevel"
> published objects only contain one element Now, some of that may be an
> organizatonal issue, but it surprised the heck out of me. The result
> is that sssd daemons start up, you can log in with the credentials for
> the first few minutes, but then they fail and take down *all* the sssd
> subdaemons, and you LDAP based access.
>
> While they may be easy to initially activate and configure, realmd and
> sssd have profound limitations with all domain controllers. The
> merging of all of the subcomponents into one suite is, in fact, a
> problem.

This is interesting to know and something I wasn't aware of, my 
objection to sssd is simply that it isn't a Samba product, so we cannot 
support it. This doesn't mean you cannot use it with Samba, you just 
cannot ask here for help with its use, we know nothing about it.

Rowland