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

    master: 30734e5
    sssd-1-16: e673478

Versions:
libsss_idmap-1.16.4-16.el7.x86_64
sssd-common-pac-1.16.4-16.el7.x86_64
libsss_simpleifp-1.16.4-16.el7.x86_64
libsss_nss_idmap-1.16.4-16.el7.x86_64
sssd-client-1.16.4-16.el7.x86_64
sssd-krb5-1.16.4-16.el7.x86_64
sssd-kcm-1.16.4-16.el7.x86_64
python-sssdconfig-1.16.4-16.el7.noarch
sssd-common-1.16.4-16.el7.x86_64
sssd-ad-1.16.4-16.el7.x86_64
sssd-proxy-1.16.4-16.el7.x86_64
sssd-1.16.4-16.el7.x86_64
libsss_autofs-1.16.4-16.el7.x86_64
sssd-ipa-1.16.4-16.el7.x86_64
python-sss-1.16.4-16.el7.x86_64
sssd-tools-1.16.4-16.el7.x86_64
sssd-winbind-idmap-1.16.4-16.el7.x86_64
libsss_certmap-1.16.4-13.el7.x86_64
sssd-debuginfo-1.16.4-13.el7.x86_64
libsss_sudo-1.16.4-16.el7.x86_64
sssd-ldap-1.16.4-16.el7.x86_64
python-sss-murmur-1.16.4-13.el7.x86_64
sssd-krb5-common-1.16.4-16.el7.x86_64
sssd-dbus-1.16.4-16.el7.x86_64
samba-common-tools-4.9.1-5.el7.x86_64
samba-winbind-4.9.1-5.el7.x86_64
samba-client-libs-4.9.1-5.el7.x86_64
samba-winbind-clients-4.9.1-5.el7.x86_64
samba-common-libs-4.9.1-5.el7.x86_64
samba-4.9.1-5.el7.x86_64
samba-common-4.9.1-5.el7.noarch
samba-libs-4.9.1-5.el7.x86_64
samba-winbind-modules-4.9.1-5.el7.x86_64
samba-client-4.9.1-5.el7.x86_64


1: Join RHEL7.7 system to Windows Domain CYGNUS.TEST (windows 2012 R2)

realm join -v CYGNUS.TEST --membership-software=samba

2. Edit /etc/samba/smb.conf and configure as show below:

[global]
security = ads
workgroup = CYGNUS
realm = CYGNUS.TEST
kerberos method = system keytab
client use spnego = yes
netbios name = dhcp201-181
log file = /var/log/samba/log.%m
max log size = 500
log level = 10
idmap config CYGNUS : backend        = sss
idmap config CYGNUS : range          = 200000-2147483647
idmap config * : backend = tdb
idmap config * : range = 100000-199999

[share1]
path = /mnt/samba/share1
comment = test share1
writable = yes
printable = no

3. Create directory /mnt/samba/share1 and create 2 subdirectories pgroup1 and pgroup2

[root@dhcp201-181 ~]# ls -ldZ /mnt/samba/share1/

drwxrws---. root domain users unconfined_u:object_r:samba_share_t:s0 /mnt/samba/share1/
[root@dhcp201-181 ~]# ls -lZ /mnt/samba/share1/
drwxr-sr-x. root foobargroup1 unconfined_u:object_r:samba_share_t:s0 pgroup1
drwxr-sr-x. root foobargroup2 unconfined_u:object_r:samba_share_t:s0 pgroup2
drwxr-sr-x. root domain users unconfined_u:object_r:samba_share_t:s0 pgroup3

4. Create user foobar1 and foobar2 and the users and add foobar1 user to  foobargroup1 , foobar2 user to foobargroup2 

5.  Restart sssd, winbind and smb services

6. kinit as user foobar1 and mount the cifs share and access pgroup1 directory and do the same with foobar2 user and access pgroup2 directory

$ cat smbtest.sh

echo "Secret123" | kinit foobar1
mount -t cifs -o cifsacl -o vers=1.0 -o sec=krb5 -o username=foobar1 //dhcp201-181/share1 /abc
ls -l /abc/pgroup1
umount /abc
kdestroy -A
echo "Secret123" | kinit foobar2
mount -t cifs -o cifsacl -o vers=1.0 -o sec=krb5 -o username=foobar2 //dhcp201-181/share1 /abc
ls -l /abc/pgroup2
umount /abc
kdestroy -A


sh -x smbtest.sh
[root@dhcp201-181 ~]# sh -x smbtest.sh 
+ echo Secret123
+ kinit foobar1
Password for foobar1: 
+ mount -t cifs -o cifsacl -o vers=1.0 -o sec=krb5 -o username=foobar1 //dhcp201-181/share1 /abc
+ ls -l /abc/pgroup1
total 0
+ umount /abc
+ kdestroy -A
+ echo Secret123
+ kinit foobar2
Password for foobar2: 
+ mount -t cifs -o cifsacl -o vers=1.0 -o sec=krb5 -o username=foobar2 //dhcp201-181/share1 /abc
+ ls -l /abc/pgroup2
total 0
+ umount /abc
+ kdestroy -A


Run the above script multiple times and did not see any errors.

Tested the above steps on samba-4.8.3-5.el7_6.x86_64 , and it worked as expected.

(In reply to Niranjan Mallapadi Raghavender from comment #6)
> Tested the above steps on samba-4.8.3-5.el7_6.x86_64 , and it worked as
> expected.

Thanks, did you use sssd-1.16.4-16.el7 for the test or the version available with RHEL-7.6?

bye,
Sumit

I used sssd-1.16.4-16.el7 with samba-4.8.3-5.el7_6.x86_64  on RHEL7.6

(In reply to Niranjan Mallapadi Raghavender from comment #8)
> I used sssd-1.16.4-16.el7 with samba-4.8.3-5.el7_6.x86_64  on RHEL7.6

Ok, do you have a chance to run the test with the latest SSSD for 7.6, sssd-1.16.2-13.el7_6.8, as well to understand if this version has issues with sssd-1.16.2-13.el7_6.8 on 7.6?

bye,
Sumit

With sssd-1.16.2-13.el7_6.8.x86_64 and samba-4.8.3-5.el7_6.x86_64  , it failed with above setup. 

[root@ipaqavme ~]# smbclient -k -L //ipaqavme.idmqe.lab.eng.bos.redhat.com/share1
gensec_spnego_client_negTokenInit_step: Could not find a suitable mechtype in NEG_TOKEN_INIT
session setup failed: NT_STATUS_INVALID_PARAMETER
[root@ipaqavme ~]# smbclient -k -L //ipaqavme.idmqe.lab.eng.bos.redhat.com/share1 -d 10
INFO: Current debug levels:
  all: 10
  tdb: 10
  printdrivers: 10
  lanman: 10
  smb: 10
  rpc_parse: 10
  rpc_srv: 10
  rpc_cli: 10
  passdb: 10
  sam: 10
  auth: 10
  winbind: 10
  vfs: 10
  idmap: 10
  quota: 10
  acls: 10
  locking: 10
  msdfs: 10
  dmapi: 10
  registry: 10
  scavenger: 10
  dns: 10
  ldb: 10
  tevent: 10
  auth_audit: 10
  auth_json_audit: 10
  kerberos: 10
  drs_repl: 10
  smb2: 10
  smb2_credits: 10
lp_load_ex: refreshing parameters
Initialising global parameters
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
INFO: Current debug levels:
  all: 10
  tdb: 10
  printdrivers: 10
  lanman: 10
  smb: 10
  rpc_parse: 10
  rpc_srv: 10
  rpc_cli: 10
  passdb: 10
  sam: 10
  auth: 10
  winbind: 10
  vfs: 10
  idmap: 10
  quota: 10
  acls: 10
  locking: 10
  msdfs: 10
  dmapi: 10
  registry: 10
  scavenger: 10
  dns: 10
  ldb: 10
  tevent: 10
  auth_audit: 10   
  auth_json_audit: 10
  kerberos: 10
  drs_repl: 10
  smb2: 10
  smb2_credits: 10 
Processing section "[global]"
doing parameter security = user
doing parameter kerberos method = system keytab
doing parameter client use spnego = yes
doing parameter netbios name = IPAQAVME
doing parameter log file = /var/log/samba/log.%m
doing parameter max log size = 500
doing parameter log level = 10
doing parameter idmap config CYGNUS : backend = sss
doing parameter idmap config CYGNUS : range = 200000-2147483647
doing parameter idmap config * : backend = tdb
doing parameter idmap config * : range = 100000-199999
pm_process() returned Yes
lp_servicenumber: couldn't find homes
added interface ens5 ip=2620:52:0:1322:10:16ff:fe98:190 bcast= netmask=ffff:ffff:ffff:ffff::
added interface ens5 ip=10.19.34.119 bcast=10.19.35.255 netmask=255.255.254.0
Netbios name list:-
my_netbios_names[0]="IPAQAVME"
Client started (version 4.8.3).
Opening cache file at /var/lib/samba/gencache.tdb
Opening cache file at /var/lib/samba/lock/gencache_notrans.tdb
Adding cache entry with key=[AD_SITENAME/DOMAIN/] and timeout=[Wed Dec 31 07:00:00 PM 1969 EST] (-1558688518 seconds in the past)
sitename_fetch: No stored sitename for realm ''
internal_resolve_name: looking up ipaqavme.idmqe.lab.eng.bos.redhat.com#20 (sitename (null))
name ipaqavme.idmqe.lab.eng.bos.redhat.com#20 found.
remove_duplicate_addrs2: looking for duplicate address/port pairs
Connecting to 10.19.34.119 at port 445
Socket options:
        SO_KEEPALIVE = 0
        SO_REUSEADDR = 0
        SO_BROADCAST = 0
        TCP_NODELAY = 1
        TCP_KEEPCNT = 9
        TCP_KEEPIDLE = 7200
        TCP_KEEPINTVL = 75
        IPTOS_LOWDELAY = 0
        IPTOS_THROUGHPUT = 0
        SO_REUSEPORT = 0
        SO_SNDBUF = 2626560
        SO_RCVBUF = 1061296
        SO_SNDLOWAT = 1
        SO_RCVLOWAT = 1
        SO_SNDTIMEO = 0
        SO_RCVTIMEO = 0
        TCP_QUICKACK = 1
        TCP_DEFER_ACCEPT = 0
 session request ok
 negotiated dialect[SMB3_11] against server[ipaqavme.idmqe.lab.eng.bos.redhat.com]
got OID=1.3.6.1.4.1.311.2.2.10
GENSEC backend 'gssapi_spnego' registered
GENSEC backend 'gssapi_krb5' registered
GENSEC backend 'gssapi_krb5_sasl' registered
GENSEC backend 'spnego' registered
GENSEC backend 'schannel' registered
GENSEC backend 'naclrpc_as_system' registered
GENSEC backend 'sasl-EXTERNAL' registered
GENSEC backend 'ntlmssp' registered
GENSEC backend 'ntlmssp_resume_ccache' registered
GENSEC backend 'http_basic' registered
GENSEC backend 'http_ntlm' registered
GENSEC backend 'http_negotiate' registered
Starting GENSEC mechanism spnego
gensec_spnego_client_negTokenInit_step: Could not find a suitable mechtype in NEG_TOKEN_INIT
gengensec_update_done: spnego[0x55beca3b9a80]: NT_STATUS_INVALID_PARAMETER tevent_req[0x55beca3ba8e0/../auth/gensec/spnego.c:1601]: state[3] error[-7963671676338569203 (0x917B5ACDC000000D)]  state[struct gensec_spnego_update_state (0x55beca3baa70)] timer[(nil)] finish[../auth/gensec/spnego.c:1916]
SPNEGO login failed: An invalid parameter was passed to a service or function.
session setup failed: NT_STATUS_INVALID_PARAMETER
sec_update_send: spnego[0x55beca3b9a80]: subreq: 0x55beca3ba8e0


[root@ipaqavme ~]# mount -t cifs -o cifsacl -o vers=1.0 -o sec=krb5 -o username=foobar1 //ipaqavme.idmqe.lab.eng.bos.redhat.com/share1 /abc
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
May 24 05:04:48 ipaqavme.idmqe.lab.eng.bos.redhat.com kernel: CIFS VFS: Send error in SessSetup = -22
May 24 05:04:48 ipaqavme.idmqe.lab.eng.bos.redhat.com kernel: CIFS VFS: cifs_mount failed w/return code = -22

cat /etc/samba/smb.conf

[global]
security = user
kerberos method = system keytab
client use spnego = yes
netbios name = IPAQAVME
log file = /var/log/samba/log.%m
max log size = 500
log level = 10
idmap config CYGNUS : backend        = sss
idmap config CYGNUS : range          = 200000-2147483647
idmap config * : backend = tdb
idmap config * : range = 100000-199999

[share1]
path = /mnt/samba/share1
comment = test share1
writable = yes
printable = no

In the above comment smb.conf was set to user instead of "security = ads", I retested again with below versions: 

sssd-1.16.2-13.el7_6.8.x86_64
samba-4.8.3-5.el7_6.x86_64

[global]
security = ads
workgroup = CYGNUS
realm = CYGNUS.TEST
kerberos method = system keytab
client use spnego = yes
netbios name = IPAQAVME
log file = /var/log/samba/log.%m
max log size = 500
log level = 10
idmap config CYGNUS : backend        = sss
idmap config CYGNUS : range          = 200000-2147483647
idmap config * : backend = tdb
idmap config * : range = 100000-199999

[share1]
path = /mnt/samba/share1
comment = test share1
writable = yes
printable = no

[root@ipaqavme ~]# smbclient -k -L //ipaqavme.idmqe.lab.eng.bos.redhat.com/share1 

        Sharename       Type      Comment
        ---------       ----      -------
        share1          Disk      test share1
        IPC$            IPC       IPC Service (Samba 4.8.3)
Reconnecting with SMB1 for workgroup listing.

        Server               Comment
        ---------            -------

        Workgroup            Master
        ---------            -------



[root@ipaqavme ~]# sh -x smbtest.sh 
+ echo Secret123
+ kinit foobar1
Password for foobar1: 
+ mount -t cifs -o cifsacl -o vers=1.0 -o sec=krb5 -o username=foobar1 //ipaqavme.idmqe.lab.eng.bos.redhat.com/share1 /abc
+ ls -l /abc/pgroup1
total 0
+ umount /abc
+ kdestroy -A
+ echo Secret123
+ kinit foobar2
Password for foobar2: 
+ mount -t cifs -o cifsacl -o vers=1.0 -o sec=krb5 -o username=foobar2 //ipaqavme.idmqe.lab.eng.bos.redhat.com/share1 /abc
+ ls -l /abc/pgroup2
total 0
+ umount /abc
+ kdestroy -A
[root@ipaqavme ~]#

Thank you, so the issue does no happen if the RHEL-7.6 versions of SSSD and Samba are used, so no backport is needed.

bye,
Sumit

A related issue to this is happening in 7.6 with:

sssd-1.16.2-13.el7_6.8.x86_64
samba-4.8.3-4.el7.x86_64

See: https://pagure.io/SSSD/sssd/issue/4035

I'm looking at backporting this for our environment (mix of RHEL and CentOS).

As this needed to be fixed in Fedora too I'm guessing it's also in RHEL 8?

I have applied the following patch to the sssd-1.16.2-13.el7_6.8 SRPM, rebuilt, and tested. The intermittent lookups we were experiencing have all gone.

https://patch-diff.githubusercontent.com/raw/SSSD/sssd/pull/811.patch

I'm not sure how much longer RHEL 7.7 will be in beta or whether this would meet the criteria for backport to 7.6? Certainly sssd-winbind-idmap in 7.6 doesn't work without it.

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/RHSA-2019:2177