1:49 p.m.
/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.
--
Sam Morris <https://robots.org.uk>