#3441 secondary group membership resolution of AD user fails if user information from other trusted domain is fetched first
Closed: Invalid 2 years ago Opened 2 years ago by jhrozek.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1464884

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.

Metadata Update from @jhrozek:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1464884

2 years ago

Metadata Update from @jhrozek:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1464884

2 years ago

Metadata Update from @jhrozek:
- Issue priority set to: blocker
- Issue set to the milestone: SSSD 1.15.3
- Issue tagged with: regression

2 years ago

Hi!

I think this should no longer be a blocker for the upstream release.

In upstream the issue I was able to observer was caused by SSSD not working properly when running under unprivileged user (I do that but it is not default). The reason was that the unprivileged processs tried to access krb5.keytab and failed.

When changing the premissions on krb5.keytab or running as root, the bug was not reproducible.

This is still a bug in SSSD, but IMO it does not justify as blocker anymore.

I agree, since neither upstream nor RHEL use the unprivileged user by default (and it's known to not work in several cases), this shouldn't block the release.

Metadata Update from @jhrozek:
- Issue priority set to: critical (was: blocker)
- Issue set to the milestone: SSSD 1.15.4 (was: SSSD 1.15.3)

2 years ago

Metadata Update from @jhrozek:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata