Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1464884

Summary: secondary group membership resolution of AD user fails if user information from other trusted domain is fetched first
Product: Red Hat Enterprise Linux 7 Reporter: shridhar <sgadekar>
Component: sssdAssignee: SSSD Maintainers <sssd-maint>
Status: CLOSED NOTABUG QA Contact: sssd-qe <sssd-qe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.4CC: grajaiya, jhrozek, lslebodn, mkosek, mzidek, pbrezina, sgadekar, tscherf
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-18 11:17:06 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:

Description shridhar 2017-06-26 07:49:28 UTC
Description of problem:
After removing cache and starting SSSD fresh, if users from different truted domain are requested first before users from main domain (to which RHEL system is joined directly) then secondary groups are not resolved at all.

Environment:
- Root AD-server : SSSD16.QE
- CHILD1-server : FIRST.SSSD16.QE
- CHILD-2-server: CHILDB.SSSD16.QE

Version-Release number of selected component (if applicable):
sssd-1.15.2-50.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Join the RHEL-7 system to the one of child domain (here it is joined to CHILDB)
2. Enable other child domain (FIRST.SSSD16.QE) in sssd.conf with ad_enabled_domain 
3. Clear SSSD cache and Restart sssd service 


 ~]# cat /etc/sssd/sssd.conf 

[sssd]
domains = childb.sssd16.qe
config_file_version = 2
services = nss, pam

[domain/childb.sssd16.qe]
ad_domain = childb.sssd16.qe
krb5_realm = CHILDB.SSSD16.QE
realmd_tags = manages-system joined-with-adcli 
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
access_provider = ad
ad_enabled_domains = first.sssd16.qe, childb.sssd16.qe
debug_level = 9


~]# service sssd stop ; rm -rf /var/lib/sss/db/* ; rm -rf /var/log/sssd/* ; date ; service sssd start 
Redirecting to /bin/systemctl stop sssd.service
Mon Jun 26 03:42:00 EDT 2017
Redirecting to /bin/systemctl start sssd.service
[root@shr7-permanent ~]# 


Actual results:

[root@shr7-permanent ~]# id administrator.qe
uid=130200500(administrator.qe) gid=130200500(administrator.qe) groups=130200500(administrator.qe),130200513

[root@shr7-permanent ~]# id administrator.qe
uid=1170600500(administrator.qe) gid=1170600513 groups=1170600513
[root@shr7-permanent ~]# 


Expected results:
[root@shr7-permanent ~]# id administrator.qeuid=1170600500(administrator.qe) gid=1170600513(domain users.qe) groups=1170600513(domain users.qe),1170600520(group policy creator owners.qe),1170600512(domain admins.qe),1170600572(denied rodc password replication group.qe)
[root@shr7-permanent ~]# id administrator.qeuid=130200500(administrator.qe) gid=130200500(administrator.qe) groups=130200500(administrator.qe),130200513
[root@shr7-permanent ~]# 


Additional info:
There are two workarounds:
Repeated 'sss_cache -E' yield correct results.

root@shr7-permanent ~]# service sssd stop ; rm -rf /var/lib/sss/db/* ; rm -rf /var/log/sssd/* ; date ; service sssd start 
Redirecting to /bin/systemctl stop sssd.service
Mon Jun 26 03:44:06 EDT 2017
Redirecting to /bin/systemctl start sssd.service
[root@shr7-permanent ~]# id administrator.qeuid=130200500(administrator.qe) gid=130200500(administrator.qe) groups=130200500(administrator.qe),130200513
[root@shr7-permanent ~]# id administrator.qeuid=1170600500(administrator.qe) gid=1170600513 groups=1170600513
[root@shr7-permanent ~]# sss_cache -E
[root@shr7-permanent ~]# id administrator.qe
uid=1170600500(administrator.qe) gid=1170600513 groups=1170600513
[root@shr7-permanent ~]# sss_cache -U
[root@shr7-permanent ~]# id administrator.qe
uid=1170600500(administrator.qe) gid=1170600513 groups=1170600513
[root@shr7-permanent ~]# id administrator.qe
uid=130200500(administrator.qe) gid=130200500(administrator.qe) groups=130200500(administrator.qe),130200513
[root@shr7-permanent ~]# id administrator.qe
uid=1170600500(administrator.qe) gid=1170600513 groups=1170600513
[root@shr7-permanent ~]# sss_cache -U
[root@shr7-permanent ~]# id administrator.qe
uid=1170600500(administrator.qe) gid=1170600513 groups=1170600513
[root@shr7-permanent ~]# sss_cache -u administrator.qe
[root@shr7-permanent ~]# id administrator.qe
uid=1170600500(administrator.qe) gid=1170600513 groups=1170600513
[root@shr7-permanent ~]# sss_cache -E
[root@shr7-permanent ~]# id administrator.qe
uid=1170600500(administrator.qe) gid=1170600513(domain users.qe) groups=1170600513(domain users.qe),1170600520(group policy creator owners.qe),1170600512(domain admins.qe),1170600572(denied rodc password replication group.qe)
[root@shr7-permanent ~]# 



