Replying to [ticket:1872 wmason]:

The current AD ID-mapping implementation sets the primaryGID to the special group "Domain Users".

Not automatically Domain Users, the code establishes membership links between all groups reported in the tokenGroups attribute including the primary group which is typically "Domain Users". This is a special-case in the AD provider, the other providers don't establish links towards the primary group.

The user private group scheme makes groups easier to manage for most organizations. To support UPG, a > new option is needed to allow the primary group to be set the same as the uidNumber calculated from
the objectSID.

The way I read this RFE, we'd have to create a group in cache with gid set to the UID calculated from SID on initgroups. That's doable but there might be some special casing required not to remove the group when it's requested directly (getent group $UID) because I don't think it's present in AD as a group, is it?

I don't think it's present in AD as a group, is it?

Correct, It is not present in AD as a group. Currently, the user private groups can be faked by setting the ldap_group_object_class to a value present in both a user and group entry. I used the "top" objectClass, and then refined the search filter using ldap_group_search_base. For UPG, it would be necessary to set the user's primaryGID to the fake gidNumber.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.13 beta
rhbz: => todo

This ticket is being requested more frequently lately. Moving to NEEDS_TRAIGE for a proper discussion.

changelog: =>
milestone: SSSD 1.15 beta => NEEDS_TRIAGE

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.13 beta

Fields changed

cc: => jacob@jacobweber.com

Just curious -- is this possible in current versions?

No, sorry.

Replying to [comment:7 jweber]:

Just curious -- is this possible in current versions?

But patches welcome :-)

Replying to [comment:2 wmason]:

Currently, the user private groups can be faked by setting the ldap_group_object_class to a value present in both a user and group entry. I used the "top" objectClass, and then refined the search filter using ldap_group_search_base. For UPG, it would be necessary to set the user's primaryGID to the fake gidNumber.

If you're doing that, is there an appropriate attribute to use for ldap_group_name, given that it would need to be present in users as well? I don't think I can use cn, since it's already used for other purposes in our system.

Or is there a way to make it use a different group name attribute in users and groups? (I'm guessing not).

Fields changed

mark: => 0

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1169903 (Red Hat Enterprise Linux 6)

rhbz: todo => [https://bugzilla.redhat.com/show_bug.cgi?id=1169903 1169903]

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1180684 (Red Hat Enterprise Linux 6)

rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=1169903 1169903] => [https://bugzilla.redhat.com/show_bug.cgi?id=1169903 1169903], [https://bugzilla.redhat.com/show_bug.cgi?id=1180684 1180684]

Fields changed

rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=1169903 1169903], [https://bugzilla.redhat.com/show_bug.cgi?id=1180684 1180684] => [https://bugzilla.redhat.com/show_bug.cgi?id=1169903 1169903]

I agree this feature is really needed. I have always used private groups with gid the same as uid, and previously used the hack wmason described above. Under the ad provider, however, this doesn't work (the group name cannot be resolved from gid).

Makes total sense, but looks like we won't have the resources in 1.13 proper.

milestone: SSSD 1.13 beta => SSSD 1.13 backlog
priority: major => critical

Most probably too big for 1.13.

milestone: SSSD 1.13 backlog => SSSD 1.14 beta

A thought:

Once we add this capability we would need to add the support of the UPGs to the compat tree for legacy clients, that might have a huge performance impact on the server.

I submitted a new ticket but then realised it was a duplicate. I'll paste the text of ticket here in case it is useful:

Some Linux distributions recommend the use of the "User Private Group" (UPG) scheme, e.g. see: ​https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/user-private-groups.html

Under the UPG scheme, every user created gets their own UPG with a GID corresponding to the UID of the user. The user's primary group is set as as the GID of the UPG.

From the above article: "Using user private groups makes it simpler and safer to manage file and directory permissions because umask defaults only have to restrict user access, not group access."

A generic instance of Microsoft Active Directory does not by default contain UPGs. Instead, on an SSS-enabled box, Active Directory users must have their primary group set to something else (typically "Domain Users"). This means that systems administrators must be more careful about the group ownership of files and folders. For instance home directories must be set with mode 0700 rather than mode 0770.

The feature request is for a new configuration option "enable_virtual_user_private_groups". By default this option should be set to "false" (disabled), but when enabled it will have the following effect:

1. When a program makes a user-related API call (getpwid, getpwnam, etc) and this is handled by SSS, if no real POSIX primary group is set for the user, the user's primary group GID will be returned as the same value as their UID

2. When a program makes a group-related API call (getgrgid, getgrnam etc), if the group requested does not actually exist in AD, but has the same name or ID (depending on the call) as an existing AD user, SSS will return a "virtual" group entry which has:

   • The same name as the user
   • the same uid as the user
   • exactly one member (the user with the matching name/UID)

With this feature added, sites which use an unextended Microsoft Active Directory as their authentication and directory source, can gain the benefit of the UPG scheme without making extensive changes to their Active Directory installation.

sensitive: => 0

Bumping priority for 1.14 since we got another request.

priority: critical => blocker

This is out of scope for 1.14, unfortunately. Moving to 1.15.

milestone: SSSD 1.14 beta => SSSD 1.15 beta

Fields changed

summary: [RFE] Support User Private Groups for AD ID Mapping => [RFE] Support User Private Groups for main domains, too

We should at least assess the scope, it would be really nice to have this implemented in 1.14

milestone: SSSD 1.15 beta => NEEDS_TRIAGE

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1327704 (Red Hat Enterprise Linux 6)

rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=1169903 1169903] => [https://bugzilla.redhat.com/show_bug.cgi?id=1169903 1169903], [https://bugzilla.redhat.com/show_bug.cgi?id=1327704 1327704]

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1327705 (Red Hat Enterprise Linux 7)

rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=1169903 1169903], [https://bugzilla.redhat.com/show_bug.cgi?id=1327704 1327704] => [https://bugzilla.redhat.com/show_bug.cgi?id=1169903 1169903], [https://bugzilla.redhat.com/show_bug.cgi?id=1327704 1327704], [https://bugzilla.redhat.com/show_bug.cgi?id=1327705 1327705]

As discussed on the meeting on Apr-21, this issue is too big for the current 1.14 milestone. It would be better to do it properly in the next version, so I'm moving the ticket back to 1.15.

milestone: NEEDS_TRIAGE => SSSD 1.15 beta

Did this enhancement make it into 1.15?

if it did, it wouldn't be open

PR: https://github.com/SSSD/sssd/pull/402

• master:
• 6c802b2
• ac962e2
• 057e8af
• cdb74b2
• 8fab9d6
• d72ac2c

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2914

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.