Detailed enhancement request proposed : 

• Permit SSSD to include non-POSIX groups when searching for a user's group memberships in response to an initgroups() call from glibc. There is already some precedent for this, in that SSSD will evaluate non-POSIX groups attached to IdM Sudo rules in RHEL 7 and later.

• Permit SSSD to include non-POSIX groups when searching for an IdM group to merge with a local group when [SUCCESS=merge] is present in /etc/nsswitch.conf.

• SSSD (via libnss_sss) would still return nothing for explicit lookups of non-POSIX groups with getgrnam(). A lookup by GID with getgrgid() would of course return nothing since the non-POSIX group would not have a GID to query.

• In the example above, we still create a postgres group in IdM, but it would be non-POSIX. IdM members would be merged into the local postgres group initgroups() if the local group exists. The non-POSIX IdM group becomes a sort of "overlay" for the local group.

• The groupadd command would not see the IdM postgres group, so a fresh install of the postgresql-server package would not fail to create the group locally.

Use case and business justification considering an example usecase :  
 

 
Using PostgreSQL as packaged by Red Hat as an example to illustrate it, but it applies to any local group. Given the following:

• A RHEL server has postgresql-server installed.
• The postgresql-server package automatically creates a group called postgres (GID 26).
• Users in IdM need to be members of the postgres group.

 
There are several possible approached to deal with this, none of which are particularly elegant:

• Add the IdM users to the local postgres group in /etc/group. This is fine for one server, but it can quickly spiral out of control for a large number of servers. This is the recommended approach in solution 2694941.
• Move any local accounts needing the group into IdM, and use the IdM group only. This could be problematic for system accounts, such as the postgres account.
• Create an identical group in IdM for the IdM users. However, Red Hat offers conflicting guidance for this:
  • Solution 2694941 and solution 529333 both state that this is not recommended or supported. But Solution 6971892 tells you to do it, and this post from the freeipa-users mailing list has Alexander Bokovoy (Senior Principal Software Engineer for IPA/IdM) advised the same.

Leveraging IdM only for certain groups has downsides that make it unattractive:

• If IdM is unavailable or SSSD is not running, applications that depend on a group existing may be unable to start or continue running.
• In particular, systemd-tmpfiles starts well before SSSD. It will fail to create entries in /run if the configured ownerships depend on groups that only exist in IdM (or any other source used by SSSD).

Solution 6971892 and Alexander's suggestion in his FreeIPA mailing list post implemented. Using the example above, we created an identical postgres group in IdM (same name and GID), and we put IdM users in that group. We leverage glibc's group merging feature found in RHEL 7.3 and later, which causes glibc to consider both local /etc/group and SSSD-derived groups when calculating a user's group memberships. Since we keep the GID the same, there's no issue with the group looking one way to one server and a different way to another server. This approach works fine, but there is one serious problem that we don't have a good solution for:

• Consider a new RHEL server that does not yet have postgresql-server installed.
• When installing the postgresql-server package, the RPM will automatically try to create the local postgres group.
• If SSSD is running, this creation will fail because the groupadd command detects that a group called postgres already exists (in IdM via SSSD). It is possible to override a duplicate GID with the -o option, but no such option exists to deal with a duplicate group name.
• Subsequent reboots of the server will fail to start PostgreSQL because systemd-tmpfileswants to set up a /run/postgresql directory group-owned by postgres. This fails because systemd-tmpfiles must start before SSSD, and the IdM-based postgres group will not be visible until SSSD starts.
• We must manually edit /etc/group and /etc/gshadow to create the local postgres group, which is not ideal.
• So we request the enhancement proposal suggested initially for our use case.