Hide Forgot
Description of problem: Unable to access cifs share using sssd-libwbclient. When accessing the share the following error is seen: [root@vm-idm-017 samba]# smbclient -k -L //vm-idm-017.lab.eng.pnq.redhat.com/share1 session setup failed: NT_STATUS_LOGON_FAILURE Version-Release number of selected component (if applicable): sssd-krb5-common-1.15.2-48.el7.x86_64 sssd-ldap-1.15.2-48.el7.x86_64 python-sssdconfig-1.15.2-48.el7.noarch sssd-common-1.15.2-48.el7.x86_64 sssd-common-pac-1.15.2-48.el7.x86_64 sssd-ad-1.15.2-48.el7.x86_64 sssd-krb5-1.15.2-48.el7.x86_64 sssd-1.15.2-48.el7.x86_64 sssd-libwbclient-1.15.2-48.el7.x86_64 sssd-client-1.15.2-48.el7.x86_64 sssd-ipa-1.15.2-48.el7.x86_64 sssd-proxy-1.15.2-48.el7.x86_64 How reproducible: Steps to Reproduce: 1. On RHEL7.4 system install sssd samba realmd cifs-utils packages krb5-workstation 2. Join the system to Windows AD using realm command realm join -v JUNO.TEST -U administrator [sssd] domains = juno.test config_file_version = 2 services = nss, pam [domain/juno.test] ad_domain = juno.test krb5_realm = JUNO.TEST realmd_tags = manages-system joined-with-samba 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 3. Start sssd service 4.configure smb.conf to provide a share "share1" [global] workgroup = JUNO netbios name = vm-idm-017 realm = JUNO.TEST security = ads kerberos method = system keytab ntlm auth = no load printers = no printing = bsd log file = /var/log/samba/log.%m max log size = 500 log level = 50 map acl inherit = Yes store dos attributes = Yes [share1] path = /mnt/samba/share1 comment = test share1 writable = yes printable = no 5. Install sssd-libwbclient sssd-libwbclient-1.15.2-48.el7.x86_64 6. Check alternatives [root@vm-idm-017 samba]# alternatives --list libnssckbi.so.x86_64 auto /usr/lib64/pkcs11/p11-kit-trust.so pax auto /usr/bin/spax ld auto /usr/bin/ld.bfd print auto /usr/bin/lpr.cups mta auto /usr/sbin/sendmail.sendmail emacs.etags auto /usr/bin/etags.emacs emacs auto /usr/bin/emacs-24.3 cifs-idmap-plugin auto /usr/lib64/cifs-utils/cifs_idmap_sss.so libwbclient.so.0.13-64 auto /usr/lib64/sssd/modules/libwbclient.so.0.13.0 cups_backend_smb auto /usr/bin/smbspool 7. Do kinit as ad user [root@vm-idm-017 samba]# kinit foobar1 Password for foobar1: [root@vm-idm-017 samba]# klist Ticket cache: KEYRING:persistent:0:0 Default principal: foobar1 Valid starting Expires Service principal 06/19/2017 18:56:03 06/20/2017 04:56:03 krbtgt/JUNO.TEST renew until 06/26/2017 18:55:57 8. Access samba share using smbclient command [root@vm-idm-017 samba]# smbclient -k -L //vm-idm-017.lab.eng.pnq.redhat.com/share1 session setup failed: NT_STATUS_LOGON_FAILURE Actual results: Unable to access the cifs share and fails with NT_STATUS_LOGON_FAILURE. Expected results: Should be able to access the share. Additional info:
Created attachment 1289109 [details] smbd log
Created attachment 1289110 [details] samba client log
I tried one more test where i updated the RHEL7.3 system (keeping the samba version same) and updated to latest sssd sssd-libwbclient to the latest version samba-common-4.4.4-9.el7.noarch samba-libs-4.4.4-9.el7.x86_64 samba-common-libs-4.4.4-9.el7.x86_64 samba-common-tools-4.4.4-9.el7.x86_64 samba-client-4.4.4-9.el7.x86_64 samba-client-libs-4.4.4-9.el7.x86_64 samba-4.4.4-9.el7.x86_64 sssd-krb5-common-1.15.2-48.el7.x86_64 sssd-ldap-1.15.2-48.el7.x86_64 sssd-client-1.15.2-48.el7.x86_64 python-sssdconfig-1.15.2-48.el7.noarch sssd-common-1.15.2-48.el7.x86_64 sssd-common-pac-1.15.2-48.el7.x86_64 sssd-ad-1.15.2-48.el7.x86_64 sssd-krb5-1.15.2-48.el7.x86_64 sssd-1.15.2-48.el7.x86_64 sssd-libwbclient-1.15.2-48.el7.x86_64 sssd-ipa-1.15.2-48.el7.x86_64 sssd-proxy-1.15.2-48.el7.x86_64 [root@vm-idm-018 ~]# alternatives --list libnssckbi.so.x86_64 auto /usr/lib64/pkcs11/p11-kit-trust.so pax auto /usr/bin/spax ld auto /usr/bin/ld.bfd print auto /usr/bin/lpr.cups mta auto /usr/sbin/sendmail.sendmail emacs.etags auto /usr/bin/etags.emacs emacs auto /usr/bin/emacs-24.3 cifs-idmap-plugin auto /usr/lib64/cifs-utils/cifs_idmap_sss.so cups_backend_smb auto /usr/bin/smbspool libwbclient.so.0.13-64 auto /usr/lib64/sssd/modules/libwbclient.so.0.13.0 And i was able to access the cifs share [root@vm-idm-018 ~]# smbclient -k -L //vm-idm-018.lab.eng.pnq.redhat.com/share1 Domain=[JUNO] OS=[Windows 6.1] Server=[Samba 4.4.4] Sharename Type Comment --------- ---- ------- share1 Disk test share1 IPC$ IPC IPC Service (Samba 4.4.4) Domain=[JUNO] OS=[Windows 6.1] Server=[Samba 4.4.4] Server Comment --------- ------- Workgroup Master --------- ------- [root@vm-idm-018 ~]# mount -t cifs -o cifsacl -o sec=krb5 -o username=foobar1 //vm-idm-020.lab.eng.pnq.redhat.com/share1 /abc rootfs / rootfs rw 0 0 sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 devtmpfs /dev devtmpfs rw,seclabel,nosuid,size=1930312k,nr_inodes=482578,mode=755 0 0 securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0 tmpfs /dev/shm tmpfs rw,seclabel,nosuid,nodev 0 0 devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /run tmpfs rw,seclabel,nosuid,nodev,mode=755 0 0 tmpfs /sys/fs/cgroup tmpfs ro,seclabel,nosuid,nodev,noexec,mode=755 0 0 cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0 pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0 cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0 cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0 cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0 cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_prio,net_cls 0 0 cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0 cgroup /sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0 cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct,cpu 0 0 cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0 cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0 cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0 configfs /sys/kernel/config configfs rw,relatime 0 0 /dev/mapper/rhel_vm--idm--018-root / xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0 selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0 systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=36,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 mqueue /dev/mqueue mqueue rw,seclabel,relatime 0 0 hugetlbfs /dev/hugepages hugetlbfs rw,seclabel,relatime 0 0 debugfs /sys/kernel/debug debugfs rw,relatime 0 0 sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0 nfsd /proc/fs/nfsd nfsd rw,relatime 0 0 /dev/vda1 /boot xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0 tmpfs /run/user/0 tmpfs rw,seclabel,nosuid,nodev,relatime,size=388220k,mode=700 0 0 //vm-idm-020.lab.eng.pnq.redhat.com/share1 /abc cifs rw,relatime,vers=1.0,sec=krb5,cache=strict,username=foobar1,uid=0,noforceuid,gid=0,noforcegid,addr=10.65.206.154,unix,posixpaths,serverino,mapposix,cifsacl,acl,rsize=1048576,wsize=65536,echo_interval=60,actimeo=1 0 0
Thank you for this test. So strictly speaking there seems to be a change in Samba which caused the failure on RHEL-7.4. But maybe it might be still better to try to fix this in SSSD's libwbclient which might be possible because you said that when using Samba's libwbclient winbindd was not running. So I think the newer version of Samba just expects a different result or return code at some point.
Upstream ticket: https://pagure.io/SSSD/sssd/issue/3461
* master: 725d04cd21016dc6092a9f03cd363bb83d7c054c
Actually, there might be one more patch needed to fix sid-to-id translations..so not sure if this bug is ready to be moved to POST
Should we close this BZ as duplicate of BZ1479398 or vice versa?
master: * aede6a1f4412f133e4b3fd76944f764d76fc4868
(In reply to Lukas Slebodnik from comment #19) > Should we close this BZ as duplicate of BZ1479398 or vice versa? Since BZ1479398 links all the customer cases, I would close this one as a duplicate of BZ1479398.
*** This bug has been marked as a duplicate of bug 1479398 ***