Jakub, > This is confusing because the enumerate word is overloaded :-)
Ha! Agreed. > What is not supported and I guess won't be is "getent passwd" or "getent > group" to get all objects from AD. I definitely agree with not being able to get all objects from AD via `getent passwd` or `getent group`. > get AD members of an IPA group added through an external group, e.g. > "getent group ipagroup" should show both its IPA and AD group members. This is exactly what I'm referring to. On the IPA masters (which have their AD Trusts established), I can query an IPA group which has IPA and external members via `getent group blah` and see both IPA and AD users, as long as the following option is set within sssd.conf: ignore_group_members = FALSE But, on the IPA client nodes the only time that all group members will be shown is if: 1.) The users have previously logged into the node in question; 2.) The users have been queried via `id user` or `getent passwd user` Is the functionality in question only available for IPA masters? Thanks! John DeSantis Il giorno gio 14 nov 2019 alle ore 04:22 Jakub Hrozek <[email protected]> ha scritto: > > On Wed, Nov 13, 2019 at 10:35:46AM -0500, John Desantis wrote: > > Hello all, > > > > Apologies for the necromancy here, but there seems to be conflicting > > information regarding group enumeration within an IPA AD Trust, > > specifically, these tidbits: > > > > > > >>>>>>> ad_users is an IPA group that contains an IPA external group > > > > >>>>>>> that > > > > >>>>>>> contains the users, right? > > > > >>>>>> > > > > >>>>>> Correct. > > > > > > >>>> To confirm: Is the idea behind your patches that it will enumerate > > > > >>>> users in groups that have not logged before? Ie. I have no means > > > > >>>> to determine which users are in a group on the sssd/ipa side. > > > > According to this thread and its linked bug reports, this was > > addressed in SSSD versions >= 1.14.0-43. But, per the URL > > https://access.redhat.com/solutions/3597701 the following is stated: > > > > "Enumeration is not supported in IPA-AD trust environments." > > "This is an expected behaviour if SSSD is not enumerating all AD > > users/groups on IPA server or client after setting enumerate = True > > and subdomain_enumerate = True in sssd.conf." > > > > & > > > > "Enumeration' is not supported in IPA-AD trust environments. As per > > confirmation from IPA/SSSD engineering team, there is no plan on > > supporting enumeration with IPA-AD trusts as it just wouldn't scale > > with large AD domains." > > > > Our AD domain does permit enumeration as the sssd_nss.log on the IPA > > master didn't manifest a message stating that the domain does not > > support enumeration. > > > > Given the aforementioned information, is it correct to assume that > > current versions of SSSD and IPA do not support enumerating a group > > which contains trusted AD users who haven't logged in before/been > > queried via `groups`, `id`, or `getent passwd`? > > This is confusing because the enumerate word is overloaded :-) > > What is not supported and I guess won't be is "getent passwd" or "getent > group" to get all objects from AD. What is supported since 1.14 was to > get AD members of an IPA group added through an external group, e.g. > "getent group ipagroup" should show both its IPA and AD group members. > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
