You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
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.
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/2698
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:
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
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:
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.
Comments
Comment from sbose at 2015-06-26 12:54:22
This RFE sounds quite similar to #1872, can you check if this is the case and close the ticket as duplicate.
Comment from richardgrainger at 2015-06-26 14:51:30
Yes, it is similar, although my request gives more detail and suggests how it could implemented.
Comment from richardgrainger at 2015-06-26 14:57:07
Actually, you can close this. I'll leave the information on #1872.
Comment from jhrozek at 2015-07-04 16:40:29
This is a duplicate of #1872.
resolution: => duplicate
status: new => closed
Comment from richardgrainger at 2017-02-24 14:28:04
Metadata Update from @RichardGrainger:
The text was updated successfully, but these errors were encountered: