Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3421

On my test system, sometimes users from other child domain are resolved. This behavior is observed intermittently.

(In reply to shridhar from comment #3)
> On my test system, sometimes users from other child domain are resolved.
> This behavior is observed intermittently.

Is it possible to enable logging and try to catch the issue with logs? Please note it would be best to know the timestamp of when the problem occurs..

* master:
 * 630aea13063c4b242b3433d16ca4346a1a38429b
 * b1d34059533eb50f6e5a4ac7b6fa1bb6fa60a445

[root@shr7-permanent ~]# rpm -q sssd
sssd-1.15.2-50.el7.x86_64
[root@shr7-permanent ~]# 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, sssd16.qe, childb.sssd16.qe
ad_enabled_domains = first.sssd16.qe, childb.sssd16.qe
debug_level = 9

[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
Fri Jun 23 06:20:03 EDT 2017
Redirecting to /bin/systemctl start sssd.service

[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 ~]# id administrator.qe
uid=130200500(administrator.qe) gid=130200500(administrator.qe) groups=130200500(administrator.qe),130200513


from /var/log/sssd/sssd_childb.sssd16.qe

Fri Jun 23 06:27:19 2017) [sssd[be[childb.sssd16.qe]]] [sdap_search_user_next_base] (0x0400): Searching for users with base [dc=first,dc=sssd16,dc=qe]
(Fri Jun 23 06:27:19 2017) [sssd[be[childb.sssd16.qe]]] [sdap_print_server] (0x2000): Searching 192.168.64.122:3268
(Fri Jun 23 06:27:19 2017) [sssd[be[childb.sssd16.qe]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=administrator)(objectclass=user)(sAMAccountName=*)(objectSID=*))][dc=first,dc=sssd16,dc=qe].


In addition to above results, following behavior was also observed:

If users information from other child domain is requested first after fresh start of SSSD then secondary group resolution does not work for users from main child domain (the domain to which rhel system is joined directly) as well. 


scenario 1:  Fetching user from other child domain:
[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
Fri Jun 23 06:55:51 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),130200513

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


Scenario 2: Fetching users from main child (to which system is joined)

 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
Fri Jun 23 06:56:11 EDT 2017
Redirecting to /bin/systemctl start sssd.service

[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 ~]# id administrator.qe
uid=130200500(administrator.qe) gid=130200500(administrator.qe) groups=130200500(administrator.qe),130200513
[root@shr7-permanent ~]#

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, 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/RHEA-2017:2294