Bug 1756240 - [RfE] Implement a new sssd.conf option to disable the filter for AD domain local groups from trusted domains [rhel-7.9.z]
Summary: [RfE] Implement a new sssd.conf option to disable the filter for AD domain lo...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.5
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: Sumit Bose
QA Contact: Dan Lavu
URL:
Whiteboard: sync-to-jira qetodo
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-09-27 07:37 UTC by Thorsten Scherf
Modified: 2021-02-02 12:03 UTC (History)
17 users (show)

Fixed In Version: sssd-1.16.5-10.el7_9.6
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-02-02 12:03:31 UTC
Target Upstream Version:


Attachments (Terms of Use)
test build with new option ad_allow_remote_domain_local_groups (9.38 MB, application/gzip)
2019-10-01 18:53 UTC, Sumit Bose
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 5346 0 None closed [RfE] Implement a new sssd.conf option to disable the filter for AD domain local groups from trusted domains 2021-02-08 18:20:00 UTC

Description Thorsten Scherf 2019-09-27 07:37:22 UTC
Description of problem:
Active Directory comes with different group types. The "Domain Local Group" type (0x00000004) is only valid in the same domain where the group was defined and not cross domain. SSSD enforces this limit since Red Hat Enterprise Linux 7.0 and sssd-1.11.2-18.el7. See 'Additional info' for more details reg the actual implementation.

There are some use-cases though where it would be helpful to disable the filter for domain local groups and make them available cross domain - even when this is against what Microsoft is proposing.

The ask here is to implement a new SSSD option that allows to disable the filter for domain local groups. The default should be that domain local groups are filtered (no change to current behavior) so that Administrators explicitly need to turn this option on to disable the filter.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

AD groups with domain-local scope should be filtered out for trusted domains
https://pagure.io/SSSD/sssd/issue/2178

AD: filter domain local groups for trusted/sub domains
https://pagure.io/SSSD/sssd/c/8280c5213094a72fcaa499dda2f8647246185d45

tokenGroups do not work reliable with Global Catalog
https://bugzilla.redhat.com/show_bug.cgi?id=1033096

Comment 4 Sumit Bose 2019-10-01 18:53:16 UTC
Created attachment 1621503 [details]
test build with new option ad_allow_remote_domain_local_groups

Comment 40 Cyril Lopez 2020-07-13 14:52:51 UTC
Dear all,

A quick summary of my work :

I was able to reproduce your environment with 3 server windows 2k16 and a rhel 7.8 sssd-ad-1.16.4-37.el7_8.3.x86_64.

I installed a first AD cyril.corp and 2 domains tree oc.cyril.corp and cat.cyril.corp. I added a relation bidirectional between oc.cyril.corp and cat.cyril.corp.

I followed https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/windows_integration_guide/index to add my RHEL 7.8 into oc.cyril.corp.

1. I created a group glocalsecOC as security group and Domain local in oc.cyril.corp in OU teams. I added inside 2 users from other domain tree : cyril@cyril.corp and lllach@cat.cyril.corp.
This works :

~~~
getent group glocalsecOC@oc.cyril.corp
glocalsecoc@oc.cyril.corp:*:710601119:cyril@cyril.corp,lllach@cat.cyril.corp
~~~

2. I created a group catgroup  as security group and Domain local in cat.cyril.corp in OU catteam. I added inside 3 users john@oc.cyril.corp, cyril@cyril.corp and lllach@cat.cyril.corp.

~~~
getent group catgroup@cat.cyril.corp
~~~

So the problem is reproduced on vanilla version.

I will continue this week with the special build.

Regards

Cyril Lopez

Comment 41 Cyril Lopez 2020-07-13 15:06:23 UTC
Good news, I made it work.

I installed the SSSD patch I removed the cache and tested :


