This Request for Enhancement (RFE) captures a formal request from a major customer with a large-scale deployment of 1800+ RHEL systems. The customer is requesting a fundamental change to SSSD's architecture to resolve the long-standing performance vs. functionality trade-off for AD group membership resolution. They propose a "lazy evaluation" model to allow both performant user lookups and functional getent group enumerations, which are currently mutually exclusive. This issue represents a significant adoption blocker for them deploying SSSD with recommended best practices, as their application architecture has a hard dependency on POSIX getent behavior. 

<hr />

What were you trying to do that didn't work?

In a large-scale RHEL environment directly integrated with Active Directory, we are trying to achieve two conflicting goals simultaneously:

Fast, scalable user identity lookups (e.g., id <user>) to ensure robust login performance.

Fully functional group member enumeration using standard POSIX tools (e.g., getent group <group_name>) for our existing applications and administrative scripts.

The current SSSD architecture forces a choice between these two objectives. The only way to achieve performant user lookups (ignore_group_members = true) breaks the getent group functionality, which they consider a critical part of a POSIX-compliant system.

What is the impact of this issue to you?
This issue is a significant blocker to their operational strategy.

Application Incompatibility: Our application portfolio and automation, built over many years across 1800+ systems, were architected with the standard POSIX assumption that getent group is a functional and reliable command. Adopting Red Hat's recommended performance tuning (ignore_group_members = true) breaks this assumption and would require a prohibitively expensive and time-consuming refactoring effort.

Architectural Conflict: We are forced to choose between infrastructure stability (fast logins) and application functionality. Deploying with ignore_group_members = false puts our critical SSH jump hosts and other servers at risk of performance degradation and login failures.

Please provide the package NVR for which the bug is seen:

This is an architectural enhancement request, not a bug in a specific build. It applies to the core design of the SSSD AD provider in all modern sssd packages on RHEL 8 and RHEL 9. (e.g., sssd-ad-2.9.x and later).

How reproducible is this bug?:
Always (100%). This is the documented, designed behavior of SSSD.

Steps to reproduce:

Configure a RHEL client with SSSD to connect to a large Active Directory domain where a test user is a member of many (>50) groups.

In sssd.conf, ensure ignore_group_members is set to false or is not present.

Execute time id <ad_user_name>. Observe: The command takes many seconds to complete.

Add ignore_group_members = true to the domain section in sssd.conf.

Clear the cache and restart SSSD: systemctl stop sssd; rm -rf /var/lib/sss/db/*; systemctl start sssd.

Execute time id <ad_user_name>. Observe: The command is now extremely fast.

Execute getent group <an_ad_group>. Observe: The group is returned, but the list of members is empty. This demonstrates the trade-off.

Expected results:
SSSD should provide a mechanism where both user and group lookups are performant and functional without forcing a choice that "cripples" system functionality.

Specifically, we expect an architecture, such as lazy evaluation, where:

id <user> and the underlying initgroups() call remain fast and efficient, using optimized lookups (like the PAC or Token-Groups).

getent group <group_name>, when first called for a group whose members are not cached, would trigger a one-time, on-demand lookup to AD to fully resolve the membership and populate the cache. Subsequent calls would be fast.

Actual results
Administrators are forced into a binary choice:

With ignore_group_members = false: getent group works, but id <user> is unacceptably slow, putting production systems at risk.

With ignore_group_members = true: id <user> is fast, but getent group is non-functional for enumerating members, breaking applications that depend on this standard behavior.