/etc/auto.smb is a script used by autofs to make Windows file servers accessible to the automounter. The script basically works by by parsing the output of 'smbclient -L SERVER'. My workplace has a fairly vanilla FreeIPA setup with a one-way trust to an Active Directory domain, and in order for smbclient to be able to list a file server's shares, it has to be able to access the Kerberos ticket cache of the user who requested the mount in order to authenticate to the file servers.

This isn't easy, because the script is launched by autofs, so it doesn't really know anything about the user other than its UID and name. The standard script just checks in some standard hardcoded locations: DIR:/run/user/$AUTOFS_UID/krb5_cc_* and /tmp/krb5cc_$AUTOFS_UID; there's no support for other locations, or any of the more interesting credential cache types.

I discovered that SSSD has a 'ccacheFile' attribute that points to the location of the user's Kerberos ticket cache. After adding '+ccacheFile' to [ifp]user_attributes in sssd.conf and restarting sssd, the following patch to /etc/auto.smb got things working.

The patch is pretty straightforward, it just retrieves the ccacheFile attribute via the sssd infopipe API:

--- /usr/share/autofs/conffiles/auto.smb 2020-01-15 22:04:23.000000000 +0000 +++ /etc/auto.smb 2020-06-28 19:07:01.941702373 +0100 @@ -24,7 +24,19 @@

get_krb5_cache() { cache= - uid=${UID} + uid=${AUTOFS_UID} + # This requires busctl, jq, sssd's infopipe responder, and for sssd.conf to contain [ifp]user_attributes = +ccacheFile + # ... maybe we should just su to the user to run smbclient? + if [[ -x /usr/bin/busctl ]] && [[ -x /usr/bin/jq ]]; then + _user_obj=$(busctl -j call org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe/Users org.freedesktop.sssd.infopipe.Users FindByID u "$uid" | jq -r '.data[0]') + if [[ -n $_user_obj ]]; then + cache=$(busctl -j get-property org.freedesktop.sssd.infopipe "$_user_obj" org.freedesktop.sssd.infopipe.Users.User extraAttributes | jq -r '.data.ccacheFile[0]') + if [[ -n $cache ]]; then + return + fi + fi + fi for x in $(ls -d /run/user/$uid/krb5cc_* 2>/dev/null); do if [ -d "$x" ] && klist -s DIR:"$x"; then cache=DIR:$x

So, I come to this list to find out whether this is a good idea or not: is this attribute an implementation detail, or something that a client of sssd can rely upon? If not, would you consider making it stable, or provide another mechanism to retrieve a user's Kerberos credential cache location--or else propose another mechanism (e.g., I suppose the script _could_ use runuser, su or sudo, etc., to run smbclient as the requesting user, which would automatically pick up KRB5CCNAME via pam_sssd.so)... would that be a better way to do this?

(It appears that the cifs code within the kernel itself has a similar problem; it is able to find a user's Kerberos credentials by use of cifs.upcall(8), which peeks into the environment of the process that caused a key to be requested, and uses the value of KRB5CCNAME that it finds there. autofs can't do something similar because the kernels doesn't make the PID of the requesting process available to it.)

BTW, I might have run into a bug while figuring out the above. I noticed that changes to [libdefaults]default_ccache_name in krb5.conf weren't taking effect even after a reboot! It turns out that pam_sss.so sets KRB5CCNAME during login to the value from its cache, rather than from krb5.conf. I ended up using ldbedit to remove the ccacheFile attribute from my user record and logging in again, whereupon the attribute was added again with the new expected value.