rm -rf /var/lib/sss/db/*
systemctl restart sssd.service
getent group catgroup@cat.cyril.corp
catgroup@cat.cyril.corp:*:209801108:lllach@cat.cyril.corp,john@oc.cyril.corp,cyril@cyril.corp


In summary, I'm able to see a group from an other domain tree than me here cat.cyril.corp (my node is in oc.cyril.corp).

/etc/sssd/sssd.conf

[sssd]
domains = oc.cyril.corp
config_file_version = 2
services = nss, pam

[domain/oc.cyril.corp]
ad_domain = oc.cyril.corp
krb5_realm = OC.CYRIL.CORP
realmd_tags = manages-system joined-with-samba 
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
override_homedir = /home/%d/%u
access_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
ldap_schema = ad

auto_private_groups = false

ldap_deref_threshold = 0
ad_allow_remote_domain_local_groups = True


So the patch could be added downstream

Thanks
Cyril

Comment 42 Sumit Bose 2020-08-10 07:58:25 UTC
(In reply to Cyril Lopez from comment #41)
> Good news, I made it work.
> 
> I installed the SSSD patch I removed the cache and tested :
> 
> 
> rm -rf /var/lib/sss/db/*
> systemctl restart sssd.service
> getent group catgroup@cat.cyril.corp
> catgroup@cat.cyril.corp:*:209801108:lllach@cat.cyril.corp,john@oc.cyril.corp,
> cyril@cyril.corp
> 
> 
> In summary, I'm able to see a group from an other domain tree than me here
> cat.cyril.corp (my node is in oc.cyril.corp).


Hi,

thanks for testing. If I understand it correctly the issue the customer still has is when this group from the other domain has members from a third domain. Does your test cover this case as well?

bye,
Sumit

> 
> /etc/sssd/sssd.conf
> 
> [sssd]
> domains = oc.cyril.corp
> config_file_version = 2
> services = nss, pam
> 
> [domain/oc.cyril.corp]
> ad_domain = oc.cyril.corp
> krb5_realm = OC.CYRIL.CORP
> realmd_tags = manages-system joined-with-samba 
> cache_credentials = True
> id_provider = ad
> krb5_store_password_if_offline = True
> default_shell = /bin/bash
> ldap_id_mapping = True
> use_fully_qualified_names = True
> fallback_homedir = /home/%u@%d
> override_homedir = /home/%d/%u
> access_provider = ad
> auth_provider = ad
> chpass_provider = ad
> access_provider = ad
> ldap_schema = ad
> 
> auto_private_groups = false
> 
> ldap_deref_threshold = 0
> ad_allow_remote_domain_local_groups = True
> 
> 
> So the patch could be added downstream
> 
> Thanks
> Cyril

Comment 43 Cyril Lopez 2020-08-10 08:04:11 UTC
Hi

I made a demo to my customer contact and my understanding is : we have all feature required with your path.

But I'm waiting a final check which will be done by the customer. At this moment, those people are not available.

BR
Cyril

Comment 45 Irina Petrova 2020-08-27 09:43:21 UTC
Hey guys (I'm covering for Cyril, while he's on PTO).

Unfortunately, Cyril's workaround fixes the issue _only partially_ (and that's not sufficient). To quote the customer:

"""
I have just tested again your delivered SSSD package including the recommended options.
And yes, I can see the domain local groups located in secondary domains.
This is working by specifying the group name with and without domain name and it displays the user member list as well!
The member list is displayed only when global catalogs are used, but that is okay...

This is only working using the "getent group ..." command.
Not successful is the "id" command having the result that a user is not able to switch to this group using the "newgrp" or "sg" commands.

As already said the domain local groups from other domains are now visible.
But visibility is not enough. They have to be part of the user authentication.
Our customers are not really able to provide us a list of use cases for testing.
But what have at least to work is the inclusion of these groups into the list of the users supplemental groups.
Only then the user is able by help of the newgrp command to set this group as the primary group.

I assume when the groups are added as supplemental groups most other yet unknown customer use cases will also work.
"""

Comment 46 Sumit Bose 2020-08-27 11:52:27 UTC
Hi,

can you ask if the tests with the 'id' command were done with 'ldap_use_tokengroups = False' (the default is 'True') and if yes if 'ldap_group_nesting_level' (default is 2) was modified as well?

I'm asking because the tokenGroups request cannot be used here since it will only return the group-memberships as expected by AD, i.e. domain local groups of other domains are not included. So this has to be disabled.

If 'ldap_use_tokengroups = False' SSSD will follow the group-nesting hierarchy by reading the direct group-memberships from the user's LDAP object and then checking if those groups are members of other groups and so on. By default SSSD will do this only up to 2 levels. If the domain local group of the other domain is deeper in the hierarchy 'ldap_group_nesting_level' should be increased.

What will currently not work is the case where the domain local group of the other domain is not part of the nested group hierarchy but if the user was added directly to the domain local group of the other domain. In this case the domain local group of the other domain is not added to the user's LDAP object in contrast to groups with a universal scope. Since there is no path to the remote domain local group SSSD would have to search in each domain of the forest if the user might be a member of a domain local group of the remote domain. This is currently not implemented and is not related to the original request of this ticket to stop filtering the remote domain local groups. If this is needed here I currently cannot say if it would be possible to implement this for RHEL-7 because I at the moment cannot say how much changes are needed to implement this.

bye,
Sumit

Comment 47 Cyril Lopez 2020-09-01 14:20:38 UTC
Hello,

So about sg or newgrp no issue in my LAB.

[root@testauth ~]# sg glocalsecOC id
uid=0(root) gid=710601119(glocalsecoc@oc.cyril.corp) groupes=710601119(glocalsecoc@oc.cyril.corp),0(root) contexte=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[root@testauth ~]# newgrp catgroup
[root@testauth ~]# id
uid=0(root) gid=209801108(catgroup@cat.cyril.corp) groupes=209801108(catgroup@cat.cyril.corp),0(root),710601119(glocalsecoc@oc.cyril.corp) contexte=unconfined_u:unconfined_r:unconfined_t:s0-
s0:c0.c1023


Also what the customer is asking, if I understand well, is working.

I create a group grpofgrp@cat.cyril.corp with in catgroup@cat.cyril.corp with in user from cat.cyril.corp and oc.cyril.corp. Windows AD doesn't allow me to add an domain local from an other tree.

[root@testauth ~]# getent group catgroup
catgroup@cat.cyril.corp:*:209801108:lllach@cat.cyril.corp,john@oc.cyril.corp,cyril@cyril.corp
[root@testauth ~]# getent group grpofgrp
grpofgrp@cat.cyril.corp:*:209801109:lllach@cat.cyril.corp,john@oc.cyril.corp,cyril@cyril.corp
[root@testauth ~]# sg grpofgrp id
uid=0(root) gid=209801109(grpofgrp@cat.cyril.corp) groupes=209801109(grpofgrp@cat.cyril.corp),0(root) contexte=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023


I will double check with the customer.

Cyril

Comment 55 Pavel Březina 2020-10-08 11:35:08 UTC
Pushed PR: https://github.com/SSSD/sssd/pull/5355

* `sssd-1-16`
    * 6f31f43ee15bcb0933ddca8726b166a93f9371a9 - ad: add ad_allow_remote_domain_local_groups

Comment 72 Dan Lavu 2020-12-15 01:16:15 UTC
Verified against sssd-1.16.5-10.el7_9.6

domain group tree_domain_group is not found with the default configuration

2020-12-14 20:13:51,032 - sssd.testlib.common.qe_class.QeHost.hostname1.ParamikoTransport - INFO - RUN getent group tree_domain_group@treedomain.com
2020-12-14 20:13:51,032 - sssd.testlib.common.qe_class.QeHost.hostname1.cmd25 - DEBUG - RUN getent group tree_domain_group@treedomain.com
\020-12-14 20:13:51,151 - sssd.testlib.common.qe_class.QeHost.hostname1.cmd25 - DEBUG - Exit code: 2
2020-12-14 20:13:51,195 - sssd.testlib.common.qe_class.QeHost.hostname1.ParamikoTransport - INFO - RUN id tree_user1@treedomain.com
2020-12-14 20:13:51,195 - sssd.testlib.common.qe_class.QeHost.hostname1.cmd26 - DEBUG - RUN id tree_user1@treedomain.com
2020-12-14 20:13:51,539 - sssd.testlib.common.qe_class.QeHost.hostname1.cmd26 - DEBUG - uid=646801108(tree_user1@treedomain.com) gid=646801108(tree_user1@treedomain.com) groups=646801108(tree_user1@treedomain.com),646801115(tree_nested_group1@treedomain.com),646801107(tree_group3@treedomain.com),646801116(tree_nested_group2@treedomain.com),646801113(tree_global_group@treedomain.com),646801117(tree_nested_group3@treedomain.com),646800513(domain users@treedomain.com),646801105(tree_group1@treedomain.com),646801106(tree_group2@treedomain.com)
2020-12-14 20:13:51,541 - sssd.testlib.common.qe_class.QeHost.hostname1.cmd26 - DEBUG - Exit code: 0


tree_domain_group is found with the changes. 


2020-12-14 20:14:15,013 - sssd.testlib.common.qe_class.QeHost.hostname1.cmd52 - DEBUG - Exit code: 0
2020-12-14 20:14:15,055 - sssd.testlib.common.qe_class.QeHost.hostname1.ParamikoTransport - INFO - RUN getent group domain_group@treedomain.com
2020-12-14 20:14:15,056 - sssd.testlib.common.qe_class.QeHost.hostname1.cmd53 - DEBUG - RUN getent group domain_group@treedomain.com
2020-12-14 20:14:15,105 - sssd.testlib.common.qe_class.QeHost.hostname1.cmd53 - DEBUG - domain_group@treedomain.com:*:646801111:
2020-12-14 20:14:15,107 - sssd.testlib.common.qe_class.QeHost.hostname1.cmd53 - DEBUG - Exit code: 0
2020-12-14 20:14:15,149 - sssd.testlib.common.qe_class.QeHost.hostname1.ParamikoTransport - INFO - RUN id tree_user1@treedomain.com
2020-12-14 20:14:15,150 - sssd.testlib.common.qe_class.QeHost.hostname1.cmd54 - DEBUG - RUN id tree_user1@treedomain.com
2020-12-14 20:14:15,189 - sssd.testlib.common.qe_class.QeHost.hostname1.cmd54 - DEBUG - uid=646801108(tree_user1@treedomain.com) gid=646801108(tree_user1@treedomain.com) groups=646801108(tree_user1@treedomain.com),646801112(tree_domain_group@treedomain.com),646801105(tree_group1@treedomain.com),646801113(tree_global_group@treedomain.com),646801116(tree_nested_group2@treedomain.com),646801117(tree_nested_group3@treedomain.com),646801115(tree_nested_group1@treedomain.com),646801106(tree_group2@treedomain.com),646801107(tree_group3@treedomain.com),646800513(domain users@treedomain.com)
2020-12-14 20:14:15,190 - sssd.testlib.common.qe_class.QeHost.hostname1.cmd54 - DEBUG - Exit code: 0
PASSED

Comment 80 errata-xmlrpc 2021-02-02 12:03:31 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (sssd bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:0341


Note You need to log in before you can comment on or make changes to this bug.