Bug 1756240
Summary: | [RfE] Implement a new sssd.conf option to disable the filter for AD domain local groups from trusted domains [rhel-7.9.z] | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Thorsten Scherf <tscherf> | ||||
Component: | sssd | Assignee: | Sumit Bose <sbose> | ||||
Status: | CLOSED ERRATA | QA Contact: | Dan Lavu <dlavu> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 7.5 | CC: | afarley, atikhono, cylopez, dlavu, grajaiya, ipetrova, jhrozek, jreznik, kbanerje, lslebodn, mzidek, pbrezina, sbose, sgoveas, sssd-qe, thalman, tscherf | ||||
Target Milestone: | rc | Keywords: | FutureFeature, Triaged, ZStream | ||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | sync-to-jira qetodo | ||||||
Fixed In Version: | sssd-1.16.5-10.el7_9.6 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2021-02-02 12:03:31 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Thorsten Scherf
2019-09-27 07:37:22 UTC
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 |