9

I have a Samba server (which is the domain controller), and a Ubuntu 14.04 Client with a logged user who is authenticated by Kerberos (the client joined to domain with Likewise). The user want to access a network share with this command:

mount.cifs //DOMAIN/PATH /HOME/USER/PATH -o sec=krb5

But with (or without) 'sec' parameter, the mount command prompts for password. If I type my password, I can mount the share, but I want to mount without password.

How can I do it with my valid Kerberous ticket?

3 Answers3

10

If you are signing in with a windows domain user a Kerberos ticket is already requested. You can test it by executing klist.

To reuse this ticket you have to add user and cruid option to your mount order. This way you do not have to enter any credentials again.

sudo mount -t cifs -o user=$USER,cruid=$USER,sec=krb5 //domain/path /home/path

To mount the share with your user as owner (and thus with write permission) add the gid and uid options.

sudo mount -t cifs -o user=$USER,cruid=$USER,sec=krb5,gid=$GID,uid=$UID //domain/path /home/path

You get your $GID by running id -g $USER and your $UID by id -u $USER.

It may be that you have to apt-get install keyutils to get this working.

stollr
  • 212
4

First, try -o vers=1. The kernel's SMB2 client has only very recently gained Kerberos support – in Ubuntu 14.04, only the 4.4.x kernel will have it.

Second, check if the request-key and cifs.upcall binaries are installed and that the latter is mentioned in /etc/request-key.conf (or /etc/request-key.d/):

create cifs.spnego * * /usr/bin/cifs.upcall %k

Finally, check the system log (/var/log/debug or journalctl -b) for messages from cifs.upcall, and make sure it is looking for your tickets in the correct place. It doesn't actually know which process is accessing the share and what $KRB5CCNAME it has, so it needs to guess a few common places.

In fact, if you run mount via sudo, the mounting process (running as uid 0) won't have any tickets by default; a separate sudo kinit may be required.

grawity
  • 501,077
2

One more tip. Auto-mounting share with Kerberos needs that required keys are loaded/updated in Kerberos cache. I've found that the most reliable way is to refresh cache right before mounting, with Systemd unit. Created file /etc/systemd/system/kinit.service:

[Unit]
Description=Refresh Kerberos Token
After=syslog.target network.target
Before=mnt-backup.mount
Before=mnt-backup.automount

[Service] ExecStart=/bin/kinit -R -kt /etc/krb5.keytab 'LINUX-CLIENT$@DOMA.IN'

[Install] WantedBy=multi-user.target WantedBy=mnt-backup.mount WantedBy=mnt-backup.automount

And then issue

systemctl daemon-reload systemctl enable kinit.service systemctl restart remote-fs.target