#1872 [RFE] Support User Private Groups for main domains, too
Closed: Fixed 2 years ago Opened 6 years ago by wmason.

The current AD ID-mapping implementation sets the primaryGID to the special group "Domain Users". 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.


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?

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

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

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

Metadata Update from @wmason:
- Issue set to the milestone: SSSD Future releases (no date set yet)

2 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from 0)
- Custom field mark reset (from 0)
- Custom field patch reset (from 0)
- Custom field review reset (from 0)
- Custom field sensitive reset (from 0)
- Custom field testsupdated reset (from 0)
- Issue close_status updated to: None
- Issue set to the milestone: SSSD 1.16.0 (was: SSSD Future releases (no date set yet))

2 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue tagged with: RFE

2 years ago

Metadata Update from @jhrozek:
- Issue assigned to jhrozek

2 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue tagged with: PR

2 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue set to the milestone: SSSD 1.16.1 (was: SSSD 1.16.0)

2 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)

2 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata