Should this already be possible in 3.2 with https://fedorahosted.org/freeipa/ticket/3706 ?

No, this was just a performance improvement so that unnecessary memberships are not loaded when traversing users in Web UI.

I was already thinking about James' request though I did not had an idea how to solve it. We could add a switch to explicitly suppress adding a new user to ipausers group (we do it unconditionally now), but I am not sure if this is what James want.

Maybe instead of adding user to ipausers group via standard LDAP operation done by the admin, we could solve it via system automember rule - AFAIK, when more rules match (the system one + custom user ones), the user should get membership to all groups - i.e. it may work. It would need to be well tested.

(In reply to Martin Kosek from comment #2)
> No, this was just a performance improvement so that unnecessary memberships
> are not loaded when traversing users in Web UI.
> 

I see.

> I was already thinking about James' request though I did not had an idea how
> to solve it. We could add a switch to explicitly suppress adding a new user
> to ipausers group (we do it unconditionally now), but I am not sure if this
> is what James want.
> 
> Maybe instead of adding user to ipausers group via standard LDAP operation
> done by the admin, we could solve it via system automember rule - AFAIK,
> when more rules match (the system one + custom user ones), the user should
> get membership to all groups - i.e. it may work. It would need to be well
> tested.

Yes. We discussed this option with Rob at some point.
We talked about making ipauser an automember rule. I remember Rob had some concerns. Check with him.

The reason for the ipausers group was so we could reference all users at once via permissions. AFAIK we've never actually written a permission to leverage this. Unsure if any users have.

So my concern was it would get disabled.

If we decide that knowing all IPA users via a group is indeed not something we need to guarantee then I'm fine moving to an automember rule. Or we could make an immutable rule I suppose.

I am not sure there is concern about someone removing the rule since there is really no impact. And if they do they can restore it anyway.
Do we have a ticket? I thought we did but could not find it.

We had a ticket https://fedorahosted.org/freeipa/ticket/1952, it was closed as WONTFIX as during review, we found that the initial approach drafted by Rob 2 years ago [1] was not OK.

However, I am thinking that if we deploy an ipausers automember *rule* and not set it as default group, it should work fine as more than one automember rule can apply to new LDAP entry. I will open an upstream ticket.

[1] http://www.redhat.com/archives/freeipa-devel/2012-January/msg00199.html

Upstream ticket:
https://fedorahosted.org/freeipa/ticket/4088

As that this is a feature request (and not a bug), I am moving this Bugzilla to RHEL-7 product line as this will be the main target of this RFE, unless decided otherwise.

The bugzilla doesn't have high enough priority in comparison to other bugs/RFEs for 7.4. Moving to next release. Without sufficient justification it can be moved again later.

Thank you taking your time and submitting this request for Red Hat Enterprise Linux. The request was cloned to the upstream tracker a long time ago (see link to the upstream ticket above), but it was unfortunately not given priority either in the upstream project, nor in Red Hat Enterprise Linux.

Given that this request is not planned for a close release, it is highly unlikely it will be fixed in this major version of Red Hat Enterprise Linux. We are therefore closing the request as WONTFIX.

To request that Red Hat reconsiders the decision, please reopen the Bugzilla with the help of Red Hat Customer Service and provide additional business and/or technical details about it's importance to you. Please note that you can still track this request or even offer help in the referred upstream Pagure ticket to expedite the solution.