Or If other child domain (here first.sssd16.qe) is defined in the /etc/krb.conf then issue is not observed.

[root@shr7-permanent ~]# cat /etc/krb5.conf
# Configuration snippets may be placed in this directory as well
includedir /etc/krb5.conf.d/

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 dns_lookup_realm = true
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false
 default_realm = CHILDB.SSSD16.QE
# default_realm = CHILDB.SSSD16.QE
 default_ccache_name = KEYRING:persistent:%{uid}

[realms]
 CHILDB.SSSD16.QE = {
  kdc = 192.168.66.26
  admin_server = 192.168.66.26
 }

 FIRST.SSSD16.QE = {
  kdc = 192.168.65.18
  admin_server = 192.168.65.18
 }

[domain_realm]
 .childb.sssd16.qe = CHILDB.SSSD16.QE
 childb.sssd16.qe = CHILDB.SSSD16.QE
 .first.sssd16.qe = FIRST.SSSD16.QE
 first.sssd16.qe = FIRST.SSSD16.QE
[root@shr7-permanent ~]# 


[root@shr7-permanent ~]# service sssd stop ; rm -rf /var/lib/sss/db/* ; rm -rf /var/log/sssd/* ; date ; service sssd start 
Redirecting to /bin/systemctl stop sssd.service
Mon Jun 26 03:47:34 EDT 2017
Redirecting to /bin/systemctl start sssd.service
[root@shr7-permanent ~]# id administrator.qe
uid=130200500(administrator.qe) gid=130200500(administrator.qe) groups=130200500(administrator.qe),130200512(domain admins.qe),130200513(domain users.qe),130200520(group policy creator owners.qe)
[root@shr7-permanent ~]# id administrator.qe
uid=1170600500(administrator.qe) gid=1170600513(domain users.qe) groups=1170600513(domain users.qe),1170600520(group policy creator owners.qe),1170600512(domain admins.qe),1170600572(denied rodc password replication group.qe)
[root@shr7-permanent ~]# 


Reproducer system is available in lab.

Comment 4 Jakub Hrozek 2017-06-28 16:08:05 UTC
Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3442

Comment 5 Lukas Slebodnik 2017-06-28 18:11:02 UTC
Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3441

Comment 9 shridhar 2017-07-20 15:13:09 UTC
The administrator credentials were expired thus it had to be changed. I had to change credentials on all AD-servers. Current credentials are Administrator (Secret321). Let me know if further information is required.

Comment 10 Michal Zidek 2017-07-26 12:23:19 UTC
I did some realm leaves and joins in the reproducer using realm join --membership-software=adcli (thank you Sumit).

Everything works for me now.

Can this be closed as WORKSFORME?

Michal

Comment 11 shridhar 2017-07-27 07:04:05 UTC
Michal, does it mean issue is and will be observed if domain is not joined using 'membership-software=adcli' option? 
If default options with command 'realm join <domain>' gives problems then is issue with 'realm' command?

Comment 12 Michal Zidek 2017-08-02 17:58:00 UTC
(In reply to shridhar from comment #11)
> Michal, does it mean issue is and will be observed if domain is not joined
> using 'membership-software=adcli' option? 
> If default options with command 'realm join <domain>' gives problems then is
> issue with 'realm' command?

Sorry, I forgot to answer here.

Not sure. The only thing I can say is that the VM had badly configured kerberos and the 'realm leave' followed by 'realm join' with adcli instead of samba solved the issue. In my environment I could not get to the broken kerberos in the first place no matter if I used samba or adcli as membership-software.

So unless we learn how the machine got to the state it got, it is difficult to say where is the bug. Maybe it is worth documenting somewhere that if someone gets to the broken state, then using adcli may help, but I am not sure.

Comment 13 shridhar 2017-08-09 06:26:40 UTC
This information is good enough. Thanks.

Comment 14 Jakub Hrozek 2017-08-18 08:45:47 UTC
Can we close the bug, then?

Comment 15 shridhar 2017-08-18 09:28:06 UTC
Sure, this bug could be closed