We migrated the file server!

…and forgot to tell you.

I maintain quite a few utilities pulling cyber security data from various scanners, threat intel feeds and asset source etc. We use this data to build dashboards to analyze our progress on patching, vulnerability analysis, asset management.

As it usually goes, the OPS team knew about the migration but never told me, they assumed the file server engineer would tell me and, the file server engineer assumed the OPS team would tell me.

Simple little task, remap the file share to the new server. Murpy waves hi, the remaps do not work. mount.cifs simply does not want to map to the new share, while smbclient works just fine.

Long story short, NTLM authentication was disabled on the new server, only Kerberos auth works. Smbclient simply got a Kerberos ticket automatically and just continued working while mount.cifs just would not work, even if I forced Kerberos auth.

CIFS VFS: cifs_mount failed w/return code = -2

After a lot of crying and digging and crying some more, I discovered the solution on the debian-bugs mailing list (https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1807620.html). The issue was that you need to install the ‘keyutils’ package on Debian for CIFS mounts to work correctly with Kerberos authentication and keyutils is not specified as a dependency on the mount.cifs package.

The above should help you immediately if you have the same issue. If you haven’t configured a Kerberos client on a debian based distribution yet, read further for some help.

Dependencies to be installed:

krb5-user keyutils cifs-utils

Configuration file to be created for krb5-user (The Kerberos client):

[libdefaults]
        default_realm = YOUR.FULLY.QUALIFIED.DOMAIN.INUPPERCASE
        dns_lookup_realm = false
        dns_lookup_kdc = false
[realms]
        YOUR.FULLY.QUALIFIED.DOMAIN.INUPPERCASE = {
                kdc = YOURKDC.YOUR.FULLY.QUALIFIED.DOMAIN.INUPPERCASE
                admin_server = YOURADMINSERVER.YOUR.FULLY.QUALIFIED.DOMAIN.INUPPERCASE
        }

Once you have configured the above, you should be able to do a ‘kinit USERNAMEONTHECONFIGUREDDOMAIN’ and if you type the correct password at the prompt, you should get your Kerberos ticket generated.

Response from ‘kinit’ if a ticket request is successful

Note the ‘renew until’ time. The issue I ran into was the ticket expires if the share is not accessed before the renew time runs out. This required me to create a cron job to automatically refresh the token on a specified interval to ensure the share is always accessible:

#!/bin/bash
echo MYPASSWORD|kinit USERNAMEONTHECONFIGUREDDOMAIN

Lastly, just to be complete, here is the command to mount a SMB share through mount.cifs and force Kerberos authentication. If you have a ticket available for the specified user with ‘klist’, the mapping will work:

mount.cifs //SHARESERVER/SHAREPATH local-path/ -o user=USERNAMEONTHECONFIGUREDDOMAIN,dom=YOUR.FULLY.QUALIFIED.DOMAIN.INUPPERCASE,uid=localusertomountshareas,gid=localgrouptomountshareas,sec=krb5

With that, I dried my tears and carried on with some real work.