Will running SLES 12 without SSSD break anything

SUSE Product Topics SLES Configure-Administer
1

First let me say this is something we need to do in the short term to work around an issue/bug with SSSD cache. I have done a rudimentary test shutting down SSSD and configuring /etc/nsswitch.conf, /etc/ldap.conf and /etc/nscd.conf back to the way we use them on SLES 11 (we have both SLES 11 and SLES 12 running on different servers) and LDAP appears to work just fine.

My question is: has SLES 12 been tightly coupled to SSSD such that not running SSSD will cause us any problems in other areas?

Background: We have an LDAP directory used throughout the company and the presence of legacy systems that cannot handle groups with a very large membership lists has been circumvented by splitting large groups into many sub-groups with the same GID but a series of suffices in the name. This has worked fine for many years, despite being something of a hack. The remaining older systems are being patched to handle large groups at which point we can flatten the sub-groups to single groups. However this is a long and drawn-out process. With the introduction of SLES 12 we discovered that SSSD does not handle multiple groups in a predictable fashion. Sometimes it works fine, but it can get into a state where the cache has more than one entry with the same GID and then SSSD returns an empty results and an error for any lookup involving that GID. The cache does not appear to expire the entry so drastic action is needed to “reset” the cache.

So we need to revert to non-SSSD configuration until we can complete the group re-alignment or until we can get a “fix” for SSSD - I’m sure there would be debate about whether this is a bug or not, but it is a change in behavior, and the results are not consistent.

So if anyone can answer the question above, I’d be most grateful. I’m sure we could debate the validity of our use of sub-groups etc. for a long time, and I’d be happy to do that, but I’d really like some feedback on the central question first :slight_smile:

2

SLES 12, out of the box, runs without SSSD, so I would expect it to be
fine unless you have services that need to use the resources provided by
SSSD, namely those users and groups that come from the LDAP side of the
house. If so, then those will fail, but that’s not necessarily anything
SLES needs to use, and is definitely not something it needs out of the box.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

3

Well actually I stated at the beginning of my post that I was reverting to a pre-SSSD LDAP configuration, which appeared to work just fine. So I don’t need SSSD to talk to LDAP. I thought SLES 12 out of the box had SSSD enabled, but maybe I’m wrong. I’m looking to run in a production environment, so the requirement is everything it needs for that, not just to basically start up and allow root login.

[QUOTE=ab;54517]SLES 12, out of the box, runs without SSSD, so I would expect it to be
fine unless you have services that need to use the resources provided by
SSSD, namely those users and groups that come from the LDAP side of the
house. If so, then those will fail, but that’s not necessarily anything
SLES needs to use, and is definitely not something it needs out of the box.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.[/QUOTE]

4

On 09/23/2018 08:04 PM, garethbeale wrote:[color=blue]

Well actually I stated at the beginning of my post that I was reverting
to a pre-SSSD LDAP configuration, which appeared to work just fine. So I[/color]

I missed the part where, beyond your test, you planned on going to an LDAP
setup without SSSD. Sorry.
[color=blue]

don’t need SSSD to talk to LDAP. I thought SLES 12 out of the box had
SSSD enabled, but maybe I’m wrong. I’m looking to run in a production[/color]

No, SLES out of the box does not care anything at all about network
services that provide users; that requires you to tel it where to point.
None of my boxes use LDAP authentication because I’m seldom needing
multiple users. Every box I build has my user, of course, and then ‘root’
as well naturally, but nothing else is configured to talk outside for
authentication purposes.
[color=blue]

environment, so the requirement is everything it needs for that, not
just to basically start up and allow root login.[/color]

Yes, please not just ‘root’ for login stuff. SLES specifically, and Linux
in general, does not need external authentication. At the end of the day
SSSD is only consulted because the system is configured to consult it for
things like authentication.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

5

Outside of the best practice discussion concerning multiple groups with different names using the same GID, perhaps there could be a way to move forward dealing with groups with large memberships.

Depending on your use case you could implement the following directive:

ignore_group_members =

Do not return group members for group lookups.

If set to TRUE, the group membership attribute is not requested from the LDAP server, and group member are not returned when processing group lookup calls, such as getgrnam or getgrgid. As an effect, “getent group $groupname” would return the requested group as if it was empty.

The directive is used most often as a performance component, but perhaps could be a functional component for your use case.

My experience in implementing this directive has been presented few downsides. The context of group lookups becomes user centric, as are authentication processes in my experience. For example, if a user is queried for group membership, a response is given, and conversely if a group is queried for a user a response is also given. However, if the entire membership of a group needs to be returned there would not be a response. In my experience the latter query is always administrator initiated. Your experience may vary, but regardless there are other tools that can be used for such queries such as ldapsearch or the samba net utility. These will also use the same authentication frameworks as the SSSD.

I believe you also posted this issue to the SSSD user list which is an excellent avenue for assistance and as a direct line to the developers.

My advice would be to consider how you can mitigate the functional issue in a manner that doesn’t reinforce legacy practices. If the legacy practice is the imperative perhaps it’s best to use the daemons that align with them instead of seeking a programmatic work-around in newer ones.

I’m hopeful that the “ignore_group_members” directive helps,

– lawrence

6

Thanks for the response. However since the groups that are causing us the issue are ones actively used on our system, eliminating them from the landscape is not an option. Replicating any problem groups as local groups in /etc/group (using the filter_groups option) was considered, but keeping sync with the LDAP directory and replicating across the large number of servers we control is just too messy.

The way forward is for us to eliminate the GID duplicates, which is mostly delayed by the need to patch clients (elsewhere in the Enterprise that are not under our control) that cannot handle the large groups that would result from such consolidation. The LDAP service we subscribe to handles a very large and diverse client base.

The subject of my original post was to determine whether there were any downsides to running temporarily without SSSD until we can consolidate these groups. We have run into some in testing which I don’t have a lot of detail about yet, but GDM and logind are not functioning correctly without SSSD, the kind of dependencies I was worried about.

[QUOTE=hangarbait;54709]Outside of the best practice discussion concerning multiple groups with different names using the same GID, perhaps there could be a way to move forward dealing with groups with large memberships.

Depending on your use case you could implement the following directive:

ignore_group_members =

Do not return group members for group lookups.

If set to TRUE, the group membership attribute is not requested from the LDAP server, and group member are not returned when processing group lookup calls, such as getgrnam or getgrgid. As an effect, “getent group $groupname” would return the requested group as if it was empty.

The directive is used most often as a performance component, but perhaps could be a functional component for your use case.

My experience in implementing this directive has been presented few downsides. The context of group lookups becomes user centric, as are authentication processes in my experience. For example, if a user is queried for group membership, a response is given, and conversely if a group is queried for a user a response is also given. However, if the entire membership of a group needs to be returned there would not be a response. In my experience the latter query is always administrator initiated. Your experience may vary, but regardless there are other tools that can be used for such queries such as ldapsearch or the samba net utility. These will also use the same authentication frameworks as the SSSD.

I believe you also posted this issue to the SSSD user list which is an excellent avenue for assistance and as a direct line to the developers.

My advice would be to consider how you can mitigate the functional issue in a manner that doesn’t reinforce legacy practices. If the legacy practice is the imperative perhaps it’s best to use the daemons that align with them instead of seeking a programmatic work-around in newer ones.

I’m hopeful that the “ignore_group_members” directive helps,

– lawrence[/QUOTE]

7

… understood. logind and the GDM should be pulling info from the PAM stack and the nscd for session auth (me suspects).

I assume that in addition to modifying the nsswitch.conf file, the PAM stack was updated to remove the pam_sss module and to reference the pam_ldap module on the target systems?

~# pam-config --delete --sss
~# pam-config --add --ldap

The nscd daemon is installed, running, and caching users and groups?

– lawrence