Lukas et al.,
Firstly reverting the ownership of the sssd service and socket files in the "/usr/lib/systemd/system" and "/var/lib/sss" directories to sssd:sssd and adding the "user = sssd" to the sssd.conf file did resolve the responder issue.This file ownership model was what I thought should be in place, but rhel did not install them consistently this way. I implemented the sssd:root ownerships to resolve some issues with services starting. Interestingly even after changing the ownerships of the same files to sssd:sssd the responder still crashed without the user = sssd directive present in the sssd.conf. I would have thought the daemon on this platform would not require it.
That said, my experience on other platforms is the daemon runs as root, so this is useful to know for additional testing with other distributions, so thank you.
As to the use case discussion, most of my experience and assistance in deployments are direct integration models. Not that I have a technical issue with the indirect approach, but most organisations I encounter prefer the reduced complexity of the direct model. As long as it works reliably. There are feature trade offs using this method but most are okay given those choices are communicated.
That said, when you stand up sssd as a client against a large, mature, complex directory service any thing you can do to reduce the load on the clients and the directory service is a good step. Filtering search results across purposefully configured hosts and reducing load on the client and the directory service are key design components of this proposition.
So, I'm curious if the socket based responders can play a meaningful part in optimisation.
An addition question that may help me. What are your thoughts on the use case(s) for the socket based responders?
Thank you!
-- lawrence