Bug 1300740 - [RFE] IPA: resolve external group memberships of IPA groups during getgrnam and getgrgid
Summary: [RFE] IPA: resolve external group memberships of IPA groups during getgrnam a...
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.3
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Jakub Hrozek
QA Contact: Steeve Goveas
Depends On:
Blocks: 1310664 1311569
TreeView+ depends on / blocked
Reported: 2016-01-21 15:30 UTC by Jakub Hrozek
Modified: 2020-05-02 17:53 UTC (History)
13 users (show)

Fixed In Version: sssd-1.13.0-42.el7
Doc Type: Enhancement
Doc Text:
Feature: In an IPA-AD trust setup, getpwnam and getgrnam calls for IPA groups that contain AD members via external groups used to only return members who were cached via an initgroups call. This patch adds the ability to resolve external members without the initgroups operation as well. Reason: The slapi-nis plugin makes heavy use of this functionality when presenting the external group members to the compatibility tree which is then consumed by legacy clients. It's the only way to define sudo rules through an external group to legacy clients at the moment. Result: calling "getent group" for an IPA group that contains a member from an Active Directory domain would return the AD members as well. Please note that "Domain Users" are a bit of a special case here and its members are not resolved. This is because Domain Users are a primary group for AD users, but do not contain its members as LDAP attributes.
Clone Of:
: 1310664 1311569 (view as bug list)
Last Closed: 2016-11-04 07:15:27 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Github SSSD sssd issues 3564 None None None 2020-05-02 17:53:15 UTC
Red Hat Product Errata RHEA-2016:2476 normal SHIPPED_LIVE sssd bug fix and enhancement update 2016-11-03 14:08:11 UTC

Description Jakub Hrozek 2016-01-21 15:30:37 UTC
This bug is created as a clone of upstream ticket:

Handling group memberships of AD users from a trusted domain has a bit of a history. In the original design the group-memberships where taken from the PAC. This meant that group-membership information was only available after a user logged in to a specific host and only on this host. To allow AD users to be members of IPA groups the IPA KDC added SIDs of IPA groups where the AD user is a member of into the PAC for this user.

Over the time there were request to let the 'id' command line utility show the full list of groups even for AD users which are not logged in. Support for this was added recently in SSSD's IPA provider and on the FreeIPA server side. 

If the SSSD cache entry of an IPA group with external member expires SSSD looks up the group members in the IPA LDAP server but since external memberships are not handled as local IPA members (RFC3207bis) the external members are not found and would be removed from the cache. #2492 mitigates this by making sure that members from different domains are not removed from the cache. Nevertheless it would be better to enhance the group lookup code for IPA groups in a way that it can resolve external members on its own.

Since this is IPA specific the changes should be made in the IPA provider to avoid regressions in the common LDAP group lookup code. On the other hand redundant LDAP requests should be avoided. A plugin scheme with a list of additional member attributes and a tevent request to resolve the additional member attributes might be a way to cover both requirements because the additional attributes can be requested in the same LDAP request as the plain RFC2307bis members and changes to the common group lookup code can be kept very localized and will only be executed if the plugin is available.

Comment 2 Jakub Hrozek 2016-02-24 13:15:18 UTC
Upstream patches:

Comment 5 Sudhir Menon 2016-08-12 14:40:19 UTC
Can you please provide the steps to verify this bug?

Comment 6 Jakub Hrozek 2016-08-12 14:46:14 UTC
(In reply to Sudhir Menon from comment #5)
> Jakub,
> Can you please provide the steps to verify this bug?

You already verified it's clone, https://bugzilla.redhat.com/show_bug.cgi?id=1311569#c6 so the same steps apply.

Comment 7 Sudhir Menon 2016-08-12 14:55:20 UTC
Fix is seen.
Verified using steps as mentioned in comment6 of bz1311569.


Comment 9 errata-xmlrpc 2016-11-04 07:15:27 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.