[Samba] working well with sssd

[Nick Couchman]

On Thu, Sep 23, 2021 at 2:36 PM Billy Bob via samba <samba at lists.samba.org>
wrote:

>  I am VERY happy to see this discussion. I literally cringe every time
> someone asks a sssd question because of the hostility toward sssd they are
> about to at least perceive.
>

+1


> I have never understood why sssd seems to be singled out for "hands-off"
> treatment by the SAMBA crew. Is accommodating sssd really any different
> than working with bind9 or time or ntp? How about integrations with things
> like pfsense, where the ability to install the ideal software on a
> stand-alone hardware system may be more constrained?
> I think it is also very important to note that when people are asking
> questions about sssd and SAMBA, it is very often the case that other
> considerations required sssd AND the integration with SAMBA is for the
> environment of concern very difficult.


Yes, this was the point I was trying to make (perhaps doing a poor job of
it!) early on in this discussion. I do understand that the easiest, most
straight-forward way to get Samba talking to AD is to use Winbind, and that
as of recent releases Winbind must be running for smbd to work with AD.
That doesn't mean that sssd is completely useless, and doesn't mean there
aren't situations where it may be required. I have 1-2 of them myself that
either will not work with just winbind or would require extensive
re-tooling and multi-company impact to change the configuration.


> This sounds exactly like the the type of issue that this list should
> address. It is clear that there is a wealth of knowledge here about the
> problems that arise ... any why. If not this list to help solve or work
> around those problems, to help make SAMBA work with sssd to solve the
> user's real problem (usually one of preserving existing and difficult or
> expensive to change environments), then WHO SHOULD? Perhaps it is the case
> that BOTH this list and lists for sssd (as well as other products, as the
> case may be) should be worked with concurrently, but I cannot fathom why
> the user with a (urgent, critical, real world ...) problem should be forced
> to solve it without also being able to freely and with welcome arms tap the
> knowledge of the people who know SAMBA best.
> I think it is fine, if the user desires, to discuss alternatives that may
> be more suitable. I do not think that should be the starting point, or
> worse the default position, which should be to help find a way to make a
> system run or, more critically, get a broken system back up and running.
> Easy problems, although often important, are a bit boring. We should
> embrace the hard problems, and take pride in a job well done making the
> "impossible" possible.
>

Well-said. One of the things that I very much value about the open source
software community at large is the flexibility to make things work in all
sorts of different environments. Should there be recommended
configurations? Yes. Should users who are clearly struggling with the
basics of getting things working be (gently) pointed in the direction of
these recommendations? Absolutely. Should a community refuse to discuss or
help users who have more "creative" or "interesting" configurations or
requirements? No - that (to me) is the value of a community versus a
commercial support contract.

-Nick