Bug 1464884 - secondary group membership resolution of AD user fails if user information from other trusted domain is fetched first
secondary group membership resolution of AD user fails if user information fr...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd (Show other bugs)
7.4
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: SSSD Maintainers
sssd-qe
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-26 03:49 EDT by shridhar
Modified: 2017-08-18 07:17 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-18 07:17:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description shridhar 2017-06-26 03:49:28 EDT
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@first.sssd16.qe
uid=130200500(administrator@first.sssd16.qe) gid=130200500(administrator@first.sssd16.qe) groups=130200500(administrator@first.sssd16.qe),130200513

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


Expected results:
[root@shr7-permanent ~]# id administrator@childb.sssd16.qeuid=1170600500(administrator@childb.sssd16.qe) gid=1170600513(domain users@childb.sssd16.qe) groups=1170600513(domain users@childb.sssd16.qe),1170600520(group policy creator owners@childb.sssd16.qe),1170600512(domain admins@childb.sssd16.qe),1170600572(denied rodc password replication group@childb.sssd16.qe)
[root@shr7-permanent ~]# id administrator@first.sssd16.qeuid=130200500(administrator@first.sssd16.qe) gid=130200500(administrator@first.sssd16.qe) groups=130200500(administrator@first.sssd16.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@first.sssd16.qeuid=130200500(administrator@first.sssd16.qe) gid=130200500(administrator@first.sssd16.qe) groups=130200500(administrator@first.sssd16.qe),130200513
[root@shr7-permanent ~]# id administrator@childb.sssd16.qeuid=1170600500(administrator@childb.sssd16.qe) gid=1170600513 groups=1170600513
[root@shr7-permanent ~]# sss_cache -E
[root@shr7-permanent ~]# id administrator@childb.sssd16.qe
uid=1170600500(administrator@childb.sssd16.qe) gid=1170600513 groups=1170600513
[root@shr7-permanent ~]# sss_cache -U
[root@shr7-permanent ~]# id administrator@childb.sssd16.qe
uid=1170600500(administrator@childb.sssd16.qe) gid=1170600513 groups=1170600513
[root@shr7-permanent ~]# id administrator@first.sssd16.qe
uid=130200500(administrator@first.sssd16.qe) gid=130200500(administrator@first.sssd16.qe) groups=130200500(administrator@first.sssd16.qe),130200513
[root@shr7-permanent ~]# id administrator@childb.sssd16.qe
uid=1170600500(administrator@childb.sssd16.qe) gid=1170600513 groups=1170600513
[root@shr7-permanent ~]# sss_cache -U
[root@shr7-permanent ~]# id administrator@childb.sssd16.qe
uid=1170600500(administrator@childb.sssd16.qe) gid=1170600513 groups=1170600513
[root@shr7-permanent ~]# sss_cache -u administrator@childb.sssd16.qe
[root@shr7-permanent ~]# id administrator@childb.sssd16.qe
uid=1170600500(administrator@childb.sssd16.qe) gid=1170600513 groups=1170600513
[root@shr7-permanent ~]# sss_cache -E
[root@shr7-permanent ~]# id administrator@childb.sssd16.qe
uid=1170600500(administrator@childb.sssd16.qe) gid=1170600513(domain users@childb.sssd16.qe) groups=1170600513(domain users@childb.sssd16.qe),1170600520(group policy creator owners@childb.sssd16.qe),1170600512(domain admins@childb.sssd16.qe),1170600572(denied rodc password replication group@childb.sssd16.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@first.sssd16.qe
uid=130200500(administrator@first.sssd16.qe) gid=130200500(administrator@first.sssd16.qe) groups=130200500(administrator@first.sssd16.qe),130200512(domain admins@first.sssd16.qe),130200513(domain users@first.sssd16.qe),130200520(group policy creator owners@first.sssd16.qe)
[root@shr7-permanent ~]# id administrator@childb.sssd16.qe
uid=1170600500(administrator@childb.sssd16.qe) gid=1170600513(domain users@childb.sssd16.qe) groups=1170600513(domain users@childb.sssd16.qe),1170600520(group policy creator owners@childb.sssd16.qe),1170600512(domain admins@childb.sssd16.qe),1170600572(denied rodc password replication group@childb.sssd16.qe)
[root@shr7-permanent ~]# 


Reproducer system is available in lab.
Comment 4 Jakub Hrozek 2017-06-28 12:08:05 EDT
Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3442
Comment 5 Lukas Slebodnik 2017-06-28 14:11:02 EDT
Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3441
Comment 9 shridhar 2017-07-20 11:13:09 EDT
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 08:23:19 EDT
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 03:04:05 EDT
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 13:58:00 EDT
(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 02:26:40 EDT
This information is good enough. Thanks.
Comment 14 Jakub Hrozek 2017-08-18 04:45:47 EDT
Can we close the bug, then?
Comment 15 shridhar 2017-08-18 05:28:06 EDT
Sure, this bug could be closed

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