Created attachment 1621503 [details]
test build with new option ad_allow_remote_domain_local_groups

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 and lllach.corp.
This works :

~~~
getent group glocalsecOC.corp
glocalsecoc.corp:*:710601119:cyril,lllach.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.corp, cyril and lllach.corp.

~~~
getent group catgroup.corp
~~~

So the problem is reproduced on vanilla version.

I will continue this week with the special build.

Regards

Cyril Lopez

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.corp
catgroup.corp:*:209801108:lllach.corp,john.corp,cyril


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

(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.corp
> catgroup.corp:*:209801108:lllach.corp,john.corp,
> cyril
> 
> 
> 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

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

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.
"""

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

Hello,

So about sg or newgrp no issue in my LAB.

[root@testauth ~]# sg glocalsecOC id
uid=0(root) gid=710601119(glocalsecoc.corp) groupes=710601119(glocalsecoc.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.corp) groupes=209801108(catgroup.corp),0(root),710601119(glocalsecoc.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.corp with in catgroup.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.corp:*:209801108:lllach.corp,john.corp,cyril
[root@testauth ~]# getent group grpofgrp
grpofgrp.corp:*:209801109:lllach.corp,john.corp,cyril
[root@testauth ~]# sg grpofgrp id
uid=0(root) gid=209801109(grpofgrp.corp) groupes=209801109(grpofgrp.corp),0(root) contexte=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023


I will double check with the customer.

Cyril

Pushed PR: https://github.com/SSSD/sssd/pull/5355

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

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
2020-12-14 20:13:51,032 - sssd.testlib.common.qe_class.QeHost.hostname1.cmd25 - DEBUG - RUN getent group tree_domain_group
\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
2020-12-14 20:13:51,195 - sssd.testlib.common.qe_class.QeHost.hostname1.cmd26 - DEBUG - RUN id tree_user1
2020-12-14 20:13:51,539 - sssd.testlib.common.qe_class.QeHost.hostname1.cmd26 - DEBUG - uid=646801108(tree_user1) gid=646801108(tree_user1) groups=646801108(tree_user1),646801115(tree_nested_group1),646801107(tree_group3),646801116(tree_nested_group2),646801113(tree_global_group),646801117(tree_nested_group3),646800513(domain users),646801105(tree_group1),646801106(tree_group2)
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
2020-12-14 20:14:15,056 - sssd.testlib.common.qe_class.QeHost.hostname1.cmd53 - DEBUG - RUN getent group domain_group
2020-12-14 20:14:15,105 - sssd.testlib.common.qe_class.QeHost.hostname1.cmd53 - DEBUG - domain_group:*: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
2020-12-14 20:14:15,150 - sssd.testlib.common.qe_class.QeHost.hostname1.cmd54 - DEBUG - RUN id tree_user1
2020-12-14 20:14:15,189 - sssd.testlib.common.qe_class.QeHost.hostname1.cmd54 - DEBUG - uid=646801108(tree_user1) gid=646801108(tree_user1) groups=646801108(tree_user1),646801112(tree_domain_group),646801105(tree_group1),646801113(tree_global_group),646801116(tree_nested_group2),646801117(tree_nested_group3),646801115(tree_nested_group1),646801106(tree_group2),646801107(tree_group3),646800513(domain users)
2020-12-14 20:14:15,190 - sssd.testlib.common.qe_class.QeHost.hostname1.cmd54 - DEBUG - Exit code: 0
PASSED

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