Any way to get sssd to ignore gidNumber (Posix attribute) when auto_private_group set to true?

[Spike White]

All,

We're replacing a commercial product that ignores whatever GID is used in
gidNumber posix attribute, when auto_private_groups is set to true.

However, we find in sssd that even when we set auto_private_groups = True,
that in additional to all the supplemental groups defined by memberOf, it
also appends as the supplemental group the group whose GID is in gidNumber.

Is that any way to disable this?  To have sssd list only "memberOf" groups
as supplemental groups when auto_private_groups == True?

Spike White

[Jakub Hrozek]

On Tue, Nov 05, 2019 at 09:00:44PM -0600, Spike White wrote:
>  All,
>  
>  We're replacing a commercial product that ignores whatever GID is used in
>  gidNumber posix attribute, when auto_private_groups is set to true.
>  
>  However, we find in sssd that even when we set auto_private_groups = True,
>  that in additional to all the supplemental groups defined by memberOf, it
>  also appends as the supplemental group the group whose GID is in gidNumber.
>  
>  Is that any way to disable this?  To have sssd list only "memberOf" groups
>  as supplemental groups when auto_private_groups == True? 
Currently I can't think of anything systematic short of pointing gidNumber
to uidNumber.  (I have not tested this).

What's the rationale behind this? What problems does the additional
group pose?

[Spike White]

Yeah, I knew we could fix this via an AD cleanup.  I was just hoping to
avoid an AD cleanup  (much more paperwork than changing a sssd.conf client
setting).  No such luck.

It's about 100 users that have improper gidNumber.

What problem does this pose?  Lamentably, this is a privileged group that
has sudo privs that allows the user to become root.  Only Linux SE's should
be in this AD group (due to company's segregation of duties policy).

This particular instance is an Oracle DBA. So according to company policy,
Oracle DBAs are supposed to have the sudo privs to fully manage an Oracle
DB.  (stop, start, view logs, etc.)  Oracle DBAs are not supposed to have
full root.  We've identified several Oracle DBAs with these improper
gidNumbers.

Several of these accounts with improper gidNumbers are really Linux SE's.
That's not so bad -- they should have full root any way (via a 'membeOf'
attribute).  So they're not bad -- until they change roles, their
"memberOf" attribute gets revoked, but then they still have full root
(because of gidNumber).

We'll fix it -- with an AD cleanup.

Spike

On Wed, Nov 6, 2019 at 2:44 AM Jakub Hrozek <jhrozek(a)redhat.com&gt; wrote:

>  On Tue, Nov 05, 2019 at 09:00:44PM -0600, Spike White wrote:
>  > All,
>  >
>  > We're replacing a commercial product that ignores whatever GID is used in
>  > gidNumber posix attribute, when auto_private_groups is set to true.
>  >
>  > However, we find in sssd that even when we set auto_private_groups =
>  True,
>  > that in additional to all the supplemental groups defined by memberOf, it
>  > also appends as the supplemental group the group whose GID is in
>  gidNumber.
>  >
>  > Is that any way to disable this?  To have sssd list only "memberOf"
>  groups
>  > as supplemental groups when auto_private_groups == True?
>
>  Currently I can't think of anything systematic short of pointing gidNumber
>  to uidNumber.  (I have not tested this).
>
>  What's the rationale behind this? What problems does the additional
>  group pose?
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  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/[e-mail]...
>