[Samba] working well with sssd

[Nico Kadel-Garcia]

On Thu, Sep 23, 2021 at 5:05 AM Andrew Bartlett via samba
<samba at lists.samba.org> wrote:
>
> 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.

If we can get past the Kerberos version issues it will be much easier.
Installing a bulky separate set of Kerberos libraries is awkward, and
one of the reasons our friends over at RHEL and Fedora have been
reluctant to support Samba as a domain controller. Working with sssd
is... a distinct issue, I think. sssd has some genuinely horrible,
horrible behavior that is difficult to collaborate with. Its
insistence on managing a set of distinct daemons, each of them part of
the sssd suite, from one central configuration file whose hand-tuned
operations are wiped out by authconfig makes it very difficult indeed
to manage. It's insistrnce on starting up, responding successfully toa
few queries, then crashing and requiring a full manual restart due to
its failure to pre-load bulky LDAP tables is very difficult to avoid
in large environments. I have harsh words about such service breaking
pre-optimization.

> 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.

If only I could get it to work at all, I would consider doing so. The
bulky LDAP environment failure has forced me to reject sssd in 3
distinct companies, usually due to the the AD admin's insistence on
preserving previous, purchased company's complex LDAP structures
without sanitizing or simplifying it. Especially when sssd is deployed
in the cloud and the AD or Samba server is not, and whether the
upstream domain controller is AD or Samba, it's a problem.

> 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.

One thing we can do that might help sssd admins is to encourage Samba
admins to organize their LDAP structures as distinct folders, rather
than scattering them around an organization's structure, rather than
plucking one group or user from one folder and one group or user from
other folders scattered around the LDAP. That allows sssd to talk to
only one much smaller space in LDAP, and avoid the pre-loading
difficulties at sssd startup.