Description of problem: In RHEL-7.6 mounting a CIFS share takes a long time (54s) to complete. The same mount completes on a RHEL-7.5 system within 3s. The machine uses SSSD and 'krb5' as 'auth' and 'chpass' provider. The /etc/krb5.conf contains a list of AD domain controllers. It turns out that cifs.upcall interferes with the 'kdcinfo' file from the SSSD locator plugin. When this file is in place and 'krb5_use_kdcinfo' is set to 'true' in sssd.conf (which is the default), we see unwanted krb5 kpasswd packets going to the AD DC stored in the 'kdcinfo' file. Removing 'kdcinfo' or setting 'krb5_use_kdcinfo' to 'false' resolves the issue. Version-Release number of selected component (if applicable): sssd-1.16.0-19.el7_5.8.x86_64 How reproducible: Always Steps to Reproduce: 1. Configure a RHEL-7.6 machine as AD client using SSSD with 'ldap' as identity provider and 'krb5' as 'auth' and 'chpass' provider 2. Make sure /var/lib/sss/pubconf/kdcinfo.* exists and contains one of the AD DC IP's 3. Mount an AD CIFS share using an AD account with krb5 security options Actual results: It takes very long for the mount to complete. Expected results: Mount completes immediately. Additional info:
In our environment with mount delays and the krb5_use_kdcinfo option... We experience, as of RHEL 7.6, NFSv4 mount delays of 45 seconds when using sec=sys and 90 seconds when using sec=krb5 to a NetApp NFS server if there isn't already a mount to the server. Doesn't appear to experience the delay automounting homedir directly after a reboot though. But if a umount is performed on said homedir and attempt to remount triggers 45/90 sec mount delay. Always reproducible. Disabling gssproxy in nfs config is one workaround. Setting 'krb5_use_kdcinfo' to 'false' while keeping gssproxy enabled is another. Our SSSD config is 'ad' for id_provider and chpass_provider, 'krb5' for auth_provider.
Upstream ticket: https://pagure.io/SSSD/sssd/issue/3958
* master: 05350ab * sssd-1-16: 1791eed
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